| Main Archive Page > Month Archives > ipsec archives |
[IPsec] New version of the IPsec Roadmap Internet Draft
From: Frankel, Sheila E. <sheila.frankel_at_nospam>Date: Fri Oct 02 2009 - 00:54:08 GMT
To: "ipsec@ietf.org" <ipsec@ietf.org>
We just submitted an updated (version 04) roadmap draft. We would like to thank everyone who took the time to read the doc and submit comments.
This email contains comments that led to changes in the doc, along with the changed text. It also mentions suggested changes with which we disagreed. Some minor editorial changes are not listed.
5 issues arose and were discussed at last week's interim meeting. They will be entered on the tracker and circulated to the list.
Sheila and Suresh
General comment:
It would be much easier to read the document if each document would be easier to detect from each other. Now when moving from one document to next is indicated by even more indented bulletpoint text than the actual text it does not provide good visual feedback to search documents. It might be better to change all document headers to sections.
RESPONSE: DONE
One slight anomaly - the RFCs are not listed individually in the Table of Contents. That means that, e.g., an RFC whose section is numbered x.x.x is not listed in the TOC, while a non-RFC section (e.g. 4.2.1 Peer Authentication Methods) is in the TOC.
Section 1.
In fact, it would be nice if Sec. 3 mentioned that IPsec and IKE apply equally to IPv4 and IPv6. It may be trivial to IPsec folks, but it isn't really.
RESPONSE: Added the following text to Introduction:
IPsec and IKE can be used in conjunction with both IPv4 and IPv6.
Section 2.1, in both the text and the diagram, refers to combined-mode algorithms only in relation to ESP. However, RFC 4543 defines the use of AES-GMAC for both ESP and AH. Same for Section 5.3
RESPONSE: AES-GMAC is only considered a combined mode algorithm in ESP; for AH it is simply an integrity-protection algorithm
Section 2.3.1, second paragraph -- The first sentence refers to two SA pairs and then the following sentences refer to two SAs. Perhaps we should make this transition less abrupt? I suggest inserting a sentence after the first to indicate that "SA" can be used to refer not only to the unidirectional SA but also to the pair.
Section 2.3.1, second paragraph -- Is it worth noting that "phase 1 SA" and "phase 2 SA" are also common names for the IKEv1 SAs?
RESPONSE: New wording:
Once an IKE negotiation is successfully completed, the peers have established two pairs of one-way (inbound and outbound) SAs. Since IKE always negotiates pairs of SAs, the term "SA" is generally used to refer to a pair of SAs (e.g., an "IKE SA" or an "IPsec SA" is in reality a pair of one-way SAs). The first SA, the IKE SA, is used to protect IKE traffic. The second SA provides IPsec protection to data traffic between the peers and/or other devices for which the peers are authorized to negotiate. It is called the IPsec SA in IKEv1 and, in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child SA, and an IPsec SA. This document uses the term "IPsec SA". To further complicate the terminology, since IKEv1 consists of two sequential negotiations, called phases, the IKE SA is also referred to as a phase 1 SA and the IPsec SA is referred to as a phase 2 SA.
Section 3.1: "IPsec protections are provided by two extension headers" - this is true for IPv6, I don't think the term is applicable to IPv4.
RESPONSE: Added new text:
IPsec protections are provided by two special headers: the Encapsulating Security Payload (ESP) Header and the Authentication Header (AH). In IPv4, these headers take the form of protocol headers; in IPv6, they are classified as extension headers.
Section 3.4
RFCs 3947 and 4304 (ESN) are in section 3 (IPsec) but are more appropriate for section 4 (IKE)
RESPONSE: Since these are additions to IPsec that are negotiated by IKE, it seemed logical to place them where they are.
Section 3.4
The descriptions of RFC 3947 and RFC 3948 are oddly placed. Both are in section 3 (IPsec) although 3947 is about IKE, and yet they are separated rather than following one another. I think that either 3947 should be moved to section 4 (IKE) or that they should be moved together.
RESPONSE: Moved 3948 right after 3947
Section 3.4
ESN is mentioned as optional for IKEv1 and included in IKEv2. It is not mentioned that this is an optional feature for IPsec (both old and new)
RESPONSE: Added Req Levels for IPsec-v2 (optional) and IPsec-v3 (optional) to RFC4304 and Appendix A
In Section 3.4. "Additions to IPsec", "RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels" is marked as optional. I do not understand the significance of marking this as optional because: 1) 4891 is informational and only describes a set of configuration settings rather than a protocol, and, 2) an IPsec traffic selector can discriminate based on "Next Layer Protocol" and thus can be used to realize 4891. So I'm thinking 4891 requirement level should be N/A rather than optional.
The exact same reasoning seems to apply to "RFC 3884, Use of IPsec Transport Mode for Dynamic Routing" which is also marked as optional.
Section 3.5: "Requirements levels for RFC3715" are meaningless - this is a requirements
RESPONSE: Added clarification that "optional" means either protocol implementation or use of features described in RFC. I think N/A would be confusing in this context. The new text is:
For each core IPsec and IKE RFC, this document will classify its Requirements Level for each protocol (IKEv1, IKEv2, IPsec-v2, IPsec-v3), as either MUST, SHALL or MAY [RFC2119]; optional; undefined; or N/A (not applicable). Optional means that either the RFC describes features that are not required to be implemented or settings or procedures that are recommended but not mandatory. Undefined means that some aspect of the RFC is not fully defined for the specific version of the protocol. N/A means that use of the RFC is inappropriate in the context (e.g., combined mode algorithms, a new feature in IPsec-v3, for use with IPsec-v2). The classification of the cryptographic algorithm RFCs is further explained in Section 5.
Section 3.4
There is nothing that limits the Heuristics draft to ipsec-v3. In facts legacy devices are a major reason for publishing these heuristics.
RESPONSE: changed IPsec-v2 to optional in the draft desc and Appendix A
Section 4.1.1: if RFC 2409 is N/A for IPsec-v3, how come RFC 4304 defines the use of ESN in IKEv1? But you can't expect a Roadmap document to resolve all issues.
RESPONSE: There definitely are murky areas, since some features have been retrofitted into IPsec-v2 without changing the RFCs. We've tried to make the Req Levels jive with both accepted practice and the RFCs as much as possible. But we're open to specific comments on what should be changed.
Section 4.1.1: the relation of IKEv1 and Oakley, as described here, is confusing. Because the Oakley *document* is informational, so you only need to read the other 3 docs as an implementer.
RESPONSE: Added new text:
This document provides additional theory and background to explain some of the design decisions and security features of IKE and ISAKMP; it does not include details necessary for the implementation of IKEv1.
Section 4.2.1 describes RFC 4478 (authentication lifetime). It says "This document defines a new informational message that...". Instead it should say "This document defines a new status notification, that...". Also, after "unless the initiator re-authenticates" I would add "within a specified period of time".
RESPONSE: DONE
Section 4.2.3 describes dead peer detection. It should mention that RFC 4306 (and the bis) call this feature "liveness check". Section 4.2.3: "dead peer detection (DPD) is an integral part of IKEv2", but now renamed to "liveness test" or "liveness check".
RESPONSE: Added new text:
This RFC defines an optional extension to IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which refers to this feature as a "liveness check" or "liveness test".
Section 4.2.4: why say that session resumption "requires changes to IKEv2"? It is an extension like many others. Similarly for the Redirect draft.
RESPONSE: This distinguishes these drafts from, e.g. the heuristics draft.
Section 4.2.4
Page 21 -- At the very top, the reference "psecme-2" should read "ipsecme-2". Also, I'm curious why this reference is linked and some earlier ones (e.g., "ipsecme-3") aren't.
RESPONSE: Current version corrected so that all references have pointers in the text
In section 5.2 covering RFC3686 document says:
... AES-CTR is a stream cipher with a 32-bit random nonce (1/SA) and a 64-bit IV, both of which are sent in the packet along with the encrypted data.
The description of the random noise and 64-bit IV is correct, but only the 64-bit IV is sent along the packet. The nonce is provided by the IKE with the keying material.
RESPONSE: Deleted "both of which ... data"
Section 5.2: please add a reference to the new AES-CTR document (also requires to change Table 2).
RESPONSE: added draft-ietf-ipsecme-aes-ctr-ikev2 and changed AES-CTR Requirements levels
Requirements levels for AES-CTR:
IKEv1 - undefined (no IANA #)
IKEv2 - optional [draft-ietf-ipsecme-aes-ctr-ikev2]
ESP-v2 - SHOULD [RFC4835]
ESP-v3 - SHOULD [RFC4835]
Section 5.4.1: shouldn't we mention that RFC 5282 is based on a more generic AEAD framework (RFC 5116)?
RESPONSE: We're trying to limit the number of non-IPsec references in the doc. Similarly, for the other algorithms (e.g. HMAC-SHA), we don't mention the non-IPsec base docs (RFC2104 - HMAC, or RFC3174 - SHA1).
Section 5.6: please define what is "Suite B" (a newcomer would be confused by the different uses of the word "suite" here).
RESPONSE: Added new Text:
[RFC4869] adds 4 pre-defined suites, based upon the United States National Security Agency's "Suite B" specifications, to those specified in [RFC4308].
Section 5.6 describes cryptographic suites documents (RFC 4308 and 4869), including the algorithms these documents specify (encryption, data integrity and DH group). It does not mention the not-so-obvious fact that RFC 4869 also requires the use of ECDSA for public keys used for authentication (if public keys are used), whereas 4308 makes no such requirement.
RESPONSE: Added new text:
While [RFC4308] does not specify a peer authentication method, [RFC4869] mandates pre-shared key authentication for IKEv1; public key authentication using ECDSA is recommended for IKEv1 and required for IKEv2.
Section 7.3: Sec. 1 of RFC 5386 makes it clear that it does *not* apply to IKEv1, or at least cannot be applied to all implementations. In addition, there is great confusion surrounding the term "unauthenticated security associations" in the BTNS context, but the IPsec Roadmap is not the place to deal with this issue.
RESPONSE: changed "the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2" to "IKEv2"
Section 7.4: I wouldn't say KINK is *another* attempt to provide an alternative, because BTNS is not an alternative, it is just an IKE (and RFC4301) tweak.
RESPONSE: changed "another" to "an"
Section 7.5: I would describe the history differently (I was there...). IPSRA attempted to tack user authentication onto IKEv1 with no change to IKE. This indeed proved cumbersome, and the result was the brand new IKEv2, which in fact adopted some of the IPSRA ideas, primarily the use of EAP.
RESPONSE: Changed text:
IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec protection to "road warriors," allowing IKE to authenticate not only the user's device but also the user, without changing IKEv1. The working group defined generic requirements of different IPsec remote access scenarios. An attempt was made to define an IKE-like protocol that would use legacy authentication mechanisms to create a temporary or short-lived user credential that could be used for peer authentication within IKE. This protocol proved to be more cumbersome than standard Public Key protocols, and was abandoned. This led to the development of IKEv2, which incorporates the use of EAP for user authentication.
Section 8.2
Is it worth mentioning that OSPF protection in RFC4552 works with manual keying only, and that no key exchange protocols are specified?
RESPONSE: Added new text:
Since OSPFv3 exchanges multicast packets as well as unicast ones, the use of IKE within OSPFv3 is not appropriate. Therefore, this document mandates the use of manual keys.
Section 8.7 describes RoHC RFCs that relate to IPsec. I think it should also mention the soon-to-be-published drafts about compressing IPsec traffic:
- draft-ietf-rohc-ipsec-extensions-hcoipsec
- draft-ietf-rohc-ikev2-extensions-hcoipsec
- draft-ietf-rohc-hcoipsec
RESPONSE: Added the 3 rohc Internet Drafts
Section 8.3: this section could be improved by explaining what HIP is.
RESPONSE: Changed text:
IP addresses perform two distinct functions: host identifier and locator. This document specifies a protocol that allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses. This enables continuity of communications across IP address (locator) changes. It uses public key identifiers from a new Host Identity (HI) namespace for peer authentication. It uses the HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for protecting its signaling messages.
Nit -- there are a few places that don't hyphenate "combined mode" when used as an adjective: "combined mode algorithm[s]" should be "combined-mode algorithm[s]".
RESPONSE: changed references to "combined mode algorithm," which is how all the RFCs do it; only other I-D that uses a hyphen is ikev2bis
Other Accepted Comments:
The document capitalizes the name of the WG as IPsecme. I think we like using IPsecME, no?
draft-ietf-ipsecme-ikev2-ipv6-config is no longer on the Standards Track.
KINK and BTNS should be all-caps. Similarly MOBIKE.
Section 6: typo: "[RFC5197] provides in in-depth".
Section 8.3: typo: "for for describing".
The description of RFC5206 has mismatched parenthesis.
Issues that will be entered into the Issue Tracker:
Issue #1:
Combined algorithms: Can IKEv1 negotiate combined algorithms to be used by IPsec-v3?
Issue #2:
Section 5.3 -- Under RFC 2404, it mentions that SHA-1 ICVs are truncated to 96 bits for IPsec. We should also mention that this truncation is done for IKEv2 as well. Same for RFC 2403.
RESPONSE: It appears that IKEv2 can negotiate the use of either the truncated or non-truncated form of the algorithms. We will propose new text to describe this.
Issue #3:
Discussion on use of AES-XCBC in IKE. Currently, the Req levels are SHOULD for IKEv1 (based on RFC4109) and optional for IKEv2. The Req levels for AES-XCBC-PRF are SHOULD (based on RFC4109) and SHOULD+ for IKEv2 (RFC4307)
This leaves us with 2 questions:
1) If there is no IANA value for AES-XCBC in IKEv1, how can RFC4109 recommend (SHOULD) its use?
2) If AES-XCBC and AES-XCBC-PRF can be used in IKEv1, what should be proposed? What should you propose if you want AES-XCBC for both a PRF and an integrity-protection algorithm in IKEv1?
Issue #4:
BEET and expired drafts:
- I would have liked to see ESP BEET mode referenced, since it's more widely
implemented than other docs that we do mention. But as far as I know it is
not on track to becoming an RFC.
- I think it might also be good to mention other
very widely implemented (expired) drafts which will never come out as
RFCs, namely IKEv1 configuration mode (draft-dukes-ike-mode-cfg-02)
and IKEv1 xauth (draft-beaulieu-ike-xauth-02).
RESPONSE: We will mention the expired drafts in the IKEv1 section of the roadmap doc, explaining that many implementations implement these 2 drafts to enable road warrior (user) authentication. The wording will include cautions about their use: security issues, implementation/interoperability problems, etc.
Issue #5:
Issue of Camellia req levels for IKEv2
Camellia-CBC: covered by generic CBC requirements in RFC4306?
Camellia-CTR: needs its own RFC?
Camellia-CCM: covered by RFC 5282?
----------------------------------------------------------------
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec