[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ESP Draft

Hello Joseph,

That was quick :-).  Thank you for the review/feedback.  Responses 
below...  Please let us know if you have further questions/comments.

Karen

>Page 8, Section 2 -
>(see Section ?? below)
>
>3.3.2.2?

	Yes.

>Page 12, Section 2.2.1 -
>See Section ?? for processing details.
>
>3.3.2.2?

	Yes.

>Page 14, Section 2.4 -
>
>"           o For the purpose of ensuring that the bits to be encrypted
>              are a multiple of the algorithm's blocksize (first bullet
>              above), the padding computation applies to the Payload Data
>              exclusive of any IV, but including the ESP trailer
>              fields. If a combined algorithm mode requires transmission
>              of the SPI and Sequence Number to effect integrity, then
>              these data items, and any associated, ICV-equivalent data,
>              are included in the computation of the pad length. (If the
>              ESN option is selected, the high order 32 bits of the ESN
>              also would enter into the computation, if the combined mode
>              algorithm requires their transmission for integrity.)"
>
>The reference to SPI and Sequence Number above are for replicated
>transmission?  If so, perhaps this could be mentioned.

	Good point.  We'll add this.

>Page 17, Section 3.1.1 -
>
>"Destination options extension header(s) could appear
>    before, after, or both before and after the ESP header depending on
>    the semantics desired"
>
>Just a question I've had for a while, is there an advantage to allowing the
>destination options to come before the ESP header?

	Just to be sure I'm using before/after the same way that
	you are :-)... If an IP packet has the following fields:

                      <BEFORE>                         <AFTER>
         orig IP hdr, dest opts, routing hdr, ESP hdr, dest ops, etc.

	If the destination options come BEFORE then they will be
	used as the packet travels along the path of the SA. In
	the example above, there is a routing extension header
	for source routing (say from A to B to C to D.) The
	destination options in the BEFORE location would be
	processed at B, and if the semantics required, the
	destination options would be passed along and processed
	at C, etc.  But the semantics might also cause them to
	be processed only at B.

	If the destination options come AFTER then they will be
	applied after the packet has arrived at the endpoint of
	the SA and the IPsec header has been processed. These
	would be options that would apply to a host, e.g., ones
	indicating that the packet is a jumbogram. While the
	"BEFORE" ones won't be protected by ESP, there's no way
	to apply the internal "AFTER" ones along the packet's
	path (they would typically be encrypted, etc.)

>Page 22, Section 3.3.2.1 -
>
>"           2. adds any necessary padding Ï Optional TFC padding and
>               (encryption) Padding"
>
>Non-text character.

	Oops -- should have been a "--".

>Page 23. Section 3.3.2.2 -
>
>"           2. adds any necessary paddingÏincludes optional TFC padding
>               and Padding."
>
>Non-text character,

	Hmm...I need to get Microsoft to stop converting my "--"s to
	hyphens :-).  The non-text character should have been a "--".

>and should there be an (encryption) before the Padding?


	Yes, there should be an "(encryption)" before the "Padding".

	I checked with Steve Kent on the following questions and
	have included his replies below.

>Page 32, Section 5 -
>
>"AES in CBC mode"
>
>128/192/256?

	This is a placeholder for an RFC.  We'll see what the new
	ID from NIST says, and what the WG decides.  I'd suggest
	128 is sufficient as a default.

>
>Page 32, Section 5 -
>
>Should 3DES be required for compatibility with existing implementations?

	The previous version of ESP required DES, not 3DES, so not
	all compliant existing implementations would offer 3DES.
	I agree that, in practice, it is likely to be true that
	most folks do offer 3DES CBC, but making this a mandatory
	mode removes incentive to go to AES CBC, which will be
	faster.  So, I would not recommend including 3DES CBC as
	a mandatory mode.

>
>Page 32, Section 5 -
>
>I saw the IP Storage group is looking at requiring AES in a Counter Mode,
>any word when NIST will have something on this?
>
	You'll have to ask NIST folks when they may have a
	counter mode standard.  We already have several counter
	mode proposals floating around as IDs, and will have to
	select one.  The WG needs to decide if it will be a
	mandatory mode, and thus merit inclusion in this document,
	or if it will be an optional mode and thus not part of
	the ESP spec.