Re: draft-touch-ipsec-vpn-06.txt

[Mark Duffy <[e-mail]>]

>   - Does the l3vpn working group feel that this document should be
>reviewed by a public working group, such as the l3vpn working group,
>prior to publication?

I would think that should be more a matter of ietf policy regarding 
personal submission RFCs than what any wg thinks.  Unless the policy is to 
ask relevant wg's :-)


>   - Do we have any technical comments on the document?

The basic concept of forming virtual links by first applying IP-in-IP 
tunnelling, then securing them by applying transport mode IPsec to the 
resulting packets seems a good one to me.  (And it is already embodied in 
at least one document that is a product of this wg.)

As an aside, I would be quite interested for the working group to take on 
the effort to progress a *standard* for virtual links.  It should go a step 
further and provide a way to convey to the far end what vpn context a given 
tunnel is for.  Those deeply interested in this subject might want to look 
at <http://www.ietf.org/internet-drafts/draft-duffy-ppvpn-ipsec-vlink-00.txt>
which provides a survey of issues in this space and of potential solutions.

Anyway, back to draft-touch.

I think the basic approach presented is sound and appropriate.  I do think 
the message gets a little lost in all the description of other possible 
approaches  and why they don't work.  I found those descriptions difficult 
to follow.

The draft expresses an interpretation of RFC 2401 that I believe is 
excessively rigid and literal.  E.g. in concluding that transport mode may 
not be used between two gateways, and that protocol #4 encapsulations must 
be skipped past in evaluating SPD policy to look for a transport header 
deeper in the packet.

The draft on page 7 states:
   There are two common implementation scenarios for tunnel mode SAs:
    One is based on firewall-like packet matching operations where tunnel
    mode SAs are not virtual interfaces, another is tunnel-based, and
    treats a tunnel mode SA as a virtual interface. The current IPsec
    architecture does not mandate one or the other.
This is completely outside my understanding of RFC 2401.  2401 is 
completely oriented towards the policy based approach.  I am unaware that 
it provides in any way for treating a tunnel mode SA as a virtual 
interface.  In fact it does much to obstruct that viz. SPD policy and 
packet selectors.

Nit: the link numbers on figure 3 do not seem to match some references to 
them in the preceding paragraphs.

Previous revisions of this document contained the concept that if one sends 
an IKE proposal for transport mode protection for protocol #4, then one is 
signalling the intent that the tunnel is to be considered a virtual 
link.  Perhaps that has been removed because offhand I cannot find it.  I 
thought that was undesirable because it imposes a new meaning onto a 
possibly pre-existing behavior, and it is implicit rather than explicit.

Regards, Mark