Subject: Re: draft-ietf-v6ops-nap-00.txt <PROXIES>

From: Mark Smith <[email-masked]>
Date: Sat, 2 Apr 2005 19:32:00 +0930

Hi Eric,

On Thu, 31 Mar 2005 12:11:51 +0200
"EricLKlein" <[email-masked]> wrote:

> just prior to this being published as draft-ietf-v6ops-nap-00 there was some 
> WG discussion about adding proxies to raft-vandevelde-v6ops-nap-01.
> 
> > Are there strong feelings about adding this section? If so I will start to 
> draft some text  based on the comments from the WG that will be aimed at 
> inclusion in the -01 version and will submit them to the list.
> 
> 

I personally would prefer not to see a section on proxies.

In the prior discussion, proxies were being advocated as another topology
hiding method, potentially useful in IPv6.

I don't think they are that useful for that function, as they only
support topology hiding for the protocols they support. For example, a
HTTP proxy will only hide the identity of devices making HTTP requests
through the proxy. Assuming those same devices have public addresses,
they will still be vulnerable to any other topology discovery techniques
that don't specifically involve HTTP.

NAT is a better topology hiding method than proxies, and, of course, this
Draft is saying NAT isn't necessary in IPv6 for that either.

Regards,
Mark.

-- 

    The Internet's nature is peer to peer.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Apr 2005 09:29:04 +0200

I agree with Mark. There is nothing specific to IPv6 about proxies;
they work equally well for IPv4. As a matter of fact a proxy
can be a very useful v4/v6 coexistence tool. I prefer that they
should be mentioned in a few words in the NAP draft, but nothing
more.

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Sun, 3 Apr 2005 20:39:49 +0300 (EEST)

> should be mentioned in a few words in the NAP draft, but nothing

There are actually enterprises (v4) today that do not allow any 
communication between "inside" and "outside" except using explicitly 
defined proxies. (E.g., maybe just HTTP(S), nothing more).

That is, especially in strictly controlled environments where the 
nodes actually don't have global v6 addresses or wouldn't use them, 
using proxies might fulfill the topology hiding (and maybe other) 
perceived requirements.

In any case, proxies become a necessity when ULAs are used.  The 
situation differs because in v4 you can use NAT ("implicit proxy") 
instead.

These issues might warrant some amount of discussion, especially if 
(IETF) work needs to happen on how the client machines are configured 
to use the right proxies.

-- 
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: Mark Smith <[email-masked]>
Date: Mon, 4 Apr 2005 14:43:49 +0930

Hi Pekka,

On Sun, 3 Apr 2005 20:39:49 +0300 (EEST)
Pekka Savola <[email-masked]> wrote:

<snip>

> situation differs because in v4 you can use NAT ("implicit proxy") 

I've understood that the intended, most common use of ULAs would be to
deploy them in parallel with globals, rather than instead of globals. I
wouldn't think a proxy would be a necessity in that scenario. Or have
I misunderstood what you're saying ?

In a ULA only scenario, a proxy would be necessary to access external
content. It's use as a topology hiding mechanism wouldn't be of much
value though, as the ULA addressed topology would be unreachable over
the public Internet anyway.

(Unless, in the case of a HTTP proxy, the proxy had be missconfigured
and was able to proxy internal intranet sites for external HTTP clients.
Apparently this is how Adrian Lamo exploited Worldcom a few years back.
For details :

http://www.securityfocus.com/news/296

)

Regards,
Mark.

--

---

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Apr 2005 13:48:12 +0300 (EEST)

> I misunderstood what you're saying ?

That's correct, but I suspect the situation may be different in some 
cases.  There will certainly be large deployments which only have ULA 
addresses, I suspect.

> the public Internet anyway.

The users who wish to hide the topology likely also want to hide 
non-routable topology.  Thus, using a proxy is benefit because by 
definition the local topology (whether non-routable or not) cannot be 
discerned.

As said, using proxies in ULA-only case (note that it could be that 
some nodes are ULA-only [but still need to have controlled access out] 
and some may be ULA+global) might fulfill some other perceived 
requirements rather than just topology hiding -- e.g., NAT-like 
security.

---

From: "John Spence, CCSI, CCNA, CISSP" <[email-masked]>
Date: Mon, 4 Apr 2005 04:01:36 -0700

Mark, Pekka, Brian, et. al.;

I do not have strong feelings on how much information on proxies goes into
the draft.

I do believe the most compelling arguments supporting the elimination of NAT
in the IPv6 architecture need a discussion of what you can achieve - and
what you give up - if you deploy proxies.  As a practical matter, even
considering the peer-to-peer IPv6 Internet of the future, in the near and
middle term the continued use of stateful firewalls (breaks end-to-end) and
proxy servers (breaks end-to-end) will be a reality.  I think a reasonable
deployment model for the enterprise is giving "internal use only" nodes ULA
addresses.  Any node needing Internet access would have both a ULA (for
internal use and, most likely, HTTP via the proxy) *and* a global-scope
address (for peer-to-peer applications).  Other nodes may use a ULA and the
proxy to obtain a "basic" Internet capability (unable to be a full Internet
peer).

That allows security managers to continue to use a model they are
comfortable with for most traffic, and arguably does provide benefits
(caching, policy enforcement, topology hiding), but also allows an
enterprise to roll out peer-to-peer services as a matter of course as
needed.  By using IPv6 and eliminating NAT, enterprise network managers gain
great flexibility - even if they continue to use proxies to fulfill some
needs.

I just think that is the reality, and to try to push a model that eliminates
NAT *and* proxy (and probably some people would like to eliminate stateful
edge firewalls even at this early stage) will result in some feeling that
the NAP draft doesn't go far enough in recognizing the need for continuity
from today's network.

----------------------------------------------------
John Spence, CCSI, CCNA, CISSP
Native6, Inc.
IPv6 Training and Consulting
[email-masked]
www.native6.com
----------------------------------------------------

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 4 Apr 2005 14:22:29 +0200

John Spence wrote:

<Snip>
> the NAP draft doesn't go far enough in recognizing the need for continuity

In listening to the (few) comments on proxies I tend to agree with John that 
Proxies should be left out of this document. If they are to addressed it 
should be in a separate security document.

Eric

---

From: Baker Fred <[email-masked]>
Date: Mon, 4 Apr 2005 12:00:03 -0700

On Apr 4, 2005, at 4:01 AM, John Spence, CCSI, CCNA, CISSP wrote:

> what you give up - if you deploy proxies.

Speaking for myself, I very much agree. The big marketing thing for 
IPv6 is the end to end architecture. What ULAs do is summarily discard 
that, and what proxies do when so configured is what NATs do 
automatically.

Think about it this way. Right now, with IPv4, someone that wants to 
implement wireless in their home buys a Linksys box at the store, 
screws it to the wall, and applies power. Job done. With IPv6, they 
will be able to do the same thing some day in the future when ISPs 
distribute a /64 to each house via DHCP and when Linksys sees enough 
market to put IPv6 into the system. Until then, you can manually 
configure a ULA and a proxy.

Given the options, what does T.C. Mits install in his house? I submit 
that he installs IPv4 and a NAT. It is easier and gets him what he 
thought he was buying.

If we think ULAs are going to commonly *replace* end to end addressing, 
that is something that somebody needs to analyze, and since that is yet 
another variation on a NAT, it seems like it should go here.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Apr 2005 23:52:35 +0300 (EEST)

On Mon, 4 Apr 2005, Baker Fred wrote:
> Speaking for myself, I very much agree. The big marketing thing for IPv6 is 
> the end to end architecture. What ULAs do is summarily discard that, and what 
> proxies do when so configured is what NATs do automatically.

Sure, but the main difference from the IPv6 and end-to-end perspective 
is that proxies are explicitly configured.  They aren't "automatic"; 
they don't apply to all the traffic trying to outsmart it, or just 
hope it doesn't break any protocol in the process due to translation.

I would hope that when the admin sets up a proxy, the proxy will be 
able to interpret that particular protocol because, hey... the proxies 
are typically protocol-specific.  Or, if it isn't, I would hope that 
the admin has made a knowing & conscious decision that the protocol is 
so simple, proxying "just works".

Using NATs, implicit or automatic proxies, etc. rips all of that away. 
Because of this, explicit proxies are the next best thing (ro the 
end-to-end communication) from the end-to-end perspective.

---

From: Baker Fred <[email-masked]>
Date: Mon, 4 Apr 2005 15:17:51 -0700

> end-to-end communication) from the end-to-end perspective.

You won't get any argument from me. I'm looking at the houses up and 
down the street and asking what their occupants might think...

 From my perspective, if the sum of this document is "you don't need no 
stinkin' NAT because if you just type enough highly technical gibberish 
into your whizbang thingie you can get something that accomplishes 
about the same thing", you lost before you started. My daughter will 
happily buy a NAT that plugs and for the most part plays.

What we need to come out of this document is a reasoned analysis of the 
issues in play, and a set of recommendations that will allow the likes 
of Linksys, Microsoft, etc to target their default configurations so 
that IPv6 products in fact plug and play, as opposed to mostly plugging 
and mostly playing. At the end of the day, you want IPv6 to be a 
solution that my daughter can adopt without knowing or caring and find 
simply works, as opposed t having the application limitations and so on 
that she presently enjoys (or doesn't).

So from my perspective, yes, this document wants to cover proxies. Not 
in detail, perhaps, but enough to say what works, what doesn't, and 
give advice on how to make them work well, or advice on how to protect 
them better than a NAT does.

---

From: "John Spence, CCSI, CCNA, CISSP" <[email-masked]>
Date: Mon, 4 Apr 2005 18:43:16 -0700

Eric;

Just to be clear - I think the document should discuss proxies.  Not as a
recommended practice, but a tool that has a place in IPv6 deployment.  We
should be clear about what feature of proxies are attractive, what
side-effects are not attractive, and how to trade off the two.  The coverage
should be brief and straightforward.

Spence

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of EricLKlein
> Sent: Monday, April 04, 2005 5:22 AM
> To: [email-masked]
> Subject: Re: draft-ietf-v6ops-nap-00.txt <PROXIES>
> 
> John Spence wrote:
> 
> <Snip>
> > NAT *and* proxy (and probably some people would like to eliminate 
> > stateful edge firewalls even at this early stage) will 
> result in some 
> > feeling that the NAP draft doesn't go far enough in recognizing the 
> > need for continuity from today's network.
> >
> 
> In listening to the (few) comments on proxies I tend to agree 
> with John that Proxies should be left out of this document. 
> If they are to addressed it should be in a separate security document.
> 
> Eric 
> 
>

---

From: "John Spence, CCSI, CCNA, CISSP" <[email-masked]>
Date: Mon, 4 Apr 2005 18:56:42 -0700

Eric;

Spence

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Apr 2005 12:19:02 +0930

On Mon, 4 Apr 2005 18:56:42 -0700

> should be brief and straightforward.

I'm starting to wonder whether this Draft is "dual-scoped", with the
scopes not quite matching. Alternatively, some of the discussion
regarding this Draft seems to have unintentionally widened the
understood scope of this Draft.

The Draft currently seems to be addressing the union of two topics :

(a) "network architecture protection" eg end-to-end,  etc.

(b) how NAT is not required for NAP, and why not

If the Draft was purely discussing (a), then there might be a place for
proxies in it, as per John's suggestion above.

On the other hand, if it is restricted to a scope of the union of NAT
and NAP ( (a) and (b) ), then I'd think proxies shouldn't be in it,
unless they specifically provide an IPv6 oriented alternative to one or
more of the functions IPv4 NAT provides.

Should the scope of this Draft be widened ? Or should some of these
other issues, e.g., proxy deployment in an IPv6 environment, be
addressed in other Drafts / RFCs. I haven't read them, however, I've
seen a few v6ops Drafts / RFC titles recently which I'd think either do
or should cover the wider issues, but not specifically the union of NAT
and NAP.

Regards,
Mark.

--

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 05 Apr 2005 12:43:49 +0200

Hi Mark,

The initial intention of the draft was to look at NAT and see why people
are using address translation technology (basically to identify the 
perceived NAT
benefits). Once identified, the next step would be to propose native IPv6 
alternatives to
these perceived benefits. I don't believe there is dual scope here.

Brgds,
G/