[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: More questions on ID types
Vipul,
> According to the latest ISAKMP draft, the only ID types allowed in
> phase I are: ID_IPV4_ADDR, ID_IPV6_ADDR, ID_IPV4_ADDR_SUBNET,
> ID_IPV6_ADDR_SUBNET. With the reasoning above, I can see how the
> first two make sense as IDs for phase I. However, the latter two
> ID types seem more appropriate for use in phase II.
>
> I have some concerns about limiting phase I IDs to these
> four types.
I agree and see no reason why the ID values should be
restricted to the 4 types listed in the ISAKMP appendix.
I think there is another problem however. For the mandatory
case of Authentication with Pre-Shared Key & Main Mode, it
seems to me that the ID payload is in the "wrong" message.
The pre-shared key needs to be accessed before the message
with the ID payload can be decrypted. The spec says that the
key can only be identified using the (source) IP address of
the incoming ISAKMP message. This doesn't work if the remote
party only has a temporarily assigned IP address. Also
if a host or gateway is multihomed, the source IP address
may change, depending on which outgoing interface was used
to reach the destination. The ISAKMP spec could specify that
a single IP address be used as the source IP address of an
ISAKMP UDP message, no matter what outgoing interface was
used, in order to reduce the configuration burden, but it
would be better to remove the need to look at source IP
address at all (which is the same as IPSEC where source
IP address is not used to identify SAs)
Thus perhaps it would be better for the Pre-Shared key case
to include the ID payload in the 3rd and 4th messages
of the exchange (the ones that transfer the D-H public info
and the nonces), rather than in the 5th and 6th. This removes
the need to look at source IP address at all, and would be
similar to the Authentication with Encryption exchange.
Bryan Gleeson
Shasta Networks.
Follow-Ups: