[IPsec] Response to Pasi's AD comments on the roadmap draft

"Frankel, Sheila E." <sheila.frankel@nist.gov> Mon, 08 March 2010 18:10 UTC

Return-Path: <sheila.frankel@nist.gov>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5F33A6A34 for <ipsec@core3.amsl.com>; Mon, 8 Mar 2010 10:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yZmgz3X0Sal for <ipsec@core3.amsl.com>; Mon, 8 Mar 2010 10:09:59 -0800 (PST)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 19F723A69E1 for <ipsec@ietf.org>; Mon, 8 Mar 2010 10:09:58 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o28I9lam003456; Mon, 8 Mar 2010 13:09:47 -0500
Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 8 Mar 2010 13:09:47 -0500
From: "Frankel, Sheila E." <sheila.frankel@nist.gov>
To: "ipsec@ietf.org" <ipsec@ietf.org>, "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com>
Date: Mon, 08 Mar 2010 13:05:14 -0500
Thread-Topic: Response to Pasi's AD comments on the roadmap draft
Thread-Index: AQHKvuqB0s+eXspKVkaiyQLdLNk5WQ==
Message-ID: <D7A0423E5E193F40BE6E94126930C49307964A8F07@MBCLUSTER.xchange.nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: sheila.frankel@nist.gov
Cc: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: [IPsec] Response to Pasi's AD comments on the roadmap draft
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2010 18:10:01 -0000

Here are our responses to Pasi's AD comments on the roadmap doc. We have indicated which changes we plan to make, and which ones we would prefer to handle somewhat differently.

We would appreciate hearing from the list, both those who agree and those who don't. We will send a separate email listing those RFCs that Pasi wants us to delete from the roadmap and those he would like us to add.

Sheila and Suresh

>  - 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.

The only places these words are used is in re-phrasing requirements specified 
in RFCs. So it doesn't set any requirements, just re-states them.

>  
>  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.

There is a lot of confusion in the vendor and user community about this issue, 
and that is why we felt it would help to have a central repository with this 
information. Obviously, any docs that come after the roadmap could change things, 
but even knowing that this is a snapshot as of a specific date is helpful - then 
you just have to examine docs that come after this to see what has changed.

We feel that it is useful to state the requirements together with the relevant 
RFCs, along with explanations (e.g. no RFC, no IANA #) for those that are undefined. 
In addition, if new RFCs and/or IANA #'s come along, it will be clear what is 
responsible for a potential change in that algorithm's applicability. We think that 
the summary table is a useful reference tool, but it's hard to read without being 
able to check back to the relevant RFC requirements.

It does make sense to state, in the 2 places that we describe these requirement 
levels, that this is a snapshot as of March 2010 (or a later publication date) and 
is subject to change in future.

>  
>  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.
>  

Originally, we just had req levels for algs - someone in the WG requested that 
we extend it to include all of the basic IKE and IPsec docs, the WG chairs concurred, 
and we added them. We would like to see the req levels remain for the algs, but we 
don't feel equally strongly about the other docs. Adding text to the RFC descriptions 
would be fine. Do you have any objection to the summary table for these docs?

>  - 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...
>  

RFC 4307 is a very problematic RFC. There are 2 lists of required algorithms for 
IKEv2. Section 3.1.1 (Encrypted Payload Algorithms) has 1 list, which specifies 
the MUST and SHOULD algs for encryption and integrity, but does not mention 
AES-XCBC. Then there are different lists in section 3.1.3 (encryption) and 
3.1.5 (integrity). I (Sheila) had originally assumed that section 3.1.1 pertained 
to IKEv2 payloads and the other sections pertained to algorithms that IKEv2 
negotiated for IPsec. The WG chairs and others disagreed, feeling that this RFC 
was hastily written and contradictory. We took section 3.1.1 to be definitive. 
I guess we should explain this in the roadmap. But it's problems like this that 
led us to include the requirements levels in the roadmap.

>  - 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.
>  

OK

>  - 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.
>  

Suggested new wording: "[RFC4309] includes IANA values that IKE can use to 
negotiate ESP-v3 SAs."

>  - 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 notification.
>  

New text and adding RFC 5026: OK

Deleting other Mobile IP and OSPF RFCs: We feel there's value in summarizing 
RFCs that use IPsec, even though they don't make any modifications. For example, 
in extending and/or re-defining features of IPsec, it can be useful to see 
dependencies and feature use in other protocols. We would prefer to add a 
statement that these RFCs use IKE/IPsec without any modifications or extensions.

>  - 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, ...).
>  

Suggested new wording: "The IANA registries for IKEv1 and IKEv2 include IANA 
values for various cryptographic algorithms. IKE uses these values to negotiate 
IPsec SAs that will provide protection using those algorithms. If a specific 
algorithm lacks a value for IKEv1 and/or IKEv2, that algorithm's use is classified 
as "undefined (no IANA #) within IPsec-v2 and/or IPsec-v3."

>  - 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.
>  

OK - but won't people be confused if they look at RFC 5114 and see that there 
are additional groups defined there?

>  - 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.
>  

OK - Policy and MIBs will be moved to Section 7 (Outgrowths of IPsec/IKE).

>  - IMHO MOBIKE would belong together with other IKEv2 remote
>  access extensions in Section 4.2.4?
>  

OK - MOBIKE will be moved to 4.2.4 (Remote Access) under the Section "IKE 
Additions and Extensions"

>  - Should RFC 2521 be mentioned? (it's largely obsolete, I guess, but
>  for completeness..)
>  

No strong opinion.

>  - 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 :-)
>  

No strong opinion.

>  - 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...)
>  

OK

>  - Section 8.5.1: this has an IKE extension (to pretty core
>  part of IKE), so might belong in Section 4.2 instead.
>  

RFC 3554, On the Use of SCTP with IPsec: Since it's a product of another WG for 
another protocol, we would prefer to leave it where it is.

>  - RFC 4322 probably should be mentioned somewhere (near BTNS and/or
>  IPSECKEY).
>  

RFC 4322, Opportunistic Encryption using the Internet Key Exchange (IKE) - OK, 
that's one we totally missed.

>  - 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."
>  

OK

>  - 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.
>  

OK with us - we'll submit the list of RFCs to be deleted/added to the WG, in case 
anyone else has strong opinions on this metter.

>  - Section 6.1: RFC 3740 barely mentions IPsec, so the description
>  should probably point out that 3740 isn't really about IPsec.
>  

OK

>  - I'm not sure what 4534/4535 have to do with IPsec; it doesn't
>  look like it supports creating IPsec SAs, for example.
>  

Do you think these should be removed? If so, we'll run it past the WG

>  - Sections 6.(14,15,16) are not about IPsec, but non-IPsec
>  approaches to securing multicast; so they don't really belong here.
>  

Do you think these should be removed? If so, we'll run it past the WG

>  - 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 8 is titled: "Other Protocols that use IPsec/IKE". We would prefer to 
change/expand this title, rather than adding another new major section.

Other proposed changes: 
	Add a new sub-section, "Wireless" or "Wireless Security" to include RFC 4705. 
	Change the heading of the section that includes RFC 5106 (EAP-IKEv2) from 
"Extensible Authentication Protocol (EAP) Method Update (EMU)" to 
"Extensible Authentication Protocol (EAP)"

>  - 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...)
>  

OK

>  - 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?
>  

OK

>  - 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").
>  

OK

>  - Section 4.2.4.3: now RFC 5739.
>  

OK

>  - Section 1 and 5: "MUST, SHALL or MAY" should probably be
>  "MUST, SHOULD or MAY"?
>  

OK

>  - I'd suggest swapping the order of 7.2.1 and 7.2.2.
>  

OK

>  - Section 7.6 and 7.6.1: I'd suggest combining this to a single
>  section.

No strong opinion on this - but this would be the only RFC that doesn't have its 
own section #, separate from its introductory section.