Subject: Working Group Last Call IKEv2

From: Barbara Fraser <[email-masked]>
Date: Tue, 03 Jun 2003 10:32:01 -0700

Hi,

This is a working group last call for comments on the IKEv2 draft, 
draft-ietf-ipsec-ikev2-08.txt, for progression to Proposed Standard:

This last call will expire in three weeks on June 23, 2003.

thanks,
Barb and Ted

---

From: Abraham Shacham <[email-masked]>
Date: Sun, 08 Jun 2003 14:40:04 -0700

Attached please find the IPComp editorial comments for IKEv2,
including in RFC editor format.

Regards,
avram

[email-masked]
[email-masked]

(*) Footnote to the bored reader of this repeated message: The I-D
is in wg last call, so at the most a single repeat is due --
during ietf last call ;-<

> -------- Original Message --------
> Subject: IKEv2-05: IPComp (editorial) comments
> Date: Mon, 03 Mar 2003 00:21:59 -0800
> From: Abraham Shacham <[email-masked]>
> To: IP Security List <[email-masked]>
> CC: ippcp <[email-masked]>
> 
> 
> s/IPcomp/IPComp/
> s/RFC 2393/RFC 3173/
> 
> In page 54:
> 
>   The Transform IDs currently defined are:
>      Name                     Number       Defined In
>      RESERVED                   0
>      IPCOMP_OUI                 1
>      IPCOMP_DEFLATE             2          (RFC2394)
>      IPCOMP_LZS                 3          (RFC2395)
> 
> Following RFC-3051, add:
> 
>      IPCOMP_LZJH                4          (RFC3051)
> 
> 
 >
 > Thanks,
 > avram
 >

=== the above comments in RFC editor format ===

page 2:

Old:

    2.22 IPcomp.................................................34

New:

    2.22 IPComp.................................................34

page 4:

Old:

    match fashion.  IKE can also negotiate use of IPcomp [RFC2393] in
    connection with an ESP and/or AH SA.  We call the IKE SA an "IKE_SA".

New:

    match fashion.  IKE can also negotiate use of IPComp [RFC3173] in
    connection with an ESP and/or AH SA.  We call the IKE SA an "IKE_SA".

page 11:

Old:

    SAs are nested, as when data (and IP headers if in tunnel mode) are
    encapsulated first with IPcomp, then with ESP, and finally with AH
    between the same pair of endpoints, all of the SAs MUST be deleted

New:

    SAs are nested, as when data (and IP headers if in tunnel mode) are
    encapsulated first with IPComp, then with ESP, and finally with AH
    between the same pair of endpoints, all of the SAs MUST be deleted

page 34:

Old:

2.22 IPcomp

New:

2.22 IPComp

Old:

    implementations of this specification MUST NOT accept an IPcomp
    algorithm that was not proposed, MUST NOT accept more than one, and

New:

    implementations of this specification MUST NOT accept an IPComp
    algorithm that was not proposed, MUST NOT accept more than one, and

Old:

    A side effect of separating the negotiation of IPcomp from
    cryptographic parameters is that it is not possible to propose

New:

    A side effect of separating the negotiation of IPComp from
    cryptographic parameters is that it is not possible to propose

pp 65, 66:

Old:

         IPCOMP_SUPPORTED                         24581

             This notification may only be included in a message
             containing an SA payload negotiating a CHILD_SA and
             indicates a willingness by its sender to use IPcomp on this
             SA. The data associated with this notification includes a
             two octet IPcomp CPI followed by a one octet transform ID
             optionally followed by attributes whose length and format is
             defined by that transform ID. A message proposing an SA may
             contain multiple IPCOMP_SUPPORTED notifications to indicate
             multiple supported algorithms. A message accepting an SA may
             contain at most one.

             The transform IDs currently defined are:

                  NAME         NUMBER  DEFINED IN
                  -----------  ------  -----------
                  RESERVED       0
                  IPCOMP_OUI     1
                  IPCOMP_DEFLATE 2     RFC 2394
                  IPCOMP_LZS     3     RFC 2395

                  values 4-240 are reserved to IANA. Values 241-255 are
                  for private use among mutually consenting parties.

New:

         IPCOMP_SUPPORTED                         24581

             This notification may only be included in a message
             containing an SA payload negotiating a CHILD_SA and
             indicates a willingness by its sender to use IPComp on this
             SA. The data associated with this notification includes a
             two octet IPComp CPI followed by a one octet transform ID
             optionally followed by attributes whose length and format is
             defined by that transform ID. A message proposing an SA may
             contain multiple IPCOMP_SUPPORTED notifications to indicate
             multiple supported algorithms. A message accepting an SA may
             contain at most one.

             The transform IDs currently defined are:

                  NAME         NUMBER  DEFINED IN
                  -----------  ------  -----------
                  RESERVED       0
                  IPCOMP_OUI     1
                  IPCOMP_DEFLATE 2     RFC 2394
                  IPCOMP_LZS     3     RFC 2395
                  IPCOMP_LZJH    4     RFC 3051

                  values 5-240 are reserved to IANA. Values 241-255 are
                  for private use among mutually consenting parties.

page 83:

Old:

    IPcomp Transform IDs

New:

    IPComp Transform IDs

page 85:

Old:

    [IPCOMP]   Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP
               Payload Compression Protocol (IPComp)", RFC 2393,
               August 1998.

New:

    [IPCOMP]   Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP
               Payload Compression Protocol (IPComp)", RFC 3173,
               September 2001.

=== eom ===

---

From: Francis Dupont <[email-masked]>
Date: Mon, 09 Jun 2003 17:06:05 +0200

In your previous mail you wrote:

   I have some concerns about the current draft (08), here are
   the minor concerns:

    - in section 2.1 (retransmission) we should stress the "messages"
      are IKE messages, i.e., for instance one can restransmit a request
      using a different address in the transport header. I propose a
      very simple improvement, change:

     For every pair of messages, the Initiator is responsible for

      to

     For every pair of IKE messages, the Initiator is responsible for

     so the reader can refer to section 3 where IKE messages are defined.

    - nowhere the rule for sending response (reverse the transport stuff)
      is fully explained. I propose to complete section 2.11 (agility):

     ... An implementation MUST
     accept incoming connection requests even if not received from UDP
     port 500 or 4500, and MUST respond to the address and port from which
     the request was received.

      becomes:

     ... An implementation MUST
     accept incoming requests even if not received from UDP port 500 or
     4500, and MUST respond to the address and port from which the request
     was received, and from the address and port to which the request was
     received.

      note that I suppressed the word "connection" as this stands for
      every requests.

    - when CHILD_SAs rekeyed with a CREATE_CHILD_SA using PFS are usable?
      In IKEv1 these synchro issues are handled by the infamous commit bit
      and the third message of quick mode... IMHO the companion draft
      (draft-ietf-ipsec-ikev2-tutorial-xx.txt) should give some hints.
      BTW I'd like to get the opinion from other implementors because
      the simplest solution (wait for an initiator->responder packet)
      is not always available... This can be an occasion to explain
      what SA to use in rekeying, the new one or the old one until it
      expires?

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 09 Jun 2003 17:41:03 +0200

the major concerns:

    - the NAT traversal facility is clearly unfinished: what
      is the decision about this: postpone this to another
      draft, give up all missing stuff, something else?

      Two examples of missing stuff:
       * the encapsulation of ESP of UDP 4500
       * the implicit peer address update mechanism

    - the peer addresses (the addresses IKE runs over, cf 2.11) are
      not protected, this makes IKEv2 usable to launch DoS attacks
      by modifying addresses in IP headers of some packets.

      Initial CHILD_SA establishment can be made safe if NAT detection
      (i.e., NAT_DETECTION_{SOURCE,DESTINATION}_IP) is mandatory for
      all implementations (I can't see any problem with this and
      the proposed modification to the draft is very simple: put
      the relevant statement some lines before or after its current
      position).

      If this is accepted, we have two ways to protect the addresses
      of peers which are not behind a NAT:
       * always use the peer address of the IKE_SA_INIT messages as
         the address of the endpoint in any derived SA (i.e., "lock"
         it, the idea is from Tero Kivinen).
       * introduce a new notification to specify the proper peer
         address(es). This idea (mine) gives a better support to SCTP
         and similar cases but needs more work/time.

Regards

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 09 Jun 2003 17:50:45 -0700

I want to formally raise the issue of identity protection once again, 
now that we are in last call. This has been referred to by Hannes and 
Hugo in recent posts, and was discussed previously here.

I don't think anyone will disagree that identity protection is useful in 
remote access scenarios for a number of reasons. In such cases, the 
identity of the SGW might often be obvious based on its use of a fixed 
IP address, but the identity of the initiator need not be.

In weighing the usefulness of adding identity protection, we might 
consider how difficult it is to see the packets en route against what 
benefit an attacker might derive from knowledge of the identity, and 
also against the cost of securing this information. In many remote 
access scenarios, gaining access to packets containing identities is not 
a simple thing - the cost to the attacker is not insignificant. And the 
derived information does not provide a direct advantage - it is only one 
piece of the puzzle, and in general, significantly more work is required 
to take advantage of it. I think that for these reasons, some folks may 
feel that this protecting the intiator identity is not that important.

Wireless network access is very much like remote access, and IPsec is 
sometimes used to secure such access. However, note that in a large 
number of wlan deployment scenarios, gaining access to the packets 
containing the identity is often straightforward, or even trivial. That 
is, the cost is significantly less than in the wired case. This changes 
the cost-benefit analysis considerably. For this reason, I think we 
should reconsider this. I think identity protection is a *very* 
important feature, and that IKEv2 should support it.

Scott