Missed one:
On May 29, 2012, at 2:24 PM, John G. Scudder wrote:
Philosophically, the thing that makes me worry the most is that we're
cutting out one of BGP's fundamental elements and replacing it with one
which provides only a subset of its semantics. Specific things missing
include:
[Sigh. Again with the right source email address.]
Missed one:
On May 29, 2012, at 2:24 PM, John G. Scudder wrote:
Philosophically, the thing that makes me worry the most is that we're
cutting out one of BGP's fundamental elements and replacing it with one
which provides only a subset of
AS_PATH specifies the ASs through which the routing announcement has
passed.
Signed_AS_PATH is to verify the path that the update message takes.
and here i thought that detecting that they differ, as an attack, is the
core goal of as-path validation.
Okay, I seem to be confused.
IDR folks,
BGPSEC (in the SIDR WG) includes a path attribute, BGPSEC_Path_Signatures, that
substantially overlaps the semantics of AS_PATH. For reasons discussed in the
forwarded note below, it proposes that updates carrying BGPSEC_Path_Signatures
should NOT carry AS_PATH.
Since this would
On May 29, 2012, at 2:24 PM, John G. Scudder wrote:
It's also worth noting that leaving AS_PATH in would not be without cost. In
the cases where the content of AS_PATH is isomorphic to that of
BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH
clearly could have been
[Once more from proper account, sigh.]
On May 29, 2012, at 2:24 PM, John G. Scudder wrote:
It's also worth noting that leaving AS_PATH in would not be without cost. In
the cases where the content of AS_PATH is isomorphic to that of
BGPSEC_Path_Signatures, there's no problem -- but in those
This leaves me feeling a little more sanguine about the
drop-the-AS_PATH idea, although I still think some more attention to
enumerating what knobs will fall by the wayside is advisable.
as folk keep inventing new knobs, one question would seem to be whether
the knob inventors will understand
AS_PATH is used to specify the path that the payload takes.
Signed_AS_PATH is to verify the path that the update message takes.
There is no reason they can not be different. Let the verifying
function take both as input and let it decide based on policy.
An AS could forward an update with a
AS_PATH is used to specify the path that the payload takes.
really? i thought it was a routing loop detection mechanism.
it's been a while since folk wrote research papers describing
schemes for routing by AS.
i would phrase it as
AS_PATH specifies the ASs through which the routing
On Tuesday, May 29, 2012 5:29 PM, Randy Bush mailto:ra...@psg.com wrote:
AS_PATH is used to specify the path that the payload takes.
really? i thought it was a routing loop detection mechanism.
it's been a while since folk wrote research papers describing
schemes for routing by AS.
i
and here i thought that detecting that they differ, as an attack, is
the core goal of as-path validation.
I thought it was to prevent an AS from announcing an update that it
was not authorised to.
nope. that is rpki-based origin validation. we are now talking about
as-path validation.
from
On Tuesday, May 29, 2012 5:52 PM, Randy Bush mailto:ra...@psg.com wrote:
and here i thought that detecting that they differ, as an attack, is
the core goal of as-path validation.
I thought it was to prevent an AS from announcing an update that it
was not authorised to.
nope. that is
12 matches
Mail list logo
