John: I believe we are aligned on the next steps. Thanks for the input. Cheerily, Sue From: John E Drake [mailto:jdrake@xxxxxxxxxxx] Sue, Comments inline. Yours Irrespectively, John From: Susan Hares <shares@xxxxxxxx> John: I agree with you that this issue is not specific to draft-ietf-idr-te-pm-bgp-13.txt, but should be taken up as a revision to RFC7752. [JD] Fine w/ me I disagree with you on the change of scope for RFC7752. This draft (draft-ietf-idr-te-pm-bgp-13.txt) does add additional risk for the scope of the attack surface on RFC7752 as it adds to the traffic engineering information passed. [JD] That sounds suspiciously like an assertion [Sue2] Yes – this is my assertion. If you wish to have this assertion reviewed by security directorate, I can ask. However, we agree on the solution. Shall we agree on creating RFC7752bis that expands the security section? I am glad to sponsor a “fast-track” action on an RFC7752bis. [JD] Fine w/ me Yours respectfully, Sue From: John E Drake [mailto:jdrake@xxxxxxxxxxx] Hi, I was a co-author of RFC 7471 and RFC 7810, which introduce a handful of new TE metrics into the existing OSPF and IS-IS TE infrastructures. The subject draft does exactly the same thing for the existing BGP-LS TE infrastructure defined in RFC 7752. As Les correctly points out, if there are security issues with the existing BGP-LS TE infrastructure or more generally with RFC 7752, then those issues need to be addressed with a revision of that RFC and not with this draft. I.e., this draft does not change the scope of RFC 7752 in any way. Yours Irrespectively, John From: Idr <idr-bounces@xxxxxxxx> On Behalf Of Les Ginsberg (ginsberg) Sue – I was not an author of RFC 7752 and have no idea what promises the authors might have made. I will say that it seems very late in the game for you to suggest that this document should not be allowed to progress because it exceeds some agreement on the scope of RFC 7752. Why weren’t these concerns expressed long before? If you feel that RFC 7752 security needs revision I would appreciate it if you state so clearly (to the WG – not just to me) and in the right context. Such work is clearly not in the scope of draft-ietf-idr-te-pm-bgp. Les From: Susan Hares <shares@xxxxxxxx> Les: Thank you for responding to Robert’s post. Your argument that this information would have added to RFC7752 is on “thin ice” as the IESG in their approval of RFC7752 was concerned about the scope of the information. The extension of the scope beyond its stated scope might have trigger the current discussions at that time. The authors indicated to the IDR chairs the RFC7752 scope would not grow. As shepherd I requested this draft to be reviewed by the security directorate because we are going beyond the original scope of RFC7752 with this draft. As Shepherd, I do not agree with you that security issues Yoav raises are specified in RFC7752. I You are correct that there are many drafts (just BGP-LS extensions and segment routing extensions that use BGP-LS). This draft is just the first of a wave of drafts. It is appropriate to have a solution for the security issues that covers all the drafts rather than go through drafts one at a time. I suggest that a revision to RFC7752 that addresses these issues is appropriate. If you are interested in discuss this topic with Yoav, Benjamin, and the IDR WG – shall we start a thread on this topic? Susan Hares From: Idr [mailto:idr-bounces@xxxxxxxx] On Behalf Of Les Ginsberg (ginsberg) Robert’s post addresses points I also want to make. What is being done here is to add additional BGP-LS codepoints to advertise IGP information that was not defined at the time RFC 7752 was written. We haven’t changed the BGP-LS transport mechanism – nor is the information being advertised here (some additional TE related link attribute information) qualitatively different than a number of existing TLVs defined in RFC 7752 (see https://tools.ietf.org/html/rfc7752#section-3.3.2 ). If this information had already been defined in the IGPs at the time RFC 7752 was written it would simply have been included as a section of RFC 7752 and no additional changes to RFC 7752 would have been required. In theory, we could have simply updated RFC 7752 rather writing a separate draft, but practically this would be a poor strategy as it would incorrectly suggest that some change was being made to the existing text in RFC 7752. I appreciate that from the POV of the Security Area you folks are not as intimately familiar with the routing drafts and the relationship between them. It is therefore understandable that you start looking at the new draft as a standalone document – and in that context your comments are absolutely correct. But the document you are reviewing is most accurately seen as an “addendum” to RFC 7752. The issues you raise have already been addressed in RFC 7752 and it is therefore very appropriate that we address your concerns by including a reference to the RFC 7752 security discussion. I think it is important that you note this relationship, because the nature of BGP-LS is that whenever IGP extensions are defined to advertise new information it is necessary to define corresponding BGP-LS codepoints. This is not the first such BGP-LS extension document – and it is safe to say it won’t be the last. It would be helpful to all if we reached a common understanding or this discussion will take place every time a BGP-LS extension document is being reviewed – which will cost us all time needlessly. Les From: Robert Raszuk <robert@xxxxxxxxxx> Hello Benjamin, Not sure if you have spotted similar comment made to IDR regarding this topic, but your comment seems to indicate that here we are about to define ways to carry nicely scoped IGP information into BGP. Well that has already happened with RFC7752 and your comment or for that matter Yoav's remarks are indeed spot on but to the security discussion on RFC7752 and IMO not any follow up extensions of it. Sure - as observed by Sue - one may argue that providing more information about the network to the potential attacker makes the network weaker, but the cure for that is to prevent the leaks and reduce probability of intercepting new information by unauthorized parties. BGP-LS is already defined in a new SAFI what by itself does provide nice level of isolation. RFC7752 is pretty clear on that too and says: "BGP peerings are not automatic and require configuration; thus, it is the responsibility of the network operator to ensure that only trusted consumers are configured to receive such information." If someone would be still concerned about configuration mistakes and negotiating SAFI 71 or 72 to those who should not get this data I recommend we reissue the RFC7752 as -bis version and restrict the scope of the distribution even further by mandating default use of NO-EXPORT community with ability to overwrite it for the selective eBGP peers. Or perhaps we could progress Jim's One Administrative Domain draft (draft-uttaro-idr-oad-01). In either case while both of your comments are great they seems a bit late in the game here or at least targeting wrong document. Kind regards, Robert. On Fri, Oct 19, 2018 at 2:27 AM Benjamin Kaduk <kaduk@xxxxxxx> wrote:
|
