Re: [Isis-wg] I-D Action: draft-ietf-isis-l2bundles-06.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, May 25, 2017 4:39 AM
> To: Les Ginsberg (ginsberg)
> Cc: [e-mail]; Mirja Kühlewind; Adam Roach; Eric Rescorla; Suresh
> Krishnan; Benoit Claise (bclaise); [e-mail]; 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)
> <[e-mail]> wrote:
> >
> > Kathleen -
> >
> >> -----Original Message-----
> >> From: Kathleen Moriarty [mailto:[e-mail]]
> >> Sent: Wednesday, May 24, 2017 7:35 PM
> >> To: Les Ginsberg (ginsberg)
> >> Cc: [e-mail]; Mirja Kühlewind; Adam Roach; Eric Rescorla;
> >> Suresh Krishnan; Benoit Claise (bclaise); [e-mail];
> >> 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)
> >> <[e-mail]> wrote:
> >>> Kathleen -
> >>>
> >>>> -----Original Message-----
> >>>> From: Kathleen Moriarty [mailto:[e-mail]]
> >>>> Sent: Wednesday, May 24, 2017 6:29 PM
> >>>> To: Les Ginsberg (ginsberg)
> >>>> Cc: [e-mail]; Mirja Kühlewind; Adam Roach; Eric Rescorla;
> >>>> Suresh Krishnan; Benoit Claise (bclaise); [e-mail];
> >>>> 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)
> >>>> <[e-mail]> 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:[e-mail]] On Behalf Of
> >>>>>> internet- [e-mail]
> >>>>>> Sent: Wednesday, May 24, 2017 5:45 PM
> >>>>>> To: [e-mail]
> >>>>>> Cc: [e-mail]
> >>>>>> 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
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Best regards,
> >>>> Kathleen
> >>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Kathleen