[humanresolv] Tentative problem statement
"Pars Mutaf" <pars.mutaf@gmail.com> Fri, 26 October 2007 12:08 UTC
Return-path: <humanresolvers-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlNzj-0008Hp-Od; Fri, 26 Oct 2007 08:08:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlNzi-0008CR-30 for humanresolvers@ietf.org; Fri, 26 Oct 2007 08:08:54 -0400
Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlNzT-0001iw-5i for humanresolvers@ietf.org; Fri, 26 Oct 2007 08:08:49 -0400
Received: by wx-out-0506.google.com with SMTP id s8so752219wxc for <humanresolvers@ietf.org>; Fri, 26 Oct 2007 05:08:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; bh=snkht0ZlJ7NXxP0hGpjE+jAQfJ0pFr8FHpVQrYqU2Fw=; b=TnVwfkSWodtCsRdrEDVliO2PByMUwpBOp94+6igU2WekrXUhMGmFqHH4iLxRySBNG+miB/CSK+MUk86Aav5zpvEXYD8qsR2GOvAEv9Ct5MVQJTfd0Nqb91Gx0Va6CwwEeDQG9mjlBeOjRq2OePR1lGjBOQgO8apmuyN2KAuNwf8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=O1JUTMG92sY87DY/gSYfZ4zBxnTtfETULZWkQzfFtTCohm5DOiIMe4KHnrd+KMPkU/VhGhZ8Bh1Q3+xYSaTaGcbGn+GTe6yamc3qbAxVRMsmBe7LeAWgchF0Q/OPsXbWp/gK6EyW0qYwggxkwqeEf5wVDZztNXXLO2BzOTLzsRk=
Received: by 10.70.41.14 with SMTP id o14mr4842420wxo.1193400484746; Fri, 26 Oct 2007 05:08:04 -0700 (PDT)
Received: by 10.70.117.20 with HTTP; Fri, 26 Oct 2007 05:08:04 -0700 (PDT)
Message-ID: <18a603a60710260508h281a126bjda7179c2b896448b@mail.gmail.com>
Date: Fri, 26 Oct 2007 14:08:04 +0200
From: Pars Mutaf <pars.mutaf@gmail.com>
To: humanresolvers@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc:
Subject: [humanresolv] Tentative problem statement
X-BeenThere: humanresolvers@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pairing cellular hosts <humanresolvers.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/humanresolvers>
List-Post: <mailto:humanresolvers@ietf.org>
List-Help: <mailto:humanresolvers-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/humanresolvers>, <mailto:humanresolvers-request@ietf.org?subject=subscribe>
Errors-To: humanresolvers-bounces@ietf.org
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. IPsec will be required not only for protecting their SIP URIs from eavesdroppers, but also for protecting data. "IP host pairing" is defined as a pairing protocol that can operate over IP; 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. 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. _______________________________________________ humanresolvers mailing list humanresolvers@ietf.org https://www1.ietf.org/mailman/listinfo/humanresolvers
- [humanresolv] Tentative problem statement Pars Mutaf
- Re: [humanresolv] Tentative problem statement Alexandru Petrescu
- Re: [humanresolv] Tentative problem statement Pars Mutaf
- Re: [humanresolv] Tentative problem statement Pars Mutaf
- RE: [humanresolv] Tentative problem statement Vanderveen, Michaela
- Re: [humanresolv] Tentative problem statement Pars Mutaf
- RE: [humanresolv] Tentative problem statement Vanderveen, Michaela
- Re: [humanresolv] Tentative problem statement Pars Mutaf
- RE: [humanresolv] Tentative problem statement Vanderveen, Michaela