Hi Paul,

Please see below.

> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoff...@vpnc.org]
> Sent: Saturday, January 23, 2010 3:28
> To: Yaron Sheffer; ipsec@ietf.org
> Subject: Re: [IPsec] Issue #157: Illustrate the SA payload with a
> diagram
> 
> At 11:57 PM +0200 1/22/10, Yaron Sheffer wrote:
> >The text in 3.3 requires "peace of mind" to fully appreciate. A
> diagram might be helpful.
> >
> >Here's a first shot (we'll need to add some descriptive text):
> >
> >                        SA Payload
> >                            |
> >                      ---------------............-
> >                      |             |            |
> >               Proposal #1       Proposal #2   Proposal #n
> >                     ESP           ESP
> >                     SPIx          SPIy
> >                      |             |
> >           ---------------------    --------------------
> >           |                   |             |         |
> >      Transform A        Tranform B    Transform C Transform D
> >          ENCR               AUTH          ENCR       ESN
> >          AES            HMAC-SHA-256    AES-CCM     ESN=1
> >           |
> >   -----------------
> >   |       |       |
> >Attr Ax Attr Ay Attr Az
> >  128     192     256
> 
> In order for this not to be confusing, Transform A should be "ENCR" and
> "AES-CBC", and Transform C needs to (in fact, MUST) have at least one
> attribute specified.
Agree.
> 
> Transform B should be listed as "INTEG", not "AUTH".
Yes.
> 
> Further, is there a good reason for you to have not included an ESN
> transform on Proposal #1? Section 3.3 says "The number of different
> transforms is generally determined by the Protocol. ... ESP generally
> has three: ESN, an encryption algorithm and an integrity check
> algorithm."
According to 3.3.3, ESN is mandatory for ESP and AH. So I should have included 
it.
> 
> Ditto for Proposal #2: is there a good reason for you to not have
> included an INTEG transform?
I was trying to illustrate a combined mode algorithm. May have got it wrong...
> 
> This begs the related question: given that there is no MUST or should
> for what goes into a Proposal, what does an ESP proposal that only has
> an ENCR and INTEG in it mean with respect to what is being proposed for
> ESN? What does an ESP proposal that has only an ENCR and ESN in it mean
> with respect to what is being proposed for INTEG? I see no MUSTs or
> SHOULDs answering this.
3.3.3 says ESN is mandatory. Which means if it is omitted, the recipient will 
reject the proposal.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to