Re: Is TS agreement necessary?

[qzhang@aber-networks.com]

is it the same as the "adjacent SPD"? i.e. a packet got
ESPed via SPD entry 1, then
AHed via another SPD entry 2 pointed to from the SPD
entry 1 ?

----- Original Message -----
From: "Joe Touch" <touch@ISI.EDU>
To: "Mark Duffy" <mduffy@quarrytech.com>
Cc: "Lars Eggert" <larse@ISI.EDU>; "Stephen Kent"
<kent@bbn.com>;
<kalyan@juniper.net>; "ipsec mailling list"
<ipsec@lists.tislabs.com>
Sent: Friday, April 12, 2002 3:37 PM
Subject: 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.
>