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 third party nexthop of a third party AS. The update message does not need to traverse the third party AS at all, but the payload will. The third party ASN might just be another ASN that the first party is using: it might be renumbering. The first party might like to include the third party ASN for loop detection. I don't have a specific feature in mind. Just "what if". On Tuesday, May 29, 2012 2:22 PM, John G. Scudder <> wrote: > 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 left out. In the remaining >> cases, what is the implementation supposed to do? It would be >> necessary to carefully specify. The easiest cop-out would be to say >> that in all such cases, the route fails validation. But I have a >> feeling that it's not that easy. Leaving AS_PATH out reduces that >> particular maze of twisty passages, although it replaces it with >> another: making sure it was really OK to axe AS_PATH to begin with >> (i.e., the discussion above). > > In an offline follow-up with Robert Raszuk, he pointed out that when > one applies a knob that results in an AS_PATH that can't be > represented as a BGPSEC_Path_Signatures [*] there is a third option, > that of downgrading from BGPSEC to unsigned BGP. That is to say, you > convert the BGPSEC_Path_Signatures to an AS_PATH, apply the knob to > the AS_PATH, and propagate the route with the AS_PATH and not the > BGPSEC_Path_Signatures. This is functionally equivalent to "in all > such cases, the route fails validation" but is more straightforward > and seems to make a lot of sense: everything that can be represented > signed, should be. If you insist on doing something that can't be > signed, you can fall back to unsigned BGP and hope for the best. > > 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. > > --John > > [*] The name of this attribute makes for awkward prose since it has > no natural singular. How about calling it BGPSEC_Path_Signature > instead? Or Signed_Path or Signed_AS_Path sans brand name -- Jakob Heitz. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
