Subject: Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt]

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 03 Feb 2005 16:55:50 +0200

Hello everybody,

I read the draft in question an I found it rather good already. I think
it really does hit a spot. I had some mostly minor comments that I think
are more a matter of taste than substantial.  However, I would like to
raise them for discussion:

General comment: I think the audience of the paper are people who are
already true believers of IPv6 and then people that are just trying to
find the functionality that they need, or think they need from NATs. I
think neither of these people groups actually need any health warnings
on NATs themselves or are even interested in the problems of NATs.
Discussion about these issues just distract people. I would propose to
remove most of the problems of NAT and put them in an annex if they are
not absolutely necessary in the text. I don't think the idea of the
paper is to say NATs are bad, but to inform how the things can be done
in IPv6 without NATs and even better!

Some comments about the text itself:

The title of 2.1 ("Simple Gateway..."). Maybe a different name would be
better than "Simple Gateway". Maybe virtually zeroconfig gateway, or
easy to configure, etc. NAT is maybe actually not that simple, but
deploying it is simple for the user.

2.2. Simple security, if the issues of NATs have to be listed in the
body of the document, maybe it is also worth while then mentioning that
private addressing does not actually always mean that the network would
be that private. For instance, my provider has this bizarre
configuration where there is NAT in the network but there is one-to-one
mapping between the private address and the public address. So, it
doesn't save any addresses, protect you at all, etc. In addition, if you
have an operator provided NAT (for a reason or another) there still
might be attackers within the private address space.

Continuing in 2.2 
" In some cases, NAT operators (including domestic users) may be
   obliged to configure quite complex port mapping rules to allow
   external access to local applications such as a multi-player game or
   web servers.  In this case the NAT actually adds management
   complexity compared to a simple router.  In situations where 2 or
   more devices need to host the same application this complexity shifts
   from difficult to impossible."

This does not raise the issue that complex configuration may turn into
security threats. If that wasn't even the idea, I don't think this is a
security issue and shouldn't be here in the first place. It kind of
sounds like you have remembered another bad thing about NAT, and just
add it where you were typing at that time... ;)

Section 2.3, I have often heard that NATs are good, because they give
you control on what can be done through your network. So, if you don't
want people to surf on certain sites, you just add NATs and that's it.
Maybe the "operator/provider/administrator control" should be added as a
perceived benefit.

Section 4.1, there is discussion about DHCP-PD and how simple it is and
you don't have to run any routing protocol. I think this is fine, but
does not quite answer the whole question. It might be good to add some
words about when your home or whatever gateway can get a prefix of its
own, it does not _have to_ give private addresses, but it can give real
public addresses. This is in practice not possible in IPv4. So
basically, you don't need private addresses.

So, these were my comments - for now...

Cheers,

Jonne.

On Wed, 2005-01-26 at 11:35, ext Brian E Carpenter wrote: 
> -------- Original Message --------
> Subject: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt
> Date: Tue, 25 Jan 2005 16:05:42 -0500
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: IPv6 Network Architecture Protection
> 	Author(s)	: G. Van de Velde, et al.
> 	Filename	: draft-vandevelde-v6ops-nap-01.txt
> 	Pages		: 30
> 	Date		: 2005-1-25
> 	
> Although there are many perceived benefits to Network Address
>     Translation (NAT), the primary benefit of "amplifying" available
>     address space is not needed in IPv6.  In addition to its many serious
>     disadvantages there is a perception that other benefits exist, such
>     as a variety of management and security reasons that could be useful
>     for an Internet Protocol.  IPv6 does not support NAT by design and
>     this document shows how Network Architecture Protection (NAP) using
>     IPv6 can provide the benefits without the need for NAT.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-01.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-vandevelde-v6ops-nap-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-vandevelde-v6ops-nap-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "EricLKlein" <[email-masked]>
Date: Fri, 4 Feb 2005 18:45:13 +0200

Speaking for myself, as one of the Authors - see comments below.

Thanks for the serious read through and comments.

Eric
----- Original Message ----- 
Soininen Jonne wrote:

> it really does hit a spot.

Thank you.

> on NATs themselves or are even interested in the problems of NATs.

Actually when I got involved with writing this it was for the IPv6 nay
sayers who felt that NAT was the mos timportant feature in the IP world. I
spoke with people in network security and network administration roles and
when they hear that we had depriciated RFC1918 like addressed in IPv6 they
compleatly freaked out. They felt that NAT was needed for site security, or
for seperation of subnets, or other of the "percieved values" that we put
into the paper.

So in short my goal was a paper that could be used by the IPv6 true belivers
to either explain to newbies or disbelivers why their NAT was not being
upgraded with the rest of the addresses and networking.

> in IPv6 without NATs and even better!

We tried to not do too much NAT bashing, but there were so many
misconceptions as to why a network "just has to have NAT" that the
explinations made the rest seem to make sense to us. If there is a real
problem and the WG all agrees, we can review moving these.

> might be attackers within the private address space.

If your provider is doing this (and it is not the first time I have heard of
this configuration) then are you using NAT after the fixed address to share
the connection between multiple hosts? Thus making it:

Fixed address (Carreir to carrier) <-> NAT (Carrier to Customer) <-> NAT
Customer Network  <-> Host

If so then it is you that are saving the IP addresses not the carrier (this
is why we have many diffrent catagories in section 5).
As to the security concerns, where I have seen this done the carriers are
usually using NAT to subnet their network (as described in 5.4) so that they
have one large block and are using it to reduce problems in their
administration network. But you are right to you there is still no security
benifit.

> add it where you were typing at that time... ;)

Not all that is bad with NAT is limited to security.
> Maybe the "operator/provider/administrator control" should be added as a
Good point.

> basically, you don't need private addresses.
Also a good point.

---

From: Mark Smith <[email-masked]>
Date: Sat, 5 Feb 2005 15:10:28 +1030

Hi,

Firstly, I also agree, this document is good and useful.

A few comments.

"2.4 Privacy and topology hiding"

I'm a bit confused by the last paragraph, which looks to be a general
description of what port scanning is. Is it trying to say that in a
number of IPv4 NAT scenarios (e.g., 1 to 1 or 1 to many, as described by a
few of the earlier paragraphs), that once the public IP address(es) of the
NAT devices have been identified, port scanning can take place against
the hosts behind the NAT device (which in reality is the NAT device
itself) ?

If that is generally the intention, then I'd suggest

(a) moving the paragraph to a bit earlier in the section. To me, it
would seem better placed directly after the 2nd paragraph, which
finishes with "At the same time a NAT creates a smaller pool of
addresses for a much more focused point of attack."

(b) it is probably worth distinguishing between configured "server port
mappings" and ephemeral port mappings on the NAT device, and then
briefly describing the possible attacks based on either type of port
mapping. The text seems to be only describing launching a port scan
against NAT boxes with configured server port mappings, and then using
those results to launch a targetted application attack. Pro-NAT people
will argue that that is a far less common scenario than ephemeral port
mappings for servers on the Internet and clients behind the NAT box, and
therefore isn't a major concern.

Suggestion (b) might be a bit too detailed for this RFC. On the other
hand, I think it would be useful if an RFC such as this one could be
read "stand alone", meaning that it also incorporates brief discussion
of the issues as well as a reference to more informative RFCs on the
particular topic. I think it would be useful to say "just read this
(single) RFC" as to why IPv6 eliminates the need for NAT."

"3.4  Untraceable IPv6 addresses"

I'm probably going slightly off topic ...

I seem to remember some concern on the IPv6 ML with ISPs assigning /127s
to PtoP links, and it causing problems related to multicast or anycast
capabilities. Admittedly I don't fully understand the issues, although I
also wonder whether they exist if /128s are assigned to hosts and host
routes used in the method described in this section.

"4.3  User/Application tracking"

I first read this in horror ( :-) ), as the ability to track usage is
anti-privacy. Then I remembered that it serving one of the perceived
benefits of IPv4+NAT for network managers, as discussed in section 2.3.
I think this is a relatively uncommon use of IPv4+NAT, so I think it
might be useful to mention again in this section that IPv4+NAT is
sometimes used for this purpose, just to placate people who've also
forgotten about section 2.3, as I did while reading through the ID.

The next section addresses my default privacy concern. As an alternative
to my previous suggestion, maybe there would be value in reversing the
order of the "User/Application tracking" and "Privacy and topology
hiding using IPv6" sections in both main sections 2 and 4.

"4.5  Independent control of addressing in a private network"

I'd suggest clarifying the following a bit further :

   When using IPv6, the need to ask for more address space will become
   far less likely due to the increased size of the subnets.  These
   subnets typically allow 2^64 hosts per subnet and an enterprise will
   typically receive a /48 which allows segmentation into at least 2^16
   different subnets.

2^16 subnets is only possible if flat routing is used, and I'm not aware
that this is possible with current IGPs, or hierarchial addressing is
used with the network topology perfectly matching the addressing
hierarchy levels. I think the "at least" implies a minimum in common
scenarios, and I wouldn't think this will be the case.

More than 2^16 subnets within a single /48 would require bits to be
stolen from the IID section of the global address. If this is the
scenario that the "at least" is implying, I think it should be clarified
a bit more.

Regards,
Mark.

-- 

    "This signature intentionally left blank."

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Sun, 06 Feb 2005 23:19:26 +0200

Eric,

thanks for your comments, I'll try to address your comments/questions
below:

> upgraded with the rest of the addresses and networking.

What I meant was: the true believers already know NATs are bad - they
don't need the repetition, and the people that think that NATs are the
best things since sliced bread are not going to believe it anyways.
Important story of the document is that IPv6 can provide you the
functionality that you think you are getting from NATs, but only better.

Anyways, that was just my opinion, and I don't feel very strongly about
it.

[Snip]

> administration network. But you are right to you there is still no security

Actually, I don't have NAT in my network. The setup is strange, because
there is this interesting thing going on: My IP access is provided by a
company that provides me access (with a VPN) to my company. However, to
get access to Internet I need a second provider. There are multiple
providers I can choose from and I have a contract with one of them. To
access the Internet I have to "activate" the access, by first choosing
my provider from a web menu and then giving the credentials (username,
password). After that I have Internet access. However, as by the time I
boot my computer it is not known which provider's access I'm going to
use they cannot give me the real IP addresses. When I then activate the
Internet access they would have to renumber my computer's IP address it
is easier to NAT. 
I actually can connect up to five computers to the Internet and really
all private addresses seem to correspond to an individual public
address...

> Not all that is bad with NAT is limited to security.

I know, but this section is about security. I think the point is valid,
but it just seems to be in the wrong place.

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 7 Feb 2005 10:42:39 +0200

Jonne
<snip>
> all private addresses seem to correspond to an individual public

This is an interesting configuration, I have seen 2 diffrent implementation 
models for what you describe and I am courious which your provider is using:
1. Access provider provides actual real IP address and then acts as a pass 
through to the ISP via the login dashboard.
2. Access provider continues to use NAT address and sets up VPN to ISP after 
the login dashboard, and you get a real IP address from the ISP.

Have you looked to see which model you have?

Thanks for the feedback,

Eric Klein
TTI Telecom

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Feb 2005 11:53:30 +0200 (EET)

Hi,

A couple of personal comments.  In short I think the doc is in pretty 
good shape.  I think the target audience of this document is mainly 
out-of-the-IETF folks who may not be all that v6-savvy.  I call this a 
"techno-political document", and hence important.

substantial
-----------

11.  References

11.1  Normative References

11.2  Informative References

==> Normative references section should nonempty.  I suggest moving at least
RFC1918, RFC2663, RFC2461, RFC3022, RFC2993, RFC3027, RFC3041, RFC3315,
RFC3484, RFC3633, draft-ietf-v6ops-renumbering-procedure and
draft-ietf-ipv6-unique-local-addr up there.

semi-editorial
--------------

  However, if a site is connected to its ISPs via NAT
    boxes, only those boxes need to deal with multihoming and renumbering
    issues.

==> s/only/sometimes only/ -- for small SOHOs the above is typically true,
but if you put e.g. servers inside the NAT, you will need to deal with these
issues in other boxes as well..?

    While the primary implementation and source of randomized RFC 3041
    addresses is expected to be from end systems running stateless
    autoconfiguration, there is nothing that prevents a DHCP server from
    running the RFC 3041 algorithm for any new IEEE identifier it hears,
    then remembering that for future queries.  This would allow using
    them in DNS for registered services since the assumption of a server
    based deployment would be a persistent value that minimizes DNS
    churn.

==> I'm not sure what the last sentence tries to say, in any case, I think
it's at least partially incorrect.  You can do DNS updates with RFC3041
addresses without DHCP as well.  This sentence seems to be hinting that DHCP
provides some exceptional otherwise unttainable features with RFC3041
addresses.

    ULAs have the following characteristics:
    o  Globally unique prefix
       *  Allows networks to be combined or privately interconnected
          without creating any address conflicts or requiring renumbering
          of interfaces using these prefixes
       *  If accidentally leaked outside of a network via routing or DNS,
          there is no conflict with any other addresses

==> it should be clarified that this Globally unique prefix characteristic
is *compared to RFC1918*, not compared to IPv6 global prefixes!  It is not
clear whether you're comparing against IPv4 privates or IPv6 globals..

  There is no reason that rack mounted devices shouldn't be
    considered mobile nodes to mask the internal topology.  It looks
    equivalent to running a VPN to a central server, however it does not
    involve any encryption or significant overhead.

==> s/shouldn't/couldn't/ otherwise this looks weird??
==> this does raise some SPoF concerns however..

    o  The technology to enable source-routing on a network
       infrastructure has been enhanced to allow this feature to
       function, without impacting the processing power of intermediate
       network devices.  The only devices impacted with the
       source-routing will be the source and destination node and the
       intermediate source-routed nodes.  This impact behavior is
       different if IPv4 is used, because then all intermediate devices
       would have had to look into the source-route header.

==> again, this is not correct AFAIK.  IPv4 source routing can be used in a
similar "loose" mode as IPv6, so there is no technical differenceto IPv6
source routing.

editorial
---------

    components.  The longterm solution is a single network without usage

==> s/longterm/long term/

    routing prefix subnet-id part (SID) and an interface identifier part

==> s/prefix/prefix,/

    Randomizing the IID, as defined in RFC 3041, only precludes tracking
    of the lower 64 bits of the IPv6 address.  Masking of the subnet ID
    will require additional approaches as discussed below in 3.4.
    Additional considerations are discussed in [17].  Providing privacy
    for a subnet ID will require different technology.

==> there seems to be duplication with the last two sentences?  Just remove
the last one?

    device like a Mobile IPv6 Home Gateway.

==> s/Gateway/Agent/

    As a simple gateway, the device has the role of managing both packet
    Routing and local address management.

==> s/Routing/routing/

What one does when topology
    probing is to get an idea of the available hosts inside an
    enterprise.

==> this sentence is hard to parse, and can be written simpler.  Reword.

    masked node using the ULA as a COA This truly masks the internal

==> s/COA/COA./

   o  The third is the IP addresses (single or blocks) that they assign
       to customers.  These can be registered addresses (usually given to
       category a and b and sometimes c)

==> you didn't spell out which category is which?  Not sure what you're
referring to..

    devices.  When looking in chapter 2.3 of RFC3314 'Recommendations for
    IPv6 in 3GPP Standards  September 2002' [9] it is found that the IPv6

==> remove "September 2002" ?

       As an alternative some work in Mobile IP to define a policy
    message where a mobile node would learn from the home agent that it
    should not even try to inform its correspondent about route
    optimization (and thereby expose its real location) would allow a
    border home agent using internal tunneling to the logically mobile
    node (potentially rack mounted) to completely mask all internal
    topology while avoiding the strain from a large number of host routes
    in the IGP.

==> that's one helluva long sentence.  Split to 2-3 ?

    o  Initial section of -00 draft 2.6 and 4.6 have been aggregated into
       a new Qcase studyR section 5.

==> weird chars around "case study"

-- 
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: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 07 Feb 2005 11:11:46 +0100

Hi Pekka,

Thanks for input. Before further digestion of the feedback have a look
at the thoughts below.

>similar "loose" mode as IPv6, so there is no technical differenceto IPv6

I expected this comment to pop-up ;-), thus i did further research on this 
with the help of Eric.

<snip>
IETF STD5 about the IP protocol itself specifically states that the source 
route option is used by gateways (and not only by end node):

on page 18:

  The loose source and record route (LSRR) option provides a means
  for the source of an internet datagram to supply routing
  information to be used by the gateways in forwarding the
  datagram to the destination, and to record the route
  information.

and later on page 21:

  When an internet module routes a datagram it checks to see if
  the record route option is present.  If it is, it inserts its
  own internet address as known in the environment into which this
  datagram is being forwarded into the recorded route begining at
  the octet indicated by the pointer, and increments the pointer
  by four.

<end snip>

My understanding of this is that all routers MUST have a look at the IPv4 
options
if LSRR is available, and this is different with IPv6.

Cheers,
G/

---

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Feb 2005 13:21:32 +0200 (EET)

Hei,

> I expected this comment to pop-up ;-), thus i did further research on this 

The issue is that IPv4 couples _record route_ and _source route_ 
functionality.  IPv6 does not support record route.  However, even if 
the routers do not look to the IPv4 options, I see no reason why the 
source route part of IPv4 could not still work without the routers 
looking at the header.

However, I did make a test with this.  At least Cisco replies with 
ICMP source route failed at the first router which has 'no ip 
source-route' configured.

So, while it might be that the routers might not _have_ to record the 
route, it's probable that most implementations disable all the source 
routing when they have something like 'no ip source-route' set.

> My understanding of this is that all routers MUST have a look at the 
> IPv4 options if LSRR is available, and this is different with IPv6.

---

From: Mark Smith <[email-masked]>
Date: Tue, 8 Feb 2005 01:05:45 +1030

Hi,

Another thing that could be added to Appendix A is the ability to deploy
new transport layer protocols without having to upgrade intermediary
devices. To demonstrate that this may be a useful property in the near
future, a couple of upcoming transport protocol examples could be

* SCTP, which, besides its original telephony signalling use, could also
be useful for Instant Messaging e.g., use the separate message boundary
capability to allow file transfers to be carried over the same SCTP
connection as the human typed text.

* DCCP

Regards,
Mark.

--

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Wed, 09 Feb 2005 19:47:39 +0200

Erik,

<snip>

> Have you looked to see which model you have?

It is something toward the model 2 that you describe.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34