Internet2 Network Security SIG

[gcbrowni <>]

I think you both bring up good points.

I think I had avoided TCP/AO in the potential questions because of the weak 
vendor support. Do others see value in including TCP/AO questions in addition 
to MD5? I suppose I could reword the MD5 questions as MD5/TCP-AO? 

Addressing the "good password" issues, and iots relation to MD5 weakness, may 
be a great topic for inclusion in the guide.


Anyone else?





> On Oct 18, 2016, at 9:48 AM, Steven Wallace 
> <>
>  wrote:
> 
> For cases where MD5 is the only viable option, ensuing a good password 
> (e.g., not something in a rainbow table) would mitigate this risk. In this 
> use case it’s the password you want to protect, weaknesses related to 
> modifying the packet such that there’s a hash collision aren’t something to 
> worry about (at least I think).
> 
> ssw
> 
> 
>> On Oct 18, 2016, at 9:09 AM, Paul Howell 
>> <>
>>  wrote:
>> 
>> 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?
>> 
>> 
>> 
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature