Using IPsec to Secure IPv6-in-IPv4 Tunnels
draft-ietf-v6ops-ipsec-tunnels-05

[Ballot comment]
From Gen-ART reviewer David Black, referring to the -05 version:

I suggest that an
RFC Editor note be used to insert the following text (much of which
Fred Baker wrote) to explain what "modeled as an interface" means:

  An important consideration in determining whether to use IPsec tunnel
  mode is whether the IPsec tunnel mode SA is modeled as an interface.
  This notion of interface is logical - any time a system, host or
  router, sends a datagram, it has to account for having done so using
  the RFC 2863 Interface MIB.  To do so, the system derives ifIndex from
  the route entry (see InetCidrRouteEntry in RFC 4292) that it uses to
  forward the  datagram, or from the IpDefaultRouterEntry described
  in RFC 4293.  The management information accessed via the ifIndex
  is "the interface" from a management and configuration perspective.

This text should be inserted immediately following this sentence in
Section 5:

  The IPv6 traffic can be protected using transport or tunnel mode.

This will also entail adding informative references to RFCs 2863,
4292 and 4293.

[Ballot comment]
> The reason threat (1) exists is the lack of widespread deployment of
> IPv4 ingress filtering [RFC3704].

I believe it would be more correct to say "lack of universal
deployment" -- it is very widely deployed, just not everywhere.

[Ballot comment]
Folks, thanks for doing a great job on this document both at balancing
RFC 4301 vs RFC 2401 and at handling issues like the PAD.

[Ballot discuss]
These are requests for technical clarification from the Gen-ART review by David Black. The authors have acknowledged the need for clarifications.

----

As an informational document whose primary purpose is to explain how
to use protocols specified elsewhere, clarity is of primary importance.
While I was able to figure out what the draft is trying to say, it
needs attention.

The open issues include the clarity problems in Section 4 that rise to
the level of possible or actual technical misstatements, the lack of
explanation of requirements in Section 5.2, and the missing IPsec
details. 

My detailed comments are as follows:

The recommendation against tunnel mode should be included in the
abstract.

Section 4 has some wording problems:

  1.  [RFC2401] does not allow IP as the next layer protocol in traffic
      selectors when an IPsec SA is negotiated.  [RFC4301] also allows
      IP as the next layer protocol (like TCP or UDP) in traffic
      selectors.

The "also" is susceptible to misreading.  The second sentence should
be rephrased to: "In contrast, [RFC4301] does allow ..."

  2.  [RFC4301] assumes IKEv2, as some of the new features cannot be
      negotiated using IKEv1.  It is valid to negotiate multiple
      traffic selectors for a given IPsec SA in [RFC4301].  This is
      possible only with [RFC4306].  If [RFC2409] is used, then
      multiple SAs need to be set up for each traffic selector.

The last sentence is incorrect as written ("set up" needs to be
replaces by "set up, one for each" to correct it) and the use of
RFC numbers for protocol names is semi-opaque.  The following would
be much clearer:

  2.  [RFC4301] assumes IKEv2, as some of the new features cannot be
      negotiated using IKEv1.  It is valid to negotiate multiple
      traffic selectors for a given IPsec SA in [RFC4301].  This is
      possible only with IKEv2.  If IKEv1 is used as specified in
      [RFC2409], then each traffic selector requires a separate SA.

I strongly recommend use of the protocol names instead of just RFC
numbers for clarity throughout the draft, and using both (e.g.,
"IKEv1 [RFC2409]") is an acceptable alternative.

Table 1 in Section 5 uses acronyms for addresses in the "Contains"
column that need to be defined before they are used.

Section 5.2 discusses the consequences of whether the endpoint
of an IPsec tunnel-mode SA is modeled as an IPv6 interface or
not.  It should say that there is always an IPv6 interface at
the endpoint of a IPv6-in-IPv4 tunnel, and the discussion of
whether to model the SA as an interface is concerned with
whether the functionality of an IPv6 interface is realized by
the IPsec SA or outside of it.

It should also be stated that all uses of the word "interface"
refer to an IPv6 interface, and that the phrase "tunnel interface"
refers to an IPv6 interface at the endpoint of an IPv6-in-IPv4
tunnel, independent of whether the tunnel is realized by IPsec
tunnel mode.  The end of Section 1 would be a good place to
do this.  The use of the phrase "IP interface" in Section A.1
is considerably clearer than the use of "interface" without "IP"
in Section 5.2 - using "IP interface" throughout Section 5.2
(and for that matter the entire draft) would improve readability.

The three requirements in Section 5.2 are generally applicable,
and should not be buried in Section 5.2's discussion of IPsec
tunnel mode.  The requirements also lack explanations of why
they are requirements.  At a minimum, the statement of the
requirements should be moved into Section 5 (before 5.1), but
I would suggest moving them to the end of Section 3 and adding
a discussion of why these requirements are important (e.g., what
goes wrong if they're not met) with reference to the scenarios
described in Section 3.

Cross-checking this draft against the elements in Section 8
of draft-bellovin-useipsec-05.txt, I find some things that need
attention:
a) Selectors - Yes, specified in Section 5.1
b) IPsec protocol and mode - Yes, ESP vs. AH is at the
end of section 4 and tunnel-vs-transport is a
major portion of this draft.
c) Key management - Almost.  The numerous mentions of
IKE indicate a preference for automatic keying, but
there should also be a strong recommendation against
manual keying, due to the amount of IPv6 traffic that
may use an IPv6-in-IPv4 tunnel.  Manual keying of
IKE needs to be clearly distinguished from manual
configuration of the IPv6-in-IPv4 tunnel.  The end
of Section 2 would be a good location for these topics.
d) SPD entries - Yes, specified in Section 5.1
e) Identification forms - Yes, but.  The first bullet in
Section 5.3 has a weak recommendation for IPv4
addresses as identities.  The "but" is that ingress
filtering is discussed entirely in the abstract, and
additional discussion is needed about how to determine
what IPv6 ingress filter to use with which IPv4 address
(this may be part of tunnel configuration).
f) Authentication form - Yes, second bullet in section 5.3
g) IKE versions and modes - No.  Section 4 implies that
both IKEv1 and IKEv2 can be used, although IKEv2 is
somewhat preferred - this should probably be stated
explicitly.  There is no discussion of IKEv1 Main vs.
Aggressive mode - it would suffice to say that if
IPv4 addresses are used as identities, identity
protection is not required (it's obvious where the
traffic is coming from), making Aggressive mode an
acceptable alternative to Main mode.
h) IPsec support availability - No.  This can be side-
stepped to some extent by noting that the IPv6 RFCs
require IPsec support.

Note that I am not asking that this draft meet all the requirements
in Section 8 of the bellovin-useipsec draft, and in particular, I'm
giving this draft significant slack against the usual IETF
requirement that sufficient mandatory-to-implement elements be
specified for interoperability.  With the possible exception of
IKEv1 vs. IKEv2, interoperability requirements belong in the RFCs
that specify the protocols involved.

[Ballot comment]
From the SecDir Review by Sean Turner:

  Section 2, 1st para after numbered items: The RFC 4031 list of security
  services also includes access control, data origin authentication,
  rejection of replays, and limited traffic flow confidentiality.  Are
  these not offered?

  Section 5.2, 2nd to last para: s/bu no inter-/but no inter-/

PROTO Write-up

> Who is the Document Shepherd for this document?

Fred Baker

> Has the Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this version is
> ready for forwarding to the IESG for publication?

I have read it, and yes, I believe that it is ready for publication.

> Has the document had adequate review both from key WG members and
> from key non-WG members?

This document has had extensive review from the working group and
from the Security area over the past couple of years.

> Does the Document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

In general, I wish that I could say that all participants in v6ops
read all drafts, and I can't say that. However, I do believe that the
review has been adequate, and my own review has not flushed out
further issues.

> Does the Document Shepherd have concerns that the document needs
> more review from a particular or broader perspective, e.g.,
> security, operational complexity, someone familiar with AAA,
> internationalization or XML?

It has already had security area review, which is the matter I would
consider most pressing.

> Does the Document Shepherd have any specific concerns or issues
> with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is
> uncomfortable with certain parts of the document, or has concerns
> whether there really is a need for it.

In my review, I had two questions: whether the recommendation to
avoid tunnel mode was necessary/appropriate, and whether the
description of a site-to-router tunnel made sense. In the former
case, it appears to me that the working group accepts the
recommendation, and my initial concerns with it actually deal with
another issue (which is tunnel mode across a network and consistent
with running IPv6 through an IPv4 transport tunnel). In the latter
case, the question arises because section 3.2 describes it, but I
don't know how to configure it. I know how to set up an IPSEC
security association host-host, host-router, and router-router, but
not from a site to a router. That said, the document describes this
as a genealized version of host-router, and in my mind the
generalization does no violence to the matter.

> In any event, if the WG has discussed those issues and has
> indicated that it still wishes to advance the document, detail
> those concerns here.

As I said, the consensus of the working group is to accept the
recommendation, and I am willing to go with that.

> How solid is the WG consensus behind this document?

Having been through a couple of last calls and quite a bit of
discussion, I believe that the working group buys in to this draft.

> Does it represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and agree
> with it?

v6ops is a quiet crowd. My experience is that when things are going
sideways, they get noisy. I believe that the working group
understands the issues and the recommendations and concurs with them.

> Has anyone threatened an appeal or otherwise indicated extreme
> discontent?

no

> Has the Document Shepherd personally verified that the document
> satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html
> and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
> not enough; this check needs to be thorough.

The document refers, informatively, to two internet drafts that have
expired from the internet draft repository. As these are merely
informative, this is acceptable, and I would recommend that the RFC
Editor include in them the URL

http://tools.ietf.org/html/...

That said, my preference would be for the two documents to be
published as RFCs (due to the fact that an internet draft is intended
to be an ephemeral document), perhaps with a note to the effect that
they represent unfinished work and the opinions of the authors. I'll
let the IESG flip that coin, and if they would like to invite the
authors to publish them through the RFC Editor process, to do so.

idnits 1.118

tmp/draft-ietf-v6ops-ipsec-tunnels-04.txt:


Checking nits according to http://www.ietf.org/ID-Checklist.html:

Checking conformance with RFC 3978/3979 boilerplate...

the boilerplate looks good.

No nits found.

Checking nits according to http://www.ietf.org/ietf/1id-
guidelines.txt:
Nothing found here (but these checks do not cover all of
1id-guidelines.txt yet).

Miscellaneous warnings:
None.

Experimental warnings:
None.

No nits found.

> Has the document met all formal review criteria it needs to, such
> as the MIB Doctor, media type and URI type reviews?

yes

> Has the document split its references into normative and informative?

yes

> Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state?

no. This document is informational, and all of the normative
references are RFCs.

> Are there normative references that are downward references, as
> described in [RFC3967]? If so, list these downward references to
> support the Area Director in the Last Call procedure for them
> [RFC3967].

No, there are not.

> Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body of the
> document?

Yes. The section states that there are no requests made of IANA, and
the document makes no requests of IANA.

> If the document specifies protocol extensions, are reservations
> requested in appropriate IANA registries?

no

> The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Writeup.
>
> Technical Summary

This document gives guidance on securing manually configured
IPv6-in-IPv4 tunnels using IPsec. No additional protocol
extensions are described beyond those available with the IPsec
framework.

> Working Group Summary
> Was there anything in WG process that is worth noting? For example,
> was there controversy about particular points or were there
> decisions where the consensus was particularly rough?

As noted, the recommendation against tunnel mode surprised me, but I
was the only guy it bothered. I would not describe that as a
particularly rough consensus.

> Document Quality
> Are there existing implementations of the protocol?

There are implementations of IPv6/IPv4 tunneling, of host-router
tunnels, router-router tunnels, and host-host tunnels. With the
exception of describing a host-router tunnel as a site-router tunnel,
everything described in this document is bog-standard.

> Have a significant number of vendors indicated their plan to
> implement the specification?

A significant number already do. Does that count?

> Are there any reviewers that merit special mention as having done a
> thorough review, e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues?

Yes. The Acknowledgments section details a number of reviewers, some
of whom offered text.

> If there was a MIB Doctor, Media Type or other expert review, what
> was its course (briefly)?

The security review looked specifically at the use of IKE in both of
its versions and the issues being raised in the document. It was done
last spring and the result is the present document.

> Personnel
>
> Who is the Document Shepherd for this document?

Asked and answered :-)

> Who is the Responsible Area Director?

David Kessens