Subject: I-D ACTION:draft-ietf-v6ops-ipsec-tunnels-00.txt

From: [email-masked]
Date: Mon, 11 Jul 2005 10:50:01 -0400

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-ipsec-tunnels-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 11 Jul 2005 19:24:07 +0300 (EEST)

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Elwyn Davies <[email-masked]>
Date: Sat, 16 Jul 2005 13:21:17 +0100

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)