[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: replay field size
--- On Mon, 10 Feb 1997 17:05:26 -0800 Rob Adams <adams@cisco.com> wrote:
> 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 ..."
The document was gone from the WG and into the IESG's hands
prior to any of the comments that you cite.
> 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 notes from you, CJ Lee, and more recently Naganand
and Roy were all _after_ the IESG had already
approved the draft for Proposed Standard RFC.
At that point, the document was in the hands of the IESG,
not within the jurisdiction of the co-chair(s).
The reason for the delayed publication is that the
RFC Editor has a very long latency between approval
and publication just now (which I'm told is being fixed
so that the latency will diminish in future).
> The technical merit for doing a 64 bit replay field?
A 64-bit replay field permits longer times between rekey
intervals. This can be useful if one has a strong algorithm.
If one has a weak algorithm, a shorter time between rekey
intervals might be preferable. Replay size and rekey intervals
are not entirely unrelated. It is up to the WG to
decide whether the benefit/cost ratio makes sense.
Let me also specifically disclaim that the 64-bit replay
or the variable-size replay was my idea. Neither was my
idea or my proposal It was proposed by someone else.
> It seems to me that the process here is broken,
> and I don't know what to do about it.
Talk with either of the co-chairs and/or
the Security AD, Jeff Schiller <jis@mit.edu>.
Within reason, I'm happy to telephone people within
the US/Canada if provided with a time and phone number
to telephone and a topic.
Alternately, one could raise this as a matter for the
POISED WG to take up in revising the process documents.
> 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.
By your count, there were 4 complaints to the list
in a working group having something like 70 participants.
This is not a large percentage. This is one reason why
it IS important for people to speak up on the list so
that the consensus is readily clear right away. When
few people comment either way on any issue, it can
be very difficult to evaluate where consensus lies.
> It think that a lot of people implementing the
> transforms will be in this boat. This shouldn't
> have made it to last call.
Last Call is a mechanism for people to raise objections
to documents moving forward. Not all Last Calls go
forward; some fail, including some in this WG. It
is very very important that people speak up during
the Last Call period, not afterwards. One voice
of complaint to the WG list during a Last Call
does not represent a clear consensus. It is also
important to note that Last Call comments aren't
required to be sent to the list. Unicast comments
to the Chairs during WG Last Call do get considered
as well. I don't recall many comments during either
of the AH HMAC WG Last Calls.
There are 2 separate Last Calls before a standards-track
document goes out as RFC from a Working Group. The first
is done by the WG Chair(s) at the point the chair(s)
believe there is probably rough consensus within
WG members that a document should advance to standards-
track RFC.
If that proves to be true, then the chair(s) pass the
document (I-D) on to the appropriate IESG Area
Director for their review and for the review of
the IESG as a whole. The IESG holds a formal
IETF Last Call before they vote (yes, the IESG
formally votes on each I-D).
Based on input received by the IESG (often privately,
not necessarily from any mailing list), a draft
can change after IESG Last Call and prior to
publication. In many cases, changes happen --
usually for editorial reasons.
> 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?
Talk with the IESG, it was their Last Call that
was announced on 7 August 1996.
By the way, another revision that happened is that
AH HMAC SHA-1 became elective-to-implement because
the IESG objected to having both AH HMAC MD5 and
AH HMAC SHA-1 as mandatory-to-implement. This
fact was also reflected in the revised I-Ds that
went out last Fall and hasn't been a secret of any
sort.
In some cases, documents change as a result of WG
Last Call before proceeding to IETF Last Call.
In those cases, new I-Ds are issued online and
announced to the IETF list and normally to the
WG list as well so that people know the drafts
have changed. Once a document is in the IESG's
hands, it is out of the hands of the WG chair(s).
Just a guess, but if this was bothersome, the closed
room process by which the IPv6 spec came out of thin air
(IPv6 being not exactly any of the IPng proposals on
the table at the time) must have also been fairly
annoying to you.
> 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.
Well, the IETF doesn't officially "vote", but it does
seems constructive to have a Straw Poll on this to try
to put it to bed.
If people would please send email to me <rja@inet.org> and
Paul Lambert <palamber@us.oracle.com> on this, we'll try
to settle it now.
It is not a requirement that one be an implementer to
participate in the straw poll, but it is a requirement
that one be an active member of the IPsec WG. Attendance
at IETF meetings is not required, though that certainly
does indicate activity.
While we're at it, it also seems like a good time to measure
the consensus on the matter of SHA-1 truncation. Hugo
has proposed trucating the SHA-1 output to 128 bits from
160 bits for use with AH. There wasn't much discussion on
this on the list, thought Hugo raised the question at
the last IETF meeting.
The questions are:
Should AH and ESP both have a fixed size replay counter ? (Yes/No/Don't Care)
If they have a fixed size counter, what size should it be? (32 bits/64 bits)
Should SHA-1 output be truncated to 128 bits from 160 bits ? (Yes/No/Don't Care)
Please send your response within the next week. Please DO send
a response so that consensus is crystal clear. We need to
resolve this issue so that Steve Kent's documents can be
edited accordingly. Paul or I will post a summary about a
week from now.
Note that if changes are made, it could easily take another
4-6 months for a revised RFC to appear online after IESG approval.
Also, the revised drafts will need to go through WG Last Call
again. I don't think any of these are problems, but I don't
want people to be surprised and feel like they need to send
out heated email. :-)
Best wishes,
Ran
rja@inet.org
Follow-Ups:
References: