comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt

On Wed, 22 Sep 2004 Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
> 
> 	Title		: Privacy Extensions for Stateless Address 
> 			  Autoconfiguration in IPv6
> 	Author(s)	: T. Narten, et al.
> 	Filename	: draft-ietf-ipv6-privacy-addrs-v2-00.txt
> 	Pages		: 26
> 	Date		: 2004-9-23

FWIW, I think we should make the specification agnostic of the hash
algorithm.  Either MD5 and SHA1 or whatever is just fine.  There is no
interoperability problem because I don't see a need to be able to
reverse the hashes, and it's just an implementation's internal matter.

I guess this is intended for Draft Standard (based on the charter 
page), but there are a few issues which need to be nailed down first 
(e.g., about the normative refs to lower maturity specs).

substantial
-----------

1) 

The document goes at great depth to discuss the scenarios and justification
for privacy addresses, but I don't think the document produces a concise
problem statement (like one paragraph of less than 5 sentences) or
description about the scenarios or the threat model.  The factoids are
dribbled through section 2 but it might make sense to try to collect the
important bits together and try to coin up a nice and neat description of
the problem that's being fixed.

For example, one should take note of the following:
 - what is the observation point? (e.g., first paragraph of 2.1 takes IMHO
bad example of sniffing the traffic might be better removed or reworded)
 - what is the assumption about the (in)stability of the prefix to the
effects of privacy addresses?
 - how does this effect stationary nodes?  nomadic nodes?

Also, security considerations talks about ingress filtering, but
doesn't really talk about the main meat of
draft-dupont-ipv6-rfc3041harmful-XX.txt, that is, why privacy
addresses give privacy only with certain assumptions about the
dynamicity (or not) of the used prefixes.  This should go in as a
paragraph of its own in security considerations after the above is
clear.

2) the document also goes on at least in 3 different places to list
issues with reverse lookups and such.  Is this really necessary?  I'm
not objecting strongly, but there have been arguments that rather than
fiddling with protocols, one should consider fixing the broken
applications.  This is also discussed in draft-ietf-dnsop-ipv6-issues
(as are the issues with DDNS), so it might be worth referring to that
informatively from here.

3) DNA is referred to in section 3.5, unfortunately I think (at least with
the current wording) this would need to be a normative reference because
it's required for implementation of this spec.  And normative refs must be
at least the same maturity level of this spec, and this may pose a problem. 
A few possibilities which might solve this problem:
 - describe DNA just as one alternative to note whether the link change has
occurred, and possibly detail some others as well
 - just wait for DNA spec, and keep this as proposed standard
 - remove (some of) the specification about link changes, e.g., just saying
that for wired interfaces plug in/out and wireless interfaces the interface
restart could be the events -- no need for DNA then.

semi-substantial
----------------

 ==> the draft talks a lot about 'global scope addresses',
but I don't think is really accurate.  The privacy address practices could
be applied to site-local or ULA addresses as well, it's just a matter of
local policy.  RFC2462bis might provide some ideas how to express
'non-link-local' in a better way.

On the other hand, I see benefit in restricting the scope of privacy
addresses to just global scope addresses, but then you have to define
those somehow and that may be tricky.. because ULA addresses, by some
terminology, are also global scope..

   Not all nodes and interfaces contain IEEE identifiers.  In such
   cases, an interface identifier is generated through some other means
   (e.g., at random), and the resultant interface identifier is not
   globally unique and may also change over time.

==> 'globally unique interface identifier' is a rather absolute
statement and may not actually be accurate because it has happened
that identifiers have been duplicated.  Maybe soften the tone a bit.
(also see the robert elz appeal on addrarch and unique/local bits.)

  A more troubling case concerns mobile devices (e.g., laptops, PDAs,
   etc.) that move topologically within the Internet.  Whenever they
   move (in the absence of technology such as mobile IP [MOBILEIP]),
   they form new addresses for their current topological point of
   attachment.

==> the document mentions Mobile IP, but this doesn't actually matter much,
depending on the actual problem statement.  Remember, unless the mobile node
would *only* do bidirectional tunneling back to the home agent, every node
the MN talks to will know the care-of address in any case, which seems equal
in privacy considerations to just laptop moving without mobile IP.

Mobile IP is actually relatively incompatible with privacy addresses 
as the home address probably acts as a stable identifier, nullifying 
the effect of using privacy addresses for care-of address if you do 
route optimization.  This could maybe be discussed in security 
considerations.  A workaround is having multiple home addresses 
(rfc3041 ones), but I don't recall if that's supported or not, and 
even then, you reveal the stable prefix as the identifier.

   One way to avoid some of the problems discussed above is to use DHCP
   for obtaining addresses.  With DHCP, the DHCP server could arrange to
   hand out addresses that change over time.

==> 'change over time' seems relative.  The key point here is that DHCP
should not provide the addresses with (similar) stable identifiers.  Looking
at current or planned DHCPv6 deployments, at least some are using (AFAIR)
DHCPv6 to give the hosts the same addresses they'd get with stateless
address autoconfiguration, including EUI64.  Obviously, such would likely
not change sufficiently often, and would include the stable identifier.

How I see it, the document seems slightly too forthcoming with
proposing DHCPv6 as a solution for privacy here, but that only works
if DHCPv6 gives temporary addresses without the stable identifiers,
and rotates even those non-identifying addresses in a regular basis
("strict pool").  But that seems unnecessary complexity, because there
is no need (no address shortage) to do that with IPv6.  So, I don't
why anyone would use DHCPv6 to avoid this problem rather than privacy
addresses.

   4.  By default, generate a set of addresses from the same
       (randomized) interface identifier, one address for each prefix
       for which a global address has been generated via stateless
       address autoconfiguration.  Using the same interface identifier
       to generate a set of temporary addresses reduces the number of IP
       multicast groups a host must join.  Nodes join the solicited-node
       multicast address for each unicast address they support, and
       solicited-node addresses are dependent only on the low-order bits
       of the corresponding address.  This default behaviour was made to
       address the concern that a node that joins a large number of
       multicast groups may be required to put its interface into
       promiscuous mode, resulting in possible reduced performance.

==> what you seem to be saying, in a rather complex way in these
steps, that a random address is generated for each received prefix
[regardless of interfaces].  Wouldn't there a simpler way to specify
that ?

      A node highly concerned about privacy MAY use different interface
       identifiers on different prefixes, resulting in a set of global
       addresses that cannot be easily tied to each other.  This may be
       useful, for example, to a mobile node using multiple wireless
       interfaces to connect to multiple independent networks.

==> I think the example is flawed, or I don't understand this concern.  
Multiple wireless interfaces have their own MAC addresses, and
multiple independent networks have their own prefixes.  If you connect
using interface 1 to network 1 and interface 2 to network 2, there is
no way to connect the privacy addresses derived from them.  Rather, if
you use interface 1 to connect to networks 1,2,..,N, you're
identifiable, but this is then again the the regular roaming scenario
and requires no special considerations...

As it is, there's nothing in the spec that would propose that a
multi-interface node could pick one of its identifiers and use it as a
basis for privacy address generation on all of its interfaces.  As I
read it, for every physical interface, the 'seed' must be different.

...

       B.
           +  If the received Valid Lifetime is greater than 2 hours
              update the lifetime of the temporary address to the
              received lifetime.
           +  If the RemainingLifetime of the temporary address is less
              than or equal to 2 hours ignore the received option.
           +  Otherwise set the valid lifetime to 2 hours.
       C.  These steps are necessary to prevent a denial of service
           attack where a bogus advertisement contains prefixes with
           very small Valid Lifetimes

==> isn't this fundamentally duplication of specification from rfc2462
checks ?  Couldn't you just specify that the lifetimes are checked as
specified in section X.X.X.y of rfc2462 ?

   6.  The node MUST Perform duplicate address detection (DAD) on the
       generated temporary address.  If DAD indicates the address is
       already in use, the node MUST generate a new randomized interface
       identifier as described in Section 3.2 above, and repeat the
       previous steps as appropriate up to 5 times.  If after 5
       consecutive attempts no non-unique address was generated,

==> 5 times seems like really a strech.  Couldn't we lower that down
to, say, 3 times?  That would still be sufficiently many repetitions,
but lower the unnecessary delay and attempts significantly in case
there are problems.

  When a temporary address becomes deprecated, a new one MUST be
   generated.  This is done by repeating the actions described in
   Section 3.3, starting at step 3).  Note that, except for the
   transient period when a temporary address is being regenerated, in
   normal operation at most one temporary address corresponding to a
   public address should be in a non-deprecated state at any given time.

==> I'm flinching back at the 'corresponding' language.  The
implementation shouldn't need to keep track of public -> private
address mappings, and if it does, this should be made more explicit.  
Instead, it may need to track prefixes, and possibly interfaces (or
interface-identifiers).

  If a very small number of nodes(say only one) use a given prefix for
   extended   periods of time, just changing the interface identifier
   part of the prefix  may not be sufficient to ensure privacy, since
   the prefix acts as a constant identifier.

==> i'd rather say s/may not be/is not/, because there's nothing conditional
(IMHO) about it.

10  References

==> needs to be broken down to informative and normative.  It's not clear
whether this is intended for PS or DS, but if DS, normative refs must only
include those specs which are of DS of BCP; if PS, PS is also OK.

editorial
---------

2.2  Address Usage in IPv4 Today

   Addresses used in today's Internet are often non-changing in practice
   for extended periods of time, especially in non-home environments
   (e.g., corporations, campuses, etc.).

==> it's not so much 'home' environments as such but whether the ISP has
assigned a static (or gives de-facto static) addresses.  This is obviously
mostly an issue at home, but could maybe be a bit more general in the text.

   A more interesting case concerns always-on connections (e.g., cable
   modems, ISDN, DSL, etc.) that result in a home site using the same
   address for extended periods of time.  This is a scenario that is
   just starting to become common in IPv4 and promises to become more of
   a concern as always-on internet connectivity becomes widely
   available.  Although it might appear that changing an address
   regularly in such environments would be desirable to lessen privacy
   concerns, it should be noted that the network prefix portion of an
   address also serves as a constant identifier.  All nodes at (say) a
   home, would have the same network prefix, which identifies the
   topological location of those nodes.  This has implications for
   privacy, though not at the same granularity as the concern that this
   document addresses.  Specifically, all nodes within a home would be
   grouped together for the purposes of collecting information.  This
   issue is difficult to address, because the routing prefix part of an
   address contains topology information and cannot contain arbitrary
   values.

==> while the topic was 'Address Usage in IPv4 today', the text jumps in the
middle to describe v6 considerations (about the prefix portion).  Maybe this
needs to go somewhere else, or at least broken down more explicitly (e.g.,
to a different paragraph).

  Finally, this document assumes that when a node initiates outgoing
   communication, temporary addresses can be given preference over
   public addresses, when the device is configured to do so.  This is
   consistent with on-going work that addresses the topic of
   source-address selection in the more general case [ADDR_SELECT]

==> on-going work no longer...

   applications are used by end users.  Thus, the default value given of
   one week (TEMP_VALID_LIFETIME) may not be appropriate in all

==> s/default value given/given default value/

   temporary addresses in order to simply network debugging and

==> s/simply/simplify/

   An implementation might want to keep track of which addresses are
   being used by upper layers so as to be able to remove a deprecated
   temporary address from internal data structures once no upper layer
   protocols are using it (but not before). [...]

==> this issue seems to be discussed in nearly the same fashion in two
different places in the draft.  Could this just be summarized in one, and
described in full in the other, or something?

8.  Security Considerations

   Ingress filtering is being deployed as a means of preventing the use
   of spoofed source addresses in Distributed Denial of Service(DDoS)
   attacks. 

==> s/is being/has been/ ?

  legitimately changing temporary addresses and spoofed source
   addresses which "in-prefix"(They use a topologically correct prefix
   and non-existent interface ID).  This can be addressed by using

==> s/which/which are/, add space after "

  [ADDRARCH]
              Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

==> 3513

   [MOBILEIP]
              Perkins, C., "IP Mobility Support", RFC 2002, October
              1996.

==> rather use 3775.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------