Subject: better MNR or bypassing it

From: Pars Mutaf <[email-masked]>
Date: Fri, 09 Feb 2007 15:58:34 +0100

Dear all, 

Quick reminder: the problem that I'm bringing to your 
attention is:

http://www.ietf.org/internet-drafts/draft-mutaf-piqproblem-00.txt

Here is a better formulated question. We have choices (the above
cited application largely merits one of them):

1. IETF designs a more general purpose multicast name resolution 
   protocol. Thanks :-) 
   Currently it is too much ZEROCONF-oriented. There are possibly 
   many other applications that will use multicast name 
   resolution. The above cited example is a very good one. The 
   above cited problem is poorly addressed by current multicast 
   name resolution protocols. 

2. Otherwise, the above cited application (private information 
   queries) can simply bypass name resolution. It can use 
   name-based IPv6 addresses (or HUMID addresses). No solution 
   will be provided for IPv4. This solution would work as follows 
   (briefly):

   The responder application run by Alice Collins' cellular host 
   configures a link-local IPv6 address and listens:

         link-local subnet prefix | 64bithash(alicecollins)

   where '|' denotes concatenation, and link-local subnet prefix
   is well-known and constant. 64bithash(alicecollins) is the 
   IPv6 interface ID.

   The initiator user enters the name Alice Collins and hence the 
   application can generate a query to the above address. The 
   phone number of Alice Collins can be learned from her phone 
   directly (if approved by her).

   It is also possible to search a host in multiple subnets 
   (using global scope addresses). I can explain this point if 
   you wish. It can also work with localized mobility management 
   and even Mobile IPv6, provided that you have the same 
   home/regional prefix with Alice Collins. This means that we 
   are not limited to link-local scope. But this needs more
   investigation.

Looking forward to your suggestions.

Thanks,

pars mutaf

On Tue, 2007-01-30 at 23:22 +0100, Pars MUTAF wrote:

> I would like to bring a new problem statement draft to your
> attention (1 page). Until it appears in the I-D rep, please
> find it here:
> 
> http://www.freewebs.com/pmutaf/draft-mutaf-piqproblem-00.txt
> 
> I believe that not having this application
> would be very unfortunate. (I think this is an INT area topic.)
> And currently available name resolution techniques do not
> address this problem as they should.
> 
> Do you have any comments on this problem statement?
> 
> Thanks.
> pars mutaf

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 9 Feb 2007 14:52:44 -0500

> -----Original Message-----
> From: Pars Mutaf [mailto:[email-masked]] 
> Dear all, 
> 

Pars, it seems to me that the reason cell phone numbers are hard to get
is that cell phone users have long preferred it to remain that way. For
that matter, with sales people completely abusing the regular land line
phone system, I believe the majority of land line telephone subscribers
would have preferred that other phone system to be equally made
difficult to abuse.

So I don't think that making it easier to distribute cell phone
telephone numbers is something that technology is preventing.

In your proposal, for example, the problem will happen when obnoxious,
over the top sales critters (as they have proven themselves to be)
figure out how to pretend they are alicecollins making the request for
your phone number. Your will reply "yes," and then you're screwed.

Or, alternatively, an alicecollins is making this request, but the one
you really know is called alicejcollins. Now this unknown person has
your cell number.

In short, I don't think it is technology that is needed here.

Bert

---

From: Pars MUTAF <[email-masked]>
Date: Sun, 11 Feb 2007 12:01:55 +0100

Hello,

Thanks much for all good questions. Please see below:

Selon "Manfredi, Albert E" <[email-masked]>:

> is that cell phone users have long preferred it to remain that way.

I don't agree with you here. Cell phone users had no choice. They were and
still are subject to a fundamental trade-off between privacy and
reachability.

I have seen users, with broken cell phones, or who have lost their phone.
They are simply in trouble. They have hard time recovering the cell phone
numbers of their friends, colleagues, family members etc.

I have seen users (including myself) exchanging phone numbers in
ridiculous ways. The first number is read to the other user, and the other
user returns his/her number via the cellular network. It should be noted
that this also requires short distance user contact. If the other user is
100 meters away, you see each other but you are in a crowded place and you
can't reach each other, you simply cannot communicate. You have cellular
phones but are unable to communicate.

Or, just after a tsunami, someone that I know is lost. But I don't have
a cell phone (or lost it). I can borrow a phone from someone else but I
don't have the phone number.

Or simply, you need another user's phone number but you don't have it yet.
You know each other but you have not exchanged your phone numbers yet.

etc etc...

> For

This is an excellent point. Please see below.

> telephone numbers is something that technology is preventing.

The main requirement is that if you need private information about Alice,
you should ask Alice. Alice will decide in *real-time* (real-time is
really the keyword here). The decision belongs to Alice.

We have Bluetooth, IrDA etc, but they require user contact. Surprisingly
we cannot exchange private information via a cellular network (i.e. over
very large distances). I suspect that this is simply because we don't have
multicast name resolution or name-based IPv6 addresses currently (in
cellular context). Please take my last sentence seriously. I mean it.
These are the only solutions for learning someone's IP address from
his/her human name. And if you don't know Alice's device's IP address,
you cannot reach her phone and request her phone number.

I think this also answers a good question like: "If this protocol is that
important why we don't have it today?"... I think the answer is above.

> you really know is called alicejcollins. Now this unknown person has

These are very sane and important concerns. This protocol must be designed
carefully. My point is that, *today*, we *have* well-known security
solutions to achieve that. A serious threat analysis must be made and the
protocol must be designed accordingly. Some of the potential threats and
defenses (I'm not expert on details):

     1. For example, as you have very well identified, the requesting
        user's identity must be verifiable. If not, the responder user
        must be notified. Again, the decision belongs to the user.

     2. There will be Denial-of-Service threats if we use public key
        cryptography. Same problem with IKE. In our case, we have an
        advantage: the requestor is necessarily a *human*. Consequently,
        CAPTCHAs (Turing test) may be used. All we need to do is to define
        a CAPTCHA option in our exchanges. Work is needed of course.

        URL: http://en.wikipedia.org/wiki/Captcha

     3. The last threat that you identified above looks like "phishing"
        to me. We have this problem on the web. I suspect that there is
        ongoing work on that. But anyway, I don't think this is a
        compelling enough reason to STOP this project.

Also,
some users may augment their own level of security by using a pseudonym
instead of their real name, etc etc.

If phone number information leaks (not because of the proposed protocol),
some users may periodically change their phone number (i.e. recovation).
But again, in this case, they will need the proposed protocol to
redistribute their new phone number more easily.

These decisions belong to the user.

> In short, I don't think it is technology that is needed here.

I think technology is needed, and we *have* this technology and the
necessary expertise. All we need to do is to put the pieces together.

Regards,

pars mutaf

> Bert

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 11 Feb 2007 19:31:10 -0800

> I have seen users, with broken cell phones, or who have lost their
> phone. They are simply in trouble. They have hard time recovering the
cell
> phone numbers of their friends, colleagues, family members etc.

Do you mean that the only copy of their address book was inside their
cell phone? If that is the case, they will indeed have a hard time
retrieving all these numbers. On the other hand, there are many ways to
synchronize a cell phone with a PC or a server that keeps a safe copy.
You can even use vCards (RFC2426) do describe these entries in a
standardized way.

> ridiculous ways. The first number is read to the other user, and the
> other user returns his/her number via the cellular network. It should
be
> noted that this also requires short distance user contact. If the
other user
> is 100 meters away, you see each other but you are in a crowded place
and
> you can't reach each other, you simply cannot communicate. You have
> cellular phones but are unable to communicate.

That's ridiculous indeed, when you could simply attach vCard to an
e-mail. Not to mention publishing it in a web page, or make it available
to your friends in an instant-messaging service.

The problems that you describe hardly seem related to server-less name
resolution in a local network!

-- Christian Huitema

---

From: Pars Mutaf <[email-masked]>
Date: Mon, 12 Feb 2007 14:35:36 +0100

Hi, 

On Sun, 2007-02-11 at 19:31 -0800, Christian Huitema wrote:
> cell phone numbers of their friends, colleagues, family members etc.
> 

That's right of course. Users should backup their correspondents' phone 
numbers to their PCs. However, this doesn't mean that they will do it 
unfortunately.

In addition, this assumes that everyone has a PC. 

In addition, even if you have a PC and even if you have a backup, 
I'm not sure if the PC will be immediately available when you buy a 
new phone (because the old one is broken).

Finally, I have also seen users with broken PCs.

(This happened recently, a friend has lost all his backup.)

> > be noted that this also requires short distance user contact. If the
> > other user is 100 meters away, you see each other but you are in a 
> > crowded place and you can't reach each other, you simply cannot 
> > communicate. You have cellular phones but are unable to communicate.
> 

Sending the phone number via e-mail is possible indeed, but this 
is a too indirect (hence slow) solution and makes some important 
assumptions. 

1. This assumes that you have the destination user's e-mail 
   address. BTW, I also think that the proposed protocol is not 
   limited to phone numbers. We can also request an e-mail 
   address. 

2. This solution is too indirect in that, you need service from 
   e-mail servers, which may be busy, temporarily unreachable, 
   the network may be congested etc. 

3. You have to wait until the mail arrives at the target mail box 
   and the user checks mail. Today we have special services 
   that notify the user upon new incoming mail. However, I'm not 
   sure how fast this is. In addition, this is an optional 
   service. 

Using an instant-messaging service has similar (almost same)
problems. 

> resolution in a local network!

The proposed protocol could also use infrastracture DNS (i.e. 
standard DNS). This would look as follows:

Let us assume that Alice Collins has a personal DNS name
"alicecollins.domain.com". Her phone has an IP address that is 
registered to this DNS name.

The requestor user enters the name Alice Collins, the proposed
application generates the corresponding DNS name, makes a 
standard DNS query, and obtains the IP address. At this point the 
proposed application can send a private information query to 
Alice's phone. If approved by Alice (in real-time), her phone 
number can be learned.

This would work globally, but I don't think this is realistic. 
(BTW, it can be noted that, one would ask why I need a phone 
number in this case.)

Using multicast name resolution (or, name-based IPv6 addresses)
with human names that have local significance only, seem 
realistic to me. Here the term "local" may take different 
meanings. It may be a local cellular network that covers a large 
number of cells, or a localized mobility management domain.

Such a local cellular zone can cover a large geographical area.
This is an important progress compared to using a technology
like Bluetooth (for exchanging private info). But the proposed 
protocol cannot work globally. That's why we need phone numbers
and our goal is to allow people to share their phone numbers 
more easily.

Regards,

pars mutaf

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 14 Feb 2007 19:05:22 +0100

On Wed, 2007-02-14 at 16:43 +0100, Olaf M. Kolkman wrote:
> Hello Pars,
> A few thoughts...

Hello thanks.

> 
> On 12Feb 2007, at 2:35 PM, Pars Mutaf wrote:
> 
> So instead of having to remember Alice Collins' phone number you
have  
> to remember the domain name under which her
telephone-number-recovery- 
> services is located.

This is exact. That's why I have serious doubts about using 
infrastructure DNS and I am promoting MNR (or name-based local 
IPv6 addresses) as a general but local solution.

> > application generates the corresponding DNS name,
> 
> How does the proposed application do that unambiguously? Given that  
> the 'Alice Collins' you are looking for might be a completely  
> different "Alice Collins" than I know.  The namespace collision will  
> be a problem that you will need to solve.

Right. Please see below in the context of MNR.

> > makes a
> Indeed, that is the argument above.
> 
> >
> I think the main problem will be to find a balance between size of  
> your "locality" and the amount of collisions in your namespace. That  
> will be problematic, as an illustration: Travel to Volendam (a  
> village in the Netherlands), walk down the street, and shout "Hey  
> Piet Veerman" and count the amounts of angry faces.

OK. I probably won't do that if I go to Volendam :-)

The automated approach to human name collisions can use a 
collision counter. The user enters his/her human name at 
configuration time: "Piet Veerman". The application will try to 
configure pietveerman0, and if it collides, pietveerman1, 
pietveerman2, etc. The user doesn't have to know which Piet 
Veerman he is. Note that as users move, these numbers may
change. A good implementation should always look for the smallest 
possible collision count (but without being too aggresive). 

Then if you need the phone number of a particular Piet Veerman 
in that village, what happens? 

The application tries pietveerman0, if no answer, the user
pushes on the NEXT button, it tries the next one until you 
find the searched Piet Veerman. The number of trials is left 
to the user. If you receive more than one responses, you will 
choose the right Piet Veerman, or call all of them one-by-one 
(you will say "sorry wrong number", etc). 

Another potential problem with colliding names is that for 
each wrong Piet Veerman, the requesting user will 
unneccessarily solve a challenge e.g. a CAPTCHA or other
Turing tests.

That's life. We cannot do more than that for colliding
names (may be I'm wrong). Perhaps parents can use this
application to detect collisions and avoid a colliding 
name for their baby? ;-))

> With the problem you are describing the number of angry faces if  
> relevant. If I were to activate the feature on the phone that would  
> provide me with the "Do you want to provide your phone number to  
> <foo>" and I were to receive more than 2 false positive requests for  
> my phone number, I would turn of the feature. So if I were the
target  
> group solving the name collisions will be important.

Yes. If there are many many Piet Veermans in the same area, this
application may be less efficient for these persons. May be they
should use pseudonyms.

I prefer looking at the problem the following way: this would work 
very well i.e. without or with very few collisions for many many 
users. 

The problem to me is the need for an efficient multicast name
resolution protocol (or, bypassing it ;-)

Regards,

pars

> --Olaf
> 
> 
> -----------------------------------------------------------
> Olaf M. Kolkman
> NLnet Labs
> http://www.nlnetlabs.nl/
> 
> 
>

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 14 Feb 2007 20:05:36 +0100

> IPv6 addresses) as a general but local solution.

sorry. quick precision: 

I'm arguing that only a local solution is realistic because
users cannot possibly remember domain names (especially if there
are many of them). They can only remember "human names". In addition, 
there is no evidence that such special domains will exist.

Hence the local solution (discussed below). Within a cellular
local network, we can cover a large area and share our phone
numbers easily over long distances. This is much better than 
using Bluetooth (which requires short distance user contact). 
But I'm not pretending a global solution.

Thanks, 
pars

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 14 Feb 2007 17:21:21 -0500

> But I'm not pretending a global solution.

Pars, I'm not sure why a local-only solution is very helpful. The guy
across the room at a conference may well have a cell number from a
different country. If that case isn't included in this solution, I'm not
sure how attractive it is.

In any case, what makes this any different from people's e-mail address
book? E-mail addresses are global, and I guess most people do not keep
them in their heads either. They use address books, which are hopefully
backed up somewhere. Same goes for web sites in the favorites or
bookmarks folder. Easier with DNS than using IP addresses, but still not
easy enough.

I think the name collision issue is what makes these proposals
difficult.

Bert

---

From: Pars Mutaf <[email-masked]>
Date: Thu, 15 Feb 2007 11:02:36 +0100

On Wed, 2007-02-14 at 17:21 -0500, Manfredi, Albert E wrote:
> > are many of them). They can only remember "human names". In 
> > addition, there is no evidence that such special domains will exist.
> > 
> different country. If that case isn't included in this solution, I'm 
> not sure how attractive it is.

Hi Bert, 

Conference room is a too old an uninteresting example.

This is very attractive in the cellular context. For example, you 
buy a new phone, you are impatient to call someone you know (who 
lives in the area). But you don't have the phone number yet. You 
can even call that person for asking another person's phone number
(who is not here).

You don't think about all these possibilities today, simply 
because you assume that you cannot do it.

> bookmarks folder. Easier with DNS than using IP addresses, but still 
> not easy enough.

I'm not sure if you see the context I'm talking about. 

> I think the name collision issue is what makes these proposals

OK may be I'll stop talking as if I invented multicast DNS. 
Collisions are not my problem. I don't think they are a technical
problem. 

You are looking for John Smith, the phone will scan all John Smiths
in the local cellular network, and you will receive 'n' results. (My
proposal comes into play only after that.) 

If John Smith is a too much colliding name, this is John Smith's
problem. We cannot penalize many other users for that.

Are you arguing that this protocol is impossible and cellular 
users will never be able to do that?

Thanks,
pars