Re: [CCAMP] Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi,

I’ve been following this discussion, and as many aspects, I was not sure if the concern was about IP routing impacts, IP traffic routed on a GMPLS controlled transport network, or (multi-layer) computation impacts (TED).

As the authors note, this text has been used over and over. I think when they were GMPLS-authored, it was to clarify GMPLS opaque LSAs are used for GMPLS-control not (“normal/SPF”) IP-routing decisions.

Going forward, it may not be so clearly separated (e.g. multi-layer TED, SDN, whatever). I think this is Alvaro’s concern – the (computation) user impact? So the previous answer while true may not be the answer to the question which Alvaro is asking.

How about we remove the sentence on the impact to IP routing? And add specifically the computation impact (e.g. RFC3630 wording):
“This document specifies the contents of Opaque LSAs in OSPFv2. Tampering with GMPLS TE LSAs may have an effect on traffic engineering computations.  [OSPF-TE] suggests mechanisms such as [OSPF-SIG] to protect the transmission of this information, and those or other mechanisms should be used to secure and/or authenticate the information carried in the Opaque LSAs.”

Ok?
Deborah



From: iesg [mailto:[e-mail]] On Behalf Of Alvaro Retana
Sent: Tuesday, November 28, 2017 3:15 PM
To: Daniele Ceccarelli <[e-mail]>; Yemin (Amy) <[e-mail]>
Cc: [e-mail]; [e-mail]; Fatai Zhang <[e-mail]>; The IESG <[e-mail]>; [e-mail]
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)

Daniele/Amy:

Hi!  Sorry for the long delay.

In short — no, the proposed text doesn’t address my concern because I think that the extension being defined here can have an impact on routing.

Let me try and make my point (about the Security Considerations) again:

This document defines an extension that "can be used for route computation in a network that contains links with variable discrete bandwidth” — but "the use of the distributed information for route computation are [sic] outside the scope of this document”.  IOW, the intent of the extension is to provide information that can be used to calculate routes, even if the document doesn’t say how to figure out those routes.

The Security Considerations then says that "This document does not introduce security issues beyond those discussed in [RFC4203]…the extensions specified here have no direct effect on IP routing.”  If the extension can be used for route computation, how can it have no direct effect on routing?  Maybe we’re just talking about semantics from the point of view that OSPF is not using the extensions for IP routing (which is true), but someone will be!  From the point of view of someone using the extension to calculate routes, then tampering/changing the LSAs could have an impact on the routing decisions, right?

IOW, I think that (even if OSPF is not using the information itself) there’s a threat that can be realized from changing the contents of this extension that may result in inconsistent or incorrect routing.

Looking closer at rfc4203, the information there can clearly also be used for making routing decisions — again, not by OSPF but by the consumer of the information.  I can’t of course do anything wrt that text…

In summary, I can see the point that the extension doesn’t cause issues for OSPF…but I think the document is incomplete if it doesn’t address the potential risk to the consumer of the information.

In the end, these are non-blocking comments — I’ll defer to whatever you decide.

Thanks!

Alvaro.


On October 13, 2017 at 8:52:45 AM, Daniele Ceccarelli ([e-mail]<mailto:[e-mail]>) wrote:
Hi Alvaro,

thanks a lot for your review, the text is being improved significantly.
I just wanted to add a comment to the discussion on the security section. The text Amy is proposing is exactly the one you can find in RFC4203:

   This document specifies the contents of Opaque LSAs in OSPFv2.  As
   Opaque LSAs are not used for SPF computation or normal routing, the
   extensions specified here have no direct effect on IP routing.
   Tampering with GMPLS TE LSAs may have an effect on the underlying
   transport (optical and/or SONET-SDH) network.  [OSPF-TE<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4203-23ref-2DOSPF-2DTE&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=5_Z-kEXVIiiwdIClSEqWVu4ZJeBrN8G31Hr9gX-epiY&s=4800_ytNzwILzJb3et85wgOtdPOTzm0yCbl9yZl-DyQ&e=>] suggests
   mechanisms such as [OSPF-SIG<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4203-23ref-2DOSPF-2DSIG&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=5_Z-kEXVIiiwdIClSEqWVu4ZJeBrN8G31Hr9gX-epiY&s=hNtWEwh7IAyTvrWImp4G_2AyyWGt6yvE7ahmB5MCtLE&e=>] to protect the transmission of this
   information, and those or other mechanisms should be used to secure
   and/or authenticate the information carried in the Opaque LSAs.

I might agree or disagree with your concern (actually tend to agree), but this is not an issue we can solve in this draft, since it is inherited by a previous RFC.
This draft is only defining a new sub-TLV inside the ISCD tlv, like many other existing RFCs. We have the same reference in many existing RFC, like for example RFC7138.

What RFC 7138 adds is a reference to RFC5920 that could work also in our case:


   Please refer to [RFC5920<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5920&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=5_Z-kEXVIiiwdIClSEqWVu4ZJeBrN8G31Hr9gX-epiY&s=YAVnSItSKY0WtdbyE6wpf-IRtecHLUUVgTHxQWCFaXg&e=>] for details on security threats; defensive

   techniques; monitoring, detection, and reporting of security attacks;

   and requirements.

Would this solve the issue?

Thanks
Daniele



From: Alvaro Retana [mailto:[e-mail]<mailto:[e-mail]>]
Sent: giovedì 12 ottobre 2017 18:40
To: Yemin (Amy) <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Fatai Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)

On Wed, Oct 11, 2017 at 10:48 PM, Yemin (Amy) <[e-mail]<mailto:[e-mail]>> wrote:
Amy:
Hi!

3) Where is this signaling defined?  How does a node know that others support the Availability ISCD/LSA?



The Interface Switching Capability Descriptor (ISCD) allows routing protocols such as OSPF and ISIS to carry technology specific information in the Switching Capability-specific information (SCSI) field.

If a node received the Availability in the ISCD, it knows that the sender support Availability.
Please add something like that, or point to the appropriate document.


 4) Security Considerations, how about change the text as following:



This document extends [RFC4203].  As with [RFC4203], it specifies the content of an Opaque LSAs in OSPFv2. As Opaque LSAs are not used for Shortest Path First (SPF) computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with GMPLS TE LSAs may have an impact on the ability to set up connections in the underlying data plane network. Mechanisms such as [RFC2154] and [RFC5304] to protect the transmission of this information are suggested. As the additional availability information may represent information that an operator may wish to keep private, consideration should be given to securing this information. [RFC3630] notes that the security mechanisms described in [RFC2328] apply to Opaque LSAs carried in OSPFv2. An analysis of the security of OSPF is provided in [RFC6863] and applies to the extensions to OSPF as described in this document. Any new mechanisms developed to protect the transmission of information carried in Opaque LSAs will also automatically protect the extensions defined in this document.

The text above (1) still says that the extensions have no direct effect on IP routing, and (2) don't address that threat.  I think that the threat with tampering may not just impact the ability to set up a connection, but it may cause routing not to be correct: use a congested path or follow a path with not enough bw, etc..  It shouldn't result in 100% lost traffic, but the routing could definitely be suboptimal.

Thanks!

Alvaro.