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

From: "Christian Huitema" <[email-masked]>
Date: Sat, 19 Mar 2005 15:33:07 -0800

> >  ... In IPv6, pinging any multicast address should get you an ICMPv6
> > Echo Response from each host in the multicast group. The pinging
> > All-Routers should get you a list of the routers in a network, and
> > therefore a list of the transit subnets in a network (but not
> > necessarily the edge LANs that have only one router on them).
> > Subnet-router anycast address will certainly find a router in your
> > subnet, and (rather than arping for each of your neighbors as is
> > currently done by viruses), pinging the All-Nodes Multicast Address
> > should get you an echo response from every node on your local LAN.
> > Solicited-Node Multicast also gives you some sweeping capability,
> > albeit only on your local lan.
> >
> 
> It's a bit of a surprise to me that the offlink sourced methods you've
> described would work in IPv6, because I've assumed that as directed
> broadcast style techniques had been deprecated in IPv4, they also
> wouldn't be available in IPv6.

This technique does not work remotely -- the all nodes and all routers
multicast addresses are defined in "link local" scope. The virus will
only learn about directly connected targets, i.e. 1 hop away.

Note that it is in any case very difficult to hide from nodes on the
same subnet. The hypothetical virus can collect a list of targets by
simply subscribing to local multicast groups, and passively waiting for
traffic to come in -- the source address of a multicast describes a
potential target. This works quite well for both IPv4 and IPv6.

The advantage of IPv6 is that it very hard to perform a "remote scan" --
much hard than "for I=1 to 254 ping 123.45.67.$I".

-- Christian Huitema

---

From: "Li, Qing" <[email-masked]>
Date: Mon, 21 Mar 2005 12:33:28 -0800

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

    No disagreement here at all WRT to node vs. user identification
    and the corresponding level of policy application and enforcement.
    One important differentiator between a proxy and a firewall is
    in proxy's ability to define higher level rules and enforce those
    rules.

    The point of the discussion, however, was that there may exist
    situations where a network administrator may want to write
    a policy based on a node id instead of a policy based on individual
    users. For example, a large corporation may have designated nodes 
    on designated subnets for access by contractors and interns. The 
    egress proxy may contain such policies. I also don't want to assume 
    the various network topologies in which the proxies are deployed and

    the types of policy rules that make sense in those different
topologies.

    The discussions carried in the NAP draft document on the addresses
    and mechanisms on hiding networks, IMHO, impact the deployment and
    operations of proxies that are becoming ever more popular in
enterprise
    environments. Therefore, I feel the doc should address the proxy
    space.

    -- Qing

---

From: "Li, Qing" <[email-masked]>
Date: Mon, 21 Mar 2005 14:36:13 -0800

> 
> For me, the NAP draft is about saying "here is a collection 
> of tools and techniques that allow the elimination of NAT 
> while maintaining a secure network".
> Right now, I think proxies should be one of the tools.  And
considering 
> how much Internet traffic is proxyable, and how prevalent 
> proxy-based value-add tools are in enterprises today, 
> I think it warrants more emphasis.
> 

   	Yes.

> 
> Nonetheless, proxy servers provide host ID and network 
> topology hiding, and should be quick and easy to deploy for 
> IPv6 networks, and can serve a majority of Internet traffic, 
> while allowing the security team to conduct other policy 
> enformcement and packet/session analysis.
> 

	Yup.

	-- Qing

---

From: "Li, Qing" <[email-masked]>
Date: Mon, 21 Mar 2005 15:04:58 -0800

> 
> I think we do. My position on things such as NAT and proxy 
> servers is based on having my fingers burnt a few times by, 
> more broadly, state in the network. I suppose I'm looking to 
> identify opportunities where, in the future, those problems 
> can be avoided, rather than them having to be remedied.
> I'm hoping that IPv6 will provide those opportunities. That's 
> why I'd like to discourage "legacy" IPv4 technologies in IPv6 
> if it is possible.
> 

    You are certainly right in that some proxy functions are 
    provided to circumvent the limitations in IPv4 deployment. 
    However, many proxy functions are developed for other good 
    reasons. I think classifying proxy servers in general as 
    "legacy" IPv4 technologies is something we should avoid. 

    For example, having a reverse proxy placed in front of a set
    of web servers hides the identities of those servers and
    can improve performance. Such a proxy would still be
    necessary in the IPv6 environment.

    -- Qing