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

[Mark Smith <[e-mail]>]

On 17 Jun 2016 00:15, "Marco Ermini" <[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]] 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.

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

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

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

Regards,
Mark.

>
> 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]]
> > Sent: Thursday, June 16, 2016 11:43 AM
> > To: Marco Ermini
> > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke);
[e-mail]; [e-mail]; [e-mail];
[e-mail]; [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]> 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]] On Behalf Of Brian E
> > > Carpenter
> > > Sent: Thursday, June 16, 2016 1:45 AM
> > > To: Erik Kline; Eric Vyncke (evyncke)
> > > Cc: [e-mail]; [e-mail]; [e-mail];
> > > [e-mail]; [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]
> > >> https://www.ietf.org/mailman/listinfo/v6ops
> > >>
> > >
> > > _______________________________________________
> > > OPSEC mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/opsec
> > > _______________________________________________
> > > v6ops mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/v6ops