RE: draft-vandevelde-v6ops-nap-01.txt - "maybe add a bit more on proxy servers ..."

["Li, Qing" <qing.li@bluecoat.com>]

> 
> RFC 2775 and RFC 3234 addressed these issues, I believe. 
> While I wouldn't be as negative as that about proxies, I do 
> think that it would divert from the main argument in the NAP 
> draft if we expanded that topic.
> 

Since a good portion of the document discusses untraceable addresses, 
therefore I also believe the document should have some discussion 
on proxies. 

In the SOHO/home environment, privacy and secure end-to-end 
communication is of main concern, which are not necessarily desirable 
or applicable in the enterprise environment. One has very little 
control and right to claim privacy in the enterprise environment. 
Think of individual users on the DoD networks.

In the enterprise environment proxies are deployed to enforce enterprise

network access policies. The privacy extension of generating temporary 
addresses and making addresses difficult to trace would make the 
enforcement task a difficult one. For example, a fixed policy rule 
such as:

address	    time-of-day          week-day    bandwidth-alloc
--------------------------------------------------------------
IPv6-addr-X     9:00AM - 3:00PM      M,W,TH,F    X-kbps

would be difficult to enforce if IPv6-addr-X either constantly
remaps to a different node, or if the node constantly replaces
IPv6-addr-X with something else.

In other words, some of the goals of NAP (probably more accurately
the goals of address privacy extension) are contrary to the 
enterprise network management goals, which are identification,
control, and enforcement. So I guess my question is how does 
NAP fit in this type of enterprise environments ?  

A secure proxy can be means to NAP. Many of the proxy functions 
require connection termination and if the policy allows, another 
connection is originated by the proxy on behalf of the client, 
effectively hiding the identity of the client.

The argument that a proxy breaks the end-to-end model is not
entirely true. Once the initial authentication and authorization
step is complete, later communication would require a simple
connection-splicing in the proxy, much like what a bridge/route does. 
Of course in the case of HTTPS termination the proxy does more work 
for decrypting/re-encrypting traffic. Secure proxy appliance
usually require NIAP and/or FIPS certification.

The other argument about the proxy breaks the security model
whereby the origin server identifies the client based on its
IP address is flawed. Identification on IP cannot identify
the individual users on the node, so origin server cannot personalize 
the content by IP alone. You don't need a proxy to get into trouble.
If the node acquires globally routable address from a
DHCP server we run into the same issue.

  -- Qing