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

[Kathleen Moriarty <[e-mail]>]

Hi Donald,

Thanks for your response, inline.

On Wed, Mar 14, 2018 at 4:52 PM, Donald Eastlake <[e-mail]> wrote:
> Hi Kathleen,
>
> On Wed, Mar 14, 2018 at 2:28 PM, Kathleen Moriarty
> <[e-mail]> wrote:
>> Hi Donald,
>>
>> Thanks for the proposed text.  Please see inline.
>>
>> On Mon, Mar 12, 2018 at 10:01 PM, Donald Eastlake <[e-mail]>
>> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>
>> Thanks,
>> Kathleen
>>
>>>
>>>    For general TRILL security considerations, see [RFC6325].
>>>
>>>
>>> Thanks,
>>> Donald
>>> ===============================
>>>  Donald E. Eastlake 3rd   [phone] (cell)
>>>  155 Beaver Street, Milford, MA 01757 USA
>>>  [e-mail]
>>>
>>> On Wed, Mar 7, 2018 at 5:35 PM, Andrew G. Malis <[e-mail]>
>>> 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
>>>> <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/trill
>>>>
>>>>
>>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen



-- 

Best regards,
Kathleen