Re: [CCAMP] Stephen Farrell's No Objection on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with COMMENT)

[Leeyoung <[e-mail]>]

Hi Stephen,

Thanks for your comment. I replied to a similar question from Ben Campbell on security. Please see in the attachment if you have not had chance to read this email thread. The rationale for the sufficiency with [RFC4203] and [RFC3630] was suggested by the following text (which we can add if you like):

   As with [RFC4203], it specifies the
   contents of 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 effect on the underlying
   Transport.  [RFC3630] notes that the
   security mechanisms described in [RFC2328] apply to Opaque LSAs
   carried in OSPFv2.

What do you think? Would this answer your question? 

Thanks.
Young


-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]] 
Sent: Wednesday, August 05, 2015 6:49 AM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Stephen Farrell's No Objection on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-ccamp-wson-signal-compatibility-ospf-15: 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-wson-signal-compatibility-ospf/



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


I have two (non-blocking) questions...

I always get worried when the security considerations
says "nothing to see here, move on, but if you must, do
feel free to look at <other-rfcs>." That is sometimes a
signal that nobody bothered to think about security, but
only thought about how to try keep the security ADs
quiet:-) Can you re-assure me that in this case, you did
think about security?

Is there any interesting new way in which abuse of these
TLVs (either via direct insertion or else by causing
them to be sort-of controlled by sending other traffic)
can be used to control how traffic flows in a network so
that the attacker can better control or predict through
which nodes (or at which wavelengths) some traffic of
interest (to the attacker) will flow? I'd say that the
answer is probably not, but did you consider it?

--- Begin Message ---

Hi Ben,

Thanks for providing your good comments and idnits check.

Please see inline for my response.

Best regards,
Young

-----Original Message-----
From: Ben Campbell [mailto:[e-mail]]
Sent: Monday, August 03, 2015 5:44 PM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Ben Campbell's No Objection on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-ccamp-wson-signal-compatibility-ospf-15: 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-wson-signal-compatibility-ospf/



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

Section 5 (security considerations) says: "This document does not
introduce any further security issues other
   than those discussed in [RFC3630], [RFC4203]."

While I don’t doubt the statement is true, it would be helpful to show
the thought behind it. In this case, the draft adds new data elements to
the OSPF TE LSA. Please consider adding a very short discussion on how
the security implications of those elements is similar to or different
from the previously existing data elements.


YOUNG>>

   As with [RFC4203], it specifies the
   contents of 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 effect on the underlying
   Transport.  [RFC3630] notes that the
   security mechanisms described in [RFC2328] apply to Opaque LSAs
   carried in OSPFv2.

   If you like, I can add these text in Section 5. Please let me know.


Nits:

Please expand TE and LSA on first mention.

YOUNG>> Yes, TE (Traffic Engineering) and LSA (Link State Advertisement) will be expanded on first mention.



idnits thinks the reference to [G.694.1] is not cited in the body. Is the
reference needed?

YOUNG>> The reference will be removed.

--- End Message ---