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

From: Alvaro Retana <[email-masked]>
Date: Tue, 10 Oct 2017 12:11:13 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-ccamp-ospf-availability-extension-10: No Objection

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-ccamp-ospf-availability-extension/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Please include draft file names in the references, not just abbreviations. 
That will make it easier to track the relationship and dependencies.  For
example, the draft uses the generalized format defined in
draft-ietf-teas-gmpls-scsi, but the name of that draft
(draft-ietf-teas-gmpls-scsi) doesn’t appear anywhere.  Also, the “References”
and “Referenced by” tools in the datatracker don’t seem to work properly — in
this case this document doesn’t appear to reference draft-ietf-teas-gmpls-scsi
at all [A].

[A]
https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/references/

(2) Section 3.2. (Processing Procedures): “This information MAY be used for
path calculation by the node(s).”  I think that the “MAY” is out of place
because this document already indicated that the use of the information is out
of scope: s/MAY/may

(3) Also from 3.2:

   The Availability SCSI-TLV MUST NOT be sent in ISCDs with Switching
   Capability field values that have not been defined to support the
   Availability SCSI-TLV. Non-supporting nodes would see such as a
   malformed ISCD/LSA.

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

(4) Section 4. (Security Considerations): “This document does not introduce
security issues beyond those discussed in [RFC4203]…the extensions specified
here have no direct effect on IP routing.”  But that is not true!  Even if out
of scope of this document, the intent has already been established that the
information can be used for route computation.  I think you should then expand
on the impact that tampering/changing the LSAs could have.

---

From: "Yemin (Amy)" <[email-masked]>
Date: Thu, 12 Oct 2017 02:48:33 +0000

Hi Alvaro,

Thanks for the review.

For the first two comments, we will address in the next version.

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.

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.

BR,

Amy

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]]
Sent: Wednesday, October 11, 2017 3:11 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Fatai Zhang <[email-masked]>; [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)

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

COMMENT:

That will make it easier to track the relationship and dependencies.  For example, the draft uses the generalized format defined in draft-ietf-teas-gmpls-scsi, but the name of that draft

and “Referenced by” tools in the datatracker don’t seem to work properly — in this case this document doesn’t appear to reference draft-ietf-teas-gmpls-scsi at all [A].

[A]

(2) Section 3.2. (Processing Procedures): “This information MAY be used for path calculation by the node(s).”  I think that the “MAY” is out of place because this document already indicated that the use of the information is out of scope: s/MAY/may

(3) Also from 3.2:

   malformed ISCD/LSA.

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

(4) Section 4. (Security Considerations): “This document does not introduce security issues beyond those discussed in [RFC4203]…the extensions specified here have no direct effect on IP routing.”  But that is not true!  Even if out of scope of this document, the intent has already been established that the information can be used for route computation.  I think you should then expand on the impact that tampering/changing the LSAs could have.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 12 Oct 2017 12:40:21 -0400

On Wed, Oct 11, 2017 at 10:48 PM, Yemin (Amy) <[email-masked]> wrote:

Amy:

Hi!

> 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.
>
Please add something like that, or point to the appropriate document.

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 13 Oct 2017 12:52:42 +0000

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://tools.ietf.org/html/rfc4203#ref-OSPF-TE>] suggests
   mechanisms such as [OSPF-SIG<https://tools.ietf.org/html/rfc4203#ref-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.

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://tools.ietf.org/html/rfc5920>] 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:[email-masked]]
Sent: giovedì 12 ottobre 2017 18:40
To: Yemin (Amy) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; Fatai Zhang <[email-masked]>; [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Amy:
Hi!

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.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 19 Oct 2017 09:28:16 +0000

Hi Alvaro,

just wondering if you had the chance to have a look at my proposal. Would this solve your issue?

Thanks,
Daniele

From: Daniele Ceccarelli
Sent: venerdì 13 ottobre 2017 14:53
To: 'Alvaro Retana' <[email-masked]>; Yemin (Amy) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; Fatai Zhang <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)

Hi Alvaro,

   and requirements.

Thanks
Daniele

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

Thanks!

Alvaro.