[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: IPsec ESN addendum -- Last Call revisions
Title: Fwd: IPsec ESN addendum -- Last Call
revisions
X-Sender: kseo@po2.bbn.com
Date: Tue, 15 Jul 2003 18:45:19 -0400
To: "Angelos D. Keromytis"
<angelos@cs.columbia.edu>
From: Karen Seo <kseo@bbn.com>
Subject: IPsec ESN addendum -- Last Call revisions
Cc: Barbara Fraser <byfraser@cisco.com>, tytso@mit.edu,
skent@bbn.com,
clynn@bbn.com, kseo@bbn.com
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com /
mimedefang)
Status:
Angelos,
Here are the comments and their status
for the ESN addendum .... Revisions have been made to address
the comments and the changes have been approved by the commenter.
These cover all the tickets for the ESN addendum.
Should I go ahead and submit the revised
draft to the IETF?
Karen
===============================================================================
Commenter: Russ
Housley
Date:
6/12/03 and 7/9/03
Status:
I
believe that since we've made the change Russ
requested on 7/9/03 to remove the sentence that
referred the reader to AH/ESP, that this has been
approved by Russ on 7/9/03
I propose an alternative
Abstract.
The IP Security Authentication Header (AH) and
Encapsulating
Security Payload (ESP) protocols use a sequence
number
to detect replay. This document describes
extensions to the
Internet IP Security Domain of Interpretation (DOI)
for
Internet Security Association and Key Management
Protocol
(ISAKMP) to negotiate the use of traditional 32-bit
sequence
numbers or extended 64-bit sequence numbers for
a
particular AH or ESP
security association.
We
proposed the above paragraph and left in a sentence
that
referred the reader to AH and ESP for a description of
ESN.
Russ replied on 7/9/03:
I do not think you can have references in
the Abstract. I suggest dropping the final
sentence.
So we've changed the
abstract as follows:
From:
This document describes extensions to the Internet IP
Security
Domain of Interpretation for ISAKMP [DOI] that are needed
to
support negotiation of whether or not a Security
Association
will use Extended (64-bit) Sequence Numbers. (See [AH]
and
[ESP] for a description of Extended Sequence
Numbers.)
To:
The IP Security Authentication Header (AH) and
Encapsulating
Security Payload (ESP) protocols use a sequence number
to
detect replay. This document describes extensions to
the
Internet IP Security Domain of Interpretation (DOI) for
the
Internet Security Association and Key Management
Protocol
(ISAKMP). These extensions support negotiation of the
use of
traditional 32-bit sequence numbers or extended 64-bit
sequence
numbers for a particular AH or ESP security
association.
===============================================================================
Commenter: Russ
Housley and David Black
Date:
6/12/03 and 7/9/03
Status:
change approved by Russ on 7/9/03
[Russ Housley 6/12/03
It would be helpful if the IANA
Considerations section indicated the portion of the registry where the
TBD value needs to be assigned.
[David Black 6/16/03
In draft-ietf-ipsec-esn-addendum-01.txt,
the IANA
Considerations section needs to be replaced by text
asking IANA to allocate an "IPSEC Security Association
Attributes" value and using that number to replace
the TBD under the "value" heading in Section 2. It
may be necessary to include text in the IANA
Considerations section saying that this value "is
assigned by the standards action of this RFC" or
something like that.
We've
changed the IANA Considerations section:
From:
This document contains "magic"
numbers to be
maintained by the IANA. No additional values will
be
assigned.
To:
This document contains a "magic" number to be
maintained by
the IANA. No additional class values will be assigned
for
this attribute. Upon approval of this draft for
publication
as an
RFC, IANA is to allocate an IPsec Security Attribute
value
for "Attribute Type". This value is to replace the
TBD
under
the heading "value" in the table in Section 2.
===============================================================================