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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 25 May 2017 14:26 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23D7129AC7 for <isis-wg@ietfa.amsl.com>; Thu, 25 May 2017 07:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vjPXJ1VVsR9 for <isis-wg@ietfa.amsl.com>; Thu, 25 May 2017 07:26:38 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC9D1243F3 for <isis-wg@ietf.org>; Thu, 25 May 2017 07:26:38 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id 9so168768973pfj.1 for <isis-wg@ietf.org>; Thu, 25 May 2017 07:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jwrfLOllo0GJFP93j94MH/GKsW0fD4GouV2kbcLCZVk=; b=d64r8YGe+lVEepkXWuOCcDyJwe+S4veV/bV0q0OMoR2kNY/s8uMnaMoPBnw50hJtg9 OZg+lZ4uzvB5CClHhnIgVRhDn9ZHeDhCLDNE1tc6xXVnRzHV14swLb4EE6GFra3sTN9p RFGkQNDkDTJrqu7/yhUdoP7GHwZpYCPQFniVczyu40Y2oEJYyXhJQuQ6yssuPXgVvK0U h+6amPo7ZIFoGCONCV6HAOJ8RMTUMGOLfOPQM8+nL/0MV4tkbDSKVBHCWu6JJQm6fgzc Sk76Aese/CPZvJksSXB6r4a8OTQA/U0LOBzY3EQUJby/qh2IXZZlORblxJiNDcKM6mSf WfAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jwrfLOllo0GJFP93j94MH/GKsW0fD4GouV2kbcLCZVk=; b=OkYMXsf9rbbcO1qnsxazLuFl/lG31HvIFyvATV49LHBuiS3ijvbMstIN/T44aj9Hnn qQcx/1MEt2f3r3mZ/9sz78yLezli+VdrmEvtlEOIQJ6UUozZ+SSRuwH6+fSyPwiEKlg+ 1pRdtddBr8ElEpjkQ8P49pA7CGVYSSFmb+BF9dW4kC2cLL2GFA45foxUl2bSaaVLKrWh 06x8FKsScy+YlBC/YmoDH2DwjqrzqlboQ1zCaq+5U7dW5U2LuL8ovYpi3ZCN6Mrv2Ku2 mWjkaoYQB2Ih3Eee6N9yo6xdVYlb+Itg79bqK3bjhukvN8R1RhvQSSPNaLus1CPzKicX rvmA==
X-Gm-Message-State: AODbwcA40aT15W3IRUdQvXGuhGfK8Y7fL6UjyBkiwMAva/3SWtH/SRGr SyZQmeGM5O8KqLFWvpHrX2/le/kwaA==
X-Received: by 10.98.34.203 with SMTP id p72mr46136060pfj.118.1495722398022; Thu, 25 May 2017 07:26:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.186.135 with HTTP; Thu, 25 May 2017 07:25:57 -0700 (PDT)
In-Reply-To: <729a4dd6517f45c3aa9175f609ea57d6@XCH-ALN-001.cisco.com>
References: <149567309799.8624.16080269380002810311@ietfa.amsl.com> <9b951044ae6b4bc69012fffe393ceefc@XCH-ALN-001.cisco.com> <CAHbuEH6fNcTEvt6m5UOk+Qj_+HuzG_HfUpfD=A7zk75xoomtVg@mail.gmail.com> <f0893e23975b44228803df5510ad6198@XCH-ALN-001.cisco.com> <CAHbuEH6yR3zL6WoXUwZ=PyLe5=0TR6wpjyt2Nk4-YArWjsDajA@mail.gmail.com> <8bf15bb4c0cc42ba9cb480efa60508d6@XCH-ALN-001.cisco.com> <07C87855-77EE-43AB-A178-DC7448E68769@gmail.com> <729a4dd6517f45c3aa9175f609ea57d6@XCH-ALN-001.cisco.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 25 May 2017 10:25:57 -0400
Message-ID: <CAHbuEH7vjb1Nghb5ZMzrMN7J9nd-M-c4koaD-XCdz4NtYMi7+A@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "isis-wg@ietf.org" <isis-wg@ietf.org>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>, Adam Roach <adam@nostrum.com>, Eric Rescorla <ekr@rtfm.com>, Suresh Krishnan <suresh.krishnan@gmail.com>, "Benoit Claise (bclaise)" <bclaise@cisco.com>, "mjethanandani@gmail.com" <mjethanandani@gmail.com>, Alissa Cooper <alissa@cooperw.in>, "Alvaro Retana (aretana)" <aretana@cisco.com>, Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/ComtIEPQu5_TudUW4WvMvaxehKQ>
Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-l2bundles-06.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 14:26:41 -0000

Thank you!

EKR, sure.  I'm about to remove my discuss as well.

Kathleen

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



-- 

Best regards,
Kathleen