[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is TS agreement necessary?



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... ??
>
>Joe

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.
When we are the IKE responder, there is some potential ambiguity.  To
resolve this there needs to be a way to associate the incoming proposal
with the SPD associated with the virtual interface.  One way to do this is
to use the destination IP address in that case to select the right SPD.

Mark