Subject: RE: [Sidr] Transport security

From: "Smith, Donald" <[email-masked]>
Date: Thu, 6 Jul 2006 11:00:23 -0600

Our IDS reports a false negative rate of 0 (Dr J).
[email-masked] giac   

> -----Original Message-----
> From: Tom Petch [mailto:[email-masked]] 
> Sent: Wednesday, July 05, 2006 2:09 AM
> To: Iljitsch van Beijnum; [email-masked]
> Subject: Re: [Sidr] Transport security
> 
> <inline>
> Tom Petch
> 
> ----- Original Message -----
> From: "Iljitsch van Beijnum" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, July 04, 2006 11:08 AM
> Subject: [Sidr] Transport security
> 
> 
> > On 3-jul-2006, at 23:56, Geoff Huston wrote:
> >
> <big snip>
> 
> >
> > Finally, as someone who works with BGP with MD5 passwords in
> > practice, I can tell you that operators in general don't even think
> > about changing keys. Yes, coordinating changing a key on both sides
> > at the same time is a pain, but coordinating changing a key 
> PERIOD is
> > almost as big a pain because even ASes that aren't very big can
> > easily have 100 peers or more and only the middle sized 
> ones are easy
> > to work with, the smaller ones barely have a clue and the 
> larger ones
> > have huge bureaucratic NOCs where it's hard to find the 
> right person.
> > And of course everything stretches across timezones and there are
> > often language barriers. Exchanging the key securely is also a big
> > problem. Making key rollover easier isn't going to change all that
> > much here, and there is no perception of immediacy anyway.
> >
> True, but working with enterprises teaches me that noone 
> takes security
> seriously until they have felt sufficient pain, millions of 
> euros or dollars.
> 
> Not long ago, noone used MD5 for BGP, suddenly they were, I 
> understand because
> of an incident (at a large European IX?).  
Network element vendors recommended the use of MD5 to mitigate the tcp
reset via sequence number guessing vulnerability 
http://www.uniras.gov.uk/niscc/docs/al-20040420-00199.html?lang=en 

That was basically the only mitigation available from the network
element vendors when this vulnerability was announced.

Also the MD5 M and M' collision issue is as far as I know ONLY an issue
when M is known so that M' can be generated to hash to the same value.
This is not the case when MD5 includes a "secret" password.

>When there is the 
> next incident, we
> should have the technology ready, and it is not difficult.  
> All we need is the
> ability to invoke key generation dynamically, with an 
> exchange of pseudo-random
> numbers etc leading to a new key pair, so that all the 
> operator sees is two
> knobs, one saying generate key change now, and the other 
> saying accept key
> change request from peer; the rest is protocol.
> 
> Tom Petch
> .
> 
> 
> 
> 
> > _______________________________________________
> > Sidr mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sidr
> 
> 
> _______________________________________________
> Sidr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sidr
> 

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr