Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)
RFC 5254

Note: This ballot was opened for revision 07 and is now closed.

(Sam Hartman) Discuss

Discuss (2008-03-06 for -)
Section 8.1:


The threat model for the environments described in this document seems
very similar to the Internet threat model.  So, I think BCP 61 applies
in full force.

What are the mandatory security services to provide for this threat
model?  It seems clear to me that isolation of one circuit's traffic
from another is clearly such a mandatory service.

Please provide an argument about what security is expected and about
how the expected data plane security guarantees are met by mandatory
to implement mechanisms.

Section 8.2

>   For a greater degree of security, an authentication mechanism that is
>   suitable to the associated protocol MUST be available. Furthermore
>   authentication using a signature for each individual MS-PW setup
>   messages MUST be available, in addition to an overall control
>   protocol session authentication , and message validation.


Why do you need signatures  of PWE3 setup messages?
If you're going down that road, I think you may need a lot more description of what security services you are trying to provide and what you are protecting against.

This document describes a significant new application and broadening
of the applicability of PWE3 As such it is necessary to make sure the
solution meets the latest IETF security requirements.  In particular,
take a look at RFC 4107 and perform that analysis.  I expect you to
find that MS-PWE3 protocols must provide mandatory to implement
automated key management.
If so, this needs to be stated as a requirement.



General:

the access metro environment seems to have significant security
requirements.  In particular there will be a lot more PE devices
involved.  It seems that isolation is important in this environment so
that the compromise of one of these devices does not lead to
compromise of other customer data from a completely unrelated PE.
Surely requirements relating to this need to be stated.
Comment (2007-05-23 for -)
No email
send info
I'd like to show strong support for Dan's comments.  I think that more
thought needs to be given to what management interfaces are required.
There are a lot of configuration settings especially in the static
cases.  For these to be easily managed, care needs to be given to
management requirements.

(Mark Townsley) Yes

(Jari Arkko) No Objection

Comment (2007-05-24 for -)
No email
send info
> domains that PSN Tunnel 1 and PSN Tunnel 2 traverse could beIGP areas

s/beIGP/be IGP/

(Ron Bonica) No Objection

(Ross Callon) No Objection

Lars Eggert (was Discuss) No Objection

(Pasi Eronen) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

(Tim Polk) No Objection

Comment (2007-05-23 for -)
No email
send info
For completeness, a statement that the data plane security considerations for SS-PWs
specified in RFC 3985 apply to MS-PWs should be included in this specification's security
considerations section.

(Dan Romascanu) (was Discuss) No Objection

Comment (2007-05-21)
No email
send info
1. Add ITU-T I.610 specification http://www.itu.int/rec/T-REC-I.610-199902-I/en as an informative reference

2. Section 7 of this document is using the expansion of the OAM acronyms as 'Operations and Maintenance' (OAM) as per the ITU-T documents. Unfortunately in the industry there are different ways of expanding these, and the IETF has also at least adopted two different ones (see RFC 4377 which in its title expands OAM as 'Operations and Management'). I would suggest that section 7 makes the usage of OAM in this document clear by adding a note that says: 

'Note that this document uses the term OAM as Operations and Management as per ITU-T I.610.'

(David Ward) No Objection

(Magnus Westerlund) No Objection

Comment (2007-05-24 for -)
No email
send info
I was very close to make this a discuss. But as my issue seems to be a result of an already existing requriement I don't see a need to block the document. 

In section 6.1.3 there is a strong requirment on congestion control and the possibility to signal information about its occurance to other segments. However for Section 6.3.4 there seem to me to be a lack of clarification what that implies for this type of MS-PWs. To me it seems that the static configured ones are the ones that will have most problems with the congestion control. This due to the issues of trying to move a PW when there are no altarnative paths, and the only course of action may be to shutdown or downgrade the capacity of the PW. I wished there was a bit more discussion on this issue and the requirement it introduces as I see it.