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

<Pasi.Eronen@nokia.com> Mon, 15 March 2010 12:03 UTC

Return-Path: <Pasi.Eronen@nokia.com>
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 432673A6B76 for <ipsec@core3.amsl.com>; Mon, 15 Mar 2010 05:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.263
X-Spam-Level:
X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=-1.264, BAYES_50=0.001, 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 B2UmERyRidgL for <ipsec@core3.amsl.com>; Mon, 15 Mar 2010 05:03:31 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E63AD3A67A3 for <ipsec@ietf.org>; Mon, 15 Mar 2010 04:36:46 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2FBaP2k003122; Mon, 15 Mar 2010 13:36:43 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:36:29 +0200
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:36:28 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 13:36:24 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 15 Mar 2010 12:36:16 +0100
From: Pasi.Eronen@nokia.com
To: sheila.frankel@nist.gov, ipsec@ietf.org
Date: Mon, 15 Mar 2010 12:36:15 +0100
Thread-Topic: Response to Pasi's AD comments on the roadmap draft
Thread-Index: AQHKvuqB0s+eXspKVkaiyQLdLNk5WZHy3v6Q
Message-ID: <808FD6E27AD4884E94820BC333B2DB775848477F15@NOK-EUMSG-01.mgdnok.nokia.com>
References: <D7A0423E5E193F40BE6E94126930C49307964A8F07@MBCLUSTER.xchange.nist.gov>
In-Reply-To: <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-OriginalArrivalTime: 15 Mar 2010 11:36:24.0146 (UTC) FILETIME=[BDE07320:01CAC433]
X-Nokia-AV: Clean
Cc: paul.hoffman@vpnc.org
Subject: Re: [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, 15 Mar 2010 12:03:33 -0000

Sheila Frankel wrote:

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

Currently, it very much reads like it's setting requirements. If we
keep the 2119 keywords for algorithms, at the very least we need to
say that this documnent is just repeating requirements from elsewhere,
and if there's a conflict between this RFC and any other RFC, then the
other RFC is takes precedence.

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

I don't think the summary table is really adding much for the
non-algorithm documents (since it's not even using the requirement
levels SHOULD/MAY/etc. that are used for algorithms).

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

I don't disagree that RFC 4307 is somewhat confusing.  But if this
roadmap document tries to fix the situation (rather than just
describing it), it needs to update RFC 4307 (which I would prefer not
to do).

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

I'm still wondering what's the criteria for including these particular
RFCs, but not others that use IPSEC (like Diameter, RADIUS, iSCSI,
TGREP, etc)....

Including *some* of the Mobile IP specs (those that may change IPsec
processing) certainly makes sense, but when it comes to various minor
MIP extensions, what's the criteria for including these in particular,
and not several other MIP 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."

Well, it's not necessarily undefined for ESP-v2/ESP-v3, since 
that algorithm could still be used with manual keying (and other
key management protocols than IKEv1/IKEv2).

I would suggest something like "ESP-v2 - optional (but no IANA #, so
cannot be negotiated by IKEv1)".

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

The situation of RFC 5114 is quite confusing, I agree (because it's
IMHO not totally clear whether the errata for RFC 4753 would apply to
RFC 5114 too).

Perhaps "It also includes 3 EC DH groups (groups 19-21) for
information; however, the normative specification for these groups 
is [4753bis]."?

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

I do not consider 8.6 and 8.4.1 to be "protocols that use IPsec/IKE";
they're new protocols that have nothing to do with IPsec, except that
they happened to borrow some of their design (like payload formats,
calculations) from RFC 4306.

So I don't think they belong under the same heading as rest of 8.x...

Best regards,
Pasi