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

[Jeffrey Haas <[e-mail]>]

On Thu, Apr 12, 2012 at 01:07:38PM -0400, George, Wes wrote:
> [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.

Fish aside, given prior statements that once you leave a BGPSEC domain that
you stop doing BGPSEC, then it seems reasonable that you can't have bgp-4
inside of bgpsec.

I suspect that's not what some people are meaning by BGPSEC domains or
versions or what have you.  But this is all fall-out of what does it mean to
do BGPSEC in an AS that won't have some number of routers that can do it.

The original model discussed was BGPSEC signature operations at eBGP
borders.  In that model, iBGP considerations are largely irrelevant to the
signatures.  Where they become important is the edge cases where iBGP may
alter AS_PATH data. 

If iBGP speakers are expected to participate in signature operations, we
need to figure out what that means.  Chris M. suggests signing at
origination - signing to what exactly?  When there's confederations, is
there signing?  What do those certs look like in the RPKI especially when AS
numbers are re-used (private ASes)?  How do you handle confederation AS
stripping signature-wise?

If you don't believe each router in an AS needs an upgrade, you obviously
have protocol behavior in mind.  Write it down, please.  Keep in mind the
answer will change based on whether BGPSEC operations are done in iBGP or
not.

> 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.

If you can do the work via capability negotiation, I'd argue you don't
really need a new version number.

-- Jeff