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

Alia Atlas <akatlas@gmail.com> Thu, 25 May 2017 14:34 UTC

Return-Path: <akatlas@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 3AA91129666 for <isis-wg@ietfa.amsl.com>; Thu, 25 May 2017 07:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, 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 jlhEb-eXZEpp for <isis-wg@ietfa.amsl.com>; Thu, 25 May 2017 07:34:24 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 AB04212441E for <isis-wg@ietf.org>; Thu, 25 May 2017 07:34:23 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id 7so94033457wmo.1 for <isis-wg@ietf.org>; Thu, 25 May 2017 07:34:23 -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; bh=5Kst2bwZXccipMuDfbEYuCcVVJsld0FFnmDLqbRs2iM=; b=Gm74i88EY5/7Ths3xN+7M9DyAHQjEOcvuDpHIoo9OfK3o+dcTZV58+UKi2LyjWC71e U2cOpgdUmHMpkPGfeIytvsXiw7ge8dfrQUqzXvW0T8CdWgKwhn2BkskYXmu5XmE/6hag vn+ors/T5LbjoxH6jUcCyn3kTYpIceodJEPjKGxDPcu6byKqqAdAR3apSaW1bg43MSt7 tQRjhNnHbT4HBD8j0WWyQzOxE0/IAFwq4SeyrSOPSRphl/CPQZcbHFknyyOaz0+b3Cxc OpSqjHvtURX039ej1Er0TY3EUcN+ES4i6bfRQ24vfmwDnRuIgvWvE2xgYOsVhfP916JH u2JA==
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; bh=5Kst2bwZXccipMuDfbEYuCcVVJsld0FFnmDLqbRs2iM=; b=rjN7yK3dEVbmZFkMtNiSHEjRZCTxEUENm4vcAdlzGtA3bfwG1E7ckmdCUb6bVHgG0j t8KCnKMEtkLL/kKJoYQXpknwxEcQ9OEv708VDVliShH4Zg7DRU6HmdB8GKUtDRPMbkzB od9QV3Uk65qa5anjU6lOPvxHV5biM6u+0GOwUBwBGURkEOEapqGZSIxh1FPCH8WYXlXl Jzxj1SoKDmciK7ahemb97Rs7mQSH+L+bIW+0ia3iVfS60O04X/tb8v0q2o1wBmC/pOXz C3O3NaK95dE+vYzkk/HhueBaGTjTK+fn8R/AS16jOANZOl9gEHdX7vQLlT7mrvnGFPyB 7CpQ==
X-Gm-Message-State: AODbwcDKYOq2Ocw/fppYmFoOOtwrdZN8joOcNL+HYiPDAjf3JdV5Co9G EWWQHT0U4mcI/CH/I4C3X0Wu9/mkvw==
X-Received: by 10.223.133.182 with SMTP id 51mr24797232wrt.86.1495722862114; Thu, 25 May 2017 07:34:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.86 with HTTP; Thu, 25 May 2017 07:34:21 -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: Alia Atlas <akatlas@gmail.com>
Date: Thu, 25 May 2017 10:34:21 -0400
Message-ID: <CAG4d1rdOjyApAmhS2oPcNRZ_o+11ALZO3pbUREsZEZq8A4Mnow@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Ben Campbell <ben@nostrum.com>, Eric Rescorla <ekr@rtfm.com>, Adam Roach <adam@nostrum.com>, "isis-wg@ietf.org" <isis-wg@ietf.org>, Alissa Cooper <alissa@cooperw.in>, "mjethanandani@gmail.com" <mjethanandani@gmail.com>, Suresh Krishnan <suresh.krishnan@gmail.com>, Mirja Kühlewind <ietf@kuehlewind.net>, "Benoit Claise (bclaise)" <bclaise@cisco.com>
Content-Type: multipart/alternative; boundary="001a11497f98e109b805505a1db7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/4eWq-eNYhyVDLSAWbJBvro1c-p0>
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:34:27 -0000

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) <
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
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>