Subject: [Ipsec] New I-D: IKEv2 Clarifications and Implementation Guidelines

From: [email-masked]
Date: Sat, 5 Feb 2005 14:39:05 +0200

Hi,

A new internet-draft, "IKEv2 Clarifications and Implementation 
Guidelines" is now available from:

http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-00.txt

Abstract

   This document clarifies some areas of the IKEv2 specification that
   may be difficult to understand to developers not intimately familiar
   with the specification and its history.  The intent is not to
   introduce any changes to the protocol, but rather to provide
   descriptions less prone to ambiguous interpretations, and thus
   encourage the development of interoperable implementations.  Readers
   are advised that this document is work-in-progress, and may contain
   incorrect interpretations.

Comments are most welcome! (This -00 version certainly contains 
errors that are due to my misunderstanding of some details..)

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Feb 2005 10:01:41 +0200

Some comments:

1. I think I can offer another reason for the existence of REKEY_SA. 
Although IPsec works on single packets, many implementations have a 
concept of a "connection" which is well-defined for TCP, and less so 
for UDP or ICMP.  Such implementations associate each connection with 
an SA used to implement it.  The REKEY_SA notification serves to tell 
these implementations that all the connections associated with one SA 
are moving to another SA, which is better than just deleting the SA and 
having them search the SAD for a suitable SA.

2. In section 2.9 you have:
    Reauthentication is done by creating a new IKE_SA from scratch (using
    IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
    payloads), creating new CHILD_SAs within the new IKE_SA (without
    REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
    deletes the old CHILD_SAs as well).

It's too bad that IKEv2 requires you to create new child SAs for 
repeated authentication.  It would be nice if the new IKE_SA could 
inherit the old child SAs just like the rekeyed IKE_SA can.  I'm 
wondering whether I should include this ability in my draft.  Barring 
that, I think it's an obvious idea for IKE peers, even in remote access 
to establish child SAs only as needed. It makes sense to do the 
reauthentication by just creating a new IKE_SA and then deleting the 
old IKE_SA. Unfortunately IKEv2 does not allow creating just an IKE_SA 
so there will be at least one child SA left, but all the other child 
SAs will be deleted.  Since we assume that both peers can establish 
child SAs as needed, this is not a problem.  I think there should be 
text that says that deleting an IKE_SA when a new IKE_SA exists should 
not be taken as an intent to disconnect existing connections.

3. Regarding section 3.3 (SUBNET) there can be another use of this 
specification.  Suppose the server's reply is as follows:
       CP(CFG_REPLY) =
         INTERNAL_IP4_ADDRESS(192.0.1.234)
         INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
         INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
       TSi = (0, 0-65536, 0.0.0.0-255.255.255.255)
       TSr = (0, 0-65536, 0.0.0.0-255.255.255.255)
This means that this SA can be used for any traffic, but only the two 
subnets are actually protected by the device. The client may send all 
its Internet traffic through the gateway or it may send only the things 
protected by the device.

4. Section 3.4.  A subnet mask has a meaning in addition to being able 
to use layer 2.  It also says which addresses will receive a broadcast. 
  For example, if the client receives:
       CP(CFG_REPLY) =
         INTERNAL_IP4_ADDRESS(192.0.1.234)
         INTERNAL_IP4_NETMASK(255.255.255.0)
This may indicate that if the client sends an encrypted packet to 
192.0.1.255, the edge device will decrypt it, and then re-encrypt it 
will all existing tunnels with assigned IPs in the 192.0.1.x range, so 
that they all receive it.  I don't know of any implementation that 
actually does this, and barring that it really does not make sense to 
have this attribute at all.

5. I'm missing some discussion of hash-and-URL. AFAIK this is something 
that hasn't been done in an RFC before.  It should be noted that the 
infrastructure for storing Certs on servers is not yet in place, and is 
outside the scope of IKEv2.  Should the cert be on the gateway?  Should 
it be on the CA?  On the CRL server?  New type of server?  There's also 
a work in progress to define push certificates.