Delete Payload processing in IKEv2_05

[" Zhang" <jzhang@elmic.com>]

Hi, Charlie,

I don't follow the description of IKEv2_05, section 1.4 about the delete informational exchange. I suggest change the last paragraph of page 10 to the following.


From end of Page 10:

......To delete an SA, an INFORMATIONAL Exchange with one or more delete payload is sent listing the SPIs (as they would be placed in the headers of outbound packets) of the SAs to be deleted. The recipient MUST delete the incoming SAs while processing the request and the paired outgoing SAs, if any, while processing the response. If any paired outgoing SAs are deleted, the reply in the INFORMATIONAL Exchange MUST contain delete payloads for these deleted ones,( otherwise, the reply MUST NOT contain any delete payloads.)


The reason for this change:
1) The original document put "it MUST delete the incoming SAs while processing the request and the outgoing SAs while processing the response" into the exception block. However, this should be a normal behavior for the recipient. And actually, for the exception case (simultanously sent out delete request), the outgoing SAs had been deleted.

2) There may be asymmetry policy which specifies IPsec protection in only ONE direction. That justifies the 'if any' in the above text. The exception case in the original IKEv2-05 document belongs to this solution, i.e., no outgoing SAs found.

Thanks,

Jimmy Zhang
Elmic Systems. Inc.




---------- Original Message ----------------------------------
From: Tero Kivinen <kivinen@ssh.fi>
Date:  Thu, 20 Mar 2003 20:00:50 +0200

>Francis Dupont writes:
>> => IMHO the current draft is a bit underspecified, for instance it
>> should explicitely permit to run IKE over port 4500 from the beginning
>> (so there will be only one mapping and as soon as an exchange succeed
>> the whole stuff, including IPsec SAs, works).
>
>>From the draft-ietf-ipsec-ikev2-05.tx:
>----------------------------------------------------------------------
>2.11 Address and Port Agility
>
>   IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
>   AH associations for the same IP addresses it runs over. The IP
>   addresses and ports in the outer header are, however, not themselves
>   cryptographically protected, and IKE is designed to work even through
>   Network Address Translation (NAT) boxes. 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.  IKE functions identically over IPv4 or
>   IPv6.
>----------------------------------------------------------------------
>
>I.e it now already says that both port 500 and 4500 are used, and the
>NAT traversal sections says:
>----------------------------------------------------------------------
>2.23 NAT Traversal
>
>...
>   The specific requirements for supporting NAT traversal are listed
>   below.  Support for NAT traversal is optional. In this section only,
>   requirements listed as MUST only apply to implementations supporting
>   NAT.
>
>      IKE MUST listen on port 4500 as well as port 500. IKE MUST respond
>      to the IP address and port from which packets arrived.
>----------------------------------------------------------------------
>
>> => note you explicitely use an IKE which always runs over UDP 4500.
>> IMHO this is the good solution and it should be documented (current
>> draft suggests the first exchange must be over UDP 500).
>
>Where does it say so? The current draft talks about ports 500 and
>4500 in almost equal way (only difference being that 4500 have
>different encoding and that port 4500 works better through NATs). 
>-- 
>kivinen@ssh.fi
>SSH Communications Security                  http://www.ssh.fi/
>SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
>