[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-des-md5-00.txt
In article <9605012213.AA21306@secpwr.watson.ibm.com> Pau wrote:
>For now, I am using addresses. But addresses may not work if NAT
>(network address translation) is used.
For what its worth, NAT is increasingly commonplace in the deployed Internet.
>SPI may be a candiate, but the two sides may choose the same SPI value.
Hence, SPI is probably not a good general solution.
>Perhaps this problem
>should be resolved at IKMP layer rather than at IPSEC layer ?
Yes. IKMP layer functions need to create an _entire_ IPsec Security
Association (not just the key) and put that into place on both sides of the
session. The IPsec layer only deals with whole IPsec Security Associations
that have already been created either manually or dynamically (just the
key alone is not sufficient and doesn't conform with the RFCs).
>The only thing the IKMP layer needs to do is to give IPSEC layer
>a 1-bit flag to indicate direction.
False. IKMP must give the IPsec layer an _entire_ IPsec Security
Association, not just a key and a direction bit. In fact, a direction bit
probably is not part of the explicit Security Association. Direction is
clear from the Security Association because the Security Association
contains the destination address as one of its component.
>I know that <I-cookie, R-cookie> and <R-cookie, I-cookie> pairs
>can be used to derive 2 uni-directional keys. But can IPSEC assumes
>cookies will always be used ?
It is not clear to me what you mean by "IPsec" in the above text.
Ran
rja@cisco.com
References: