The latest version appears to address all the comments that I and others
made, and generally looks good (give or take a few editorial fixes - see
below).
One minor issue with regard to the language used about how to model the
tunnel end-point when specific SPD tunnel mode is used: I am not sure that it
is up to this document to 'require' (s5.3, 2nd para) that they are not
modelled as separate interfaces. What we are saying is that it is not really
possible to build specific SPD tunnel mode on end points modelled as
interfaces... Therefore we recommend that specific SPD tunnel mode end points
should not be modelled as separate interfaces. This is followed through into
the reccommendations in s9 para 2: suggest s/support/recommend/. There ought
to be a better way of saying this but I can't think what it is at present.
Regards,
Elwyn
A number of language/editorial nits:
s1: Unexpanded acronyms: SA, SPD, ECN (SA is expanded in s2.1)
s2: para 1: s/was mostly/is mostly/
s2: para 3: s/specifies following/specifies the following/,
s/measures./measures:/
s2: paras4/5: make them bulleted paras to clarify that they are the
'following measures'
s2.1: para 1: s/The successful/A successful/
s2.1: last para: s/kind/kinds/
s2.1: last para: Unexpanded acronyms GRE, L2TP (maybe need references).
s2.2: para 1: s/The successful/A successful/
s3.2: next-to-last para: Unexpanded acronyms ISP, CPE
s4: The language in this section may become slightly less clear when the
drafts become RFCs
s4: para 2: s/is defined in [RFC2401] and [I-D.ietf-ipsec-rfc2401bis]/was
originally defined in [RFC2401] now superseded by
[I-D.ietf-ipsec-rfc2401bis]/
s4: para 2: s/IPsec security/The IPsec security/, s/difference/differences/
s4: para 7: Move the first sentence {'IKE is defined in [RFC2409] (which is
referred to as IKE in this document) and in [I-D.ietf-ipsec-ikev2] (which is
referred to as IKEv2 in this document).'} to be the second sentence of para
2. Start a new para after this, substituting s/them/the two versions of the
security architecture/. In the rest of the section - do what the IKE
sentence says - use IKE and IKEv2 consistently - IKEv1 -> IKE, places where
the IKE RFC/draft are used replaced by IKE/IKEv2 (e.g., Bullet point 3), para
6) [Actually IKEv1 seems to be used pretty consistently in the rest of the
document!]
s5: para 1: s/the IPsec tunnel establishment for/establishment of an IPsec
tunnel for the/, s/we'll/we will/, s/look on/look at/
s5: Figure 5: Might be more obvious as a 'boxed' table, maybe with column
headings 'Components (first to last)', 'Contains'. Also presumably the
packet has a payload!
s5.2: para 1: delete 'kind of'
s5.2: para 3: s/whose tunnel endpoint's IPv4 address is/with tunnel endpoint
IPv4 addresses/
s5.2: para 3: s/The implementations/Implementations/
s5.3.1: para 1: s/routing table/the routing table/, s/is passes/is passed/
s5.3.1: para 3: s/prevent/prevent an attacker/
s7: para 2: s/the same way/in the same way/
s7: bullet point 2: s/the NAT changes/where the NAT changes/
s7: last para: s/MOBIKE/The IETF MOBIKE working group/
s8: 1st bullet: s/off-band/out-of-band/
s9: last para: s/is to either tunnel mode with generic SPDs or transport
mode, and applying/is to use either tunnel mode with generic SPDs or
transport mode, and apply/
s11: para 1: s/in the tunnel/into the tunnel/
s11: para 2: s/to the both,/to both/
s11: para 3: IF you use IKE to mean IKEv1 then s/IKE/Either IKE or IKEv2/ -
If you go for IKEv1 explicitly, IKE is finr.
References: Whether RC2401 and RFC2409 are normative is arguable!
App A: para 2: s/associations are/association is, s/interfaces/an interface/
App A: throughout: s/destination/DST/ in rules (some already do)
Pekka Savola wrote:
On Mon, 11 Jul 2005 Internet-Drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IPv6 Operations Working Group of the
IETF.
Title : Using IPsec to Secure IPv6-in-IPv4 Tunnels
Author(s) : P. Savola, et al.
Filename : draft-ietf-v6ops-ipsec-tunnels-00.txt
Pages : 21
Date : 2005-7-11
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.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt
The authors believe that this version addresses all comments sent to date.
There has been substantial revision in the draft. Those who previously
read it are encouraged to take another look and see if it's better. If you
haven't taken a look yet, now would be a good chance.
The issue list is at:
http://www.netcore.fi/pekkas/ietf/temp/ipsec-tunnels.html
There's also a htmlwdiff there.