Re: [secdir] secdir review of draft-ietf-pwe3-ms-pw-arch-06

["BOCCI Matthew" <[e-mail]>]

Tom,

Many thanks for your review.

> -----Original Message-----
> From: Tom Yu [mailto:[e-mail]]
> Sent: 17 June 2009 04:53
> To: [e-mail]; [e-mail]; [e-mail]; BOCCI
> Matthew; [e-mail]
> Subject: secdir review of draft-ietf-pwe3-ms-pw-arch-06
> 
> Security-related comments:
> 
> My observations on the security-related content of this document focus
> on the ambiguity of the text in a few places.  I suspect that details
> resolving those ambiguities are available elsewhere, which would make
> the ambiguity only a minor problem, but I believe that this document
> should contain at least a summary of those details or a citation to
> where the reader can find those details.
> 
> In the Section 13, "Security Considerations", the sentence "However,
> S-PEs represent a point in the network where the PW label is exposed
> to additional processing." needs clear elaboration.  The PW label is
> not mentioned again in that section.  What are the risks associated
> with this additional processing?  Is a breach of the integrity or
> confidentiality of the pseudowire (PW) label a threat?  Or is the
> issue that a PW Switching Provider Edge (S-PE) may misdirect or
> otherwise tamper with a PW segment due to malice, malfunction, or
> misconfiguration?

It is exposed to the forwarding functionality in the S-PE, so it is at
least swapped by an S-PE and therefore associated with the context of
the downstream PW segment. The PW label is itself not confidential
because it is allocated by a downstream S-PE that does the label swap,
however an upstream S-PE must 'trust' that the downstream S-PE will
maintain that context correctly.

I suggest adding the following to address this:

"An S-PE or T-PE must trust that the context of the MS-PW is maintained
by a downstream S-PE. OAM tools must be able to verify the identity of
the far end T-PE to the satisfaction of the network operator."

> 
> As in RFC 5254 (referenced in this document), the word "trust" appears
> in multiple places in the Security Considerations sections without
> adequate specification, in my opinion.  There may be additional
> disambiguating context for the uses of the word "trust" in RFC 5254
> and this document that I am not familiar with.  The most reasonable
> interpretation that I can attach to words such as "trust" and
> "eligible" in the Security Considerations of these documents is that
> they refer to the policy of the operator of some network participating
> in the pseudowire.  Ambiguity remains concerning the specific entity
> whose policy applies in any given instance of those words, but I
> expect that I would find it more clear once I had more context.

I propose adding the following clarifications of the terms 'trust' and
'eligible':

An eligible S-PE or T-PE is one that meets the security and privacy
requirements of the MS-PW, according to the network operator's policy. 
A trusted S-PE or T-PE is therefore one that is understood to be
eligible by its next hop S-PE or T-PE, while a trust relationship exists
between two S-PEs or T-PEs if they mutually consider each other to be
eligible.
 
> 
> Editorial comments:
> 
> The references section does not distinguish between normative and
> informative references.  By the context of their citations, I infer
> that all of the cited references are normative.  If this is true, the
> subsection (or section) heading should reflect this fact.

We have split this into normative and informative references as per the
GenART review.

> 
> Section 11, "Congestion Considerations", includes an editor's note to
> reference draft-ietf-pwe3-congestion-frmwk-01.txt, which has expired.

I propose removing this editor's note and adding an informative
reference to the latest congestion framework draft, which has just been
uploaded.

> 
> Trailing whitespace occurs on many lines of this document.  While
> cosmetic in nature, it did complicate copying and pasting from this
> document.

I think this is a result of the draft being produced with the MS Word
template. I think Word pads the end of each line with white space when
we print to text file, which post-processing with the draft.pl script
does not remove.

Best regards

Matthew