Local Network Protection for IPv6
draft-ietf-v6ops-nap-06

[Ballot discuss]
I like the al the changes made to the document - thank you. I think this addressed all but a few of the point. The first one, I know that you request more explanation of this awhile back so I have tried to explain that better.

-------------

  At the same time a NAT creates a smaller pool of addresses for a much
  more focused point of attack, where the adversary does not need to
  scan the entire local network but can instead concentrate on the
  active ports associated with the public NAT address.  By periodically
  scanning the limited 16 bit port range on the public side of the NAT,
  the attack will routinely find all ports that are open to active
  internal nodes.

This assumes that the mappings are address independent as opposed to
address dependent. Most NATs are address dependent.

Proposed resolution - rewrite to explain how this behavior is different
for different types of NATs and provide some information about what
types are deployed with regard to this.

Some of this is easiest to understand having a read of Section 5 of
draft-ietf-behave-nat-udp. Imagine that a host on the inside has sent a packet to host A on the outside and the public port that the nat assigned is 555, now when A sends to 555, it gets forwarded to the host on the inside. Now imagine another host on the outside, call it B, when B sends to port 555 on the NAT, the NAT can do one of many things, some NATs (called Endpoint Independent Filtering ones) send it on the the host. For these types of NATs, what you are saying about scanning is true. For other types of NATs (Address Depended ones), unless the source address of the packet is from A, they will not forward the packet. On these NATs, scanning will not work unless the scanner correctly spoofs the address (and possibly port) of A. Basically some NAT just remember that things to port 555 get forwarded to some specific place on the inside. Some other types of NATs remember that things from the Address of A that arrive on port 555 get sent to the place on the inside. As you can imagine, you can run a lot more connections before running out of ports withe the second scheme so big enterprise NATs tend to use it and it has better security properties so home style NATs also tend to use it.

If you have a look at draft-jennings-behave-test-results-03, you can see that most NATs are actually of the type where scanning will not work.

If this is still clear as mud, let's set up a phone call and I can mail out some slides and try and explain it better.

----------

  3.  The size of the address space of a typical subnet (64 bits of
      IID) will make a complete subnet ping sweep virtually impossible
      due to the potential number of combinations available [21].

21 seems to have expired but my recollection was that in said in many cases a sweep was possible across the space. I think a good article on this topic is

http://www.cs.columbia.edu/~smb/papers/v6worms.pdf

I'd be more conformable seeing this not described as impossible but instead pointing to these other documents for the description of how hard it is.


-------------

The term NAP6 is not good as it will easily be confused with NAT6 by
both english and non english speakers. I don't see this as an editorial
comment as this name is going to cause significant confusion in
discussions about this technology. If people
think it is a good idea to deliberately create confusion here, I
would certainly be interested in hearing why.

Proposed Resolution - change name.  NToP would be fine with me or any
other acronym where it was not going to be easily confused with existing
names.

--------------

Change
  o  and through economic pressure are typically forced today to use
      NAT
to
  o  and today typically  use NAT

(Or provide evidence that it was economic pressure not the many other
things identified in this draft that caused the to use NAT)

---------------

At the meeting at the last IETF, I forget if we came to some resolution on this one. If so jog my memory. My notes did not cover it one way or the other.

You say
  Product marketing departments have widely
  sold IPv4 NAT as a security tool and suppliers have been implementing
  address translation functionality in their firewalls, though the
  misleading nature of those claims has been previously documented in
  [2] and [4].

I have read 2 and 4 in the past and just skimmed them now - could you
point the reader (and me) to where in these documents it show that
marketing departments claims that NAT provides some security tools is
misleading. Unless 2 and 4 actually do claim that marketing departments have made misleading claims, I don't think we should be claiming they do say that.

[Ballot comment]
I am generally happy with the new version.
Margaret Wasserman sent the following comments.
It would be great if you could address at least
her substantive comments, all of which is easy
as far as I can see.

----

>1.  Introduction
>
>  There have been periodic claims that IPv6 will require a Network
>  Address Translation (NAT), because with IPv4 people use NAT to
>  accomplish that person's preferred task.

[Editorial] What person?  Perhaps change to:

  There have been periodic claims that IPv6 will require Network
  Address Translation (NAT), because IPv4 network administrators
  use NAT to meet a variety of needs that will also need to be
  met when using IPv6.

>  This document will explain
>  why those pronouncements are false by showing how to accomplish the
>  task goal without address translation.

[Editorial] s/pronouncements/claims
[Editorial] s/the task goal/those goals

[Editoral] Start new paragraph.

>  Although there are many
>  perceived benefits to NAT, its primary benefit of "amplifying"
>  available address space is not needed in IPv6.  The serious

>  This document describes the goals for utilizing a NAT device in an
>  IPv4 environment that are regularly cited as solutions for perceived
>  problems.

[Editorial] Goals cannot be cited as solutions for perceived problems,
can they?  How about:

    This document describes the goals that are commonly met in IPv4
    networks through the use of NAT.

>  It then shows how these needs can be met without using the

[Editorial] s/needs/goals

>  Another consideration discussed is the view that NAT can be used to
>  fulfill the goals of a security policy.  At a technical level the
>  translation process fundamentally can not produce security because
>  mangling the address in the header does not fulfill any useful
>  security functions;

[Substantive] Later on, you talk about the value of all nodes
appearing to be at the edge of the network, hiding the internal
topology from attackers and you propose a solution to provide the
same type of protection in IPv6.  That is inconsistent with this
paragraph, so I'd suggest that you remove this paragraph.

>  in fact it breaks the ability to produce an audit
>  trail which is a fundamental security tool.  That said, the artifacts
>  of NAT devices do provide some value.
>
>  1.  The need to establish state before anything gets through from
>      outside to inside solves one set of problems.
>  2.  The need to stop receiving any packets when finished with a flow
>      solves a set of problems
>  3.  the need to appear to be attached at the edge of the network
>      solves a set of problems
>  4.  and the ability to have addresses that are not publicly routed
>      solves yet another set (mostly changes where the state is and
>      scale requirements for the first one).

[Editorial/maybe Substantive] The content of this list is very confusing.
According to the previous paragraph, this would seem to be a list of the
ways in which NATs provide value.

The first bullet is okay, as NAT requires that users establish state
before anything comes in from the outside, and the last bullet is
also okay, as NATs provide the ability to use non-publicly routed
addresses.  But the other bullets make less sense.  NATs do not impose
"the need to stop receiving packets" or "the need to appear attached to
the edge of the network".

You could instead say something like

    2. NAT state expirations stops allowing inbound connections
        after an application completes, which solves a set of problems.
    3. Making all nodes appear as though they are attached at
        the edge of the network solves a set of problems.



>          Goal                IPv4                    IPv6
>  +------------------+-----------------------+-----------------------+
>  | Simple Gateway  |  DHCP - single        |  DHCP-PD - arbitrary  |
>  | as default router|  address upstream    |  length customer      |
>  | and address pool |  DHCP - limited      |  prefix upstream      |
>  | manager          |  number of individual |  SLAAC via RA        |
>  |                  |  devices downstream  |  downstream          |
>  |                  |  see section 2.1      |  see section 4.1      |
>  +------------------|-----------------------|-----------------------+

[Editorial] Define SLAAC before use.

>  o  One approach uses explicit host routes in the IGP to remove the
>      external correlation between physical topology attachment point
>      and end-to-end IPv6 address.  In the figure below the hosts would
>      be allocated prefixes from one or more logical subnets, and would
>      inject host routes to internally identify their real attachment
>      point.  This solution does however show severe scalability issues
>      and requires hosts to securely participate in the IGP, as well as
>      having the firewall block all external to internal traceroute for
>      the logical subnet.  The specific limitations are dependent on the
>      IGP protocol, the physical topology, and the stability of the
>      system.  In any case the approach should be limited to uses with
>      substantially fewer than the maximum number of routes that the IGP
>      can support (generally between 5,000 and 50,000 total entries
>      including subnet routes).  Hosts should also listen to the IGP for
>      duplicate use before finalizing an interface address assignment as
>      the duplicate address detection will only check for use on the
>      attached segment, not the logical subnet.

[Substantive]  This is a _much_ improved description of this mechanism.
However, I am still of the opinion that an informational document is not
the right place to define a new untraceable addressing mechanim.

[Editorial] Including the picture after all three bullets makes it unclear
which mechanism is pictured.  Maybe re-order to put this one last, or
add a sentence to make it clearer which is pictured?

>  o  On a local network, any user will have more security awareness.
>      This awareness will motivate the usage of simple firewall
>      applications/devices to be inserted on the border between the
>      external network and the local (or home network) as there is no
>      Address Translator and hence no false safety perception.

[Substantive] IPv6 will not make users have more security awareness.
When we say something like this, we are emitting the same type of
marketing hype that we deride in the vendors of NAT products.  This
bullet should just be omitted.

[Editorial] Although all but one of the specific problems I had with the
text in Appendix A have been fixed, I am still not sure why an
appendix on the benefits of IPv6 belongs in this document.

[Ballot discuss]
In section 2.2

  It is frequently believed that through its session-oriented
  operation, NAT puts in an extra barrier to keep the private network
  protected from outside influences.  Since a NAT device typically
  keeps state only for individual sessions, attackers, worms, etc.
  cannot exploit this state to attack a specific host on any other
  port, though in the port overload case of NAPT attacking all active
  ports will impact a potentially wide number of hosts.  This benefit
  may be partially real, however, experienced hackers are well aware of
  NAT devices and are very familiar with private address space, and
  have devised methods of attack (such as trojan horses) that readily
  penetrate NAT boundaries.  For these reasons the sense of security
  provided by NAT is actually an illusion.

The last sentence here is not supported by the rest of the paragraph
and is in fact fairly misleading. The stateful filtering offered by
NAT offers a measure of protection against a variety of
straightforward network attacks, but not against all attacks. The
example given, a trojan horse, operates by bypassing the filtration,
so the security of filtration isn't perfect. This is consistent with
the security principle of "defense-in-depth". To see how controversial
this statement is, note that many firewalls also do not block
trojans, so this para implies that the "sense of security provided by
firewalls is an illusion" - I don't believe this reflects IETF
consensus. This could be resolved by removing the paragraph.

--------------

This document doesn't clearly explain what level of effort is required
to obtain the listed benefits with IPv6. It seems to me that there are
at least four possible situations:

- This comes for free with IPv6 as-is.
- You could get this capability by upgrading some existing IPv6
  network element (e.g., your router) but leaving the rest of
  your network alone.
- You need to update/reconfigure a substantial fraction of the
  elements in your network, including end-hosts.
- New protocols need to be standardized to provide this capability.

This is important because the claimed benefits of NAT are of the
second variety: you just plug in your NAT and you get them.
A fair comparison needs to include level of effort.

Proposed resolution: For everyone of the comparison points - classify
them into one of the above four items.

--------------------------


  could be useful for an Internet Protocol site.  IPv6 does not support
  NAT by design and this document shows how Network Architecture
  Protection (NAP6) using IPv6 can provide the same or more benefits
  without the need for address translation.

I don't understand what "does not support NAT by design" means. IPv4
doesn't "support" NAT, it's just something that elements do. What's
the difference here?

Proposed resolution: remove this statement

-------------------

Change "This document will explain
  why those pronouncements are false by showing how to accomplish the
  task goal without address translation. "
to

  "This document will explain
  how to accomplish the
  task goal without address translation. "

If the goal of this document is to convince people are considering using
nat6 to not use it, it needs to come across in a factual and non biased
way as possible.

----------------------


  Another consideration discussed is the view that NAT can be used to
  fulfill the goals of a security policy.  At a technical level the
  translation process fundamentally can not produce security because
  mangling the address in the header does not fulfill any useful
  security functions; in fact it breaks the ability to produce an audit
  trail which is a fundamental security tool.  That said, the artifacts
  of NAT devices do provide some value.

ISTM that this contradicts the later part of the document where you
clearly agree that Topology Hiding is desired by customers. I think this
is generally considered a security feature.

Proposed resolution: remove this paragraph


Later you have
  The act of address translation does not provide security in itself;
  for example, consider a configuration with static NAT translation and
  all inbound ports translating to a single machine.  In such a
  scenario the security risk for that machine is identical to the case
  with no NAT device in the communication path.  As result there is no
  specific security value in the address translation function.  The
  perceived security of NAT comes from the lack of pre- established or
  permanent mapping state.  Dynamically establishing state in response
  to internal requests reduces the threat of unexpected external
  connections to internal devices. 

Same issue here - proposed resolution - remove this paragraph


Other places you have

            It must be noted that even a firewall doesn't fully secure
            a network. Many attacks come from inside or are at a layer
            higher than the firewall can protect against. In the final
            analysis, every system has to be responsible for its own
            security, and every process running on a system has to be
            robust in the face of challenges like stack overflows etc.
            What a firewall does is prevent a network administration
            from having to pay for bandwidth to carry unauthorized
            traffic, and in so doing reduce the probability of certain
            kinds of attacks across the protected boundary.

Uh - I do not believe IETF consensus is that "reducing for paying
bandwidth" is the only thing firewall provide. I do agree firewalls
don't solve all your problems.

Proposed resolution: remove this paragraph and fix any other similar
issues in the document

-----------

  IPv6 Network Architecture Protection can be summarized in the
  following table.  It presents the marketed "benefits" of IPv4+NAT
  with a cross-reference of how those are delivered in both the IPv4
  and IPv6 environments.

Why the quotes around "benefits" - it seems to put a tone that NAT has
no benefits but I think the point of this document it to show that v6
can deliver the same benefits as NAT. I really don't care deeply about
this one but taking this sort of tone in this document actually reduces
the odds of this document achieving what you hope it will achieve,
since it makes it appear biased.

Proposed resolution - remove quotes

--------------

  This role, often marketed as a
  firewall, is really an arbitrary artifact while a real firewall has
  explicit management controls.

I don't understand what this means. A simple packet filter firewall
doesn't really need any more management controls than your average
NAT. I don't think that a device without management controls can't be a
real firewall.

Proposed resolution - remove this sentence

(Note this also contradicts what you say later with )

  There is no reason a stateful
  IPv6 firewall product cannot be shipped with the equivalent default
  protection that is offered by today's IPv4/NAT products.

(BTW - I 100% agree with this and think this theme should be part of
central argument on how to achieve all the security properties other
than topology hiding)

-------------

  At the same time a NAT creates a smaller pool of addresses for a much
  more focused point of attack, where the adversary does not need to
  scan the entire local network but can instead concentrate on the
  active ports associated with the NAT address.  By periodically
  scanning the limited 16 bit port range on the public side of the NAT,
  the attack will routinely find all ports that are open to active
  nodes.

This assumes that the mappings are address independent as opposed to
address dependent. Most NATs are address dependent.

Proposed resolution - rewrite to explain how this behavior is different
for different types of NATs and provide some information about what
types are deployed with regard to this.


----------

S 4.2.

  2.  IPsec is a mandatory service for IPv6 implementations.  IPsec

I don't see how this has any relevance to this document. IPsec may be
mandatory to implement for IPv6, but that doesn't mean that it's going
to get used for IPv6 any more than for IPv4. The major implementations
of IPv4 support IPsec already.


-----------

      In addition, the use of
      IPsec with NATs consumes extra bandwidth for UDP encapsulation
      and keepalive overhead [12].

Please provide the actual bandwidth used in both the v6 case and ipsec
over typical NAT case.

---------------

  There should also be an easy interface
  which allows users to create inbound 'pinholes' for specific purposes
  such as online-gaming.  Another consideration would be the capability
  for service provider mediated pinhole management where things like
  voice call signaling could dynamically establish pinholes based on
  predefined authentication rules.

I don't think these statements are implementable today. Considerable
work has been put into Midcom and UPnP and no one has been able provide
an authorization model that makes applications like this practical. It
is also not clear how one would detect the existence and address of the
correct firewall in the first place.

Proposed resolution - remove these two sentences

------------------


  o  One approach uses explicit host routes in the IGP to remove the
      external correlation between physical topology attachment point
      and end-to-end IPv6 address.  In the figure below the hosts would
      be allocated prefixes from one or more logical subnets, and would
      inject host routes to internally identify their real attachment
      point.  ...

This needs to explains that this would require every v6 endpoints to be
built differently than how they are currently being built and add to the
gaps that IETF should look at if this an approach that we want v6
devices to do

------------------

  o  Another technical approach to fully hide the internal topology is
      use of a tunneling mechanism.  Mobile IPv6 without route
      optimization is one approach for using an automated tunnel, as it
      always starts in tunnel mode via the Home Agent (HA). ...

This needs to explain that indicates this would require all v6 endpoints
to to support mobile v6 and that for many latency sensitive applications
such as VoIP, using a home agent can make the latency ban enough that
the application is not usable.

------------------

I don't see how section 2.6 is really relevant for this document.

Proposed resolution - remove section 2.6

----------

  3.  The size of the address space of a typical subnet (64 bits of
      IID) will make a complete subnet ping sweep virtually impossible
      due to the potential number of combinations available.

I might be confused here - it seems like this is only possible if IPs
are generated randomly. While I know this is one of the options for
IPv6, I was under the impression that many devices are
forming part of this using MAC. Imagine that you knew that a Cisco phone
had an certain vulnerability, and you know that their MACs are over a
very narrow range. I think analysis needs to make clear that many
implementations won't get this protection by default.

Proposed resolution - update analysis and gaps as appropriate

-------------

The term NAP6 is not good as it will easily be confused with NAT6 by
both english and non english speakers. I don't see this as an editorial
comment as this name is going to cause significant confusion in
discussions about this technology. If people
think it is a good idea to deliberately create confusion here, I
would certainly be interested in hearing why.

Proposed Resolution - change name.  NToP would be fine with me or any
other acronym where it was not going to be easily confused with existing
names.

--------------

The paragraph that start says

  As discussed in Section 3.1, there are multiple parts to the IPv6
  address, and different techniques to manage privacy for each which
  may be combined to protect the entire address.  In the case where a
  network administrator wishes to fully isolate the internal IPv6
  topology, and the majority of its internal use addresses, one option
  is to run all internal traffic using Unique Local Addresses (ULA).
  By definition this prefix block is not to be advertised into the
  public routing system, so without a routing path external traffic
  will never reach the site.  For the set of hosts that do in fact need
  to interact externally, by using multiple IPv6 prefixes (ULAs and one
  or more global addresses) all of the internal nodes that do not need
  external connectivity, and the internally used addresses of those
  that do will be masked from the outside.  The policy table defined in
  [10]provides a mechanism to bias the selection process when multiple
  prefixes are in use such that the ULA would be preferred when the
  correspondent is also local.

I can not understand what this has to do with hiding the topology from
devices on the outside.

Proposed resolution: remove this paragraph

------------

I don't understand the meaning of
  None of
  these items are show-stoppers for immediate usage of NAP6 in
  scenarios where there are no current gaps.

If what you mean is

  Other than the gaps, there are no gaps.

Then this says nothing and should be removed.

If what you mean is
For scenario X, and Y are there are no gaps but for scenario Z there is.
Then you should lay out which scenarios fall into each category.

------------------

Section 6.2

You say there is no gap. I have a Mac that is supports v6. I don't
really know if it is a fully compliant endpoint but let's assume it is
for a second. I have no idea how to go and configure it to start getting
centrally assigned addressees then inserting those into the IGP. If I
wanted Apple to implement this, what RFC would I need to ask them to
implement? I think you need to identify this as a gap.

--------------

On the topic of using a Home Agent. I think it should be pointed out
more explicitly that this has some of limitations of using a NAT such as
forcing the traffic through a route that may be non optimal which may
increase the latency of real time traffic. In many cases the use of a HA
could change the latency of an a voip call from 70 ms to over 200 ms. It
is also not clear to me how an application on a device would know when
it could just use direct connection (perhaps other device is in same
site) and when it would need to tunnel.

Proposed resolution: discuss why HA have some of the same undesirable
properties of NATs and thus a non HA approach such as the routing
approach, is preferable


------------

One point implies that IGPs works with "between 5,000 and 50,000 total
entries including subnet routes" while other places say "an IGP is
typically not designed to carry many thousands of IPv6 prefixes". I'm
confused here. I would be very interested on many many routes was
possible on say a cisco 2100 and 7200 just as vague reference
points. Would the fact these were going to machine that went on and off
the net all the time like notebook computers causes changes to the size
assumptions due to the routes being less stable? I'm also interested in
what we would expect as the multiple in number of routes in a system
that did this vs the same deployment if it did not. Would their existing
routing hardware be fine? These all seem like very fine questions to be
asking the ops community about deploying this. It may be that this all
fine but anyone that is considering dumping nat6 for this is going to be
considering these same questions.

Proposed Resolution: Give them the answers to what they need to know
about deploying this sort of solution.

--------------

Change
  o  and through economic pressure are typically forced today to use
      NAT
to
  o  and today typically  use NAT

(Or provide evidence that it was economic pressure not the many other
things identified in this draft that caused the to use NAT)

---------------

You say
  Product marketing departments have widely
  sold IPv4 NAT as a security tool and suppliers have been implementing
  address translation functionality in their firewalls, though the
  misleading nature of those claims has been previously documented in
  [2] and [4].

I have read 2 and 4 in the past and just skimmed them now - could you
point the reader (and me) to where in these documents it show that
marketing departments claims that NAT provides some security tools is
misleading.


---------------

  This document defines IPv6 approaches which collectively achieve the
  goals of the network manager without the negative impact on
  applications or security that are inherent in a NAT approach.

It does not seem that it does provide a solution to the topology hiding
that does not require future work and does not have various other
limitations.

Proposed resolution - make this statement consistent with the gaps
section of the document

------------

  These techniques, known collectively as Network
  Architecture Protection, retain the concept of a well defined
  boundary between "inside" and "outside" the private network, and
  allow firewalling, topology hiding, and privacy.

Similar comments to above.

-------------

  However, because
  they preserve address transparency where it is needed, they achieve
  these goals without the disadvantage of address translation.

The HA approach has the same limitation of what many people consider the
worst problem introduced by NATs (the latency, jitter, of non optimal
path). I think this need mentioning.

State Change Notice email list have been change to kurtis@kurtis.pp.se, v6ops-chairs@tools.ietf.org, dromasca@avaya.com, gunter@cisco.com, alh-ietf@tndh.net, rdroms@cisco.com, brc@zurich.ibm.com, ericlklein@softhome.net from v6ops-chairs@tools.ietf.org, dromasca@avaya.com, gunter@cisco.com, alh-ietf@tndh.net, rdroms@cisco.com, brc@zurich.ibm.com, ericlklein@softhome.net

State Change Notice email list have been change to v6ops-chairs@tools.ietf.org, dromasca@avaya.com, gunter@cisco.com, alh-ietf@tndh.net, rdroms@cisco.com, brc@zurich.ibm.com, ericlklein@softhome.net from v6ops-chairs@tools.ietf.org; dromasca@avaya.com; gunter@cisco.com;alh-ietf@tndh.net;rdroms@cisco.com;brc@zurich.ibm.com;ericlklein@softhome.net

[Ballot discuss]
The discussion of host routes in 3.4, 4.4 and 6.1 needs to more effectively describe the limitations.  4.4 says "severe scalability issues" (but 3.4 and 6.1 don't); Alex Zinin did some analysis in the context of TRILL and IS-IS on the scalability of host routes, which are probably relevant; http://www3.ietf.org/proceedings/05mar/slides/trill-0/sld2.htm

[Ballot discuss]
We have a review from Margaret Wasserman and a partial
review from Thomas Narten:

  http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00246.html
  http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00264.html

and some subsequent discussion on the v6ops list. I do not think the
state of the document is quite as bad as the above links would lead us
to believe -- there is some good analysis in the document -- but
there are issues that we need to correct. For instance, I think
the document would benefit from an additional editorial round to
change the tone of the language used. E.g., we should not talk about
"marketing campaigns", "marketing departments", "huge problems".

Section 2.2 would be better cast as an argument that firewall and NAT
functions do not need to be provided together, rather than a lengthy
argument about the limitations of stateful firewall techniques. Yes,
there are limitations but the firewalls are still useful.

Section 3.4 probably promises too much. Its not clear to me that we
today have all the mechanisms available for Mobile IPv6 to use random
home addresses, for instance.

Section 4.2 item 2 is incorrect, because IPsec has been updated to
deal with NATs, and this feature is already widely deployed. I would
also suggest toning down the claim that mandatory IPsec will provide
significant security benefits. In reality, IPsec works well for the
VPN service (in both IP versions) but may not fit well for other types
of security needs.

Section 4.3 assumes that device - address mapping is known. This isn't
necessarily the case when, for instance, the hosts use RFC 3401.

Section 4.7 does not mention issues with multihoming, such as ingress
filtering problems or the ability to switch from one ISP to another
when the first one breaks down. These are being addressed in ongoing
IETF work, but we may not want to claim that everything is already
solved. Perhaps you should at least place a forward reference to
Section 6.4. See also Margaret's comment about this section for
additional issues.

See renumbering comments from Margaret and Thomas.

Overall, I would suggest doing one additional editing round
for the document and then seeing if the raised issues have
been satisfactorily addressed.

Nits:
  - Run spell checker
  - Missing Reference: [RFC1918] is mentioned on line 1414, but not defined
  - Unused Reference: [8] is defined on line 1166, but not referenced

[Ballot discuss]
I've definitely been looking forward to this document for a very long time and think it is important for v6 and much needed. I have never really been sure on my opinion on if V6 NATs would get deployed or not but this definitely helped clarify that. In general I think this is a really good document but I think there are a few places where it oversells the state of the art with v6 and I think that this is the long term will hinder not help getting v6 deployed. I will provide specific examples later in this message.

The draft seem confused on if some of the recommended possibilities are done or not done. Take section 6.1 which says that there is no gap then goes on to describe what sounds a lot like significant work that would need to be done to close the gap. I would much rather see this document clearly say what works needs to be done so we can get on it with - and if the draft also provides sketches of possible approaches to the solution - great.

I am unclear on how, or for that matter if, the untraceable addresses work. Let's imagine a have a large enterprise with a few hundred thousand employees each with a computer, desk phone, and pda/mobile phone that all use the internet. Would I have in the order of half a million routes on the internal network? Can the routing ADs comment on if this is reasonable? When would a device get a new untraceable address? how would it switch out the old one? Right now this seems like work that needs to be done. If I'm confused on this and everything needed it ready today, I'm happy to get educated.

In section 4.2 with the para that starts "To implement simple security..." I think this is recommending something that would block applications other than HTTP to the vast majority of the users of the internet. I really doubt this was what people wanted and certainly not what I want. I think this section would be much better if it pointed out that the "reflective session state" type FW protection provided by today residential NATs can be provided by a v6 FW. I assume that the recommendation is that these "home" style of devices do provide this type of FW but would like to point out that if this is the recommendation, it has profound implications on e2e connectivity. I think the implication should at least be pointed out including the need for things like STUN and ICE to work in such environments.

I do not think the idea of home users needing to configure pinholes in their edge device to be a good idea or implementable in practice. Clearly it's good if this option is there and some people will be able to use it but I don't think our design can be based on the usage of such a feature.

In section 4.4, the possibility of using explicit host routes is mentioned but I don't see how that works without revealing the information we are trying to hide. I expect this is just a I don't understand but perhaps an example of how this works would enlighten me and others.

The other solution in 4.4 is using a Home Agent. I think it should be pointed out that this has some of limitations of using a NAT such as forcing the traffic through a route that may be non optimal which may increase the latency of real time traffic. It is also not clear to me how an application on a device would know when it could just use direct connection (perhaps other device is in same site) and when it would need to tunnel.

In section 5.2, 3rd para, it says that "only one server of any given protocol type is possible per address". I'm not sure this is 100% true since most servers can run on different ports.

Please make clear your recommendations about IPsec and content aware Firewall inspection. Are you recommending that IPsec not be used or recommending that content aware Firewalls not be used. I'm not sure I see how both can be used at the same time unless you are suggesting that application level proxies be used. If the recommendation is that all traffic going to internet needs to go through a firewall that implements an appropriate application level proxy, then I think this is a bad impediment to e2e and feel strongly that the IETF should not be recommending application layer proxies at every administrative domain boundary. (that would almost be like 3GPP :-)

Several places there is the idea that a ULA could solve some of the problems. This is very unclear to me how this would help for the devices that wanted to use the internet. A application on a devices that wishes to communicate with another has no idea if it should use the ULA or a real address unless it is somehow topologically aware of if the address of the other devices in on the internal network. There may be hosts that never need to communicate to hosts on the internet but these are not relevant to the internet or this document and should just be left out of scope. I understand the ULA may useful for things like communicating site routing information while global addresses are changing but that does not seem all that relevant to this document. Implying that there is a solution for devices that are not connected to the internet does not add to the credibility that we have a solution for devices that are. This is rambling but to get specific, I am confused on what situations a ULA might be relevant to the problem this draft is addressing.

Section A.7 - I am unclear on how NAP provides for virtual communities of interest.

The term NAP is not good as it will easily be confused with NAT by both english and non english speakers.

In the conclusion it say "In particular the explicit nature of content aware firewall in NAP will be a vast security improvement...". I see no evidence in the document to support this claim. What is it that v6 content aware firewalls can do that v4 ones can't?

[Ballot discuss]
I've definitely been looking forward to this document for a very long time and think it is important for v6 and much needed. I have never really been sure on my opinion on if V6 NATs would get deployed or not but this definitely helped clarify that. In general I think this is a really good document but I think there are a few places where it oversells the state of the art with v6 and I think that this is the long term will hinder not help getting v6 deployed. I will provide specific examples later in this message.

The draft seem confused on if some of the recommended possibilities are done or not done. Take section 6.1 which says that there is no gap then goes on to describe what sounds a lot like significant work that would need to be done to close the gap. I would much rather see this document clearly say what works needs to be done so we can get on it with - and if the draft also provides sketches of possible approaches to the solution - great.

I am unclear on how, or for that matter if, the untraceable addresses work. Let's imagine a have a large enterprise with a few hundred thousand employees each with a computer, desk phone, and pda/mobile phone that all use the internet. Would I have in the order of half a million routes on the internal network? Can the routing ADs comment on if this is reasonable? When would a device get a new untraceable address? how would it switch out the old one? Right now this seems like work that needs to be done. If I'm confused on this and everything needed it ready today, I'm happy to get educated.

In section 4.2 with the para that starts "To implement simple security..." I think this is recommending something that would block applications other than HTTP to the vast majority of the users of the internet. I really doubt this was what people wanted and certainly not what I want. I think this section would be much better if it pointed out that the "reflective session state" type FW protection provided by today residential NATs can be provided by a v6 FW. I assume that the recommendation is that these "home" style of devices do provide this type of FW but would like to point out that if this is the recommendation, it has profound implications on e2e connectivity. I think the implication should at least be pointed out including the need for things like STUN and ICE to work in such environments.

I do not think the idea of home users needing to configure pinholes in their edge device to be a good idea or implementable in practice. Clearly it's good if this option is there and some people will be able to use it but I don't think our design can be based on the usage of such a feature.

In section 4.4, the possibility of using explicit host routes is mentioned but I don't see how that works without revealing the information we are trying to hide. I expect this is just a I don't understand but perhaps an example of how this works would enlighten me and others.

The other solution in 4.4 is using a Home Agent. I think it should be pointed out that this has some of limitations of using a NAT such as forcing the traffic through a route that may be non optimal which may increase the latency of real time traffic. It is also not clear to me how an application on a device would know when it could just use direct connection (perhaps other device is in same site) and when it would need to tunnel.

In section 5.2, 3rd para, it says that "only one server of any given protocol type is possible per address". I'm not sure this is 100% true since most servers can run on different ports.

Please make clear your recommendations about IPsec and content aware Firewall inspection. Are you recommending that IPsec not be used or recommending that content aware Firewalls not be used. I'm not sure I see how both can be used at the same time unless you are suggesting that application level proxies be used. If the recommendation is that all traffic going to internet needs to go through a firewall that implements an appropriate application level proxy, then I think this is a bad impediment to e2e and feel strongly that the IETF should not be recommending application layer proxies at every administrative domain boundary. (that would almost be like 3GPP :-)

Several places there is the idea that a ULA could solve some of the problems. This is very unclear to me how this would help for the devices that wanted to use the internet. A application on a devices that wishes to communicate with another has no idea if it should use the ULA or a real address unless it is somehow topologically aware of if the address of the other devices in on the internal network. There may be hosts that never need to communicate to hosts on the internet but these are not relevant to the internet or this document and should just be left out of scope. I understand the ULA may useful for things like communicating site routing information while global addresses are changing but that does not seem all that relevant to this document. Implying that there is a solution for devices that are not connected to the internet does not add to the credibility that we have a solution for devices that are. This is rambling but to get specific, I am confused on what situations a ULA might be relevant to the problem this draft is addressing.

Section A.7 - I am unclear on how NAP provides for virtual communities of interest.

The term NAP is not good as it will easily be confused with NAT by both english and non english speakers.

In the conclusion it say "In particular the explicit nature of content aware firewall in NAP will be a vast security improvement...". I see no evidence in the document to support this claim. What is it that v6 content aware firewalls can do that v4 ones can't?

[Ballot comment]
There are a bunch of well known problems/nightmares in using NAT. However some of these limitation happen with some of the items recommend approaches here such as Home Agents, SHIM6, and firewalls with policies that packets from some device on the outside can't come in unless the device on the inside sent a packet out first. It would be really nice to see for the things recommended here, which of the NAT induced problems go away and which don't.

PROTO-write-up for the record:
-----Original Message-----
From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se]
Sent: Saturday, March 18, 2006 14:55
To: David Kessens
Cc: Bert Wijnen; Dan Romascanu; Baker Fred
Subject: draft-ietf-v6ops-nap-02.txt



David,

please find the request from the v6ops WG to publish the above 
document as below.


>  1.a) Have the chairs personally reviewed this version of the 
> Internet
>        Draft (ID), and in particular, do they believe this ID is 
> ready
>        to forward to the IESG for publication?  Which chair is the WG
>        Chair Shepherd for this document?

I have read this document and I believe it is ready for publication.

>    1.b) Has the document had adequate review from both key WG members
>        and key non-WG members?  Do you have any concerns about the
>        depth or breadth of the reviews that have been performed?

The document have been analysed, referenced and discussed in several 
WGs so I believe this condition to be satisfied.

>    1.c) Do you have concerns that the document needs more review 
> from a
>        particular (broader) perspective (e.g., security, operational
>        complexity, someone familiar with AAA, internationalization,
>        XML, etc.)?

No. If there where a int-area directorate I might have suggested that 
(there isn't one, right?).

>    1.d) Do you have any specific concerns/issues with this document 
> that
>        you believe the ADs and/or IESG should be aware of?  For
>        example, perhaps you are uncomfortable with certain parts 
> of the
>        document, or have concerns whether there really is a need for
>        it.  In any event, if your issues have been discussed in 
> the WG
>        and the WG has indicated it that it still wishes to advance 
> the
>        document, detail those concerns in the write-up.

I personally think that this is a highly useful document that should 
be published as is and that it will bring additional value to the 
community.

>    1.e) How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

By my judgement there is very broad consensus for the publication of 
this document.

>    1.f) Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email to the Responsible Area Director.  (It 
> should be
>        separate email because this questionnaire will be entered into
>        the tracker).
>

No threats or appeals have been discussed around this document.

>    1.g) Have the chairs verified that the document checks out against
>        all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
>        Boilerplate checks are not enough; this check needs to be
>        thorough.

This document does pass the id nits test.


>    1.h) Has the document split its references into normative and
>        informative?  Are there normative references to IDs, where the
>        IDs are not also ready for advancement or are otherwise in an
>        unclear state?  The RFC Editor will not publish an RFC with
>        normative references to IDs (will delay the publication until
>        all such IDs are also ready for RFC publicatioin).  If the
>        normative references are behind, what is the strategy for 
> their
>        completion?  On a related matter, are there normative 
> references
>        that are downward references, as described in BCP 97, RFC 3967
>        RFC 3967 [RFC3967]?  Listing these supports the Area 
> Director in
>        the Last Call downref procedure specified in RFC 3967.

It does.

>    1.i) For Standards Track and BCP documents, the IESG approval
>        announcement includes a write-up section with the following
>        sections:
>
>        *    Technical Summary
>
>        *    Working Group Summary
>
>        *    Protocol Quality
>
>    1.j) Please provide such a write-up.  Recent examples can be 
> found in
>        the "Action" announcements for approved documents.

This is an Informational document.

- kurtis -