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 protected]] On Behalf Of Smith, Donald
Sent: Monday, March 31, 2014 5:56 PM
To: George, Wes; Qiong; [email protected]
Subject: Re: [OPSEC] comments for firewall draft

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 protected]



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




From: Qiong <[email protected]>




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.
_______________________________________________
OPSEC mailing list
[email protected]
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.
 ----------------------------------------------------------------------

_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec

Reply via email to