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

[Eric Rescorla <[e-mail]>]

I agree with Kathleen here that it would be good to explain why this
document
doesn't introduce new security issues. The document, not this discussion,
serves as the archival record, and so should be sufficient to convince the
reader of this point.

-Ekr


On Thu, May 25, 2017 at 9:39 AM, 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.
> 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]."
>
> 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
>