Hi Pasi, Thanks for your comments. Some of them are pretty major and we would like to request some time to properly address them. We will respond by next Monday with our proposed resolutions.
Thanks Suresh > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of [email protected] > Sent: Friday, February 26, 2010 12:08 PM > To: [email protected] > Subject: [IPsec] AD review comments for draft-ietf-ipsecme-roadmap-05 > > I've now done my AD review for draft-ietf-ipsecme-roadmap-05, > and have bunch of comments (most of them minor). Most important first: > > - I'm not very happy about the use of MUST, SHOULD, etc. in > this document. This is supposed to be a purely informational > guide to other documents, not something that sets > requirements (of any level) for anyone. > > For cryptographic algorithms, we already have separate > documents that specify the requirement levels. IMHO repeating > them here just means the two places will soon be inconsistent > (which is not helpful for the audience here). If the WG has > considered this and decided the repeating them here is > useful, I would strongly suggest just having the tables in > Appendix B (with explicit note that they're probably out of > date by the time the reader finds them), and removing them > from Section 5.x. > > For things other than cryptographic algorithms, I'm not sure > if talking about "requirements levels" even makes that much > sense. Consider, for example, Section 4.2.4.2 (IKEv2 redirect): > > Requirements levels for RFC5685: > IKEv1 - N/A > IKEv2 - optional > > This is not really specifying any requirement level; a > phrasing like "This extension applies only to IKEv2, not > IKEv1" would IMHO be more accurate. Text in most other > sections (than crypto algs) could be rephrased similarly. > > - Appendix B: I'm trying to match table B against RFC > 4307/4835 and I can't quite get them to match. For example, > RFC 4307 lists > AUTH_AES_XCBC_96 as "SHOULD+", while the column "IKEv2" here > says "optional". This suggests that perhaps even including > this table isn't such a good idea... > > - Section 5.4: "Since combined mode algorithms are not a > feature of IPsec-v2, these IKEv1 implementations are used in > conjunction with IPsec-v3." I'm not sure if this is really a > good way to describe the situation; after all, GCM-for-ESP > (RFC 4106) predates IPsec-v3... > > I'd suggest something like "Although IPsec-v2 ESP [RFC2406] > did not originally include combined mode algorithms, some > IKEv1 implementations have added the capability to negotiate > combined mode algorithms for use in IPsec SAs; these > implementations do not include the capability to use combined > mode algorithms to protect IKE SAs." > > Analogous changes are needed in 5.4.1, 5.4.2, 5.4.3, and 5.6.2. > > - Section 5.4.1: "[RFC4309] includes IANA values for use in > ESP-v3"; ESP doesn't have any IANA registries; IKEv1 and > IKEv2 do. RFC 4309 is included in both. > > - Quite many IETF protocols use (or can use) IPsec to protect > their traffic, so we have *lot* of RFCs that specify how to > configure IPsec for use X (ranging from RADIUS and Diameter > to iSCSI and TGREP). > I don't think these belong in the IPsec document roadmap, > unless they modify/extend how IPsec works (e.g. define new > payloads/something for IKEv1/v2, or change the IPsec > processing somehow). > > With this in mind, I'd suggest deleting 8.1.1, 8.1.2, and > 8.2; rephrasing 8.1.3 and 8.1.4 to explain their impact on > IPsec; deleting 8.1.5/8.1.6/8.1.7 and adding RFC 5026 (text below). > > Proposed new text for 8.1.3: > > This document specifies the use of IPsec in securing Mobile IPv6 > traffic between mobile nodes and home agents. Mobile IPv6 requires > considering the Home Address destination option and Routing Header > in IPsec processing. Also, IPsec and IKE security association > addresses can be updated by Mobile IPv6 signaling messages. > > Proposed new text for 8.1.4: > > This document updates [RFC3776] in order to work with the revised > IPsec architecture [RFC4301]. Since the revised IPsec architecture > expands the list of selectors to include the Mobility > Header message > type, it becomes much easier to differentiate between different > mobility header messages. This document also specifies the use > of IKEv2 configuration payloads for dynamic home address > configuration. > > Proposed text for RFC 5026: > > This document extends [RFC4877] to support dynamic discovery of > home agents and the home network prefix; for the latter purpose, it > specifies a new IKEv2 configuration attribute and notificatio7n. > > - Section 5.x: IMHO lines like "ESP-v2 - undefined (no IANA #)" > are a bit confusing, because ESP does not have any IANA > registries; the registries are specific to a key management > protocol (IKEv1, IKEv2, Photuris, KINK, HIP, ...). > > - Section 5.7.4: "It also includes 3 EC DH groups (groups > 19-21) that were previously defined in [RFC4753]". The > normative specification for groups 19-21 in IKE is still > 4753/5753bis, so I would propose just omitting this sentence. > > - I would suggest moving 3.2/3.3 somewhere later in the > document -- as the document already says, this is not really > deployed stuff, and might fit better in e.g. Section 7. > > - IMHO MOBIKE would belong together with other IKEv2 remote > access extensions in Section 4.2.4? > > - Should RFC 2521 be mentioned? (it's largely obsolete, I > guess, but for completeness..) > > - What about RFC 2709? (it's definitely obsolete, but things > like this influenced the design of the current IPsec NAT-T, > like using a different port number to avoid any 2709-like stuff :-) > > - Should we include RFC 3329? It does (partly) specify the > "3gpp-ipsec" mechanism for setting up IPsec SAs (basically, a > simple key management protocol instead of IKE), and this is > something that is actually implemented (however, some of the > details needed to implement this are not actually in 3329, > but only in 3GPP specs...) > > - Section 8.5.1: this has an IKE extension (to pretty core > part of IKE), so might belong in Section 4.2 instead. > > - RFC 4322 probably should be mentioned somewhere (near BTNS > and/or IPSECKEY). > > - Section 8.8.1: suggest adding something like "It also > defines how public key fingerprints (hashes) are distributed > via BGP, and used later to authenticate IKEv2 exchange > between the tunnel endpoints." > > - Section 6: MIKEY (as specified in IETF RFCs) creates > security associations for SRTP, not IPsec -- so it's not > really relevant for this document (some other SDOs have > extended MIKEY to create IPsec SAs, but that's an area we > IMHO don't need to cover in this roadmap). > So Sections 6.(7,8,9,10,12,13) should be dropped. > > - Section 6.1: RFC 3740 barely mentions IPsec, so the > description should probably point out that 3740 isn't really > about IPsec. > > - I'm not sure what 4534/4535 have to do with IPsec; it > doesn't look like it supports creating IPsec SAs, for example. > > - Sections 6.(14,15,16) are not about IPsec, but non-IPsec > approaches to securing multicast; so they don't really belong here. > > - Section 8.6 and 8.4.1 are not about IPsec, but adapting > IKEv2 to non-IPsec uses. Perhaps these (and RFC 4705, which > is missing from the > list) should be grouped under "Non-IPsec Protocols Related to > IKE" or something? (and Section 8.4.1 doesn't really belong > under title "EMU"; it did not come from the EMU WG). > > - Section 7.4: would it be useful to mention that some > vendors have proprietary extensions for Kerberos in IKEv1 (not KINK)? > (since these are really deployed and used, unlike KINK...) > > - Section 7.1: I would suggest not having separate sections > for all IPComp compression algorithms. Perhaps a one-sentence > summary like: > "Compression algorithms for IPcomp include DEFLATE [RFC > 2394], LZS [RFC2395], and LZJH [RFC 3051]." would be sufficient? > > - Section 1: "The usage of terms in this document conforms to > definitions in [RFC4949]." No, it does not; just remove this sentence. > Here's what Sam wrote back then for his ABSTAIN ballot for 4949: > > "However there is a lot left in the glossary that is the author's > personal opinion. We found a number of instances where the author > was trying to use this glossary to establish normative meanings for > words based on his belief of how those words should be > used--sometimes in direct conflict with common practice." > > (For example, 4949 considers terms like "MAC (message > authentication code)" and "initialization vector" to be > wrong; the "correct" terms would be "keyed hash"/"protected > checksum" and "initialization value"). > > - Section 4.2.4.3: now RFC 5739. > > - Section 1 and 5: "MUST, SHALL or MAY" should probably be > "MUST, SHOULD or MAY"? > > - I'd suggest swapping the order of 7.2.1 and 7.2.2. > > - Section 7.6 and 7.6.1: I'd suggest combining this to a > single section. > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
