Subject: Re: [IPsec] IKEv2bis Issue #157

From: Alfred Hönes <[email-masked]>
Date: Wed, 3 Feb 2010 19:12:24 +0100 (MEZ)

At Wed, 3 Feb 2010 17:20:20 +0200, Yoav Nir wrote:
> Hi all.
>
> 5 more issues.
>
> ...
>
>
> 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.
>
> ...

If line formating limits hurt, you might consider to
"mirror the figure at the lower diagonal", i.e. give it
a look & feel like an asn1dump without the hex data,
or -- the ToC of the draft !  :-)

Here's a sketch in terse notation:

     SA Payload
        Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
                      7 transforms,      SPI = 0x95903423 )
           Transform  ENCR ( Name = ENCR_AES_CBC )
              Attribute ( Key Length = 128 )
           Transform  INTEG ( Name = AUTH_HMAC_SHA1_96 )
           Transform  ENCR ( Name = ENCR_AES_CBC )
              Attribute ( Key Length = 192 )
           Transform  INTEG ( Name = AUTH_XCBC_96 )
           Transform  ENCR ( Name = ENCR_AES_CBC )
              Attribute ( Key Length = 256 )
           Transform  ESN ( Name = No ESNs )
           Transform  ESN ( Name = ESNs )
        Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
                      4 transforms,      SPI = 0x12345678 )
           Transform  ENCR ( Name = ENCR_AES_GCM w/ 8-octet ICV )
              Attribute ( Key Length = 128 )
           Transform  ESN ( Name = No ESNs )
           Transform  ENCR ( Name = ENCR_AES_GCM w/ 8-octet ICV )
              Attribute ( Key Length = 256 )
           Transform  ESN ( Name = ESNs )

Alternatively, curly braces could be added for double clarity
(you might also leave these off at lower levels):

     SA Payload {
        Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
                      7 transforms,      SPI = 0x95903423 ) {
           Transform  ENCR ( Name = ENCR_AES_CBC ) {
              Attribute ( Key Length = 128 )
           }
           Transform  INTEG ( Name = AUTH_HMAC_SHA1_96 ) { }
           Transform  ENCR ( Name = ENCR_AES_CBC ) {
              Attribute ( Key Length = 192 )
           }
           Transform  INTEG ( Name = AUTH_XCBC_96 ) { }
           Transform  ENCR ( Name = ENCR_AES_CBC ) {
              Attribute ( Key Length = 256 )
           }
           Transform  ESN ( Name = No ESNs ) { }
           Transform  ESN ( Name = ESNs ) { }
        }
        Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
                      4 transforms,      SPI = 0x12345678 ) {
           Transform  ENCR ( Name = ENCR_AES_GCM w/ 8-octet ICV ) {
              Attribute ( Key Length = 128 )
           }
           Transform  ESN ( Name = No ESNs ) { }
           Transform  ENCR ( Name = ENCR_AES_GCM w/ 8-octet ICV ) {
              Attribute ( Key Length = 256 )
           }
           Transform  ESN ( Name = ESNs ) { }
        }
     }

Many variations are possible.

Note that in the diagram in Yoav's message, the representation of
transform type 5 is not consistent with the remainder of the figure;
above, I have left off the code point (number) assigned to the ESN
transform names -- in the same way as for the other transform types.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Feb 2010 10:36:24 -0800

>transform names -- in the same way as for the other transform types.

I definitely like Alfred's first example more than the tree diagram currently under discussion. The empty curly braces in the second diagram are more confusing that just using the indentation in the first example.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 3 Feb 2010 23:33:49 +0200

I find Tero's figure easier to understand, more "illustrative". This is obviously very subjective.

	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Wednesday, February 03, 2010 20:12
> To: [email-masked]
> Subject: Re: [IPsec] IKEv2bis Issue #157
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.