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

Re: Manual key management issues

> Hi Steve,

Ummm, I'm not Steve, but since I just answered one IPsec question, I figure
I'm almost on a roll... :)

> 1.  During Automatic key management, as we know, SPIs will be  exchanged
> priorto any data transfer with the help of ISAKMP. But, how are the SPIs
> exchanged during Manual Key Management ?

They are simply assigned with whatever value you want.  You have to add a
pair (inbound/outbound) to BOTH machines you wish to secure.

> 2. Assuming that SPI is not exchanged prior to data transfer in manual key
> management,

Bad assumption... VERY bad assumption.

> we thought of implementing the matching of incoming packet with the SAs by
> comparing the packet's Dest_address and Sec_protocol with the SA
> counterparts. If we found that more than one SAs are matched than we do an
> exhaustive processing and only process the packet with the totally matching
> SA. Is this strategy fine ?

No... that strategy is dangerous.

> Or is it that for conformance to IPSEC, the SA has to be found by matching
> against the unique tuple (SPI, IPSEC proto,Dest Addr)?

Yes, you MUST do this.  If you receive a packet that does not have an SA
matching <AH or ESP, SPI, Dest addr>, you MUST drop it, and you SHOULD/MUST
issue a warning or log a failure or something.

> 3. Also, once again in manual key management, we are planning to create SAs
> for outgoing packets at run-time if a matching SA is not found in the SAD
> by generating a unique SPI value. When are the SAs for receiving packets
> created?

They are created before packets are received.  You have no other choice.
This is why ISAKMP is important for a scalable IPsec solution.  Manual
keying, while necessary, is very annoying for frequent rekeying situations.

> Do we create SAs for the SPD entries in incoming direction at bootup time
> and they are static, i.e., remain until the system is rebooted?

To answer your question, you have to create SAs before you can hope to
receive IPsec-protected traffic.

SA lifetimes are independent of how they were created.  You can manually add
an SA with a finite lifetime.  You just better add another before that first
one expires.

> But, this might compromise the security if SAs remain for so long a period.

Yes, long-lived SAs are a security risk.

The IPsec architecture document makes (or if it doesn't, it should make)
clear how inbound/outbound processing and SA creation interact.  Basically:

INBOUND PROCESSING:
	* Look up SA using <AH or ESP, SPI, dest addr>
	* If SA lookup fails, drop the packet and log/notify/scream about
	  the error.  No ifs, ands, or buts.  If an SA isn't there, you
	  won't get the data protected by that SA.
	* If SA is present proceed to process the packet accordingly.

OUTBOUND PROCESSING
	* Using SPD/selectors/whatever, find an appropriate SA.
	* If none exists, kick some keying entity in the pants to add an
	  SA on your behalf that fits your policy.  This entity is usually
	  ISAKMP, but it doesn't have to be.
	* If no keying entity is found (or it returns an error, times out,
	  etc.), drop the packet. 
	* Otherwise, the keying entity will add the SA for you (and
	  presumably your destination will now have one too) and then
	  process the outgoing packet.

Hope this helps!
--
Daniel L. McDonald  -  Solaris Internet Engineering  ||  MY OPINIONS ARE NOT
Mail: danmcd@eng.sun.com, danmcd@kebe.com <*>        ||  NOT NECESSARILY SUN'S!
Phone: (650) 786-6815            |"rising falling at force ten
WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush
Follow-Ups: References: