[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ESP revisions straw poll
No Optional IV. IV is included in payload. A good model now since
we don't do varied keys a la Hughes anymore.
Replay field always in the packet, always sent, used by receiver or not.
Aligns the packet, fewer options, yada yada yada...
Replay window size is irrelevant.
No encryptionless ESP. Not enough gain (don't do a few byte moves/clears)
for the complexity of another option. If we're going to do this, bag AH
altogether and just make the MAC cover the header in ESP, as Dan, I think
suggested.
I believe this is what we agreed on in Memphis.
-Rob
-----Original Message-----
From: Stephen Kent [SMTP:kent@bbn.com]
Sent: Tuesday, May 13, 1997 6:06 PM
To: ipsec@tis.com
Subject: ESP revisions straw poll
Folks,
In an effort to reach closure on the suggested changes to the latest ESP
spec, I suggest the following revision, in addition to my earlier message
about authenticationless ESP:
- 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.
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.
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.
Steve