RE: 2401bis-00 submitted to IETF

[Stephen Kent <kent@bbn.com>]

At 17:46 -0700 10/21/03, Mike Taylor wrote:
>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.

It's not that easy. If we apply the SA selectors to the ICMP message, 
there is still the concern that the content of the message could be 
hostile, e.g., it might be a destination unreachable message for a 
host or net that is not consistent with the SA via which it was 
received. in our new text we explain why it is necessary to send this 
sort of traffic off for additional examination.

>
>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.

no, this text refers to black ICMP messages.

>
>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.
>

yes, the text is being revised significantly to be more comprehensive 
and clearer.

Steve