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

[Alvaro Retana <[e-mail]>]

Hi!

This works for me.

Thanks!

Alvaro.

On November 28, 2017 at 6:13:15 PM, BRUNGARD, DEBORAH A ([e-mail])
wrote:

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]) 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]]
*Sent:* giovedì 12 ottobre 2017 18:40
*To:* Yemin (Amy) <[e-mail]>
*Cc:* The IESG <[e-mail]>;
[e-mail]; Fatai Zhang <
[e-mail]>; [e-mail]; [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]> 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.