[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec SA establishment through ISAKMP
> From: Titus Peedikayil <titus@routerware.com>
> To: "'ipsec@tis.com'" <ipsec@tis.com>
> Subject: IPsec SA establishment through ISAKMP
> Date: Mon, 2 Mar 1998 21:18:29 -0800
> I would like some clarification on the following thoughts. I have
> assumed that each host has seperate OUTBOUND and INBOUND SADs. They also
> have seperate OUTBOUND and INBOUND SPDs.
>
> i) When a host A sends an ISAKMP proposal payload to host B, would not
> the proposals be based on the INBOUND IPsec policy (SPD) on host A
> (since IPsec SAs are receiver-oriented)? And since the SPIs for the
> proposals are determined by the protocols supported on host A, the tuple
> <destination address, ipsec protocol, SPI> will be unique on host A.
>
> ii) If (i) is correct, then B chooses a proposal based on the OUTBOUND
> IPsec policy (SPD) and returns it in its reply (proposal payload). This
> proposal represents the IPsec processing (or transforms) that B applies
> when it sends data packets to A. So B would create an SA with the
> selected proposal in the OUTBOUND SAD.
>
> iii) If (i) is correct, then steps (i) and (ii) only achieves secure
> communication from B to A. If B too were to initiate a proposal payload,
> then communication could be secured from A to B also just like in (i)
> and (ii). But if the ISAKMP on B does not initiate a proposal payload,
> is there some way for A to force it?
I also stumbled over this question some weeks ago.
I think the current situation is, that we have different keys and
SPIs after the exchange, but the SA is applied in both directions,
that is, INCOMING and OUTGOING rules are updated.
To use these "asymmetric" channels, either the IKE-exchange is to be
declared unidirectional (I mean SA is only used as described in the
question) or there must be a way for B to inform A about it's
own requirements for the current SA request, which could easily be
done by an own SA proposal of B in the first IKE message to A. A
replies in the third message (But this would be a quite great change
to IKE we don't need at this point, I think..., may be IKE V.2)
(everything applies to SAs exchanged under phase II)
However, I wasn't at this list from the beginning, so I would be
interested if this issue was discussed earlier? (May be, the question
first arises with SAD / SPD definitions in architecture document).
Regards
Kai
# Kai Martius #
# Dpt. of Medical CS and Biometrics / Dresden University of Technology #
# PGP Fingerprint: to be compared after download of my key #
# available at http://www.imib.med.tu-dresden.de/imib/personal/kai.html #
# #
# See our project (and me) at CeBit'98 fair Hannover/Germany 19-25.3.98 #
# Infos: http://www.inf.tu-dresden.de/~hf2/cebit98 #
References: