Subject: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 15 Jun 2016 10:50:29 +0000

The authors (and OPSEC WG chairs) would really appreciate if a review of https://tools.ietf.org/html/draft-ietf-opsec-v6-08 is done in the coming days/weeks (in time to submit a -09 in case it needs to be amended).

This I-D is about the operation security considerations when operating an IPv6 network (both as Service Provider and enterprise/subscriber).

Thanks a lot in advance for your review and be sure to include [email-masked] in your reply.

- the authors (Merike, KK and Eric)
- the chairmen (Gunter and Eric)

PS: Markus, Fred, Fernando and Lee, as you kindly volunteered to review it during IETF-95, I also put your names ;-)

---

From: "Sleigh, Robert" <[email-masked]>
Date: Wed, 15 Jun 2016 11:33:53 +0000

Hi Eric et al.

Great doc, thanks. Just a couple of typos I spotted.

2.1.2

"This means that using ULA does not prevent route and packet filters to be implemented and monitored."

Should this read: 

"This means that using ULA does not prevent route and packet filters having to be implemented and monitored."

2.7.2.8

"the audit log are easier to manager"

Should this read:

"the audit logs are easier to manage"

Hope this helps

Regards

Bob
07958 318592

From: OPSEC [mailto:[email-masked]] On Behalf Of Eric Vyncke (evyncke)
Sent: 15 June 2016 11:50
To: [email-masked]; [email-masked]
Cc: Howard, Lee; [email-masked]; [email-masked]; [email-masked]
Subject: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08

NOTICE AND DISCLAIMER
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. 
If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. 
If you've received this email in error, please let me know immediately on the email address above. Thank you.

We monitor our email system, and may record your emails.

EE Limited 
Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW
Registered in England no: 02382161

EE Limited is a wholly owned subsidiary of:

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

---

From: Markus deBruen <[email-masked]>
Date: Wed, 15 Jun 2016 15:04:54 +0200

Hi Eric, 

the draft is very well written and contains useful guidance/recommendations. Sections 2.4 and 2.5 do not contain much IPv6-specific information and sections 2.7.2.* do not give much guidance. However, these three sections together amount to ~11 pages (1/3 of the document). If you could shorten these sections, the document would become more manageable. 
Some minor comments and nits: 
2.1.2 
"... The latter would be problematic." 
I suspect by "latter" you mean NPTv6. Better make that explicit. 

"A typical argument is that there are too many mistakes made with filters and 
ULAs make things easier to hide machines." 
Why "to hide machienes"? I would suggest "to set filters". 

2.1.4 
"... privacy extension addresses should be used" 
Punctuation mark is missing. 

2.2 
still TBD 

2.3.2 
"... for protecting hosts connected against..." 
"Connected hosts" maybe!? 

2.3.4 
"RFC6980 [RFC6980] aims to update RFC4861 [RFC4861]" 
"[RFC6980] updates [RFC4861]" 

2.7.2 
"embeb" -&gt; embed 

2.7.2.4 
"... operational problems" 
Punctuation mark is missing. 

2.7.2.8 
The second "MAP-E" should be "MAP-T". 

2.8 
"device to authenticated" -&gt; "device authenticated" 

3.1 
"bogon and reserved space" 
Some links might be helpful (e.g. to IANA). 

5 
"[RFC7084] (which obsoletes [RFC6204]" 
Missing ")" 

"[RFC7084] states that a clear choice must be given to the user to select one 
of those two policies." 
Does it? I did not find the corresponding passage. 

Throughout the document there are some "IPV6", "DOS" and " ", which should be 
replaced with "IPv6", "DoS" and " ". 

I hope these comments are helpful. 

Cheers, 
Markus 

---- Ein Mi, 15 Jun 2016 12:50:29 +0200 Eric Vyncke (evyncke)&lt;[email-masked]&gt; hat geschrieben ----

---

From: Erik Kline <[email-masked]>
Date: Wed, 15 Jun 2016 12:45:31 -0700

Section 2.1.2 is far too permissive for my tastes.  We need to be able
to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.

Section 2.6.1.5 could punch up the SAVI stuff a bit more as well.  We
should, in my opinion, make it painfully clear that DHCP (of any
protocol) in the absence of link-layer security/auditability features
does not provide any satisfactory way "to ensure audibility and
traceability" [Section 2.1.6].

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 15 Jun 2016 20:05:13 +0000

One thing I wondered about as reading this - many and perhaps most sections gave a fairly informative comment, and then made one or two recommendations. I wonder (this is a question) whether it would be worthwhile capitalizing "RECOMMEND", both in the sense of defining the term (RFC 2119) and highlighting it in the text. I also wonder if it would make sense to pull together a list of recommendations made in a table somewhere, perhaps in an appendix. I could imagine someone wanting a list of them without wading through the text.

> 1.  Introduction
> 
>    Running an IPv6 network is new for most operators not only because
>    they are not yet used to large scale IPv6 networks but also because
>    there are subtle differences between IPv4 and IPv6 especially with
>    respect to security.  For example, all layer-2 interactions are now
>    done by Neighbor Discovery Protocol [RFC4861] rather than by Address

s/by/using/, twice. As worded, it sounds like NDP and ARP doing this by themselves, as *actors*; no, the *system* does them using NDP and ARP as its *language*.

>    Resolution Protocol [RFC0826].  Also, there are subtle differences
>    between NAT44 and NPTv6 [RFC6296] which are explicitly pointed out in
>    the latter's security considerations section.

For NAT44, I might also point to RFC 2993 and maybe 4864.

>    IPv6 networks are deployed using a variety of techniques, each of
>    which have their own specific security concerns.

> 2.  Generic Security Considerations
> 
> 2.1.  Addressing Architecture
> 
>    IPv6 address allocations and overall architecture are an important
>    part of securing IPv6.  Typically what you initially design for will
>    be what you use for a very long time.

This sentence is in the second person ("you"), and most of the document is third person ("it"). Reword as "Initial designs, even if intended to be temporary, tend to last much longer than expected"?

> Although initially IPv6 was
>    thought to make renumbering easy, in practice, it would be extremely
>    difficult to renumber.

I would temper the statement. As we said in RFC 4192, the problems with renumbering tends to be the places where a number is written into a static configuration rather than managed using a database or whatever, and the places where people cut corners ("its address will never change, so I don't need to worry about its name and DNS"). I would find myself saying that good OSS trumps static configurations, and in IPv6, systems change at least their IIDs from time to time (RFC 7721). It's not that IPv6 (or IPv4) is hard to renumber, it's that the required operational support is often not there or not workable due to poor practice.

>    Once an address allocation has been assigned, there should be some
>    thought given to an overall address allocation plan.  With the
>    abundance of address space available, an address allocation may be
>    structured around services along with geographic locations, which

"topology"? Topology is often structured geographically, yes, but if A provides services to B and C and is a logical gateway to them, A, B, and C can be grouped for management purposes even if they are not in the same geographic location.

>    then can be a basis for more structured security policies to permit
>    or deny services between geographic regions.
> 
>    A common question is whether companies should use PI vs PA space
>    [RFC7381] but from a security perspective there is little difference.

comma after "[RFC7381]".

>    However, one aspect to keep in mind is who has ownership of the
>    address space and who is responsible if/when Law Enforcement may need
>    to enforce restrictions on routability of the space due to malicious
>    criminal activity.

Pregnant statement. I find myself wondering about the implications of "ownership" and "law enforcement restrictions on routability". In "ownership", are you pointing to issues when you change providers and therefore need to change PA addresses? If not, something else? In "LEA issues", are you talking about law enforcement blocking the address space, turning BGP announcements off, etc?

> 2.1.1.  Statically Configured Addresses
> 
>    When considering how to assign statically configured addresses it is
>    necessary to take into consideration the effectiveness of perimeter
>    security in a given environment.  There is a trade-off between ease
>    of operational deployment where some portions of the IPv6 address
>    could be easily recognizable for operational debugging and
>    troubleshooting versus the risk of scanning; [SCANNING] shows that
>    there are scientifically based mechanisms that make scanning for IPv6
>    reachable nodes more realizable than expected.  The use of common
>    multicast groups which are defined for important networked devices
>    and the use of commonly repeated addresses could make it easy to
>    figure out which devices are name servers, routers or other critical
>    devices.
> 
>    While in some environments the perimeter security is so poor that
>    obfuscating addresses is considered a benefit; it is a better
>    practice to ensure that perimeter rules are actively checked and
>    enforced and that statically configured addresses follow some logical
>    allocation scheme for ease of operation.

I find myself on both sides of the prophylactic security discussion. I compare and network and its defenses to the human immune system, and perimeter security to the skin. I favor having a working perimeter security system much like I favor a functional skin, and for the same immunologic reasons. That said, the body provides the defense, reducing the rate at which it needs to bring other systems into play, and then assumes it has been breached; a person whose only immunologic defense is their skin is an AIDS patient, and doesn't have a good prognosis. My fundamental problem with most network security systems is that they over-emphasize perimeter security.

I say that because this paragraph seems to over-emphasize perimeter security - "in some environments the perimeter security is so poor...". I think I would say that "security is so poor". I would be tempted to go beyond to talk about the ways a remote network can be mapped, such as by observing email envelopes and addresses found in WWW logs etc, and the value of temporary random addresses (as opposed to permanent addresses, whether DHCP -assigned or MAC/SLAAC).

But I agree with the recommendation.

> 2.1.2.  Use of ULAs
> 
>    ULAs are intended for scenarios where IP addresses will not have
>    global scope.  The implicit expectation from the RFC is that all ULAs
>    will be randomly created as /48s.  Any use of ULAs that are not
>    created as a /48 violates RFC4193 [RFC4193].

Mention also that they are expected to not be announced, and if announced not accepted, in BGP?

>    ULAs could be useful for infrastructure hiding as described in
>    RFC4864 [RFC4864];

I believe that at least one cable operator uses them for cable modem addresses, which need no GUA and want to be hidden. Personally, I think that's a better use of a ULA - for something does doesn't actually need a global address. The paragraph here seems to assume that the only valid use of a ULA is as a counterpart to RFC 1918, and with NAT.

I'd really wish that we could talk about infrastructure (count the addresses in the envelope of this email; they are mostly infrastructure addresses) and internal-only services (wwwin-SERVICE.cisco.com names being a classic Cisco example, to my mind) when we start a paragraph with a comment on "infrastructure hiding", rather than proceeding directly to NAT.

> 2.1.4.  Temporary Addresses - Privacy Extensions for SLAAC
> ...
>    As privacy extension addresses could also be used to obfuscate some
>    malevolent activities (whether on purpose or not), it is advised in
>    scenarios where user attribution is important to disable SLAAC and
>    rely only on DHCPv6.  However, in scenarios where anonymity is a
>    strong desire since protecting user privacy is more important than
>    user attribution, privacy extension addresses should be used

No mention of IEEE 802.1X?

>    Using privacy extension addresses prevents the operator from building
>    a priori host specific access control lists (ACLs).  It must be noted
>    that recent versions of Windows do not use the MAC address anymore to
>    build the stable address but use a mechanism similar to the one
>    described in [RFC7217], this also means that such an ACL cannot be
>    configured based solely on the MAC address of the nodes, diminishing
>    the value of such ACL.  On the other hand, different VLANs are often
>    used to segregate users, then ACL can rely on a /64 prefix per VLAN
>    rather than a per host ACL entry.

"then ACL"? Either I don't understand the sentence, or you meant "the".

> 2.1.6.  DHCP/DNS Considerations
> 
>    Many environments use DHCPv6 to allocate addresses to ensure
>    audibility and traceability (but see Section 2.6.1.5).  A main

audit-ability

>    security concern is the ability to detect and mitigate against rogue
>    DHCP servers (Section 2.3.2).

I think you want to say "counteract" rather than "mitigate against".

> 2.3.5.  3GPP Link-Layer Security
> 
>    The 3GPP link is a point-to-point like link that has no link-layer
>    address.  This implies there can only be an end host (the mobile
>    hand-set) and the first-hop router (i.e., a GPRS Gatewat Support Node

Gateway

> 2.4.  Control Plane Security
> 
>    RFC6192 [RFC6192] defines the router control plane and this
>    definition is repeated here for the reader's convenience.

Run-on sentence. Replace "and" with a period and capitalize the next word.

>    Modern router architecture design maintains a strict separation of
>    forwarding and router control plane hardware and software.  The
>    router control plane supports routing and management functions.  It
>    is generally described as the router architecture hardware and
>    software components for handling packets destined to the device
>    itself as well as building and sending packets originated locally on
>    the device.

I'm having trouble parsing the above sentence...

> The forwarding plane is typically described as the
>    router architecture hardware and software components responsible for
> 
> 
> 
> Chittimaneni, et al.   Expires September 22, 2016              [Page 11]
> Internet-Draft                 OPsec IPV6                     March 2016
> 
> 
>    receiving a packet on an incoming interface, performing a lookup to
>    identify the packet's IP next hop and determine the best outgoing
>    interface towards the destination, and forwarding the packet out
>    through the appropriate outgoing interface.

I'm having trouble parsing the above as well. I'd suggest breaking it into 2-3 sentences.

> 2.4.3.  Packet Exceptions
> 
>    This class covers multiple cases where a data plane packet is punted
>    to the route processor because it requires specific processing:
> ...
>    o  processing of the hop-by-hop extension header;

May I suggest the authors comment on draft-ietf-6man-hbh-header-handling as it progresses? Let's not let that and this conflict.

> 2.6.1.1.  Logs of Applications
> ...
>    #!/usr/bin/perl ?w

Should that be "-w"?

>    use strict ;
>    use warnings ;
>    use Socket ;
>    use Socket6 ;
> 
>    my (@words, $word, $binary_address) ;
> 
>    ## go through the file one line at a time
>    while (my $line = <STDIN>) {
>      chomp $line;
>      foreach my $word (split /[ \n]/, $line) {

replace "[ \n]" with "\s+". \s includes any white space character, including a space, a tab, \n, \r, and a couple of others. The "+" specifies strings of one or more in length.

>        $binary_address = inet_pton AF_INET6, $word ;
>        if ($binary_address) {
>          print inet_ntop AF_INET6, $binary_address ;
>        } else {
>          print $word ;
>        }
>        print " " ;
>      }
>      print "\n" ;
>    }

> 2.7.1.  Dual Stack
> 
>    Dual stack has established itself as the preferred deployment choice
>    for most network operators without a MPLS core where 6PE RFC4798

without *an* MPLS core...

> 2.7.3.2.  NAT64/DNS64
> 
>    Stateful NAT64 translation [RFC6146] allows IPv6-only clients to
>    contact IPv4 servers using unicast UDP, TCP, or ICMP.  It can be used
>    in conjunction with DNS64 [RFC6147], a mechanism which synthesizes
>    AAAA records from existing A records.
> 
>    The Security Consideration sections of [RFC6146] and [RFC6147] list
>    the comprehensive issues.  A specific issue with the use of NAT64 is
>    that it will interfere with most IPsec deployments unless UDP
>    encapsulation is used.  DNS64 has an incidence on DNSSEC see section
>    3.1 of [RFC7050].

You might want to mention 6145, draft-bao-v6ops-rfc6145bis, and SIIT-DC.

> 3.1.  External Security Considerations:

You mention having a firewall that only permits inbound traffic that corresponds to an active session. Would RFC 6092 be worth mentioning in that context?

> 5.  Residential Users Security Considerations

Would RFC 6092 be worth mentioning in this context?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jun 2016 11:44:45 +1200

> to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.

I have strong sympathy with that statement, but I don't think this is
the document to do it; the point is made in RFC4864 too. What we should
do here is underline that NAT != security.

While I'm here, some other points:

"2.2.  Extension Headers

   TBD, a short section referring to all Fernando's I-D & RFC."

That's not the whole story ;-). Firstly, RFC 7045 has a lot of
relevance to security aspects. Second, there is no reason to refer
to most of the material (Fernando's or not) unless it's directly relevant
to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering,
but only if that document is going anywhere.

"2.3.3.  ND/RA Rate Limiting
...
   The following drafts are actively discussing methods to
   rate limit RAs and other ND messages on wifi networks in order to
   address this issue:

   o  [I-D.thubert-savi-ra-throttler]

   o  [I-D.chakrabarti-nordmark-6man-efficient-nd]"

Neither of those drafts is in the least active (from 2012 and 2015
respectively). Dead drafts are of no help to the reader, IMHO.

"4.2.  Transition Mechanism

   SP will typically use transition mechanisms such as 6rd, 6PE, MAP,
   DS-Lite which have been analyzed in the transition Section 2.7.2
   section."

Shouldn't you add RFC6877 464XLAT now?

Finally, I think there should be a Privacy Considerations section.

Rgds
    Brian

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

---

From: Marco Ermini <[email-masked]>
Date: Thu, 16 Jun 2016 09:15:17 +0000

Well, actually, infrastructure hiding IS part of security.  It is not the full picture, but it is incorrect to say that it is not.

I personally don't sympathize on NAT-haters.  NAT has its reasons, especially for carrier-grade NAT and especially in the telco scenario, and yes, it does provide some level of security - again, not the complete picture, but it does.

Regards,
 
Marco Ermini

CISSP, CISA, CISM, CEH, ITIL, MCP, PhD
Senior IT Security Analyst
D +49 (0)899 901 1523  M +49 (0)175 439 5642

ResMed Germany Inc

-----Original Message-----
From: OPSEC [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, June 16, 2016 1:45 AM
To: Erik Kline; Eric Vyncke (evyncke)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08

> to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.

I have strong sympathy with that statement, but I don't think this is the document to do it; the point is made in RFC4864 too. What we should do here is underline that NAT != security.

"2.2.  Extension Headers

That's not the whole story ;-). Firstly, RFC 7045 has a lot of relevance to security aspects. Second, there is no reason to refer to most of the material (Fernando's or not) unless it's directly relevant to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering,
but only if that document is going anywhere.

Neither of those drafts is in the least active (from 2012 and 2015 respectively). Dead drafts are of no help to the reader, IMHO.

Rgds
    Brian

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

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Jun 2016 19:43:09 +1000

On 16 June 2016 at 19:15, Marco Ermini <[email-masked]> wrote:
> I personally don't sympathize on NAT-haters.  NAT has its reasons, especially for carrier-grade NAT

CGN isn't necessary in IPv6, it's to solve the problem of ISPs running
out of IPv4 addresses.

 and especially in the telco scenario, and yes, it does provide some
level of security - again, not the complete picture, but it does.

NAT is not necessary in IPv6. The equivalent of NAT's perceived
security can be provided via alternative methods, as described in
RFC4864.

A further technique to hide topology that isn't mentioned in RFC4864
is to use something like ISATAP or similar, to create a single /64
subnet over the top of multiple IPv4 subnets. Externally, all hosts
will appear to belong to a single IPv6 subnet, hiding the internal
topology.

If you truly want to hide the identities of hosts, NAT doesn't do
enough - it is only translating addresses, where as there are many
other host identifiers that the host itself supplies or will receive
and supply that can identify hosts e.g. HTTP cookies. "A Technique for
Counting NATted Hosts"
(https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field
within the IPv4 header that leaked across a NAT was able to be used to
identify hosts.

If you truly want to hide a host from the Internet, yet still allow it
to access things on the Internet, under IPv6 your network would use
ULA addressing, and have a per-application protocol proxy server that
makes all requests look like they've entirely originated from the
application proxy server itself. To the Internet server, the
application proxy server would appear to be the application end host
making the requests, preventing any internal host identifiers or other
attributes from leaking.

Regards,
Mark.

---

From: Marco Ermini <[email-masked]>
Date: Thu, 16 Jun 2016 10:03:25 +0000

Hi,

NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the CGN equipment can't handle them differently.  Unfortunately RFC 4864 does not mention such case, AFAIK.

In any case, I am happy to concede it could be an extreme case and that it is not necessary anymore in IPv6 for the great majority of use cases.

I was not really making a specific case for IPv6 - my opposition was to the concept that NAT is not security, and to the fact that it should be written as such in the RFC.  NAT *does* provide a form of security - the fact that it is not desirable or it is unnecessary to use is another topic, in which I believe we all agree (at least for 99% of use cases ;-))

Regards,
 
Marco Ermini

ResMed Germany Inc

-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Thursday, June 16, 2016 11:43 AM
To: Marco Ermini
Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08

> especially for carrier-grade NAT

CGN isn't necessary in IPv6, it's to solve the problem of ISPs running out of IPv4 addresses.

 and especially in the telco scenario, and yes, it does provide some level of security - again, not the complete picture, but it does.

NAT is not necessary in IPv6. The equivalent of NAT's perceived security can be provided via alternative methods, as described in RFC4864.

A further technique to hide topology that isn't mentioned in RFC4864 is to use something like ISATAP or similar, to create a single /64 subnet over the top of multiple IPv4 subnets. Externally, all hosts will appear to belong to a single IPv6 subnet, hiding the internal topology.

If you truly want to hide the identities of hosts, NAT doesn't do enough - it is only translating addresses, where as there are many other host identifiers that the host itself supplies or will receive and supply that can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted Hosts"
(https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within the IPv4 header that leaked across a NAT was able to be used to identify hosts.

If you truly want to hide a host from the Internet, yet still allow it to access things on the Internet, under IPv6 your network would use ULA addressing, and have a per-application protocol proxy server that makes all requests look like they've entirely originated from the application proxy server itself. To the Internet server, the application proxy server would appear to be the application end host making the requests, preventing any internal host identifiers or other attributes from leaking.

Regards,
Mark.

>
> Regards,
>
> Marco Ermini
>
> CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D 
> +49 (0)899 901 1523  M +49 (0)175 439 5642
>
> ResMed Germany Inc
>
>
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
>> Section 2.1.2 is far too permissive for my tastes.  We need to be 
>> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.
>
> relevance to security aspects. Second, there is no reason to refer to 
> most of the material (Fernando's or not) unless it's directly relevant

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Jun 2016 22:17:13 +1000

On 16 Jun 2016 20:03, "Marco Ermini" <[email-masked]> wrote:
>
> Hi,
>
> NAT can be still necessary in IPv6 in dual-stack scenario, for instance,
where every host is assigned both a IPv4 and IPv6 addresses and the CGN
equipment can't handle them differently.

Can you provide an example of this sort of CGN device.

IPv4 and IPv6 have to be handled differently because they're different
protocols, requiring different code. A single device might be performing
NAT on IPv4 traffic it receives and doing standard stateless forwarding of
IPv6 traffic. Is that the scenario you're describing?

I'd struggle to believe that there are CGN devices where performing NAT on
IPv6 traffic is mandatory if IPv4 NAT is being performed.

Unfortunately RFC 4864 does not mention such case, AFAIK.
>
> In any case, I am happy to concede it could be an extreme case and that
it is not necessary anymore in IPv6 for the great majority of use cases.
>
> I was not really making a specific case for IPv6 - my opposition was to
the concept that NAT is not security, and to the fact that it should be
written as such in the RFC.

So this draft is purely about IPv6. There will be a lot of IPv4 security
measures that can be applied to IPv6, however there will also be others
that shouldn't, and opportunities where IPv6 can provide better security
that IPv4 (e.g. sparse host addressing in a /64 makes address probing to
discover hosts impossible within a useful and practical timeframe.).

 > NAT *does* provide a form of security

What specific security does it provide that is due to the address
translation function?

If you're thinking about the protection provided due to the state being
created during the address translation process, that state can be created
without performing address translation, which is what a stateful firewall
does and did in IPv4 before NAT became widely deployed.

> - the fact that it is not desirable or it is unnecessary to use is
another topic, in which I believe we all agree (at least for 99% of use
cases ;-))

I don't see a need to deploy NAT with IPv6 as what has been achieved with
IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT.

Regards,
Mark.

> Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke);
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
> > Well, actually, infrastructure hiding IS part of security.  It is not
the full picture, but it is incorrect to say that it is not.
out of IPv4 addresses.
> >
>
> NAT is not necessary in IPv6. The equivalent of NAT's perceived security
can be provided via alternative methods, as described in RFC4864.
>
> A further technique to hide topology that isn't mentioned in RFC4864 is
to use something like ISATAP or similar, to create a single /64 subnet over
the top of multiple IPv4 subnets. Externally, all hosts will appear to
belong to a single IPv6 subnet, hiding the internal topology.
>
> If you truly want to hide the identities of hosts, NAT doesn't do enough
- it is only translating addresses, where as there are many other host
identifiers that the host itself supplies or will receive and supply that
can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted
Hosts"
>
> If you truly want to hide a host from the Internet, yet still allow it to
access things on the Internet, under IPv6 your network would use ULA
addressing, and have a per-application protocol proxy server that makes all
requests look like they've entirely originated from the application proxy
server itself. To the Internet server, the application proxy server would
appear to be the application end host making the requests, preventing any
internal host identifiers or other attributes from leaking.
> > I have strong sympathy with that statement, but I don't think this is
the document to do it; the point is made in RFC4864 too. What we should do
here is underline that NAT != security.

---

From: Marco Ermini <[email-masked]>
Date: Thu, 16 Jun 2016 14:15:05 +0000

I'll try the horrible Outlook to reply using text, please beg my pardon if this is not formatted properly.

On Thursday, June 16, 2016 2:17 PM, Mark Smith [mailto:[email-masked]] wrote:
>> Hi,
>>
>> NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the
>> CGN equipment can't handle them differently. 

I would prefer not to make names, but you would be unpleasantly surprised.  Anyway, it is also not just a matter of not being able to configure them in a certain way (which is possibly the case), but also the case in which they don't work properly.

> IPv4 and IPv6 have to be handled differently because they're different protocols, requiring different code. A single device might be
> performing NAT on IPv4 traffic it receives and doing standard stateless forwarding of IPv6 traffic. Is that the scenario you're describing?

Yes, for instance.  Or, they handle certain functions (e.g. NAT) purely in the data plane as they are logically simple to be implemented in firmware, while more complex functions (like implementing ULA addresses translation) requires routine engines to be involved, therefore involving different latency for execution.

It is pretty common that customers with ISPs offering dual stack, to experience a higher latency for their connection once they implement IPv6 along with IPv4.   This does not apply when only IPv4 or only IPv6 are used.

Another requirement is that a specific logging or monitoring system is implemented (especially for legal requirements), and this is done through logging NAT translations.  An ISP implementing IPv6 along with IPv4 would be in that situation.

Luckily, router vendors are moving away from the antiquate architecture which separates data and management plane, for various reasons.

This is also why we published draft-gont-opsec-ipv6-firewall-reqs-03.txt, to make it explicit that this should not happen.

(I am aware this is off-topic, just making my point :-))

> In any case, I am happy to concede it could be an extreme case and that it is not necessary anymore in IPv6 for the great majority of use

Okay

>> I was not really making a specific case for IPv6 - my opposition was to the concept that NAT is not security, and to the fact that it should be
> So this draft is purely about IPv6. There will be a lot of IPv4 security measures that can be applied to IPv6, however there will also be others
> that shouldn't, and opportunities where IPv6 can provide better security that IPv4 (e.g. sparse host addressing in a /64 makes address probing
> to discover hosts impossible within a useful and practical timeframe.).

Okay, I have nothing to object on this.

>What specific security does it provide that is due to the address translation function?
> If you're thinking about the protection provided due to the state being created during the address translation process, that state can be
> created without performing address translation, which is what a stateful firewall does and did in IPv4 before NAT became widely deployed.

I totally agree with you.  I am actually referring to the possibility to hide the systems behind the NATted interfaces of the router/firewall, not just their addresses but also ports and services.  If you only apply filtering, you are protecting - but not hiding.

In a perfect world, you have such good filters that you can transparently provide the real addresses and ports from clients to the rest of the Internet - however we don't live in such world, therefore hiding provides an additional layer of protection in the "defence in depth" approach.

The fact that this "hiding" actually hinders the deployment of many services and makes life worse to engineers in many cases, is another topic on which we agree totally :-)

There are also cases where NAT offers better (or at least simpler) protection than filters.  For instance, there are known "overbilling attacks" performed in telco networks, where mobile terminals are sent with UDP packets to keep them alive even if would actually disconnect, causing them to be excessively billed.  Filters for those situations tend to be complicated and need to understand the Layer-7 protocol running over UDP to protect the terminals; NAT offers a straightforward protection, instead.

PS. I am aware that major firewall vendors implement filters against overbilling attacks; I was only making an objection to the semantic of the sentence: NAT *provides* security, saying the contrary is not correct.  Whether this could be achieved in some other ways is another matter.

>> - the fact that it is not desirable or it is unnecessary to use is another topic, in which I believe we all agree (at least for 99% of use cases ;-))
>
> I don't see a need to deploy NAT with IPv6 as what has been achieved with IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT.

I mean the same as you do, I would just phrase it as "the poor ISPs which still do that, should consider migrating their architecture to better options".

Regards,
Marco

---

From: Mark Smith <[email-masked]>
Date: Fri, 17 Jun 2016 10:21:27 +1000

On 17 Jun 2016 00:15, "Marco Ermini" <[email-masked]> wrote:
> >> NAT can be still necessary in IPv6 in dual-stack scenario, for
instance, where every host is assigned both a IPv4 and IPv6 addresses and
the
> I would prefer not to make names, but you would be unpleasantly surprised.

I'm sceptical, I and I think others would want a concrete example.

If people aren't implementing specifications well, we need to know, so that
if necessary the specifications can be improved.

  Anyway, it is also not just a matter of not being able to configure them
in a certain way (which is possibly the case), but also the case in which
they don't work properly.
> > IPv4 and IPv6 have to be handled differently because they're different
protocols, requiring different code. A single device might be
> > performing NAT on IPv4 traffic it receives and doing standard stateless
forwarding of IPv6 traffic. Is that the scenario you're describing?
> Yes, for instance.

OK, so "CGN" is not being performed on IPv6 traffic.

>Or, they handle certain functions (e.g. NAT) purely in the data plane as
they are logically simple to be implemented in firmware, while more complex
functions (like implementing ULA addresses translation) requires routine
engines to be involved, therefore involving different latency for execution.

So this sounds like equipment here additional features cannot be
implemented in hardware, so it is implemented in control plane software.

This is an example of why not to use NAT. It is technically very complex
compared to pure IPv4 and pure IPv6 forwarding.

I'm starting to wonder if people think that if they want to use ULAs for
some reason, they think they then must NAT them. If they do, I think that
might show a misunderstanding of something fundamental about IPv6 - a host
natively supports multiple concurrent addresses with different scopes, and
tries to choose one of its source address to match the destination address.

> It is pretty common that customers with ISPs offering dual stack, to
experience a higher latency for their connection once they implement IPv6
along with IPv4.   This does not apply when only IPv4 or only IPv6 are used.

I'd like some examples of this.

I've been natively dual stacked at home for the past near 5 years. I have
not experienced additional and noticeable higher latency for anything I do.
It just works, and I can't tell what is going over IPv4 or IPv6 - and I
know that most if not all Google, Facebook and Netflix traffic can and does
come over IPv6.

I also worked in the residential deployment of IPv6 at the other end of my
connection in 2009/2010, and we never received any IPv6 latency complaints.
In 2012 it was enabled by default for new customer connections.

I have come across presentations over the past years that have shown that
IPv6 has reduced latency for dual stack services, because the IPv6 path was
different and simpler than the IPv4 path.

> Another requirement is that a specific logging or monitoring system is
implemented (especially for legal requirements), and this is done through
logging NAT translations.  An ISP implementing IPv6 along with IPv4 would
be in that situation.

No need to do _address translation_ to be able to perform that.

> Luckily, router vendors are moving away from the antiquate architecture
which separates data and management plane, for various reasons.

Actually, that's going to increase the cost of equipment, because it isn't
going to be cheap to do something complex fast.

> This is also why we published draft-gont-opsec-ipv6-firewall-reqs-03.txt,
to make it explicit that this should not happen.
> > In any case, I am happy to concede it could be an extreme case and that
it is not necessary anymore in IPv6 for the great majority of use
> > cases.
>
> Okay
>
> >> I was not really making a specific case for IPv6 - my opposition was
to the concept that NAT is not security, and to the fact that it should be
> > So this draft is purely about IPv6. There will be a lot of IPv4
security measures that can be applied to IPv6, however there will also be
others
> > that shouldn't, and opportunities where IPv6 can provide better
security that IPv4 (e.g. sparse host addressing in a /64 makes address
probing
translation function?
> > If you're thinking about the protection provided due to the state being
created during the address translation process, that state can be
> > created without performing address translation, which is what a
stateful firewall does and did in IPv4 before NAT became widely deployed.
>
> I totally agree with you.  I am actually referring to the possibility to
hide the systems behind the NATted interfaces of the router/firewall, not
just their addresses but also ports and services.  If you only apply
filtering, you are protecting - but not hiding.

NAT is no where near as effective at hiding systems as people think. Too
many attributes of the system behind the NAT leak across NAT, or can be
forced to leak across the NAT.

It is quite a porous barrier, because NAT is not actually designed to hide
systems. Address translation inherently hides some of the attributes of the
systems (addresses) but not all of them.

> In a perfect world, you have such good filters that you can transparently
provide the real addresses and ports from clients to the rest of the
Internet

It's sounding like you're not up to date with IPv6 firewalling capabilities
in devices, and therefore might be assuming that none exist.

Are you aware for example that Windows has had a stateful IPv6 firewall,
enabled by default, since Windows XP service pack 2, released more than a
decade ago?

I've been using IPv6 under Linux to access the Internet either via tunnels
or natively for more than a decade, using the stateful IPv6 firewall that
has been part of the Linux kernel for at least that long.

This Android phone has native and public IPv6 addresses and is not behind
any sort of IPv6 NAT. It's behind a device that can perform IPv6 stateful
firewalling, however I think I've turned it off, because I trust that as
Google can't trust there is a network firewall upstream of my phone, they
ensure my phone is "Internet proof".

The "perfect" world you're referring to is and has been reality for a long
time for a lot of people.

>- however we don't live in such world, therefore hiding provides an
additional layer of protection in the "defence in depth" approach.
>
> The fact that this "hiding" actually hinders the deployment of many
services and makes life worse to engineers in many cases, is another topic
on which we agree totally :-)
>
> There are also cases where NAT offers better (or at least simpler)
protection than filters.  For instance, there are known "overbilling
attacks" performed in telco networks, where mobile terminals are sent with
UDP packets to keep them alive even if would actually disconnect, causing
them to be excessively billed.  Filters for those situations tend to be
complicated and need to understand the Layer-7 protocol running over UDP to
protect the terminals; NAT offers a straightforward protection, instead.

There is no need to perform _address translation_ to perform this
protection.

Continuing to say NAT in these examples is a bit like saying "I need my
toolbox to bang in nails". You need your toolbox because that is where your
hammer is, however it is actually your hammer that you use to bang in nails.

NAT is address translation + stateful filtering inherent in the operation
of address translation. People who object to NAT in IPv6 are objecting to
the implied assertion that it is necessary to perform address translation
to achieve stateful filtering.

People who advocate NAT for IPv6 for security purposes don't seem to
understand that address translation is *not* required to be able to perform
stateful filtering - or they're using the term "NAT" when they should
really be using the term "stateful filtering".

> PS. I am aware that major firewall vendors implement filters against
overbilling attacks; I was only making an objection to the semantic of the
sentence: NAT *provides* security, saying the contrary is not correct.

"Security against what" is the key question. You can't actually say NAT
provides security without defining the threat or context. If you don't
define the threat, the implication of such a statement is that it provides
security against literally every threat.

If a bank implements NAT on their data network, are they now secured
against bank robbers coming into a branch with guns? Obviously not.

"NAT *provides* security" is going to be wrong in many cases because NAT is
an entirely ineffective measure for a large set of threats.

> Whether this could be achieved in some other ways is another matter.
>

It is the *exact* matter here.

NAT is being asserted as the security measure that should by used in IPv6,
because it has been used in IPv4 (and not necessarily exclusively because
of security - lack of IPv4 addresses is another reason), without any
consideration of its drawbacks or alternatives that don't have those
drawbacks e.g. those described in RFC4864.

> >
> > I don't see a need to deploy NAT with IPv6 as what has been achieved
with IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT.
>
> I mean the same as you do, I would just phrase it as "the poor ISPs which
still do that, should consider migrating their architecture to better
options".

The cost of CGN capacity to NAT video traffic volumes from popular video
sites is likely going to make deploying native IPv6 a cheaper alternative
very quickly.

Regards,
Mark.

out of IPv4 addresses.
> > NAT is not necessary in IPv6. The equivalent of NAT's perceived
security can be provided via alternative methods, as described in RFC4864.
> > If you truly want to hide the identities of hosts, NAT doesn't do
enough - it is only translating addresses, where as there are many other
host identifiers that the host itself supplies or will receive and supply
that can identify hosts e.g. HTTP cookies. "A Technique for Counting NATted
Hosts"
> > If you truly want to hide a host from the Internet, yet still allow it
to access things on the Internet, under IPv6 your network would use ULA

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jun 2016 13:39:30 +1200

> Well, actually, infrastructure hiding IS part of security.  It is not the full picture, but it is incorrect to say that it is not.

Have you read RFC4864 recently? Section 4.4 is all about how you don't need
NAT to hide infrastructure topology in IPv6.

> I personally don't sympathize on NAT-haters.  NAT has its reasons, especially for carrier-grade NAT and especially in the telco scenario, and yes, it does provide some level of security - again, no…

That's IPv4. This is IPv6.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jun 2016 13:46:20 +1200

In addition to what Mark said about this:

> NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the CGN equipment can't handle them differently.  Unfortunat…

CGN and IPv6 are completely orthogonal, even in a dual stack scenario.
v4 packets go to the CGN function and v6 packets go to the v6 router
function, possibly in the same box. So absolutely the equipment handles
them differently. (If there are sick products that get this wrong, that
is not really the IETF's business. Although it's a bit out of date in
seome aspects,  RFC 6264, An Incremental Carrier-Grade NAT (CGN) for IPv6
Transition, explains how to do it correctly.)

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Jun 2016 19:11:50 -0700

> to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.

+1. I recall long queues at the mike at IETF 94 saying that.

> traceability" [Section 2.1.6].

+1. Instead of the text you have here, I would suggest citing section 9.1
of draft-ietf-v6ops-host-addr-availability, which deals with the problem in
detail.

---

From: Marco Ermini <[email-masked]>
Date: Fri, 17 Jun 2016 11:29:05 +0000

I am sorry Brian, I don't think you understood my argument.  I am not arguing about you mention.  I am arguing against the semantic of a phrase that says "NAT does not provide security".  This sentence is semantically wrong, and usually comes from a priori NAT-haters (I have met a few).

I am only against stating such sentence in the RFC, not against the fact that we don't need NAT.  I hope this is clearer now.

Anyway, I have made my point sufficiently, I believe.

Regards,
Marco.

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Friday, June 17, 2016 3:40 AM
To: Marco Ermini; Erik Kline; Eric Vyncke (evyncke)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08

> Well, actually, infrastructure hiding IS part of security.  It is not the full picture, but it is incorrect to say that it is not.

Have you read RFC4864 recently? Section 4.4 is all about how you don't need NAT to hide infrastructure topology in IPv6.

    Brian

---

From: Gert Doering <[email-masked]>
Date: Fri, 17 Jun 2016 13:47:32 +0200

Hi,

> NAT can be still necessary in IPv6 in dual-stack scenario, for instance, where every host is assigned both a IPv4 and IPv6 addresses and the CGN equipment can't handle them differently.  Unfortunat…

Why would anyone route their IPv6 traffic to the IPv4 CGN box?

CGN boxes are way expensive, so anyone with a calculator would route
everything that does not need NAT around the CGN box.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Marco Ermini <[email-masked]>
Date: Fri, 17 Jun 2016 13:12:09 +0000

I am sorry, I surrender the Outlook on the third indent

From: Mark Smith [mailto:[email-masked]]
Sent: Friday, June 17, 2016 2:21 AM
To: Marco Ermini
Cc: Eric Vyncke (evyncke); [email-masked]; Erik Kline; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Brian E Carpenter
Subject: RE: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08

On 17 Jun 2016 00:15, "Marco Ermini" <[email-masked]<mailto:[email-masked]>> wrote:
> On Thursday, June 16, 2016 2:17 PM, Mark Smith [mailto:[email-masked]<mailto:[email-masked]>] wrote:
> >> Hi,
> >>

[Marco Ermini]

I am sorry, I am not authorised to do that publically.  But this is not necessary anyway.  There is no need to list everything that works wrong, to define what the correct behaviour should be.

If people aren't implementing specifications well, we need to know, so that if necessary the specifications can be improved.

[Marco Ermini]

This is why we have draft-gont-opsec-ipv6-firewall-reqs-03.txt.

  Anyway, it is also not just a matter of not being able to configure them in a certain way (which is possibly the case), but also the case in which they don't work properly.

[Marco Ermini]

Sort of CG equipment will be anyway in the way also for dual-stack residential connections, and CGN is still used on pure IPv6 implementations as you need to offer connectivity to IPv4-only hosts.

>Or, they handle certain functions (e.g. NAT) purely in the data plane as they are logically simple to be implemented in firmware, while more complex functions (like implementing ULA addresses translation) requires routine engines to be involved, therefore involving different latency for execution.
>

So this sounds like equipment here additional features cannot be implemented in hardware, so it is implemented in control plane software.

This is an example of why not to use NAT. It is technically very complex compared to pure IPv4 and pure IPv6 forwarding.

[Marco Ermini]

I do agree with you.

I'm starting to wonder if people think that if they want to use ULAs for some reason, they think they then must NAT them. If they do, I think that might show a misunderstanding of something fundamental about IPv6 - a host natively supports multiple concurrent addresses with different scopes, and tries to choose one of its source address to match the destination address.

[Marco Ermini]

I can really see your point here.  It may well be that “people” can misunderstand IPv6.  Despite its existence since a decade, it is not widely adopted outside of certain Asian countries.

I've been natively dual stacked at home for the past near 5 years. I have not experienced additional and noticeable higher latency for anything I do. It just works, and I can't tell what is going over IPv4 or IPv6 - and I know that most if not all Google, Facebook and Netflix traffic can and does come over IPv6.

[Marco Ermini]

You are lucky.  Again, I cannot make names, but you are my guest if you come near Munich sometimes, and I’ll show you the typical European dual stack implementation. ☹

I also worked in the residential deployment of IPv6 at the other end of my connection in 2009/2010, and we never received any IPv6 latency complaints. In 2012 it was enabled by default for new customer connections.

[Marco Ermini]

There are ISPs in Germany which offer by default IPv6, and requires to pay additional fees if you want IPv4 (which is sometimes necessary if your company only implements IPv4 and you need to VPN in, as CGN from IPv6 to IPv4 breaks most VPN platforms).

However, the European operators offering dual stack all suffers from latency issues.  It can also be partially due to the client operative system and how it detects which is the best path to use for hosts that offer both connectivity.

I have come across presentations over the past years that have shown that IPv6 has reduced latency for dual stack services, because the IPv6 path was different and simpler than the IPv4 path.

[Marco Ermini]

Again, that is in the ideal world, but it is not my experience with different European residential service providers.

IPv6 should have been the ultimate solution to many issues, but apparently it has not been that silver bullet that everyone was hoping for.

[Marco Ermini]

Of course, if you have the possibility, you can always do things differently and better.

> Luckily, router vendors are moving away from the antiquate architecture which separates data and management plane, for various reasons.

Actually, that's going to increase the cost of equipment, because it isn't going to be cheap to do something complex fast.

[Marco Ermini]

Au contraire, for equipment vendors, moving from having hardware and different planes to manage, to a software-only version which can be shipped as both hardware and virtual image, means notable reduction of costs in terms of development, support, etc.

But of course I concede there may be differences case by case.

> I totally agree with you.  I am actually referring to the possibility to hide the systems behind the NATted interfaces of the router/firewall, not just their addresses but also ports and services.…

NAT is no where near as effective at hiding systems as people think. Too many attributes of the system behind the NAT leak across NAT, or can be forced to leak across the NAT.

It is quite a porous barrier, because NAT is not actually designed to hide systems. Address translation inherently hides some of the attributes of the systems (addresses) but not all of them.

[Marco Ermini]

Most of the NAT vulnerabilities come from home routers, with their PnP and other protocols which are often badly implemented, as well as protocols that do not necessarily play well with NAT.  If it just hides IPs and ports, that is already doing something.

Please do not get me wrong.  I am as much as anyone else hoping to see the day that NAT is relegated into the place in history where it should be.  And I am (unfortunately) well aware that all protocols which negotiate an high port through an encrypted channel (FTP-S, or certain versions of Microsoft Communicator/Lync, certain VPN, etc.) will never work with any NAT (I ensure you I have lived that on my skin).

At the same time, I cannot neglect that practically speaking, my experience with CGN with IPv4 in telcos is that it is quite effective.  Firewall vendors have spent a decade fixing it and implementing every sort of variant such as NAT-T, NAT-PMP, NAT for RPC, etc.

> In a perfect world, you have such good filters that you can transparently provide the real addresses and ports from clients to the rest of the Internet

It's sounding like you're not up to date with IPv6 firewalling capabilities in devices, and therefore might be assuming that none exist.

Are you aware for example that Windows has had a stateful IPv6 firewall, enabled by default, since Windows XP service pack 2, released more than a decade ago?

I've been using IPv6 under Linux to access the Internet either via tunnels or natively for more than a decade, using the stateful IPv6 firewall that has been part of the Linux kernel for at least that long.

This Android phone has native and public IPv6 addresses and is not behind any sort of IPv6 NAT. It's behind a device that can perform IPv6 stateful firewalling, however I think I've turned it off, because I trust that as Google can't trust there is a network firewall upstream of my phone, they ensure my phone is "Internet proof".

The "perfect" world you're referring to is and has been reality for a long time for a lot of people.

[Marco Ermini]

I am sorry, I do not think bringing the discussion on a personal level is useful to the discussion.  If this is interesting, I am aware that Windows has IPv6 and a firewall.  This is not a demonstration that IPv6 filters are near as good as IPv4 ones.

On residential routers, the myth that IPv6 will come and solve all of the NAT problems is, and allow ubiquitous and secure access to all the devices is, in fact, a myth.  IPv6 breaks protocols as much (if not more) than IPv4 NAT.  The most used residential routers in Germany (and proudly German engineered product) requires “advanced view” enabled just to enable it; it provides ULAs via DHCPv6, and performs translation to routable IPv6 addresses.  While IPv4 NAT needs to perform stateful translation of IPs and ports, residential routers on IPv6 only translate IPs – but that is not improving a lot.

On top of it, not to break certain, more complex protocols to work (such as BitTorrent of FTP), they need to actually understand them at Layer-7 level to make them work through the translation – and guess what, NAT is much more tested.  My actual company has to require their employees to request IPv4 if they want to work from home and have their soft phone work properly.

A famous vendor of personal computer which also provides “TV” and “Phone” version of their OS, uses NAT to implement their application filtering.  This means that there is no layer-7 stateful filter without NAT (so far).

Certain firewall vendors (I am sorry, again, I cannot make names, but they can be found easily) come with IPv6 disabled and will simply *ignore* and *let come through* IPv6 traffic arriving on their interfaces *by default*.  And I am not talking about “personal firewalls”, but of NASDAQ-quoted “next generation” enterprise vendor of appliances “Gartner leader again. Again.”.

Practically speaking, to bring IPv6 to a state where the hosts are as secure as they are today on IPv4 on local networks behind NAT, you need well-thought firewall setups, much better default, improved software stack and application-understanding layer-7 filters.  This is not the actual case generally on IPv6 networks and NAT does provide a poor-man “hack” to at least prevent easy access to your network-enabled refrigerator and microwave at home from intruders.

>- however we don't live in such world, therefore hiding provides an additional layer of protection in the "defence in depth" approach.
>

There is no need to perform _address translation_ to perform this protection.

[Marco Ermini]

There is no theoretical need, but this is what works.

Continuing to say NAT in these examples is a bit like saying "I need my toolbox to bang in nails". You need your toolbox because that is where your hammer is, however it is actually your hammer that you use to bang in nails.

NAT is address translation + stateful filtering inherent in the operation of address translation. People who object to NAT in IPv6 are objecting to the implied assertion that it is necessary to perform address translation to achieve stateful filtering.

People who advocate NAT for IPv6 for security purposes don't seem to understand that address translation is *not* required to be able to perform stateful filtering - or they're using the term "NAT" when they should really be using the term "stateful filtering".

[Marco Ermini]

I agree, but no one is advocating for NAT – not me, certainly.  Again, I am sorry, but I believe there are people who are over-sensible about this topic and haven’t got my argument properly.

> PS. I am aware that major firewall vendors implement filters against overbilling attacks; I was only making an objection to the semantic of the sentence: NAT *provides* security, saying the contrary is not correct.

"Security against what" is the key question. You can't actually say NAT provides security without defining the threat or context. If you don't define the threat, the implication of such a statement is that it provides security against literally every threat.

If a bank implements NAT on their data network, are they now secured against bank robbers coming into a branch with guns? Obviously not.

"NAT *provides* security" is going to be wrong in many cases because NAT is an entirely ineffective measure for a large set of threats.

[Marco Ermini]

I do not believe so.  I believe that on practical implementation, NAT is much safer than the current IPv6 filters.

NAT is being asserted as the security measure that should by used in IPv6, because it has been used in IPv4 (and not necessarily exclusively because of security - lack of IPv4 addresses is another reason), without any consideration of its drawbacks or alternatives that don't have those drawbacks e.g. those described in RFC4864.

[Marco Ermini]

I am not asserting that NAT should be used in IPv6 (not sure if this is referred to me).

> I mean the same as you do, I would just phrase it as "the poor ISPs which still do that, should consider migrating their architecture to better options".

The cost of CGN capacity to NAT video traffic volumes from popular video sites is likely going to make deploying native IPv6 a cheaper alternative very quickly.

[Marco Ermini]

…or it is going to bounce back once the usual IPv6 problems arise – sticking purely to the example you made, see recently how NetFlix had to block certain IPv6 accesses because it can’t apply its origin filters.

Regards,
Mark.

[Marco Ermini]

Regards.

> > From: Mark Smith [mailto:[email-masked]<mailto:[email-masked]>]
> > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > On 16 June 2016 at 19:15, Marco Ermini <[email-masked]<mailto:[email-masked]>> wrote:
> > > From: OPSEC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E
> > > Carpenter
> > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> > > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > >> [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>

---

From: Marco Ermini <[email-masked]>
Date: Fri, 17 Jun 2016 13:16:55 +0000

To access IPv4-only enabled hosts?

Regards,
 
Marco Ermini

ResMed Germany Inc

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Friday, June 17, 2016 1:48 PM
To: Marco Ermini
Cc: Mark Smith; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08

Hi,

CGN boxes are way expensive, so anyone with a calculator would route everything that does not need NAT around the CGN box.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Fri, 17 Jun 2016 17:10:08 +0200

Hi,

> To access IPv4-only enabled hosts?

You wouldn't send IPv*6* packets to an IPv4-only host in a dual-stack
client situation.  CGN for IPv4 is not NAT64.

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Jun 2016 08:14:46 +1200

So, can we agree on "NAT is not required to provide security in IPv6 (see
for example [RFC4864])."

I agree that this aspect of IPv6, including the appropriate use of ULAs,
is definitely hard to explain to people brought up on common IPv4 practice.

Regards
   Brian

---

From: Mark Andrews <[email-masked]>
Date: Sat, 18 Jun 2016 08:13:22 +1000

In message <38465846B6383D4A8688C0A13971900C48DC4AFA@ge2eml2k1004>, Marco Ermini writes:

> On residential routers, the myth that IPv6 will come and solve all of the
> NAT problems is, and allow ubiquitous and secure access to all the
> devices is, in fact, a myth.  IPv6 breaks protocols as much (if not more)
> than IPv4 NAT.  The most used residential routers in Germany (and proudly
> German engineered product) requires advanced view enabled just to enable
> it; it provides ULAs via DHCPv6, and performs translation to routable
> IPv6 addresses.  While IPv4 NAT needs to perform stateful translation of
> IPs and ports, residential routers on IPv6 only translate IPs  but that
> is not improving a lot.

This sounds like the ISP or CPE vendor has not listened to +15 years
of advice on how to deploy IPv6.  You should be getting a prefix
delegation from the ISP which is then redistributed to the inside
network.  The PD should be at least a /56 and preferably a /48.

The prefix delegation can be delivered via 6RD if there isn't native
IPv6.

ULA is a additional prefix that provides stable internal addressing.

NAT66 is not recommended and has even published several RFC that
states exactly that opinion.

RFC6296

   For reasons discussed in [RFC2993] and Section 5, the IETF does not
   recommend the use of Network Address Translation technology for IPv6.
   Where translation is implemented, however, this specification
   provides a mechanism that has fewer architectural problems than
   merely implementing a traditional stateful Network Address Translator
   in an IPv6 environment.  It also provides a useful alternative to the
   complexities and costs imposed by multihoming using provider-
   independent addressing and the routing and network management issues
   of overlaid ISP address space.  Some problems remain, however.  The
   reader should consider the alternatives suggested in [RFC4864] and
   the considerations of [RFC5902] for improved approaches.

If someone thinks NAT66 provides any effective security they need
their head read.  Internal addresses leak all over the place and
once you have one all the internal machines are addressable.

The only thing NAT66 provides is the ability to have a single IPv6
address per machine vs multiple IPv6 address internally which comes
at a cost of requiring external equipement to be able to determine
the effective GUA the machine has and more complicated software at
the application level to work around the NAT.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 17 Jun 2016 22:32:26 +0000

> On Jun 16, 2016, at 2:43 AM, Mark Smith <[email-masked]> wrote:
> 

Even there, beware the email header.