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

[Fred Baker <[e-mail]>]

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