Les: I am only going to respond to your many misconceptions inline. Most of the text below are comments which harshly personalizes the discussion rather than consider that Yoav indicates some of the same concern regarding the information that I had as your shepherd. You have rejected my suggested resolution of a RFC7752bis as a way to resolve the security directorates concerns. I will add this fact to shepherd’s report so that Alvaro and the IESG knows you have rejected any resolution that involves revising RFC5572’s security section. It is now up to you to propose a solution that will satisfy SEC-DIR review. Cheerily, Sue From: Les Ginsberg (ginsberg) [mailto:ginsberg@xxxxxxxxx] Sue – Inline. From: Susan Hares <shares@xxxxxxxx> Les: I apologize if my email message was unclear. We both agree that your draft is not related to SR routing. SR routing is related to BGP-LS as a transport mechanism for information. I agree that RFC7752 had traffic engineering information. However, that traffic engineering information almost got that draft rejected by the IESG at the time. As my previous message to this list indicated, we got agreement on RFC7752 based on limiting that information and the assurance that BGP-LS nodes were deployed on a separate set of nodes. Expanding the traffic engineering information beyond RFC7752 re-opens all the security issues and questions from RFC7752’s original review. [Les:] So far, you are the only person who seems aware of this. I am not saying you are wrong – I am just saying my private attempts to get more context for this have thus far failed – and you have not provided any documentation of this. If your statement is accurate (again – not saying it isn’t) – it also seems most unfortunate (and I am being “kind” here) that this was not mentioned in the course of the four years that draft-ietf-idr-te-pm-bgp has taken to progress to this point. [Sue]: You are repeatedly making this a personal issue. As I have stated in previous messages you were not at in-person authors meetings. I cannot help if you do not attend IETF discussions with your shepherd or your co-authors do not relay my concerns. I would ask that you stop any further personal comments. The security directorate reviewer is asking these security questions. The security directorate does have people with both routing and security experts. SR routing is also expanding the information past the original RFC7752. The expansions requested by SR routing also re-open those original security questions and issues. [Les:] I do not know why you mention SR here since we both agree this draft is not SR related. [sue]: Why am I mentioning it? They have a reasonable solution to the security consideration by considering everything as a trusted domain (see RFC8402), and defining who the BGP peers are. Due to deployments, I am trying to help you resolve this issue quickly. . One way to answer these questions is to provide a RFC7752bis with an updated security section. If you agree with this approach, I suggest simply referring to a RFC7752bis that in your security section. If you disagree that an update to the RFC7752bis is required, we can start a thread on that point. [Les:] There is no RFC7752bis draft. J So you are asking me to reference a non-existent document? [Sue]: I am looking for a solution that will technically resolve the security concerns. After you agree in principle, I would go to Alvaro and the IESG and see if we could get a fast-track for the solution. I understand that you (at least) would like to have one – which is perfectly legitimate – though you should go through the normal WG process to take this work on – correct? [Sue]: I am willing to take this through a fast track IDR document since it is for the security considerations only. I am willing to go the extra mile and talk to Routing ADs and the security ADs about a quick resolution. But this dodges the question as to whether draft-ietf-idr-te-pm-bgp has a dependency on enhanced security. So far, you are the only person making this claim – and several folks (including myself) have expressed a different POV. [Sue]: Yoav had the same point of view on the potential security issues in his original review so I am not the only person that believes there is a problem. As I mentioned as a shepherd, I would let the SEC-DIR provide an independent review on whether your security considerations sections was sufficient. Yoav ruled “not sufficient”. At this point, please do not repeat this comment again as it is not true. Restating it over and over does not make it true. Using words like “dodges the issue” are not words that progress a consensus decision forward. I think you at least have to provide a justification for this dependency before we introduce it and get some support for your position – since this will mean draft-ietf-idr-te-pm-bgp would be stuck in MISSREF state until this currently non-existent draft becomes an RFC. [Sue]: The solution could be easy – but you are not willing to listen regarding the proposed resolution. RFC8402 considers the BGP-LS for Segment routing to be a trusted domain and provides some additional comments on BGP peers. My suggestion would have been to revise RFC7752 to be a trusted domain with some of the same wording. Les Did this message clarify my earlier brief message? Do you want to continue to discuss the need for RFC7752bis? Cheerily, Sue From: Idr [mailto:idr-bounces@xxxxxxxx] On Behalf Of Les Ginsberg (ginsberg) Sue – One of us is confused. J draft-ietf-idr-te-pm-bgp is not related to Segment Routing. Those words do not appear anywhere in the document. Nor is there a reference to any SR document. Further, RFC 7752 includes traffic engineering information (see https://tools.ietf.org/html/rfc7752#section-3.3.2 ) so the suggestion that we are introducing a new attack vector by defining some additional(sic) TE codepoints does not make sense to me. I appreciate that there are other drafts on your mind which are SR related – but this is not one of them. Could you please update your response with these points in mind? Thanx. Les From: Susan Hares <shares@xxxxxxxx> Robert, Benjamin, and Yoav: I agree these context of these issues are not specific to this draft. However, traffic engineering information does provide information which is a tempting attack vector. The original RFC7752 described a different purpose with restricted usage that SR routing extensions do not adhere to in BGP. Since Spring WG shows that operators are interested in the extended use, it may be time to examine the RFC7752bis or other solutions that takes care of these security issues. My job as a shepherd is to point out these issues per draft for the IESG and security directorate in order to obtain the correct feedback. As a WG chair, I have pointed out these issues, but the WG has these drafts on WG LC without the extra security. Without RFC7752bis with additional security in the base document, I am working as a shepherd make the manageability and security sections as clear as possible. If the feedback from the security directorate review or the IESG is that we need to obtain a solution for RFC7752bis that describes and handles these security issues, I will be glad to support fast-tracking this issue within the WG. If an offline discussion with Benjamin, Yoav, the IDR chairs, and Alvaro would speed this along, I can set this up early next week. It would be helpful to have this offline discussion before the IDR interim session on 10/26. Thank you for all your comments. Sue From: Idr [mailto:idr-bounces@xxxxxxxx] On Behalf Of Robert Raszuk 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:
|
