Subject: RE: draft-touch-ipsec-vpn-06.txt

From: "Claudio Lordello" <[email-masked]>
Date: Fri, 23 Jan 2004 09:19:16 -0500

> 2) This document does relate to the l3vpn WG, hence it is appropriate
>    for this WG to review the document and raise any issues it feels it
>    has. However, the WG has a number of things it can say, including:
> 
>     - basically OK, no need to bring it into the WG formally, i.e.,
>       just go ahead and publish it as Joe has requested
>     - OK, but here are some things that should be clarified/fixed (and
>       then indicate what they are)
>     - really conflicts with what we are doing and shouldn't be
>       published until some of our other documents are completed (but
>       so far, I don't sense that folk are  saying that) 
>     - technically flawed, should not be published at all. (Again, I
>       don't sense that folk are saying that)

My comments to this draft fall under the second bullet above. The issues that I believe need to be fixed are related to the stated "problems" with routing over IPsec tunnels. I believe the stated problems are the result of a given implementation and are not shared by all implementations of IPsec tunnels. As an example, I quote the first paragraph on the Abstract section:

"It describes how virtual links
 established by IPsec tunnel mode conflict with routing and forwarding
 inside the VN, due to the IP routing dependence on references to
 interfaces and next-hop IP addresses."

As an implementor who has developed an IPsec implementation which allows routing over IPsec tunnels without the issues described on the draft, I have to disagree with such an statement.

For the record, I have no problem with the draft's proposed "IP tunnel + IPsec-transport" approach. It is a viable approach to the problem, as it is a pure "IPsec tunnel", or yet, a "GRE tunnel + IPsec-transport" which does not get mentioned in the draft but has been available for a while from some vendors.

Claudio.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 23 Jan 2004 15:38:00 +0100

Claudio,

Claudio Lordello wrote:
> My comments to this draft fall under the second bullet above. The
> issues that I believe need to be fixed are related to the stated
> "problems" with routing over IPsec tunnels. I believe the stated
> problems are the result of a given implementation and are not shared
> by all implementations of IPsec tunnels. As an example, I quote the
> first paragraph on the Abstract section:
> 
> "It describes how virtual links established by IPsec tunnel mode
> conflict with routing and forwarding inside the VN, due to the IP
> routing dependence on references to interfaces and next-hop IP
> addresses."
> 
> As an implementor who has developed an IPsec implementation which
> allows routing over IPsec tunnels without the issues described on the
> draft, I have to disagree with such an statement.

I agree that routing can work over a topology built from IPsec tunnel 
mode SAs, and we list several alternative approaches in the ID. Our 
point is that 2401 (and 2401bis, if I read it correctly) is 
underspecified in this regard - a compliant implementation will not 
neccessarily support dynamic routing over tunnel mode SAs.

What our draft proposes is another method for constructing a secure 
virtual topology out of IPIP tunnels and IPsec transport mode. Our 
alternative neccessarily supports dynamic routing due this composition. 
(And has the nice side effect of being much simpler, at least in my 
opinion, but that is beside the point here.)

We suggest using this alternative approach, instead of complicating 
IPsec with further constraints that will establish dynamic routing 
functionality for tunnel mode on all implementations.

As for the sentence you quoted, I agree that re-stating it may be 
useful. What do you think about this instead:

"It describes how virtual links established by IPsec tunnel mode
can conflict with routing and forwarding inside the VN, due to the IP
routing dependence on references to interfaces and next-hop IP
addresses."

Lars
-- 
Lars Eggert                                     NEC Network Laboratories