[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ICMP in IPSec
-----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-----
References: