[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some questions
On 12 May 98 at 8:51, Daniel Harkins wrote:
> Privyet Valery,
Hi Dan,
thank you for your answers. You seem to know russian :-)
> > ISAKMP, for example, using DES in one direction and IDEA in the
> > other, that might be useful under some circumstances.
>
> Yes, that's right, they must use the same transform. Under what situations
> would you want to have asymmetrical SAs?
In case of asymmetrical path or when you know for sure, that
information, flowing in one direction, is much more important than in
the other. Note, that not only transform, but entire protection suit
(e.g. - SA bungle) must be the same in both directions. So, you
cannot use, for example, transport mode in one direction and tunnel
in the other. Note also, that IPsec itself doesn't impose such
limitation (one can create asymmetrical SAs manually), it is
ISAKMP/IKE that does it. Anyway, I don't think it is important for
the most of cases in real life, but there can be a few very special
cases when this lack of flexibility of ISAKMP/IKE may be undesirable.
It's possible just not to pay attention for such cases...
> > 2. Regarding previous question: when protection suite (e.g. sequence
> > of SAs) is negotiated, what should be the order of appliance of those
> > SAs when processing an outgoing packet? Should it be the same as the
> > order in which their proposals appear in the ISAKMP SA Payload? It is
> > very natural, but it seems that IPsec drafts doesn't state this
> > explicitly.
>
> For situations where you negotiate AH and ESP you apply ESP first.
Well, let's imagine situation when responder receives SA payload that
proposes protection suite containing AH and ESP both in transport
mode in the order (I mean order of Proposal payloads) AH, ESP. What
should it do? Should it reject this suite or accept it, but apply SAs
in correct order: ESP, AH (assuming, that peer will do the same,
because the other order is prohibited)?
> Applying multiple AH or multiple ESP transforms to a single packet is not
> defined.
Sorry, but it is defined if you use tunnel mode (Architecture
document, section 4.3, first case of iterated tunnelling), although
marked as "unlikely to be used". But this case isn't prohibited.
Moreover, the order of applying SAs (first ESP, then AH) is defined
only for transport mode SA bundles (as far, as I understand). Tunnel
mode SAs can be applied in any order, so, my second question is still
valid
> Dan.
Thanks,
Valery Smyslov.
References: