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<[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
