Tero's proposed tree structure would not fit in an RFC without trimming even
more, making it even less readable. I have used Alfred's proposed layout, but I
changed the example to match it. Please: read the example and make sure that
the illustration is correct:
For example, one such proposal would
have two proposal structures. Proposal 1 is ESP with AES-128, AES-
192, and AES-256 bits in CBC mode, with either HMAC-SHA1-96 or
XCBC-96 as the integrity algorithm; Proposal 2 is AES-128 or AES-256
in GCM mode with an 8-octet ICV. Both proposals allow but do not
require the use of ESN. This can be illustrated as:
SA Payload
Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
7 transforms, SPI = 0x052357bb )
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 = 0x35a1d6f2 )
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 )
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
