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

From: "Li, Qing" <[email-masked]>
Date: Fri, 18 Mar 2005 11:18:35 -0800

> 
> 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

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Mar 2005 17:01:17 +1030

Hi Qing,

On Fri, 18 Mar 2005 11:18:35 -0800
"Li, Qing" <[email-masked]> wrote:

> control, and enforcement.

The key term here is identification. When you identify using a network
layer address, you aren't really identifying a person, you are
identifying a node, and then basing all your security and policy on the
assumption that the person the policy is applying to will always use
that node. While humans continue to be portable and mobile, that is a
relatively weak assumption. I've seen that assumption broken often
enough when, for example, people in an enterprise network who don't have
Internet access or special application access want it temporarily - they
just move to another node that does. Obviously those people are breaking
the access policy, the question is, are they bothering to try because
the policy barriers are quite low and therefore their chances of success
are high ? Because it isn't too hard, they may not consider they are
breaking important rules.

Ideally, policy should be able to be applied to the user no matter which
node they happen to be using at the time. A network location independant
user identification method would be better, such as username / password.
Once the user has been identified, the specific policy for the user
could then be deployed to the node they're currently about to use. 

 So I guess my question is how does 
> usually require NIAP and/or FIPS certification.

I've understood that the major benefit of the end-to-end argument, in a
networking context, is that you don't build single points of failure
inside the network, by chosing to maintain state in an intermediary
device, in scenarios where a single point of failure didn't previously
exist. Following on from that, if you do maintain state in the network,
to then eliminate those single points of failure, significant complexity
has to be added.

For example, imagine a geographically large network, with Internet
connections at two cities, and an private WAN between them. It can cope
with one of the Internet connections failing - the traffic will be
rerouted from the local Internet connection, across the private WAN, and
out the remote Internet connection. Individual TCP connections will
survive this sort of transient failure, as they don't rely on the
specific devices that are helping them communicate. 

However, if you were maintaining proxy servers at both sites, for TCP
connections to survive a proxy failure, you now have to keep the two
proxy server's states synchronised. This is complex, and will be heavy
on traffic (every TCP segment each proxy sees will generate another
synchronisation packet between the proxies, for example), which may
require much higher bandwidth links between these proxy servers than the
normal traffic requirements of the private WAN.

The stateless, "router only" model is a lot simpler.

> DHCP server we run into the same issue.

That is another good example of where network location and node identity
(ie. IP address), are not identifying a person but a node.

Regards,
Mark.

-- 

    The Internet's nature is peer to peer.