Subject: [BEHAVE] silently discarding packets?

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Apr 2009 16:18:22 +0200

Hi,

One of the comments we received form Greg on the NAT64 draft is about 
whether the NAT64 should send ICMP error messages when discarding 
packets for which it doesn't have a binding for.

The current draft reads:

     <t>If the packet arrived on the IPv4 interface and the NAT64
     filters on its IPv4 interface, then the NAT64 checks to see if
     the incoming packet is allowed according to the
     address-dependent filtering rule. To do this, it searches for
     a session table entry with a source IPv4 transport address
     equal to the destination IPv4 transport address in the incoming
     5-tuple and destination IPv4 address (in the session table entry)
     equal to the source IPv4 address in the incoming 5-tuple.
     If such an entry
     is found (there may be more than one), packet processing
     continues. Otherwise, the packet is discarded. If the packet
     is discarded, then an ICMP message SHOULD be sent to the
     original sender of the packet, unless the discarded packet is
     itself an ICMP message. The ICMP message, if sent, has a type
     of 3 (Destination Unreachable) and a code of 13 (Communication
     Administratively Prohibited).</t>

According to Greg, most implementations silently drop the packet in thsi 
case.
I was thinking to downgrade it to a MAY... what people think?

Thanks, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Apr 2009 16:30:01 +0200

>    Administratively Prohibited).</t>

Wouldn't a TCP reset or port unreachable make more sense?

> According to Greg, most implementations silently drop the packet in  
> thsi case.

In the case where there was a mapping but it timed out sending back a  
message that will get the other side to update its state would be  
helpful, IMO.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Apr 2009 16:44:45 +0200

> Wouldn't a TCP reset or port unreachable make more sense?

ok, sorry if i didn't gave enough background
Let me try again.

This was for UDP and for a packet coming from the IPv4 interface.
If the packet is coming form the IPv6 interface, we would send

The type should be 3
          (Destination Unreachable) and the code should be 0 (Network
          Unreachable in IPv4, and No Route to Destination in IPv6).

For TCP is still work in progress

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Apr 2009 17:29:22 +0200

>         Unreachable in IPv4, and No Route to Destination in IPv6).

Well, what I said still applies: if there was previously data flowing  
but the translator removed the state, it's helpful to the IPv4 host to  
get a reset in the form of a port unreachable:

Type    Name                                              Reference
----    -------------------------                         ---------
   3     Destination Unreachable                           [RFC792]

	Codes
              3  Port Unreachable                           [RFC792]

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 22 Apr 2009 14:48:53 -0400

Hello Marcelo,

I believe a 'MAY' is appropriate.  Otherwise it seems to me a security issue since if somebody does not get an ICMP back, it knows there is a binding and if there is no binding, it makes the device have to send ICMP packets back.

Thanks,

Reinaldo

On 4/22/09 7:44 AM, "marcelo bagnulo braun" <[email-masked]> wrote:

The type should be 3

> message that will get the other side to update its state would be

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

---

From: Dave Thaler <[email-masked]>
Date: Wed, 22 Apr 2009 14:03:16 -0700

I think the choice of MAY vs SHOULD should not be made simply
on the basis of what most implementations do, but rather on
what we think the right thing is.  (If it's a MAY or a SHOULD
and implementations don't do it, they're still compliant.)

I'd say the NAT64 component SHOULD do it, but that a firewall
(whether on the same box or not) might block it.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, April 22, 2009 7:18 AM
> To: Behave WG; Gregory M. Lebovitz
> Subject: [BEHAVE] silently discarding packets?
>
> Hi,
>
> thsi

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Apr 2009 10:10:54 +1200

For sure you can't rely on it because of firewalls, but
otoh it could be extremely useful for diagnostics when
things go wrong.

I'd go for SHOULD, but MUST be possible to configure on or off.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Apr 2009 21:16:13 -0700

> I was thinking to downgrade it to a MAY... what people think?

I think I would agree with that. Such packets may be part of an  
attack, of which the ICMP packets may be an amplification of the  
attack. Hence, I would think that it should be configurable whether  
they are responded to or not.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 22 Apr 2009 21:34:01 -0700

> they are responded to or not.

We could try fight this battle with firewall vendors, tell them to not silently discard packets, but please don't have much hope. They will make the general argument about stealth: it is generally safer to not respond to packets that you are not expected. We may choose to keep huffing and puffing for some time, but my guess is that in the end the brick wall will still be standing.

If you think about it some more, the firewall guys really have a point. Our protocols should really not depend on error messages coming back, and specifically not on error messages that cannot be authenticated. The same RST that indicates that a port is closed could also be used by an attacker to trick unsuspected host in believing that a port is closed. Do we really want to put up a fight to ensure RST attack are still possible?

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Apr 2009 08:16:32 +0200

> they are responded to or not.

If an attacker sends packets and then gets ICMP port unreachables (or  
TCP resets) back, how does that help the attacker?

Someone said the attacker could use this to observe whether a mapping  
exists, but since a mapping only exists if there were packets to/from  
the address used by the attacker fairly recently anyway, the attacker  
would already know.

I.e., if 11.11.11.11 has a session through the NAT64 using ports 80  
and 1025, and then 99.99.99.99 sends a packet witch ports 80 and 1025,  
the NAT64 would always send an error to 99.99.99.99 so an off-path  
attacker wouldn't be able to find out any information.

This whole "ICMP is scary" business is nonsense, we have ICMP for a  
reason, we should use it like intended.

About firewalls: it's a firewalls business to break RFCs, so whatever  
we write in an RFC a firewall vendor isn't going to care. This isn't  
about firewalls, this is about translation devices.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 23 Apr 2009 03:48:40 -0400

I was basing my assertions on the following REQs from the ICMP BEHAVE RFC.

  REQ-4: If a NAT device receives an ICMP Error packet from an external
          realm, and the NAT device does not have an active mapping for
          the embedded payload, the NAT SHOULD silently drop the ICMP
          Error packet.  If the NAT has active mapping for the embedded
          payload, then the NAT MUST do the following prior to
          forwarding the packet, unless explicitly overridden by local
          policy:

  REQ-9: A NAT device MAY implement a policy control that prevents ICMP
          messages being generated toward certain interface(s).
          Implementation of such a policy control overrides the MUSTs
          and SHOULDs in REQ-10.

The above seems to capture what some people were expressing about silently drop and policy control.

On 4/22/09 11:16 PM, "Iljitsch van Beijnum" <[email-masked]> wrote:

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Apr 2009 09:58:31 +0200

So, what i am reading is that most of people think that there are valid 
(security) reasons not to send ICMP errors back.

What about the following (based on Brain's proposal)

    If the packet is discarded, then the NAT64 device SHOULD
    be able to send back an ICMP message  to the
    original sender of the packet, unless the discarded packet is
    itself an ICMP message. The ICMP message, if sent, has a type
    of 3 (Destination Unreachable) and a code of 13 (Communication
    Administratively Prohibited). The NAT64 device MUST allow to configure
    whether the ICMP error messages are sent or not.

how does this sounds?

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Apr 2009 10:19:48 +0200

On 23 apr 2009, at 9:48, Reinaldo Penno wrote:

>  REQ-4: If a NAT device receives an ICMP Error packet

> silently drop and policy control.

No it doesn't. The above just makes sure there are no ICMP messages  
sent for ICMP messages, in order to prevent "ICMP storms".

If people want to filter ICMP messages, that is stupid because they  
serve important functions (unreachables avoid lengthy application  
timeouts) but that's their business. It's not a NAT64's job to make  
that decision for other people, especially as we expect NAT64s to be  
deployed by ISPs.

> attacker wouldn't be able to find out any information.

Ok, that's not exactly how it works, I forgot to take endpoint  
independent behavior into account. So that means more packets match a  
mapping, but if there is no match we still need those ICMP messages.

On 23 apr 2009, at 9:58, marcelo bagnulo braun wrote:

> So, what i am reading is that most of people think that there are  
> valid (security) reasons not to send ICMP errors back.

Superstition isn't valid and it's only a (small) handful of people  
who've spoken up. If we want to break existing (without a translator)  
behavior we should at least have a decent consensus call.

>   itself an ICMP message.

Not able, it should simply do it.

>   The ICMP message, if sent, has a type
>   Administratively Prohibited).

No, it should be a port unreachable.

>   The NAT64 device MUST allow to configure

I don't see any reason for this text, if operators want this they can  
ask their vendors for it. Interoperation isn't enhanced by including  
this as a must so there is no reason to include it.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 23 Apr 2009 04:41:14 -0400

Your comment was based on REQ-4 alone.

REQ-9 mention the issue of policy control overriding whether or not NAT
generates messages. So, NAT64 is not making the the decision one way or
another. It is configurable.

---

From: Gregory Lebovitz <[email-masked]>
Date: Sun, 26 Apr 2009 23:26:11 -0700

> I'd go for SHOULD, but MUST be possible to configure on or off.

I like Brian's thinking on this, and would take it just a bit further. The
text ought to:

- explain why it is very useful for diagnostics to send
- explain in that firewalls today provide the option for sending or not
sending
- describe the security consideration in choosing to send or not send
- say, "because of the contradictory nature of the two good things (i.e.
diagnostics and security) the deployer will need to decide which is best for
their environment."
- MAY send
- MAY silently discard
- implementations MUST provide the option to do either
- hosts MUST NOT assume the existance of a send

Not the tightest text in the world, but it fits the reality of the situation
in question.

Hope it helps,
Gregory.

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks