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

[Marco Ermini <[e-mail]>]

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

From: Mark Smith [mailto:[e-mail]]
Sent: Friday, June 17, 2016 2:21 AM
To: Marco Ermini
Cc: Eric Vyncke (evyncke); [e-mail]; Erik Kline; [e-mail]; [e-mail]; [e-mail]; [e-mail]; 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" <[e-mail]<mailto:[e-mail]>> wrote:
>
> 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:[e-mail]<mailto:[e-mail]>] 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.
>
> 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.

[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.
>
> > 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.

[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.

> 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.

[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.

> 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.

[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.



> 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 :-))
>
> >>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.
>
> 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
> >> 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.).
>
> Okay, I have nothing to object on this.
>
>
> >> 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.
>
> 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.

[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.
>
> 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.

[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.



> 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.

[Marco Ermini]

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

>
> >> - 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".
>

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.

>
> Regards,
> Marco
>
> >
> >Regards,
> >Mark.
> >
> > Regards,
> > ​​​​​
> > Marco Ermini
> >
> > CISSP, CISA, CISM, CEH, ITIL, MCP, PhD
> > Senior IT Security Analyst
> > D [phone]  M [phone]
> >
> > ResMed Germany Inc
> >
> >
> >
> > -----Original Message-----
> > From: Mark Smith [mailto:[e-mail]<mailto:[e-mail]>]
> > Sent: Thursday, June 16, 2016 11:43 AM
> > To: Marco Ermini
> > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08
> >
> > On 16 June 2016 at 19:15, Marco Ermini <[e-mail]<mailto:[e-mail]>> wrote:
> > > 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
> >
> > 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
> > > [phone]  M [phone]
> > >
> > > ResMed Germany Inc
> > >
> > >
> > > -----Original Message-----
> > > From: OPSEC [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Brian E
> > > Carpenter
> > > Sent: Thursday, June 16, 2016 1:45 AM
> > > To: Erik Kline; Eric Vyncke (evyncke)
> > > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> > > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> > > Subject: Re: [OPSEC] [v6ops] Asking for a review of
> > > draft-ietf-opsec-v6-08
> > >
> > > On 16/06/2016 07:45, Erik Kline wrote:
> > >> 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.
> > >
> > > 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
> > >
> > >>
> > >> 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].
> > >>
> > >> _______________________________________________
> > >> v6ops mailing list
> > >> [e-mail]<mailto:[e-mail]>
> > >> https://www.ietf.org/mailman/listinfo/v6ops
> > >>
> > >
> > > _______________________________________________
> > > OPSEC mailing list
> > > [e-mail]<mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/opsec
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]<mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/v6ops