Re: Is TS agreement necessary?

[Mark Duffy <mduffy@quarrytech.com>]

At 01:43 PM 4/11/02 -0700, Joe Touch wrote:
>Mark Duffy wrote:
>> At 06:08 PM 4/5/02 -0800, Joe Touch wrote:
>> 
>>>Lars Eggert wrote:
>>>
>>>>Stephen Kent wrote:
>>>>
>>>>
>>>>>RFC 2401 is reasonably clear in noting that the SPD is nominally per 
>>>>>interface. What sort of management interface is provided to a client 
>>>>>is up to the vendor, so long as one can achieve the same effects as a 
>>>>>per-interface SPD.  Otherwise, the implementation would not be compliant
>>>>
>>>>As a side note, I misunderstood this for a long time to mean "SPD per 
>>>>PHYSICAL interface", which is not sufficient (because of ambiguities via 
>>>>multiple matching tunnel-mode SAs in the same per-physical-interface 
>>>>SPD). When viewing tunnel mode SAs as virtual interfaces in their own 
>>>>right that have separate SPDs associated with them, these problems 
>>>>dissapear. Maybe that's part of the confusion around tunnel mode...
>>>>Lars
>>>
>>>Hi, Steve,
>>>
>>>One of the confusions I have is regarding systems that say they use 
>>>these tunnel mode SAs as virtual interfaces. It seems that the tunnel SA 
>>>has to be in the SPD of the underlying interface, but they only work if 
>>>the SA is in the SPD of the virtual interface (i.e., inside the tunnel). 
>>>That seems self-referential... ??
>>>
>>>Jo
>> 
>> I'm not Steve but I'll pipe up anyway :-)
>> It doesn't seem any problem on the outgoing side -- first the forwarding
>> decision selects the outgoing interface (the tunnel).  Then the SPD for
>> that virtual interface is consulted (and it has all-wildcard selectors for
>> the single tunnel mode SA).  The packet is encapsulated and a new
>> forwarding decision made.
>
>As per other mail to PPVPN, the issue is that the SA of the tunnel 
>appears in the SPD of the tunnel itself.  That seems recursive.

The SA that realizes the tunnel is associated with the SPD of the virtual
(tunnel) interface.  Thee is no recursive consulting of the same SPD.

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.

>                                                                It seems 
>that the SA of a tunnel should appear in the SPD of the interface (real 
>or virtual) that the tunneled packet will be emitted on.

Why?  That would defeat the logical separation  between the overlay and the
underlying network that the overlay is aiming to achieve.

>
>> When we are the IKE responder, there is some potential ambiguity.
>
>I'm not speaking about IKE at all, FWIW.

OK, but for IPsec to be used in this manner, the IKE side of things needs
to work too of course.

>Joe
>