[Gen-art] RE: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt

[[e-mail]]

Fred,

Many thanks for the longer explanation.  There is one slight twist -
this draft is dealing entirely with IPv6-in-IPv4 tunnels, so in:

> Ideally, that means that first IPv6 has to decide which interface is  
> used by the route to the destination as a next hop interface, select  
> the source address from the interface, let IPSEC sign or encrypt the  
> message, add the IPv6 header, and then hand the datagram to the  
> device driver. In a purely layered sense, that is borderline bizarre.

> So what I understand existing implementations to do is select an IP  
> address a priori (there often is only one interface, so selecting the

> most global address available is an algorithm that always works), do  
> the IPSEC part, do the IPv6 part, and let IPv6 hand the thing to a  
> device driver. That's what Mohan is describing.

The second header is an IPv4 header, and IPv4 controls the dispatch
to the device driver (which may be unable to deal with IPv6).  In this
case, there is both an "IPv4 interface" (deals with the device driver)
and an "IPv6 interface" (drops the packet into IPsec).  The a priori
address selection technique still works, but there are both IPv6 and
IPv4 addresses to be selected.  In any case, as you say:

> Trust me, at least from the perspective of a network management  
> model, anywhere an IP datagram potentially leaves the box there is an

> IPv6 interface. Internally, it's what tells you that "on this device,

> when you send an IPv6 datagram to a given immediate neighbor, whether

> router or host, you call <this> driver and do <this> with the 
> datagram".

In this case, the IPv6 datagram is leaving encased in an IPv4 header,
so both "interfaces" believe they've sent a datagram, and the notions
of "immediate neighbor" are different for IPv4 vs. IPv6.

Thanks,
--David

> -----Original Message-----
> From: Fred Baker [mailto:[e-mail]] 
> Sent: Tuesday, December 12, 2006 7:33 PM
> To: Mohan Parthasarathy; Black, David
> Cc: [e-mail]; [e-mail]; Pekka Savola; 
> [e-mail]; David Kessens; Lindqvist Erik Kurt
> Subject: Re: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt
> 
> 
> On Dec 12, 2006, at 2:51 PM, Mohan Parthasarathy wrote:
> > In some implementations e.g., linux, to protect the traffic using  
> > IPsec tunnel mode SA, traffic matching the selectors is given to  
> > IPsec for protecting the traffic. IPsec is just another software  
> > module that is neither visible as an interface nor in the routing  
> > tables. By this it means that IPsec is not modeled as an interface  
> > at all.
> 
> On Dec 12, 2006, at 3:38 PM, [e-mail] wrote:
> > Let's start with a router.  In order for a router to forward an  
> > IPv6 packet, it has to send it through an IPv6 interface, hence,  
> > somewhere between where the forwarding table is consulted and where

> > the packet hits the wire, there is an "IPv6 interface".
> 
> I think you guys are looking at two sides of one coin.
> 
> IPSEC maintains its security association between a source and a  
> destination IP address. As such, while one wants to call IPSEC before

> handing the datagram to IP (whether v4 or v6), in doing so one must  
> predetermine which IP address will be used, which potentially implies

> which interface the datagram will be sent from. This would be  
> consistent with RFC 1122's statement on page 62:
> 
>              (B)  A host MAY restrict itself to sending (non-source-
>                   routed) IP datagrams only through the physical
>                   interface that corresponds to the IP source address
of
>                   the datagrams.
> 
> Ideally, that means that first IPv6 has to decide which interface is  
> used by the route to the destination as a next hop interface, select  
> the source address from the interface, let IPSEC sign or encrypt the  
> message, add the IPv6 header, and then hand the datagram to the  
> device driver. In a purely layered sense, that is borderline bizarre.

> So what I understand existing implementations to do is select an IP  
> address a priori (there often is only one interface, so selecting the

> most global address available is an algorithm that always works), do  
> the IPSEC part, do the IPv6 part, and let IPv6 hand the thing to a  
> device driver. That's what Mohan is describing.
> 
> In a router, where IPSEC is usually in tunnel mode and one interface  
> is as good as another, the need for IPSEC use and the set of security

> associations used on a given interface (eg, from that interface's  
> address) is an attribute used in forwarding the IP datagram. At the  
> point where IP is about to copy the link layer header onto the head  
> of the datagram, it asks what kind of link layer is in use. One kind  
> of "link layer" requires the addition of an IPSEC header, another IP  
> header, and a link layer header. That's what David is describing.
> 
> Mohan, any time a system, host or router, sends a datagram, it has to

> account for having done so using the RFC 2863 Interface MIB, it has  
> to determine whether the ability to send datagrams is currently  
> administratively enabled. It derives ifIndex from the route entry  
> (see InetCidrRouteEntry in RFC 4292) that it uses to forward the  
> datagram, or from the IpDefaultRouterEntry described in RFC 4293.  
> This table is "the interface" from a management and configuration  
> perspective, and is found near whatever the software is dealing with  
> internally. This is what David is asking about.
> 
> Trust me, at least from the perspective of a network management  
> model, anywhere an IP datagram potentially leaves the box there is an

> IPv6 interface. Internally, it's what tells you that "on this device,

> when you send an IPv6 datagram to a given immediate neighbor, whether

> router or host, you call <this> driver and do <this> with the 
> datagram".
> 
> 

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art