Subject: Re: [nat66] Terminology: Definition for "IPv6 Realm"?

From: "Dan Wing" <[email-masked]>
Date: Mon, 3 May 2010 12:41:32 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Chris Engel
> Sent: Friday, April 30, 2010 10:37 AM
> To: 'Fred Baker'
> Cc: Keith Moore; [email-masked]
> Subject: Re: [nat66] Terminology: Definition for "IPv6 Realm"?
> 
> 
> A statefull firewalls is NOT an appropriate substitute for 
> NAT, nor is NAT an appropriate substitute for a statefull 
> firewall. They compliment each other and overlap in certain 
> areas but they don't fulfill one another's roles.
> 
> The object, the entire goal, of NAT is to abstract the 
> organizations internal infrastructure from it's external 
> presence. That has functionality in terms of security 
> certainly but it also has functionality operationally.
> 
> I'll try to be brief as this could get quite long...
> 
> In terms of security, NAT...
> 
>  - Acts as a compensating control to help mitigate the impact 
> of firewall misconfigurations. The firewall itself, by 
> definition, cannot substitute for NAT in this arena. It is 
> presumed in this scenario that the firewall (filters) is the 
> point of failure itself. Relying on that layer/mechanism 
> alone means you have a single point of failure. NAT adds an 
> additional layer or (partial) protection.
> 
> - NAT helps to obscure the internal network architecture. 
> This makes it more difficult to profile that network for 
> attack. Although, as been pointed out elsewhere, it is not 
> impossible for an attacker to conduct some profiling even in 
> the presence of NAT. It does require considerably more effort 
> and sophistication to do so with NAT in place. The analogy 
> being that while wall safes can be defeated, they still 
> provide a significant measure of protection over leaving your 
> valuables laying out in the open.
> 
> - NAT aids in privacy as it helps retard the ability of 
> tracking an individual devices activity by IP address from 
> external sources.

Just for the record, that requires stateful translation in
the NAT and is usually achieved via port translation (NAPT).
draft-mrw-behave-nat66 does not do port translation.

-d

> 
> In terms of operability, NAT...
> 
> - NAT reduces the impact of switching vendors by reducing the 
> degree to which an organization must renumber. The private 
> address scheme on an internal network can rename the same and 
> only the external address scheme needs be changed. This has 
> been thoroughly discussed elsewhere.
> 
> - NAT is very useful for the reverse function as well. It 
> allows a network to be flexible in it's distribution and 
> redistribution of internal infrastructure without the need 
> for any changes to the external advertisement of services. 
> Services can be moved between devices, internal networks, 
> moved from a single device to a load balancer....with PAT 
> even split from one device (say providing SMTP & HTTP) 
> without any change in the external advertisement of such 
> services at the network level. This is incredibly useful, it 
> can be accomplished simply on a single interface and, is 
> protocol/application independent and avoids many of the 
> propagation/caching/timing issues caused by other methods of 
> service advertising such as DNS.
> 
> - NAT allows for simplification of address management. 
> Typically the number of devices that need an external 
> advertisement of services (i.e. expect INBOUND traffic) is 
> only a small fraction of the totality of internal devices. 
> NAT allows you to manage that small pool of external 
> addresses on a single device/interface without any need to 
> impact internal address assignments.
> 
> 
> 
> These are just a few of the more obvious areas where NAT 
> provides useful functionality. Note, that I certainly don't 
> mean to imply that NAT does not cause it's share of problems 
> and complications as well. However, every organizations usage 
> case will be different. As with every technology each 
> organization will need to assess the costs and benefits of it 
> in regards it's own unique situation and arrive at the 
> conclusion that makes the most sense for it's own usage.
> Different organizations WILL reach different conclusions. The 
> concept that a significant number of organizations won't find 
> the benefits of NAT far outweigh the costs is (IMO) willful blindness.
> 
> The internet needs to support a wide diversity of users with 
> a wide diversity of interests. I believe that such 
> flexibility, far more then the concept of end-to-end 
> transparency or end-to-end reachability is what lead to the 
> true success of the internet....the freedom for each 
> organization to utilize it in the manner that best fits that 
> individual organizations needs.
> It is admirable to support efforts that NAT NEED not be 
> deployed for those organizations who deem it problematic.... 
> it is wrong-headed to attempt to PREVENT organizations who 
> find NAT useful from deploying it on their OWN network 
> boundaries in an IPv6 world.
> 
> 
> 
> 
> Christopher Engel
> 
> > -----Original Message-----
> > From: Fred Baker [mailto:[email-masked]]
> > Sent: Friday, April 30, 2010 11:28 AM
> > To: Chris Engel
> > Cc: Keith Moore; [email-masked]
> > Subject: Re: [SPAM] - Re: [nat66] Terminology: Definition for
> > "IPv6 Realm"? - Email has different SMTP TO: and MIME TO:
> > fields in the email addresses
> >
> >
> > Is your intent here the same as what is built by firewalls?
> > If so, NAT is a solution, but it is not required to achieve
> > the goal. I suspect that what you're looking for is a
> > firewall, not a NAT.
> >
> > You might read
> > http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security
> >   "Recommended Simple Security Capabilities in Customer
> > Premises Equipment
> >   for Providing Residential IPv6 Internet Service", James Woodyatt,
> >   24-Apr-10, <draft-ietf-v6ops-cpe-simple-security-11.txt>
> >
> > which is a set of requirements we are developing in v6ops for
> > stateful firewalls for IPv6 networks, which one would most
> > likely implement in a CPE.
> >
> >
> > On Apr 30, 2010, at 4:12 PM, Chris Engel wrote:
> >
> > > You WILL have Realms (I believe even very similar to those
> > described
> > > in RFC 2663) in IPv6.
> > >
> > >
> > > 1) I am convinced that there WILL be NAT in IPv6....very 
> similar to
> > > the flavors available in IPv4. It's an open question
> > whether it will
> > > be defined in an RFC but it will exist. Why? Because too
> > many people
> > > like myself will demand it of our vendors. With that kind
> > of economic
> > > pressure, some vendor somewhere will bite and you'll have
> > NAT whether
> > > you like it or not. I just got done telling our hosting
> > company (which
> > > we spend several hundred grand on annually) that we will require a
> > > NAT-like solution for IPv6 and if they don't provide one
> > and another
> > > hosting service does we will be looking to switch 
> vendors. How many
> > > customers like that do you think it will take before it becomes
> > > worthwhile for some-one to invest in building NAT66
> > devices? The only
> > > thing not having any RFC's for them will do is make it likely that
> > > there are no standards, just a hodge-podge of vendor specific
> > > solutions.
> > >
> > >
> > > 2) Even without NAT, you will STILL have the concept of
> > realms. There
> > > are networks, that by design, have very limited or NO
> > reachability to
> > > the general internet. That's why ULA-R exists. In the
> > absence of NAT,
> > > I'm sure a very common deployment scenario for Enterprises
> > will be to
> > > have 2 Network address architectures. Every device on the private
> > > network will have a ULA address and then the devices which are
> > > intended to have some external connectivity will also be
> > assigned a PA
> > > address. The routers/firewalls on the network boundary will be
> > > designed NOT to route ULA traffic...either outgoing or
> > incoming. That
> > > would be my deployment scheme if I had to do IPv6 without
> > NAT. Though
> > > frankly, the plans right now are to avoid IPv6 entirely
> > until there is
> > > some NAT solution. Possibly looking at doing some sort of NAT46
> > > gateway solution if necessary and staying on IPv4 local.
> > >
> > >
> > >
> > > I'm far from the only Network Manager that feels this way. I make
> > > purchasing decisions for my enterprise and I've talked to guys in
> > > similar positions at other enterprises that feel the same 
> way about
> > > NAT that we do. The only reason you aren't seeing vendors 
> biting on
> > > this already is that IPv6 isn't really on most enterprises radar
> > > screens yet. In essence there is no real need or demand for IPv6
> > > itself yet.
> > >
> > > Right now IPv6 (for Enterprises at least) is just a huge
> > unjustified
> > > cost center...that people who are being pro-active may
> > dabble a little
> > > bit with to build up some experience for the time when
> > their may be a
> > > real need to support it.
> > >
> > >
> > >
> > >
> > >
> > >
> > > Christopher Engel
> > >
> > >> -----Original Message-----
> > >> From: [email-masked] [mailto:[email-masked]] On
> > >> Behalf Of Fred Baker
> > >> Sent: Friday, April 30, 2010 1:39 AM
> > >> To: Keith Moore
> > >> Cc: [email-masked]
> > >> Subject: [SPAM] - Re: [nat66] Terminology: Definition for "IPv6
> > >> Realm"? - Email has different SMTP TO: and MIME TO: fields in the
> > >> email addresses
> > >>
> > >>
> > >> I would (did) argue that the issue isn't reachability...
> > >>
> > >> On Apr 30, 2010, at 6:30 AM, Keith Moore wrote:
> > >>
> > >>
> > >>      I agree that the concept of ??? (reachability
> > >> boundaries?) needs a name.
> > >>
> > >>      Keith
> > >>
> > >>
> > >>              Fine. The concept I described is relevant,
> > even if (as
> > >> both Brian and I point out) it is not the same as the one RFC
> > >> 2663/3103 talk about. We'll use a different word so you
> > don't have to
> > >> worry about it.
> > >>
> > >>
> > >>              On Apr 30, 2010, at 6:14 AM, Keith Moore wrote:
> > >>
> > >>
> > >>
> > >>                      Even if one accepts the need for
> > v6-v6 NAT (I do
> > >> not) that's still not a justification for IPv6 addressing realms.
> > >>
> > >>
> > >>                              Look at the "cc" line of this email.
> > >>
> > >>                              On Apr 30, 2010, at 3:11 AM,
> > Keith Moore
> > >> wrote:
> > >>
> > >>
> > >>
> > >>                                      Why is there a need
> > for such a
> > >> concept as "IPv6 realm"?
> > >>
> > >>                                      It seems to me that
> > if we ever
> > >> create IPv6 realms in the sense that realms exist in IPv4
> > (i.e. if we
> > >> make IPv6 addresses ambiguous), we've irrevocably broken IPv6.
> > >>
> > >>                                      And if we end up creating a
> > >> subtly different concept in IPv6 - something like realms
> > without the
> > >> potential for address assignment conflicts
> > >> - it will be confusing to call such things realms.
> > >>
> > >>                                      But I really think the right
> > >> thing to do is to make explicit that there is only one 
> "realm" for
> > >> the entire IPv6 address space.
> > >>
> > >>                                      Keith
> > >>
> > >>
> > >>                                      We got a definition 
> for "IPv4
> > >> realm", based on RFC 2663 (but also RFC 3103).
> > >>                                      Both RFC's are IPv4 
> oriented,
> > >> not providing an explicit definition  for an "IPv6 realm".
> > >>
> > >>                                      This question might
> > be related
> > >> to NAT66, because the IPv4 realm concept is originating 
> from NAT44.
> > >>
> > >>                                      Does anyone know a
> > correspondent
> > >> definition/reference for IPv6 realm?
> > >>
> > >>                                      If not, I'd like to offer an
> > >> initial proposal for discussion, - a common realm term for
> > IPv4 and
> > >> IPv6:
> > >>
> > >>                                      (IPv4 or IPv6 address)
> > >> realm: is defined as a set of addresses, which share all a common
> > >> prefix, that are mutually reachable (thus, within a single
> > IP routing
> > >> domain).
> > >>
> > >>                                      Note: "IPv6 realm" 
> definition
> > >> based on the GLOBAL UNICAST ADDRESS format (§ 2.5.4/RFC
> > 4291) because
> > >> this is a hierarchical format using a "global routing
> > prefix", which
> > >> is assigned to a "site" (i.e. sth like a REALM).
> > >>                                      Comments would be 
> appreciated,
> > >>                                      Albrecht
> > >>                                      _____
> > >>                                      RFC 2663 IP Network
> > >> Address Translator (NAT) Terminology and Considerations
> > >>                                      2.1. Address realm or realm
> > >>
> > >>
> > >>
> > >>
> > >>                                         An address realm
> > is a network
> > >> domain in which the network addresses
> > >>                                         are uniquely assigned to
> > >> entities such that datagrams can be routed
> > >>                                         to them. Routing 
> protocols
> > >> used within the network domain are
> > >>                                         responsible for finding
> > >> routes to entities given their network
> > >>                                         addresses. Note that this
> > >> document is limited to describing NAT in
> > >>                                         IPv4 environment
> > and does not
> > >> address the use of NAT in other types
> > >>                                         of environment. 
> (e.g. IPv6
> > >> environments)
> > >>
> > >>
> > >>                                      RFC 3103 Realm Specific
> > >> IP: Protocol Specification
> > >>                                      3.  Terminology
> > >>                                         Private Realm
> > >>
> > >>                                            A routing realm
> > that uses
> > >> private IP addresses from the ranges
> > >>                                            (10.0.0.0/8,
> > >> 172.16.0.0/12, 192.168.0.0/16) specified in
> > >>                                            [
> > >>                                      RFC1918
> > >>                                      ], or addresses that are
> > >> non-routable from the Internet.
> > >>
> > >>                                         Public Realm
> > >>
> > >>                                            A routing realm with
> > >> unique network addresses assigned by the
> > >>                                            Internet
> > Assigned Number
> > >> Authority (IANA) or an equivalent address
> > >>                                            registry.
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >>                                      nat66 mailing list
> > >>
> > >>                                      [email-masked]
> > >>
> > >> https://www.ietf.org/mailman/listinfo/nat66
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >>                                      nat66 mailing list
> > >>                                      [email-masked]
> > >>
> > >> https://www.ietf.org/mailman/listinfo/nat66
> > >>
> > >>
> > >>
> > >>                              http://www.ipinc.net/IPv4.GIF
> > >>
> > >>
> > >> _______________________________________________
> > >>                              nat66 mailing list
> > >>                              [email-masked]
> > >>
> > >> https://www.ietf.org/mailman/listinfo/nat66
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>              http://www.ipinc.net/IPv4.GIF
> > >>
> > >>
> > >>
> > >>
> > >> http://www.ipinc.net/IPv4.GIF
> > >>
> > >>
> >
> > http://www.ipinc.net/IPv4.GIF
> >
> >
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66