[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ipsec] Proposed changes to IKEv2 based on IESG comments
The following are the IESG comments on IKEv2 annotated with what I did
to address them in the IKEv2 spec. In most cases, the needed correction
or clarification was obvious. But in some cases, I had to guess what to
do (or explain why I believed no action was necessary). In one case (3rd item
under controversial - IRAC/IRAS with IPv6 - I don't know what to do and
need guidance). I'm posting this to solicit objections, feedback, and
ideas.
--Charlie
********MOST LIKELY TO BE CONTROVERSIAL********
>2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918
>addresses.
RFC3330 reserves addresses of the form 192.0.2.0/24 for examples in
documentation. Unfortunately, negotiation of traffic selectors requires
specification of two subnets. They are currently taken from 10.*, which is
reserved for local use. While in theory, on might divide 192.0.2.0 into
multiple subnets, this is likely in practice to be confusing.
>The IANA considerations seem sparse, and I hope the wg is prepared
>to work with IANA and the designated expert on this, especially in
>setting up the process for creating a new registry when a new transform
>type is registered.
There is a separate IANA considerations document with the initial registry,
but I'm not sure what more can or should be said about the modification
process. In practice, I do not expect that new transform types will be
created.
>In reading this draft, I am concerned about whether the IPv6
>addressing model that is described in Section 2.19 and 3.15 has been fully
>thought through.
>
>The CFG_REQUEST functionality that is described is somewhat in
>the style of PPP's IPCPv4, in that a particular address can be assigned,
>along with IP-layer parameters such as the DNS and WINS server addresses.
>
>However, for PPP IPCPv6, a different route was taken; only the
>Interface-Id is negotiated with mechanisms such as RS/RA used to obtain
>the prefix and upper-layer configuration handled by
>existing mechanisms such as DHCPv6. This allows configuration mechanisms
>to be leveraged across interface types.
>
>I'm concerned that the implications of the IPv6 configuration mechanisms
>defined in IKEv2 haven't been well thought through; the examples seem
>mostly focussed on IPv4.
>
>For example, the document contains a number of oddities -- it defines how
>to configure an IPv6 NetBios Name Server, even though NetBIOS is not
>supported for IPv6; yet another mechanism is defined for configuring an
>IPv6 DNS server; the draft allows a host to obtain *both* an address and
>a prefix, as well as to obtain the address of a DHCP server, etc.
>
>Note that a number of comments were posted to the IPSEC list about these
>issues, but they seem to have been ignored.
It seems quite likely that the design of IPv6 configuration mechanisms
in the IRAC/IRAS case was an afterthought based on modifying IPv4. I could
not find the comments on the IPSEC list. I tried reading the IPv6 DHCP
spec for guidance, but it wasn't obvious how to resolve this. Is there
someone out there with IPv6 expertise who can help?
**********ALL CHANGES**********
IETF I-D Tracker v1.0 --To: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-ipsec-ikev2-14.txt to Proposed Standard
--------
Evaluation for draft-ietf-ipsec-ikev2-14.txt can be found at
https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag=7977&rfc_flag=0
Last Call to expire on: 2004-04-12
Please return the full line with your position.
Yes No-Objection Discuss Abstain
Harald Alvestrand [ ] [ X ] [ ] [ ]
Steve Bellovin [ ] [ ] [ X ] [ ]
Bill Fenner [ ] [ X ] [ ] [ ]
Ted Hardie [ ] [ X ] [ ] [ ]
Scott Hollenbeck [ ] [ X ] [ ] [ ]
Russ Housley [ ] [ ] [ X ] [ ]
David Kessens [ ] [ ] [ X ] [ ]
Allison Mankin [ ] [ X ] [ ] [ ]
Thomas Narten [ ] [ X ] [ ] [ ]
Jon Peterson [ ] [ X ] [ ] [ ]
Margaret Wasserman [ ] [ ] [ X ] [ ]
Bert Wijnen [ ] [ X ] [ ] [ ]
Alex Zinin [ ] [ X ] [ ] [ ]
2/3 (9) Yes or No-Objection opinions needed to pass.
DISCUSSES AND COMMENTS:
======================
Harald Alvestrand:
Comment:
Reviewed by Scott Brim, Gen-ART.
Only minor issues found, these have been forwarded to the AD.
>Steve Bellovin:
>
>Discuss:
>Define SA. Define -- not just expand -- "IKE SA". What is one?
At first mention of SA (in introduction), added reference to RFC2401bis
for definitions.
>2.7: The acronym SA is overloaded -- it's being used to refer to a concept
>as well as to a payload containing proposals for the concept.
SA refers to Security Association except as part of the phrase "SA payload".
Found and fixed 3 places where that rule wasn't followed.
>2.15: This section denounces passwords, but the only mandatory input
>mechanism for shared secrets is an ASCII string. It MUST support hex input
Changed hex input to be a MUST.
>2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918
>addresses.
RFC3330 reserves addresses of the form 192.0.2.0/24 for examples in
documentation. Unfortunately, negotiation of traffic selectors requires
specification of two subnets. They are currently taken from 10.*, which is
reserved for local use. While in theory, on might divide 192.0.2.0 into
multiple subnets, this is likely in practice to be confusing.
>3.1: The text about ignoring things from the UDP header beyond the ports
>and addresses is a bit odd, since that's about all there is in it....
Changed text to "Information from the beginning of the packet through the
UDP header is largely ignored except...". (Meaning that this information is
not cryptographically protected and hop counts, IP options, etc. are ignored)
>3.3.3: What are ESN and INTEG?
Added the abbreviations ENCR, PRF, INTEG, D-H, and ESN to the transform
type value table in section 3.3.2.
>3.3.5: RC4 also requires a key length
Removed reference to RC4, which is not profiled for use with IPsec and
probably never will be.
>3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems. Support for
>ID_IPV4_ADDR is only required for IPv4-capable systems
ok.
>3.6: What URL types must be supported? HTTP? HTTPS? FTP? MAILTO?
None are MUST. Clarified that URL w/HTTP is SHOULD.
>5: A discussion of fragmentation attacks needs to be here. The bare mention
>of [KPS03] earlier is insufficient.
Added a paragraph to section 5 stating the problem, recommending use of
"Hash and URL" encoding, and referring again to [KPS03].
>Appendix B doesn't list DH Group 5, but it's mentioned in Section 5.
Group 5 is defined in [ADDGROUP] and was removed from Appendix B for
that reason.
>Comment:
>Should there be discussion of requirements for maximum UDP packet size (after
>fragment reassembly)?
See comments below under Margaret Wasserman.
>On the number of very closely-spaced packets that the
>system must be capable of receiving? (There have been reports of
>interoperability problems in the past because of this issue.)
IKEv2 is a request/response protocol, so with the exception of fragmented
packets there should be no congestion issues.
>Ted Hardie:
>
>Comment:
>In Section 2.23:
>
> If the NAT_DETECTION_DESTINATION_IP payload received does not
> match the hash of the destination IP and port found from the IP
> header of the packet containing the payload, it means that this
> end is behind NAT (i.e., the original sender sent the packet to
> address of the NAT box, which then changed the destination address
> to this host). In this case the this end should start sending
> keepalive packets as explained in [Hutt04].
>
>Two nits: "the this end should" should probably be "this end";
Changed to "this end SHOULD"
>the parenthetical
>section seems confusing and should probably be re-worded or perhaps
>dropped (as what to do is clear without it).
Dropped.
>Just below, NAT-T is used without explanation in the text; expansion may be
>useful.
Changed to NAT traversal.
>In 3.3.4 (Mandatory transform IDs), the draft says:
>
>
> It is likely that IANA will add additional transforms in the future,
> and some users may want to use private suites, especially for IKE
> where implementations should be capable of supporting different
> parameters, up to certain size limits. In support of this goal, all
> implementations of IKEv2 SHOULD include a management facility that
> allows specification (by a user or system administrator) of Diffie-
> Hellman parameters (the generator, modulus, and exponent lengths and
> values) for new DH groups. Implementations SHOULD provide a
> management interface via which these parameters and the associated
> transform IDs may be entered (by a user or system administrator), to
> enable negotiating such groups.
>
> All implementations of IKEv2 MUST include a management facility that
> enables a user or system administrator to specify the suites that are
> acceptable for use with IKE. Upon receipt of a payload with a set of
> transform IDs, the implementation MUST compare the transmitted
> transform IDs against those locally configured via the management
> controls, to verify that the proposed suite is acceptable based on
> local policy. The implementation MUST reject SA proposals that are
> not authorized by these IKE suite controls.
>
>reading these together, it was not clear to me whether it was considered
>acceptable for an implementation to be configured such that there
>were none of the mandatory transforms in its permitted set. I eventually
>came to the conclusion that this was permitted (i.e., only private suites
>in use), but I feel the document might benefit from making the point explcit
>here, one way or the other.
Added clarifying sentence to end of 3.3.4 that mandatory transforms are
mandatory to implement but need not be configured as acceptable to
local policy.
>The IANA considerations seem sparse, and I hope the wg is prepared
>to work with IANA and the designated expert on this, especially in
>setting up the process for creating a new registry when a new transform
>type is registered.
There is a separate IANA considerations document with the initial registry,
but I'm not sure what more can or should be said about the modification
process. In practice, I do not expect that new transform types will be
created.
>Russ Housley:
>
>Discuss:
>
> In section 1.5, the last sentence says: "... it MAY send an Informational
> message without cryptographic protection to the source IP address and port
> to alert it to a possible problem." However, section 1.4 says that
> informational messages "MAY ONLY occur after the initial exchanges and are
> cryptographically protected with the negotiated keys." These are in
> conflict, and one of them needs to be changed to resolve the conflict.
> Also, "MAY ONLY" ought to be changed to "MUST ONLY."
Changed the MAY ONLY to MUST ONLY. Clarified that an informational message
can occur outside of an informational exchange; section 1.5 talks about
such messages. Informational exchanges (section 1.4) MUST ONLY occur within
an IKE_SA.
> In section 2.23, the text says: "IKEv2 can negotiate UDP encapsulation of
> IKE, ESP, and AH packets." Then, in the middle of page 38, the conventions
> for tunneling IKE and ESP over UDP are described. The conventions for AH
> ought to be described too. Further, the IANA registry for port 4500 ought
> to be updated to point to this document. It currently says:
>
> ipsec-msft 4500/tcp Microsoft IPsec NAT-T
> ipsec-msft 4500/udp Microsoft IPsec NAT-T
> # Christian Huitema <Huitema@microsoft.com> March 2002
Section 2.23 was incorrect and reflected some wishful thinking on my
part. Port 4500 was reserved for UDP encapsulation of IKE and ESP
packets. No similar encapsulation for AH has been defined. I corrected
section 2.23 to remove any mention of AH.
> In the 3rd paragraph of section 2.21, the document says: "If the message is
> marked as a response, the node MAY audit the suspicious event but MUST NOT
> respond." How would an implementation respond to a response message?
There is no defined way to respond to a response. That's why responses are
forbidden. Perhaps this statement is unnecessary.
> In section 3.3.2, the table for transform type values needs an entry for
> zero, making it RESERVED.
Done.
> Also in Section 3.3.2, the table for encryption algorithms has some missing
> references. ENCR_AES_CBC ought to refer to RFC 3602, and ENCR_AES_CTR ought
> to refer to RFC 3686.
Done.
> Also in Section 3.3.2, the table of PRFs should replace "PRF_AES_CBC" with
> "PRF_AES128_CBC" in order to match the companion algorithms document.
> Further, it ought to refer to RFC 3664.
Done.
> Also in Section 3.3.2, the last entry in the integrity algorithms table is
> ought to be AUTH_AES_XCBC_96, and it ought to refer to RFC 3566.
Done.
> Also in Section 3.3.2, the Diffie-Hellman groups table should not constrain
> the kinds of groups that might be registered in the future. It ought to
> say: "values 6-13 and 19-1023 are reserved to IANA."
Done.
> In section 3.3, I do not understand the context where ESP or AH would make
> use of D-H. Why is D-H an optional type for ESP or AH?
D-H is an optional type in an SA payload negotiating ESP or AH. If present,
the messages must also contain KE payloads and use the keying material
from this fresh D-H exchange in keying the ESP or AH SAs as specified
in section 2.17.
> In section 3.5, the table needs to say something about values 4, 6, 7,
> and 8. I assume that they are also reserved to IANA.
Done.
> In section 3.10.1, the first table needs an entry for zero, making it
> RESERVED. Further, at the end of the first table, the document ought to
> reserve values 40-1891 (not 39-8191).
Done.
> In section 6, please change the title of the Diffie-Hellman registry
> to "IKEv2 Diffie-Hellman Transform IDs." Again, the point is to avoid
> unduly constraining the kinds of groups that might be registered in
> the future.
Done.
> Also in section 6, the last paragraph would be more clear if is said:
> "Changes and additions to any of these registries are by expert review."
Done.
> Appendix A refers to two Internet Drafts that will never be published.
> These references need to be replaced with a brief summary of the issue.
Replaced the reference to draft-ietf-ipsec-hash-revised-02.txt with
a five word summary.
The reference to the other document on NAT traversal requirements was redundant
with the statement that NAT traversal was folded into IKEv2, so the
reference was removed.
>Comment:
>
> Please spell out the acronym "PFS" the first time it is used.
It was only used twice. In both cases, I changed it to refer to the
optional Diffie-Hellman exchange instead of using the acronym.
> In the 2nd paragraph of section 3.12, the document says: "... i.e., it MUST
> be non-critical." It would be more clear, I think, to say: "the critical
> bit MUST be set to 0." This is discussed elsewhere in the document, but
> stating the value of the bit will make it clearer.
Done.
> In section 3.1, the second-to-last entry in the main table should read
> "RESERVED TO IANA" to match the wording in the rest of the tables.
Done.
> [IKEv2IANA] and [Ker01] are not referenced in the document. Please
> delete these references.
Done.
>David Kessens:
>
>Discuss:
>Comments from the ops directorate:
>
>In reading this draft, I am concerned about whether the IPv6
>addressing model that is described in Section 2.19 and 3.15 has been fully
>thought through.
>
>The CFG_REQUEST functionality that is described is somewhat in
>the style of PPP's IPCPv4, in that a particular address can be assigned,
>along with IP-layer parameters such as the DNS and WINS server addresses.
>
>However, for PPP IPCPv6, a different route was taken; only the
>Interface-Id is negotiated with mechanisms such as RS/RA used to obtain
>the prefix and upper-layer configuration handled by
>existing mechanisms such as DHCPv6. This allows configuration mechanisms
>to be leveraged across interface types.
>
>I'm concerned that the implications of the IPv6 configuration mechanisms
>defined in IKEv2 haven't been well thought through; the examples seem
>mostly focussed on IPv4.
>
>For example, the document contains a number of oddities -- it defines how
>to configure an IPv6 NetBios Name Server, even though NetBIOS is not
>supported for IPv6; yet another mechanism is defined for configuring an
>IPv6 DNS server; the draft allows a host to obtain *both* an address and
>a prefix, as well as to obtain the address of a DHCP server, etc.
>
>Note that a number of comments were posted to the IPSEC list about these
>issues, but they seem to have been ignored.
It seems quite likely that the design of IPv6 configuration mechanisms
in the IRAC/IRAS case was an afterthought based on modifying IPv4. I could
not find the comments on the IPSEC list. I tried reading the IPv6 DHCP
spec for guidance, but it wasn't obvious how to resolve this. Is there
someone out there with IPv6 expertise who can help?
>Margaret Wasserman:
>
>Discuss:
>In general, I think that this is a good piece of work. However,
>there are two issues with this document that should be addressed:
>
>(1) This document uses UDP and includes a retransmission mechanism for
>requests, but it does not indicated that the retransmission timer must
>back off exponentially.
Added to section 2.4:
To be a good network citizen, retransmission times MUST increase exponentially
to avoid flooding the network and making an existing congestion situation
worse.
>(3) This specification does not mandate a minimum supported UDP packet
>size for hosts that
>implement IKEv2. Would the default minimum (556 bytes of UDP payload
>in IPv4) be sufficient? Or should this specification mandate that
>implementations of IKEv2 must support larger UDP packets?
In the simplest use of IKEv2, UDP payload sizes never exceed 340 bytes.
(So an implementation that did not support 340 byte payloads could not
possibly work). There is no theoretical upper bound on the size of a
valid IKEv2 message (except for a 32 bit field for message length).
There will be cases where IKEv2 messages in practice will exceed 556 bytes
(they can contain X.509 certificates, which are commonly bigger than
1024 bytes), but there is no natural number to require of the underlying
UDP implementation.
Added the following to section 2:
While IKEv2 messages are intended to be short, they contain structures with
no hard upper bound on size (in particular, X.509 certificates), and IKEv2
itself does not have a mechanism for fragmenting large messages. IP defines
a mechanism for fragmentation of oversize UDP messages, but implementations
vary in the maximum
message size supported. Further, use of IP fragmentation opens an
implementation to denial of service attacks [KPS03].
IKEv2 implementations SHOULD be aware of the maximum UDP message size
supported and MAY shorten messages by leaving out some certificates or
cryptographic suite proposals if that will keep messages below the maximum.
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec