[IPsec] Yet another closing session - issues #153-#157

[Yoav Nir <[e-mail]>]

Hi all.

5 more issues.

Issue #153 - List of EAP methods
================================
3.16: I suggest to remove the table quoted from the EAP RFC. There are dozens of methods now in the IANA registry, many of which are preferable to the ones mentioned here.

I agree, especially since we have a SHOULD NOT for using methods 4-6. I suggest removing the entire table (and the sentence "The following types are defined..." which precedes it. Instead, change the following paragraph to read as follows (added comment in parenthesis):

   Note that since IKE passes an indication of initiator identity in
   message 3 of the protocol, the responder should not send EAP Identity
   requests (type 1).  The initiator may, however, respond to such requests
   if it receives them.



Issue #154 - Sending dummy messages during rekey
================================================
Sec. 2.8: "An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages." 
A dummy (higher level protocol) message on an IPsec SA is way out of scope. Whether such messages even exist is a matter of local implementation. 
Or does the document refer to "dummy ESP messages" (RFC 4303, sec. 2.6)? If so, please add the reference.

I suspect that some implementations do not implement TFC, and so had no reason to implement dummy messages. If this was a MUST here or even a SHOULD, I would definitely object, but this is a MAY-level requirement.

I think we can close this by replacing "MAY send a dummy message on a newly created SA..." with "MAY send a dummy ESP message on a newly created ESP SA..."  (added ESP twice, because there are no dummy messages in AH), and add a normative reference to RFC 4303 - no need IMO to link from the text.



Issue #155 - SHOULD send triggering packet and interoperability
===============================================================
In the sectioon 2.9 the "SHOULD" requirement was removed for the very specific traffic selector as fist traffic selector. 

I think that "SHOULD" requirement needs to be kept, as it affects interoperability, as if other end does not include that triggering packet then certain policies cannot interoperate. 

Also in the interops we have seen implementations who could not interoperate at all if sender end included triggering packet (I do not know if the failure to create Child SA was because the traffic selector containing port selectors, or whether it was because there were multiple traffic selectors). 

If there is "SHOULD" level requirement for that, then we can at least point the other vendors to that and say, that as we SHOULD be sending that triggering packet, then you also needs to be able to cope with it... 

Old text was: 

To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first traffic selector in each of TSi and TSr a very specific traffic selector including the addresses in the packet triggering the request. 

new text in draft-ietf-ipsecme-ikev2bis-07.txt is: 

If the initiator requests an SA because it wants to send a data packet, including the specific addresses in the packet triggering the request in the first traffic selector in both TSi and TSr enables the responder to choose the appropriate range.

I agree with Tero here. I think the SHOULD should come back.



Issue #156 - SHOULD generate and accept which types?
====================================================
Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID), and then says: 

Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR. 

What does " Implementations SHOULD be capable of generating and accepting all of these types" mean? It can't mean the four just listed, because that list of four comes with MUSTs. If it means all the listed types, the sentence should be changed to "Implementations SHOULD also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and ID_DER_ASN1_GN."


Unlike the other issues in this mail, this one generated a lively debate, that quickly went to requirements for PKIX. Valery made a (to mind mind valid) point that the requirements in section 4 specify certificates with RSA keys, where other algorithms are available: GOST, DSA and ECDSA. While this is a valid point, criticism of section 4 should be in another issue, so I suggest going with Pasi's recommendation, and keeping the text as is.



Issue #157 - Illustrate the SA payload with a diagram
=====================================================
The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might be helpful. 

"The margin is too narrow for a diagram" (Trac munges my diagram and will not take attachments). Will be sent separately to the list.

Everybody likes illustrations. Yaron made one, Tero improved on this, and several people commented, for a total of 11 messages to the list.  The final version is Tero's, which kind of looks cramped, but I think should be added. (what ever happened to that draft about adding graphics to RFCs?)

                          SA Payload
                              |
           +------------------+---------------------------+
           |                                              |
           |                                              |
       Proposal #1                                    Proposal #2
   Proto ID = ESP (3)                             Proto ID = ESP (3)
     SPI size = 4                                   SPI size = 4
     7 transforms                                   4 transforms
   SPI = 0x95903423                               SPI = 0x12345678
           |                                              |
  +------+-+----+------+------+------+------+      +------+------+------+
  |      |      |      |      |      |      |      |      |      |      |
 Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans  Trans
 form   form   form   form   form   form   form   form   form   form   form
 ENCR   INTEG  ENCR   INTEG  ENCR    ESN   ESN    ENCR   ESN    ENCR   ESN
 ENCR   AUTH   ENCR   AUTH   ENCR    No    Use    AES-   No     AES-   Use
 _AES   _HMAC  _AES   _AES   _AES    ESN   ESN    GCM    ESN    GCM    ESN
 _CBC   _SHA1  _CBC   _XCBC  _CBC     0     1     w/8     0     w/8     1
   |    _96      |    _96      |                  octet         octet
   |             |             |                  ICV           ICV
   |             |             |                   |             |
   |             |             |                   |             |
Attribute     Attribute     Attribute           Attribute     Attribute
Key Length    Key Length    Key Length          Key Length    Key Length
   128           192           256                 128           256