[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ipsec] Re: 2401bis -- Issue 91 -- handling ICMP error messages



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

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


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