[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages
At 12:02 AM 4/25/2004 -0400, kseo@bbn.com wrote:
>Hi Mark,
>
>My apologies for the delay in replying....
>
>>I have no argument with the proposal to follow the second approach. But,
>>I don't see why in this case the receiver would need to do any "special"
>>processing i.e. examining the payload of the icmp packet. Can you please
>>explain the reason for that?
>>
>>If I understand the proposal correctly, the icmp packets will be sent on
>>an SA that is explicitly negotiated for icmp (and maybe other
>>stuff). Why shouldn't the receiver just accept the icmp packets on their
>>own merits?
>
> I believe there was a concern that the sender of the ICMP
> packet could send it to an entity (behind the local IPsec
> implementation) that could not legitimately have sent
> the triggering packet contained in the ICMP packet. This
> could be by error or as a DoS attack. By checking the
> contents of the ICMP packet, the IPsec implementation can
> at least ensure that the triggering packet came from
> an entity on its protected side that has an existing SA
> that matches the triggering packet. Since this special
> checking is a local matter, not negotiated, we could make
> it optional for a vendor who wants to provide additional
> protection. Would making this additional checking a SHOULD
> or a MAY address your concern?
>
>Thank you,
>Karen
Hi Karen,
I understand how, as you describe, this processing of icmp error messages
might protect against certain DOS attacks. But it seems to me to be
overzealous in your approach #2.
In your approach #1 the icmp error message is being sent on an SA pair
implied by the enclosed packet in the icmp payload. In that case I think
it makes perfect sense for both IPsec devices to evaluate the SPD policy
for that enclosed packet.
But in #2 the icmp error message is being sent on an SA negotiated for
protocol=icmp, type=<mumble> and code=<mumble>. It seems to me to be an
impropriety for the IPsec implementation to check the enclosed
packet. This would be checking that goes beyond the negotiated selectors
-- AFAIK there is no other comparable thing done elsewhere in
IPsec. Should an IPsec implementation also check for invalid combinations
of control bits in a tcp header? Or for packets with src addr == dest
addr? These are also checks that could protect against attacks but they
oughtn't IMO to be part of the *IPsec* processing.
--Mark
P.S. Comments on the wording:
- Regardless of what behavior is chosen, it would be better if the text
does not describe a fast path and a slow path, and what is done in each. I
don't think there is anything gained by including such implementation
assumptions.
- The phrase "to ensure that the enclosed packet is consistent with its
source" could use some elaboration.
>>Thanks, Mark
>>
>>P.S. I marked the paragraph below that I am asking about.
>>
>>
>>At 07:54 PM 4/13/2004 -0400, Karen Seo wrote:
>>>Folks,
>>>
>>>Following up on a discussion at the end of February/early March re: how
>>>to handle ICMP traffic... We were talking about how to carry ICMP
>>>traffic via an SA between two IPsec implementations. This did NOT
>>>involve ICMP traffic that might be bypassed or consumed on the
>>>ciphertext side of the IPsec boundary. Also, there are two categories
>>>of ICMP traffic -- error messages (e.g., type = destination unreachable)
>>>and non-error messages (e.g., type = echo). This discussion covered ONLY
>>>error messages. Non-error ICMP messages should be explicitly accounted
>>>for in the SPD.
>>>
>>>Two approaches were discussed:
>>> 1. The sender of ICMP error message uses the (return) SA for the
>>> packet that resulted in the ICMP error message. In this
>>> discussion, the SA was assumed to not be configured to
>>> carry ICMP error messages.
>>> 2. The sender of ICMP error message uses an SA that is configured
>>> to handle ICMP error messages of the relevant type and code.
>>> Note that while this case was viewed in the discussion
>>> as being a different/separate SA from case 1 above, this SA
>>> could be the same as case 1, if that SA were configured to
>>> carry ICMP error taffic (in addition to user traffic). Note
>>> also that the ICMP Type and Code for this SA could be set to
>>> ANY, if there is no need to restrict the type of ICMP traffic
>>> that it is allowed to carry.
>>>
>>>Here's what needs to happen at the sender and receiver, to make each
>>>case work:
>>> For case 1:
>>> a. The sender notices that the packet is an ICMP error
>>> message and diverts it to slow path processing. It
>>> examines the enclosed packet (or portion thereof),
>>> swaps the source and destination addresses and
>>> ports, and performs an SPD lookup to find the SA
>>> to use. Then the ICMP packet is sent via the
>>> the selected SA.
>>>
>>> b. The receiver notices that a packet has failed the
>>> selector check (e.g., the source address or the
>>> protocol does not match). The packet is diverted
>>> to slow path processing where it is observed to be
>>> an ICMP error message and the enclosed packet
>>> is examined. The source and destination addresses
>>> and ports are swapped and matched against the
>>> selectors for the SA via which the ICMP packet was
>>> received. If they match, the ICMP message is passed
>>> on for further processing, e.g., PMTU check.
>>>
>>> This case assumes that no further access control checks
>>> are desired for the ICMP packet.
>>>
>>> For case 2:
>>> a. The sender extracts ICMP type and code and does an
>>> SPD lookup to find an appropriate SA. (The Sender
>>> only does fast path processing.)
>>> b. The receiver processes the ICMP packet on the SA
>>> via which it was received, verifying that the ICMP
>>> type and code of the message match the selectors
>>> for the SA.
>>
>>[md] Why check the icmp payload as stated below? And what does it mean
>>for the enclosed packet to be "consistent with its source"?
>>
>>> If they do, then the receiver passes
>>> the ICMP message to slow path processing. The
>>> selectors of the enclosed packet are extracted
>>> and matched against the SPD-S cache, to ensure
>>> that the enclosed packet is consistent with its
>>> source. If they do, the ICMP message is passed
>>> along for further processing, e.g., PMTU check.
>>> (The receiver does both fast path and slow path
>>> processing.)
>>>
>>> Note that an ICMP packet may arrive on an SA unrelated
>>> to the SA used for the triggering packet. The sender
>>> will use the first SPD or SPD-S cache entry that it
>>> comes to that is configured to carry ICMP traffic of
>>> the given type and code. Even if the SA for the
>>> triggering packet is configured to carry ICMP traffic,
>>> there may be an earlier entry in the SPD that matches
>>> the ICMP message's type and code. So one has
>>> to search the outbound SPD-S cache to verify whether
>>> or not there's an extant SA for the enclosed
>>> (triggering) packet.
>>>
>>>Proposed approach
>>> To simplify the processing done by the Sender (of the ICMP
>>> message) to find the SA to use for sending the ICMP message
>>> and to support access control checks on the ICMP messages
>>> (using ICMP Message Type and Code) by the Receiver,
>>> we propose to use the second approach.
>>>
>>> Note: In the second approach, there is no requirement that
>>> the SA used for the ICMP message be dedicated only to ICMP
>>> messages. To minimize the number of SAs between two IPsec
>>> systems, an administrator may wish to configure the SPD such
>>> that the ICMP messages may be combined with other traffic,
>>> i.e., by specifying SPD entries that carry both normal
>>> traffic and ICMP traffic.
>>>
>>>Comments? Thank you,
>>>Karen
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec