Subject: [IPsec] Issue #42 Improve example of multiple proposals

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2008 15:52:11 +0300

> >  3.3.  Security Association Payload
> ...
> >     The Proposal structure contains within it a Proposal # and an IPsec
> >     protocol ID.  Each structure MUST have a proposal number one (1)
> >     greater than the previous structure.  The first Proposal in the
> >     initiator's SA payload MUST have a Proposal # of one (1).  A proposal
> >     of AH or ESP would have two proposal structures, one for AH with
> >     Proposal #1 and one for ESP with Proposal #2.
> 
> I think the last sentence should be removed, as it is bit confusing
> and some people might read it "AH and ESP" and interpret it as
> bundles. I do not really consider AH or ESP style proposal that
> common to require example here. Perhaps ESP with combined mode ciphers
> and ESP with normal ciphers + integrity algorithms would make better
> example.
> 
> ===Not done. The current example is clearer than your proposed change
> because few people understand combined modes, even if the current
> example is far-fetched. A different, clearer example would be a good
> replacement for the current text.

The problem is that currently there is only ONE good reason to use
multiple proposals. This is combined mode ciphers. Because of this I
think it is the one that should be used as an example.

I do not think using combined modes in ESP is that complicated.
Replacement text could be something like this:

   The Proposal structure contains within it a Proposal # and an IPsec
   protocol ID. Each structure MUST have a proposal number one (1)
   greater than the previous structure. The first Proposal in the
   initiator's SA payload MUST have a Proposal # of one (1). A common
   reason to use multiple proposals is when used with combined mode
   ciphers. Combined mode ciphers include both integrity and
   encryption in single encryption algorithm. Because of this it is
   not allowed to have combined mode ciphers with an another integrity
   algorithm, thus proposal must not have any integrity algorithms
   (other than NONE). If initiator want to propose both combine mode
   ciphers and normal ciphers, it must include two proposals. One will
   have all combined mode ciphers, and no integrity algorithm. The
   other will have all non-combined mode ciphers and all allowed
   integrity algorithms with them. For example such proposal would
   have two proposal structures, one for ESP with ENCR_AES-CCM_8,
   ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1 and one for ESP
   with ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and
   AUTH_HMAC_SHA1_96 as Proposal #2.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Sep 2008 15:46:10 -0700

>    AUTH_HMAC_SHA1_96 as Proposal #2.

<sigh> I'm coming around on us having to talk about combined-mode 
ciphers where they are needed here. The above text (with a bit of 
editorial change) is a good example of why we would have multiple 
proposals.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 24 Sep 2008 07:32:56 -0400

> editorial change) is a good example of why we would have multiple 

The reason we would mention combined-mode as an example is because it is 
not supported on all implementations, and therefore an implementation that 
supported it would be advised to propose both combined-mode and otherwise. 
 However, there may be better examples.

It is also the case that AH support is not required of an implementation, 
correct?  So we could use this as an example case.  If the user wants to 
perform authentication only, and prefers to use AH, but is willing to use 
ESP in the hypothetical case of interoperating with a peer that supports 
ESP only, then that is also a good example of requiring multiple 
proposals.

The same goes for more advanced cryptographic algorithms.  For example, if 
a user wants to use AES-256 but is willing to use AES-128 if that is the 
strongest algorithm supported by a particular partner, then both may be 
proposed.

Use of ESN is another example.  Implementations that support ESN would not 
want for a negotiation to fail simply because the peer does not support 
ESN.  Such implementations would be advised to send proposals both with 
and without ESN.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Paul Hoffman <[email-masked]>
To:
Tero Kivinen <[email-masked]>, [email-masked]
Date:
09/23/2008 06:47 PM
Subject:
Re: [IPsec] Issue #42 Improve example of multiple proposals

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Sep 2008 15:06:43 +0300

On Sep 24, 2008, at 2:32 PM, Scott C Moonen wrote:

> The reason we would mention combined-mode as an example is because  
> it is not supported on all implementations, and therefore an  
> implementation that supported it would be advised to propose both  
> combined-mode and otherwise.  However, there may be better examples.
>
> It is also the case that AH support is not required of an  
> implementation, correct?  So we could use this as an example case.   
> If the user wants to perform authentication only, and prefers to use  
> AH, but is willing to use ESP in the hypothetical case of  
> interoperating with a peer that supports ESP only, then that is also  
> a good example of requiring multiple proposals.

That's different, because ESP and AH are different protocols, so it  
makes sense that they be separated to different proposals. AES-GCM and  
AES-CBC+HMAC-SHA1 are valid alternatives for accomplishing the same  
things. Using them in separate proposals is a finer point.

> The same goes for more advanced cryptographic algorithms.  For  
> example, if a user wants to use AES-256 but is willing to use  
> AES-128 if that is the strongest algorithm supported by a particular  
> partner, then both may be proposed.

Yes, but both can be proposed in a single proposal - they're just  
different ENCR transforms.

> Use of ESN is another example.  Implementations that support ESN  
> would not want for a negotiation to fail simply because the peer  
> does not support ESN.  Such implementations would be advised to send  
> proposals both with and without ESN.

Again ESN-yes and ESN-no can both be proposed in a single proposal.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Sep 2008 15:27:13 +0300

> ESP only, then that is also a good example of requiring multiple 

The reason I do not like to use "AH or ESP" as example is that it is
very easy for the IKEv1 implementor to read that as "AH and ESP" as
was possible with IKEv1, but which is no longer possible with IKEv2.
Just to avoid confusion about this I think it would be good idea to
avoid "AH or ESP" in the example.

> strongest algorithm supported by a particular partner, then both may be 

But that does not require multiple proposals, they can all be proposed
in one proposal, which contains all ciphers which implementation is
willing to accept. The responder will then select exactly one cipher
from the list given by the initiator. 

> ESN.  Such implementations would be advised to send proposals both with 

No. Implementations should send ONE proposal having both "No Extended
Sequence Numbers" and "Extended Sequence Numbers" in their proposal
i.e. 2 transform type 5 (Extended Sequence Numbers) transform
attributes, with transform IDs of both 0 and 1. As implementations
MUST understand ESN transform attributes they must be able to pick the
one which they support from such proposal.

In most cases you can go with just ONE proposal having multiple
transforms inside, including multiple transforms having same trasform
ID but different transform attributes.

This does not work with combined mode ciphers, as you are not allowed
to use any other Integrity Algorithm with them than NONE, thus you
cannot propose one proposal having:

Transform Type			Transform Attribute
1 Encryption Algorithm	    	12 ENCR_AES_CBC
1 Encryption Algorithm		16 ENCR_AES-CCM_16
1 Encryption Algorithm		3 ENCR_3DES
1 Encryption Algorithm		20 AES-GCM with a 16 octet ICV
2 Integrity Algorithm	      	0 NONE
2 Integrity Algorithm	      	2 AUTH_HMAC_SHA1_96
5 Extended Sequence Numbers	0 No Extended Sequence Numbers
5 Extended Sequence Numbers	1 Extended Sequence Numbers 

As now the responder could select ENCR_AES-CCM_16 with
AUTH_HMAC_SHA1_96 which is not allowed, or it could also pick
ENCR_3DES with NONE integrity algorithm, which is something you would
not want to allow.

Because of this you need to give 2 proposals:

Proposal #1
Transform Type			Transform Attribute
1 Encryption Algorithm	    	12 ENCR_AES_CBC
1 Encryption Algorithm		3 ENCR_3DES
2 Integrity Algorithm	      	2 AUTH_HMAC_SHA1_96
5 Extended Sequence Numbers	0 No Extended Sequence Numbers
5 Extended Sequence Numbers	1 Extended Sequence Numbers 

Proposal #2
Transform Type			Transform Attribute
1 Encryption Algorithm		16 ENCR_AES-CCM_16
1 Encryption Algorithm		20 AES-GCM with a 16 octet ICV
2 Integrity Algorithm	      	0 NONE
5 Extended Sequence Numbers	0 No Extended Sequence Numbers
5 Extended Sequence Numbers	1 Extended Sequence Numbers 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Sep 2008 07:37:57 -0700

>avoid "AH or ESP" in the example.

I agree with this.

>one which they support from such proposal.

Tero: please write up some text for the document about using one 
proposal instead of multiple proposals that could be represented as 
one proposal. If the WG can agree to it, it would be a good addition 
to the document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Sep 2008 15:40:14 +0300

> one proposal. If the WG can agree to it, it would be a good addition 

The section 3.3. has already paragraph explaining those, but I think
what we should do is to add examples of both cases (just like rfc2409
had). Here is the paragraph explaining the multiple transforms:

   If there are multiple transforms with the same Transform Type, the
   proposal is an OR of those transforms.  If there are multiple
   Transforms with different Transform Types, the proposal is an AND of
   the different groups.  For example, to propose ESP with (3DES or AES-
   CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two
   Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and
   two Transform Type 3 candidates (one for HMAC_MD5 and one for
   HMAC_SHA).  This effectively proposes four combinations of
   algorithms.  If the initiator wanted to propose only a subset of
   those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there
   is no way to encode that as multiple transforms within a single
   Proposal.  Instead, the initiator would have to construct two
   different Proposals, each with two transforms.

So we could add following sections:
----------------------------------------------------------------------
3.3.7.  Example of SA Payload with One Proposal

  In normal case there is only need to include just one proposal to
  the SA payload. This one proposal will list all the supported
  (non-combined mode) algorithms and responder will pick the one set
  of those algorithms to be used. Multiple proposals (most commonly
  two) is needed in some more complex cases like proposing both
  combined mode ciphers and non-combined mode ciphers.

  This example here offers one proposal payload inside the SA payload
  and proposes all commonly used encryption algorithms (3DES, AES_CBC,
  AES_CTR), integrity algorithsm (MD5, SHA1, AES_XCBC_96), and
  extended sequence numbers. It also includes 3 key lengths for the
  AES algorithms. This proposal is one to be used when creating child
  SA without doing another Diffie-Hellman.

                          1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |       SA Payload Length=136   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0 (last)      |   RESERVED    |  Proposal Proposal Length=132 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Proposal #=1 | Protocol ID=3  |  SPI Size=4   |# of Transf.=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SPI (4 bytes) = 0x58293233                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=8     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=1 |   RESERVED    | Transf. ID = 3 ENCR_3DES      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=1 |   RESERVED    | Transf. ID = 12 ENCR_AES_CBC  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Attribute Type=14 Key Length| Attribute Value = 128         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=1 |   RESERVED    | Transf. ID = 12 ENCR_AES_CBC  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Attribute Type=14 Key Length| Attribute Value = 192         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=1 |   RESERVED    | Transf. ID = 12 ENCR_AES_CBC  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Attribute Type=14 Key Length| Attribute Value = 256         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=1 |   RESERVED    | Transf. ID = 13 ENCR_AES_CTR  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Attribute Type=14 Key Length| Attribute Value = 128         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=1 |   RESERVED    | Transf. ID = 13 ENCR_AES_CTR  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Attribute Type=14 Key Length| Attribute Value = 192         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=1 |   RESERVED    | Transf. ID = 13 ENCR_AES_CTR  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Attribute Type=14 Key Length| Attribute Value = 256         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=8     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=3 |   RESERVED    | Transf. ID=1 AUTH_HMAC_MD5_96 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=8     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=3 |   RESERVED    | Transf. ID=2 AUTH_HMAC_SHA1_96|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=8     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=3 |   RESERVED    | Transf. ID=5 AUTH_AES_XCBC_96 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 3 (not last)  |   RESERVED    |        Transform Length=8     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=5 |   RESERVED    | Transf. ID=0 No ESN           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0 (last)      |   RESERVED    |        Transform Length=8     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transf. Type=5 |   RESERVED    | Transf. ID=1 ESN              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In short this payload format can be expressed as:

   Proposal #1: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233
      Transform: Type = 1 (Encryption Algorithm), ID = 3 ENCR_3DES
      Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC
      		 Attribute: Type = 14 (Key Length), Value = 128
      Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC
      		 Attribute: Type = 14 (Key Length), Value = 192
      Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC
      		 Attribute: Type = 14 (Key Length), Value = 256
      Transform: Type = 1 (Encryption Algorithm), ID = 13 ENCR_AES_CTR
      		 Attribute: Type = 14 (Key Length), Value = 128
      Transform: Type = 1 (Encryption Algorithm), ID = 13 ENCR_AES_CTR
      		 Attribute: Type = 14 (Key Length), Value = 192
      Transform: Type = 1 (Encryption Algorithm), ID = 13 ENCR_AES_CTR
      		 Attribute: Type = 14 (Key Length), Value = 256
      Transform: Type = 2 (Integrity Algorithm), ID = 1 AUTH_HMAC_MD5_96
      Transform: Type = 2 (Integrity Algorithm), ID = 2 AUTH_HMAC_SHA1_96
      Transform: Type = 2 (Integrity Algorithm), ID = 5 AUTH_AES_XCBC_96
      Transform: Type = 5 (Extended Sequence Numbers), ID = 0 No ESN
      Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN

   This same shorter format is used in the next section when
   describing more complex proposals. The return packet from the
   responder will contain SA payload having contents something like
   this (provided it selected AES_CBC with 256 bit keys, AES_XCBC and
   ESN):

   Proposal #1: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233
      Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC
      		 Attribute: Type = 14 (Key Length), Value = 256
      Transform: Type = 2 (Integrity Algorithm), ID = 5 AUTH_AES_XCBC_96
      Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN

3.3.8.  Example of SA Payload with Combined Mode Ciphers

   Combined mode ciphers gives one more complication when proposal
   structures are concenrned, as it is forbidden to propose integrity
   algorithms with them. This means that you cannot include normal
   non-combined mode ciphers and intergrity protection in the same
   proposal where you propose combined mode ciphers. This means you
   need two proposals if you want to propose both.

   This example has two proposals one proposing ENCR_AES_CCM_16 (with
   3 different key lengths). Second proposes ENCR_AES_CBC (with 3
   different key lengths) and AUTH_HMAC_SHA1_96 or AUTH_AES_XCBC_96.
   Here we also want to do another Diffie-Hellman using group 1536,
   2048 or 3072 bit MODP-group. Here is the proposals in the short
   format:
   
   Proposal #1: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233
      Transform: Type = 1 (Encryption Algorithm), ID = 16 ENCR_AES_CCM_16
      		 Attribute: Type = 14 (Key Length), Value = 128
      Transform: Type = 1 (Encryption Algorithm), ID = 16 ENCR_AES_CCM_16
      		 Attribute: Type = 14 (Key Length), Value = 192
      Transform: Type = 1 (Encryption Algorithm), ID = 16 ENCR_AES_CCM_16
      		 Attribute: Type = 14 (Key Length), Value = 256
      Transform: Type = 5 (Extended Sequence Numbers), ID = 0 No ESN
      Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN
      Transform: Type = 4 (Diffie-Hellman Group), ID = 5 1535-bit MODP
      Transform: Type = 4 (Diffie-Hellman Group), ID = 14 2048-bit MODP
      Transform: Type = 4 (Diffie-Hellman Group), ID = 15 3076-bit MODP
   Proposal #2: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233
      Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC
      		 Attribute: Type = 14 (Key Length), Value = 128
      Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC
      		 Attribute: Type = 14 (Key Length), Value = 192
      Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC
      		 Attribute: Type = 14 (Key Length), Value = 256
      Transform: Type = 2 (Integrity Algorithm), ID = 2 AUTH_HMAC_SHA1_96
      Transform: Type = 2 (Integrity Algorithm), ID = 5 AUTH_AES_XCBC_96
      Transform: Type = 5 (Extended Sequence Numbers), ID = 0 No ESN
      Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN
      Transform: Type = 4 (Diffie-Hellman Group), ID = 5 1535-bit MODP
      Transform: Type = 4 (Diffie-Hellman Group), ID = 14 2048-bit MODP
      Transform: Type = 4 (Diffie-Hellman Group), ID = 15 3076-bit MODP

   Note, how the ESN and Diffie-Hellman groups are included in both
   proposals. For ESN that would not be mandatory, as it would be
   possible for example to support ESN only with combined mode
   ciphers, and non-combined mode ciphers would always say No ESN. For
   Diffie-Hellman Groups the situation is different, as the KE payload
   is shared with both proposals, meaning the Diffie-Hellman group
   used in KE payload group must be something that is proposed in both
   proposals.

   The return packet from the responder selecting combined mode
   ciphers could have following proposal:

   Proposal #1: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233
      Transform: Type = 1 (Encryption Algorithm), ID = 16 ENCR_AES_CCM_16
      		 Attribute: Type = 14 (Key Length), Value = 192
      Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN
      Transform: Type = 4 (Diffie-Hellman Group), ID = 14 2048-bit MODP

   The return packet from the responder selecting AES_CBC could have
   following proposal:

   Proposal #2: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233
      Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC
      		 Attribute: Type = 14 (Key Length), Value = 128
      Transform: Type = 2 (Integrity Algorithm), ID = 2 AUTH_HMAC_SHA1_96
      Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN
      Transform: Type = 4 (Diffie-Hellman Group), ID = 5 1535-bit MODP
----------------------------------------------------------------------

If we add such sections, then we might want to remove some of the
other text I already sent about combined mode ciphers, as this already
explains them.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec