Subject: Re: [BEHAVE] [Fwd: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp]

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Nov 2007 12:53:32 +0200

On 2007-10-31, at 16:29, ext Pyda Srisuresh wrote:
> --- Lars Eggert <[email-masked]> wrote:
>> On 2007-10-30, at 19:29, ext Carlos Pignataro wrote:
>>> On 10/30/2007 12:34 PM, Lars Eggert said the following:
> [suresh] We all agree that IP packets with BAD IP header checksum  
> are silently
> dropped by end-hosts and routers. ICMP errors are not generated by  
> end-hosts or
> routers in response to IP packets with bad IP header checksums.

Correct.

> In that case, how could the embedded IP header checksum have been  
> corrupted?
> You say, one possibility is corruption during transmission.  
> Corruption of which
> specific bits in the IP header? It could have been transmission  
> corruption on
> any part of the IP header - Src/Dest IP addresses, TTL, Length,  
> Checksum etc.
> We cannot assume that every other part of the IP header may be OK,  
> but checksum
> alone may have gotten corrupted. In other words, if the IP header  
> checksum is
> corrupted, the entire IP header is suspect.  That is the gist of  
> recommendation
> for REQ-3a.

Please be precise in your terms. We're talking about ICMP packets  
here that have their own header checksum (like IP), an ICMP message  
checksum and an embedded payload that contains the first part of an  
IP packet, which also has a header checksum and may have a transport  
checksum. We need to clearly differentiate between these for the  
purposes of this discussion.

Let me restate my concerns in those terms.

Obviously, a NAT needs to verify if the header checksum in the  
outermost IP header is correct before doing anything, as in RFC1812.  
We have no argument about this.

Next, ICMP messages include a checksum that covers the entire ICMP  
message. I actually couldn't find anything in 792, 1122 and 1812 that  
defines where this checksum is to be validated, but since ICMP is  
carried end-to-end inside IP, I'd assume the idea is that the end  
system validates it, as for our other transport protocols.

You can argue that a NAT acts as an end system here, because it needs  
to rewrite the contents of the ICMP message. In that case, you can  
argue that it should validate the ICMP message checksum and drop the  
packet if it is invalid. (The draft currently doesn't talk about  
this, however, and probably should.)

Next, the ICMP payload contains the beginnings of the IP packet that  
caused the ICMP message to be generated. Here is where our  
disagreement starts.

It's highly unlikely that the ICMP message checksum will be valid and  
the IP checksum of the embedded packet will be invalid, because, as  
you correctly point out, ICMP messages aren't supposed to be  
generated in response to corrupt IP packets. So while the NAT could  
validate the IP header checksum of the embedded packet, it's not  
clear how useful that will be. If you want to recommend this, I can  
live with it.

My main concern is with validating the transport checksums as a  
security measure, and the rest of this email will discuss this concern.

> In order for a NAT
> to make the mods, NAT needs to start with a good base. Modifying an  
> IP packet,
> fully knowing that it's header is suspect, could result in  
> bombarding the wrong
> end-host with the ICMP error message.

First, "bombarding" isn't the term I'd use when we're talking about  
forwarding one packet.

Second, if you're concerned here that an attacker may abuse this to  
blast traffic at a host and want to prevent this, you're entering the  
realm of defining security mechanisms, which BEHAVE isn't chartered  
to do.

> It woudl be derelict to not drop suspect IP packets for a device  
> that examines
> the payload and detects checksum failure. I do believe, the current
> recommendation of SHOULD as Best Current Practice is the right  
> thing to do.

Routers don't check transport checksums to identify "suspect"  
packets, either.

And again, your choice of wording makes it clear that you do want to  
design a security mechanism here.

> [suresh] Lars - This is not one of designing a security mechanism  
> within BCP.
> This is a NAT functionality requirement. NAT needs to examine the  
> IP and
> transport headers in order to make decisions concerning translation  
> and
> forwarding. When the IP and transport checksums are BAD, the  
> corresponding IP
> and transport headers are suspect. When the IP and trasport headers  
> are
> suspect, NAT does not have a good base to start from. I hope, you  
> agree, it is
> not advisible to do lookups or translations knowing fully well the  
> base headers
> are suspect. Hence, the recommendations REQ-3a, 3d. Thanks.

As I said above, I can live with NATs validating the IP header  
checksums of embedded packet, even though I don't think it will matter.

Validating the transport checksums, in a way that goes beyond what  
the IETF is currently recommending for end systems, is the issue.

Lars

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Thu, 1 Nov 2007 07:57:20 -0400

If I understand things correctly, the question concerns an incoming  
ICMP error response. Specifically the question is: Should the NAT  
verify the checksum of the embedded IP and transport header before  
updating the IP addresses and ports in those headers?

Let's look at how the NAT handled the original (outgoing) UDP or TCP  
packet. Neither BEHAVE-UDP (RFC 4787) or BEHAVE-TCP say anything  
about the NAT having to check the IP or transport header checksum  
before updating the IP addresses and ports in those headers.

Since we are not mandating that the NAT verify the checksums in the  
original outgoing packet, it seems wrong to mandate that the NAT  
verify the checksums in the ICMP error response.

Thus I think we should remove this requirement from the ICMP document.

- Philip

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 7 Nov 2007 06:13:38 -0800 (PST)

Lars,

Please see my comments inline.

regards,
suresh

> this, however, and probably should.)
[suresh] As you said, RFCs 791, 1122 and 1812 are mum about ICMP checksum
validation. So, we did not mention anything about ICMP checksum validation in
the draft. However, I agree with you that the draft should add a requirement to
validate the ICMP checksum. I will go ahead and add this.

> clear how useful that will be. If you want to recommend this, I can  
[suresh] OK. Couple of comments. First, I do agree with you that the usefulness
of validating embedded IP header checksum is limited if the ICMP message
checksum is not validated. Second, NAT is able to definitively validate the
embedded IP checksum, as all the bits necessary to validate the embedded IP
header checksum are guaranteed to be within the ICMP error message. This is
unlike the transport checksum, where the transport segment is not guaranteed to
be fully embedded within the ICMP error message. 

SO, I will go ahead and keep the recommendation to validate the embedded IP
header checksum. Thanks.

> design a security mechanism here.
[suresh] Lars - Your inference that I was wanting to desing a security
mechanism in incorrect. I used the word "suspect" to refer to the bits
corrupted along transmission. If you have a different choice term, please
suggest one. I will be happy to use that. Thanks.

> the IETF is currently recommending for end systems, is the issue.

[suresh] Couple of comments on validating the transport checksum. 
a) The usefulness of validating the embedded transport checksum is limited if
the ICMP message checksum is not validated; 
b) It would be useful if NAT could guarentee the validity of all tuple fields
of the embedded IP packet (ex: Src IP, Dest Ip, Src port, Dest Port for a
TCP/UDP packet) used for looking up a matching session. However, it is not
guaranteed that ICMP payloads contain the entire transport segment. So, NAT is
not guaranteed that it can validate the transport tuples always.

So, the usefulness of Req-3d is really limited to the cases where the embedded
packet contains the entire transport segment. Considering that you say that
this requirement to validate embedded transport checksum goes beyond what the
IETF is currently recommending for end systems, I am OK to drop the Req-3d.

Thank you for your time.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 7 Nov 2007 06:31:23 -0800 (PST)

> before updating the IP addresses and ports in those headers.
[suresh] As Carlos pointed out earlier, per RFC 1122 and RFC 1812, an endhost
or a router MUST drop an IP packet with invalid IP header checksum. SO, there
is no need to restate this requirement in BEH-UDP or BEH-TCP. 

As for transport checksums - RFC 1122 explictily says (in section 4.1.3.4 and
4.2.2.7) that endhosts MUST validate the transport checksum. So, once again, no
need to restate this requirement in BEH-UDP or BEH-TCP. 

> verify the checksums in the ICMP error response.

[suresh] Please see my comment above.

regards,
suresh