On Fri, Mar 23, 2012 at 6:59 AM, Robert Raszuk <[email protected]> wrote: > >>> When compared to what is today I don't think folks are mandated by any >>> RFC >>> to make a choice between two attributes which carry the same metric to >>> decide which one should win on a per AS basis. >> >> >> they are not, and in the future the 'mandate' is I believe a 'SHOULD', >> not a 'MUST' so not really a 'mandate', but a 'suggestion', eh? >> >> It seems that the intent of the effort here is really just to provide >> an informational blob to the operators which they can use as they see >> fit... much like other optional transitive attributes today. > > > Ok that sounds very reasonable indeed.
progress! > However number of folks have stated that bgpsec protocol proposal calls for > replacing AS-PATH and AS4_PATH attributes with BGPSEC_Path_Sig attribute. In > particular this text from /draft-ietf-sidr-bgpsec-protocol-02 sort of > suggests that: > > The other option is that the BGPSEC speaker 'other option' > discards anything in the AS_PATH attribute and reconstructs the I believe this means: "You could just ignore AS_PATH and reconstruct the content there from ..." (or that's how I read the clipping) > AS_PATH from the data in the BGPSEC_Path_Signatures attribute. I > believe that there are no interoperability problems if the choice > between these two options is left up to the BGPSEC speaker. probably in this last sentence they mean "bgpsec listener" (since this is on the receiver, not the sender?) > Also it says in the same section 5: > > One option the 'option' > BGPSEC speaker checks the AS_PATH attribute against the information > in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the > two do not match. > > That means that if AS_PATH for example contains AS_SET that someone doing > BGP multipath (across non identical paths) has correctly inserted into > AS_PATH or as mentioned before did replace-as the update will be dropped as > BGPSEC just can not handle those .... sure. 'option' I don't think if there were an AS_SET in the update coming from the BGPSEC speaking peer there would be sig parts to worry about (since the inclusion of AS_SET means you can't secure the path...So, I suppose if this condition exists the path is invalid by default? and likely spoof/bad/malicious?) > > > Meta question: > > Can optional attribute result in such drastic actions (nothing to do with > operator's choice of local behavior) against mandatory attribute(s) ? I think you created a situation which is actually in violation of the standard... or which would be seen as a malicious update and which should be dropped, so I'm not sure your meta-question follows properly here? -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
