Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Donald Eastlake]

Hi Alvaro,

A -07 version of draft-ietf-trill-multilevel-unique-nickname has been
posted with the intent of resolving your comment as per my response
below.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Tue, Mar 13, 2018 at 11:50 AM, Donald Eastlake  wrote:
> Hi Alvaro,
>
> On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana  wrote:
>> Alvaro Retana has entered the following ballot position for
>> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
>>
>> ...
>>
>> --
>> COMMENT:
>> --
>>
>> (1) The nickname selection process for multilevel is not backwards compatible
>> because of the use of the NickBlockFlags APPsub-TLV.  That is ok since the
>> border RBridges can recognize "old" Rbridges (ones that don't support this
>> specification) in an area. A couple of related comments:
>>
>> (1.1) Section 4.4. (Capability Indication) says that "Non border RBridges in 
>> an
>> area SHOULD understand the NickBlockFlags APPsub-TLV."  That statement is
>> somewhat contradictory (maybe that's not the right word, but the only one 
>> that
>> comes to mind):
>>
>> - On one hand, non border RBridges could be just be "old" (ones that don't
>> support this specification).  We can't normatively specify something that by
>> definition nodes that don't support this specification won't know about.
>>
>> - On the other hand, if the non border Rbridge does support this 
>> specficiation,
>> then why wouldn't it understand the NickBlockFlags APPsub-TLV?  IOW, why 
>> isn't
>> the "SHOULD" a "MUST" instead?  When is it ok to not do it?
>>
>> All this is to say that I think that "SHOULD" should not be used normatively.
>> s/SHOULD/should
>
> Sounds reasonable to me.
>
>> (1.2) Given that rfc6325 specifies a single Level 1 network, it is reasonable
>> to expect that networks implementing these multilevel extensions will grow 
>> from
>> a single area to multiple.  It would be ideal to include Deployment
>> Considerations to discuss what a Migration Path would look like.
>>
>> (2) Maybe I missed it somewhere...  The Security Considerations section says
>> that "border RBridges need to fabricate the nickname 
>> announcements...Malicious
>> devices may also fake the NickBlockFlags APPsub-TLV to announce a range of
>> nicknames."  I'm sure that malicious devices don't only include ones that are
>> unauthenticated, but may include over or under claiming by existing border
>> RBridges or even non border RBridges originating the NickBlockFlags 
>> APPsub-TLV.
>>
>> (2.1) Is the origination of the NickBlockFlags APPsub-TLV restricted to 
>> border
>> RBridges?  If so, why isn't there a check to make sure that the 
>> NickBlockFlags
>> APPsub-TLV came from a border RBridge?
>
> Such a check would add some complexity and it is not clear there would
> be much gain as an RBridge that is forging NickBlockFlags APPsub-TLVs
> would presumably just falsely claim it is a border RBridge by claiming
> ownership of at least one Level 2 nickname.
>
>> (2.2) rfc8243 talks about the (potential) ability of border RBridges to
>> "discover each other...by using the IS-IS "attached bit" [IS-IS] or by
>> explicitly advertising in their LSP "I am a border RBridge".  But I didn't 
>> see
>> these options/mechanisms mentioned in this document.
>
> Border RBridges know they are border RBridges because, by
> configuration, they are talking to both Level 1 and 2. They act
> specially but it is not clear what good looking at the attached bit or
> border RBridges advertising that explicitly in the LSP would do. If
> you are in Level 2 and see some Level 2 RBridge advertising that it
> owns Level 1 nicknames, you know it is a border RBridge and likewise,
> if you are in Level 1 and see some Level 1 RBridge advetising that it
> owns Level 2 nicknames, you know it is a border RBridge. And the
> nicknames are distinguished by being taken from mutually exclusive
> ranges of nicknames.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Donald Eastlake]

Hi Eric,

A -07 version of draft-ietf-trill-multilevel-unique-nickname has been
posted with the intent of resolving your comment.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Mon, Mar 12, 2018 at 11:49 PM, Donald Eastlake  wrote:
> Hi Eric,
>
> On Thu, Mar 8, 2018 at 9:27 AM, Eric Rescorla  wrote:
>>
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
>>
>> ...
>>
>> --
>> COMMENT:
>> --
>>
>> In the security considerations,  isn't the requirement not that you configure
>> IS-IS authentication but that you actually have to require it on receipt? Or
>> are these the same things.
>
> I must admit that the current wording just talks about inclusion of
> authentication TLVs in a way which seems to leave out checking them
> :-)
>
> The wording should be improved.
>
>> Even with ordinary trill, can't you just spoof a lot of announcements with
>> other people's nicknames? Why is this different?
>
> Well, it is a bit more complex with IS-IS. It depends on just what you
> try to spoof. If you spoof an announcement from some existing RBridge,
> as soon as it is flooded to the claimed source RBridge that RBridge
> will issue an overwritting announcement or purge. But, unless you turn
> on appropriate security, there are ways to spoof announcements that
> would have bad effects.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

Re: [trill] Kathleen Moriarty's Discuss on draft-ietf-trill-transport-over-mpls-07: (with DISCUSS)

[Donald Eastlake]

Hi Kathleen,

On Wed, Mar 14, 2018 at 2:28 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:
> Hi Donald,
>
> Thanks for the proposed text.  Please see inline.
>
> On Mon, Mar 12, 2018 at 10:01 PM, Donald Eastlake 
wrote:
>> Hi Kathleen,
>>
>> Would the following replacement Security Considerations section for
>> draft-ietf-trill-transport-over-mpls be adequate?
>>
>>
>>This document specifies methods using existing standards and
>>facilities in ways that do not create new security problems.
>>
>>For general VPLS security considerations, including discussion of
>>isolating customers from each other, see [RFC4761] and [RFC4762].
>>
>>For transport of TRILL by Pseudowires security consideration, see
>>[RFC7173]. In particular, since pseudowires are support by MPLS or IP
>>which are in turn supported by a link layer, that document recommends
>>using IP security or the lower link layer security.
>>
>>For added security against the compromise of data end-to-end
>>encryption and authentication should be considered; that is,
>>encryption and authentication from source end station to destination
>>end station.
>
> Would this be accomplished through IPsec?

For end-to-end security, it could be. Or DTLS. Whatever is convenient for
the information you want to protect. Since end stations are connected to
edge TRILL switches via Ethernet, if you wanted to protect all of the data
between two end stations, you could use IEEE Std 802.1AE. Do you want a
list added?

> If encryption and authentication are not employed, what are the risks
> to tenant isolation since this draft joins TRILL campuses?

I wouldn't say that the draft "joins TRILL campuses". If a TRILL campus is
actually structured so that the connectivity being provided is connecting
two islands, then you could say it is making those TRILL switches parts of
the same campus. The term "campus" in TRILL is not intended to have any
geographic (or academic) implication but rather, to be for TRILL switches
the same as the term "bridged LAN" is for IEEE 802.1 bridges.

Whenever a link extends outside local physical control, there is increased
risk. Assuming a link between two TRILL switch ports in a TRILL campus is
Ethernet, it could be anything from a little copper on a backplane inside a
cabinet to Ethernet connectivity purchased from a carrier and extending
hundreds of miles.

If you are talking about the risk of a TRILL campus merging with a
malicious TRILL switch, that can be avoided by IS-IS PDU authentication.
Until adjacency is establish (RFC 7177), which requires successful exchange
of IS-IS Hellos PDUs, no data will flow.

> I think
> there should be text that explains this risk in addition to the text
> already proposed.

How about adding text like the following:


Transmission outside the customer environment through the provider
environment, as described in this document, increases risk of compromise or
injection of false data through failure of tenant isolation or by the
provider. In the VPLS model (Section 3), the use of link encryption and
authentication between the CEs of a tenant that is being connected through
provider facilities should be a good defense. In the VPTS model (Section
4), it is assumed that the CEs will peer with virtual TRILL switches of the
provider network and thus link security between TRILL switch ports is
inadequate as it will terminate at the edge PE. Thus, end station to end
station encryption and authentication is more appropriate for the VPTS
model.


Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Thanks,
> Kathleen
>
>>
>>For general TRILL security considerations, see [RFC6325].
>>
>>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  d3e...@gmail.com
>>
>> On Wed, Mar 7, 2018 at 5:35 PM, Andrew G. Malis 
wrote:
>>>
>>> Kathleen,
>>>
>>> I don’t want to speak for the authors. However, I did contribute to this
>>> draft (although not this specific section). So that said, here’s my two
>>> cents ….
>>>
>>> I agree that first sentence could have been worded better, but the
bottom
>>> line is that depending on the model used, the security considerations
for
>>> RFC 7173, 4761, or 4762 applies, including the discussions in those
RFCs on
>>> issues such as isolation and end-to-end security. Those RFCs are
referenced
>>> in the security section. So the substance is already there, perhaps the
>>> draft just needs better pointers to it.
>>>
>>> Cheers,
>>> Andy
>>>
>>>
>>> On Wed, Mar 7, 2018 at 5:01 PM, Kathleen Moriarty
>>>  wrote:

 Kathleen Moriarty has entered the following ballot position for
 draft-ietf-trill-transport-over-mpls-07: Discuss

 When responding, 

Re: [trill] Kathleen Moriarty's Discuss on draft-ietf-trill-transport-over-mpls-07: (with DISCUSS)

[Kathleen Moriarty]

Hi Donald,

Thanks for the proposed text.  Please see inline.

On Mon, Mar 12, 2018 at 10:01 PM, Donald Eastlake  wrote:
> Hi Kathleen,
>
> Would the following replacement Security Considerations section for
> draft-ietf-trill-transport-over-mpls be adequate?
>
>
>This document specifies methods using existing standards and
>facilities in ways that do not create new security problems.
>
>For general VPLS security considerations, including discussion of
>isolating customers from each other, see [RFC4761] and [RFC4762].
>
>For transport of TRILL by Pseudowires security consideration, see
>[RFC7173]. In particular, since pseudowires are support by MPLS or IP
>which are in turn supported by a link layer, that document recommends
>using IP security or the lower link layer security.
>
>For added security against the compromise of data end-to-end
>encryption and authentication should be considered; that is,
>encryption and authentication from source end station to destination
>end station.

Would this be accomplished through IPsec?
If encryption and authentication are not employed, what are the risks
to tenant isolation since this draft joins TRILL campuses?  I think
there should be text that explains this risk in addition to the text
already proposed.

Thanks,
Kathleen

>
>For general TRILL security considerations, see [RFC6325].
>
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
> On Wed, Mar 7, 2018 at 5:35 PM, Andrew G. Malis  wrote:
>>
>> Kathleen,
>>
>> I don’t want to speak for the authors. However, I did contribute to this
>> draft (although not this specific section). So that said, here’s my two
>> cents ….
>>
>> I agree that first sentence could have been worded better, but the bottom
>> line is that depending on the model used, the security considerations for
>> RFC 7173, 4761, or 4762 applies, including the discussions in those RFCs on
>> issues such as isolation and end-to-end security. Those RFCs are referenced
>> in the security section. So the substance is already there, perhaps the
>> draft just needs better pointers to it.
>>
>> Cheers,
>> Andy
>>
>>
>> On Wed, Mar 7, 2018 at 5:01 PM, Kathleen Moriarty
>>  wrote:
>>>
>>> Kathleen Moriarty has entered the following ballot position for
>>> draft-ietf-trill-transport-over-mpls-07: Discuss
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-trill-transport-over-mpls/
>>>
>>>
>>>
>>> --
>>> DISCUSS:
>>> --
>>>
>>> I was very surprised to see the following in the security considerations
>>> section and would like to work with you on improvements.
>>>As an informational document specifying methods that use only
>>>existing standards and facilities, this document has no effect on
>>>security.
>>>
>>> Having watched many TRILL documents go by in the last 4 years, we didn't
>>> push
>>> too hard on security in some cases as a result of the restriction to a
>>> campus
>>> network.  This particular document extends into multi-tenancy where there
>>> are
>>> certainly security considerations introduced to be able to provide
>>> isolation
>>> properties.  MPLS offers no security and it is being used to join TRILL
>>> campuses as described int his draft.  This is done without any
>>> requirement of
>>> an overlay protocol to provide security - why is that the case?
>>> Minimally, the
>>> considerations need to be explained.  Ideally, a solution should be
>>> offered to
>>> protect tenants when TRILL campuses are joined.
>>>
>>>
>>>
>>>
>>> ___
>>> trill mailing list
>>> trill@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trill
>>
>>
>



-- 

Best regards,
Kathleen

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] I-D Action: draft-ietf-trill-multilevel-unique-nickname-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transparent Interconnection of Lots of Links 
WG of the IETF.

Title   : TRILL Multilevel Using Unique Nicknames
Authors : Mingui Zhang
  Donald E. Eastlake 3rd
  Radia Perlman
  Hongjun Zhai
  Dongxin Liu
Filename: draft-ietf-trill-multilevel-unique-nickname-07.txt
Pages   : 15
Date: 2018-03-14

Abstract:
   TRILL routing can be extended to support multiple levels by building
   on the multilevel feature of IS-IS routing. Depending on how
   nicknames are managed, there are two primary alternatives to realize
   TRILL multilevel: the unique nickname approach and the aggregated
   nickname approach as discussed in RFC 8243. This document specifies a
   unique nickname approach. This approach gives unique nicknames to all
   TRILL switches across the multilevel TRILL campus.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-trill-multilevel-unique-nickname-07
https://datatracker.ietf.org/doc/html/draft-ietf-trill-multilevel-unique-nickname-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-multilevel-unique-nickname-07


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/

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill