Subject: Re: ra-privacy: my responses to comments

From: Keith Moore <[email-masked]>
Date: Thu, 1 Aug 2013 14:31:30 +0200

On reflection I wanted to respond to this a bit more:

I was responding to slide 9, and in particular the bullet point that says "The node Should not use public addresses".

When I initially read this, I interpreted "public addresses" with the meaning that they tend to have in IPv4 - which is to say addresses that aren't "private addresses".   I wasn't sure what public addresses would mean for IPv6, since we have no private addresses in IPv6.   But we used to have something very similar to private addresses in IPv6 called site locals.   We deprecated them for good reasons, and my first impression of that slide was that it seemed to be advocating something like the concept of IPv4 private addresses in IPv6.   So that's why I spoke up.    

Hosnieh clarified the slide by explaining that by using "public addresses" she meant addresses resolvable from DNS lookups.   But then the idea that a node should not use "public addresses" is problematic for different reasons.  

There are many people (in IETF and elsewhere) who believe that applications should never use IP addresses directly or in referrals to other applications.   This is often cited as if it were some architectural principle - in fact just last night, I actually had an AD state that to me as if it were a principle.   I happen to disagree emphatically with that supposed principle, for many reasons, but I won't list those reasons here.   For the moment it only matters that there is a widely held belief that all applications should only use names to refer to hosts or application endpoints.   From that point-of-view, all hosts/nodes need to have names, so (by this definition) all hosts/nodes need to have public addresses.   And the people who believe that applications should always use names to refer to hosts or application endpoints have a lot of influence on network protocol design choices.   So a recommendation for hosts to only use addresses not listed in DNS can have the effect of making those hosts unable to support various applications.

Bottom line:  The decision about whether a node should use an address listed in DNS is not something that should be dictated entirely, or probably even mostly, by concerns about the privacy of addresses.    

I would also suggest that the privacy benefit from using addresses not listed in DNS is probably very small.   But in order to evaluate that benefit, it would help to identify specific threats to privacy that  are remedied by not using addresses listed in DNS.

Keith

On Jul 30, 2013, at 7:12 AM, Hosnieh Rafiee wrote:

> The term public addresses:
> @Keith Moore:
> Concerns: All IPv6 addresses are public addresses and should be available. Not chosen a good term.
>  
> I just obtained that term from from the mailing list. Check this old list : http://www.ietf.org/mail-archive/web/ipv6/current/msg17792.html
> A public address is one intended to be resolvable from higher-layer IDs such as DNS names.
> If this is wrong or I misunderstood the meaning , then I will change it to “DNS addresses” or another term.  
> What I knew before:
> Global addresses = Router prefix + IID
> Local Addresses = local prefix + IID
> What I understood:
> Public addresses = router prefix + IID  and has  DNS records (like a domain)
>

---

From: Scott Brim <[email-masked]>
Date: Thu, 1 Aug 2013 15:26:00 +0200

On 08/01/13 14:31, Keith Moore allegedly wrote:
> There are many people (in IETF and elsewhere) who believe that
> applications should never use IP addresses directly or in referrals to
> other applications.   This is often cited as if it were some
> architectural principle - in fact just last night, I actually had an AD
> state that to me as if it were a principle.   I happen to disagree
> emphatically with that supposed principle, for many reasons, but I won't
> list those reasons here.   

You may have to if you want to press your case.

> For the moment it only matters that there is
> a widely held belief that all applications should only use names to
> refer to hosts or application endpoints.   From that point-of-view, all
> hosts/nodes need to have names, so (by this definition) all hosts/nodes
> need to have public addresses.   

All sources of Internet public services need to have DNS names, but
that's it.  Other than that, "names" are only needed in higher layer
communications, and can be handled there.  For example, your laptop
doesn't need a name to open communication with a SIP server, but once it
does it can use one or more SIP-level identifiers for its end of the
SIP-level communication.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 1 Aug 2013 15:47:09 +0200

Many thanks for your comments.

> > For the moment it only matters that there is a widely held belief that
> > all applications should only use names to
> All sources of Internet public services need to have DNS names, but that's
it.
> Other than that, "names" are only needed in higher layer communications,
and
> can be handled there.  For example, your laptop doesn't need a name to
open
> communication with a SIP server, but once it does it can use one or more
SIP-
> level identifiers for its end of the SIP-level communication.

That is the actual case. I assume that the node who are clients would use
Privacy Extension RFC. I do not think you use it for your servers.  This is
why I said that nodes who wants to have privacy should not have "DNS names"
or addresses that are defined in DNS but if they want to have they MUST not
generate it based on MAC address. 
Of course it is "should" and not 'must". However, if you have wording issue,
I can change it to "Might".

Thanks,
Best,
Hosnieh

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 Aug 2013 16:09:43 +0200

On Aug 1, 2013, at 3:47 PM, Hosnieh Rafiee wrote:

>> All sources of Internet public services need to have DNS names, but that's it.
>> Other than that, "names" are only needed in higher layer communications, and
>> can be handled there.  For example, your laptop doesn't need a name to open
>> communication with a SIP server, but once it does it can use one or more SIP-
> Privacy Extension RFC. I do not think you use it for your servers.  

I do not think it is appropriate to assume that nodes are either clients or servers.    Nodes can (and routinely do) support several applications in which the local protocol engine acts as a client, a server, or a peer, depending on the needs of each application.

> This is

I recommend removing the text, or replacing it with something like "The choice of whether to list a node's address in DNS properly depends on many factors, including the set of applications to be run on the host.   Not listing a node's address in the public DNS may increase the node's privacy, but may also impair its ability to support certain applications."

Keith

---

From: Scott Brim <[email-masked]>
Date: Thu, 1 Aug 2013 16:17:28 +0200

On 08/01/13 16:09, Keith Moore allegedly wrote:
> I do not think it is appropriate to assume that nodes are either clients
> or servers.    Nodes can (and routinely do) support several applications
> in which the local protocol engine acts as a client, a server, or a
> peer, depending on the needs of each application.

"sources of Internet public services".  They may also be clients of
public services but that's orthogonal.  "peer" is also a nit - if you
want an unknown someone to be able to contact you, you need to make
yourself findable, whether the protocol design is p2p or not.  Otherwise
you don't.

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 Aug 2013 16:21:17 +0200

> yourself findable, whether the protocol design is p2p or not.  Otherwise

I don't think we're disagreeing here.

Keith

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 1 Aug 2013 18:32:35 +0200

Thanks a lot for your comments. They were actually quite helpful and made
some good points. Here are my answers:

>There are many people (in IETF and elsewhere) who believe that applications
should never use IP addresses directly or in referrals to Other
applications.   This is often cited as if it were >some architectural
principle - in fact just last night, I actually had an AD state that to me
as if it were a principle.   I happen to disagree emphatically with that
supposed principle, for many >reasons, but I won't list those reasons here.
For the moment it only matters that there is a widely held belief that all
applications should only use names to refer to hosts or application
>endpoints.   From that point-of-view, all hosts/nodes need to have names,
so (by this definition) all hosts/nodes need to have public addresses.   And
the people who believe that applications >should always use names to refer
to hosts or application endpoints have a lot of influence on network
protocol design choices.   So a recommendation for hosts to only use
addresses not >listed in DNS can have the effect of making those hosts
unable to support various applications.

I imagine the name that you want to be publicly available is different than
the names that you use it in local link for some applications. Right?  

>Bottom line:  The decision about whether a node should use an address
listed in DNS is not something that should be dictated entirely, or probably
even mostly, by concerns about the privacy of addresses.    

This is actually what I tried to explained in the draft but not very
successfully. I will have to use different wording in addressing this
problem and not convey the meaning that one is forced to do as explained in
draft but explain the repercussions that could ensue if one doesn't follow
the advice given in the draft.

>I would also suggest that the privacy benefit from using addresses not
listed in DNS is probably very small.   But in order to evaluate that
benefit, it would help to identify specific threats to >privacy that  are
remedied by not using addresses listed in DNS.

It is not small. If you ask the DNS guys (or probably you are one of them?),
they will tell you that nowadays the types of attacks against DNS have
changed.
The attackers now use DNS as a tool with which to attack other nodes on the
network.
One such attack is node scanning, which is not feasible in the traditional
way with IPv6. This is because, as you know, there are 2^64 addresses in
each subnet.
One might use DNS to find the IP address of other nodes in a target network.
As I said during my talk, we implemented this attack using DNS. We obtained
a lot of names all of which resided in public DNS servers. Even with the use
of security this would not be prevented, but the chances of this type of
attack being perpetrated would be diminished. 
If you are interested,  you can download the attacking tool that we used
from our website (easily search ipv6ssl and hpi). It is publicly
available.It is not an optimized tool as our purpose was for research. We
will upload a more optimized version soon. 

Thanks,
Best,
Hosnieh

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Aug 2013 08:26:21 +1200

> You may have to if you want to press your case.

Some of Keith's arguments on this point were captured in
draft-carpenter-behave-referral-object-01, but that draft also
contains the statement:

"  In some cases, this problem may be readily solved by passing a Fully
   Qualified Domain Name (FQDN) instead of an IP address.  Indeed, that
   is an architecturally preferred solution [RFC1958]. "

That's indeed what RFC 1958 says.

> does it can use one or more SIP-level identifiers for its end of the

It can, but applications can get into trouble for a whole lot of reasons
discussed in the above draft and its successors (draft-carpenter-grobj-reqts
and draft-carpenter-referral-ps).

   Brian

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 1 Aug 2013 22:42:58 +0200

Thanks,
Best,
Hosnieh

---

From: Keith Moore <[email-masked]>
Date: Thu, 1 Aug 2013 22:51:35 +0200

I do think it might be useful to recommend that DNS servers be configured as to refuse requests to list DNS zones as a means to thwart attackers from looking for IPv6 addresses.   But assuming that such listing is disabled, I don't know why listing a host's address in DNS would make that host a more likely target for attack.  In other words, why is DNS name probing any more feasible of an attack than IPv6 address probing?

Keith

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 1 Aug 2013 23:26:21 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott
> Brim

> "peer" is also a nit - if you

I also object to the notion that every host or application should be identified by name and not by address. In a peer to peer network, the peers can certainly have the other peers' IP addresses known to them. You don't need a DNS at all, in situations like this.

Matter of fact, I would suggest that the Client Identifier Option of DHCP is precisely for such scenarios. Where the unconfigured peer needs to be given a specific IP address, because that's the only way the other peers can find it.

Bert

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 01 Aug 2013 18:01:24 +0200

On 8/1/13 2:31 PM, Keith Moore wrote:

> Hosnieh clarified the slide by explaining that by using "public
> addresses" she meant addresses resolvable from DNS lookups.   But then
> the idea that a node should not use "public addresses" is problematic
> for different reasons.

Keith,

 From a terminology perspective we have RFC 4941 defining temporary 
addresses, but that document doesn't provide a term for the 
non-temporary addresses. 4941 does have some text saying
	a "public" (i.e., non-secret) server address, registered
         in the DNS
FWIW RFC 5014 consistently uses "public" to refer to "not temporary".

> other applications.

I don't think there is any particular assumption about the role of the 
DNS (or other registries like SIP proxies) versus IP addresses in 
referrals in this work.

Instead this work is using the terms the same way that RFC 5014 does.

Regards,
    Erik

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 2 Aug 2013 10:37:48 +0200

Hi,

Thanks for your comments. 
> > yourself findable, whether the protocol design is p2p or not.
> > Otherwise you don't.
> 
> I also object to the notion that every host or application should be
identified by
> name and not by address. In a peer to peer network, the peers can
certainly
> have the other peers' IP addresses known to them. You don't need a DNS at
all,
> in situations like this.
> 
> Matter of fact, I would suggest that the Client Identifier Option of DHCP
is
> precisely for such scenarios. Where the unconfigured peer needs to be
given a
> specific IP address, because that's the only way the other peers can find
it.

DHCPv6 is another approach to generate an IID. So, the choice of using DNS
name is out of scope of ra-privacy document.  In ra-privacy draft, we
explained that having a DNS names (not local names)/ public names would have
a negative effect on user's privacy. This is why, the node "should" not have
public addresses(that has public DNS names) if it cares about privacy. But
also we explained that if a node wants to have public addresses, it "must"
not generate it based on MAC..[..].
Our reason: you usually don't have public DNS names for your clients and you
usually use it for your host.
Some says that you should not separate the type of nodes (clients or
servers...) and so you should not use "should" for this case. So, I agreed
that I can use "recommended" or "might" and then explain the circumstances
of having public DNS names.

Thanks,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 2 Aug 2013 10:59:41 +0200

Hi,
Again Thanks for your comments.

> I do think it might be useful to recommend that DNS servers be configured
as to
> refuse requests to list DNS zones as a means to thwart attackers from
looking
> for IPv6 addresses.   But assuming that such listing is disabled, I don't
know why
> listing a host's address in DNS would make that host a more likely target
for
> attack.  In other words, why is DNS name probing any more feasible of an
> attack than IPv6 address probing?

To do brute force scanning, you need to do brute force attacks against  2^64
addresses which might take years! If you are in the same LAN or can
eavesdrops ICMPv6 messages exchanged among nodes or send ICMPv6 messages,
then you can also find nodes. But if you are not access to these
capabilities, the best next option is guessing and using DNS servers. If DNS
is not secure then you can spoof the source IP address of the legitimate DNS
server and ask for axfr. If it is secure then there are other ways to attack
DNS server and obtain nodes that I explained in my other message. 
There is other way also to have a website that use it as a honey pot in
order to store IP addresses of nodes. However, it might not occurrence
because of NAT and many other reasons.

Thanks,
Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 2 Aug 2013 11:44:14 +0200

Hi,
Thank you so much.

>I recommend removing the text, or replacing it with something like "The
choice of whether to list a node's address in DNS properly depends on many
factors, including the set of >applications to be run on the host.   Not
listing a node's address in the public DNS may increase the node's privacy,
but may also impair its ability to support certain applications."

Ok. Thanks.

Best,
Hosnieh

---

From: Doug Barton <[email-masked]>
Date: Fri, 02 Aug 2013 10:05:45 -0700

> FWIW RFC 5014 consistently uses "public" to refer to "not temporary".

I'm not sure the conclusions you're drawing are valid there. The 3 
commonly accepted categories are SLAAC, static, and 4941/temporary. The 
fact that an address may or may not be published in the DNS is 
orthogonal to the type of address.

Doug