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

Misc. issues: Inbound SA triple identification / Inbound&Outbound SA, selectors exchange

Hi,

After reading most IPSEC related RFCs and various books, and discussing
with many people, I am still bumping on the following issues. Hopefully
some of you have already been though these questions and can give me
some hints or a different point of view.

1.
SA definition (RFC 2401, section 4.1, p. 8).
In most places it is said that one of the three keys to identify an SA
is the IP destination address: but he meaning of "destination" is
different depending on wether we deal with an inbound or outbound SA.

For an outbound SA, the destination address is actually the right key.

For an inbound SA, the IP address wich allows us to uniquely identify an
SA, along with the SPI and the protocol, is the SOURCE IP address. There
is no reason why two remote peers would not allocate the same SPI. I'd
say we even need to consider the source IP address of the cryptographic
endpoint: in tunnel mode we need to know the IP address of the IPSEC
tunnel endpoint in order to uniquely identify the SA for an incoming
packet.

Is this correct?

2.
My understanding is that Inbound and Outbound SAs derived from a single
Phase 2 negotiation only differ by their Key (because they have
different SPIs). Everything else is identical: same IPSEC protocol, same
transform, same lifetime, and the selectors are symmetric.

Is this correct?

If yes I never understood how the lifetime in kiloBytes is working: I
mean is it applied to each SA or to both SAs together (inbound +
outbound
traffic).

3.
Policy Decisions/Selectors/ID Payloads

ID payloads are used to pass selectors from Initiator to responder in a
Phase 2 exchange.
ID payloads are optional in Quick mode: does this mean that when they
are not included this is a request to establish an SA for ALL traffic
between the ISAKMP peers?

What about Phase 1 SAs? Port and Protocol fields are set to 0 in ID
payloads of a Phase 1 exchange. RFC 2408 (section 2.3 p. 16) says two
ISAKMP peers "can" negotiate (and have active) multiple ISAKMP SAs. Is
this something each implementation MUST or MAY support?? How does each
peer decide to use one IKE SA rather than another one?



Sorry for asking so many questions at once...


Any light you can shed on any of these issues would be greatly
appreciated!!!


Thanks & Regards,

Emmanuel Hislen.

--
Emmanuel Hislen
Lucent Technologies INS
Follow-Ups: