[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ipsec] Proposed changes to IKEv2 based on IESG comments
Charlie, Angelos, are you still using the Issues Tracker ?
>From my quick review,
Issues 100, 103 and 108 are already fixed and closed with IKEv14
Issues 101, 102, 106, 107 are still outstanding because they require the Jan
04 IKEv2 IANA document to be updated.
Issues 112-114 are still open for IKEv14 tracking IESG comments.
Here are the sorted & grouped list of issues not yet closed:
99 Editorial Must Fix Clarification on end-to-end tunnel mode Text Proposed
angelos 2004-04-14.02:24:04 Kaufman
Accepted
94 Editorial Must Fix Fix cert bundle numbering Accepted angelos
2004-03-25.00:41:09 Kaufman
95 Editorial Must Fix Responder SHOULD send AUTH/SAr2/TSi/TSr Accepted
angelos 2004-03-25.00:42:11 Kaufman
96 Editorial Must Fix Clarification on OPAQUE port numbers Accepted angelos
2004-03-25.00:43:10 Kaufman
Pending
101 Editorial Must Fix Inconsistencies between IKEv2 and IANA registry
drafts Pending angelos 2004-04-14.02:26:25 Kaufman
102 Editorial Must Fix How are registries updated ? Pending angelos
2004-04-14.02:26:59 Kaufman
103 Editorial Must Fix XCBC_96 PRF definition Pending angelos
2004-04-14.02:27:37 Kaufman
104 Editorial Must Fix ESN values Pending angelos 2004-04-14.02:28:13
Kaufman
105 Editorial Must Fix ID Payload types Pending angelos 2004-04-14.02:28:48
Kaufman
106 Editorial Must Fix Notification types missing from IANA document
Pending angelos 2004-04-14.02:29:19 Kaufman
107 Editorial Must Fix Traffic selector types reserved space Pending
angelos 2004-04-14.02:29:59 Kaufman
108 Editorial Must Fix Clarification on behavior/detection of responder
being behind NAT (Section 2.23) Pending angelos 2004-06-24.07:04:11 Kaufman
109 Editorial Must Fix Clarification on supporting mandatory algorithms
Pending angelos 2004-06-24.07:07:34 Kaufman
110 Editorial Must Fix Fix/expand/define acronyms and terms Pending angelos
2004-06-24.07:09:59 Kaufman
111 Editorial Must Fix Maximum UDP packet size issues Pending angelos
2004-06-24.07:11:34 Kaufman
112 Editorial Must Fix Editorial nits in version -14 of the draft Pending
angelos 2004-06-24.07:16:14 Kaufman
113 Editorial Must Fix Clarifications on the use of UDP / minimum
requirements Pending angelos 2004-06-24.07:20:24 Kaufman
114 Editorial Must Fix IPv6 addressing model Pending angelos
2004-06-25.06:15:42 Kaufman
91 Technical Must Fix Handling ICMP error messages Pending kseo
2003-10-27.01:43:27 kseo
92 Technical Must Fix Fragmentation handling in tunnel mode Pending angelos
2004-02-24.17:41:26 kseo
97 Editorial Must Fix Security considerations: key length from group 1
Pending angelos 2004-04-14.02:22:13 Kaufman
98 Editorial Must Fix OPAQUE and ANY do not have the same meaning Pending
angelos 2004-04-14.02:22:56 Kaufman
100 Editorial Should Fix CERTREQ processing Pending angelos
2004-04-14.02:25:04 Kaufman
> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]
> On Behalf Of Charlie Kaufman
> Sent: Sunday, July 18, 2004 7:14 PM
> To: ipsec@ietf.org
> Subject: [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=vie
w_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
>
>
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec