Re: ICMP in IPSec
Michael Richardson <mcr@sandelman.ottawa.on.ca> Sun, 23 May 1999 05:50 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA12168; Sat, 22 May 1999 22:50:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03610 Sat, 22 May 1999 23:37:41 -0400 (EDT)
Message-Id: <199905230130.VAA00586@pzero.sandelman.ottawa.on.ca>
To: ipsec <ipsec@lists.tislabs.com>
Reply-To: ipsec@lists.tislabs.com
cc: Ricky Charlet <rcharlet@redcreek.com>, pzeldin@research.solidum.com, aland@research.solidum.com, feliks@research.solidum.com
Subject: Re: ICMP in IPSec
In-reply-to: Your message of "Fri, 14 May 1999 21:04:45 -0000." <373C8FED.4927518C@redcreek.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset="US-ASCII"
Date: Sat, 22 May 1999 21:30:14 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Ricky" == Ricky Charlet <rcharlet@redcreek.com> writes: Ricky> I have not followed Michael Richardson's draft (icmp-handle) in Ricky> my 'initial thoughts' post. I find it more clear to ponder these out in Ricky> terms of 'situational examples'. I hope (naively??) that my list of This is, in my opinion, the best way to arrive at functional requirements. Ricky> situations is complete. The goal would be to move from my situational Ricky> format to filling in Michael's draft with the details per message rather Ricky> than per situation. Excellent. If you want be to translate my LinuxDOC SGML RFC source to Marshall Rose style XML, then I can forward things and you can take over the document. Ricky> ICMP traffic from Sgw1 to E1. Ricky> Sgw1 needs to ask itself if it trusts that the traffic causing Ricky> the ICMP event is really from E1, a trusted endpoint. Sgw1 may choose Ricky> to always trust that any traffic received from this interface is Ricky> authentic, may decide never to trust any traffic received on this Ricky> interface, or may decide that traffic received on this So, Sgw1 believes the traffic is from E1'. What is missing is the answer to question: what does SGw1 do with it. Ricky> ICMP traffic from R1 to E1. Ricky> This is unexpected. R1 should never have any knowledge of E1's Ricky> IP address and therfore should not be able to direct ICMP messages at Ricky> E1'. All such ICMP traffic MUST be silently discarded by Sgw1 unless an Ricky> operator has configured an applicible bypass IPSec selector (this is NOT Ricky> recomended). I don't agree that R1 doesn't know about E1. You are thinking about encryptionful ESP only. In the AH case, R1 can see the IP address. Clearly, R1 has no business sending ICMPs to E1, so I agree with the conclusion. Ricky> ICMP traffic from R1 to Sgw1. Ricky> Traffic from R1 does not arrive in an SA and is therefore of Ricky> highly suspect integrity. If R1 is sending an IMCP error message, then Ricky> the original offending IP packet returned with the ICMP error message is Ricky> almost certianly trunkated, possilby making it impossible to deterime Ricky> the original sender's IP address. Also, there are extremely I don't agree that it is certainly truncated. It may be, yes, but that isn't guaranteed. The SPI value is likely not truncated. Ricky> messages which R1 might return that E1' could possibly be interested in. Ricky> These are "fragmentation needed", "unreachable due to TOS (net and Ricky> host)", and to a lessor degree "source quench" and/or ECN notifications. As noted elsewhere, ECN does not use ICMP. Ricky> The Fragmentation and TOS messages are of possible interest to E1' Ricky> because the associated bits from E1's IP header were copied I would strengthen this to: fragmentation is REQUIRED by E1'. I have experience with installations where road warriors simply can not pick up larger emails from a POP server via an IPsec tunnel because of the way that fragmentation is not handled by the security gateway. The gateway encrypts big packets and fragments the result and the (slow) link is congested, so they always lose a fragment of the larger packets. TCP never makes any progress. Ricky> So Sgw1 has four questions to answer about ICMP messages Ricky> received from R1 intended for return to E1'. Ricky> 1. Is this message intended for me directly or for some endpoint I Ricky> protect? Ricky> 2. Is this an interesting message? Ricky> 3. Do I trust the message? Ricky> 4. Is there enough information in the message to be useful to E1'? Ricky> To answer question number 1 above use the following logic: If Ricky> message is an ICMP query, then it is not for E1'... respond to ICMP Ricky> queries to this interface as per local interface policy. If message is Ricky> an ICMP error, then examine the original offending packet data IPSec Ricky> Header field for a valid SPI number. Presence of an SPI implies that Ricky> this message is intended for some endpoint and not for the Sgw itself. Ricky> If the message is in fact intended for this Sgw, then local policy Ricky> should specify whether to handle/respond or ignore the message. I find this too ad-hoc. I suggest you distinguish error and informational messages. Echo Request is an informational type. Errors get processed in particular ways, while informational types pass through based upon local policy. Ricky> MAY be forwarded onward to E1'. All other ICMP messages intended for E1' Ricky> MUST be dropped. Now you may ask yourself, "What about all those Ricky> unreachable messages?" Receipt of an 'unreachable' IMCP error message on Ricky> Sgw1 while it was trying to send to Sgw2 is not a problem that E1 need Ricky> be informed of directly. It is an implementation concern with what to do Ricky> when tunneled traffic is attempting to reach an unreachable peer Ricky> gateway. ICMP unreachable messages may be a clear DOS attack on security gateways, but at the same time they are useful "advice" Ricky> ICMP traffic from R2 to E1' Ricky> MUST be dropped by Sgw2 due to no match with selectors. But, Ricky> note a workaround here. If an operations and maintenance group wishes Ricky> to trust and allow these ICMP messages (from R2 to E1'), Ricky> configure on Sgw1 and Sgw2, new selectors which match R1's IP addresses, Ricky> to E1's IP address(es) and protocol = ICMP. In this case, R2 becomes a Ricky> new, legitimate endpoint (let's say E3). An SA from Sgw2 to Sgw1 for Ricky> carrying E3 to E1' ICMP traffic is negotiated and utilized. The Ricky> parameters of this SA will be entirely up to the O&M group. I suggest that for error conditions that the IP header that is quoted be examined by SGw2, the src/dst addresses be reversed and checked against the SPD. In PAX PDL notation, one would use the following pattern with records from the SPD enumerated. Wildcards in the SPD show up as wildcards when these patterns are instantiated. PATTERN IcmpFragmentNeededPacket(src BIT 32, dst BIT 32, prot BIT 8, srcport BIT 16, dstport BIT 16) { ip1 IP_4_Hdr(*, dst) WHERE protocol == IPPROTO_ICMP; ich IcmpBasicHeader(ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED); ip2 IP_4_Hdr(dst,src) WHERE protocol == prot; Payload ANYOF { protocol == IPPROTO_TCP : tcpbody TcpHeader(dstPort, srcPort) protocol == IPPROTO_UDP : udpbody UdpHeader(dstPort, srcPort) } } Note that src/dst values are *exchanged* in the header that is matched, since the SPD matches packets that go the other way. This assumes that SAs are created in matched pairs. See draft-nossik-pax-pdl-00.txt for longer explanation of this notation. I am using this notation as documentation only. Ricky> ICMP traffic from E2' to E1': Ricky> Handle as per IPSec selector specifications on Sgw2. It is Ricky> recommended that even when E2 is more narrowly idenified than an IP Ricky> address, that protocol=ICMP be configured to fit in the selector. This is something that we need to indicate during negotiation, otherwise SGw1 will reject the packet when it checks what is coming out of the tunnel. Tunnel exit conditions are probably the most difficult thing to test since it requires a non-compliant implementation to test against! So, we need to do either do: 1. offer a new selector type in IKE which is the "I will include ICMP error messages relating to any packet that matches the SPD". If the peer doesn't understand this, then it will select the proposal that doesn't include this option instead. 2. define a way to define proposals which are unions of protocols and define a selector for ICMP messages. I favour #1 in the short term as it can be done without major unheaval, and #2 for the next revision of IKE. Ricky> New requirements for IPSec Security Gateways. Ricky> o a per interface ICMP allow/deny/if-match-endpoint-IP config toggle Ricky> o a per interface trust ICMP error frag-needed toggle Ricky> o a per interface trust ICMP error TOS deny toggle Ricky> o when generating an ICMP error, MUST bundel entire original IP Ricky> datagram and clear DF bit. Ricky> o Never send ICMP errors to an ISAKMP peer. This is a good list, and should be a document with each requirement clearly explained. ICMP isn't simple, so don't be surprised if handling it takes a lot of text. Our current documents handle 98% of desired traffic, but the law of dimishing returns starts to apply when covering the corner cases. {some definitions used above} PATTERN IP_4_Pkt ( SrcAddr BIT 32, DstAddr BIT 32 ){ eh Ethernet_Hdr WHERE Type == ETHERTYPE_IP; iph IP_4_Hdr(SrcAddr, DstAddr); } /* UDP header */ PATTERN IcmpBasicHeader (type UINT 8, code UINT 8) { type UINT 8 == type; code UINT 8 == code; checksum BIT 16; } PATTERN TcpHeader (srcPort UINT 16, dstPort UINT 16 ){ src UINT 16 == srcPort ; /* source port */ dst UINT 16 == dstPort ; /* destination port */ sequenceNumber UINT 32; acknowledgmentNumber UINT 32; dataOffset UINT 4 >= 5; reserved BIT 6 == 0b000000; ctrl Control; window UINT 16; checksum BIT 16; urgentPointer UINT 16; optionsAndPadding ANYOF { dataOffset == 5 : opt0 TcpOptions 0; dataOffset == 6 : opt32 TcpOptions 32; dataOffset == 7 : opt64 TcpOptions 64; dataOffset == 8 : opt96 TcpOptions 96; dataOffset == 9 : opt128 TcpOptions 128; dataOffset == 10 : opt160 TcpOptions 160; dataOffset == 11 : opt192 TcpOptions 192; dataOffset == 12 : opt224 TcpOptions 224; dataOffset == 13 : opt256 TcpOptions 256; dataOffset == 14 : opt288 TcpOptions 288; dataOffset == 15 : opt320 TcpOptions 320; } } /* UDP header */ PATTERN UdpHeader (srcPort UINT 16, dstPort UINT 16 ){ src UINT 16 == srcPort; /* source port */ dst UINT 16 == dstPort; /* destination port */ length UINT 16; /* datagram length */ checksum BIT 16; /* checksum */ } ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBN0daGI5hrHmwwFrtAQFCMAL9G6rhG13nsiDg7kzKq9inrdHXmDyIgu3S HlwNuJnLbT70P6Q1X3Dziqc9A3EprWtcnAot9puEY1UtqnJPW3TNhWnin1AQjAOV sm51f+2/O5Jy/ASAFOxZtRcP/6G9Yrya =TTnM -----END PGP SIGNATURE-----
- RE: ICMP in IPSec Black_David
- ICMP in IPSec Ricky Charlet
- Re: ICMP in IPSec Ari Huttunen
- Re: ICMP in IPSec Ricky Charlet
- Re: ICMP in IPSec Michael Richardson
- Re: ICMP in IPSec Loretta Zhou
- Re: ICMP in IPSec Ricky Charlet
- Re: ICMP in IPSec Ricky Charlet