Re: Is TS agreement necessary?

[Mark Duffy <mduffy@quarrytech.com>]

Hi Lars,

At 11:58 AM 4/12/02 -0400, Lars Eggert wrote:
>Mark Duffy wrote:
>> Consider a hypothetical device that has 2 conventional interfaces and
>also
>> implements an overlay network using IPsec to implement a single
>virtual
>> interface.  The device does not have any IPsec policy (SPD) active on
>the
>> conventional interfaces (all packets are "pass").  A forwarding
>decision
>> (e.g. L3 routing) is made in the overlay context to send a particular
>> packet out via the virtual interface.  The SPD associated with  the
>virtual
>> interface is consulted and it contains a single entry with wildcard
>> selectors (match all packets) that says apply tunnel mode IPsec to all
>> packets and send them to remote peer p1 (addressed in the non-overlay
>> space).  An SA is negotiated using IKE, if it does not already exists.
>The
>> packet is encapsulated in a tunnel mode IPsec packet whose destination
>> address is p1.  That packet is then processed as a "new" packet by the
>L3
>> forwarding in the non-overlay context.  L3 forwarding selects one of
>the
>> conventional interfaces as the exit interface and the packet is sent.
>
>In this example the "interface" is a do-nothing pseudo construct that 
>serves no other purpose than holding a tunnel mode SA (see section 3.2 
>of our ID for a discussion). This approach requires a different pseudo 
>interface for each SA, and each SA associated with such an interface 
>MUST be tunnel mode.

I understand your words but I don't think I understand your overall point
here.  The reason we create such a virtual interface, is because *we want
to* so that we can represent it as the next hop for IP routes in a
forwarding table, and also so we can run an IGP over it.  In fact, I think
that is the basic problem we are trying to solve here.

Question: In the IIPtran implementation, are the IP-in-IP tunnels
manifested as virtual interfaces?


>Network interfaces are characterized by the encapsulation the perform 
>(e.g. Ethernet, etc.) The pseudo interface you propose does not perform 
>such on operation by itself, but depends on IPsec to perform the 

Whether the IPsec encapsulation is performed by a "separate module" vs
whether the ethernet encap is performed by a "separate module" (separate
from what, in fact?) seems to me irrelevant from a standards perspective.
Either way, some encap gets added.  It just varies in size and complexity :-)


>required encapsulation, and only functions correctly when restrictions 
>on the contents of its SA are enforced. This seems awfully complicated.
>
>Also note that the destinction between tunnel mode and transport mode 
>begins to dissappear, since you tunnel mode SAs MUST be associated with 
>non-encapsulating pseudo-interfaces, while transport mode SA MUST be 
>associated with regular interfaces. Encapsulation is a function of the 

Ah, this relates to section 3.2 of draft-touch, I believe.  And this is a
point I have not understood during this discussion.  I agree that the
virtual interfaces would use tunnel mode, for the needed encapsulation.
But I don't see why any other use of IPsec, such as that applied pursuant
to SPD policy for each conventional interface, would be restricted in
whether it could be tunnel mode or transport mode.

Restated, I should think "traditional" use of IPsec based on per-interface
SPD is and can continue to be free to use tunnel mode or transport mode.
And, quite separate from that, there is an application for IPsec *tunnel
mode* cast as a virtual tunnel interface.  BTW, IIPtran could equally be
used for the virtual tunnel interface.  Makes sense?

>interface, not one of IPsec.
>
>Lars
>-- 
>Lars Eggert <larse@isi.edu>               Information Sciences Institute
>http://www.isi.edu/larse/              University of Southern California
>