[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: replay field size
I agree with Roy here..
I first objected to this in a post to the list on September 26th 1996. Derrell Piper complained in a post on
October 3rd. C. J. Lee posted on 27 Nov. saying, "To me, different replay counter size for different AH/ESP
transforms would definitely complicated an IPsec implementation in terms of storing and using the per session
(SA) replay checking state ..." Ran, you made some argument about alignment (which is irrelevant to replay)
on the 9th of December. You claimed then that you explained your objection on the list, but I couldn't find it in
the digest. Then Roy complained again on the 15th of January. Now Naganand is questioning it.
And I argued with you, Ran, in private mail about this and the need for negotiating replay window size. I also
recall most people implementing it, at least that I knew, questioning a 64 bit replay field.
The only defense of this I found in the digest was by Ran. I don't know of anyone else actually
implementing this who ever thought a 64 bit replay field was a good idea.... Granted my exposure
is limited, but not that limited.
>>Process aside, the technical merit is slight. The amount of code
>>needed for 2 replay sizes is clearly small
This is a matter of opinion and is also irrelevant. Any amount of code added to support a "feature"
that a majority of implementers think is wrong is too much code.
>>Process aside, the technical merit is slight.
The technical merit for doing a 64 bit replay field? Sorry I couldn't resist, but it does lead me to my next point.
It seems to me that the process here is broken, and I don't know what to do about it. When people
complain about an annoyance that has no valid merit that anyone can think of, and the annoyance
goes through anyway, then we have a broken process. And I know I'm going to get flamed for saying
that it is an annoyance, but it is. If you're not implementing this on a 64 bit architecture and you're trying
to share your replay code with ESP, then it is a real pain, plain and simple. It think that a lot of
people implementing the transforms will be in this boat. This shouldn't have made it to last call.
In fact, I have a process question. I found the last call announcement in the archives on for the AH
documents and it was on 7 Aug 96. The document that went to last call was draft-ietf-ipsec-ah-hmac-md5-01.
I happen to have a copy of that document and it has a 32 bit replay field... hmmmm... Then an update
was posted on the 30th of August. This contained the 64 bit replay field. The update said the -02 documents
were based on comments received during last call. A 64 bit replay field was not discussed on the list, and
of course no one complained because it was a 32 bit field as far as we knew.
What do you do if a document goes through revisions like this after last call?
I bet if we took a vote by people implementing the transforms of a 64 bit vs. a 32 bit replay field,
we'd find results different than what is in the documents.
-Rob Adams
Cisco Systems
----------
From: Ran Atkinson[SMTP:rja@inet.org]
Sent: Sunday, February 09, 1997 2:57 PM
To: 'ipsec@tis.com'
Cc: rja@inet.org
Subject: RE: replay field size
--- On Sun, 9 Feb 1997 15:42:07 -0500 Roy Pereira <rpereira@TimeStep.com> wrote:
> Why was RFC2085 (HMAC-MD5 IP Authentication with Replay Prevention)
> released with a 64-bit replay counter if so many of us objected?
Because contrary to your assertions, there were NOT (repeat NOT)
many objections to the 64-bit counter _during WG Last Call_. A very small
number of people do NOT constitute "many".
Process aside, the technical merit is slight. The amount of code
needed for 2 replay sizes is clearly small (evidence some of the
conforming implementations that existed prior to Last Call).
The reason last call exists is to provide a "last" opportunity to
object before things move forward to standards-track status. Input
needs to arrive during the Last Call period, not afterwards.
Participants are expected to remain current with the drafts all the
time, last calls live at least a week so that folks can have a chance
to re-read the draft before it proceeeds. If folks do not take the
time to make their specific issues known to the WG chairs during last
call, that is the choice of those individuals not the fault of the
chair(s).
> Furthermore, why wasn't a generic digest algorithm RFC released
> (HMAC-x Authentication) instead ?
The WG chose to proceed in the way it has. The changes Steve Kent
has proposed would increase the fixed structure to both AH and ESP.
If the WG decides to accept his edited drafts for Draft Standard,
then a different approach can be employed down the road. At this point,
a crucial consideration is avoiding making existing conforming
implementations suddenly non-conforming by issuance of new RFCs.
My understanding has always been that Steve's changes don't make
existing conforming implementations suddenly non-conforming.
> We should be able to just plug in a new cipher algorithm and a new
> digest algorithm without having to re-invent the wheel. Just plug in
> their identifiers and go...
There _is_ more to it than just identifiers. Different algorithms have
different modes and different resulting data sizes and IVs and so forth.
With AH HMAC SHA-1 there was the question raised of using the standard
160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output.
If one truncates, then the method/process of truncation needs to
be openly and clearly specified. Just assigning identifiers will
tend NOT lead to interoperable implementations. Additional structure
to the base specifications will help, but is probably not a panacea.
Ran
rja@Inet.org
Follow-Ups: