Hi,
Does anyone else have preference on this?
To me, it seems that if more (general) information is added on interfaces,
it should probably go near the last (added) paragraph in Section 1. That
said, at least to me (personally) the proposed text below seems too
lengthy and too detailed for this document.
I'm also not sure how helpful the text is in the sense that nodes quite
often have a lot of various virtual and pseudointerfaces (just for these
kinds of purposes) which are shown in SNMP MIB modules (such as Interface
MIB) but there is no (easy) way to see them otherwise.
On Thu, 18 Jan 2007 [EMAIL PROTECTED] wrote:
The -05 version is much better - it's sufficiently improved to remove
the Discuss in the draft's current form. Nonetheless, 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. This is close to the limit of what I'd be comfortable
doing with an RFC Editor Note, but I think this would significantly
improve the clarity of the "what is an interface?" confusion that
I stumbled over in the original review.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
-----Original Message-----
From: Pekka Savola [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 18, 2007 3:11 AM
To: Black, David
Cc: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt
Hello David (B.), Brian,
A new version of the draft has been submitted. We believe it
addresses
your comments. Please check it out. This was the only DISCUSS.
http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-ipsec-tunnels/
Below are a few notes where it isn't 100% clear whether the
desired impact
was achieved.
- section 5.0 almost in its entirety (most text moved from
deleted section 5.2).
NOTE: I think section 5 is still a bit unclear of when
"interface" refers
to "IP interface" and when "tunnel interface".
NOTE: we also now explicitly state that ingress filtering
configuration
must be applied manually [it cannot be negotiated as part of
IKE or IPsec
configuration, for example]. This is likely good enough, but I think
David Black was looking for a bit more than that -- unfortunately, I
don't think any IPsec-side automation can be provided..
On Sat, 9 Dec 2006 [EMAIL PROTECTED] wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-v6ops-ipsec-tunnels-04.txt
Reviewer: David L. Black
Review Date: 9 December 2006
IESG Telechat date: 14 December 2006
Summary:
This draft is on the right track, but has open issues, described
in the review.
Comments:
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.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
