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

From: "Paul Knight" <[email-masked]>
Date: Thu, 22 Jan 2004 16:15:51 -0500

Hi all,

In response to Ross's original question, I would like to support the Touch
draft progressing as an Informational RFC, since in my opinion it does a
very good job of describing the basic transport/tunnel dilemmas for dynamic
routing.  The Touch draft is largely a theoretical approach, although it is
based on experience with the X-bone project.  As Joe says, it has been
discussed in the past in both IPSEC and PPVPN, and definitely provided the
impetus to the modifications to RFC2401 regarding transport mode.  The IPSEC
group had no objections to the draft, and as Joe says, suggested that it be
published as Informational.  I think it is a very useful reference point for
further work, and it would be a mistake to try to expand its scope to deal
with the whole range of transport-vs.-tunnel issues.

I also agree with Eric that it will be valuable to develop a separate L3VPN
WG draft which focuses on the issues of using an IPsec SA as a routing
adjacency, and related issues of specifying the next-hop, ordering the
processing of routing and SA lookup, etc.  This should be an
implementation-focused RFC.

IMHO, I agree with Joe that my draft 
(http://www.ietf.org/internet-drafts/draft-knight-ppvpn-ipsec-dynroute-03.tx
t)
may be a reasonable starting point (or at least a source of some text) for
this effort, although it is currently focusing mostly on the transport mode
approach.  It describes an implementation which is very widely deployed.
For a WG draft, it would probably be useful to add balancing text describing
the tunnel mode approach. In addition, I think it should start by developing
a good analysis of how to treat tunnel endpoints as interfaces - or not.  It
also needs to clearly describe the issues of ordering of SA and route
selection, and how to separate the two.  This is really a key point - how to
prevent the routing from compromising the security.  There must be a clear
delineation of the two.  The WG draft may also need to address such issues
as how to handle the loss of routes within the overlay network - how to
prevent the traffic from ending up on a default route, potentially with
unintended security characteristics.

The goal is clearly interoperability.  As my draft points out,
interoperability of dynamic routing (RIP and OSPF) using transport mode
(IIPtran, in the Touch terminology) has been demonstrated between multiple
vendors.  However, this whole area can benefit from some more work.

Regards,
Paul Knight

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Touch
> Sent: Thursday, January 22, 2004 12:53 PM
> To: [email-masked]
> Cc: Ross Callon; [email-masked]; Thomas Narten
> Subject: Re: draft-touch-ipsec-vpn-06.txt
> 
> 
> 
> 
> Eric Rosen wrote:
> 
> > I think it  would be useful to  have an RFC which discusses  the 
> > issues that arise  when you  want to  use  an IPsec  Security 
> > Association  as a  routing adjacency. In fact, it might even be  
> > useful to have a standard way of doing this that would 
> ensure multi-vendor interoperability.
> > 
> > As Claudio points  out, implementors do know how to do  this, and 
> > there have been many products on the market for years that 
> do this.  Whether they do it
> > in  an  interoperable  manner  is  another question.   
> Whether  this  is  in
> > violation of the IPsec standard is a further question.
> > 
> > I'd have  thought that a draft  on this topic, even  an 
> informational 
> > draft, would need the approval of the IPsec WG.
> 
> The IPsec WG already decided on this issue and suggested how 
> to proceed
> - in the manner we are already doing.
> 
> > I am concerned about the fact that
> > the IPsec WG has failed to progress this draft.
> 
> It was never an IPsec WG document. The time delay is largely 
> due to input from other WGs who 'discover' it and want to 
> revisit issues that have already been covered ;-)
> 
> > Given that there are many deployed  products that do routing over 
> > IPsec, I'd think  an informational  draft on  the topic  
> would benefit  
> > from  making it clearer  what the existing  practices and  
> what the  
> > interoperability issues are.
> 
> The doc already discusses interoperability (i.e., that 
> transport mode/IP tunnel and tunnel mode interoperate on the 
> wire), and lists the various approaches in detail.
> 
> > With  regard  to the  draft's  relation to  L3VPN,  the  
> L3VPN charter  
> > does unfortunately include  "CE-based VPNs using IPsec".  
> Unless  this 
> > is removed from the charter (which would be a good thing imho), I 
> > think it would be odd for an individual draft on the topic to be 
> > published.
> 
> The current CE-based L3VPN docs already cite this draft, 
> directly or indirectly. CE-based L3VPNs are only one way our 
> draft might be used; there are places where dynamic routing 
> is used independent of a CE-based solution.
> 
> Our draft - and our work for several years - is more closely 
> associated with the IPsec WG due to the more direct impact on 2401bis.
> 
> Paul Knight had an earlier summary of the various techniques 
> for doing 
> tunnels and their interaction with routing - which includes 
> refs to our 
> draft - and is more closely the summary and L3VPN-focused draft that 
> you're proposing. You might want to solicit that document to focus on 
> L3VPN issues.
> 
> Joe
> 
> 
> 
>