RE: 2401bis-00 submitted to IETF

["Mike Taylor" <mtaylor.eng@sbcglobal.net>]

I'm just getting to the point in my IPSec development where I need
to start dealing with whatever issues arise related to ICMP error
message processing, as discussed in

	Section 6. ICMP Processing Relevant to IPSec

of 2401.

I was just pondering the following language again in of 2401 when I received
the
email the draft:

   "An ICMP error message protected by AH or ESP and generated by a
   router SHOULD be processed and forwarded in a tunnel mode SA.  Local
   policy determines whether or not it is subjected to source address
   checks by the router at the destination end of the tunnel."

I see that it has not been reworded in the draft.  I suppose the meaning
should be
obvious to me, but being somewhat dense it isn't.

What does the above mean?  It can't really refer to the case, as a literal
interpretation might suggest, that we have received an ICMP error message
that has already had ESP or AH applied.  Obviously in that case we should
do the same thing with it as we would any other IP datagram we receive
where the proto is AH or ESP - look it up in the SADB based on the SPI,
protocol,
and destination, and go from there.

So initially I thought it was referring to the same type of issue as with
PMTU, i.e.,
where we receive an ICMP error message from a router that contains an IP
datagram
with proto AH or ESP that appears to have been sent by the SG (i.e., sent on
one
of its tunnels).  Is that the intent?  For example, suppose that the router
is
reporting that the SG at the other end of the tunnel is unreachable.  Then
we would
have to synthesize a DUR to send back to hosts on the trusted network
similarly
to how the handling of PMTU is described in Appendix B, except perhaps that
local
configuration could prevent us from doing this.

So I'm concerned that I'm missing something important.  Another reason I
find it confusing
is that a few paragraphs later we have

   "An ICMP message not protected by AH or ESP is unauthenticated and its
   processing and/or forwarding may result in denial of service.  This
   suggests that, in general, it would be desirable to ignore such
   messages."

Now is it the intent of this paragraph that we would be desirable not to
forward ICMP error messages from one end of a VPN to the other?  In other
words,
that we shouldn't take red ICMP error messages coming in from one end of the
VPN,
apply IPSec, and send them in the tunnel ultimately to the red network at
the
other end of the VPN?  That can't be.  Surely we want to do that.  We have
to
be able to trust ICMP error messages we receive from within the trusted
network.
Wouldn't make for much of a VPN if we couldn't.

So I'm afraid I'm missing something fundamental here.  Whether I am, or am
not
missing something, either way it seems to me that much of the text
in Section 6 of the new draft ought to be reworded to clarify the meaning.


Thanks,

Mike

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC
> Sent: Tuesday, October 21, 2003 10:39 AM
> To: ipsec@lists.tislabs.com
> Subject: Re: 2401bis-00 submitted to IETF
>
>
> Since it might take a while for the draft to get posted in the
> official IETF repository, there is a temporary copy of the draft
> available at
> <http://www.vpnc.org/ietf-ipsec/TEMP-draft-ietf-ipsec-rfc2401bis-00.txt>.
> This temporary copy will disappear when the official copy hits the
> official repository.
>
> --Paul Hoffman, Director
> --VPN Consortium