[sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)

[Jeffrey Haas <[e-mail]>]

I'm not at my usual spot in the week to catch up on IETF mail, but this
thread is noisy enough that it's caught my attention anyway. :-)

On Tue, Apr 10, 2012 at 01:37:34PM -0400, Warren Kumari wrote:
> I think that sone of the biggest issues to keep in mind with carrying the "same" data in two places is what to do when you suddenly discover that they are not actually the same?

The apparent issue in this thread is basically, "what happens to AS_PATH?"
Glancing at draft-ietf-sidr-bgpsec-protocol-02 (and not thoroughly reading
it), there's commentary about what should be done with the AS_PATH.  That
commentary is mostly correct in the sense that all of the path loop
detection is already present.  (And the mostly is important.)  

IMO, there are two specific issues with regard to removing the AS_PATH and
one with keeping it.

1. What do you do about confederations?  These ASes are not only typically
internal but would have to use some sort of internal certs if we decided to
cover the confederation case.  Additionally, the current encoding format
doesn't include AS_PATH segment type as part of the signature.  

Note in particular that confederation segments MUST be stripped when
crossing an eBGP boundary.

2. More generally, what do you do about incremental deployment *within* the
AS?  One presumption I've been working on that I *thought* was shared by the
WG was that BGPSEC procedures only had to be done at eBGP edges.  While this
is primarily true for signature validation purposes, a desired side effect
of having the signature as a optional,transitive that paralleled the AS_PATH
was that iBGP speakers don't have to even be BGPSEC aware.  This lets you
upgrade your network from the outside first and get benefit.

As John Scudder likes to say, "a hard, crunchy shell". :-)

IMO, we should keep the AS_PATH.

3. Which brings us to the third point - what do we do when the signature and
the AS_PATH disagree with each other?  Note that this was also a problem for
4-byte ASes (RFC 4893).  That spec chose to simply trust the 4-byte path
beyond a certain point.  (I don't necessarily agree with it, but that's what
consensus was.)  Exactly what we do here needs to be specified, and some of
that specification will come from deciding what we want to do about some things.

For example, we want to prevent the path from being shortened.  As long as
the ASes involved in both signature and path are congruent, we can use the
length in the signature if the number of ASes in the path are shorter than
the signature.

In the case where the paths are still congruent but the AS_PATH has a longer
prepend (see my ingress prepending use case from a few sessions back), it
may be fine to use the AS_PATH (and its length for route selection
purposes).  Yes, I understand there isn't consensus here.

In the case where the paths are not congruent (which shouldn't happen unlike
the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across other BGP), we
probably have some sort of hard error case.  One reasonable assumption is
that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP speaker
doing path manipulations for policy.  IMO, the proper behavior here is to
*not* propagate the route at a BGPSEC ASBR boundary; any BGP speaker that
manipulates the AS_PATH in such a way as to break the congruency of ASes
between AS_PATH and signature MUST be a BGPSEC speaker.

The above still doesn't deal with common deployment considerations such as
as-override, replace-as and remove-private.  I see there's a thread about
proxy signing and perhaps that discussion is over there.  I'll hopefully get
to it in a few days.

(And if you're not familiar with those three features and their deployment
scenarios, please take some time to become familiar.  Not dealing with them
will be a significant deployment hurdle.)

-- Jeff