Subject: [BEHAVE] IPv6 NAT: User perspectives

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Nov 2008 09:22:55 -0500

Hi,

I spend a fair bit of time talking with end users.  I've done
this for much of this decade, in most regions of the world.
I've also alternated being user and implementer/vendor through
the years, so I've got experience on both sides of that fence.

Many of the folks I talk with are "enterprise" or "academic"
end users, but the mixture also includes some service providers,
some governmental/military users, and also other kinds of users.

A question that I routinely ask of users is:
   "What are your top 10 IPv6-related feature desires, in priority  
order ?"

The clear #1 answer to that is:
	"IPv6::IPv4 bi-directional NAT with protocol translation"

   The consistent user explanation to me is that for many years, their
   IPv6-only systems will need to be able to access IPv4-only content.
   Content means nearly anything (e.g. email, web, IM) to these users.
   They also would like to permit IPv4-only users to access IPv6-only
   content, hence the "bi-directional" part of this.

The clear #2 answer to that is:
	"IPv6::IPv6 NAT that works like my existing IPv4:IPv4 NAT"
	
    The consistent user explanation is that they perceive a security
    benefit to their current NAT.[1]  Many organisations (including my
    employer's IT folks) have a clear policy that only a small set
    of systems (e.g. public web servers) have global-scope IP addresses,
    with the majority of systems (and the default choice) being to
    use local-scope (e.g. RFC-1918) addresses.  Many also say that
    it is desirable that some applications do not work through the
    widely deployed IPv4 NAT implementations (absent an ALG being
    specifically deployed by the organisation to permit that application
    to traverse the NAT device).

Based on these user inputs over the past 8 years, I believe that some
form(s) of IPv6 NAT are going to happen.  There are three questions
before the IETF on this topic:

1) Will there be an open specification for IPv6::IPv6 NATs soon ? [2]
2) If there is an open specification, will it provide the properties
    that users want/desire/expect ? [3]
3) If there is an open specification, will it preclude evolutionary
    directions for IPv6 (or for the Internet generally) ? [4]

Yours,

Ran Atkinson
[email-masked]

[1] It is irrelevant whether this perception is valid.  Users
buy and deploy based on their perceptions.  Standards bodies
of any sort have extremely limited ability to change widely held
user perceptions.

[2] This is phrased precisely.  It really does NOT matter whether
a specification is standards-track or not.  It matters a lot
how quickly an open specification is perceived to be stable enough
to code against.  I have reason to believe that multiple implementers
are coding IPv6::IPv6 NAT products right now, so the time window
is probably very small (a few months at best).  I am out of the
loop on what my employer's products might or might not do, so I'm
not speaking about or for my employer in any of this.

[3] For example, one expectation is that the mechanism itself will
prohibit sessions from being initiated on the "external" interface
of the NAT device.  Most users do NOT consider it desirable that
a device outside the interior domain can send a packet and have it
be translated inwards by the NAT *unless* the corresponding interior
node initiated the session.

[4] For example, there are tens of I-Ds on ways to improve IPv6
mobility (for mobile hosts, mobile networks, or both).  There
are also several different proposals being worked on in the IRTF
Routing RG, HIP RG, or other places that generally fall in
the "8+8" class of architectures.  Such proposals might involve
enhancements to (host, network) mobility, (host, network)
multi-homing, MANETs, and other desired network capabilities.

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

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 26 Nov 2008 16:48:35 +0200

>     use local-scope (e.g. RFC-1918) addresses.

You won't be serving your customers if you give them a "NAT" just because they 
ask for a "NAT". My guess is that your customers have defined such policy to:
- prevent inbound connections, and/or
- obfuscate the toplogy.

By any chance, a would-be IETF-specified NAT66 will not address the first 
bullet. They really want a stateful firewall. Admittedly, because of the 
second bullet, they might still want a NAT66 anyway.

As a matter of fact, today (and ever since I "deployed" it), my NAT44 does NOT 
block inbound connections. If you send a packet to my NAT with the (private) 
IP address of one of my internal hosts, you _will_ be able to reach that 
host. Oh sure, not just _anybody_ can do it, but my ISP, and probably the 
many customers of my ISP that sit on the same segment as my NAT, can do it. 
And I trust neither of them, especially not the second category.

I have a feeling that your customers won't be happy if you give them a genuine 
NAT66 just because they asked for an IPv6-IPv6 NAT. You can market your 
integrated stateful firewalling and NAT66 solution an "IPv6-IPv6 NAT" if it 
helps. I don't think product naming and marketing is a concern for IETF 
standardization.

>     Many also say that it is desirable that some applications do not work
>     through the widely deployed IPv4 NAT implementations (absent an ALG
>     being specifically deployed by the organisation to permit that
>     application to traverse the NAT device).

*Properly* speaking, I don't really see the point of using a NAT if you have 
application layer gateways. The set of the protocols that do operate 
unhindered through NATs include those protocols most undesirable in such 
organizations: Skype, p2p file transfer, most IMs protocols...

Indeed my own employer uses proxies and private addresses for each a the few 
protocols that are allowed. No need for any NAT in this picture.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Nov 2008 10:17:28 -0500

On  26 Nov 2008, at 09:48, Rémi Denis-Courmont wrote:
> You won't be serving your customers if you give them a "NAT"
> just because they ask for a "NAT".

[Note Well:

1: These inputs aren't necessarily from "my customers" in any case;
    they are just users that I've talked with.  I talk with
    lots of non-customer users in the normal course of life.
2: I have very little to do with product/feature decisions here.
3: I am never allowed to speak for my employer. ]

> My guess is that your customers have defined such policy to:

They definitely said "prevent inbound connections".

Most did not say "obfuscate the topology" or something
obviously similar in my presence.

Some military users said they do want to "obfuscate the topology",
but they do NOT care if outsiders can "count the hosts inside".
Further, several users observed that it isn't hard to count
hosts inside existing IPv4 NAT deployments.  One reminded
me of this paper, which I think is from a USENIX Security
Symposium about 10 years back:
	<http://www.cs.columbia.edu/~smb/papers/fnat.pdf>

A few folks reminded me of the IPv6 Privacy Address extension,
and said they would likely deploy that in situations where they
cared about privacy issues or host-counting issues.

> The set of the protocols that do operate

> organizations: Skype, p2p file transfer, most IMs protocols...

As near as I can tell, different users have different policies
as to which applications/protocols are desirable or undesirable.

I don't have enough information to draw generalised conclusions
about policies.

Yours,

Ran Atkinson
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Nov 2008 14:10:26 -0500

Rémi Denis-Courmont wrote:
> bullet. 

I'm arguing that an IETF-specified NAT66 MUST address the first bullet.

Otherwise, a few years down the road we'll find, once again, that we've
failed to deliver a standard that actually does what people need.  (or
think they need).

> helps. I don't think product naming and marketing is a concern for IETF 

I think some consideration of naming and marketing is a practical
necessity for IETF, at least, if we want our work to be effective.
That's not to say that we want to devote a large amount of our energy to
these issues.  But failure to consider them is a good way to waste the
time that we invest in protocol design and specification.

Keith

---

From: james woodyatt <[email-masked]>
Date: Wed, 26 Nov 2008 12:13:39 -0800

> They definitely said "prevent inbound connections".

Did anyone explain why an ordinary firewall without any sort of NAT66  
function is insufficient for this purpose?

> Most did not say "obfuscate the topology" or something obviously  
> similar in my presence.

Did anyone offer any other explanations for why they perceive a need  
for NAT66 besides topology obfuscation or the prevention of inbound  
connections?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Nov 2008 15:29:32 -0500

> function is insufficient for this purpose?

most network admins don't have a sufficiently clear distinction between
NATs and firewalls in their minds, and/or aren't sufficiently aware of
the implications of the differences between IPv4 and IPv6, to be that
precise.

IETFers have enough trouble sorting out those issues.  should we expect
network administrators (or their bosses) to do better?

(eventually, they probably will. but it will take many years.)

IETF needs to define a standard for v6 firewalls.  address translation
needs to be an optional feature of such firewalls - and if included,
there needs to be a way to disable it.  a traversal protocol, with
authentication, needs to be a mandatory feature of such firewalls.  a
protocol to let apps be aware of their external addresses (whether the
addresses are changed or not from the "internal" addresses) also needs
to be a mandatory feature of such firewalls.

calling such a firewall a "v6 NAT" (or something similar) is just good
marketing.  even if the NAT part is optional.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Nov 2008 07:15:06 +0200 (EET)

> - prevent inbound connections, and/or

FWIW, I was just educated to another case that may be common in some 
contexts.

Enterprises A and B connect directly to each other (B2B and other 
applications which are initiated from enterprise A) as well as the 
Internet.  Even though they could use public address space, A uses 
natting towards B to change public or private addresses to another set 
of public addresses.  This avoids B from having to configure static 
routes or run a routing protocol towards A, which has a large set of 
IP addresses.  Further A and B don't necessarily want all their 
communication go through the direct link -- if a user from A surfs to 
www.B.com, that should still use Internet connectivity.

NAT seems to simplify this B2B private routing for specific apps.

With IPv6 this could be done without NAT more easily (if both 
enterprises had only a single /48 or such) if they are willing to 
route all traffic through their direct link.  But if they are not, 
we're back in the same "a routing protocol or clumsy static route 
management" mess.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 28 Nov 2008 08:47:01 -0500

Yes, this is very similar (or perhaps identical) to the case that Fred  
Baker presented in the behave WG meeting in MN.  In his scenario,  
Cisco wants to allow partners to access certain Cisco servers without  
providing their partners full access to Cisco's internal network, or  
even full visibility into the structure of Cisco's internal network.

It wasn't said explicitly, but it's also likely that Cisco would want  
people on their partner's network to be able to go over the Internet  
to access Cisco's external web sites, just like everyone else.

I'm aware of other cases along these lines, such as trading partner  
networks that are used in the retail supply chain.

Margaret

On Nov 28, 2008, at 12:15 AM, Pekka Savola wrote:

> natting towards B to change public or private addresses to another  
> set of public addresses.  This avoids B from having to configure  
> static routes or run a routing protocol towards A, which has a large  
> set of IP addresses.  Further A and B don't necessarily want all  
> their communication go through the direct link -- if a user from A  
> surfs to www.B.com, that should still use Internet connectivity.
>
> Systems. Networks. Security. -- George R.R. Martin: A Clash of  
> Kings_______________________________________________
> Behave mailing list
> [email-masked]