Internet Key Exchange (IKEv2) Protocol
draft-ietf-ipsec-ikev2-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
17 | (System) | post-migration administrative database adjustment to the No Objection position for Margaret Wasserman |
2012-08-22
|
17 | (System) | post-migration administrative database adjustment to the Yes position for Steven Bellovin |
2012-08-22
|
17 | (System) | post-migration administrative database adjustment to the No Objection position for David Kessens |
2012-08-22
|
17 | (System) | post-migration administrative database adjustment to the Yes position for Russ Housley |
2005-07-06
|
(System) | Posted related IPR disclosure: Nokia Corporation's statement about IPR claimed in draft-ietf-ipsec-ikev2-17.txt | |
2004-10-04
|
17 | (System) | New version available: draft-ietf-ipsec-ikev2-17.txt |
2004-09-23
|
17 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-09-21
|
17 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-09-21
|
17 | Amy Vezza | IESG has approved the document |
2004-09-21
|
17 | Amy Vezza | Closed "Approve" ballot |
2004-09-21
|
17 | Russ Housley | State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Russ Housley |
2004-09-20
|
16 | (System) | New version available: draft-ietf-ipsec-ikev2-16.txt |
2004-09-17
|
17 | Russ Housley | Note field has been cleared by Russ Housley |
2004-09-16
|
17 | Amy Vezza | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup by Amy Vezza |
2004-09-16
|
17 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman |
2004-09-16
|
17 | Harald Alvestrand | [Ballot comment] Reviewed by Scott Brim, Gen-ART. Only minor issues found. This round's review (on version 15): I'm no IKE expert, but it looks ready … [Ballot comment] Reviewed by Scott Brim, Gen-ART. Only minor issues found. This round's review (on version 15): I'm no IKE expert, but it looks ready to go except for two presentation issues that could be fixed. I don't think they should hold it back -- Harald gets to decide. I suggest "no objection". I'm CCing Charlie Kaufman. First, as said before on previous versions, I think the "Bob and Alice" stuff is not clearer than simply using "initiator" and "responder" everywhere, and in fact gets in the way. The document is still readable, but one has to translate Bob and Alice into initiator and responder, so they are not helpful. Second, a nit -- this text: Transform Used In Type RESERVED 0 Encryption Algorithm (ENCR) 1 (IKE and ESP) Pseudo-random Function (PRF) 2 (IKE) Integrity Algorithm (INTEG) 3 (IKE, AH, and optional in ESP) Diffie-Hellman Group (D-H) 4 (IKE and optional in AH and ESP) Extended Sequence Numbers (ESN) 5 (Optional in AH and ESP) RESERVED TO IANA 6-240 PRIVATE USE 241-255 could use better formatting. |
2004-09-15
|
17 | Margaret Cullen | [Ballot discuss] My exponential backoff issue was resolved, however I don 't think that my other issue has been fully addressed. The draft now says: … [Ballot discuss] My exponential backoff issue was resolved, however I don 't think that my other issue has been fully addressed. The draft now says: 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. How are implementations supposed to know the UDP message size? Does this mean that IKEv2 nodes SHOULD implement PMTU discovery so that they can know what size packet will reach the other end without fragmentation. The document states that there can be a DoS risk if fragmentation occurs. I don't understand why that is the case or how serious of a risk it is, so I am not sure how important it is (or isn't) to avoid fragmentation. However, there certainly are options available to avoid IP-layer fragmentation if that poses a risk. Is there a reason why that isn't considered to be worth the trouble? |
2004-09-15
|
17 | Margaret Cullen | [Ballot discuss] My exponential backoff issue was resolved, however I don 't think that my other issue has been fully addressed. The draft now says: … [Ballot discuss] My exponential backoff issue was resolved, however I don 't think that my other issue has been fully addressed. The draft now says: 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. How are implementations supposed to know the UDP message size? Does this mean that IKEv2 nodes SHOULD implement PMTU discovery so that they can know what size packet will reach the other end without fragmentation. The document states that there can be a DoS risk if fragmentation occurs. I don't understand why that is the case or how serious of a risk it is, so I am not sure how important it is (or isn't) to avoid fragmentation. However, there certainly are options available to avoid IP-layer fragmentation if that poses a risk. Is there a reason why that isn't considered to worth the trouble? |
2004-09-13
|
17 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Yes from Discuss by Russ Housley |
2004-09-02
|
17 | Amy Vezza | Telechat date was changed to 2004-09-16 from 2004-09-02 by Amy Vezza |
2004-09-02
|
17 | Russ Housley | [Ballot discuss] In 2002, the working group decided not to pursue elliptic curves. Hilarie Orman made several presentation advocating them; her slides are in the … [Ballot discuss] In 2002, the working group decided not to pursue elliptic curves. Hilarie Orman made several presentation advocating them; her slides are in the minutes. However, the IPR concerns associate with elliptic curves lead the working group to classic Diffie-Hellman. Yet, two elliptic curve groups are still included in the document. This seems to contradict the working group decision. I suggest the removal of the elliptic curve groups from Appendix B. |
2004-09-02
|
17 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Discuss from Yes by Russ Housley |
2004-08-31
|
17 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Yes from Discuss by Russ Housley |
2004-08-25
|
17 | David Kessens | [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens |
2004-08-24
|
17 | Russ Housley | Placed on agenda for telechat - 2004-09-02 by Russ Housley |
2004-08-24
|
17 | Russ Housley | [Note]: 'Back on agenda to see if the new version clears the remaining DISCUSS positions.' added by Russ Housley |
2004-08-23
|
17 | Steven Bellovin | [Ballot Position Update] Position for Steve Bellovin has been changed to Yes from Discuss by Steve Bellovin |
2004-08-16
|
15 | (System) | New version available: draft-ietf-ipsec-ikev2-15.txt |
2004-08-14
|
17 | Russ Housley | State Changes to IESG Evaluation::AD Followup from IESG Evaluation::Revised ID Needed by Russ Housley |
2004-06-24
|
17 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2004-06-24
|
17 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Amy Vezza |
2004-06-24
|
17 | Margaret Cullen | [Ballot discuss] In general, I think that this is a good piece of work. However, there are two issues with this document that should be … [Ballot 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. (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? |
2004-06-24
|
17 | Thomas Narten | [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten |
2004-06-24
|
17 | David Kessens | [Ballot discuss] Comments from the ops directorate: In reading this draft, I am concerned about whether the IPv6 addressing model that is described in Section … [Ballot 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. |
2004-06-24
|
17 | David Kessens | [Ballot Position Update] Position for David Kessens has been changed to Discuss from No Objection by David Kessens |
2004-06-24
|
17 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2004-06-24
|
17 | Margaret Cullen | [Ballot discuss] I have three concerns about this document: (1) This document uses UDP and includes a retransmission mechanism for requests, but I couldn't find … [Ballot discuss] I have three concerns about this document: (1) This document uses UDP and includes a retransmission mechanism for requests, but I couldn't find anything that indicated that the retransmission timer must back off exponentially. (2) I'm not sure if this is a real concern or not, but... This document defines a UDP-based prototol that includes at least one mechanism (hash based encoding of certificates) to avoid the need for IP fragmentation. However, there are many other IKEv2 payloads defined that are variable length and could be quite long. Furthermore, there is the possibility of IKEv2 packets containing multiple payloads. Given the statement that the use of IP fragmentation opens up the possibility of DoS attacks, did the authors consider any IKE-level mechanisms to avoid fragmentation, such as limiting the overall packet size? Or compressing the payloads in some way? (3) Should this specification mandate a minimum supported UDP packet size for hosts that implement IKEv2? These last two are really just questions, so if they have already been discussed in the WG or don't apply for some reason, I'll remove my discuss. |
2004-06-24
|
17 | Margaret Cullen | [Ballot discuss] I'm not sure if this is a real concern or not, but... This document defines a UDP-based prototol that includes at least one … [Ballot discuss] I'm not sure if this is a real concern or not, but... This document defines a UDP-based prototol that includes at least one mechanism (hash based encoding of certificates) to avoid the need for IP fragmentation. However, there are many other IKEv2 payloads defined that are variable length and could be quite long. Furthermore, there is the possibility of IKEv2 packets containing multiple payloads. Given the statement that the use of IP fragmentation opens up the possibility of DoS attacks, did the authors consider any IKE-level mechanisms to avoid fragmentation, such as limiting the overall packet size? Or compressing the payloads in some way? Also, should this specification mandate a minimum supported UDP packet size for hosts that implement IKEv2? These are really just questions, so if they have already been discussed in the WG or don't apply for some reason, I'll remove my discuss. |
2004-06-24
|
17 | Margaret Cullen | [Ballot discuss] I'm not sure if this is a real concern of not, but... This document defines a UDP-based prototol that includes at least one … [Ballot discuss] I'm not sure if this is a real concern of not, but... This document defines a UDP-based prototol that includes at least one mechanism (hash based encoding of certificates) to avoid the need for IP fragmentation. However, there are many other IKEv2 payloads defined that are variable length and could be quite long. Furthermore, there is the possibility of IKEv2 packets containing multiple payloads. Given the statement that the use of IP fragmentation opens up the possibility of DoS attacks, did the authors consider any IKE-level mechanisms to avoid fragmentation, such as limiting the overall packet size? Or compressing the payloads in some way? Also, should this specification mandate a minimum supported UDP packet size for hosts that implement IKEv2? These are really just questions, so if they have already been discussed in the WG or don't apply for some reason, I'll remove my discuss. |
2004-06-24
|
17 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to Discuss from Undefined by Margaret Wasserman |
2004-06-24
|
17 | Margaret Cullen | [Ballot Position Update] New position, Undefined, has been recorded for Margaret Wasserman by Margaret Wasserman |
2004-06-23
|
17 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
2004-06-10
|
17 | Margaret Cullen | State Changes to IESG Evaluation - Defer from IESG Evaluation by Margaret Wasserman |
2004-06-10
|
17 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2004-06-10
|
17 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2004-06-10
|
17 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2004-06-10
|
17 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2004-06-09
|
17 | Harald Alvestrand | [Ballot comment] Reviewed by Scott Brim, Gen-ART. Only minor issues found, these have been forwarded to the AD. |
2004-06-09
|
17 | Harald Alvestrand | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand |
2004-06-09
|
17 | Russ Housley | [Ballot comment] Please spell out the acronym "PFS" the first time it is used. In the 2nd paragraph of section 3.12, the document says: … [Ballot comment] Please spell out the acronym "PFS" the first time it is used. 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. 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. [IKEv2IANA] and [Ker01] are not referenced in the document. Please delete these references. |
2004-06-09
|
17 | Russ Housley | [Ballot discuss] In section 1.5, the last sentence says: "... it MAY send an Informational message without cryptographic protection to the source IP address … [Ballot 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." 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 March 2002 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? In section 3.3.2, the table for transform type values needs an entry for zero, making it RESERVED. 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. 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. 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. 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." 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? 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. 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). 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. 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." 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. |
2004-06-09
|
17 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Discuss from Yes by Russ Housley |
2004-06-09
|
17 | Steven Bellovin | [Ballot discuss] Define SA. Define -- not just expand -- "IKE SA". What is one? 2.7: The acronym SA is overloaded -- it's being used … [Ballot discuss] Define SA. Define -- not just expand -- "IKE SA". What is one? 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. 2.15: This section denounces passwords, but the only mandatory input mechanism for shared secrets is an ASCII string. It MUST support hex input 2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 addresses. 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.... 3.3.3: What are ESN and INTEG? 3.3.5: RC4 also requires a key length 3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems. Support for ID_IPV4_ADDR is only required for IPv4-capable systems 3.6: What URL types must be supported? HTTP? HTTPS? FTP? MAILTO? 5: A discussion of fragmentation attacks needs to be here. The bare mention of [KPS03] earlier is insufficient. Appendix B doesn't list DH Group 5, but it's mentioned in Section 5. |
2004-06-09
|
17 | Steven Bellovin | [Ballot comment] Should there be discussion of requirements for maximum UDP packet size (after fragment reassembly)? On the number of very closely-spaced packets that the … [Ballot comment] Should there be discussion of requirements for maximum UDP packet size (after fragment reassembly)? 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.) |
2004-06-09
|
17 | Steven Bellovin | [Ballot discuss] Define SA. Define -- not just expand -- "IKE SA". What is one? 2.7: The acronym SA is overloaded -- it's being used … [Ballot discuss] Define SA. Define -- not just expand -- "IKE SA". What is one? 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. 2.15: This section denounces password, but the only mandatory input mechanism for shared secrets is an ASCII string. It MUST support hex input 2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 addresses. 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.... 3.3.3: What are ESN and INTEG? 3.3.5: RC4 also requires a key length 3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems. Support for ID_IPV4_ADDR is only required for IPv4-capable systems 3.6: What URL types must be supported? HTTP? HTTPS? FTP? MAILTO? 5: A discussion of fragmentation attacks needs to be here. The bare mention of [KPS03] earlier is insufficient. Appendix B doesn't list DH Group 5, but it's mentioned in Section 5. |
2004-06-09
|
17 | Steven Bellovin | [Ballot comment] Should there be discussion of requirements for maximum UDP packet size (after fragment reassembly)? On the number of very closely-spaced packets that the … [Ballot comment] Should there be discussion of requirements for maximum UDP packet size (after fragment reassembly)? 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.) Should the techniques in [KPS03] be mandatory? |
2004-06-09
|
17 | Steven Bellovin | [Ballot discuss] Define SA. Define -- not just expand -- "IKE SA". What is one? 2.7: The acronym SA is overloaded -- it's being used … [Ballot discuss] Define SA. Define -- not just expand -- "IKE SA". What is one? 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. 2.15: This section denounces password, but the only mandatory input mechanism for shared secrets is an ASCII string. It MUST support hex input 2.19: Use IP addresses from the sample range (RFC 3330) instead of RFC 1918 addresses. 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.... 3.3.3: What are ESN and INTEG? 3.3.5: RC4 also requires a key length 3.5: MUST support ID_IPV6_ADDR on IPv6-capable systems. Support for ID_IPV4_ADDR is only required for IPv4-capable systems 3.6: What URL types must be supported? HTTP? HTTPS? FTP? MAILTO? Appendix B doesn't list DH Group 5, but it's mentioned in Section 5. |
2004-06-09
|
17 | Steven Bellovin | [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin |
2004-06-08
|
17 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie |
2004-06-08
|
17 | Ted Hardie | [Ballot comment] In Section 2.23: If the NAT_DETECTION_DESTINATION_IP payload received does not match the hash of the destination IP … [Ballot 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"; the parenthetical section seems confusing and should probably be re-worded or perhaps dropped (as what to do is clear without it). Just below, NAT-T is used without explanation in the text; expansion may be useful. 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. 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. |
2004-06-08
|
17 | Ted Hardie | [Ballot comment] In Section 2.23: If the NAT_DETECTION_DESTINATION_IP payload received does not match the hash of the destination IP … [Ballot 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"; the parenthetical section seems confusing and should probably be re-worded or perhaps dropped (as what to do is clear without it). Just below, NAT-T is used without explanation in the text; expansion may be useful. 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. |
2004-06-08
|
17 | Ted Hardie | [Ballot comment] In Section 2.23: If the NAT_DETECTION_DESTINATION_IP payload received does not match the hash of the destination IP … [Ballot 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"; the parenthetical section seems confusing and should probably be re-worded or perhaps dropped (as what to do is clear without it). Just below, NAT-T is used without explanation in the text; expansion may be useful. |
2004-06-08
|
17 | Ted Hardie | [Ballot comment] In Section 2.23: If the NAT_DETECTION_DESTINATION_IP payload received does not match the hash of the destination IP … [Ballot 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"; the parenthetical section seems confusing and should probably be re-worded or perhaps dropped (as what to do is clear without it). |
2004-06-08
|
17 | Ted Hardie | [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie |
2004-06-03
|
17 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-06-03
|
17 | Russ Housley | Placed on agenda for telechat - 2004-06-10 by Russ Housley |
2004-06-03
|
17 | Russ Housley | [Ballot Position Update] New position, Yes, has been recorded for Russ Housley |
2004-06-03
|
17 | Russ Housley | Ballot has been issued by Russ Housley |
2004-06-03
|
17 | Russ Housley | Created "Approve" ballot |
2004-06-02
|
14 | (System) | New version available: draft-ietf-ipsec-ikev2-14.txt |
2004-06-01
|
17 | Russ Housley | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::Revised ID Needed by Russ Housley |
2004-04-20
|
17 | Russ Housley | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for Writeup by Russ Housley |
2004-04-12
|
17 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2004-03-29
|
17 | Amy Vezza | Last call sent |
2004-03-29
|
17 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2004-03-25
|
17 | Russ Housley | State Changes to Last Call Requested from AD Evaluation by Russ Housley |
2004-03-25
|
17 | Russ Housley | Last Call was requested by Russ Housley |
2004-03-25
|
17 | (System) | Ballot writeup text was added |
2004-03-25
|
17 | (System) | Last call text was added |
2004-03-25
|
17 | (System) | Ballot approval text was added |
2004-03-25
|
13 | (System) | New version available: draft-ietf-ipsec-ikev2-13.txt |
2004-03-24
|
17 | Russ Housley | State Changes to AD Evaluation from AD Evaluation::Revised ID Needed by Russ Housley |
2004-02-09
|
17 | Russ Housley | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Russ Housley |
2004-02-04
|
(System) | Posted related IPR disclosure: Certicom's Statement About IPR Claimed in RFC 3526, RFC 2409, draft-ietf-ipsec-ikev2, and Other IETF Specifications Using MODP Groups | |
2004-01-07
|
12 | (System) | New version available: draft-ietf-ipsec-ikev2-12.txt |
2003-12-17
|
17 | Russ Housley | State Changes to AD Evaluation from Publication Requested by Russ Housley |
2003-10-13
|
17 | Russ Housley | Draft Added by Russ Housley |
2003-10-10
|
11 | (System) | New version available: draft-ietf-ipsec-ikev2-11.txt |
2003-08-18
|
10 | (System) | New version available: draft-ietf-ipsec-ikev2-10.txt |
2003-08-11
|
09 | (System) | New version available: draft-ietf-ipsec-ikev2-09.txt |
2003-07-02
|
(System) | Posted related IPR disclosure: Internet Key Exchange (IKEv2) Protocol | |
2003-07-02
|
(System) | Posted related IPR disclosure: Microsoft's statement about IPR claimed in draft-ietf-ipsec-ikev2-08.txt | |
2003-06-02
|
08 | (System) | New version available: draft-ietf-ipsec-ikev2-08.txt |
2003-04-22
|
07 | (System) | New version available: draft-ietf-ipsec-ikev2-07.txt |
2003-04-01
|
06 | (System) | New version available: draft-ietf-ipsec-ikev2-06.txt |
2003-02-24
|
05 | (System) | New version available: draft-ietf-ipsec-ikev2-05.txt |
2003-01-10
|
04 | (System) | New version available: draft-ietf-ipsec-ikev2-04.txt |
2002-10-15
|
03 | (System) | New version available: draft-ietf-ipsec-ikev2-03.txt |
2002-04-25
|
02 | (System) | New version available: draft-ietf-ipsec-ikev2-02.txt |
2002-03-01
|
01 | (System) | New version available: draft-ietf-ipsec-ikev2-01.txt |
2001-11-16
|
00 | (System) | New version available: draft-ietf-ipsec-ikev2-00.txt |