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

Re: ESP revisions straw poll

>       - The optional IV field will be removed; if an encryption algorithm
> requires an IV, it will be transmitted as the initial portion of the
> ciphertext payload.  The definition of the encryption algorithm as provided
> for use with ESP, will specify the presence (or absence) or an IV, and
> describe its length.  the recent I-Ds on RC5 and CAST adopt this approach
> to algorithm definition.
>
Yes.  This is what we have always wanted.


> I'm still not sure that we have concensus on what to do about the AR
> counter field in ESP.  If authentication is NOT negotiated, then it seems
> somewhat odd to include this field. It would align the start of the payload
> on an 8-byte boundary, though this would not appear to be strictly required
> by IPv6 conventions.  However, if folks rellly want the payload to be
> 8-byte aligned, I'll make the AR counter mandatory, as in AH, even if
> authentication is not selected.  I'm looking for feedback on this, so votes
> are solicited.
>
AR field (called "Sequence Number") should immediately follow the SPI.
Always present, 8-byte aligned.  It should start at 1.  It should always
be incremented by sender, even when authentication is not present.


> Finally, in talking with a couple of active contributors, I've gotten the
> impression that there is support for encryptionless ESP, as defined in the
> current I-D.  The argumemts are that this should be easy to implement
> (since it is just ESP without encryption turned on), it is more efficient
> than AH, and  it is both appropriate and adequate in tunnel mode, as an
> alternative to tunnel mode AH.  So, I'd like to conduct a straw poll on
> this topic too.
>
No.  None of the arguments are compelling.
 - It is not needed, as we already have another mechanism.
 - any added complexity to negotiation adds complexity to implementation
   and testing.
 - the improvement in efficiency is in the measurement noise --
   insignificant.

On the other hand, as has been pointed out previously, we are powerless
to stop someone from creating a "null encryption" transform.  But, it
should not be part of the base specification.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2