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

From: "Frankel, Sheila E." <[email-masked]>
Date: Mon, 8 Mar 2010 13:05:14 -0500

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.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Mar 2010 10:31:10 -0800

I would like to see much more comment from the WG on this thread. In general, I agree with Sheila and Suresh's reply to Pasi, but others should chime in as well.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Mon, 15 Mar 2010 12:36:15 +0100

Sheila Frankel wrote:

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

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

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?

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Mar 2010 07:35:22 -0800

>other RFC is takes precedence.

Good call. This should appear in the intro, possibly as a one-paragraph subsection so that the section head stands out.

>describing it), it needs to update RFC 4307 (which I would prefer not

I agree that we don't want this document to update 4307. However, it seems appropriate for this document to highlight the confusion that 4307 causes.

>RFCs, but not others that use IPSEC (like Diameter, RADIUS, iSCSI,

It's a judgement call. I don't think the real-world use of IPsec by Diameter and RADIUS is orders of magnitude smaller than that of MIP, but I could be wrong.

>and not several other MIP extensions?

Again, it's a judgement call. It's fine to include more or fewer of these.

>cannot be negotiated by IKEv1)".

That seems good.

>information; however, the normative specification for these groups

It is inappropriate for this document to say what the normative specification for another document is, particularly one that is as confusing as RFC 5114.

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

It is easy to add another section.

--Paul Hoffman, Director
--VPN Consortium

---

From: <[email-masked]>
Date: Tue, 16 Mar 2010 13:38:08 +0100

Paul Hoffman wrote:

> It is inappropriate for this document to say what the normative
> specification for another document is, particularly one that is as
> confusing as RFC 5114.

Assuming 4753bis gets approved by IESG before the roadmap (which seems
very likely), I think we can say this. Or perhaps we could
say "current" instead "normative"?

  "RFC 5114 also included 3 EC DH groups (groups 19-21) that were
  originally defined in [RFC4753]; however, the current specification
  for these groups is [4753bis]".

Best regards,
Pasi

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Mar 2010 07:39:35 -0700

>  for these groups is [4753bis]".

That works for me.

--Paul Hoffman, Director
--VPN Consortium