Subject: [OPSEC] comments for firewall draft

From: Qiong <[email-masked]>
Date: Mon, 31 Mar 2014 10:30:37 +0800

Hi authors,

I recently read your draft
draft-gont-opsec-ipv6-firewall-reqs-00<http://tools.ietf.org/html/draft-gont-opsec-ipv6-firewall-reqs-00>
.
I think it is quite useful for operators and it is in a good shape. Thanks
for your effort.

Just a quick question: I think NAT is a quite common function in firewall,
is there some reason that it should not be included in IPv6 firewall ?

Best wishes

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institute

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================

---

From: "George, Wes" <[email-masked]>
Date: Mon, 31 Mar 2014 07:34:39 -0400

From: Qiong <[email-masked]<mailto:[email-masked]>>

Just a quick question: I think NAT is a quite common function in firewall, is there some reason that it should not be included in IPv6 firewall ?

WG] Because NAT should not be used unless necessary. NAT is often confused with security (i.e. security by obscurity), but we’re really trying to break that conflation in IPv6 since it is also not necessary for address preservation and really shouldn’t be used for even 1:1 address translation since it is possible to add multiple addresses for hosts, so that they can have addresses for both internal and external scope, rather than the existing private/public NAT that happens in many networks today on IPv4.

So if anything, the document probably needs words to that effect so that it’s explicitly clear that this is a non requirement.

Wes George

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 31 Mar 2014 15:56:19 +0000

Why does everyone believe NAT (NAPT really) is security by obscurity?
For the port translation portion it makes it harder, 64k harder, to find the open ports (ok really less then 32k harder due to the birthday paradox but still).

SRC based NAT meets the intent of bcp38 by preventing src based ip address spoofing. We (collectively)  have millions of broadband customers that can't do src based IP address spoofing due to NAT. 

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

From: OPSEC [[email-masked]] on behalf of George, Wes [[email-masked]]
Sent: Monday, March 31, 2014 5:34 AM
To: Qiong; [email-masked]
Subject: Re: [OPSEC] comments for firewall draft

From: Qiong <[email-masked]>

Wes George

---

From: Marco Ermini <[email-masked]>
Date: Mon, 31 Mar 2014 16:27:22 +0000

Hi,

I think this is a good point, and I personally agree with all of the comments.

NAT is pretty common in firewalls, and things such as NAT64 or NAT46 (or any combination of 4s and 6s...) are pretty commonly used, therefore they should be present, especially in the context of carrier-grade NAT for IPv6 providers.

I'll take some time to talk with the co-authors about this.

Marco Ermini

Senior IT Security and Compliance Analyst
 
ResMed Germany Inc Fraunhofer Str. 16 - 82152 - Martinsried - Germany

ResMed.com

-----Original Message-----
From: OPSEC [mailto:[email-masked]] On Behalf Of Smith, Donald
Sent: Monday, March 31, 2014 5:56 PM
To: George, Wes; Qiong; [email-masked]
Subject: Re: [OPSEC] comments for firewall draft

WG] Because NAT should not be used unless necessary. NAT is often confused with security (i.e. security by obscurity), but we're really trying to break that conflation in IPv6 since it is also not necessary for address preservation and really shouldn't be used for even 1:1 address translation since it is possible to add multiple addresses for hosts, so that they can have addresses for both internal and external scope, rather than the existing private/public NAT that happens in many networks today on IPv4. 

So if anything, the document probably needs words to that effect so that it's explicitly clear that this is a non requirement.

Wes George

Anything below this line has been added by my company's mail server, I have no control over it.
-----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

 ----------------------------------------------------------------------
Warning:  Copyright ResMed.  Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those
materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient.  This communication is confidential and may contain legally privileged information.  By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal privilege in, the content of the email and of any attachments.  If the recipient of this message is not the intended addressee, please call ResMed immediately on  1 (800) 424-0737 USA.
 ----------------------------------------------------------------------

---

From: Simon Perreault <[email-masked]>
Date: Mon, 31 Mar 2014 12:52:42 -0400

Le 2014-03-30 22:30, Qiong a écrit :
> I think NAT is a quite common function in firewall, is there some
> reason that it should not be included in IPv6 firewall ?

Do you have specific things in mind that the draft should say on this topic?

IMHO, the fact that NAT is common in firewall equipment is irrelevant.
Many other functions are common: IPSEC gateway, SSL VPN, IDS, etc. etc.
etc. A draft covering everything would be a huge effort with low chance
of success.

I would prefer this draft to remain focused on the core firewall function.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Marco Ermini <[email-masked]>
Date: Mon, 31 Mar 2014 17:35:40 +0000

-----Original Message-----
From: OPSEC [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Monday, March 31, 2014 6:53 PM
To: [email-masked]
Subject: Re: [OPSEC] comments for firewall draft

> etc. A draft covering everything would be a huge effort with low chance of success.
>

Well, then the argument is: is NAT a central function in a firewall, especially in an IPv6 one?

I do believe NAT is a bit different than the others you mentioned, because in the great majority of circumstances you would really use a firewall to perform NAT.

In all of the other cases you mentioned (VPN, NIDS, etc.) they may be enabled with a license in environments where no better solution is desired, required or could be afforded; but they are really not central to a firewall, and are better performed with a dedicated system.

Mileage may vary with different firewall brands; e.g. with Juniper, SSL VPN is better provided by a dedicated security gateway appliance, while in Cisco or Palo Alto there is more convergence and this function is enabled by license. Anyway, all of them (thinking especially about NIDS/NIPS) are better provided by dedicated appliances and are not really so central for a firewall.

Worth to be noted, in the original RFP document I redacted, there were also all of these functions, but they were removed as it would have been too many things to discuss at once. However, I do think that NAT may have some special merit. Therefore it would be good to collect votes on that. So far I got 3+ and 1- if I am not wrong.

Marco Ermini

---

From: "George, Wes" <[email-masked]>
Date: Mon, 31 Mar 2014 15:16:41 -0400

On 3/31/14, 11:56 AM, "Smith, Donald" <[email-masked]> wrote:

>For the port translation portion it makes it harder, 64k harder, to find
>the open ports (ok really less then 32k harder due to the birthday
>paradox but still).
WG] IMO “harder to attack because harder to find” is pretty much the
definition of security by obscurity. That’s not to say that security by
obscurity adds no value, but I don’t believe that it’s of such high value
that it can’t be replaced with other things. In other words, it’s not an
immutable requirement for proper security.

>SRC based NAT meets the intent of bcp38 by preventing src based ip
>address spoofing. We (collectively)  have millions of broadband customers
>that can't do src based IP address spoofing due to NAT.
WG] That certainly makes sense, but if that were consistently true,
there’d be no reason to implement uRPF on DSLAMs or CMTSs, and we likely
wouldn’t have the problem we have today with spoofed traffic coming from
all over, given the prevalence of NATs in residential and enterprise
networks. I have trouble explaining the existence of the amount of spoofed
traffic that we seem to be fighting with today as originating solely from
devices that are directly connected without any NAT in front of them. I
think the reality is that there are plenty of NAT boxes that will happily
pass all sorts of junk upstream, and MAYBE if they’re smart they’ll only
try to NAT stuff sourced from their internal LAN and simply pass the other
stuff unmolested.

My point is that justifying (or worse, REQUIRING) NAT in a firewall
because it gives you BCP38 or security by obscurity is solving for the
wrong thing and conflating the primary purpose of NAT (address
sharing/rewriting) with some of the arguably helpful side effects of using
it. Preventing spoofed traffic, and providing proper security is a good
goal. There are other ways to get there besides NAT.

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

---

From: Fernando Gont <[email-masked]>
Date: Mon, 31 Mar 2014 17:46:19 -0300

Hi, Qiong,

On 03/30/2014 11:30 PM, Qiong wrote:
> 
> I recently read your draft draft-gont-opsec-ipv6-firewall-reqs-00
> <http://tools.ietf.org/html/draft-gont-opsec-ipv6-firewall-reqs-00> . I
> think it is quite useful for operators and it is in a good shape. Thanks
> for your effort.
> 
> Just a quick question: I think NAT is a quite common function in
> firewall, is there some reason that it should not be included in IPv6
> firewall ?

I'd say that, s far, it has not been included mostly because we have not
yet worked out all requirements and details. That said, I'd bet you'd
find a lot of opposition for such a requirement here at the IETF.

Given that you've already raised the question, I'll essentially read the
wg comments, and reflect the discussion in the next revision of the I-D.

Thanks so much!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 31 Mar 2014 17:53:19 -0300

On 03/31/2014 08:34 AM, George, Wes wrote:
> 
> From: Qiong <[email-masked] <mailto:[email-masked]>>
> 
> 
> WG] Because NAT should not be used unless necessary. NAT is often
> confused with security (i.e. security by obscurity), 

The thing is NAT, directly or indirectly bring:

1) Host/network masquerading

2) Diode-like firewall functionality (only allow communications
initiated from the internal network).

"2" is really a side affect, though.

But the above are certainly interesting from a security pov.

(Note: I'm not endorsing the use of NAT, nor suggesting that we should
include anything about NATs in this I-D... Just trying to add another
perspective).

> but we’re really
> trying to break that conflation in IPv6 since it is also not necessary
> for address preservation and really shouldn’t be used for even 1:1
> address translation since it is possible to add multiple addresses for
> hosts, so that they can have addresses for both internal and external
> scope, rather than the existing private/public NAT that happens in many
> networks today on IPv4. 
> 
> So if anything, the document probably needs words to that effect so that
> it’s explicitly clear that this is a non requirement.

I'll try to craft some text along these lines and post it to the
mailing-list for review...

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 31 Mar 2014 22:30:13 -0300

Hi, Wes,

On 03/31/2014 04:16 PM, George, Wes wrote:
> that it can’t be replaced with other things.

I think that each "mitigation" has it's place. Most of them are
complementary.

> goal. There are other ways to get there besides NAT.

FWIW, I agree with the above. That said, we're specifying requirements
as "required" and "optional", too. So one might least this feature as
optional, without that meaning that supporting some sort of ipv6 nat
functionality is really required.

Against, I'm not yet arguing in favor or against some sort of IPv6 NAT,
but rather trying to foster discussion of this topic.

Thanks!

Cheers,