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

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Feb 2010 17:20:20 +0200

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Feb 2010 19:28:17 +0200

Yoav Nir writes:
> ...
> 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): 
> 

I support this change.

> 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.  
> 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.

How about changing it to just say that "initiator can send a dummy
message ...".

And the dummy message is not necessarely only those ones described in
the RFC4303 section 2.6, it can be anything that is suitable for the
scenario.

For example in the vpn setup where SA is set up during the autostart
it can be simple ping packet or it can be just udp packet discard port
whether is suitable for the environment.

This text is not describing what the dummy packet is, it is just
saying you might want to (and can) send such packet to make sure other
end knows you have the Child SA installed properly, so they can start
sending packets back.

I do not think we really need to change anything in this text.

> In the sectioon 2.9 the "SHOULD" requirement was removed for the
> very specific traffic selector as fist traffic selector.  
> ...

I (still) agree with myself and Yoav :-)

> 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.

I think it means the four just listed. Note, that only one of them is
MUST to send, all of them is MUST to accept. So the "SHOULD be capable
of generating" is saying that also the other four should be somethint
that can be configured to be sent. The next part "and accepting" is
not really needed as it is already covered by the MUST before.

> 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.

I agree that better keep the text as it is now.

> "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
>                               |

I was not completely happy with the picture as the text in its gets so
narrow, so I was thinking what if we rotate it 90 degrees.

                                 +------------------+----------------+
                                 | Transform	    | Attribute      |
                                 | Type = ENCR(1)   | Type =         |
                               +-+ ID =             |  Key length(14)|
                               | |  ENCR_AES_CBC(12)| Value = 128    |
                               | +------------------+----------------+
                               | | Transform	    | Attribute      |
                               | | Type = ENCR(1)   | Type =         |
                               +-+ ID =             |  Key length(14)|
                               | |  ENCR_AES_CBC(12)| Value = 192    |
                               | +------------------+----------------+
                               | | Transform	    | Attribute      |
                               | | Type = ENCR(1)   | Type =         |
              +--------------+ +-+ ID =             |  Key length(14)|
              | Proposal #1  | | |  ENCR_AES_CBC(12)| Value = 256    |
              | Protocol ID  | | +------------------+----------------+
            +-+    = ESP (3) + | | Transform        |
            | | SPI size = 4 |-+-+ Type = INTEG(3)  |
            | | 7 transforms | + | ID = AUTH_HMAC_  |
            | | SPI =        | | |       SHA1_96(2) |
            | |   0x95903423 | | +------------------+
            | +--------------+ | | Transform        |
            |                  +-+ Type = INTEG(3)  |
            |                  | | ID = AUTH_AES_   |
            |                  | |       XCBC_96(5) |
            |                  | +------------------+
            |                  | | Transform        |
            |                  +-+ Type = ESN (5)   |
            |                  | | ID = No ESN (0)  |
            |                  | +------------------+
            |                  | | Transform        |
            |                  +-+ Type = ESN (5)   |
+---------+ |                    | ID = ESN (1)     |
| SA      +-+		         +------------------+
| Payload | |                    +------------------+
+---------+ |                    | Transform        |
            |                  +-+ Type = ESN (5)   |
            |                  | | ID = No ESN (0)  |
            |                  | +------------------+
            |                  | | Transform        |
            |                  +-+ Type = ESN (5)   |
            |                  | | ID = ESN (1)     |
            | +--------------+ | +------------------+----------------+
            | | Proposal #1  | | | Transform 	    | Attribute      |
            | | Protocol ID  | | | Type = ENCR(1)   | Type =         |
            +-+    = ESP (3) +-+-+ ID = AES-GCM w/  |  Key length(14)|
              | SPI size = 4 | | |  8 octet ICV(18) | Value = 128    |
              | 7 transforms | | +------------------+----------------+
              | SPI =        | | | Transform 	    | Attribute      |
              |   0x12345678 | | | Type = ENCR(1)   | Type =         |
              +--------------+ +-+ ID = AES-GCM w/  |  Key length(14)|
                                 |  8 octet ICV(18) | Value = 256    |
                                 +------------------+----------------+

But that still gets too long to fit for one page, so better to keep my
previous picture.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 8 Feb 2010 21:46:50 +0200

Hi Tero,

Going back to the original issue: there is no interoperable way to send "generic dummy packets". So it's OK if we mention dummy ESP packets, but anything else would be implementation specific. Even pings.

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tero Kivinen
> Sent: Monday, February 08, 2010 19:28
> To: Yoav Nir
> Cc: ipsec
> Subject: [IPsec] Yet another closing session - issues #153-#157
> 
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 9 Feb 2010 13:27:42 +0200

Yaron Sheffer writes:
> Going back to the original issue: there is no interoperable way to
> send "generic dummy packets".

True, and that is ok. This dummy packet does NOT require any
processing from the other end except that some ESP packet needs to be
sent, so other end knows that initiator has installed the SA keying
material, and can start sending its own data to the SA.

It does not matter whether two peers agree on what kind of dummy
packet is sent, or whether the other end understands anything about
the dummy packet.

The dummy packet could be completely random garbage packet too, which
then gets ESP encapsulated, and then other end will decrypt it and
throw it away is it is random. It would be good if the packet would
fit in the traffic selectors, as otherwise the other end might send
unneeded INVALID_SELECTORS notification back... 

> So it's OK if we mention dummy ESP packets, but anything else would
> be implementation specific. Even pings.

Yes, this is implementation specific, and thats why I think it is
better to just talk about "dummy message" as the original text said.
-- 
[email-masked]