Re: [Ipsec] new ICMP text for 2401bis

[Mark Duffy <mduffy@quarrytech.com>]

Thanks Steve.  Some more comments below.   ...Mark

At 05:31 PM 8/18/2004, Stephen Kent wrote:
>At 5:34 PM -0400 8/17/04, Mark Duffy wrote:
>>Steve, sorry about the delayed response.  Please see some comments below.
>>--Mark
>>
>>At 05:01 PM 8/9/2004, Stephen Kent wrote:
>>[...]
>>>6.1 ICMP message not protected by IPsec
>>>
>>>An ICMP message not protected by AH or ESP is unauthenticated and its 
>>>processing and/or forwarding may result in denial or degradation of 
>>>service.  This suggests that, in general, it would be desirable to 
>>>ignore such messages. However, many ICMP messages will be received by 
>>>hosts or security gateways from unauthenticated sources, e.g., routers 
>>>in the public Internet. Ignoring these ICMP messages can degrade 
>>>service, e.g., because of a failure to process PMTU message and 
>>>redirection messages. Thus there is also a motivation for accepting and 
>>>acting upon unauthenticated ICMP messages. To accommodate both ends of 
>>>this  spectrum, a compliant IPsec implementation MUST permit a local 
>>>administrator to configure an IPsec implementation to accept or reject 
>>>unauthenticated ICMP traffic.  This control MUST be at the granularity 
>>>of ICMP type and MAY be at the granularity of ICMP type and code.
>>
>>No disagreement here with requiring that control, but wouldn't the SPD 
>>(already covered under other MUSTs) generally be sufficient to meet this 
>>requirement?
>
>In Figure 3 in 2401bis we show processing of unprotected side, inbound 
>ICMP traffic in its own box, not crossing the IPsec boundary. Also, if we 
>want to do something like place a restriction on how small a PMTU size we 
>are willing to believe based on an unauthenticated ICMP message received 
>on this side(the example below), that is not the kind of thing we express 
>via the SPD.

Ahh, I looked only at figure 1 before speaking; I should have dug deeper :-)
But, let me then pose a more basic question:  *Why* is the reception of 
inbound ICMP traffic done outside the IPsec boundary?  IKE is inside the 
boundary.  Why should ICMP be different?  And what about other protocols 
destined to the IPsec device itself, such as tcp and ospf?  The figure 
doesn't show where these are, but I would hope/expect that they are also 
inside the IPsec boundary.

As far as applying other restrictions such as min PMTU size, agreed that 
such checks cannot be expressed via the SPD.  But that doesn't mean they 
can't be checked "behind" (after, inside) the SPD.


>>>   Additionally, an implementation SHOULD incorporate mechanisms and 
>>> parameters for dealing with such traffic. For example, there could be 
>>> the ability to establish a minimum PMTU for traffic (perhaps on a per 
>>> destination basis), to prevent receipt of an unauthenticated ICMP from 
>>> setting the PMTU to a trivial size."  [See Section xxx for recommendations.]
>>
>>Is that SHOULD intended to apply to ICMP messages that are forwarded, or 
>>those that are addressed to the IPsec implementation itself, or both?
>
>I intended for this to apply to unauthenticated messages, not ones 
>arriving on an SA, so they would be addressed to the IPsec implementation 
>itself. However, I was not thinking about messages that are bypassed, when 
>I wrote that. Such messages must be accounted for in the SPD, or they 
>would not be allowed across the IPsec boundary, but I am not suggesting 
>that such messages, if bypassed, need to be subjected to additional 
>"reasonableness" checks.

ok.  perhaps the text can be clarified.

I guess it should clarify that:

  -- the statement "a compliant IPsec implementation MUST permit a local 
administrator to configure an IPsec implementation to accept or reject 
unauthenticated ICMP traffic" refers only to ICMP addressed to the 
implementation itself (the SPD is already sufficient to handle this for 
transit bypassed ICMP).

  -- the extra "SHOULD" checks (like min PMTU) apply only to ICMP addressed 
to the implementation itself.

Are those in line with your intent?



>>>6.2 ICMP messages protected by IPsec
>>>
>>>(This section does NOT apply to ICMP traffic that is bypassed or 
>>>consumed on the ciphertext side of the IPsec boundary.)
>>>
>>>Both the payload of an ICMP error packet, and the header of the ICMP 
>>>packet require checking from an access control perspective. If one of 
>>>these packets is forwarded to a host behind a security gateway, the 
>>>receiving host IP implementation will make decisions based on the 
>>>payload, i.e., the header of the packet that purportedly triggered the 
>>>error response. Thus an IPsec implementation SHOULD to try to ensure 
>>>that this header information is
>>>consistent with the IPsec peer that transmitted the ICMP packet.
>>
>>I don't think it is clear what it means to "ensure that this header 
>>information is consistent with the IPsec peer that transmitted the ICMP 
>>packet".  How about
>>"Thus an IPsec implementation receiving an IPsec protected ICMP message 
>>SHOULD try to ensure that the ICMP payload information is consistent with 
>>packets that would be sent on the SA pair on which the ICMP message was 
>>received."
>
>Howe about:
>
>"An IPsec implementation MUST be capable of being configured to verify 
>that the ICMP payload information is consistent with packets that would be 
>sent on the SA pair on which the ICMP message was received."

good text, but see below.


>>Why is this a SHOULD, but then below the specific actions required to 
>>achieve this are MUST?  On the other hand, MUST isn't correct here either 
>>because in the case where there is an SA for the ICMP packet in its own 
>>right, this special check on the ICMP payload is not being called 
>>for.  Maybe it should say it MUST do this under certain conditions as 
>>described below.
>
>My revised text makes the ability to do this a MUST, but also recognizes 
>that one can choose to configure the SPD so that this will not happen.

But, I don't think it should really let them choose in that manner.  In 
fact the rest of the text doesn't say 'let them choose', it says 
essentially 'always do the icmp payload check when forwarding icmp error 
messages on an SA where they don't match the selectors, but never check the 
icmp payload when forwarding the error messages on an SA where the ICMP 
packets do match the selectors'.

I think the source of the confusion here, for me anyway, is that the 2nd 
paragraph in 6.2 ("Both the payload...") describes the possible attack and 
then makes some requirements for checking the icmp payload (such as your 
reworded text above) but then the following paragraphs (correctly I 
believe) call for doing this check only in the case where the ICMP packets 
are forwarded on an SA where they don't match the selectors.  I'd recommend 
that 6.2 include something like:

     For ICMP messages sent on an SA with selectors that match the ICMP 
packet itself, an IPsec implementation MUST NOT verify the ICMP Payload 
information.

     For ICMP messages sent on an SA with selectors that do not match the 
ICMP packet, an IPsec implementation MUST be configurable to verify that 
the ICMP payload information is consistent with packets that would be sent 
on the SA pair on which the ICMP message was received.

Or better yet, omit all that and just move all discussion about checking 
the ICMP payload to inside the description of the case where ICMP messages 
are sent on an SA with selectors that do not match the ICMP packet.


>>>  If this sort of check is not performed, then for example, anyone with 
>>> whom the receiving IPsec system (A) has an active SA could send an ICMP 
>>> destination dead message that refers to any host/net with which A is 
>>> currently communicating, and thus effect a highly efficient DoS attack 
>>> re communication with other peers of A. Normal IPsec receiver 
>>> processing of traffic is not sufficient to protect against such attacks.
>>>
>>>If no SA exists that matches the traffic selectors associated with an 
>>>ICMP error packet,
>>
>>I don't think that should say "if no SA exists ...".  Rather, I think it 
>>should say "if no SPD entry exists that matches the traffic selectors 
>>associated with an ICMP error packet".  I agree with the point below that 
>>it should not negotiate a new SA to forward an ICMP under the special 
>>processing rules (based on the ICMP payload).  But I think it *should* 
>>negotiate a new SA if needed when operating under the usual rules (i.e. 
>>if there is an SPD entry that natively matches the ICMP packet).
>
>My rationale was that since we are talking about ICMP error messages, they 
>should never cause an SA to be created, because they should be sent only 
>in response to receipt of a packet that arrived over an SA, causing the 
>error in question. Hence I did mean that we should never create an SA to 
>carry these messages.

I can understand the motivation, but suppose you have an SPD like this:

     1. SA=a, DA=b, protocol=tcp, SP=*, DP=*   --> protect
     2. SA=a, DA=b, protocol=icmp, type=*, code=*   --> protect

or even like this:

     1. SA=a, DA=b, protocol=tcp, SP=*, DP=*   --> protect
     2. SA=a, DA=b, protocol=*   --> protect

Then a tcp session starts up and an SA is opened under rule #1.  Then an 
ICMP is generated for a tcp packet in that session.  As written, the text 
would not permit an SA to be opened under rule #2 to forward that 
ICMP.  This seems wrong to me, unless we have a rule in IPsec that says 
"never open a new SA for an IPsec error message".

I do agree that if the SPD contains only rule #1, a new SA under rule #1 
should not be opened merely to forward an ICMP error message.

[snip]



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec