handling of ICMP error codes in 2401bis

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

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


Steve Kent, I'd like to suggest some changes to a 2401bis. I will
be happy to provide a text diff to 2401 if you agree with the spirit.

(I'm not clear if you are revising just ESP or 2401 as well)

Specifically, I'd like to propose:

{From http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec/icmp/node5.html
 which is part of http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec/icmp/ }

                         Handling ICMP error messages

   ICMP  error  messages can be handled in two ways: one way is to handle
   them  like the information messages -- establish selectors and SAs for
   them.

   A  second,  more  useful,  way  is to realize that every error message
   contains  within  it  some  portion  of the IP packet which caused the
   error.  It is therefore possible to examine this IP packet, compare it
   to existing selectors, and insert the ICMP message into an appropriate
   SA.  When  doing  comparisons, the source and destination designations
   must be exchanged.

   This  method  has  the  advantage  that  it  inherently works well for
   per-host, per-port, and whatever future selectors may be created. This
   method  assumes  that SAs are created in equivalent pairs. This is the
   case  for  IKE  negotiated  unicast SAs, but would not be the case for
   multicast SAs, or manually keyed ones in general.

   At  first  take  it  may seem that this technique does not require any
   negotiation, and can be implemented as a local policy. This is not the
   case.  The  receiving  end of the SA will do tunnel exit checking, and
   unless  it is also implementing this policy will reject the packet and
   flag a security violation.

   It  is  therefore  necessary  for  an  IKE proposal to carry the "ICMP
   error"  processing  attribute  as  part  of  the  proposal. This would
   require  an extension to IKE, likely in the form of a variation of the
   identity  payload, initially in the private payload ID space protected
   by  a  vendor  ID  payload.  It  would be easy to deploy as even after
   standarization,  it  would not require a new ISAKMP version -- vendors
   that didn't recognize the proposal would simply not select it.

]       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

iQCVAwUBPLTFO4qHRg3pndX9AQEYnwP/Ql01LXA/BZGK+w+BLen/wU16PtBGu3/V
Gkx7VnWOkcqT5g3nGmrhzjXd4H7TlprX0Dgk0sGA/3zBESc9XCJ2PxLiDlmVK3py
AqappSAvuMafFww6JDJ/A2A064ICO7hfEwLshpeBHZ7LvSOTVgAiKqn3yJ/4u3g5
gXr2vJszsW4=
=y5ZT
-----END PGP SIGNATURE-----