[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: isakmp doubts
My turn to be on info duty.
>>P.C.Narasimha Reddy (pcn@teil.soft.net) said on 4/9/97 at 3:55 AM
>
>hi
>
> I am having some doubts about the isakmp+oakley,
> can anyone please clarify them.
>
> 1) Is the SPI space used by the various protocols
> defined anywhere? In page 16 of the ISAKMP draft
> it says that "Each security protocol has its own
> SPI-space."
>
The SPI is used for your own implementation's purposes to identify a security
association. Use what ever you want (most use a random number, others
increment a counter). However below 100 (or is it 500?) is reserved for other
purposes. And DON"T use 0 (it will mess up my implementation :-))
Remember, there are 2 SPIs, your SPI and the other guy's SPI. When sending,
you must use the other guy's SPI for the SA so he can find the SA. When receiving,
you will receive your own SPI for the SA so you can find the SA.
> 2) Is SPI unique on a host? Or is it unique for
> a particular destination IP address in the
> SA Data Base?
>
That is up to your implementation. You could have unique SPIs per system, per protocol
(ESP/AH), or whatever. Just as long as you can find the right SA using the SPI value.
> 3) A "PROPOSAL" contains details of one "PROTECTION
> SUITE", and a "PROTECTION SUITE", may contain many
> "SECURITY PROTOCOLS". But SPI is part of the
> proposal payload, and one proposal payload is used
> to give the details of one "SECURITY PROTOCOL" only.
> To give details of more than one "SECURITY PROTOCOL"
> in a proposal we use multiple proposal payloads with
> the same proposal# (proposal number). So there can
> be different SPI values for the "SECURITY PROTOCOLS"
> within the same "PROPOSAL"(ie. multiple proposal
> payloads with the same proposal number)?
> So my doubt is whether it is mandatory to use different
> SPI values for different "SECURITY PROTOCOLS" within the
> same "PROPOSAL"?
> Or is it mandatory to use the same SPI value?
> In the case where different SPI values are mandatory, how
> is a SA identified, because an SA will then have more than
> one SPI values(one for each "SECURITY PROTOCOL")?
>
Dealing only with proposal and transform payloads, yes the SPI is in the proposal payload.
Proposal payloads may or may not have the same SPI. Again this depends on the uniqueness of your SPIs.
If the proposals are of the same number and have the same SPI, you are saying you are using the same
SPI for AH and for ESP and that you will be able to find the SA during IPSEC traffic based on both SPI and
protocol. If the SPIs have different values for proposals of the same number,
you are using SPIs which are unique even across protocols.
Either way is fine as long as you can deal with it during IPSEC traffic.
As for proposals of different numbers, there is no reason not to use the same AH spi and ESP spi in all proposals
since only one will be picked, but again it doesn't matter since the spi for each protocol will be returned to you in
the selected proposal response.
> 4) The different Exchanges defined in the ISAKMP have
> a defined set of messages to be exhanged to negotiate the
> ISAKMP SA and the IPSEC SA later. How do you handle
> the issue of "TIMEOUT" and "RE-TRANSMITION" of messages
> during these Exchanges? Is there an agreed upon way as
> to how we should handle this issue? I feel that this
> issue needs an agreed upon standard solution for
> interoperability reasons.
Timeout the message and resend it. After n tries give up and send a notify or delete payload and forget about
the negotiation. I do not believe there is an interoperability issue here as long as the implementation can deal
with receiving duplicate messages and tossing all but the first.
>
> 5) ISAKMP can be used to negotiate multiple SA's between
> two entities. So when there are multiple active SA's
> between any two nodes, how do I decide which of the
> active SA to use for the outgoing traffic? Because
> in IPSEC, the securing of the IP packets is done
> in the IP layer, And in the IP layer the information
> of which process had generated this IP packet is all
> lost, this information is only available in the socket
> layer. When we have a very dynamic situation where we have
> each user on the system, using his own ID_USER_FQDN
> (example piper@foo.bar.com) and each user negotiates
> an SA for his use. So we will ultimately have a
> situation where there are more than one active SA
> between two nodes(nodes that are identified by IP addresses).
> Here when the IP layer is securing outgoing traffic, it
> has to use the SA corresponding to the perticular user,
> so it has to know which process has generated this traffic,
> and who is the owner of that process. How can this situation
> be supported using IPSEC?
This is user based IPSEC and is in great demand but is not solved yet.
Note, I say user based in the sense that multiple "people" or "personalities"
on a machine want to talk to the same host using different SAs.
We CAN do psuedo-user where authentication of the entire machine is done
via a user based certificate, say. But this is not the multiple user case.
>
> 6) In a "Video on demand" application, it is logical to have
> just encryption from the service provider to the customer, and
> to have just Authentication from the customer to the service
> provider traffic. In this situation there is a requirement for
> two SA's to the same destination IP address, one for outgoing
> traffic only and another for incoming traffic only. How do I
> negotiate such SA's using ISAKMP?
>
Well, I answered 5 out of 6 anyway. I can certainly send with whatever SA I
want, but how do I tell the other side to send to me using a particular SA (SPI)?
Is there the concept of SA direction in ISAKMP negotiation?
Edward Russell
erussell@ftp.com