Subject: [Fwd: IESG review of pwe3 architecture document]

From: Stewart Bryant <[email-masked]>
Date: Mon, 15 Dec 2003 16:27:41 +0000

One round of comments from the IESG

Stewart

-------- Original Message --------
Subject: IESG review of pwe3 architecture document
Date: Tue, 9 Dec 2003 18:55:59 -0600
From: Peterson, Jon <[email-masked]>
To: [email-masked]' <[email-masked]>,        'Stewart Bryant'	 <[email-masked]>

The comments below are preliminary - Bert Wijnen has asked for a little more
time to let the MIB doctors look over the draft. I wanted to get these back
to you now, though, to get any necessary dialog started.

<IANA>

I saw your response, Stewart, on the question from IANA. I'm not sure that
overloading existing values of the IP version numbers in:

http://www.iana.org/assignments/version-numbers

is really going to fly. Was this really the only way that packets could be
marked? That isn't a registry that we really change very often... it would
strike people as very odd that an architecture document wanted to muck
around with IP versioning.

Another comment that came up verbally on the telechat was the general
question of how much protocol work has been done in the architecture
document - it's unusual for us to see bit fields and so on in an
Informational RFC (it makes the status of these fields as a normative
reference for a Proposed Standard suspect). So just FYI, any more detailed
protocol specification that goes through PWE3 as a Proposed Standard would
probably have to replicate the field specifications in pwe3-arch - it
couldn't just be referenced.

<Russ>

    Section 10, 4th paragraph says:

       IPSec MAY provide authentication, integrity, non-repudiation, and
       confidentiality of data transferred between two PEs. It cannot
       provide the equivalent services to the native service.

    IPsec does not, and cannot, provide non-repudiation.  IPsec can be used
    to provide integrity, authentication, confidentiality, and access
    control.

    Once this correction is made, I am concerned that the IPsec-related
    access controls will be confused with the access controls being
    discussed in the last paragraph of section 10.  I belive some
    clarifying language is needed.

<Steve>

I was a bit surprised to see the pwe3 architecture document handle TDM,
when we did not see the TDM requirements document.

Nit: 5.4.4: bits 4-11 MUST be ignored by the receiver

10: IPsec does not provide non-repudiation.  A better definition of how
to use IPsec will be necessary in the protocol document; I strongly
suspect that they will *not* find it easy.  This is mostly a heads-up
to the WG to start thinking about it now, and to read
draft-bellovin-useipsec-02.txt (which I've requested publication on as
a BCP).  Perhaps they should consider the RTP security mechanisms,
given that they're apparently leaning towards RTP in any event?

- J