> >6) Section 3.13.1, could probably use a little tweaking to replace
> > references to "ICMP" with "ICMP, ICMPv6 and MIPv6". Also, the
> > paragraph containing "This document does not specify how to
> > represent the 'MH Type' field ..." actually goes on to specify
> > just that.
>
> Disagree. The WG has not even begun to think about ICMPv6 and MIPv6,
> so saying anything could lead readers to make assumptions that could
> end badly.
But RFC 4301 already specifies this in section 4.4.1.1. Given this, I
think it's incorrect to treat this as unspecified in ikev2bis:
* If the Next Layer Protocol is a Mobility Header, . . .
For IKE, the IPv6 Mobility Header
message type (MH type) is placed in the most significant
eight bits of the 16-bit local "port" selector.
* If the Next Layer Protocol value is ICMP, . . .
For IKE, the message type is placed in the most significant 8
bits of the 16-bit selector and the code is placed in the
least significant 8 bits. . . .
It's less clear that this addresses ICMPv6 than MIPv6, but but elsewhere
in the document "ICMP" is explicitly used in a generic sense, and I think
we're on pretty good ground for both. I'm aware of at least one
implementation other than ours that uses both MH type and ICMPv6 type/code
in this fashion in IKEv2.
I'd be willing to work on alternative text for 3.13.1 if others agree,
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From:
Paul Hoffman <paul.hoff...@vpnc.org>
To:
Scott C Moonen/Raleigh/i...@ibmus
Cc:
"ipsec@ietf.org" <ipsec@ietf.org>
Date:
12/15/2009 01:55 PM
Subject:
Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes,
IKEv2-bis!)
At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>1) There are excessive spaces on the second lines of these list items in
section 2.23:
Fixed.
>2) In section 3.3, this sentence: "If an algorithm that combines
encryption and integrity protection is proposed, it MUST be proposed as an
encryption algorithm and an integrity protection algorithm MUST NOT be
proposed." seems to apply to all protocols, including IKE, and it is more
strict than what we'd agreed to for ticket #122. It is also more strict
than the "MAY" in section 3.3.3. Speaking of ticket #122, the updated
text for that ticket is somehow missing in this draft.
#122 is being fixed in the next draft, not the current draft. In it, I
removed the sentence you have a problem with.
>3) In section 3.6: "Certificate payloads SHOULD be included in an
exchange if certificates are available to the sender unless the peer has
indicated an ability to retrieve this information from elsewhere using an
HTTP_CERT_LOOKUP_SUPPORTED Notify payload." This sentence is incoherent
-- I think if the HTTP_... notify was sent you'd still include a
certificate payload, it just wouldn't hold a certificate. I'm probably
not the best person to suggest alternative wording, but perhaps something
like "Certificate payloads SHOULD be used to send entire certificates if
they are ..."
This has been in the document for quite a while. If it is important to
you, please open a new ticket for it and start a thread.
>4) Section 3.10.1 -- we should remember to remove "{{ Demoted the SHOULD
}}" before publication.
Yarrgh. So much for my regexps. Removed.
>5) Section 3.13.1, extraneous capitalization:
>
> o Selector Length - Specifies the length of this Traffic Selector
> Substructure including the header.
> ^
Fixed.
>6) Section 3.13.1, could probably use a little tweaking to replace
references to "ICMP" with "ICMP, ICMPv6 and MIPv6". Also, the paragraph
containing "This document does not specify how to represent the 'MH Type'
field ..." actually goes on to specify just that.
Disagree. The WG has not even begun to think about ICMPv6 and MIPv6, so
saying anything could lead readers to make assumptions that could end
badly.
>7) Section 3.14, "The Encrypted Payload, if present in a message, MUST be
the last payload in the message. Often, it is the only payload in the
message." Out of curiosity, do we know of any cases where this payload is
not the only payload in the message? It strikes me as odd to allow for
some payloads prior to this one to be integrity protected but not
encrypted. I suppose since RFC 4306 allows it we don't have a lot of
wiggle room here.
Exactly. We don't need to prohibit it, just cast aspersions on it.
>8) Section 4, "Every implementation MUST be capable of responding to an
INFORMATIONAL exchange, but a minimal implementation MAY respond to any
INFORMATIONAL message with an empty INFORMATIONAL reply." Is that true
even if the INFORMATIONAL request contained a Delete payload for a Child
SA?
Opened as Issue #128, on which I will start a new thread.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
