Subject: draft-ietf-v6ops-ipsec-tunnels-01.txt

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Aug 2005 15:24:52 +0300 (EEST)

Hi,

There were no WGLC comments.  An update has been sent to the 
secretariat.  The issue tracker has been updated at:

http://www.netcore.fi/pekkas/ietf/temp/ipsec-tunnels.html

The updated draft is also available there.

On Sat, 16 Jul 2005, Elwyn Davies wrote:
> 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 [email-masked] 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.
>> 
>

-- 
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: Pekka Savola <[email-masked]>
Date: Thu, 25 Aug 2005 15:24:52 +0300 (EEST)

Hi,