Hi,
I also agree with Tero and Yaron. It's better to have all defined
notifications listed in one table.
In this case the paragraph immediately preceeding the table must be changed
from:
The values in the following table are only current as of the
publication date of RFC 4306. Other values
I agree with Tero, regardless of the discussion we had on where to put the
tables etc., the document needs to be internally consistent. So we should add
the new notify types that we're defining in *this* document to the notify types
table. Luckily there aren't many.
Thanks,
Yaron
-
There are two places that have very similar text about
INVALID_KE_PAYLOAD: Section 1.3 (for CREATE_CHILD_SA exchange), and
Section 2.7 (for IKE_SA_INIT exchange). Especially the latter seems a
bit strange, everything else in that section applies to
CREATE_CHILD_SA exchanges, too, but this par
Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
notification SHOULD silently delete the Child SA": Is this really
necessary? I think this notification should only occur in cases where
DELETE payload for this Child SA pair has already been sent, and
probably has been processed already
Section 2.25.2, "If a peer receives a request to delete a Child SA
when it is currently rekeying the IKE SA, it SHOULD reply as usual,
with a Delete payload." I noticed this is different from what RFC 4718
recommended, but this is probably OK, given the other text... (but I
still hope this wa
Section 2.14: "only the first 64 bits of Ni and the first 64 bits of
Nr are used in the calculation". This section has two calculations
involving Ni/Nr, but this sentence should only apply to the former.
Suggested rephrasing: "the calculation" -> "when calculating SKEYSEED
(but all bits are us
Section 2.8, sentence: "Note that, when rekeying..." This is in
wrong place; the rest of this paragraph is about IKE_SA rekeying, so
it should be moved to the previous paragraph.
[[ Tero noted this as well, but Paul disagreed, saying that the placement
was correct. This needs to be resolved.
Section 2.23, paragraph starting: "An initiator can float..." needs
some clarifications. Probably "UDP encapsulation/encapsulated" should
be "UDP encapsulation of ESP/UDP-encapsulated ESP" (since at other
places, the document also talks about IKE packets being UDP
encapsulated).
--Paul Hoffm
Section 1.5 doesn't read well, and needs a rewrite. Pasi can
provide text once the substantial issue re: INVALID_IKE_SPI
is decided.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/
Section 2.23.1: If the responder doesn't find SPD entry for
transport mode with the modified traffic selectors, and does a lookup
with the original selectors, if it finds an entry for transport mode,
can it use it? (And would that screw up the initiator processing of
the reply? Unfortunately,t
One of the differences between RFC 4306 and the IKEv2bis draft is in
Section 2.17, Generating Key Material for Child SAs. Appendix E.2 of the
IKEv2bis draft indicates the following:
In Section 2.17, removed "If multiple IPsec protocols are negotiated,
keying material is taken in the order in
Section 1.5: I noticed the 1st paragraph nowadays (well, since -00 of the WG
draft) allows sending INVALID_IKE_SPI notification inside an existing IKE_SA.
This contradicts a MUST NOT in RFC 4306, and I'm not sure if it really brings
any benefits?
--Paul Hoffman, Director
--VPN Consortium
__
Another big thank you for doing this review. I have incorporated everything
other than the following.
--
Also the bullet
- Store the original traffic selector IP addresses as real source
and destination address in case w
All of these are fine; done.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
I'm doing a yet another full review pass over the whole document (not
just diff as I've usually done; to find issues/inconsistencies that
diffs wouldn't necessarily show). So far, I've covered Sections 1
and 2.
Substantial comments:
- Section 1.5: I noticed the 1st paragraph nowadays (well, sin
- Abstract: "It replaces..." Here "it" seems to refer to "IKE", which
isn't correct; it should refer to "This document". This could be fixed
by e.g. switching the first and second sentence, or changing "it" to
"This document".
- Section 1.2: s/IKE_INFORMATIONAL/INFORMATIONAL/
- Section 1.4, 3rd p
Here is the final part of my comments.
--
In section 2.23.1 there is extra "the":
It can have multiple traffic
selectors if it has, for example, multiple port ranges that it wants
to negoti
I agree. This was also noted in
http://www.rfc-editor.org/errata_search.php?rfc=4718
Best regards,
Pasi
(not wearing any hats)
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of ext Paul Hoffman
> Sent: 17 January, 2010 18:07
> To: IPsecme W
Hi
On Jan 18, 2010, at 12:48 PM, Toshihiko Tamura wrote:
> Hi, I want to ask about simultaneous Child SA rekeying
> at section 2.8.1 in IKEv2bis.
>
> I'm sure it is convenient to support this function,
> but why is current IKEv2bis draft saying this fucntion
> as SHOULD?
> -
Hi, I want to ask about simultaneous Child SA rekeying
at section 2.8.1 in IKEv2bis.
I'm sure it is convenient to support this function,
but why is current IKEv2bis draft saying this fucntion
as SHOULD?
---
If redundant SAs are created though such a collision, the SA
c
20 matches
Mail list logo
