[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ipsec] Proposed Last Call based revisions to IKEv2



At 10:50 PM -0700 5/15/04, Charlie Kaufman wrote:
>Issue #96, 98

Charlie has proposed changes to align with the fragmentation 
description in rfc2401bis. I have a different proposition, one that I 
think the WG may like even better than the one Charlie gave while 
still achieving the same goal of giving rfc2401bis what it needs.

One of the huge problems with IKEv1/2401 is that the specification 
for how to do things is spread among multiple RFCs. We have cleaned 
that up to a huge extent in IKEv2/2401bis. However, what Charlie 
suggests here creates the split again; I think we can nip that in the 
bud.

What I propose is that Charlie only change the following in IKEv2:

- In 3.10, add an entry under status-type notify messages:

    NON-FIRST-FRAGMENTS-ALSO                  16395

    Used for fragmentation control. See [RFC2401bis] for explanation.

- In 3.13.1, eliminate "or port is OPAQUE" in both Start Port and End 
Port descriptions.

- In 3.13.1, just before the text paragraph that starts "The 
following table lists...", add the following paragraph.

    Systems that are complying with [RFC2401bis] that wish to indicate
    "ANY" ports MUST set the start port to 0 and the end port to 65535;
    note that according to [RFC2401bis], "ANY" includes "OPAQUE". Systems
    working with [RFC2401bis] that wish to indicate "OPAQUE" ports, but
    not "ANY" ports, MUST set the start port to 65535 and the end port
    to 0.

This way, the IKEv2 document is not specifying any semantics for 
fragmentation handling, and there is no possibility of disagreement 
with 2401bis. It also separates out the semantics of OPAQUE and ANY 
in a way to make it clear that these are 2401bis constructs, not 
IKEv2 constructs.

One concern with using Charlie's text is that it would likely cause 
the need for another WG Last Call and another IETF Last Call. I 
believe the above changes could avoid that because the revisions do 
not specify any new semantics. (Russ, does that sound correct to you?)

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec