[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is TS agreement necessary?
Mark Duffy wrote:
> 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.
See the recent post in response to Cliff. I was talking 'self
referential' more than recursive. I.e., contextually recursive, not a
recursion of processing or packet.
>> 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.
Because SPDs are supposed to have both tunnel and transport SAs, as
indicated in RFC2401. Making a rule about tunnel SAs excluding other
tunnel SAs or transport SAs from an SPD is clearly not in RFC2401.
>>>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.
What we end up with may require revision of the setup protocol. IKE is
already under revision; it is not productive to require an IKE-compliant
solution.
Joe