Wes,
Comments inline below marked with [ks]. > >Being pragmatic, I understand that the risk is low for exceeding the max size >without extended message support based on the average AS-path length, but I >have concerns about the suggested solution that treats unsigned updates as a >fallback path for updates that would otherwise be too large. > [ks] There seems to be some misunderstanding here. Let me try to clarify. [ks] The proposed change is simply that BGPsec specification acknowledges that there is a maximum message size, which is provided by BGP. (That is 4096 bytes maximum size currently and in the future it may be more.) BGPsec simply abides by the maximum size. Then the design question is: What does the sending BGPsec router do when it finds that by adding its Secure_Path and Signature Segment, the size exceeds the maximum message size? (This question needs to be addressed independent of the actual value of the maximum size provided by BGP.) [ks] The secondary question is how often does it happen (i.e. exceeding the maximum size)? You seemed to say “risk is low for exceeding the max size without extended message support based on the **average** AS-path length.” Actually, the worst-case AS-path length was used. Please see the analysis in my previous post. https://www.ietf.org/mail-archive/web/sidr/current/msg08502.html >First, I don’t believe that there is any construct within the current BGPSec >setup that allows for this sort of mixed mode where most updates are signed >but some subset are not. Normally it’s something negotiated on session >establish - either BGPSec is supported by both neighbors, or it is not - and >the BGP machinery handles updates accordingly. [ks] When BGPsec is negotiated, it simply means that the router can send/receive BGPsec updates. Traditional unsigned updates can still be exchanged on that session as necessary. This was part of the design from the start. That’s because an AS may negotiate BGPsec with a peer but can have a customer that is not upgraded to BGPsec. Once a BGPsec session is established, an update may have BGPsec_Path or (unsigned) AS_PATH attribute, but not both. See section 2.2, p.5: “BGP update messages without the BGPsec_Path attribute (i.e. unsigned updates) MAY be sent within a session regardless of whether or not the use of BGPsec is successfully negotiated.” >So likely the document would need some additional guidance on how that mixed >mode is supposed to work. I think it’s pretty straightforward since there is >already a defined process for stripping signatures and sending unsigned >updates, but there’s sufficient grey area that I am not comfortable leaving >this “as an exercise for the implementer” since it needs to properly >interoperate. [ks] Please see my response above. However, it is worth double checking to make sure that what you are suggesting is stated clearly in the document. I’ll do that. >And if what is being suggested is that one update being too large drops the >entire session back to unsecured mode, that seems even worse. [ks] No. That is not being suggested. Thanks. Sriram
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
