Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-tp-oam-requirements-03

From: Martin Vigoureux <[email-masked]>
Date: Wed, 18 Nov 2009 13:11:02 +0100

Dear Phillip,

thanks for your review.
Would the following rephrasing (of the Security Considerations)
satisfy your expectations?
For your information, Tim Polk had a similar type of comment
as part of IESG Review and is ok with the text proposed below.
Thanks

martin

OLD
   In general, mechanisms SHOULD be provided to ensure that OAM
   functions cannot be accessed unauthorized.

   Further, OAM messages MAY be authenticated to prove their origin and
   to make sure that they are destined for the receiving node.

   An OAM packet received over a PW, LSP or Section MUST NOT be
   forwarded beyond the End Point of that PW, LSP or Section, so as to
   avoid that the OAM packet leaves the current administrative domain.
NEW
   OAM systems (network management stations) SHOULD be designed such
   that OAM functions cannot be accessed without authorization.

   OAM protocol solutions MUST include the facility for OAM messages to
   authenticated to prove their origin and to make sure that they are
   destined for the receiving node. The use of such facilities MUST be
   configurable.

   An OAM packet received over a PW, LSP or Section MUST NOT be
   forwarded beyond the End Point of that PW, LSP or Section, so as to
   avoid that the OAM packet leaves the current administrative domain.

Phillip Hallam-Baker a écrit :
> I am reviewing this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments. Feel free to
> forward to any appropriate forum.
> 
> 
> This documents sets out requirements for Operations, Administration
> and Maintenance of MPLS Transport Profile.
> 
> It is a high level architectural requirements document, intentionally
> separated from the details of specific implementations. As such it is
> appropriate for the security considerations section to be at a high
> level.
> 
> It is however a mystery to this reader why encryption is specified as
> a should but integrity protections only merit a MAY. I would be much
> more reassured by a document that ignores confidentiality issues
> completely (as has been the general policy for low level routing &ct.)
> and points out the fact that this is yet another opportunity for a
> malicious party to play merry heck by introducing bogus data that
> other parts of the network will then operate on.
> 
> For example, introduction of bogus messages would allow an attacker to
> reserve excessive bandwidth in the name of another party, possibly
> performing a DoS attack or possibly to perform a financial fraud,
> causing some party to incur costs for bandwidth not required.
> 
> In comparison the confidentiality issues are rather minor, and in any
> event almost certainly subsumed by the fact that anyone who can
> observe the content of the OAM packets can almost certainly observe
> the volumes of the data flows and infer that information. While
> confidentiality is a nice to have, it is not worth much without
> integrity.
> 
> I suggest that the security considerations section makes the ability
> to support integrity protections a MUST or SHOULD requirement. If only
> a SHOULD is applied, confidentiality would be better demoted to MAY.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 21 Nov 2009 11:24:30 -0500

Yes, that works for me.

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/