Re: I-D Action: draft-ietf-isis-l2bundles-06.txt
Alia Atlas <[email protected]>
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <CAG4d1rdOjyApAmhS2oPcNRZ_o+11ALZO3pbUREsZEZq8A4Mnow@mail.gmail.com> |
Les, Thank you very much for your rapid responses and updated drafts. Regards, Alia On Thu, May 25, 2017 at 10:24 AM, Les Ginsberg (ginsberg) < [email protected]> wrote: > Kathleen - > > Thanx for your assistance - https://www.ietf.org/internet- > drafts/draft-ietf-isis-l2bundles-07.txt has been posted. > > Les > > > > -----Original Message----- > > From: Kathleen Moriarty [mailto:[email protected]] > > Sent: Thursday, May 25, 2017 4:39 AM > > To: Les Ginsberg (ginsberg) > > Cc: [email protected]; Mirja Kühlewind; Adam Roach; Eric Rescorla; Suresh > > Krishnan; Benoit Claise (bclaise); [email protected]; Alissa > Cooper; > > Alvaro Retana (aretana); Ben Campbell > > Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-l2bundles-06.txt > > > > Hi Les, > > > > Thank you, this text is much better and it is helpful to detail the full > set of > > considerations. I'll clear my discuss once this has been posted. > > > > Best regards, > > Kathleen > > > > Sent from my iPhone > > > > > On May 25, 2017, at 12:53 AM, Les Ginsberg (ginsberg) > > <[email protected]> wrote: > > > > > > Kathleen - > > > > > >> -----Original Message----- > > >> From: Kathleen Moriarty [mailto:[email protected]] > > >> Sent: Wednesday, May 24, 2017 7:35 PM > > >> To: Les Ginsberg (ginsberg) > > >> Cc: [email protected]; Mirja Kühlewind; Adam Roach; Eric Rescorla; > > >> Suresh Krishnan; Benoit Claise (bclaise); [email protected]; > > >> Alissa Cooper; Alvaro Retana (aretana); Ben Campbell > > >> Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-l2bundles-06.txt > > >> > > >> Hi Les, > > >> > > >> On Wed, May 24, 2017 at 9:39 PM, Les Ginsberg (ginsberg) > > >> <[email protected]> wrote: > > >>> Kathleen - > > >>> > > >>>> -----Original Message----- > > >>>> From: Kathleen Moriarty [mailto:[email protected]] > > >>>> Sent: Wednesday, May 24, 2017 6:29 PM > > >>>> To: Les Ginsberg (ginsberg) > > >>>> Cc: [email protected]; Mirja Kühlewind; Adam Roach; Eric Rescorla; > > >>>> Suresh Krishnan; Benoit Claise (bclaise); [email protected]; > > >>>> Alissa Cooper; Alvaro Retana (aretana); Ben Campbell > > >>>> Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-l2bundles-06.txt > > >>>> > > >>>> Hi Les, > > >>>> > > >>>> On Wed, May 24, 2017 at 9:16 PM, Les Ginsberg (ginsberg) > > >>>> <[email protected]> wrote: > > >>>>> Folks - > > >>>>> > > >>>>> This revision addresses a number of review comments received > > >>>>> during > > >>>> IESG review. > > >>>>> > > >>>>> Here are some responses to some of the points raised by reviewers > > >>>>> (all > > >>>> reviewers have been copied on this email I hope). > > >>>>> > > >>>>> 1)Security section has been revised. > > >>>>> > > >>>>> 2)* Appendix A: The length value for "L2 Bundle Attribute > > Descriptors" > > >>>>> under "TLV for Adjacency #2" is wrong. It says 29 but it needs to > > >>>>> be > > >>>>> 32 > > >>>>> > > >>>>> This has been corrected - thank you Suresh. > > >>>>> I also changed to using RFC5737 approved addresses in the examples. > > >>>>> > > >>>>> 3)Comments provided by Mahesh in his OPS DIR review and cited by > > >>>>> Benoit have been addressed > > >>>>> > > >>>>> 4)Alvaro commented: > > >>>>> > > >>>>> " I would like to see some discussion related to the > > >>>>> "interface" with these > > >>>> external entities." > > >>>>> > > >>>>> I have added explicit text indicating this is out of scope. To > > >>>>> defend this here > > >>>> are several examples: > > >>>>> > > >>>>> RFC 5305 does not discuss how link attribute information is > > >>>>> passed to TE > > >>>> applications > > >>>>> Protocol documents do not define how information is passed to > > >>>>> PCE - we > > >>>> have PCE WG documents for that > > >>>>> Protocol documents do not define how link state info is passed > > >>>>> to BGP-LS - we write separate BGP-LS drafts for that > > >>>>> > > >>>>> I hope my response suffices. > > >>>>> > > >>>>> 5)Kathleen Moriarty argued that advertisement of > > >>>>> o IPv4 Interface Address (sub-TLV 6 defined in [RFC5305]) > > >>>>> o IPv6 Interface Address (sub-TLV 12 defined in [RFC6119]) > > >>>>> o Link Local/Remote Identifiers (sub-TLV 4 defined in > > >>>>> [RFC5307]) > > >>>>> > > >>>>> exposes new security issues. > > >>>> > > >>>> This was a question as opposed to an argument as I was trying to > > >>>> find all possible security issues to assist with adding a security > > >>>> considerations section. I do see that path exposure is covered by > > >>>> the security considerations in other is-is documents. > > >>>> > > >>>>> > > >>>>> I disagree. > > >>>>> > > >>>>> Interface addresses are associated with the parent L3 link and are > > >>>>> already > > >>>> being advertised by IS-IS via existing TE extensions (e.g. RFC > > >>>> 5305, RFC > > >> 4205). > > >>>>> Link IDs for the L2 Links which are advertised are readily > > >>>>> available today via > > >>>> network management tools. > > >>>> > > >>>> Will these be referenced then in the security consideration section > > >>>> for completeness as it is still an issue? > > >>>> > > >>> [Les:] I did not do this. It is a difficult model to follow when > > >>> writing a > > >> document if one is required to explain everything that is NOT an > issue. > > >> > > >> Let's try to work through this as it should be easy to resolve. > > >> Walking through the possibilities should help with EKR's discuss too. > > >> > > >> This draft does add these sub-TLVs, so I would think some text would > > >> be appropriate, even to say this is already an issue (path and other > > >> information is already exposed since confidentiality is not provided). > > >> The draft adds the lag member identity and disaggregated info, is > > >> there anything that needs to be said about them? We typically > > >> include text in drafts about security considerations specific to a > > >> draft or include a reference that explains existing known security > > >> considerations with a reference and I see you are the author on > > >> several from is-is that were nicely written (thanks for that). > > >> > > > > > > [Les:] I appreciate your intent and your willingness to work on > proposed > > text. The point I would like to emphasize is that nothing being > advertised in > > these extensions is new information. All of it is already being > advertised by > > IS-IS for L3 links. The only thing new here is advertising this same > information > > for links which are members of an L2 bundle. I do not believe that > introduces > > new security concerns. But, here is proposed text - let me know if this > will > > address your concerns. > > > > > > " The IS-IS protocol has supported the advertisement of link attribute > > > information, including link identifiers, for many years. The > > > advertisements defined in this document are identical to existing > > > advertisements defined in [RFC4205], [RFC5305], [RFC7810], and > > > [SR-IS-IS] - but are associated with L2 links which are part of a > bundle > > interface on which the IS-IS protocol operates. > > > There are therefore no new security issues introduced by the > > > extensions in this document. > > > > > > As always, if the protocol is used in an environment where > > > unauthorized access to the physical links on which IS-IS PDUs are sent > > > occurs then attacks are possible. The use of cryptographic > > > authentication as defined in [RFC5304] and [5310] is recommended to > > prevent such attacks." > > > > > > Les > > > > > > > > > > > >>> The new statement in the draft says: > > >>> > > >>> "No new security issues are introduced by the protocol extensions > > >>> defined inn this document. Security concerns for IS-IS are > addressed > > >>> in [RFC5304] and [RFC5310]." > > >> > > >> These 2 references are about authentication and the text in prior > > >> drafts that use these references provide an explanation as to why > > >> they are included as references. > > >> > > >> RFC7810 and RFC 7891 do include some helpful explanations for the > > >> security consideration section that might serve as good examples to > > >> follow. I had included the following in my discuss as I thought the > > >> text in this RFC was helpful: > > >> > > >> Security concerns for IS-IS are already addressed in [ISO10589], > > >> [RFC5304], and [RFC5310] and are applicable to the mechanisms > > >> described in this document. Extended authentication mechanisms > > >> described in [RFC5304] or [RFC5310] SHOULD be used in deployments > > >> where attackers have access to the physical networks, because nodes > > >> included in the IS-IS domain are vulnerable. > > >> > > >> Thank you, > > >> Kathleen > > >> > > >>> > > >>> I believe this is both accurate and complete - and my comments above > > >> explain why. > > >>> > > >>> Les > > >>> > > >>>> Thank you, > > >>>> Kathleen > > >>>> > > >>>>> > > >>>>> 6)The shepherd's report and some reviewers have mentioned that > > >>>>> there > > >>>> currently is no OSPF equivalent document. > > >>>>> > > >>>>> This statement is true, but I fail to see how this is relevant to > > >>>>> the progress > > >>>> of this IS-IS draft. > > >>>>> It is often the case that equivalent drafts are written for OSPF > > >>>>> and IS-IS > > >>>> because the same functionality may be required in deployments using > > >>>> either protocol. However we have never linked the progress of the > > >>>> two documents together - it is often the case that one document is > > >>>> written and proceeds before the other. > > >>>>> > > >>>>> I think it would be quite reasonable for OSPF to support > > >>>>> equivalent > > >>>> functionality and it may be that someone - based on real deployment > > >>>> requirements (which is what has driven the writing of the IS-IS > > >>>> draft) - will write such a draft soon. But why this is deemed an > > >>>> issue for the progression of the IS-IS draft is a mystery to me. > > >>>>> > > >>>>> I do want to thank all the reviewers for their time and their > > >>>>> diligence. I think > > >>>> the document is significantly improved based on your comments. > > >>>>> > > >>>>> Les > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Isis-wg [mailto:[email protected]] On Behalf Of > > >>>>>> internet- [email protected] > > >>>>>> Sent: Wednesday, May 24, 2017 5:45 PM > > >>>>>> To: [email protected] > > >>>>>> Cc: [email protected] > > >>>>>> Subject: [Isis-wg] I-D Action: draft-ietf-isis-l2bundles-06.txt > > >>>>>> > > >>>>>> > > >>>>>> A New Internet-Draft is available from the on-line > > >>>>>> Internet-Drafts > > >>>> directories. > > >>>>>> This draft is a work item of the IS-IS for IP Internets of the > IETF. > > >>>>>> > > >>>>>> Title : Advertising L2 Bundle Member Link > Attributes in IS-IS > > >>>>>> Authors : Les Ginsberg > > >>>>>> Ahmed Bashandy > > >>>>>> Clarence Filsfils > > >>>>>> Mohan Nanduri > > >>>>>> Ebben Aries > > >>>>>> Filename : draft-ietf-isis-l2bundles-06.txt > > >>>>>> Pages : 17 > > >>>>>> Date : 2017-05-24 > > >>>>>> > > >>>>>> Abstract: > > >>>>>> There are deployments where the Layer 3 interface on which IS-IS > > >>>>>> operates is a Layer 2 interface bundle. Existing IS-IS > > >>>>>> advertisements only support advertising link attributes of the > Layer > > >>>>>> 3 interface. If entities external to IS-IS wish to control > traffic > > >>>>>> flows on the individual physical links which comprise the Layer > 2 > > >>>>>> interface bundle link attribute information about the bundle > > >> members > > >>>>>> is required. > > >>>>>> > > >>>>>> This document introduces the ability for IS-IS to advertise the > link > > >>>>>> attributes of layer 2 (L2) bundle members. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> The IETF datatracker status page for this draft is: > > >>>>>> https://datatracker.ietf.org/doc/draft-ietf-isis-l2bundles/ > > >>>>>> > > >>>>>> There are also htmlized versions available at: > > >>>>>> https://tools.ietf.org/html/draft-ietf-isis-l2bundles-06 > > >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-isis-l2bundles-0 > > >>>>>> 6 > > >>>>>> > > >>>>>> A diff from the previous version is available at: > > >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-l2bundles-06 > > >>>>>> > > >>>>>> > > >>>>>> Please note that it may take a couple of minutes from the time of > > >>>>>> submission until the htmlized version and diff are available at > > >>>> tools.ietf.org. > > >>>>>> > > >>>>>> Internet-Drafts are also available by anonymous FTP at: > > >>>>>> ftp://ftp.ietf.org/internet-drafts/ > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> Isis-wg mailing list > > >>>>>> [email protected] > > >>>>>> https://www.ietf.org/mailman/listinfo/isis-wg > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> > > >>>> Best regards, > > >>>> Kathleen > > >> > > >> > > >> > > >> -- > > >> > > >> Best regards, > > >> Kathleen > _______________________________________________ > Isis-wg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg