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

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 12 Dec 2006 14:51:25 -0800 (PST)

David,

Thanks for the review.  I am trying to understand the "interface"
related comments that you made.

>Section 5.2 discusses the consequences of whether the endpoint
>of an IPsec tunnel-mode SA is modeled as an IPv6 interface or
>not.  It should say that there is always an IPv6 interface at
>the endpoint of a IPv6-in-IPv4 tunnel, and the discussion of
>whether to model the SA as an interface is concerned with
>whether the functionality of an IPv6 interface is realized by
>the IPsec SA or outside of it.
>
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.
If in addition to the above, IPsec creates an interface and hence visible to routing 
so that it can get packets matching the route pointing to the
interface rather than through "traffic selectors matching". By
this it means that IPsec is modeled as an interface.
These are the models that this document is talking about. So, how
can we say that there is always an interface ? Could you clarify further ?

-thanks
mohan

>It should also be stated that all uses of the word "interface"
>refer to an IPv6 interface, and that the phrase "tunnel interface"
>refers to an IPv6 interface at the endpoint of an IPv6-in-IPv4
>tunnel, independent of whether the tunnel is realized by IPsec
>tunnel mode.  The end of Section 1 would be a good place to
>do this.  The use of the phrase "IP interface" in Section A.1
>is considerably clearer than the use of "interface" without "IP"
>n Section 5.2 - using "IP interface" throughout Section 5.2
>(and for that matter the entire draft) would improve readability.

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

---

From: [email-masked]
Date: Tue, 12 Dec 2006 18:38:58 -0500

Mohan,

> If in addition to the above, IPsec creates an interface and hence
> visible to routing  so that it can get packets matching the route
> pointing to the interface rather than through "traffic selectors
matching".
> By this it means that IPsec is modeled as an interface.

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".  For a host, there is
an IPv6 interface somewhere in the stack between the application and
the wire.  That is the basis for the statement that "there is always
an IPv6 interface at the endpoint of an IPv6-in-IPv4 tunnel".

For the IPv6-in-IPsec-in-IPv4 protocol stack in this draft, you describe
two different approaches to achieving the functionality.  For the first
one:

> software module that is neither visible as an interface nor in the
> routing tables.

There is an IPv6 interface above IPsec, and then the traffic gets
handed to the IPsec selectors to deal with.  For the second one:

> If in addition to the above, IPsec creates an interface and hence
> visible to routing  so that it can get packets matching the route
> pointing to the interface rather than through "traffic selectors
matching".
> By this it means that IPsec is modeled as an interface.

The IPv6 interface is part of the IPsec implementation.

I would like to see the draft discuss where the IPv6 interface is
located as opposed to the current text that could imply that there
may not be an IPv6 interface.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Dec 2006 16:32:59 -0800

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  

On Dec 12, 2006, at 3:38 PM, [email-masked] 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".

---

From: [email-masked]
Date: Wed, 13 Dec 2006 01:29:55 -0500

Fred,

Many thanks for the longer explanation.  There is one slight twist -

> 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

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

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:[email-masked]] 
> Sent: Tuesday, December 12, 2006 7:33 PM
> To: Mohan Parthasarathy; Black, David
> Cc: [email-masked]; [email-masked]; Pekka Savola; 
> [email-masked]; David Kessens; Lindqvist Erik Kurt
> Subject: Re: Gen-ART review of draft-ietf-v6ops-ipsec-tunnels-04.txt
> 
>