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

Hi Warren,

Not seeing the problem/error does not mean it is not there.

I would in fact encourage in the initial years of deployment to use both 
to easily detect bugs and inconsistency issues.

In my view we should do all BGP processing based on "legacy" attributes 
and BGPSEC should be a hint to the local operator on how to treat the 
update.

Actually I am of the opinion (I think similar to some research voices in 
US) that secured BGP (or for that matter even origin validation) should 
be handled by few BGP Route Controllers providing AS based overlay 
certificate processing rather then by each individual BGP speaker in the 
network. BGP should be able to transport it as purely opaque information 
which could after automatic detection be used as best path 
decision/preference factor in a given AS.

Regards,
R.

> On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote:
>
>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk<robert@raszuk.net>  wrote:
>>> Anyhow my doubt has been answered and I stay by my opinion that not sending
>>> AS_PATH and AS4_PATH is a terrible idea.
>>
>> So... we can send the data along, but in the case of BGPSEC speakers
>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
>> Carrying extra bits isn't actually helpful is it? (the implementers
>> drove the design decision here I believe)
>
> 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?
>
> There has been much good work in IDR to better handle bugs / implementations issues, and these considerations probably had much to do with this...
>
> For example, I'm a BGPSEC speaker. In the BGPSEC bits I see:
>
> AS1 AS2 AS3 AS4 AS5  All this checks out, the magic crypto says all is happy, etc.
> but, in the AS_PATH I see:
> AS1 AS 100 AS17 AS6
>
> What do I do here? Do I a: drop the update or b: ignore the issue or c: reset the session or d: prefer the singed or unsigned or e: nasal demons?
> Someone who's opinion I really respect once said: Never test for an error condition you don't know how to handle.
>
> This idea extends this by simply not allowing the error condition to occur.
>
> You have all of the information to recreate the AS_PATH / AS4_PATH when you leave a BGPSEC domain, and because it is only in one place, you sidestep all sorts of weird error corner cases...
>
> W
>
>
>>
>>> Perhaps one could depreciate it in 20 years when world is upgraded to
>>> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not
>>> helpful for any even potential BGPSEC deployment model.
>>
>> is it helpful for the folks that write bgp code though? "Hey, you will
>> need to re-synthesize the as-path at sec->non-sec boundaries. you need
>> to also create sec-path at none->sec boundaries."
>>
>> -chris
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>