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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 Oct 2007 10:06:41 +0100

Behave,

I think the discuss from Lars below needs WG discussion. I like to here
opinions about this.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

Subject: DISCUSS and COMMENT: draft-ietf-behave-nat-icmp
From: Lars Eggert <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Sat, 27 Oct 2007 17:46:45 -0400
List-Id: iesg.ietf.org

Discuss:
Section 4.1., paragraph 4:
>    REQ-3:  When an ICMP Error packet is received, the NAT device
>    SHOULD do the following.
>    a) If the IP checksum of the embedded packet fails to validate, drop
>    the Error packet

  DISCUSS: I disagree. (And I apologize for not catching this during my
  earlier review.) The reason that (part of) the packet that caused an
  ICMP message to be generated is included is for diagnostic purposes,
  so the end hosts can determine what went wrong and determine whether
  they need to react in some way. This can't happen if NATs drop these
  packets. Also, the reason why some end system OSs drop ICMP messages
  with invalid checksums is to protect against some attacks. NATs,
  however, are not firewalls. It is inappropriate for this document to
  specify NAT mechanisms that implement a specific security policy.
  There is also no IETF standard that recommends that end hosts drop
  ICMP packets with payloads that have invalid checksums, which is
  another reason why this document should not recommend that NATs do
  this. (And, as an aside, the effectiveness of this "security" measure
  is questionable, because if I can't spoof the complete packet with a
  valid checksum, I'd just include a partial packet in the payload, for
  which you can't validate the checksum, but that you must still act
  on.)

Comment:
Section 240, paragraph 0:
>    ICMP Query session timer MUST not expire in less than 60 seconds. We

  s/MUST not/MUST NOT/

Section 240, paragraph 1:
>    RECOMMEND however that the administrator(s) be allowed to configure

  RECOMMEND is not an RFC2119 term. You need to rephrase to say
  RECOMMENDED, MUST or REQUIRED. (Or use lowercase here, because REQ-2
  has the correct 2119 phrasing.)

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

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 29 Oct 2007 11:13:31 -0400

Magnus, Lars,

Please find my 2¢ in a couple of comments inline.

On 10/29/2007 5:06 AM, Magnus Westerlund said the following:
> ------------------------------------------------------------------------
> 
> Subject:
> DISCUSS and COMMENT: draft-ietf-behave-nat-icmp
> From:
> To:
> [email-masked]
> To:
> [email-masked]
> CC:
> [email-masked], [email-masked]
> 
> 
> Discuss:
>   they need to react in some way.

This requirement is about the IP Header Checksum of the embedded packet,
and ICMPs should not be generated when the IP Header Checksum fails:

For hosts: RFC1122:
   3.2  PROTOCOL WALK-THROUGH
      3.2.1 Internet Protocol -- IP
         3.2.1.2  Checksum: RFC-791 Section 3.1
...
            A host MUST verify the IP header checksum on every received
            datagram and silently discard every datagram that has a bad
            checksum.

For routers: RFC1812:
5.2.2 IP Header Validation
...
   that the header is meaningful.  If the packet fails any of the
   following tests, it MUST be silently discarded, and the error SHOULD
   be logged.
...
   (2) The IP checksum must be correct.

Therefore, I don't disagree with this requirement.
If the IP Header Checksum is incorrect, and the NAT fixes-up the
embedded IP Address, how should it update the checksum?

> This can't happen if NATs drop these

The REQ-3 a) quoted in the discuss refers to the IP Header Checksum of
the embedded packet. However this comment seems to be referring to REQ-3
d), i.e.:

   d) If the embedded packet contains the entire transport segment,
   and the transport protocol of the embedded packet requires the
   recipient to validate the transport checksum, and the checksum
   fails to validate, drop the Error packet.

In that case, I think a MAY for REQ-3 d) is likely more appropriate (to
leave some room for implementing it if desired), although another option
is  removing it as a requirement. I agree that the "protection"
effectiveness is questionable, but in any case it's a mechanism that I'd
think would kick in in very limited cases. I cannot think of a general
harmful scenario that would result for dropping those, but maybe
something that might not get widely implemented either. There seem to be
soem corner case scenarios. E.g.: this requirement may possibly mask a
bug in a host or NAT setting bad tcp checksums that trigger the
generation of ICMPs before the destination TCP gets to process the
transport checksum (e.g., unreachables, time exceeded, that also embed
the complete segment), and those ICMPs would not reach the sending host.
However, it those packets did reach the destination application, the
source would not receive a hint of what the problem is either.

Thanks,

--Carlos.

> ------------------------------------------------------------------------
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 30 Oct 2007 08:46:44 -0700 (PDT)

Lars and Magnus, 

Please see my responses inline.

regards,
suresh

--- Magnus Westerlund <[email-masked]> wrote:

> CC: [email-masked], [email-masked]
>   packets. 

[suresh] As Carlos responded on this e-mail thread, ICMP error messages should
not be generated by endhosts or router when the IP Header Checksum fails.
Packets with bad IP header checksum MUST be silently dropped by endhosts and
routers. The recommendation here is also to drop an ICMP error message if the
embedded IP Header Checksum is BAD.

>            Also, the reason why some end system OSs drop ICMP messages
>   this.

[Suresh] I Assume, you are refering to Req-3d here. We had extensive discussion
on this in the WG and in the end agreed to make this a SHOULD. Here are some
reasons I recall.

End-hosts should not be generating IP packets with BAD transport checksum.
Further, ICMP error messages are not generated due to BAD transport checksum in
the IP packet. So, the likely case where an ICMP error packet contains a BAD
embedded transport checksum is when it is spoofed. Also, many new
implemenations now check against BAD embedded trasnport checksum in ICMP error
messages (when the payload contains  requsite bytes to compute the checksum).
So, we decided to make this a SHOULD requirement to mitigate malformed ICMP
errors from reaching endhosts.

>        (And, as an aside, the effectiveness of this "security" measure

[Suresh] Right, checksum validation merely mitigates end hosts from malformed
ICMP Error attacks, doesnt eliminate it. The security consideratiosn section
also has a discussion on this.
 
> >    ICMP Query session timer MUST not expire in less than 60 seconds. We
[suresh] Will do.

>   has the correct 2119 phrasing.)
[suresh] OK. I will reword the sentence as follows. Thanks.

    It is RECOMMENDED however that the administrator(s) be allowed to
    configure the timer.

regards,
suresh

---

From: Lars Eggert <[email-masked]>
Date: Tue, 30 Oct 2007 18:34:24 +0200

Hi,

you are right that I had been mixing two issues in my DISCUSS,. i.e.,  
what NATs should do when the IP checksum of the embedded packet is  
incorrect, and what they should do when the transport checksum is  
incorrect. Let's discuss these separately.

> and ICMPs should not be generated when the IP Header Checksum fails:

I agree that ICMPs should not be generated in response to receiving a  
packet with an invalid checksum.

But REQ-3 is about acting on the IP and transport checksums of  
packets that are embedded in the payload of an ICMP packet. RFCs 1122  
and 1812 don't apply to this.

> embedded IP Address, how should it update the checksum?

Dropping them is one option.

Leave the checksum incorrect but still translating the addresses is  
another, and one that leaves the end host in the loop. It leaves the  
end host the choice on what to do, whereas dropping the packet  
removes that choice.

(Not translating the embedded IP addresses is a third option, but I'm  
not sure how useful that is.)

> leave some room for implementing it if desired),

A MAY is not appropriate. No standards track RFC allows this (MAY) or  
recommends this (SHOULD/MUST) for end systems. So even a MAY for NATs  
goes beyond our current recommendations for end systems.

> although another option
> is  removing it as a requirement.

This would be my preferred resolution.

> I agree that the "protection"
> think would kick in in very limited cases.

So if you agree that the effectiveness is questionable and it may not  
kick in very often either, why burden NAT implementations with this  
functionality?

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 30 Oct 2007 18:38:58 +0200

> embedded IP Header Checksum is BAD.

As I said in my earlier reply to Carlos, the 1122 and 1812  
recommendations aren't about IP headers embedded in ICMP payloads.

> embedded transport checksum is when it is spoofed.

No. The likely case is flaky hardware that introduces bit errors.

> Also, many new

NATs are not firewalls. It is not their task to protect the end  
systems from anything.

Lars

---

From: Carlos Pignataro <[email-masked]>
Date: Tue, 30 Oct 2007 13:29:47 -0400

> and 1812 don't apply to this.

IMHO, the question is: under which legitimate circumstances can an IP
datagram with invalid Internet Header Checksum generate an ICMP error,
such that it gets embedded in the ICMP? RFC1122 and 1812 do apply in the
processing of a packet with invalid checksum, and if they need to be
silently dropped, how can they get embedded into ICMPs? So the citations
are in the ICMP-eliciting path. The only option (besides bugs) appears
to be that the IP Hdr checksum got corrupted after the IP Hdr got
embedded on the icmp and it's on its way back, in which case the ICMP
checksum would fail and the "corrupted" header won't be processed by the
originating host anyway, correct?

> end host the choice on what to do, whereas dropping the packet  

It's not clear to me that there's a lot of meaningful information that
the host would want to be in the loop for in these cases (see the
previous para).

> not sure how useful that is.)

But this one could potentially expose cross-realm addresses.

> goes beyond our current recommendations for end systems.

lowercase "might"? :) See below.

> kick in very often either, why burden NAT implementations with this  

Because it appears the WG found consensus around leaving it as something
potentially (or under some cases) useful, and it appears to be something
that a "strict policy" might want, I think that leaving room for
implementing it (while not requiring) is of value.

Thanks,

--Carlos.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 31 Oct 2007 10:30:31 +0200

On 2007-10-30, at 19:29, ext Carlos Pignataro wrote:
> silently dropped, how can they get embedded into ICMPs?

You assume that an ICMP message that contains an embedded IP packet  
with an invalid checksum was generated somewhere in response to  
receiving this IP packet with an invalid header checksum.

It is equally possible that the ICMP message was generated based on  
an IP packet with a valid checksum, but then got corrupted during  
transmission.

> So the citations

The ICMP checksum only covers the ICMP header and not the payload.  
(Unless I'm seriously misreading RFC792.)

> the host would want to be in the loop for in these cases (see the

It's not obvious to me that hosts wouldn't. Not dropping these  
packets leaves them the option to choose.

> But this one could potentially expose cross-realm addresses.

Right, that's why it's not useful.

Let me try to make my point with a different argument: What would a  
plain RFC1812 router do, if it was in the path instead of a NAT? A  
router would simply forward the ICMP packet, irrespective of whether  
the IP checksum of a packet embedded on an ICMP message was valid or  
not. A NAT should do exactly the same, in my opinion, i.e., it should  
forward the packet whenever it can. So if it has a binding that  
allows it to translate the embedded IP header, it should always do  
so, even if the embedded checksum is invalid.

>>> In that case, I think a MAY for REQ-3 d) is likely more appropriate
>>> (to leave some room for implementing it if desired),
>>

I wouldn't even want to allow that.

> implementing it (while not requiring) is of value.

BEHAVE isn't chartered to design security mechanisms ("strict  
policy".) I'm not saying that that shouldn't be done, but BEHAVE  
under the current charter isn't the WG to do it.

Lars

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 31 Oct 2007 07:29:16 -0700 (PDT)

> an IP packet with a valid checksum, but then got corrupted during  

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

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. 

Unlike a router that does not examine the ICMP error payload, NAT examines the
embedded payload for session match and modify IP addresses and fixes checksum
before forwarding the IP packet to the intended recipient. 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.

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. 

> (Unless I'm seriously misreading RFC792.)

[suresh] I do believe, the ICMP checksum covers the entire ICMP message
includign the payload.
> so, even if the embedded checksum is invalid.

[suresh] Please see my comment above. NAT does a combination of router and
end-host functionality. Unlike a router, it is a requirement for NAT to examine
the ICMP error payload in order to determine where to forward the ICMP error
packet. If the enbedded IP header is suspect, NAT cannot do its job right.

> under the current charter isn't the WG to do it.

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

regards,
suresh

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 31 Oct 2007 11:09:29 -0400

Lars,

Thanks for the follow-up, please see some comments inline (separating
Req3-a from Req3-d)

> an IP packet with a valid checksum, but then got corrupted during  

Yes, as noted below.

> (Unless I'm seriously misreading RFC792.)

No, the ICMP checksum covers the complete ICMP message starting from the
ICMP Type. It does not include a pseudo-header (unlike ICMPv6). For ICMP
errors, the checksum includes the embedded packet. As such, the host
receiving the ICMP would not get to processing the "corrupted" header.

> packets leaves them the option to choose.

It is not clear to me under which conditions it would, and that the host
would actually get to processing the embedded info.

> so, even if the embedded checksum is invalid.

I don't think that this comparison is valid, because an RFC1812 router
does not examine and modify the ICMP payload to perform its function
(and as was noted on this list, from the outside network's perspective a
NAT is more host-like). However, one additional viewpoint, if the
embedded IP Header checksum is invalid, and a binding is found, do you
think the NAT should trust and act upon that binding (given that the
embedded IP addresses, IP protocol numbers can be corrupt)? Do you think
it should recalculate a correct checksum? IMHO, a SHOULD in Req3-a is
useful.

> under the current charter isn't the WG to do it.

I was thinking in terms of "reliability" rather than "security". If the
embedded L4 checksum is incorrect, the L4 ports or pseudo-headers may be
incorrect, resulting in a mis-binding. I'd think that the NAT could not
reliably perform its function (or could mis-associate). OTOH, I agree
that there may be cases in which a host may want to see these. IMHO, the
text of Req3-d is useful, and it should be a recommendation; the level
of recommendation IMHO could be either MAY or SHOULD (though SHOULD may
be a bit too strong here).

Thanks,

--Carlos.