[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-ietf-v6ops-nap-00.txt



Yes Mark - I think that is an excellent review of the discussion,
thanks for providing it.  I don't know if a consensus was reached
as much as we got tired of kicking the same ideas back and forth!
I think there were two main camps:

1) proxies break end-to-end, so should be excluded from a
discussion of NAP - don't want to encourage bad behavior

2) proxies break end-to-end, but are a tool that has useful
characteristics, and we should just mention what those are and
let sysadmins - based on their networks and needs - make
deployment decisions as they see fit 

I think everyone agreed that no more than a brief mention of
where they fit within a "world without NAT" would be appropriate.

Spence


> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mark Smith
> Sent: Monday, April 18, 2005 7:22 PM
> To: qing.li@bluecoat.com
> Cc: v6ops@ops.ietf.org
> Subject: Re: draft-ietf-v6ops-nap-00.txt
> 
> 
> On Tue, 19 Apr 2005 07:04:09 +0900
> Fred Baker <fred@cisco.com> wrote:
> 
> > 
> > On Apr 19, 2005, at 6:50 AM, Li, Qing wrote:
> > 
> > > 	I just got back from a trip and just caught up on emails.
> > > 	I wasn't able to conclude from the NAP thread whether
> > > 	the NAP doc will include additional text on proxies, or
> > > 	whether there was any suggestion on another document in
> > > 	which discussions on IPv6 capable proxies may be more
> > > 	approriate.
> > 
> > I'm not sure that a real consensus was reached. The nearest
thing I 
> > heard to a consensus was that proxies deserve their own 
> document, as 
> > they are both a v4 and a v6 problem, but that v6-specific 
> issues might 
> > be raised in this document.
> > 
> 
> Here is a summary of what I think were key points of the 
> discussion. Please correct me if I've misunderstood, mistated 
> or misrepresented any of them.
> 
> I think this draft is specifically addressing the benefits of 
> NAT to IPv4, and how certain identified properties and 
> configurations of IPv6 can provide those benefits without 
> resorting to address translation. 
> 
> Proxies were advocated as another topology hiding tool. 
> 
> In a globally addressed scenario (which may be parallel with 
> ULA addressing), proxies aren't that effective as topology 
> hiding tools, as they only hide the topology for a specific 
> application protocol eg., HTTP. Proxies won't hide the 
> topology from techniques that don't use that specific 
> application protocol. There are quite a number of discovery 
> techiques that could be successfully used as alternatives in 
> a proxied combined global / ULA scenario.
> 
> In a ULA only scenario, proxies at the edge of the ULA / 
> Global boundary would provide a topology hiding feature. Two 
> drawbacks though are that this breaks end-to-end, which is 
> one of the things (I think) IPv6 is intended to restore; 
> proxies have to be configured correctly, to ensure they don't 
> proxy internal, ULA located resources for globally located 
> nodes, which would defeat the fundamental purpose of 
> deploying ULA only and a proxy in the first place, namely 
> hiding the internal network yet providing access to global 
> resources. Accessing internal resources from global nodes 
> could be seen to be a form of topology discovery - it may 
> provide enough internal information for other attack methods 
> such as social engineering. Proxies don't inherently provide 
> full topology hiding, even for the application protocol they 
> support - they have to be configured correctly first.
> 
> This draft is specifically addressing features of IPv6 that
provide
> IPv4+NAT benefits, and proxies aren't IPv6 specific, so 
> detailing their
> use in this draft may be out of scope. I personally thought 
> they shouldn't be mentioned at all, others thought they could 
> be mentioned, but not in detail, because they aren't IPv6
specific.
> 
> I think that is all the points discussed; please add any if 
> I've missed them. The discussion seemed to die off there; 
> possibly that means consensus was reached ?
> 
> Regards,
> Mark.
> 
> -- 
> 
>     The Internet's nature is peer to peer.