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

From: [email-masked]
Date: Wed, 24 May 2017 17:44:58 -0700

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/

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 25 May 2017 01:16:45 +0000

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.

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.

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:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Wednesday, May 24, 2017 5:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Isis-wg] I-D Action: draft-ietf-isis-l2bundles-06.txt
> 
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 24 May 2017 21:29:02 -0400

Hi Les,

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

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

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 25 May 2017 01:39:21 +0000

Kathleen -

> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2017 6:29 PM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]; Mirja Kühlewind; Adam Roach; Eric Rescorla; Suresh
> Krishnan; Benoit Claise (bclaise); [email-masked]; Alissa Cooper;
> Alvaro Retana (aretana); Ben Campbell
> Subject: Re: [Isis-wg] I-D Action: draft-ietf-isis-l2bundles-06.txt
> 
> Hi Les,
> 
> > Here are some responses to some of the points raised by reviewers (all
> reviewers have been copied on this email I hope).
> >
> >    Protocol documents do not define how link state info is passed to
> > BGP-LS - we write separate BGP-LS drafts for that
> >
> 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).
> 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.
> >
> > 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
> >
> >> From: Isis-wg [mailto:[email-masked]] On Behalf Of
> >> internet- [email-masked]
> >> 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.
> >>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 May 2017 09:48:42 +0800

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) <[email-masked]
> wrote:

> > >     " 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
> > > Link IDs for the L2 Links which are advertised are readily available
> today via
> > network management tools.
> >
> [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.
> > > This statement is true, but I fail to see how this is relevant to the
> progress
> > of this IS-IS draft.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 24 May 2017 22:35:14 -0400

Hi Les,

> [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).

>    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

-- 

Best regards,
Kathleen

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 25 May 2017 04:53:56 +0000

Kathleen -

> Sent: Wednesday, May 24, 2017 7:35 PM
> >> Cc: [email-masked]; Mirja Kühlewind; Adam Roach; Eric Rescorla;
> >> Suresh Krishnan; Benoit Claise (bclaise); [email-masked];
> >> Alissa Cooper; Alvaro Retana (aretana); Ben Campbell
> >> > under "TLV for Adjacency #2" is wrong. It says 29 but it needs to
> >> > be
> >> > 32
> >> >
> >> >     " 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
> >> >    Protocol documents do not define how link state info is passed
> >> > to BGP-LS - we write separate BGP-LS drafts for that
> >> >
> >> considerations section.  I do see that path exposure is covered by
> >> the security considerations in other is-is documents.
> >>
> >> >
> >> > I disagree.
> >> >
> >> > Link IDs for the L2 Links which are advertised are readily
> >> > available today via
> 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

> 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
> >> > This statement is true, but I fail to see how this is relevant to
> >> > the progress
> >> of this IS-IS draft.
> >> 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.
> >> >
> >> 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.
> >> >

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 25 May 2017 07:39:24 -0400

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) <[email-masked]> wrote:
> 
> Kathleen -
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 25 May 2017 13:29:03 +0000

Les:

Hi!

That works for me.

Thanks!

Alvaro.

On 5/24/17, 10:16 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

4)Alvaro commented: 

I have added explicit text indicating this is out of scope.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 May 2017 22:17:53 +0800

This is fine with me. I'm happy to remove my discuss in favor of Kathleen
if she would like to take it from here?

-Ekr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 25 May 2017 14:24:52 +0000

Kathleen -

Thanx for your assistance - https://www.ietf.org/internet-drafts/draft-ietf-isis-l2bundles-07.txt has been posted.

    Les

> Sent: Thursday, May 25, 2017 4:39 AM
> 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
> 
> >>>>> This revision addresses a number of review comments received
> >>>>> during
> >>>> IESG review.
> >>>>>
> >>>> 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
> >>>> being advertised by IS-IS via existing TE extensions (e.g. RFC
> >>>> 5305, RFC
> >> 4205).
> >> 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
> > [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.
> >
> > 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
> >
> >
> >
> >> drafts that use these references provide an explanation as to why
> >> they are included as references.
> >>
> >>>> either protocol. However we have never linked the progress of the
> >>>> two documents together - it is often the case that one document is
> >>>>>> A New Internet-Draft is available from the on-line
> >>>>>> Internet-Drafts
> >>>> directories.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 25 May 2017 10:25:57 -0400

Thank you!

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

Kathleen

-- 

Best regards,
Kathleen

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 May 2017 10:34:21 -0400

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) <
[email-masked]> wrote:

> Kathleen -
>
> Thanx for your assistance - https://www.ietf.org/internet-
> drafts/draft-ietf-isis-l2bundles-07.txt has been posted.
>
>     Les
>
>