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

[Joe Touch <[e-mail]>]

Mark Duffy wrote:

> 
>>   - 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 :-)

1) that's the policy
2) as I've stated, and as is available in the archives, we did as 
several WGs even before the IESG did.

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

It was embodied in this draft in 3/2000, and described in normative
publications of our project since 2000 as well.

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

Please review the IPsec WG mailing list archives on this issue. Rigidity 
is the defining characteristic of security specs (if not all specs, 
hopefully).

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

2401 cannot mandate only firewall-like (policy-based) approach; that
would defeat BITW architectures, which are specifically supported.

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

That has already been corrected in an update that is pending this final
IESG review.

> 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

That's in section 4.2.4 (IKE impact), and has been reviewed by the IPsec WG.

Joe