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

[Phillip Hallam-Baker <[e-mail]>]

Yes, that works for me.

On Wed, Nov 18, 2009 at 7:11 AM, Martin Vigoureux
<[e-mail]> wrote:
> 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.
>>
>



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