Subject: [Ipsec] new ICMP text for 2401bis

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Aug 2004 17:01:36 -0400

Folks,

The 2401bis text proposed below is based on a draft proposal sent on 
4/13 (plus some text from the original issue 91 write up in Oct 2003) 
and reflects list discussions with:
	- Mark Duffy about case 2 (whether or not the receiver should
	  be doing the kind of checking we propose) -- we believe the
	  receiver MUST do this checking.  (see Steve Kent's email of
	  May 7 and May 10)
	- Mark Duffy re: removal of text re: "fast path and slow path"
	  -- we agreed to remove it.
	- Rich Graveman re: clarifying that we believe this proposal
	  would work with ICMPv6
	- Mark Duffy and Mohan Parthasarathy re: clarifying what we
	  meant by checking "to ensure that the enclosed packet is
	  consistent with its source" and "to see if the selector
	  fields in the enclosed packet match those of an existing
	  SA, etc.
	- one BIG (but accommodating) change is that we dropped the requirement
	  to use a dedicated SA for ICMP error messages

--------

A. The following text will be placed in Section 6. "ICMP Processing".

This section discusses IPsec handling of ICMP traffic.  Please note that:

a. There are two categories of ICMP traffic -- error messages (e.g., 
type = destination unreachable) and non-error messages (e.g., type = 
echo). This section applies exclusively to error messages.  Non-error 
ICMP messages should be explicitly accounted for in the SPD.

b. This section applies to ICMPv6 as well as to ICMPv4.

c. A mechanism SHOULD be provided to allow an administrator to cause 
ICMP messages (selected, all, none) to be logged as an aid to problem 
diagnosis."

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

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. 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, then an IPsec implementation MUST map an outbound 
ICMP error packet to the SA that would carry the return traffic 
associated with the packet that triggered the ICMP error packet. 
(This allows an administrator to explicitly account for ICMP error 
packets in SPD entries, causing them to bypass the payload check 
noted below. This results in reduced security for hosts, as noted 
above.) This requires an IPsec implementation to detect outbound ICMP 
error packets that map to no extant SA, and treat them specially with 
regard to SA creation and lookup. The implementation extracts the 
header for the packet that triggered the error (from the ICMP message 
payload), reverses the source and destination IP address fields, 
extracts the protocol field, and reverses the port fields (if 
accessible). it them uses this extracted information to locate an 
appropriate, active outbound SA. This implies that there must be an 
active SA for that traffic. An IPsec implementation MUST NOT create a 
new SA carry ICMP traffic error packets as a result of an attempt to 
transmit such packets.

If an IPsec implementation receives an IMCP error packet that does 
not match the SA traffic selectors, the receiver also MUST process 
the received message in a special fashion. Specifically, the receiver 
must extract the header of the triggering packet from the ICMP 
payload, and reverse fields as described above to determine if the 
packet is consistent with the selectors for the SA via which it was 
received. Only then is it safe to forward the ICMP message to the 
destination.

The sender and receiver MUST support the following processing when 
ICMP error packets are sent over SAs with selectors that DO NOT match 
these packets:

	a. If an IPsec implementation encounters an outbound ICMP error message
            for which no applicable SA exists, it extracts the header info from
            the payload, reverses the source and destination IP 
addresses, and, if
            accessible, the source and destination port fields. It 
uses the address,
            protocol, and port fields (if available) to perform an SPD 
lookup. If an
            appropriate, extant SA is found, the packet is transmitted 
via this SA.
            (No new SA will be created to carry an ICMP error packet.) 
If no suitable
            SA exists, the ICMP packet is dropped, an auditable event.

	b. If an IPsec implementation receives an ICMP error packet 
on an SA and the
            traffic selectors for that SA do not allow for the packet, 
a secondary
            check is performed. The receiver extracts the header info 
from the ICMP
            payload, reverses the source and destination IP addresses, and, if
            accessible, the source and destination port fields. The 
resulting values
            are compared to the selectors for the SA via which the 
ICMP packet was
            received. If the selectors match, the packet is forwarded, 
otherwise it
            it is discarded, and auditable event.

B. The following text will be added to Security Considerations:

An IPsec implementation is configured to pass ICMP error packets over 
SAs based on the ICMP header values, without checking the header info 
from the ICMP packet payload. For
example, a tunnel may be created between two sites that uses ANY for 
protocol and port fields and IP address ranges that encompass all 
systems behind the security gateways serving each site. In such 
cases, the hosts behind the security gateways will be vulnerable to 
DoS attacks that might be launched by other peers with which there 
are active SAs.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 10 Aug 2004 14:15:33 +0300

> 6.1 ICMP message not protected by IPsec

If I understood correctly this section covers the ICMP messages coming
from the "internet" side, i.e from the interface where we normally
receive ESP traffic?

So this section does not cover the unprotected ICMP messges coming
from the "insde" side, right?

Having picture here would really make things easier understand.
Something like:

         (1)              (3)        (5)               (7)
+------+/     +---------+/              \+---------+      \+------+
|Host A|------|SGW A(3a)|=== Internet ===|(5a)SGW B|-------|HOST B|
+------+     /+---------+      //        +---------+\      +------+
          (2)                 //                     (6)
                     (4)     //
  +----------------+/       //
  |IPsec HOST C(4a)|=======//
  +----------------+

Where Host A and B are non IPsec hosts, and SGW A and B are IPsec
Gateways, and IPsec HOST C is a host capable of talking IPsec itself
(but not a gateway). Numbers near the boxes refer to the interface at
that point. A double line "=" is used to mark IPsec connection (ESP
tunnel or similar) and number inside the box like "(3a)" refers a
traffic exiting from tunnel after decryption and authentication.

And then say that section 6.1 covers cases (3), (4), and (5). 

> 6.2 ICMP messages protected by IPsec

Especially this title is hard to understand. I think it should say
something like "6.2 ICMP messages protected by or to be protected by
IPsec".

So this section covers traffic on numbers (2) and (6). And probably
also (3a), (4a) and (5a)?

> processing of traffic is not sufficient to protect against such 

Ok, this talks about the (3a), (4a) and (5a).... I.e. tunnel exit
checks. 

> new SA carry ICMP traffic error packets as a result of an attempt to 

And this talks packets coming at (2) and (6). 

> If an IPsec implementation receives an IMCP error packet that does 
					 ^^^^ Typo

> not match the SA traffic selectors, the receiver also MUST process 

I assume here "SA traffic selectors" referes to the normal traffic
selectors, like SA only for TCP 22 receiving ICMP host unreachable
with internal packet having TCP 22. 

> received. Only then is it safe to forward the ICMP message to the 

And this is again for the (3a), (4a) and (5a). 

> ICMP error packets are sent over SAs with selectors that DO NOT match 

"... DO NOT match these ICMP packets (but the packet inside the ICMP
message matches)"?

> 	a. If an IPsec implementation encounters an outbound ICMP
>	   error message for which no applicable SA exists, it
>	   extracts the header info from the payload, reverses the
>	   source and destination IP addresses, and, if accessible,
>	   the source and destination port fields. It uses the
>	   address, protocol, and port fields (if available) to
>	   perform an SPD lookup. If an appropriate, extant SA is
>	   found, the packet is transmitted via this SA. (No new SA
>	   will be created to carry an ICMP error packet.) If no
>	   suitable SA exists, the ICMP packet is dropped, an
>	   auditable event.

Looks good. So this covers packets coming from (2), and (6).

> 	b. If an IPsec implementation receives an ICMP error packet on
>          an SA and the traffic selectors for that SA do not allow
>          for the packet, a secondary check is performed. The
>          receiver extracts the header info from the ICMP payload,
>          reverses the source and destination IP addresses, and, if
>          resulting values are compared to the selectors for the SA
>          via which the ICMP packet was received. If the selectors
>          match, the packet is forwarded, otherwise it it is
>          discarded, and auditable event.

And this (3a), (4a) and (5a). 

> from the ICMP packet payload.

I think that needs some kind of rewording like "An IPsec
implementation can be configured ..." or similar. 

> For example, a tunnel may be created between two sites that uses ANY
> for protocol and port fields and IP address ranges that encompass
> all systems behind the security gateways serving each site. In such

Perhaps we should describe the situation more here?

BTW, what about the old PMTU text? Do we copy the old RFC2401 PMTU/DF
processing stuff from there (section 6 and appendix B)? 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Aug 2004 16:21:02 -0400

>from the "internet" side, i.e from the interface where we normally

yes. we can clarify the scope when we insert the text.

>from the "insde" side, right?

right.

>Having picture here would really make things easier understand.

we'll see what makes sense in terms of describing what sets of 
traffic is addressed by each part of section 6. based on your 
comments below, I'm not quite sure how to interpret (2) and (6) 
above, so we probably need a diagram plus some notes to clarify this 
complex issue.

>something like "6.2 ICMP messages protected by or to be protected by

good point.

>also (3a), (4a) and (5a)?

the emphasis is on traffic that arrives on an SA, or that arrives on 
the protected side and is mapped to an SA.  So, some examples of ICMP 
traffic that might be captured under 2 and 6 would not be included, 
e.g., if the traffic was outbound but addresses to the IPsec device.

>Ok, this talks about the (3a), (4a) and (5a).... I.e. tunnel exit

yes

>And this talks packets coming at (2) and (6).

more precisely, packets that arrive at (2) and (6) but which are 
destined for devices with which the IPsec implementation is 
communicating via SAs.

>with internal packet having TCP 22.

it refers to whatever selectors are in the SPD-O cache (i.e. for 
extant SAs). it is not talking about (2) or (6) traffic that is 
directed to the IPsec implementation itself, from the protected side.

yes, that's what I have been saying in my motes above. none of the 
text here talks about what to do re traffic on the protected side 
that is "consumed" by the Ipsec implementation, vs. being transported 
by that implementation.

>And this is again for the (3a), (4a) and (5a).

yes.

>"... DO NOT match these ICMP packets (but the packet inside the ICMP

the text below is just a restatement of the text above, in a more 
concise form. so, this refers to transmit and receive processing for 
ICMP error packets that would not otherwise be mapped to extant SAs.

>And this (3a), (4a) and (5a).

yes.

>implementation can be configured ..." or similar.

I should have said: "if an IPsec implementation is configured to pass ..."

>Perhaps we should describe the situation more here?

suggestions?

>processing stuff from there (section 6 and appendix B)?

Yes, Karen has not yet added back the PMTU text.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Aug 2004 11:56:07 +0300

> above, so we probably need a diagram plus some notes to clarify this 

The (2) is the traffic coming from the host A and going to host B
throught the SGW A and B using IPsec tunnel between the SGWs. I.e. it
didn't include traffic destioned to the SGW A.

I agree that was not clear in from the picture, and trying to get that
distinction in to the picture is little hard... Perhaps:

          (1)                (3)      (5)                  (7)
+------+/     +------------+/            \+------------+      \+------+
|Host A|------|(2)SGW A(3a)|===Internet===|(5a)SGW B(6)|-------|HOST B|
+------+     /+------------+      //      +------------+\      +------+
           (9)                   //                      (10)
                        (4)     //
     +----------------+/       //
     |IPsec HOST C(4a)|=======//
     +----------------+

Hmm.. probably not. I think it is simply better to explain that in the
text saying that (2) and (6) only cover the traffic destinoned to the
tunnel, not the traffic destioned to the SGWs themselves. 

> I should have said: "if an IPsec implementation is configured to pass ..."

What happens if it is configured that way? It does not tell that
either... Perhaps it should say:

----------------------------------------------------------------------
If an IPsec implementation is configure to pass ICMP error packets
over SAs based on the ICMP header values, without checking the header
infor from the ICMP packet payload, then the attackers can cause DoS
attacks by sending the ICMP packets through the SGW to the other end,
just like they could if the hosts would be on the same network. 
----------------------------------------------------------------------

> >Perhaps we should describe the situation more here?

Hmmm.. not really, but remembering the items raised in the IESG to the
UDP encapsulation draft, they always wanted to see the real attacks,
not just text saying there are some attacks.

Perhaps it is just enough to say that the attacker can do all same
attacks with ICMP messages, it could if it would be on the same
network (including faking the header and contained payload IP
addresses). 

> Yes, Karen has not yet added back the PMTU text.

After we have this ICMP and that PMTU text done, we should be ready...
I do not know anything else missing...
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Aug 2004 09:51:18 -0400

Tero,

Yes, diagrams to explain which ICMP flows we're talking about are 
tricky to construct.  We'll give it a shot, but a table to eplain the 
flows will be needed.

>either... Perhaps it should say:

Yes, we can include text along these lines in the security 
considerations section to explain the dangers of configuring SAs that 
allow transmission of ICMP error messages to skip checking the 
payload.

>not just text saying there are some attacks.

OK, we can add an "e.g.," and give examples of the sorts of DoS 
attacks that can result.

>I do not know anything else missing...

Always nice to hear "we're almost done" feedback :-)

Steve

---

From: Mark Duffy <[email-masked]>
Date: Tue, 17 Aug 2004 17:34:37 -0400

Steve, sorry about the delayed response.  Please see some comments below.
--Mark

At 05:01 PM 8/9/2004, Stephen Kent wrote:
[...]
>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?

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

>(This section does NOT apply to ICMP traffic that is bypassed or consumed 
>on the ciphertext side of the IPsec boundary.)
>
>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."

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.

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

I assume that this would refer to SPD entries of any flavor (discard, 
bypass, protect) and so it is only if there is no SPD entry at all that 
matches the ICMP packet that it should then consider doing the special 
outbound processing described next...

>  then an IPsec implementation MUST map an outbound ICMP error packet to 
> the SA that would carry the return traffic associated with the packet 
> that triggered the ICMP error packet. (This allows an administrator to 
> explicitly account for ICMP error packets in SPD entries, causing them to 
> bypass the payload check noted below. This results in reduced security 
> for hosts, as noted above.) This requires an IPsec implementation to 
> detect outbound ICMP error packets that map to no extant SA,

Pursuant to my point above, "that map to no extant SA" would need a 
corresponding change to refer to SPD policy rather than extant SA.

>  and treat them specially with regard to SA creation and lookup. The 
> implementation extracts the header for the packet that triggered the 
> error (from the ICMP message payload), reverses the source and 
> destination IP address fields, extracts the protocol field, and reverses 
> the port fields (if accessible). it them uses this extracted information 
> to locate an appropriate, active outbound SA. This implies that there 
> must be an active SA for that traffic. An IPsec implementation MUST NOT 
> create a new SA carry ICMP traffic error packets as a result of an 
> attempt to transmit such packets.
>
>If an IPsec implementation receives an IMCP error packet that does not 
>match the SA traffic selectors, the receiver also MUST process the 
>received message in a special fashion. Specifically, the receiver must 
>extract the header of the triggering packet from the ICMP payload, and 
>reverse fields as described above to determine if the packet is consistent 
>with the selectors for the SA

s/if the packet/ if the triggering packet/    -- would add some clarity

>via which it was received. Only then is it safe to forward the ICMP 
>message to the destination.
>
>The sender and receiver MUST support the following processing when ICMP 
>error packets are sent over SAs with selectors that DO NOT match these packets:
>
>       for which no applicable SA exists,

as argued above, this should be a reference to SPD policy, not extant SA

>                                           it extracts the header info from
>      the payload, reverses the source and destination IP addresses, and, if
>      accessible, the source and destination port fields. It uses the address,
>      protocol, and port fields (if available) to perform an SPD lookup. If an
>      appropriate, extant SA is found, the packet is transmitted via this SA.
>      (No new SA will be created to carry an ICMP error packet.) If no 
> suitable
>    b. If an IPsec implementation receives an ICMP error packet on an SA 
> and the
>      traffic selectors for that SA do not allow for the packet, a secondary
>      check is performed. The receiver extracts the header info from the ICMP
>      accessible, the source and destination port fields. The resulting values
>      are compared to the selectors for the SA via which the ICMP packet was
>      received. If the selectors match, the packet is forwarded, otherwise it

[...]

---

From: Mark Duffy <[email-masked]>
Date: Tue, 17 Aug 2004 17:34:37 -0400

[...]

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Aug 2004 17:31:58 -0400

At 5:34 PM -0400 8/17/04, Mark Duffy wrote:
>>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 
>>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.

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

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

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

>>  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 assume that this would refer to SPD entries of any flavor 
>(discard, bypass, protect) and so it is only if there is no SPD 
>entry at all that matches the ICMP packet that it should then 
>consider doing the special outbound processing described next...

yes, it applies to all SPD entry types.

>>then an IPsec implementation MUST map an outbound ICMP error packet 
>>to the SA that would carry the return traffic associated with the 
>>packet that triggered the ICMP error packet. (This allows an 
>>administrator to explicitly account for ICMP error packets in SPD 
>>entries, causing them to bypass the payload check noted below. This 
>>results in reduced security for hosts, as noted above.) This 
>>requires an IPsec implementation to detect outbound ICMP error 
>>packets that map to no extant SA,
>

see my response above re this issue.

>>  and treat them specially with regard to SA creation and lookup. 
>>The implementation extracts the header for the packet that 
>>triggered the error (from the ICMP message payload), reverses the 
>>source and destination IP address fields, extracts the protocol 
>>field, and reverses the port fields (if accessible). it them uses 
>>this extracted information to locate an appropriate, active 
>>outbound SA. This implies that there must be an active SA for that 
>>traffic. An IPsec implementation MUST NOT create a new SA carry 
>>ICMP traffic error packets as a result of an attempt to transmit 
>>such packets.
>>
>>the received message in a special fashion. Specifically, the 
>>receiver must extract the header of the triggering packet from the 
>>ICMP payload, and reverse fields as described above to determine if 
>>the packet is consistent with the selectors for the SA
>

OK< we'll make the suggested change here.

>>ICMP error packets are sent over SAs with selectors that DO NOT 
>>match these packets:
>>

see response earlier.

[SNIP]

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Aug 2004 17:31:58 -0400

Howe about:

see response earlier.

[SNIP]

Steve

---

From: Mark Duffy <[email-masked]>
Date: Thu, 19 Aug 2004 19:06:38 -0400

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

At 05:31 PM 8/18/2004, Stephen Kent wrote:
>>>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.
>>
>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.

>>> parameters for dealing with such traffic. For example, there could be 
>>> the ability to establish a minimum PMTU for traffic (perhaps on a per 
>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?

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

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

>>> 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.
>>>
>>>ICMP error packet,
>>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]

---

From: Mark Duffy <[email-masked]>
Date: Thu, 19 Aug 2004 19:06:38 -0400

or even like this:

[snip]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Aug 2004 12:06:00 -0400

Mark,

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

I placed the processing for unauthenticated ICMP traffic directed to 
the IPsec device on the unprotected side of the boundary because it 
seemed like the right thing to do, based on having implemented high 
assurance systems this way for the last 25 years :-)  It could be 
moved to the other side of the boundary, but the sorts of checks that 
one will perform are not the sort that we can describe in the SPD, so 
bypassing this traffic doesn't accomplish anything useful. Also, the 
effects are often local to the unprotected side of the IPsec 
implementation. So, if one were to perform the processing on the 
protected side, then we would have to signal over to the unprotected 
side to effect changes, etc. Also, the ICMP module on the unprotected 
side deals with all ICMP traffic, not just error messages, so things 
like ICMP ECHO processing are done there. It just seems to be 
appropriate to localize the processing there, for this traffic.

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

yes. we can clarify the text.

	<SNIP>

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

yes, that was my intent. The idea is that if you want to let the ICMP 
traffic go through without the payload checks, then you configure the 
SPD to allow it to pass under the normal checking procedure.  If you 
want to impose the checks, then don't create SPD entries that allow 
the ICMP error traffic to pass, and that will force the checks.

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

The configuration choice re payload checking does not apply when the 
error packets don't match the SA selectors. It occurs when the SPD 
entry is created to accommodate or not accommodate ICMP error packets 
explicitly. So the text above is not what I hand in mind. However, if 
the WG wants this additional level of configuration, we could change 
the text.

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

I see your point. I'll change the text to say that Iits OK to create 
an SA to carry an ICMP error message IF there is an SPD entry that 
matches the ICMP header. This means that such messages will be 
transmitted over extant SAs based on payload header matching ONLY if 
there is no SPD entry that would otherwise accommodate transmission 
of ICMP error traffic.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Aug 2004 12:06:00 -0400

Mark,

	<SNIP>

	<SNIP>

	<SNIP>

	<SNIP>

Steve