Re: [humanresolv] Tentative problem statement

Alexandru Petrescu <> Fri, 26 October 2007 15:59 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IlRah-0006KR-C0; Fri, 26 Oct 2007 11:59:19 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IlRag-0006Jz-Db for; Fri, 26 Oct 2007 11:59:18 -0400
Received: from ([]) by with smtp (Exim 4.43) id 1IlRaf-0006wP-PX for; Fri, 26 Oct 2007 11:59:18 -0400
X-VirusChecked: Checked
X-StarScan-Version:; banners=.,-,-
X-Originating-IP: []
Received: (qmail 12499 invoked from network); 26 Oct 2007 15:59:15 -0000
Received: from (HELO ( by with SMTP; 26 Oct 2007 15:59:15 -0000
Received: from ( []) by (8.12.11/Motorola) with ESMTP id l9QFxE3O024857; Fri, 26 Oct 2007 08:59:15 -0700 (MST)
Received: from ( []) by (8.13.1/Vontu) with SMTP id l9QFxEH5007409; Fri, 26 Oct 2007 10:59:14 -0500 (CDT)
Received: from [] ( []) by (8.13.1/8.13.0) with ESMTP id l9QFxD2B007371; Fri, 26 Oct 2007 10:59:13 -0500 (CDT)
Message-ID: <>
Date: Fri, 26 Oct 2007 17:59:09 +0200
From: Alexandru Petrescu <>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Pars Mutaf <>
Subject: Re: [humanresolv] Tentative problem statement
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 071025-1, 25/10/2007), Outbound message
X-Antivirus-Status: Clean
X-CFilter-Loop: Reflected
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pairing cellular hosts <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Pars Mutaf wrote:
> Hello, Please find below a tentative problem statement, comments are 
> welcome. pars
> IP host pairing problem statement
> Today, cell phone numbers are not published in a phonebook for 
> avoiding telemarketers, prank callers, Spam and SPIT (SPam over 
> Internet Telephony). Users today exchange their phone numbers upon 
> user contact, often through oral communication.
> In IP telephony, users will need a user friendly "pairing" protocol 
> that identifies the two phones and let them exchange their SIP URIs 
> and Mobile IPv6 home addresses, and possibly other information. The 
> phones will establish an IPsec security association upon this first 
> contact.

IKE already does this (establish IPsec SA).

> IPsec will be required not only for protecting their SIP URIs from
> eavesdroppers, but also for protecting data.

IPsec already protects data.

> "IP host pairing" is defined as a pairing protocol that can operate 
> over IP;

Is ND a host pairing protocol, if so can we say so.  Is Bluetooth a
pairing protocol, if so can we say so.  Is Bluetooth VCARD exchange a
means to achieve what IP host pairing tries to achieve.

> upon user contact and also over the Internet i.e. long distances. It
> will address three problems of pairing:
> 1. Pairing when there is user contact: In this case, users can 
> exchange their names or pseudonyms helping identify the hosts to each
>  other the first time they meet.

Define better "user contact": visual contact?  Natural talk/hear
distance?  "Out-of-band" communication?  Letter-through-mail communication?

(When in a meeting and I want to talk to someone next to me, but talking 
disturbs the meeting, and hushing is too incomprehensible - then I write 
on paper and show the paper.)

> 2. Re-pairing, or updating pairing state through the Internet: The 
> users may change their SIP URIs and/or Mobile IPv6 home addresses or 
> other information. The users will need to update these informations 
> without waiting until their next meeting. Or, they may need 
> additional information which was not previously exchanged when there 
> was user contact.
> 3. Pairing without user contact (where possible): Users may know each
>  other but user contact may not be possible. Or, two previously 
> paired hosts may lose pairing state. Users cannot probably wait until
>  their next meeting to recover from loss of state.
> Engineering problems:
> - Identifying the two hosts to each other in (1) and (3). - 
> Preventing unauthorized and annoying pairing attempts from unknown 
> users. - The design of the pairing protocol used to exchange and 
> update the SIP URIs, home addresses and possibly other information.

I think ND with link-local addresses, followed by an IKE exchange and
then by some extensions to "IPv6 Node Information Queries" rfc4620
(extensions to deliver the URI, or the phone number, instead of just the 
FQDN) - can do the trick.  Could this work?


This email has been scanned by the MessageLabs Email Security System.
For more information please visit 

humanresolvers mailing list