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

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



Hi Karen, sorry for the delayed response.

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?

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