[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.