[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKE negotiation/rekeying problem with RSIP


>
>>>>>> "Saint-Hilaire," == Saint-Hilaire, Ylian <ylian.saint-hilaire@intel.com>
>writes:
>    Saint-Hilaire,> There is a possible problem IKE initiation/rekeying over
>    Saint-Hilaire,> RSIP. If two inner computers use an RSIP gateway to
>    Saint-Hilaire,> establish IPsec sessions to one destination, the
>    Saint-Hilaire,> destination computers will see 2 IKE phase1's from the
>
>  1) this in itself may be a problem for some gateways.

well, they should be separate phase 1 because they must use
different cookies. that's what the cookie parameter in rsip support
for ike is for. the initiator/responder cookie pair in phase 1 is the
isakmp spi. from isakmp (rfc 2408):

	In the case of ISAKMP, the Initiator and
       Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,...

so they should be seen as separate phase 1 sa's. this goes hand in hand
with the requirement to not rely only on IP address for authentication.
IDii and IDir must be exchanged (from the rsipsec draft).

>
>    Saint-Hilaire,> gateway. If the destination computer ever needs to rekey
>    Saint-Hilaire,> a phase 2 or negotiate a new phase 2, he may select an
>    Saint-Hilaire,> incorrect phase 1 to negotiate with.
>
>  2) worse, they can't both get UDP port 500. There are choices to resolve
>this:
>	a) permit initiators to use other than port 500, and have the
>	remote gateway respond to the correct port.
>

i asked for this back in orlando (dec 98). these are my slides for
the presentation i gave at the ipsec wg to ask for this (the DOI
document is very explicit about not allowing these port numbers
to vary, at least for purposes of including themin the hash):

	http://playground.sun.com/~gab/talks/ipsec-nat-issues.PDF

note: see slides 7-9 in the above. i got no answer from the working
group on this matter, so i decided not to rely on ports for 
demultiplexing...

>	b) have the gateway demux based upon cookies instead of port numbers.
>	This makes the gateway aware of IKE, but it needs to know proto 50/51
>	anyway.

this has been in the draft since 00. please see sections 3 and 5.1 in

   http://www.ietf.org/internet-drafts/draft-ietf-nat-rsip-ipsec-01.txt

notice that the draft does allow use of ports other than 500, but does not
assume this is possible, hence the cookie parameter negotiation.

so given that (1) the draft already spells out the requirements at the end of
section 3 as follows:

   To prevent Y from mistakenly deriving the identity of its IKE
   peer based on the source address of the packets (Nb), X MUST
   exchange client identifiers with Y:

      - IDii, IDir if in Phase 1, and

      - IDci, IDcr if in Phase 2.

   The proper use of identifiers allows the clear separation
   between those identities and the source IP address of the
   packets.

that (2) phase 1 sa's are uniquely identified by the spi comprising
the initiator/responder cookie pair
is there still a problem?

-gabriel
Follow-Ups: