Skip to Content.
Sympa Menu

netsec-sig - Re: [Security-WG] I2 - draft RFC 7454 Survey from the Technolocy Exchange session

Subject: Internet2 Network Security SIG

List archive

Re: [Security-WG] I2 - draft RFC 7454 Survey from the Technolocy Exchange session


Chronological Thread 
  • From: Paul Howell <>
  • To: "" <>
  • Subject: Re: [Security-WG] I2 - draft RFC 7454 Survey from the Technolocy Exchange session
  • Date: Tue, 18 Oct 2016 13:09:29 +0000
  • Accept-language: en-US
  • Authentication-results: internet2.edu; dkim=none (message not signed) header.d=none;internet2.edu; dmarc=none action=none header.from=internet2.edu;
  • Ironport-phdr: 9a23:n9u1AxCG9kviyfUrpuXTUyQJP3N1i/DPJgcQr6AfoPdwSP3yoMbcNUDSrc9gkEXOFd2Crakb26yL6Ou5BCQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpW1aJhKqfxF4LfnvG5LDytu4/+G055DJZQhU3nywba44ZEGtoA7MrMgKkM59JY4wzAfEuH1FZ74QyG91cwG9hRH5s/+54Zor0yNPtvYlv5pYUaLlcqA8Zb1eEDk8NW0pvovmuQSVHljH3WcVTmhDykkAOAPC9hyvBpo=
  • Spamdiagnosticoutput: 1:0

Hi,

On the topic of MD5 authentication, I thought RFC5925 TCP-AO obsoletes MD5,
so should there be TCP/AO questions on use and vendor support?

The rest of this looks pretty good.

Regards,
Paul

-----Original Message-----
From:
<>
on behalf of gcbrowni
<>
Reply-To:
<>
Date: Tuesday, October 11, 2016 at 1:29 PM
To:
<>
Subject: [Security-WG] I2 - draft RFC 7454 Survey from the Technolocy
Exchange session

Good Afternoon Everyone!


During the Miami Technology Exchange there was a working session about the
routing security controls in RFC7454. During the session there was feedback
that a community survey would be a great way to help get an overview of the
posture of both the regionals/transit and the campus sites.

The goal would be to use the survey as the basis for a discussion around
which we create material to help guide the community. I hesitate to use the
term "Best Practices", but, at least a paper that discusses the pros and cons
of each control so that community members can make a better informed
decision, and maybe also some recomendations from our peers. This would all
be supported through the I2 website, along with config examples and
webcasts/recorded tutorials, etc. There would most likley be two different
perspectptives: campus & transit, since they sometimes have divergent needs.

I put the following together as a first draft of the questions we might be
interested in. I’d appreciate feeback from the group. We’d probabally use a
survey tool, much the way Steve Wallace did when he sent one recently about
BCP38 controls. Results would be anonymous and aggregated. If someone
represented both a campus & transit provider then we’d ask that they take the
survey twice, just as wallace did.



Comments? Suggestions? Anything else, or different, that you would like to
see?

-Grover

=========

For each of these (except the first), I was thinking we'd ask if the site was
implementing the control (via a simple toggle) and why/why not they were
doing it? I think the why/why not comments could potentially be the most
useful part of the survey. We’d also ask if they considered the control a
MUST or a SHOULD, for a typical user in that situation.



Are you answering more from a end-site/university perspective or an
aggregator/regional perspective?
Do you filter BGP so that only your approved BGP peers can send TCP/179 to
you?
Do you rate limit your BGP so TCP/179 can not flood your site with traffic?
What levels did you select?
Are you encouraging your peers to use MD5 authentication?
Have you encountered problems, operationsally, with
supporting/troubleshooting MD5 and/or key rotation?
Are you filtering on your borders so that external traffic can not be
directed to your iBGP addresses?
Are you implementing GTSM or performing other security work using TTLs?
Are you currently implementing dampening?
If so, at what levels?
Have you implemented a max-prefixes setting on your BGP sessions?
Are you filtering private ASN’s inbound and outbound?
Are you explicitly setting the next-hop for received eBGP routes to the
router that you the prefix?
Are you scrubbing communities from the prefixes you receive, when they are no
longer appropriate?
For customer BGP sessions, so you explicitly filter what you will accept from
them?
Are you filtering martians, default, unassigned address space to/from your
peers?
Are your IPv6 controls the same as your IPv4 controls?
How do you review your controls and keep things up to date?
Are you doing anything with RPKI?






Archive powered by MHonArc 2.6.19.

Top of Page