Re: [sidr] [Idr] No BGPSEC intradomain ?

["George, Wes" <[e-mail]>]

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Thursday, April 12, 2012 10:51 AM
> To: Robert Raszuk
> Cc: George, Wes; Paul Jakma; [e-mail] List; [e-mail]
> Subject: Re: [Idr] [sidr] No BGPSEC intradomain ?
>
> On Thu, Apr 12, 2012 at 03:52:29PM +0200, Robert Raszuk wrote:
> > I very much agree with both Paul and Wes that new BGP version number
> > or at least new set of AFIs would be the best way to smoothly
> > migrate unsecure BGP to secure one.
>
> If it's not backward compatible, sure.
[WEG] that's sort of the point -- there are a lot of factors to consider when determining what "backward compatible" truly means as far as BGPSec is concerned, especially when it comes to monitoring tools and other things that need to know the data but not necessarily make routing decisions on it.
>
> > I have not seem anyone resisting that idea yet with real technical
> > arguments against it ;)
>
> See my migration comments earlier.  If you think you can get a given SP that
> might be willing to install BGPSEC at the edges also willing to upgrade
> every other BGP speaker inside their AS... you're more optimistic than I.

[WEG] I'm not totally sure which message you're referring to, but I think that may be a red herring. I'm not seeing how incrementing the BGP version automatically means that all routers in an ASN must upgrade to it. This isn't exactly the same flag day sort of driver as the move between v3 and v4. BGP speakers that support BGPv5 also SHOULD support BGPv4, and would determine which they should use on initial capability negotiation. Same way as they would do if BGPSec (and any other option) is a standalone capability to negotiate. Even if you look at this from a scaling perspective (the BGPv5 speaker would have to craft and send out two different versions of update) we've already sort of said that this is acceptable collateral damage because of the fact that it can't send the same updates to neighbors of multiple different ASNs because it has to sign them all differently.
What am I missing?

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.