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

[Kathleen Moriarty <[e-mail]>]

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-06
>>>>>> 
>>>>>> 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