[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
unmanaged scope comments (fwd)
I was a bit frustrated to note that my earlier comments on unmaneval-00
weren't replied to, or taken into account in -01.
One of the biggest issues is that there seems to an assumption that
unmanaged networks always employ (from ISP and/or internally) NAT. That
restricts the applicability unnecessarily.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
---------- Forwarded message ----------
Date: Thu, 19 Sep 2002 18:34:23 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: unmanaged scope comments
Larger issues:
1) Especially for case A and C. I think there needs to be a clearer
characterization of (IPv4) connectivity and addresses, like (this has all
cases I think -- it could be simplified):
1. global addresses
a) dynamic
- enough addresses for every node
- only one
b) static
- ^
- ^
2. private addresses: NAT by ISP (or outside of your control) [otherwise
one of cases above]
- dynamic
- static
2)
4 Application requirements of an IPv6 unmanaged network
The application requirements are expressed in mostly three
dimensions: connectivity, naming, and security. Connectivity issues
include the provision of IPv6 addresses and their quality: do host
need a global scope address, should this address be stable, or more
precisely what should be the expected lifetime of the address.
==> connectivity includes one very important component IMO: the quality of
network connections. This is often ignored. It's a high risk for a vendor
to enable IPv6 by default, for example, if that'd result in lower quality
connections to e.g. dual-stack web servers (a very real fact in 6bone), this
should be taken into consideration at least in the short term.
3)
4.2 Requirements of client applications
[...]
maintaining the privacy of the client. Many potential users of IPv6
observe that the current NAT configuration provides some level of
privacy: all communications to outside servers appear to come from
the single IPv4 address of the NAT; the source IPv4 address does not
identify a specific host inside the unmanaged network ..
==> .. or even a specific host in the ISP. IMO it's usually a non-issue,
particularly in unmanaged case, whether someone can identify which node in
a sparsely populated subnet is which.
4) Triggered by sect 4.3 and 4.4, but it's more generic than that; I think
the draft needs to consider differences wrt. static/dynamic
addresses/prefixes. In particular, privacy, server address and generally
DNS issues come to mind.
5)
The case where the ISP is IPv6 capable, but the gateway is not is
similar to case A.
5.1 Case A, host deployment of IPv6 applications
In this case the gateway doesn't provide IPv6; the ISP may or may
not provide IPv6, but this is not relevant, since the non-upgraded
gateway would prevent the hosts from using the ISP service. Some
hosts will try to get IPv6 connectivity, in order to run
applications that require IPv6, or work better with IPv6.
==> This is not true I think: for example, even if gateway runs v4 private
addresses, ISP could provide e.g. internal tunnel service or something like
ISATAP to their v6-enabled network.
==> Do you refer to *layer 3* gateway? (Otherwise, this gets simpler with
e.g. bridged ATM encapsulation in xDSL).
6)
5.1.1 Application support in Case A
Server applications are also not a primary focus of Case A. Server
applications require DNS support, which is difficult to engineer for
clients located behind a NAT. Besides, server applications, at this
stage, cater mostly to IPv4 clients; putting up an IPv6 only server
is not very attractive.
==> I'm not quite sure how DNS support is difficult to engineer; this
probably has an unstated assumption that the address behind NAT would change
too often to be really updateable or writable in DNS. This does not need to
be the case.
==> In case A, clients don't necessarily need to be behind a NAT.
7) backward/upward compatibility; I brought this up in the interim meeting.
IMO I don't see it as a hard requirement to be able to be able to perform
v4only <-> v6only conversions. This depends quite a bit on what our "dual
stack" deployment strategy is: whether we encourage vendors (e.g. LCNA type
applications) to ship v6-only stacks or dual-stacks.
8) A comment:
-- I think that there is a case to be made that using translation
tools boosts the previously mentioned network effect and makes it
work in our favor; the somewhat crippled nature of the translation
tools is in fact also a good thing, because it gives people an
incentive to throw them away once they realize that they are broken.
I realize that this is heresy, so be it. --
==> No I don't agree with the last statement: this gives folks only an
incentive to enhance and tweak these features, not fix them *properly*.
Think NAT ALGs...
Semi-editorial:
nat/firewall with that name. Since updating DNS is a management
task, it somewhat falls outside the scope of an unmanaged network.
==> management, yes, but it's often automatic.
A peer to peer session typically starts by
an exchange of synchronization messages through the rendezvous
servers, during which the peers exchange the addresses that will be
used for the session.
==> not knowing better these protocols, I'm only guessing, but some of these
messages could be done e.g. to initiate NAT, and thus be at least partially
unnecessary with IPv6.
There are multiple aspects to the security of peer-to-peer
applications, many of which relate to the security of the rendezvous
system.
==> I'm not sure which threats you refer to; the one I can think of is some
kind of information disclosure. But I'm more afraid of the (programming)
security of p2p apps myself.
4.4 Requirements of server applications
The DNS entries for the server will have to be updated, preferably
in real time, if the server's address changes. In practice, updating
the DNS is slow, which implies that server applications will have a
==> The slowness of DNS is debatable, I think. TTL can be tuned if
necessary.
The security of server applications depends mostly on the
correctness of the server, and also on the absence of collateral
effects: many incidents occur when the opening of a server on the
Internet inadvertently enables remote access to some other services
on the same host.
==> s/host/node/
==> not necessarily only the same node, even on the same local network
==> does 'correctness of the server' refer to the server application?
5.1.3 Naming services in Case A
At this phase of IPv6 deployment, hosts in the unmanaged domain have
access to DNS services over IPv4, through the existing gateway. DNS
resolvers are supposed to serve AAAA records, even if they only
implement IPv4; the local hosts should thus be able to obtain the
IPv6 addresses of IPv6 only servers.
==> s/are supposed to//
==> s/should thus be/are/ (are these really worth the conditionals..)
presence of translation or port mapping services; there is also not
much of a case for letting local IPv4 servers publish their service
on the IPv6 Internet.
==> I agree! These should be dual-stacked if they're important.
To enable this scenario, the gateway need to use a mechanism obtain
a global address prefix from the ISP, and advertise this address
prefix to the hosts in the unmanaged network; several solutions will
be assessed in a companion memo [EVAL].
==> and in the degenate case...?
5.2.3 Naming services in Case B
[...]. Currently, IPv4 only hosts
discover the IPv4 address of the local DNS server using DHCP; there
must be a way for IPv6 only hosts to discover the IPv6 address of
the DNS server.
==> s/discover/usually discover/
Generic issue: I think that perhaps case B and case C could be reversed; I
find it more probable that ISP is the last party of the three to offer v6
service.
5.3.2 Addresses and connectivity in Case C
There are two ways to bring immediate IPv6 connectivity on top of an
IPv4 only infrastructure: automatic tunnels provided by the [6TO4]
technology, or configured tunnels. Both technologies have advantages
and limitations, which will be studied in a companion document.
==> + mechanisms if gateway does not have global addresses.
5.4 Case D, ISP stops providing native IPv4 connectivity
In this case the ISP is IPv6-only, so the gateway looses IPv4
connectivity, and is faced with an IPv6-only service provider. The
gateway itself is dual stack, and the unmanaged network includes
IPv4 only, IPv6 only and dual stack hosts.
==> no IPv4 connectivity to the customer, or no v4 at all (e.g. no
possibility for ALG's, web caches, DNS / SMTP servers etc.). Probably the
former.
Editorial:
s/IPv6 only/IPv6-only/ ?
s/IPv4 only/IPv4-only/ ?
2 Topology
(ISP)connection. Several hosts are connected to the subnet:
==> s/are/may be/
or may not perform NAT and firewall function. A key point of this
==> s/function/functions/
3.2 Client applications
network and a server at a remote location. A typical example is
accessing a web server from a client inside the managed network, or
reading and sending e-mail with the help of a server outside the
managed network.
==> s/managed/unmanaged/g (whoops.. :-)
3.3 Peer-to-peer applications
There are two kinds of peer-to-peer applications, the "local peer-
to-peer" that only involve hosts on the unmanaged network, and the
s/on the unmanaged network/in the unmanaged network/ (lots of other places;
I'm not sure which one is correct, but 'in' sounds better to my ear at
least)
well identified peers outside the unmanaged network. These
==> s/well identified/well-identified/ ?
applications are often facilitated by a server outside the managed
networks. Examples of a peer-to-peer application would be a video-
==> s/managed/unmanaged/ (whoops :-)
==> s/networks/network/
3.4 Server applications
==> I think the order should be changed: Server before Peer-to-peer, as peer
to peer is IMO the most generic case.
requires
some special programming of the NAT or firewall. When the NAT only
publishes a small number of global IP addresses and relies on "port
==> s/requires/require/
==> s/publishes/maps to/ (or something else, publishes sounds funny)?
nat/firewall with that name. Since updating DNS is a management
task, it somewhat falls outside the scope of an unmanaged network.
==> s/nat/NAT/
4.2 Requirements of client applications
An important security issues with client applications is,
==> s/issues/issue/
==> s/is,/is/
4.3 Requirements of peer-to-peer applications
Peer-to-peer applications require global connectivity. In an IPv6
network, we would expect the peers to use a global IPv6 address,
which will have to remain stable for the duration of the peer-to-
peer between client and server.
==> s/peer/peer session/
==> "client and server" is a bit funny wording in P-2-P case.. :-)
to deploy, and light weight; it will have to involve tunneling over
==> s/light weight/light-weight/ (not sure..?)
5.2.1 Application support in Case B
We expect the unmanaged network to include three kinds of hosts:
IPv4 only, IPv6 only, and dual stack.
==> soften the wording a bit: not every unmanaged network need to include
all three.
IPv4 only hosts use the services a brand new IPv6 only printer.
==> s/services/services, like/
To enable this scenario, the gateway need to use a mechanism obtain
==> s/need/needs/, s/obtain/to obtain/
not. The gateway has been upgraded and offers both IPv4 and IPv6
connectivity the hosts. It cannot rely on the ISP for IPv6
==> s/connectivity/connectivity to/
connectivity, because the ISP does not offer ISP connectivity yet.
==> s/offer ISP/offer IPv6/
representation of the IPv4 address of the server, either by sing a
==> s/sing/using/
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords