new ISAKMP ping draft

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


I submitted a new draft, draft-richardson-ipsec-ikeping-00.txt.

  It documents two new exchanges for ISAKMP, an echo request/reply. This is
primarily intended for diagnostics purposes. There were some initial comments 
from among those who saw the draft last week:

1) why not use an Informational exchange?

  In general, my reason to avoid this is because both are essentially
components of mainstream ISAKMP/IKE. That is, it is tied strongly to IKE 1.0
as documented.

  Informational Exchanges can be encrypted and authenticated, can be
associated (via the cookies) with active exchanges going on. 2408 says:

>4.8 Informational Exchange
>
>   The Informational Exchange is designed as a one-way transmittal of
>   information that can be used for security association management.

  The intention is not one, way and is not for SA management. Basically,
I'd like to stay completely out of that place. 

2) why not use a notify?
   
   Well, using a notify means sending it in some kind of exchange, e.g. an
Informational Exchange. If not using Informational Exchanges, I see no reason
to use a notify.

3) combine with the heartbeat/make-dead systems.

   These are used to detect a dead phase 1 SA. They are, AFAIK, encrypted Notifies.
   I do not want the ISAKMP echo request/reply to take any crypto resources
(in particular, no entropy!) and I do not want anyone to be confused into
thinking that these have anything to do with the things sent within a 
phase 1 SA.

4) It has been suggested that the cookies match the current IKE style rather
   than any proposed replacement.  

  I made up the cookie stuff. I didn't want the responder to waste a single
iota of entropy, but to do something easily noticable to the packet. I do not 
really care about the cookies, and upon reflection, the current proposal
likely won't get through "IKE enabled" NAT boxes.
  I'm open to anything.

5) echo response

  I considered having the responder copy the source IP and port number into
the body of the reply. It could even stick it in as its cookie. That would
permit a request'or to diagnose that they are in fact behind a NAT. 

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPH6+5IqHRg3pndX9AQHk2AP9GkqWleMmC1uSEddWWgC4hRNDwEKAgYL1
KgpXD6SxPfe6VhtTaOCtEE90koIKYnNwJNiuRdg09fydhG7zwMsrAurOYU/SVK6G
Vx2kXOSMDgdsrP1zLI1iM95s7HKgzlar1n+w8mbQM4ninTqPTmq74VDYGZfU3stB
2ja52RmKAF0=
=gYj4
-----END PGP SIGNATURE-----