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

[Kathleen Moriarty]

Hi Donald,

Thanks for your response, inline.

On Wed, Mar 14, 2018 at 4:52 PM, Donald Eastlake  wrote:
> Hi Kathleen,
>
> On Wed, Mar 14, 2018 at 2:28 PM, Kathleen Moriarty
>  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?

Yes, I think that would be helpful.  Thank you.
>
>> 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.


That's helpful, thanks for the proposed text.

Best regards,
Kathleen

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

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

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

[Donald Eastlake]

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.

   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 <
> kathleen.moriarty.i...@gmail.com> 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
>>
>
>
___
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)

[Andrew G. Malis]

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 <
kathleen.moriarty.i...@gmail.com> 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
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

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

[Kathleen Moriarty]

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