Subject: [BEHAVE] Comments on TCP RST handling in draft-ietf-behave-v6v4-xlate-stateful-02.txt

From: Reinaldo Penno <[email-masked]>
Date: Mon, 26 Oct 2009 02:40:19 -0400

Hello,

The draft is evolving quite nicely and looks very good. I have a comment on
the way TCP RSTs are handled. I will post other comments shortly.

I believe the way the text is written today precludes an implementation that
wants to provide more security. I would not mind if the 'basic' mode of
operation did not preclude a more secure mode, but the way it is written,
this is not possible.

Text is the following...

³   If a V4 RST or a V6 RST packet is received, the packet is translated
   and forwarded.  The lifetime is set to 4 min and state is moved to
   RST RCV.²

And then

³   *** RST RCV ***

   If a packet is received, the lifetime is set to 2 hours and 4 min and
   the state is moved to ESTABLISHED.

   If the lifetime expires, the session table entry is deleted and the
   state is moved to CLOSED.
³

I have two comments on the text above:

1) If I have a way of detecting brute force TCP RST attacks or forged TCP
RSTs I would like to drop the TCP RST instead of blindly translating it. The
current text does not allow for it.

2) If I track TCP seq numbers and the TCP RST passes my security policy, I
do not want to keep the connection around for 4 minutes. This represents a
huge waste of resources knowing that many connections (~12%) end up with TCP
RST.

I have a general comment irrespective of the two points above.

3) keeping a connection around for 2 hour and 4 minutes if just so happens
that I receive a packet after a TCP RST is also a security issue and waste
of resources. I would suggest running a timer _after_ receiving this new
packet and if no other packet is received from the opposite direction then
the connection should be moved to CLOSED state.

It seems this is a escape provision in the case the TCP RST is not
acceptable by the end hosts.

Add-on Text:
-----------

Then I would suggest the following text:

"If the security policy determines that the TCP RST packet is an attack it
can be silently drooped (There is already a similar text for V4 SYNs).

....

If the implementation tracks TCP sequence numbers and the TCP RST passes its
security policy the connection can be moved to the CLOSED state."

Regards,

Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Oct 2009 08:11:04 +0100

> Add-on Text:

I personally don't have an issue with adding this text. I will do so 
unless someone else has a problem and thinks it deserves more discussion.

Regards, marcelo

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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 Oct 2009 11:47:39 +0200

Hi,

> unless someone else has a problem and thinks it deserves more  

objection. A NAT is *not* a security device and does not implement  
"security policies."

We've hit this several times in the past with different BEHAVE  
document, and we've always been very careful to focus on the  
"translator" functions only. (Other WGs have talked about firewall/ 
security functions, e.g., V6OPS.)

Lars

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 26 Oct 2009 06:04:55 -0400

> objection. A NAT is *not* a security device and does not implement

I understand your point of view but security is discussed at length in
RFC4787 and RFC5382.

There are many examples and the word 'policy' is used:

" subject to the NAT's security policy"
" if its security policy permits"
" security properties of the NAT"
...

Filtering behavior is also a type of security.

Therefore what I'm proposing is following previous recommendations. The text
as exists today have security issues.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Oct 2009 11:09:09 +0100

> objection. A NAT is *not* a security device and does not implement  

Agree.

We've had this discussion a while ago. The translator is not in a good  
position to know what are and what aren't legitimate reset packets. If  
it guesses wrong, it can either reset sessions that the host in  
question wanted to keep alive, or it can delay the removal of stale  
state.

A NAT44 isn't a firewall, so in that case the above objection is  
relevant. But a NAT64 is even less of a firewall than a NAT44, because  
the IPv6 side of the translator can't be considered to be "internal".  
Hosts need to handle their own security, translators should stay out  
of this.

And if and when implementers decide that they want to implement  
"security policies" (which would be a mistake as per the above) it's  
important that this functionality is kept separate from the translator  
functionality.

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 26 Oct 2009 06:29:12 -0400

As I said, NAT 'security policy' term is used in RFC4787 and RFC5382. The
current NAT64 document has the following text which follows from the two
RFCs mentioned above.

"     If the **security policy** requires silently dropping externally
      initiated TCP connections, then the packet is silently discarded,
      else,"

"  For any other IPv6 packet, depending on the **security policy** other
   packets MAY be forwarded or MAY be silently discarded. "

"     If the local **security policy** determines that ICMPv6 Informative
      packets are to be filtered, the packet is silently discarded."

Etc....

Therefore I'm not sure as why the term 'security policy' comes as a
surprise. It is in all documents and widely deployed.

I feel that NAT64 should look and feel in terms of behavior (forwarding,
control & security) as closely as NAT44 as possible in order to be deployed
successfully.  

Are you suggesting  all those security considerations should be removed from
NAT64 to another document and/or deprecated in NAT44 documents?

Thanks,

Reinaldo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Oct 2009 11:58:02 +0100

> control & security) as closely as NAT44 as possible in order to be  

No. A traditional NAT44 sits on an internal/external boundary, a place  
where you would naturally want to apply security policy. However, this  
is not the case for a NAT64, which sits more towards the middle of the  
network. (Same for an ISP-operated NAT44.) It makes no sense to import  
NAT44 baggage into NAT64. Also, BEHAVE has been writing up what NAT44s  
actually do, while for NAT64 we're specifying what we WANT them to do,  
which is a rather different approach.

> NAT64 to another document and/or deprecated in NAT44 documents?

Yes, I believe some of the text quoted earlier would best be removed.  
Obviously that doesn't mean a NAT64 document shouldn't have any  
security considerations, just that firewalling should be kept out of  
the NAT64 document.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Oct 2009 12:17:06 +0100

> objection. A NAT is *not* a security device and does not implement 

right, so far we have been following the behave requirements closely, so 
there are a few places where the security policy appears, for instance 
whether to silently discard packets or not.

As i said, i don't have a strong opinion here.

Regards, marcelo

> "translator" functions only. (Other WGs have talked about 
> firewall/security functions, e.g., V6OPS.)
>
> Lars

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Oct 2009 12:25:46 +0100

> NAT64 to another document and/or deprecated in NAT44 documents?

Let me comment on this.

Current NAT64 draft fllows as closely as possible behave requirements 
for nats (TCP, UDP, ICMP)

so, if i have done correctly, only the cases that are explictly 
considered in the behave requirements as depending on the security 
policy are covered in the nat46 spec.
I think this can eb the right approach. We build on the consensus 
reached on the beheva requirements. We don't add or remove any of the 
security considerations compared to the behave requirements.

(please let me know if i a missing any of them in the current nat64 
document, i will heck it mysefl in any case)

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 26 Oct 2009 07:38:35 -0400

Thanks for your answer Marcelo.

I think specifying the TCP state transition and associated behavior 'add new
security considerations' as you put it since it is something not fully
discussed on the previous BEHAVE TCP RFC.

Perhaps a companion document could specify TCP state tracking for NATs since
it is useful and mostly common to both NAT44 and NAT64.

Thanks,

Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 26 Oct 2009 12:42:27 +0100

> it is useful and mostly common to both NAT44 and NAT64.

maybe that is a reasonable way forward.
In the current nat64 we strictly reflect current behave requirements
In addition, an additional document covers the seq number tracking and 
other security features and is presented to the WG for consideration.

regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 26 Oct 2009 07:45:09 -0400

On 10/26/09 3:58 AM, "Iljitsch van Beijnum" <[email-masked]> wrote:

> network. (Same for an ISP-operated NAT44.)

If an enterprise starts using IPv6 where do you think it will sit? I would
suggest that it will sit where NAT44 sits today and not in the middle of the
network somewhere as you mention.

Why do you think this is not a valid case or have such a narrow view of
NAT64? I think NAT64 applicability statement should be clarified in the
document. 

It makes no sense to import
> which is a rather different approach.

Agreed, but operators are used to the look and feel of NAT44 and since NAT64
will in many occupy a similar position and perform similar function,
operators will want similar behavior. I think emails in this regard were
already sent to the list.

> Yes, I believe some of the text quoted earlier would best be removed.

That seems at odds with the general consensus with the document until now...

Regardless, the security text in the current document and the points I
raised around NAT64 would still need to be documented somewhere. There is an
interesting document about this subject.

http://tools.ietf.org/html/draft-gont-behave-nat-security-01

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Oct 2009 12:56:08 +0100

On 26 okt 2009, at 12:45, Reinaldo Penno wrote:

> If an enterprise starts using IPv6 where do you think it will sit?

I don't know. The point of NAT64 is that ISPs run it for their  
customers. But I do know that enterprises are paranoid enough to have  
separate firewalls rather than depend on the way a NAT64 may or may  
not filter TCP resets.

Filtering packets is not a core function of a NAT64 so it shouldn't do  
any packet filtering as such, rather than adopt the notion "hey, these  
are packets that some other boxes would filter out so let's filter  
them out here, too!"

Airplanes have wheels. That doesn't mean we require pilots to have a  
driver's license.

Also, the end-to-end principle applies here: hosts need to validate  
resets anyway, so there is no point in doing that in the middle of the  
network, too.

> There is an

> http://tools.ietf.org/html/draft-gont-behave-nat-security-01

I wasn't very impressed with the previous documents in this series, so  
I'll save myself and the author the aggravation of reading it and then  
firing off a bunch of criticisms.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 26 Oct 2009 08:26:44 -0700

>>> control & security) as closely as NAT44 as possible in order to be

Agreed.  NAT64 should be about service continuity with NAT44.  I
understand the point about baggage of NAT44, but my ideal is that i go
from NAT44 to NAT64 and my customers (excluding the uber-techy 2%)
never know it happened.  NAT44 is the service they pay for today, and
it is the service my operations folks are comfortable delivering and
supporting.

> already sent to the list.

I agree with Reinaldo here.  Many operators will see the NAT64 as an
enhancement to existing NAT44 software / hardware / topology.  In my
deployment, i expect the NAT64 to bridge between my dual-stack / 6VPE
network and the IPv4 internet ... so my NAT64 will be on the border to
the v4 Internet.  I control the servers and services within my
network, so i can make them either dual-stack or leverage the
front-end load balancers to do the internetworking as required.  I
will not use NAT64 for interworking for flows that originate and
terminate in my network.

>> security considerations, just that firewalling should be kept out of

We also must not neglect the fact that many (the majority?) of the
NAT64 boxes and boxes to be have a "day job" of being a firewall.
That said, we don't want to have NAT64 to preclude the value that the
underlying firewall platform may have.  I am not saying NAT64 needs to
be a security device, i wont go near that can of worms, but we just
don't want to preclude the platform from having those features as a
part of a product.  Then again, the vendors frequently can build the
knobs to turn the security on and off.  So, lets just craft the
language so that it does not paint folks into having to be
non-compliant which is bad for them and bad for the standard.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Oct 2009 16:52:00 +0100

On 26 okt 2009, at 16:26, Cameron Byrne wrote:

> never know it happened.

Sorry, I have to disagree.

NAT64 lives in the IPv6 world. In IPv6, there is no NAT. So there are  
no existing ideas about what a NAT should do, either. So what we need  
to do is break as little as we can. Since there is no presumption that  
a NAT64 is going to protect IPv6 hosts (and obviously it isn't because  
it doesn't sit between IPv6-to-IPv6 communications) that means  
filtering as little as possible.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 Oct 2009 18:25:37 +0200

> NAT64 boxes and boxes to be have a "day job" of being a firewall.

Nobody is saying that a vendor cannot or should not implement both  
NAT'ing and firewalling functions on the same piece of hardware. But  
there is no need to conflate the two functions in one IETF  
specification.

The draft should describe how to NAT v6 to v4 in a stateful way.  
Nothing more, nothing less. How to implement firewall functions is  
orthogonal to that.

Lars

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 26 Oct 2009 12:54:30 -0400

On 10/26/09 8:52 AM, "Iljitsch van Beijnum" <[email-masked]> wrote:

> NAT64 lives in the IPv6 world. In IPv6, there is no NAT.

There has been NAT in IPv6 since 8 years ago with NAT-PT. This effort is an
update to NAT-PT.

 So there are  
> it doesn't sit between IPv6-to-IPv6 communications)

We have NAT66 for that.

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 26 Oct 2009 13:10:07 -0400

I think we are talking about NAT specific filtering behavior: port + address
filtering which is a NAT property, translations of unsolicited packets,
dropping certain packets due to state of translation.

A firewall as a separate entity (or software system) as you advocate would
not have access to NAT binding/map tables or policies and therefore cannot
perform such functions. Or maybe you are suggesting something different?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2009 11:07:16 +1300

On 2009-10-27 05:25, Lars Eggert wrote:
> there is no need to conflate the two functions in one IETF specification.
> 
> The draft should describe how to NAT v6 to v4 in a stateful way. Nothing
> more, nothing less. How to implement firewall functions is orthogonal to
> that.

I don't think we yet know enough about scalability and prefix discovery to
know where NAT64/DNS64 pairs will be deployed topologically, so I think we
genuinely don't know whether there will be security functions in the same box.
Lars is correct.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Oct 2009 17:20:30 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Reinaldo Penno
> Sent: Monday, October 26, 2009 4:45 AM
> To: Iljitsch van Beijnum
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Comments on TCP RST handling in 
> draft-ietf-behave-v6v4-xlate-stateful-02.txt
> 
> 
> 
> 
> raised around NAT64 would still need to be documented 
> somewhere. There is an interesting document about this subject.
> 

Yes, and Fernando has asked for an agenda slot at the upcoming
BEHAVE meeting to present it.

-d

---

From: Dave Thaler <[email-masked]>
Date: Tue, 27 Oct 2009 02:16:04 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Iljitsch van Beijnum
> Sent: Monday, October 26, 2009 4:56 AM
> To: Reinaldo Penno
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Comments on TCP RST handling in draft-ietf-
> behave-v6v4-xlate-stateful-02.txt
> 
> customers. 

Disagree.  The point of NAT64 is to support multiple scenarios, of
which that is one.  For the scenario "IPv6 Internet to an IPv4
network" (which is the scenario Microsoft's "Direct Access" fits into),
the NAT64 would be run by the enterprise, and would likely sit
near the ISP side of the enterprise network so that remote IPv6 
clients that the firewall lets in (which in the Direct Access case
is traffic protected by IPsec) could reach internal IPv4-only
servers with private IPv4 addresses.

-Dave

> But I do know that enterprises are paranoid enough to have

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Oct 2009 12:52:29 +0200

Hi,

> dropping certain packets due to state of translation.

NATs don't "filter". Stateful NATs translate packets for which they  
have binding state, and drop packets for which they have none. That  
they need to drop packets for which they have no binding is a side- 
effect of NAT'ing and not a feature.

Yes, that side effect is similar to the filtering function that  
firewalls perform, and especially stateful firewalls implement similar  
connection state tracking functions than NATs. But although the  
mechanism is similar, the purpose is different.

> perform such functions. Or maybe you are suggesting something  

You're throwing to concepts together that are logically separate. Both  
stateful NATs and stateful firewalls implement connection state  
tracking - but for different purposes. Yes, implementing NAT and  
firewall functions on the same piece of hardware can therefore be  
beneficial, because you can share this mechanism.

Lars

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 27 Oct 2009 11:07:40 -0400

Thank you for your answer Lars, comments inline...

> mechanism is similar, the purpose is different.

In the case of RFC4787, Section 15, "Filtering Behavior", the level of
filtering is a function of how stringent is the NAT security policy. It is a
security choice since there are multiple filtering levels based on a single
outcome (matching a half-state). The discussion on filtering is extensive
and driven solely from the point of security (and application usability).
For example, 

" ....In theory, filtering based on
      both IP address and port is more secure than filtering based only
      on the IP address (because the external endpoint could, in
      reality, be two endpoints behind another NAT, where one of the two
      endpoints is an attacker)."

And this type of behavior is the one I was pointing out.

> You're throwing to concepts together that are logically separate.

I'm actually agreeing they are logically separate and trying to point out
that in order to perform filtering as described in Section 15 of RFC4787 you
need to:

* be the NAT device, or
* have access to the NAT state.

In the latter you can argue that a firewall could do it, but it is driven by
NAT security policy and need to access NAT state, therefore it becomes
somewhat of a 'NAT-Firewall'.

The same is true for any NAT security policy and associated behavior that is
based on NAT state.

Does that make sense?

> Both  

Regards,

Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 27 Oct 2009 16:25:42 +0100

I still think that we should rely on the security guidelines that were 
specified by the behave requirements.
I mean, filtering behaviour that need to be supported are carefully 
defined by the behave requirements, we should simply stick to them

There was consensus on this requirements, i don't see the need to go 
back and open these issues.

Regards, marcelo

---

From: Fernando Gont <[email-masked]>
Date: Wed, 28 Oct 2009 07:23:16 -0200

Lars Eggert wrote:

> We've hit this several times in the past with different BEHAVE document,
> and we've always been very careful to focus on the "translator"
> functions only. (Other WGs have talked about firewall/security
> functions, e.g., V6OPS.)

As part of that translation, you hit security issues whether you like it
or not.

>From the external realm, all connections come from the NAT. Therefore
the NAT should comply to the same type of requirements as and end system
(e.g., in respect of how ISNs are generated, how IP IDs are selected,
etc.) -- if you don't, there's the potential of interoperability
problems *introduced* by the NAT behavior.

Once you realize there's more you should do than translating the
addresses, you probably want to do it security-wise.

Although, the NAT could be subject of DoS attacks similar to those that
can be performed against end-systems (e.g., fragmentation attacks). So
yes, the NAT should do something about it.

P.S.: draft-gont-behace-nat-security discusses some of these issues.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Wed, 28 Oct 2009 07:32:48 -0200

> firing off a bunch of criticisms.

There was a single (real) version of the I-D (-01), which has now been
revised.

Version -01 was presented at MPLS, but my impression was that quite a
few folks were in "reject mode" by default. And didn't consider the
interoperability implications that may arise when you do less than what
you should be doing.

Thanks,

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 28 Oct 2009 12:07:18 +0100

> As part of that translation, you hit security issues whether you  

 From http://tools.ietf.org/html/draft-gont-behave-nat-security-01

    When the target host receives the two unrelated datagrams, carrying
    same fragmentation id, and from the same assigned host address, the
    target host is unable to determine which of the two sessions the
    datagrams belong to and might corrupt both sessions.  This can be a
    security breach any of the sessions associated.

This is not a security issue. This is a correctness issue. Here we  
invoke the words "unreliable datagram service". In other words: life  
is hard, corruption happens, if you don't like it, use better  
checksums at higher layers. Which is of course exactly what protocols  
that promote security such as TLS and IPsec do.

Nothing to see here; please move along.

(I predicted that me reading that draft wouldn't be fun for either of  
us.)

Here's something I especially disagree with:

    NATs should implement an ephemeral port selection algorithm such  
that
    the source port of outgoing packets is obfuscated

This is NOT a NAT's job!

    NATs should rewrite the Sequence Number

This is ridiculous. Tracking sequence numbers increase state in a NAT  
significantly, while the end-to-end argument tells us that if the  
endpoint need to select initial sequence numbers properly anyway,  
there is no point in a middlebox revisiting that decision.

Your unstated assumption is that hosts make the wrong choices and NATs  
should rectify that situation. That is NOT what NATs are for!!! And  
that goes double for NAT64s!