From owner-multi6@ops.ietf.org  Mon Sep  1 16:10:56 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12642
	for <multi6-archive@lists.ietf.org>; Mon, 1 Sep 2003 16:10:55 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19tuy1-0005FW-Gs
	for multi6-data@psg.com; Mon, 01 Sep 2003 20:08:01 +0000
Received: from [209.20.253.166] (helo=ran.psg.com)
	by psg.com with esmtp (Exim 4.22)
	id 19tutU-0004tw-Gq
	for multi6@ops.ietf.org; Mon, 01 Sep 2003 20:03:20 +0000
Received: from localhost ([127.0.0.1] helo=ran.psg.com)
	by ran.psg.com with esmtp (Exim 4.20)
	id 19tutU-0007Ur-1T
	for multi6@ops.ietf.org; Mon, 01 Sep 2003 13:03:20 -0700
Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D03F52BD7@Esealnt877.al.sw.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
From: "Yuri Ismailov (KI/EAB)" <yuri.ismailov@ericsson.com>
To: "'Iljitsch van Beijnum'" <iljitsch@muada.com>
Cc: ietf@ietf.org, multi6@ops.ietf.org
Subject: RE: where the indirection layer belongs
Date: Fri, 29 Aug 2003 15:57:00 +0200
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]


Regarding (a) and (b) alternatives it would be nice to have both. However it is not clear why multihoming for v6 and v4 are different issues. Handling of multiple addresses per host is the stack design issue.
The major problem is not to choose the right interface and to send data through it. Applications can do this today, for example SO_DONOTROUTE option in WinSock2. The issue is to CHANGE between interfaces. Current design is OK as long as there is no dynamics.

Honestly, I think that solving one problem at a time may create problems for solving other problems.
Given broad changes in the stack - whole IETF work essentially, creates a good opportunity to review current design and introduce changes, which allow to avoid fixes.
For example, try to implement and run at the same time more than one draft/RFC introducing IP tunneling. I have had quite fun playing around with this and seriously, if to look at the real problem, it is the fact that the same name - IP address, is horribly overloaded with different semantics.

Why layer? Because if it is not layer, then sockets, in their current form, will still be a limit due to the bundling with IP addresses.

-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
Sent: Friday, August 29, 2003 2:31 PM
To: Yuri Ismailov (KI/EAB)
Cc: ietf@ietf.org; multi6@ops.ietf.org
Subject: Re: where the indirection layer belongs


[CC'ing multi6 as I don't think everyone there knows about this thread 
on the IETF discussion list, but please remove either ietf or multi6 if 
this discussion continues.]

On vrijdag, aug 29, 2003, at 11:10 Europe/Amsterdam, Yuri Ismailov 
(KI/EAB) wrote:

> Thirdly, if to stay below transport layer all efforts will not let go 
> beyond a device (host) level. Obviously, there is a need for naming 
> users, devices, content, services or anything else one might think 
> about.

But aren't we squarely inside the application domain here?

> This is still multihoming of devices, what about "multideviced" users? 
> If one has more than one device and wants to move a flow between 
> devices would this be possible if implemented below transport layer? 
> ....

That's a good point.

But first of all: let's not get too carried away with new and 
interesting problems thereby forgetting about actual needs that users 
have today. We need a way to allow multihoming in IPv6 that doesn't 
have the scaling problems our current IPv4 multihoming practices have.

It's not uncommon to see a FQDN point to several IP addresses so that 
the service identified by the FQDN can be provided either by

(a) multiple hosts, or
(b) a host with multiple addresses.

Now if we want to support moving from one addresses to another in the 
middle of an (application level) session, we have two choices: build a 
mechanism that assumes (a) and by extension also works with (b), or 
focus on (b) exclusively.

It looks like Tony Hain wants to go for (a) while Keith Moore assumes 
(b), hence the insanity claims because a solution for (a), which by its 
nature can only reasonably implemented above TCP, is much more involved 
and less efficient than one that only supports (b), which can work on a 
per-packet basis below TCP and other transports.

As a member of the multi6 design team that works on a (b) solution I'm 
convinced that such a solution will provide many benefits and should be 
developed and implemented.

However, this doesn't say anything about the need for an (a) solution. 
Obviously (a) would be good to have. Peer to peer file sharing 
applications extensively use mechanisms like this, where they download 
parts of a file from different hosts.

Also, the current socket API isn't exactly the optimum way for 
applications to interact with the network. It would make sense to 
create something new that sits between the transport(s) and the 
application, and delegate some tasks that are done by applications 
today, most notably name resolution. This allows us to implement new 
namespaces or new address formats without any pain to application 
developers or users stuck with applications that aren't actively 
maintained by developers. This would also be a good opportunity to 
create sensible ways for applications to ask for advanced services from 
the network.

But the real question here is: does this new "thing" have to be a 
layer? In the layering system we have today, each layer talks to the 
underlying one on the local system, but it also interacts with the same 
layer on the remote end.

I'm not convinced this is called for here. For instance, a host that 
implements the above could use a new advanced API to open a set of TCP 
sessions to all the addresses that a FQDN points to, and then 
distribute HTTP requests for the different parts of a file over these 
sessions. But on the other end of one or more of these sessions, there 
could be a regular HTTP server that is completely unaware of the new 
mechanisms and uses existing socket API calls.

So yes, we need something new above the transport layer, but no, it 
shouldn't be a "layer".

Iljitsch





From owner-multi6@ops.ietf.org  Mon Sep  1 16:12:46 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12681
	for <multi6-archive@lists.ietf.org>; Mon, 1 Sep 2003 16:12:46 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19tv2F-0005cV-09
	for multi6-data@psg.com; Mon, 01 Sep 2003 20:12:23 +0000
Received: from [209.20.253.166] (helo=ran.psg.com)
	by psg.com with esmtp (Exim 4.22)
	id 19tv1o-0005aH-AH
	for multi6@ops.ietf.org; Mon, 01 Sep 2003 20:11:57 +0000
Received: from localhost ([127.0.0.1] helo=ran.psg.com)
	by ran.psg.com with esmtp (Exim 4.20)
	id 19tv1k-0007XG-U9
	for multi6@ops.ietf.org; Mon, 01 Sep 2003 13:11:53 -0700
Message-ID: <9088369538.20030829085045@brandenburg.com>
In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390BAA77C4@KC-MAIL4.kc.umkc.edu>
References: <5EF7D95E17BDAD4A968C812E5ABC390BAA77C4@KC-MAIL4.kc.umkc.edu>
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Date: Fri, 29 Aug 2003 08:50:45 -0700
From: Dave Crocker <dhc@dcrocker.net>
To: "Ayyasamy, Senthilkumar  (UMKC-Student)" <saq66@umkc.edu>
CC: multi6@ops.ietf.org
Subject: Re: Multiple Address Service for Transport (MAST)
X-Spam-Status: No, hits=0.5 required=5.0
	tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Senthilkumar,

   
>><http://brandenburg.com/specifications/draft-crocker-mast-propo
>>sal-00.txt>
ASUS> can you compare your proposal with
ASUS> http://www.cs.ucla.edu/~bzhang/etcp/etcp_draft.txt


Section 4.2.2. of the draft anticipates your question. First, it
acknowledges the cleanliness of putting the mechanism directly into
transport. The two major arguments for a "wedge" approach over a
transport approach that it it puts forward are:

          a) working with the installed base of TCP implementations --
          since no changes are required to TCP, and

          b) working with non-TCP transports

Three other arguments worth considering:

          c) working with mobility, as well as multi-homing

          d) not incurring the per-packet option overhead with a larger
          packet and with option processing.

          e) moving the multi-homing/mobility negotiations out of the
          critical path to transport activity; hence it does not impose
          any start-of-connection delays. on the other hand, my
          impression is that the tcp option approach does not impose a
          delay, either.

I'll skip over any possible IPv6/IPv4 issues and any possible security
issues on the theory that they are, or can be, solved just fine for the
TCP option approach.

d/
--
 Dave Crocker <mailto:dcrocker@brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>






From owner-multi6@ops.ietf.org  Tue Sep  2 15:01:38 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27229
	for <multi6-archive@lists.ietf.org>; Tue, 2 Sep 2003 15:01:38 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19uGMi-000CP8-Om
	for multi6-data@psg.com; Tue, 02 Sep 2003 18:58:56 +0000
Received: from [212.68.5.99] (helo=n97.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 19uGJE-000C6S-7k
	for multi6@ops.ietf.org; Tue, 02 Sep 2003 18:55:20 +0000
Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id 402D91C; Tue,  2 Sep 2003 10:38:58 +0300 (EEST)
Message-ID: <3F5445EF.3060100@nomadiclab.com>
Date: Tue, 02 Sep 2003 10:25:35 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Crocker <dhc@dcrocker.net>
Cc: "Ayyasamy, Senthilkumar (UMKC-Student)" <saq66@umkc.edu>,
        multi6@ops.ietf.org
Subject: Re: Multiple Address Service for Transport (MAST)
References: <5EF7D95E17BDAD4A968C812E5ABC390BAA77C4@KC-MAIL4.kc.umkc.edu> <9088369538.20030829085045@brandenburg.com>
In-Reply-To: <9088369538.20030829085045@brandenburg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-2.2 required=5.0
	tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

(Discussing TCP vs. wedge approaches)

Dave Crocker wrote:
> Three other arguments worth considering:
> 
>           c) working with mobility, as well as multi-homing
> 
>           d) not incurring the per-packet option overhead with a larger
>           packet and with option processing.
> 
>           e) moving the multi-homing/mobility negotiations out of the
>           critical path to transport activity; hence it does not impose
>           any start-of-connection delays. on the other hand, my
>           impression is that the tcp option approach does not impose a
>           delay, either.

There are a couple of other issues worth consider, too:

             f) transport layer implementation requires more signalling,
             i.e., separately for each connection, than a wedge one,
             which is basically host-to-host (or end-point-to-end-point)

             g) a wedge implementation will have interesting interplay
             with transport layer RTT and throughput estimates.  OTOH,
             that information is actually more host-to-host (or path
             related) in nature than connection related.

--Pekka Nikander





From owner-multi6@ops.ietf.org  Tue Sep  2 15:25:16 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29841
	for <multi6-archive@lists.ietf.org>; Tue, 2 Sep 2003 15:25:15 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19uGkH-000F2M-Gj
	for multi6-data@psg.com; Tue, 02 Sep 2003 19:23:17 +0000
Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net)
	by psg.com with esmtp (Exim 4.22)
	id 19uGjl-000F0y-Mm
	for multi6@ops.ietf.org; Tue, 02 Sep 2003 19:22:45 +0000
Received: from dfnjgl21 (autoimage.com[216.62.6.129])
          by comcast.net (sccrmhc13) with SMTP
          id <20030902192244016004v31le>
          (Authid: sdawkins@comcast.net);
          Tue, 2 Sep 2003 19:22:44 +0000
Message-ID: <01a201c37187$96b7fdf0$070010ac@DFNJGL21>
Reply-To: "Spencer Dawkins" <spencer@mcsr-labs.org>
From: "Spencer Dawkins" <spencer@mcsr-labs.org>
To: <multi6@ops.ietf.org>
References: <5EF7D95E17BDAD4A968C812E5ABC390BAA77C4@KC-MAIL4.kc.umkc.edu> <9088369538.20030829085045@brandenburg.com> <3F5445EF.3060100@nomadiclab.com>
Subject: Re: Multiple Address Service for Transport (MAST)
Date: Tue, 2 Sep 2003 14:22:34 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=0.5 required=5.0
	tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Pekka,


> (Discussing TCP vs. wedge approaches)

>              g) a wedge implementation will have interesting
interplay
>              with transport layer RTT and throughput estimates.
OTOH,
>              that information is actually more host-to-host (or path
>              related) in nature than connection related.

You'd think so, but I sure haven't heard of a lot of people doing
ftp://ftp.rfc-editor.org/in-notes/rfc2140.txt in production TCPs...

Maybe the wedge approach would provide an incentive here?

Spencer




From owner-multi6@ops.ietf.org  Wed Sep  3 02:21:37 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27217
	for <multi6-archive@lists.ietf.org>; Wed, 3 Sep 2003 02:21:37 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19uQwJ-000Bo4-J5
	for multi6-data@psg.com; Wed, 03 Sep 2003 06:16:23 +0000
Received: from [212.68.5.99] (helo=n97.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 19uQwH-000Bnr-8E
	for multi6@ops.ietf.org; Wed, 03 Sep 2003 06:16:21 +0000
Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id 4963B1C; Wed,  3 Sep 2003 09:29:44 +0300 (EEST)
Message-ID: <3F558736.5060102@nomadiclab.com>
Date: Wed, 03 Sep 2003 09:16:22 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Spencer Dawkins <spencer@mcsr-labs.org>
Cc: multi6@ops.ietf.org
Subject: Re: Multiple Address Service for Transport (MAST)
References: <5EF7D95E17BDAD4A968C812E5ABC390BAA77C4@KC-MAIL4.kc.umkc.edu> <9088369538.20030829085045@brandenburg.com> <3F5445EF.3060100@nomadiclab.com> <01a201c37187$96b7fdf0$070010ac@DFNJGL21>
In-Reply-To: <01a201c37187$96b7fdf0$070010ac@DFNJGL21>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-2.5 required=5.0
	tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Spencer,

>>(Discussing TCP vs. wedge approaches)
> 
>> g) a wedge implementation will have interesting interplay
>>    with transport layer RTT and throughput estimates.
>>    OTOH, that information is actually more host-to-host (or path
>>    related) in nature than connection related.
> 
> You'd think so, but I sure haven't heard of a lot of people doing
> ftp://ftp.rfc-editor.org/in-notes/rfc2140.txt in production TCPs...

I haven't really checked the BSD stack code recently, but
it does keep the RTT and throughput estimates in routing
table entries and not in tcb entries.  In fact, it has a cloned
routing table entry for each active host, and that entry carries
the RTT and throughput estimates over consequent TCP connections.

I would need to study to source code more closely to be able
to say anything more.

> Maybe the wedge approach would provide an incentive here?

Maybe.

--Pekka Nikander





From owner-multi6@ops.ietf.org  Wed Sep  3 09:55:17 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04645
	for <multi6-archive@lists.ietf.org>; Wed, 3 Sep 2003 09:55:16 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19uY3J-000LJQ-JD
	for multi6-data@psg.com; Wed, 03 Sep 2003 13:52:05 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19uY3F-000LHx-9U
	for multi6@ops.ietf.org; Wed, 03 Sep 2003 13:52:01 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309031341.WAA08950@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id WAA08950; Wed, 3 Sep 2003 22:40:55 +0859
Subject: Re: Multiple Address Service for Transport (MAST)
In-Reply-To: <9088369538.20030829085045@brandenburg.com> from Dave Crocker at
 "Aug 29, 2003 08:50:45 am"
To: Dave Crocker <dhc@dcrocker.net>
Date: Wed, 3 Sep 2003 22:40:54 +0859 ()
CC: "Ayyasamy, Senthilkumar  (UMKC-Student)" <saq66@umkc.edu>,
        multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=0.4 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Dave;

MAST is another form of (original) LIN6.

While you say:

	It requires no change to the IP infrastructure, and no change
	to IP modules or transport modules in the end-systems.

	It requires no change to existing transport protocols and
	no changes to IP. Instead, it defines a wedge layer between
	IP and transport.

	In contrast, the current proposal provides support that
	requires no new infrastructure and no changes to existing
	protocols.

	The service should require no changes to the IP network
	infrastructure, to the IP layer in end-systems, or to the
	transport layer in the end-systems.

They are all wrong.

First, a transport protocol is defined on the wire, not at the
API. So, if, on the wire, packets with different pairs of
source/destination addresses belong to the same connection,
it is not TCP but a new protocol.

Second, while you don't have to modify existing transport
code, you must add something to the transport module. That is,
as transport has its own checksum on addresses, calculation
of which is transport dependent, your code include additional
transport module. If you want to add new transport, your
code must also be modified.

Yes, as you correctly observe, your proposal is only as
transparent as NAT.

You modify everything only to have a system to be able to
handle address changes not so efficiently.

But, the worst problem of your proposal is that you don't
properly address the most serious issue on when to change
addresses and which address should be preferred. Read my
draft.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Fri Sep  5 19:50:55 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26911
	for <multi6-archive@lists.ietf.org>; Fri, 5 Sep 2003 19:50:55 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19vQGz-0004lO-If
	for multi6-data@psg.com; Fri, 05 Sep 2003 23:45:49 +0000
Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net)
	by psg.com with esmtp (Exim 4.22)
	id 19vQGT-0004kR-Ub
	for multi6@ops.ietf.org; Fri, 05 Sep 2003 23:45:17 +0000
Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250])
          by comcast.net (rwcrmhc11) with SMTP
          id <200309052345170130035b61e>
          (Authid: sdawkins@comcast.net);
          Fri, 5 Sep 2003 23:45:17 +0000
Message-ID: <037401c37407$c2ca0b40$0400a8c0@DFNJGL21>
Reply-To: "Spencer Dawkins" <spencer@mcsr-labs.org>
From: "Spencer Dawkins" <spencer@mcsr-labs.org>
To: "Multi6 Mailing List" <multi6@ops.ietf.org>
References: <4E85E49D1F0CBF4F96EA08E335750D7D03F52BD3@Esealnt877.al.sw.ericsson.se> <3F4F9DF9.1070509@digi-data.com> <20030829145444.2ea04bcf.moore@cs.utk.edu> <3F4FB414.4020708@digi-data.com> <3F54E0EE.1060100@nomadiclab.com> <3F58F69C.5030306@digi-data.com> <02c401c373f2$c9053f30$0400a8c0@DFNJGL21> <1132867803.20030905160327@brandenburg.com>
Subject: Comments on draft-crocker-mast-proposal-00.txt
Date: Fri, 5 Sep 2003 18:45:17 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=0.0 required=5.0
	tests=REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Dave,

As you requested - the following are my comments on MAST,
revectored to multi6.

Rather than send detailed comments (which I can do, if you think it
would be helpful), I'd like to start at 50,000 feet...

- I like the possibility of using MAST with IPv4. I took a quick look
at LIN6, after Masataka's note on MULTI6. There were things I liked
about LIN6, but the IP version number in the acronym was not a
feature.

- I like your awareness of NATs in IPv4 networks as a deployment
issue.

- I understand why you are thinking "end hosts only". You might also
want to think about MAST proxies to allow MAST mobility against an
unmodified correspondent host (to use the MIP term). If I learned
anything in TRIGTRAN, it was to think about who had the incentives to
deploy something - in wireless mobility, a service provider may have
an incentive to deploy client-side software (if needed) and a server
somewhere in the access network, but the correspondent hosts usually
don't have an incentive to deploy anything.

- MAST seems to be very agnostic about the "bootstrap" IP address. It
happens that I am working on a product that has some MASTish
functionality. We started out being agnostic, too. I'm arguing that we
really need a more useful host identifier (note the use of the
lower-case "h" and "i"). You are explicitly punting on the question of
rendezvous in 4.2.5. There's a lot of prior art that assumes one host
is mobile (WAP had this focus) and that all application exchanges are
mobile-initiated, but much less on how two mobile hosts find each
other. I'm not sure how we do this without HIP-DNS, an LIN6 mapping
agent, or something else within the network.

- One HIP issue I've wondered about, but have not mentioned in public,
is how an application might make of "whatever it THINKS is the IP
address" (because a mobile address/identifier looks like any other
address). What happens if an application expects to do a reverse DNS
lookup of a HIP HI, for instance? Per your 8.1, I THINK any IP
addresses your transports/applications see are really IP addresses,
but they may not be routable or reachable at any given moment... I'm
not the application guy here, I'm just wondering out loud.

- I agree with Matataka's note that selecting an interface is not an
easy problem. When I've asked about this in places like DNA, the
pushback is that this decision is internal to a host, and need
not/should not be standardized in IETF. You might want to think about
this, and mention your position on this explicitly.

- I'm wondering if you have looked at RSIP lately (Experimental
protocol), re: NAT traversal, or at STUN - it looks like you're
including some STUN functionality in PROBE.

- I'm wondering how much you have thought about the use of PROBEs to
verify path connectivity from time to time. The transport view of the
world is that this is really an application-level responsibility,
because the transport (hence, the MAST) doesn't know how often to
verify path connectivity - too often risks punting on paths that are
broken now but will be healed before they are needed, and too seldom
forces the application to probe, anyway. Coming from my particular
part of the world, I think hosts really do see access link failures
(for some values of "see" and "failures"), that hosts can send "Now
I'm at this address" when access links fail, and that connection path
failures for inactive paths beyond the access links are likely to be
resolved before the path is needed (think, "core network routing
update").

- The feedback I got in TRIGTRAN was that it was OK for transports to
ignore path changes when they are doing congestion control, because
all we know is that at least part of the connection path has changed;
Slow Start wouldn't be WRONG, but it might be unnecessary - we could
also see if we can sustain the current rate, and perform congestion
avoidance based on losses (as transports do today), not notification
of path change (today's transports ignore subnetwork path changes
within a single IP hop, right?). You might want to mention your
position on this point explicitly, because we're still having the
"where is the right place for this functionality?" discussion that
includes "but transport does its thing on a single connection path
today".

- When you get to scenario-playing, the hard questions happen when
both hosts move simultaneously. But you know this, of course.

- When you're moving forward from proposal to specification, you'll
need someone smarter than I am about security on the design team.

Hope this helps! Have a great weekend.

Spencer




From owner-multi6@ops.ietf.org  Sat Sep  6 05:22:54 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01557
	for <multi6-archive@lists.ietf.org>; Sat, 6 Sep 2003 05:22:53 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19vZDT-000GxT-4z
	for multi6-data@psg.com; Sat, 06 Sep 2003 09:18:47 +0000
Received: from [213.156.1.123] (helo=sequoia.muada.com)
	by psg.com with esmtp (Exim 4.22)
	id 19vZCs-000GvP-AL
	for multi6@ops.ietf.org; Sat, 06 Sep 2003 09:18:10 +0000
Received: from muada.com (sequoia.muada.com [213.156.1.123])
	by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h869H8xS062718;
	Sat, 6 Sep 2003 11:17:10 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
Date: Sat, 6 Sep 2003 11:16:48 +0200
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "Multi6 Mailing List" <multi6@ops.ietf.org>
To: "Spencer Dawkins" <spencer@mcsr-labs.org>
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <037401c37407$c2ca0b40$0400a8c0@DFNJGL21>
Message-Id: <D7E32927-E04A-11D7-A55A-00039388672E@muada.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-Spam-Status: No, hits=-3.0 required=5.0
	tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,
	      USER_AGENT_APPLEMAIL
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On zaterdag, sep 6, 2003, at 01:45 Europe/Amsterdam, Spencer Dawkins 
wrote:

> - I like the possibility of using MAST with IPv4. I took a quick look
> at LIN6, after Masataka's note on MULTI6. There were things I liked
> about LIN6, but the IP version number in the acronym was not a
> feature.

But is it realistic to expect to deploy a technology in IPv4 that uses 
up additional address space?

> - I understand why you are thinking "end hosts only". You might also
> want to think about MAST proxies to allow MAST mobility against an
> unmodified correspondent host (to use the MIP term).

Always high on my list of desirable features because it makes 
deployment a lot easier.

> - I agree with Matataka's note that selecting an interface is not an
> easy problem. When I've asked about this in places like DNA, the
> pushback is that this decision is internal to a host, and need
> not/should not be standardized in IETF.

Yeah right. See RFC 3484.

> - I'm wondering how much you have thought about the use of PROBEs to
> verify path connectivity from time to time.

I've tried to convince the SCTP folks that this is a bad idea right on 
this here list, but unfortunately they weren't convinced. Just checking 
path availability is mostly useless and wastes bandwidth.

If you only have two paths you're going to try the second one anyway 
when the first fails because there is no reasonable alternative course 
of action. If you have more paths there is a signicant chance that 
several of them will fail because of the same underlying problem.

If you really want to be cool, _use_ the different paths concurrently. 
I'm convinced that as soon as we've got the basic multiadressing 
mechanisms in place, load balancing single TCP sessions over multiple 
paths will be the next big thing.

Iljitsch




From owner-multi6@ops.ietf.org  Sat Sep  6 08:36:04 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10183
	for <multi6-archive@lists.ietf.org>; Sat, 6 Sep 2003 08:36:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19vcEl-00024R-Oa
	for multi6-data@psg.com; Sat, 06 Sep 2003 12:32:19 +0000
Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net)
	by psg.com with esmtp (Exim 4.22)
	id 19vcEi-00023f-II
	for multi6@ops.ietf.org; Sat, 06 Sep 2003 12:32:16 +0000
Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250])
          by comcast.net (rwcrmhc11) with SMTP
          id <20030906123215013002himme>
          (Authid: sdawkins@comcast.net);
          Sat, 6 Sep 2003 12:32:16 +0000
Message-ID: <03f101c37472$e893f410$0400a8c0@DFNJGL21>
Reply-To: "Spencer Dawkins" <spencer@mcsr-labs.org>
From: "Spencer Dawkins" <spencer@mcsr-labs.org>
To: "Multi6 Mailing List" <multi6@ops.ietf.org>
References: <D7E32927-E04A-11D7-A55A-00039388672E@muada.com>
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
Date: Sat, 6 Sep 2003 07:32:16 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=0.5 required=5.0
	tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Iljitsch,

Thank you for your comments on my comments. I did have two notes back.

Spencer


> On zaterdag, sep 6, 2003, at 01:45 Europe/Amsterdam, Spencer Dawkins
> wrote:
>
> > - I like the possibility of using MAST with IPv4. I took a quick
look
> > at LIN6, after Masataka's note on MULTI6. There were things I
liked
> > about LIN6, but the IP version number in the acronym was not a
> > feature.
>
> But is it realistic to expect to deploy a technology in IPv4 that
uses
> up additional address space?
>

Dave keeps saying "a proposal, not a specification", but as I read the
MAST proposal, it doesn't use up additional address space - Dave,
can you give me a clue here? What I THOUGHT I saw was that we
start out with one IP address (that already exists) and then add
others
(that already exist). I may have been blinded - this was where I
started
out on my current project.

But this was one of the differences, I thought, between MAST and LIN6.

[deleted down to]

>
> > - I'm wondering how much you have thought about the use of PROBEs
to
> > verify path connectivity from time to time.
>
> I've tried to convince the SCTP folks that this is a bad idea right
on
> this here list, but unfortunately they weren't convinced. Just
checking
> path availability is mostly useless and wastes bandwidth.

"If a connection path fails on the Internet, and no host sees data
transfer
fail as a result of the failure, was there really a failure?"

>
> If you only have two paths you're going to try the second one anyway
> when the first fails because there is no reasonable alternative
course
> of action. If you have more paths there is a signicant chance that
> several of them will fail because of the same underlying problem.

A good point, which I should have thought of, but hadn't yet.

>
> If you really want to be cool, _use_ the different paths
concurrently.
> I'm convinced that as soon as we've got the basic multiadressing
> mechanisms in place, load balancing single TCP sessions over
multiple
> paths will be the next big thing.

In principle, I agree.

The problem I have is that I'm working with orders-of-magnitude
nominal
bandwidth differences between interfaces in my application (50 Kb/s
for GPRS, to 11 Mb/s for 802.11, to 100 Mb/s for 802.3). The increase
in throughput from using two different interfaces simultaneously gets
lost
in the noise.

If you have a box with three gig-E interfaces, doing a transfer to
another
box with a 10-gig-E interface, using three interfaces simultaneously
could be pretty noticeable, of course. And pretty phat.

For critical environments, I could see loadbalancing as a way of
providing
better feedback about alternative path failures ("you're down to one
path,
which is still working, but if that path fails, it's all over"). Maybe
some of
nice OPS people could express an opinion about whether real
customers need this capability?

Thanks again,

Spencer Dawkins




From owner-multi6@ops.ietf.org  Sat Sep  6 09:37:15 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13624
	for <multi6-archive@lists.ietf.org>; Sat, 6 Sep 2003 09:37:14 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19vdCj-0005r2-Is
	for multi6-data@psg.com; Sat, 06 Sep 2003 13:34:17 +0000
Received: from [213.156.1.123] (helo=sequoia.muada.com)
	by psg.com with esmtp (Exim 4.22)
	id 19vdCf-0005qp-IA
	for multi6@ops.ietf.org; Sat, 06 Sep 2003 13:34:13 +0000
Received: from muada.com (sequoia.muada.com [213.156.1.123])
	by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h86DXCxS065354;
	Sat, 6 Sep 2003 15:33:13 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
Date: Sat, 6 Sep 2003 15:32:52 +0200
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "Multi6 Mailing List" <multi6@ops.ietf.org>
To: "Spencer Dawkins" <spencer@mcsr-labs.org>
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <03f101c37472$e893f410$0400a8c0@DFNJGL21>
Message-Id: <9DAB2B1E-E06E-11D7-A55A-00039388672E@muada.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-Spam-Status: No, hits=-0.4 required=5.0
	tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,
	      USER_AGENT_APPLEMAIL
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On zaterdag, sep 6, 2003, at 14:32 Europe/Amsterdam, Spencer Dawkins 
wrote:

>> But is it realistic to expect to deploy a technology in IPv4 that
>> usesup additional address space?

> Dave keeps saying "a proposal, not a specification", but as I read the
> MAST proposal, it doesn't use up additional address space - Dave,
> can you give me a clue here?

Wouldn't a host need two or more addresses to use MAST? (I must admit I 
haven't read it in detail but the general principles are similar to 
several earlier proposals.) Anyway, I would hate to see IPv4-specific 
problems (NAT...) get in the way of an IPv6 solution.

>> If you really want to be cool, _use_ the different paths
>> concurrently. I'm convinced that as soon as we've got the basic 
>> multiadressing mechanisms in place, load balancing single TCP 
>> sessions over multiple paths will be the next big thing.

> In principle, I agree.

> The problem I have is that I'm working with orders-of-magnitude
> nominal bandwidth differences between interfaces in my application (50 
> Kb/s for GPRS, to 11 Mb/s for 802.11, to 100 Mb/s for 802.3).

You encapsulate IP in 802.3? How does that work for you?

PS.  :-)

> The increase in throughput from using two different interfaces 
> simultaneously gets lost in the noise.

Right. That is, unless someone else does the same thing and talks to 
your ethernet address using her GPRS address and the other way around...

For applications that want/need more than 10 or 100 Mbps, running over 
50 kbps is useless most of the time anyway. So when you fire up the 
microwave but forget to close the door and the wireless stops 
functioning, you really don't want your download to continue over GRPS, 
which is both to slow to be useful and too expensive.

> If you have a box with three gig-E interfaces, doing a transfer to
> another box with a 10-gig-E interface, using three interfaces 
> simultaneously could be pretty noticeable, of course. And pretty phat.

Well, I was thinking more along the lines of a cable + ADSL setup, but 
I'll take 3 x GE if I can get it.  :-)

If you track the RTTs and queue sizes carefully, you should be able to 
select the path with the lowest delay for a certain packet size if you 
have a low bandwidth, low delay line and a high bandwidth, high delay 
one. This would be very useful in setups that include a satellite path.

I was involved in a project where we needed to deliver real time 
traffic of different speeds (ranging from a single packet a second to 
upwards of 10 Mbps) to three remote systems over TCP. (Don't ask.) We 
were supposed to load balance over the three remote systems for 
resiliency reasons. So we implemented a system that distributed the 
data in round robin fashion. This was pretty bad because it was fairly 
common for one system to become very slow for a while. In this case our 
performance went down compared to using only a single system! So we 
started fiddling with all socket options known to man and on each write 
selected the destination for which the least amount of data was still 
buffered for transmission. This worked amazingly well, we could now use 
all three destinations to the full capacity and react to changes almost 
instantly. (At the cost of some end-to-end reordering of the data.)

> For critical environments, I could see loadbalancing as a way of
> providing better feedback about alternative path failures ("you're 
> down to one path, which is still working, but if that path fails, it's 
> all over"). Maybe some of nice OPS people could express an opinion 
> about whether real
> customers need this capability?

I consider myself mostly an ops person and the thing I like about this 
is that it takes the "pick an address and pray" factor out of the 
equation: you always get the full available speed. If you want more 
input on this, you may want to ask the SCTP crowd, they have 
requirements along the lines you mention but I don't think they 
implement load balancing.

Iljitsch




From owner-multi6@ops.ietf.org  Sat Sep  6 16:51:45 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04362
	for <multi6-archive@lists.ietf.org>; Sat, 6 Sep 2003 16:51:45 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19vjvw-0007GO-F7
	for multi6-data@psg.com; Sat, 06 Sep 2003 20:45:24 +0000
Received: from [216.148.227.85] (helo=rwcrmhc12.comcast.net)
	by psg.com with esmtp (Exim 4.22)
	id 19vjvQ-0007DM-6d
	for multi6@ops.ietf.org; Sat, 06 Sep 2003 20:44:52 +0000
Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250])
          by comcast.net (rwcrmhc12) with SMTP
          id <200309062044510140001or9e>
          (Authid: sdawkins@comcast.net);
          Sat, 6 Sep 2003 20:44:51 +0000
Message-ID: <042e01c374b7$b92c6f00$0400a8c0@DFNJGL21>
Reply-To: "Spencer Dawkins" <spencer@mcsr-labs.org>
From: "Spencer Dawkins" <spencer@mcsr-labs.org>
To: "Multi6 Mailing List" <multi6@ops.ietf.org>
References: <9DAB2B1E-E06E-11D7-A55A-00039388672E@muada.com>
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
Date: Sat, 6 Sep 2003 15:44:52 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=0.5 required=5.0
	tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Iljitsch,

I'm not sure we're talking about the same "additional" address -
I'm thinking that a device with two interfaces now already needs
two addresses (so the second address isn't "additional"), and
you're thinking that a device that has only one interface and
one address now would need an "additional" address to do
MAST.

I think.

Spencer

----- Original Message ----- 
From: "Iljitsch van Beijnum" <iljitsch@muada.com>
To: "Spencer Dawkins" <spencer@mcsr-labs.org>
Cc: "Multi6 Mailing List" <multi6@ops.ietf.org>
Sent: Saturday, September 06, 2003 8:32 AM
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt


> On zaterdag, sep 6, 2003, at 14:32 Europe/Amsterdam, Spencer Dawkins
> wrote:
>
> >> But is it realistic to expect to deploy a technology in IPv4 that
> >> usesup additional address space?
>
> > Dave keeps saying "a proposal, not a specification", but as I read
the
> > MAST proposal, it doesn't use up additional address space - Dave,
> > can you give me a clue here?
>
> Wouldn't a host need two or more addresses to use MAST? (I must
admit I
> haven't read it in detail but the general principles are similar to
> several earlier proposals.) Anyway, I would hate to see
IPv4-specific
> problems (NAT...) get in the way of an IPv6 solution.




From owner-multi6@ops.ietf.org  Sat Sep  6 23:05:11 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29674
	for <multi6-archive@lists.ietf.org>; Sat, 6 Sep 2003 23:05:10 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19vpky-0005TI-0P
	for multi6-data@psg.com; Sun, 07 Sep 2003 02:58:28 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19vpkr-0005Si-J8
	for multi6@ops.ietf.org; Sun, 07 Sep 2003 02:58:21 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8733FP08581
	for <multi6@ops.ietf.org>; Sat, 6 Sep 2003 20:03:16 -0700
Date: Sat, 6 Sep 2003 19:58:15 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <11438719956.20030906195815@brandenburg.com>
To: multi6@ops.ietf.org
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.5 required=5.0
	tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Folks,

Thanks for the comments.  Keep them coming.  Some responses:

This realm encompasses three bits of functionality:

1. Rendezvous -- finding someone without existing context between the finder
and the findee. In classic client-server scenarios, that is what we use the
DNS for. Clearly, some mobility scenarios create challenges that existing DNS
mechanisms do not cover.

2. Multi-address support -- or rather, making it possible for a specific
host-pair transport context to be able to use more than one address over the
life of the association.

3. Multi-address use -- intelligently choosing among multiple available
addresses.

MAST defers #1, focuses on #2, and treats #3 simplistically. This is
intentional, of course.

HIP and LIN6 are more ambitious.


SD> - I like the possibility of using MAST with IPv4.

HIP and LIN6 are tied to IPv6 and involve notable enhancements to the Internet
architecture.  Both seem pretty clean to me, architecturally.  MAST does not
take such an approach for two major reasons.  One is installed base, and the
support thereof.  I like to be friendly to millions of hosts, when possible.

The other issue is administrative overhead. MAST does not create any
interesting administrative load HIP and LIN6 impose some significant new
administration. MAST currently involves none. If MAST tackled mutual mobility
(specifically, anytime a caller needs to find a callee for the first time)
then some sort of third-party mechanism is needed and no existing Internet
mechanism is sufficient to the task, I believe. See #3, next segment, below,
re: LIN6.


SD> I took a quick look at LIN6,

Glad to see the reference to it.  I will fold consideration of it into the MAST
proposal.  Here are some initial thoughts:

I think that comparison of HIP, LIN6 and MAST will be helpful.  There are some
pretty interesting differences among them.  I'm planning on doing something
more detailed, but for now:

1. The MAST proposal has a discussion of HIP.  I'm hoping that a HIP savant
will tell me of any errors, so I can fix them.

2. LIN6 appears to be a transport-layer host identifier paradigm, with new
administration of the addresses and then a mapping between the transport-layer
id and one or more classic IP-layer addresses.  By contrast, MAST
introduces *no* new addresses on the wire.  New addresses within the end-nodes
are not required, though internal use of private IP addresses is discussed as
an implementation choice.

3. The LIN6 specification also provides for the rendezvous function, using
DNS, which MAST chooses to defer. The LIN6 rendezvous mechanism appears to be
two-stage.  Stage one is a domain name, with a new, MA record.  Stage two is a
dynamic mapping service, using the transport-level id and any IP-level
addresses that are currently operational.

Without worrying about the fine-grained details of this mechanism, I'll say
that I think it is generally the right approach, when the initiator of an
association must find a mobile host. My guess is that DNS is better for
"sticky" values and that anything that is more dynamic should use something
else. To this end, I find myself thinking in terms of a "presence" service, a
la instant messaging.


SD> - I like your awareness of NATs in IPv4 networks as a deployment
SD> issue.

Be friendly to the installed base and minimize adoption dependencies (ie,
number of changes to make and number of new mechanisms required.) Also, avoid
changing the infrastructure if at all possible.

Adoption of a new mechanism will be a lot easier.


SD> - I understand why you are thinking "end hosts only". You might also
SD> want to think about MAST proxies to allow MAST mobility against an
SD> unmodified correspondent host (to use the MIP term).

Section 8.3 of the MAST proposal is relevant, here. It does not use quite the
same language, but I think the functionality is exactly what you are
describing, or only needs a bit more. If not, please elaborate.


SD> - MAST seems to be very agnostic about the "bootstrap" IP address.
...
SD> mobile-initiated, but much less on how two mobile hosts find each
SD> other.

See above. DNS + distributed, dynamic bulletin boards (presence) function
seems like the right approach to me.

Basically, I think such a mechanism is very important and involves major
effort. It deserves its own focus.

MAST defers this type of mobility out of respect for its difficulty. I think
we do not need to put solving the rendezvous problem into the critical path of
the multi-homing and "client mobility" uses.


SD> - One HIP issue I've wondered about, but have not mentioned in public,
SD> is how an application might make of "whatever it THINKS is the IP
SD> address" (because a mobile address/identifier looks like any other
SD> address). What happens if an application expects to do a reverse DNS
SD> lookup of a HIP HI, for instance? Per your 8.1, I THINK any IP
SD> addresses your transports/applications see are really IP addresses,
SD> but they may not be routable or reachable at any given moment... I'm
SD> not the application guy here, I'm just wondering out loud.

Any application that uses IP addresses is a problem for any translation
function. To handle it, something has to change. The mapping code needs to
know about the application, or the application needs to know about the new
address, or the "address" needs to be something newly assigned thing (end
point identifier) that stays constant. Whatever the choice, it is a big deal.


SD> - I agree with Matataka's note that selecting an interface is not an
SD> easy problem.

I agree.  That's why MAST says a) it's a hard problem, worthy of study, and b)
until we understand it better, be simplistic and conservative.


SD> When I've asked about this in places like DNA, the pushback is that this
SD> decision is internal to a host, and need not/should not be standardized in
SD> IETF.

That is like saying that the TCP retransmission algorithm is internal to a
host and need not/should not be standardized in the IETF.

This is something that has a direct impact on the rest of the Internet. A bad
scheme, implemented in lots of hosts, is going to do a lot of operational
damage.

It needs to be standardized.


SD> You might want to think about
SD> this, and mention your position on this explicitly.

Section 7 tries to do this.  While the current text might seem like a cop-out,
it is not meant to be.

Again, I have too much respect for the complexity and sensitivity of this bit
of mechanism to believe it should be set into concrete too soon, other than
for a simple, safe mechanism just to get things started. More interesting
address selection -- I'm not fond of calling it path selection -- mechanisms
are needed, but again, this can be taken out of the initial critical path for
development and deployment.


SD> - I'm wondering if you have looked at RSIP lately (Experimental
SD> protocol), re: NAT traversal, or at STUN - it looks like you're
SD> including some STUN functionality in PROBE.

I haven't.  Suggestions for what to change, in the PROBE function, would be
welcome.


SD> - I'm wondering how much you have thought about the use of PROBEs to
SD> verify path connectivity from time to time.

Second bullet of the first list under 5.4.  Yes?


SD> The transport view of the
SD> world is that this is really an application-level responsibility,
SD> because the transport (hence, the MAST) doesn't know how often to

My original thinking was that the module that knows about the multiple
addresses should check for their continued validity, especially since the
higher levels do not even know that the multiple addresses exist (in the MAST
proposal). In that sense, I think we need to distinguish things like
application-level aliveness tests from link-level keep-alives. In that sense,
MAST's PROBE is a lower-layers function.


SD> verify path connectivity - too often risks punting on paths that are
SD> broken now but will be healed before they are needed, and too seldom
SD> forces the application to probe,

This is all standard routing-table maintenance stuff, isn't it?  Hence we
should be able to re-use the learning from that task, in terms of balancing
switchover delay, versus flapping.

I don't have any religion on this, other than appreciating the challenge of
getting it right.


SD> - When you're moving forward from proposal to specification, you'll
SD> need someone smarter than I am about security on the design team.

I had not known about the Purpose-Built Key internet-draft.  It seems perfect
for the security MAST needs to provide, specifically to avoid hijacking the
MAST association.



IvB> But is it realistic to expect to deploy a technology in IPv4 that uses
IvB> up additional address space?

MAST does not use up new address space in IPv4 or IPv6.  None.

This point appears to be easy to miss, so let me summarize this aspect of
MAST again:

     MAST uses simple domain names as public, unique end-point identifiers.
     Oddly, MAST doesn't do much with them, yet, for the portion of the
     problem space that MAST attacks.

     MAST creates no new addresses.  None.  Internal to a MAST host, there
     might be a mapping of the changing IP addresses to a stable one that is
     private to that host.  Again oddly, this is like having a NAT function
     just inside the host, between transport and IP.

     
>> - I'm wondering how much you have thought about the use of PROBEs to
>> verify path connectivity from time to time.
IvB> If you only have two paths you're going to try the second one anyway
IvB> when the first fails because there is no reasonable alternative course 
IvB> of action. If you have more paths there is a signicant chance that 
IvB> several of them will fail because of the same underlying problem.

Round-robin is sometimes a fine approach.  Sometimes it has problems.  Just
because a re-try is necessary does not automatically making trying an
alternative address the right thing to do.


IvB> If you really want to be cool, _use_ the different paths concurrently.
IvB> I'm convinced that as soon as we've got the basic multiadressing 
IvB> mechanisms in place, load balancing single TCP sessions over multiple 
IvB> paths will be the next big thing.

I've always felt that the fastest way to switchover to an alternate path is to
already be using it.  Still, this is sensitive stuff and needs to be
approached carefully.


d/
--
 Dave Crocker <mailto:dcrocker@brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>




From owner-multi6@ops.ietf.org  Sun Sep  7 16:18:17 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04931
	for <multi6-archive@lists.ietf.org>; Sun, 7 Sep 2003 16:18:17 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19w5rX-000172-3K
	for multi6-data@psg.com; Sun, 07 Sep 2003 20:10:19 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19w5r0-00013z-Dn
	for multi6@ops.ietf.org; Sun, 07 Sep 2003 20:09:46 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309071954.EAA06992@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id EAA06992; Mon, 8 Sep 2003 04:54:41 +0900
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
In-Reply-To: <037401c37407$c2ca0b40$0400a8c0@DFNJGL21> from Spencer Dawkins at
 "Sep 5, 2003 06:45:17 pm"
To: Spencer Dawkins <spencer@mcsr-labs.org>
Date: Mon, 8 Sep 2003 04:54:40 +0859 ()
CC: Multi6 Mailing List <multi6@ops.ietf.org>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Spencer;

> - I like the possibility of using MAST with IPv4. I took a quick look
> at LIN6, after Masataka's note on MULTI6. There were things I liked
> about LIN6, but the IP version number in the acronym was not a
> feature.

It must be IPv6 to avoid all the MTU problems with 8+8.

Moreover, with IPv6 with proper multihoming, we can assume
the global routing table is small and almost all hosts have it,
which is helpful for address selection from multiple candidates,
which is necessary for multihoming without scalability problem
on routing table size.

It should also be noted that, no one really need another way of
IPv4 multihoming.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Sun Sep  7 16:53:23 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07392
	for <multi6-archive@lists.ietf.org>; Sun, 7 Sep 2003 16:53:22 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19w6VN-0003jo-Uk
	for multi6-data@psg.com; Sun, 07 Sep 2003 20:51:29 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19w6Ur-0003ge-Sj
	for multi6@ops.ietf.org; Sun, 07 Sep 2003 20:50:58 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309072042.FAA07379@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id FAA07379; Mon, 8 Sep 2003 05:42:08 +0900
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
In-Reply-To: <11438719956.20030906195815@brandenburg.com> from Dave Crocker at
 "Sep 6, 2003 07:58:15 pm"
To: Dave Crocker <dcrocker@brandenburg.com>
Date: Mon, 8 Sep 2003 05:42:07 +0859 ()
CC: multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Dave;

> HIP and LIN6 are more ambitious.

Original LIN6 proposal was primarily for mobility and was not
so ambitious. Use of ID is a way to avoid MTU problems of
mobile tunneling.

> The other issue is administrative overhead. MAST does not create any
> interesting administrative load HIP and LIN6 impose some significant new
> administration. MAST currently involves none.

LIN6 does not require any new administration than that for IPv4,
either.

The difference between LIN6 and MAST is efficiency, which is why
our team is working on LIN6 for multihoming support.

> SD> - I agree with Matataka's note that selecting an interface is not an
> SD> easy problem.
> 
> I agree.  That's why MAST says a) it's a hard problem, worthy of study, and b)
> until we understand it better, be simplistic and conservative.

Dave, it is *THE* problem (though it is a selection of an address
not an interface).

If you think you don't understand it very well, it would be wise to
be simplistic and conservative not to make any proposal.

Solving a new problem is not a conservative way of life.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Sun Sep  7 17:49:51 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11433
	for <multi6-archive@lists.ietf.org>; Sun, 7 Sep 2003 17:49:50 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19w7MG-0007Xr-Nv
	for multi6-data@psg.com; Sun, 07 Sep 2003 21:46:08 +0000
Received: from [213.156.1.123] (helo=sequoia.muada.com)
	by psg.com with esmtp (Exim 4.22)
	id 19w7Lk-0007TT-FR
	for multi6@ops.ietf.org; Sun, 07 Sep 2003 21:45:36 +0000
Received: from muada.com (sequoia.muada.com [213.156.1.123])
	by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h87LiYxS085592;
	Sun, 7 Sep 2003 23:44:35 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
Date: Sun, 7 Sep 2003 23:44:15 +0200
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: multi6@ops.ietf.org
To: Dave Crocker <dcrocker@brandenburg.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <11438719956.20030906195815@brandenburg.com>
Message-Id: <6D5610F9-E17C-11D7-AC02-00039388672E@muada.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-Spam-Status: No, hits=-2.2 required=5.0
	tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On zondag, sep 7, 2003, at 04:58 Europe/Amsterdam, Dave Crocker wrote:

> This realm encompasses three bits of functionality:

> 1. Rendezvous -- finding someone without existing context between the 
> finder
> and the findee. In classic client-server scenarios, that is what we 
> use the
> DNS for. Clearly, some mobility scenarios create challenges that 
> existing DNS
> mechanisms do not cover.

I would argue that MAST doesn't perform the initial rendezvous, but 
rather just adds additional addresses to an existing context.

> 2. Multi-address support -- or rather, making it possible for a 
> specific
> host-pair transport context to be able to use more than one address 
> over the
> life of the association.

> 3. Multi-address use -- intelligently choosing among multiple available
> addresses.

Yes, this is obviously something we shouldn't overlook.  :-)

However unless I missed it twice, the MAST draft doesn't really discuss 
this. What is the idea here? Are transports supposed to know how to 
handle the additional addresses? Or does MAST sit between IP and the 
transport and adjust the addresses one uses to the addresses the other 
needs? If the latter is the case, then you need to decide your course 
of action with regard to the transport checksums. If you leave them 
alone there shouldn't be any problems as when the addresses are 
restored at the receiver, the checksum becomes valid again. Unless you 
use NAT, that is. I'm sure most NATs use incremental updates too the 
checksum so this would still work but I'm equally sure there are one or 
two out there that simply recompute the whole checksum, which isn't 
what you want here.

While we're talking about NATs: how is a host behind NAT going to be 
successfully multiaddressed? Does it make sense to address the corner 
case where this is possible, or should a NATted host just be a single 
homed correspondent to a multihomed system?

How are you going to decide when an address jump is in order?

How does MAST fit in the current communication model? Do you do MAST 
first and then a three way handshake? Set up TCP first and then do MAST?

> SD> - I agree with Matataka's note that selecting an interface is not 
> an
> SD> easy problem.

> I agree.  That's why MAST says a) it's a hard problem, worthy of 
> study, and b) until we understand it better, be simplistic and 
> conservative.

Actually if you can jump addresses this is no longer a big issue. 
Unfortunately, if you negotiate in-band, you can't jump addresses when 
you need it most: after you notice that the first packet didn't make it 
to the other side.

Even cooler is letting the routers rewrite the source addresses so:

1. You always have a "good" source address in order to pass ingress 
filtering by your ISP
2. The other side gets to see it automatically when your view of the 
path to it changes

> IvB> But is it realistic to expect to deploy a technology in IPv4 that 
> uses
> IvB> up additional address space?

> MAST does not use up new address space in IPv4 or IPv6.  None.

Except that you need more than one address to get some use out of MAST, 
which is neither unusual nor a big deal for IPv6, but certainly the 
former and possibly the latter in IPv4.

> IvB> If you only have two paths you're going to try the second one 
> anyway
> IvB> when the first fails because there is no reasonable alternative 
> course
> IvB> of action. If you have more paths there is a signicant chance that
> IvB> several of them will fail because of the same underlying problem.

> Round-robin is sometimes a fine approach.  Sometimes it has problems.  
> Just
> because a re-try is necessary does not automatically making trying an
> alternative address the right thing to do.

I was talking about the first address being dead, in that case it is.  
:-)   Unfortunately it isn't easy to see whether an address is dead, 
which I think is your point.

> IvB> If you really want to be cool, _use_ the different paths 
> concurrently.
> IvB> I'm convinced that as soon as we've got the basic multiadressing
> IvB> mechanisms in place, load balancing single TCP sessions over 
> multiple
> IvB> paths will be the next big thing.

> I've always felt that the fastest way to switchover to an alternate 
> path is to already be using it.  Still, this is sensitive stuff and 
> needs to be
> approached carefully.

If we get the basic multihoming part right then this part is up to the 
transport guys. I'm sure they'll come up with something great.




From owner-multi6@ops.ietf.org  Sun Sep  7 20:15:18 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20826
	for <multi6-archive@lists.ietf.org>; Sun, 7 Sep 2003 20:15:17 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19w9bS-000HTT-8O
	for multi6-data@psg.com; Mon, 08 Sep 2003 00:09:58 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19w9au-000HSY-2H
	for multi6@ops.ietf.org; Mon, 08 Sep 2003 00:09:24 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h880EKP09090
	for <multi6@ops.ietf.org>; Sun, 7 Sep 2003 17:14:20 -0700
Date: Sun, 7 Sep 2003 17:09:15 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <68114980002.20030907170915@brandenburg.com>
To: multi6@ops.ietf.org
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-0.4 required=5.0
	tests=QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


>> 1. Rendezvous -- finding someone without existing context between the
IvB> I would argue that MAST doesn't perform the initial rendezvous,

that's what I wrote, immediately after the 3-item list.
IvB>  but
IvB> rather just adds additional addresses to an existing context.


>> 3. Multi-address use -- intelligently choosing among multiple available
>> addresses.

IvB> However unless I missed it twice, the MAST draft doesn't really discuss 
IvB> this.

Section 7 of the proposal.



IvB> While we're talking about NATs: how is a host behind NAT going to be 
IvB> successfully multiaddressed?

The PROBE function is explicitly intended to help deal with this question.


IvB> How are you going to decide when an address jump is in order?

That's Section 7, again.


IvB> How does MAST fit in the current communication model? Do you do MAST
IvB> first and then a three way handshake? Set up TCP first and then do MAST?

Was the diagram in Section 4.1 unclear about this?


IvB> Even cooler is letting the routers rewrite the source addresses so:

MAST explicitly seeks to avoid touching infrastructure, most especially
routers.


>> IvB> up additional address space?

>> MAST does not use up new address space in IPv4 or IPv6.  None.

IvB> Except that you need more than one address to get some use out of MAST,

The reference was to "address space", not "addresses".


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>





From owner-multi6@ops.ietf.org  Mon Sep  8 04:20:49 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01045
	for <multi6-archive@lists.ietf.org>; Mon, 8 Sep 2003 04:20:48 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wHCg-000Pat-Hy
	for multi6-data@psg.com; Mon, 08 Sep 2003 08:16:54 +0000
Received: from [140.116.247.131] (helo=locust.csie.ncku.edu.tw)
	by psg.com with esmtp (Exim 4.22)
	id 19wHC6-000PZY-0E
	for multi6@ops.ietf.org; Mon, 08 Sep 2003 08:16:21 +0000
Received: from supc ([140.116.247.195])
	by locust.csie.ncku.edu.tw (8.11.7+Sun/8.11.6) with SMTP id h888CL719843
	for <multi6@ops.ietf.org>; Mon, 8 Sep 2003 16:12:21 +0800 (CST)
Message-ID: <001a01c375e1$783fe2d0$c3f7748c@supc>
From: "Su Po-chou" <supc@locust.csie.ncku.edu.tw>
To: <multi6@ops.ietf.org>
Subject: router advertisement question
Date: Mon, 8 Sep 2003 16:16:12 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0017_01C37624.852FABE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=0.7 required=5.0
	tests=HTML_40_50
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C37624.852FABE0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Hi all,
I want to get 2 or more addresses from one router by using =
autoconfiguration=20
assume that the router's prefix is 3ffe:3600:1a:1::
now, I hope I can get two address from router's advertisement, e.g. =
3ffe:3600:1a:1::1234 and 3ffe:3600:1a:1:5678
Is this available on radvd ?  =20
Suggestion is needed. =20

Thanks for your kindliness
PC

------=_NextPart_000_0017_01C37624.852FABE0
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dbig5">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi all,</FONT></DIV>
<DIV><FONT size=3D2>I want to get 2 or more addresses from one router by =
using=20
autoconfiguration </FONT></DIV>
<DIV><FONT size=3D2>assume that the router's prefix is=20
3ffe:3600:1a:1::</FONT></DIV>
<DIV><FONT size=3D2>now, I hope I can get two address from&nbsp;router's =

advertisement, e.g. 3ffe:3600:1a:1::1234 and =
3ffe:3600:1a:1:5678</FONT></DIV>
<DIV><FONT size=3D2>Is this available on radvd ?&nbsp;&nbsp; =
</FONT></DIV>
<DIV><FONT size=3D2>Suggestion is needed.&nbsp; </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Thanks for your kindliness</FONT></DIV>
<DIV><FONT size=3D2>PC</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0017_01C37624.852FABE0--





From owner-multi6@ops.ietf.org  Mon Sep  8 05:09:52 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03782
	for <multi6-archive@lists.ietf.org>; Mon, 8 Sep 2003 05:09:52 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wI0E-0003BP-Sa
	for multi6-data@psg.com; Mon, 08 Sep 2003 09:08:06 +0000
Received: from [213.156.1.123] (helo=sequoia.muada.com)
	by psg.com with esmtp (Exim 4.22)
	id 19wHzd-000399-2d
	for multi6@ops.ietf.org; Mon, 08 Sep 2003 09:07:29 +0000
Received: from muada.com (sequoia.muada.com [213.156.1.123])
	by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id h8896SxS093170;
	Mon, 8 Sep 2003 11:06:28 +0200 (CEST)
	(envelope-from iljitsch@muada.com)
Date: Mon, 8 Sep 2003 11:06:12 +0200
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: multi6@ops.ietf.org
To: Dave Crocker <dcrocker@brandenburg.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <151107507227.20030907150442@brandenburg.com>
Message-Id: <B1D3EF3A-E1DB-11D7-AC02-00039388672E@muada.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
X-Spam-Status: No, hits=-1.3 required=5.0
	tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,
	      USER_AGENT_APPLEMAIL
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On maandag, sep 8, 2003, at 00:04 Europe/Amsterdam, Dave Crocker wrote:

> IvB> How are you going to decide when an address jump is in order?

> That's Section 7, again.

In other words, you don't know.  :-)

> IvB> How does MAST fit in the current communication model? Do you do 
> MAST
> IvB> first and then a three way handshake? Set up TCP first and then do
> IvB> MAST?

> Was the diagram in Section 4.1 unclear about this?

Yes. It shows the logical dependencies. What I'm interesting in is the 
order of events. Negotiate first, connect later, or connect first, 
negotiate later?




From owner-multi6@ops.ietf.org  Mon Sep  8 05:41:30 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05835
	for <multi6-archive@lists.ietf.org>; Mon, 8 Sep 2003 05:41:29 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wIUw-0005Ex-Gm
	for multi6-data@psg.com; Mon, 08 Sep 2003 09:39:50 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19wIUq-0005Ea-G4
	for multi6@ops.ietf.org; Mon, 08 Sep 2003 09:39:44 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309080929.SAA11994@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id SAA11994; Mon, 8 Sep 2003 18:29:09 +0900
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
In-Reply-To: <6D5610F9-E17C-11D7-AC02-00039388672E@muada.com> from Iljitsch van
 Beijnum at "Sep 7, 2003 11:44:15 pm"
To: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Mon, 8 Sep 2003 18:29:08 +0859 ()
CC: Dave Crocker <dcrocker@brandenburg.com>, multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=0.0 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Iljitsch;

Read the draft and think.

> I'm sure most NATs use incremental updates too the 
> checksum so this would still work but I'm equally sure there are one or 
> two out there that simply recompute the whole checksum, which isn't 
> what you want here.

That is an uninteresting implementation detail.

> How does MAST fit in the current communication model? Do you do MAST 
> first and then a three way handshake? Set up TCP first and then do MAST?

It is documented in the draft.

     Hence a host may initiate and conduct a classic, single IP-
     pair TCP connection. It may then separately query for remote
     host support of MAST and initiate a MAST exchange to be used
     by that connectivity.  Either participant is then free to
     add or remove addresses. Of course use of MAST may instead
     be performed before a transport context is established, so
     that future contexts immediately have access to multiple IP
     addresses.
 
> > SD> - I agree with Matataka's note that selecting an interface is not 
> > an
> > SD> easy problem.
> 
> > I agree.  That's why MAST says a) it's a hard problem, worthy of 
> > study, and b) until we understand it better, be simplistic and 
> > conservative.
> 
> Actually if you can jump addresses this is no longer a big issue. 

Wrong.

Why you don't give any definition on "jump", that MAST support
the mechanism to change addresses does not help to solve *THE*
problem.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Mon Sep  8 06:58:46 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10189
	for <multi6-archive@lists.ietf.org>; Mon, 8 Sep 2003 06:58:45 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wJgT-000Afr-RK
	for multi6-data@psg.com; Mon, 08 Sep 2003 10:55:49 +0000
Received: from [212.68.5.99] (helo=n97.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 19wJgP-000Afe-IS
	for multi6@ops.ietf.org; Mon, 08 Sep 2003 10:55:45 +0000
Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id 9566E1C; Mon,  8 Sep 2003 14:09:08 +0300 (EEST)
Message-ID: <3F5C6037.6010403@nomadiclab.com>
Date: Mon, 08 Sep 2003 13:55:51 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: multi6@ops.ietf.org
Subject: Mast vs HIP (was Re: Comments on draft-crocker-mast-proposal-00.txt)
References: <11438719956.20030906195815@brandenburg.com>
In-Reply-To: <11438719956.20030906195815@brandenburg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-1.3 required=5.0
	tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES,
	      USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,

[I defer my detailed comments on MAST until later, since I still
  haven't had time to *really* contemplate the proposal.]

Dave Crocker wrote:

> HIP and LIN6 are tied to IPv6 and involve notable enhancements to the
> Internet architecture.  Both seem pretty clean to me, architecturally.

Well, HIP does demonstratably work with IPv4.  There are three
implementations that support IPv4.  Our HIP implementation
even supports mobility between IPv4 and IPv6, today.

What HIP does not do that well is IPv4 API support.  That is,
while most current IPv4 applications will work just fine,
including the most common FTP scenarios, there are applications
and use cases where HIP may (mostly indeterministically) fail.

Actually, HIP is even slightly more ambitious here.  It aims
to provide application interoperability between the IPv4 and
IPv6 APIs.  That is, with HIP an IPv4 client can talk directly
to an IPv6 server, and usually also vice versa.  Only if the
IPv4 client sends IP "addresses" over the application level
data stream, does the IPv6 server learn that its peer is
actually using IPv4 addresses.  However, if the IPv6 server
is able to handle these IPv4 "addresses", the "addresses" will be
mapped to the corresponding host identifiers inside the API,
if possible.  The case that apparently will not work is an IPv6 
application sending an IPv6 "address" to an IPv4 only application.

What comes to the architecture, yes, HIP basically presents an
architectural enhancement.  However, we expliclitly try to
avoid the amount of necessary changes, and restrict them
to the end nodes.

> The other issue is administrative overhead. MAST does not create any 
> interesting administrative load HIP and LIN6 impose some significant
> new administration. MAST currently involves none.

The base HIP specification expects very little administrative
overhead.  Basically, what is needed is to store the host
identifiers (or HITs) to the DNS.  However, HIP is able to work
even without them, in the opportunistic mode.  In that sense,
HIP can be deployed without any administrative overhead, if
so desired.

> I think that comparison of HIP, LIN6 and MAST will be helpful.   There
> are some pretty interesting differences among them.  I'm planning on
> doing something more detailed, but for now:

I would be very glad to see such a comparison.

> 1. The MAST proposal has a discussion of HIP.  I'm hoping that a HIP
> savant will tell me of any errors, so I can fix them.

I think that you have got it mostly right in the proposal, but
I haven't had time to think of all the details.  OTOH, I tried
to offer some corrections above, some comments below.

> By contrast, MAST introduces *no* new addresses on the wire.  New
> addresses within the end-nodes are not required, though internal use
> of private IP addresses is discussed as an implementation choice.

HIP explicitly uses "private IP addresses" within the stack, in order
to help the kernel to differentiate between HITs/LSIs and normal
IP addresses.  However, that is an implementation detail, and most
probably one could build an HIP implementation that does not do that.
However, given that HIP introduces a new name space, I don't see
any reason for trying to mix the name spaces.  The applications
won't be any happier, since HITs are not IP addresses, even if they
do look like ones.

Some people have suggested that it might be possible to implement
HIP in an external box and using the HITs/LSIs in the place of
IP addresses even locally in the wire.  While there may be some
value in the the proposal, I personally don't like it.

> 3. The LIN6 specification also provides for the rendezvous function,
> using DNS, which MAST chooses to defer. 

We have removed rendezvous from the HIP base specifications, and
plan to address is separately for first time rendezvous
(using DNS) and for mobility (new infrastructure).

SD> - One HIP issue I've wondered about, but have not mentioned in
SD>   public, is how an application might make of "whatever it THINKS
SD>   is the IP address" (because a mobile address/identifier looks
SD>   like any other address). What happens if an application expects
SD>   to do a reverse DNS lookup of a HIP HI, for instance?

Right now, if an application attempts to do a reverse DNS lookup
on a HIP HIT or LSI, that will fail.

To make reverse lookup work, some serious work is needed.  For LSIs,
the DNS library needs to convert them to HITs, and then try to do
reverse lookup of the HITs.   What comes to HITs, the issue is
still open, with proposals ranging from using the first bits in a
HIT to identify an assigning authority to using distributed hash
tables.

--Pekka Nikander





From owner-multi6@ops.ietf.org  Mon Sep  8 11:44:01 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00442
	for <multi6-archive@lists.ietf.org>; Mon, 8 Sep 2003 11:44:01 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wO8z-00069S-Uk
	for multi6-data@psg.com; Mon, 08 Sep 2003 15:41:33 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19wO7E-0005xa-Cc
	for multi6@ops.ietf.org; Mon, 08 Sep 2003 15:39:44 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h88FidP24498;
	Mon, 8 Sep 2003 08:44:39 -0700
Date: Mon, 8 Sep 2003 08:39:39 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <1641558140.20030908083939@brandenburg.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
CC: multi6@ops.ietf.org
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
In-Reply-To: <B1D3EF3A-E1DB-11D7-AC02-00039388672E@muada.com>
References: <151107507227.20030907150442@brandenburg.com>
 <B1D3EF3A-E1DB-11D7-AC02-00039388672E@muada.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.5 required=5.0
	tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Iljitsch,

>> Was the diagram in Section 4.1 unclear about this?

IvB> Yes. It shows the logical dependencies. What I'm interesting in is the 
IvB> order of events. Negotiate first, connect later, or connect first, 
IvB> negotiate later?

What details are you looking for, beyond:

     1. Introduction:

     Hence a host may initiate and conduct a classic, single IP-
     pair TCP connection. It may then separately query for remote
     host support of MAST and initiate a MAST exchange to be used
     by that connectivity.  Either participant is then free to
     add or remove addresses. Of course use of MAST may instead
     be performed before a transport context is established, so
     that future contexts immediately have access to multiple IP
     addresses.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Tue Sep  9 02:53:49 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22768
	for <multi6-archive@lists.ietf.org>; Tue, 9 Sep 2003 02:53:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wcLs-000FLo-Ts
	for multi6-data@psg.com; Tue, 09 Sep 2003 06:51:48 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19wcLN-000FGd-CF
	for multi6@ops.ietf.org; Tue, 09 Sep 2003 06:51:17 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h896uAP19437;
	Mon, 8 Sep 2003 23:56:10 -0700
Date: Mon, 8 Sep 2003 23:51:06 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <18756244795.20030908235106@brandenburg.com>
To: "Eugene M. Kim" <gene@nttmcl.com>
CC: multi6@ops.ietf.org
Subject: Re: A comment about MAST
In-Reply-To: <04b201c37691$7f5aabd0$f54545d8@daal>
References: <04b201c37691$7f5aabd0$f54545d8@daal>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-1.3 required=5.0
	tests=BAYES_30,IN_REP_TO,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eugene,

thank you for the comments.

EMK> completely hidden from upper-level applications so they will still
EMK> identify the connection as between IP.a, Port.l, and IP.y, Port.r
EMK> (communication endpoints).  Although this is the least intrusive
EMK> approach, I think this is not enough if applications that `leak' those
EMK> endpoints over the wire were to benefit from MAST.  This is somewhat
EMK> similar to the classic NAT problem.

I think it is exactly the same, yes.


EMK> My suggestion is to expose the address changes to upper-level
EMK> applications through some backward-compatible API extension, which shall
EMK> notify applications that addresses are being added to or removed from
EMK> the local or remote endpoint identifier.

More generally, you are suggesting a line of consideration that the draft
probably should mention.  Namely, it might discuss additional areas for
development.  There is already a small amount of such commentary in the
document. The suggestion you are making is an interesting one for this.  Some
sort of "roadmap" would probably be helpful.

In general, IETF protocol work does not specify APIs, though of course there
are exceptions.  Certainly it would be useful to suggest this separate
information channel to the application.


EMK>   Complex applications (and
EMK> protocols they implement) that do care about and use endpoint
EMK> identifiers over the wire can be modified to utilize MAST and this new
EMK> API so they can propagate address changes accordingly.  If they ignore
EMK> the new API, their operation will break at the moment an original
EMK> endpoint address, local or remote, becomes invalid; but since they will
EMK> break anyway without MAST at all at that moment, this seems to be a
EMK> non-issue.

Right.  And a good discussion worth adding to the proposal is about
application awareness of current addresses.


EMK> I am not suggesting that the MAST proposal should define such APIs with
EMK> it; IMO they are better left out as future work items as individual
EMK> operating systems implement MAST.

Yes, but I do think the proposal will benefit from having some discussion
about the issue.  Thank you for raising it.


EMK> P.S. Which is the main discussion list for MAST, and could you forward
EMK> this to the list if there is one?

multi6.  I have forwarded your note, and copied you.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Tue Sep  9 02:54:22 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22786
	for <multi6-archive@lists.ietf.org>; Tue, 9 Sep 2003 02:54:21 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wcKI-000F9M-PO
	for multi6-data@psg.com; Tue, 09 Sep 2003 06:50:10 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19wcJO-000F2T-4p
	for multi6@ops.ietf.org; Tue, 09 Sep 2003 06:49:14 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h896sBP19343;
	Mon, 8 Sep 2003 23:54:12 -0700
Date: Mon, 8 Sep 2003 23:49:07 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <11456125594.20030908234907@brandenburg.com>
To: multi6@ops.ietf.org
CC: "Eugene M. Kim" <gene@nttmcl.com>
Subject: Fwd: A comment about MAST
In-Reply-To: <04b201c37691$7f5aabd0$f54545d8@daal>
References: <04b201c37691$7f5aabd0$f54545d8@daal>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-0.4 required=5.0
	tests=IN_REP_TO,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Forwarded, at the author's request. my reply follows.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

===== Forwarded message =====
From: Eugene M. Kim <gene@nttmcl.com>
To: "Dave Crocker" <dcrocker@brandenburg.com>
Date: Monday, September 8, 2003, 10:16:17 PM
Subject: A comment about MAST

Greetings,

I have a comment regarding your MAST proposal; I apologize if this have
already been addressed before:

My understanding of the architectural model as described and illustrated
in 4.1 suggests that the address changes and handovers will be
completely hidden from upper-level applications so they will still
identify the connection as between IP.a, Port.l, and IP.y, Port.r
(communication endpoints).  Although this is the least intrusive
approach, I think this is not enough if applications that `leak' those
endpoints over the wire were to benefit from MAST.  This is somewhat
similar to the classic NAT problem.

My suggestion is to expose the address changes to upper-level
applications through some backward-compatible API extension, which shall
notify applications that addresses are being added to or removed from
the local or remote endpoint identifier.  Simple applications that do
not care about nor use endpoint identifiers can safely ignore this new
API and still work across address changes.  Complex applications (and
protocols they implement) that do care about and use endpoint
identifiers over the wire can be modified to utilize MAST and this new
API so they can propagate address changes accordingly.  If they ignore
the new API, their operation will break at the moment an original
endpoint address, local or remote, becomes invalid; but since they will
break anyway without MAST at all at that moment, this seems to be a
non-issue.

I am not suggesting that the MAST proposal should define such APIs with
it; IMO they are better left out as future work items as individual
operating systems implement MAST.

Regards,
Eugene

P.S. Which is the main discussion list for MAST, and could you forward
this to the list if there is one?
===== End of original message text =====




From owner-multi6@ops.ietf.org  Tue Sep  9 04:46:22 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26226
	for <multi6-archive@lists.ietf.org>; Tue, 9 Sep 2003 04:46:21 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19we3g-0002sm-3O
	for multi6-data@psg.com; Tue, 09 Sep 2003 08:41:08 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19we2d-0002hO-Pu
	for multi6@ops.ietf.org; Tue, 09 Sep 2003 08:40:04 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309090823.RAA25347@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id RAA25347; Tue, 9 Sep 2003 17:23:25 +0900
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <11456125594.20030908234907@brandenburg.com> from Dave Crocker at
 "Sep 8, 2003 11:49:07 pm"
To: Dave Crocker <dcrocker@brandenburg.com>
Date: Tue, 9 Sep 2003 17:23:25 +0859 ()
CC: multi6@ops.ietf.org, "Eugene M. Kim" <gene@nttmcl.com>
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Dave;

> Forwarded, at the author's request. my reply follows.

> My understanding of the architectural model as described and illustrated
> in 4.1 suggests that the address changes and handovers will be
> completely hidden from upper-level applications so they will still
> identify the connection as between IP.a, Port.l, and IP.y, Port.r
> (communication endpoints).  Although this is the least intrusive
> approach,

That is the stupidity not to be overlooked.

What we learned from NAT is that NAT is worst intrusive.

> I think this is not enough if applications that `leak' those
> endpoints over the wire were to benefit from MAST.  This is somewhat
> similar to the classic NAT problem.

> Complex applications (and
> protocols they implement) that do care about and use endpoint
> identifiers over the wire can be modified to utilize MAST and this new
> API so they can propagate address changes accordingly.

That is the old argument for NAT lovers.

> API so they can propagate address changes accordingly.  If they ignore
> the new API, their operation will break at the moment an original
> endpoint address, local or remote, becomes invalid; but since they will
> break anyway without MAST at all at that moment, this seems to be a
> non-issue.

Wrong.

It is merely that NAT approach unnecessarily break some application.

It is, of course, possible to have NAT penetration protocol and
its API and you can argue as "If they ignore the new API, ... this
seems to be a non-issue".

In addition, the statement:

	their operation will break at the moment an original
	endpoint address, local or remote, becomes invalid;

assumes a lot of restriction on when to change addresses, lack
of argument on which is, as has been pointed out by some, the
fatal flaw of MAST draft.

People who believe NAT least intrusive should keep using IPv4 with
NAT.

Rest of us work on IPv6.

PERIOD.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Tue Sep  9 12:00:46 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19293
	for <multi6-archive@lists.ietf.org>; Tue, 9 Sep 2003 12:00:45 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wkqF-000KyF-Mb
	for multi6-data@psg.com; Tue, 09 Sep 2003 15:55:43 +0000
Received: from [209.20.253.166] (helo=ran.psg.com)
	by psg.com with esmtp (Exim 4.22)
	id 19wkpj-000Ku2-58
	for multi6@ops.ietf.org; Tue, 09 Sep 2003 15:55:11 +0000
Received: from localhost ([127.0.0.1] helo=ran.psg.com)
	by ran.psg.com with esmtp (Exim 4.22)
	id 19wkph-000CLt-Vu
	for multi6@ops.ietf.org; Tue, 09 Sep 2003 08:55:10 -0700
Message-Id: <5.1.1.9.2.20030909213202.056ec170@127.0.0.1>
In-Reply-To: <11438719956.20030906195815@brandenburg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Tue, 09 Sep 2003 22:00:21 +0900
To: Dave Crocker <dcrocker@brandenburg.com>, multi6@ops.ietf.org
From: Fumio Teraoka <tera@ics.keio.ac.jp>
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
X-Spam-Status: No, hits=-1.3 required=5.0
	tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REPLY_WITH_QUOTES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Dave,

Sorry for late response. There are some comments about the
description of the LIN6 identifier in your artcle as a co-author
of the LIN6 i-d.

LIN6 introduces a 64-bit "node identifier (node id)" which is
assigned to a node. The node id is not only a transport layer
identifier. The node id in LIN6 is used in the application layer,
the transport layer, and the network layer (possibly, in the link
layer). In the network layer, the node id is concatinated with a
64-bit network prefix to generate a IPv6 address. In the application
layer and the transport layer,the node id is concatenated with a 64-bit
"fixed value" to generate an identifier which is compatible with
the IPv6 address format.

Unfortunately, I have not read the MAST i-d yet. I'll read the i-d and
post some comments on this list.

Best regards,

Fumio Teraoka

At 03/09/06 19:58 -0700, Dave Crocker wrote:
>Folks,
>
>Thanks for the comments.  Keep them coming.  Some responses:
>
>This realm encompasses three bits of functionality:
>
>1. Rendezvous -- finding someone without existing context between the finder
>and the findee. In classic client-server scenarios, that is what we use the
>DNS for. Clearly, some mobility scenarios create challenges that existing DNS
>mechanisms do not cover.
>
>2. Multi-address support -- or rather, making it possible for a specific
>host-pair transport context to be able to use more than one address over the
>life of the association.
>
>3. Multi-address use -- intelligently choosing among multiple available
>addresses.
>
>MAST defers #1, focuses on #2, and treats #3 simplistically. This is
>intentional, of course.
>
>HIP and LIN6 are more ambitious.
>
>
>SD> - I like the possibility of using MAST with IPv4.
>
>HIP and LIN6 are tied to IPv6 and involve notable enhancements to the Internet
>architecture.  Both seem pretty clean to me, architecturally.  MAST does not
>take such an approach for two major reasons.  One is installed base, and the
>support thereof.  I like to be friendly to millions of hosts, when possible.
>
>The other issue is administrative overhead. MAST does not create any
>interesting administrative load HIP and LIN6 impose some significant new
>administration. MAST currently involves none. If MAST tackled mutual mobility
>(specifically, anytime a caller needs to find a callee for the first time)
>then some sort of third-party mechanism is needed and no existing Internet
>mechanism is sufficient to the task, I believe. See #3, next segment, below,
>re: LIN6.
>
>
>SD> I took a quick look at LIN6,
>
>Glad to see the reference to it.  I will fold consideration of it into the MAST
>proposal.  Here are some initial thoughts:
>
>I think that comparison of HIP, LIN6 and MAST will be helpful.  There are some
>pretty interesting differences among them.  I'm planning on doing something
>more detailed, but for now:
>
>1. The MAST proposal has a discussion of HIP.  I'm hoping that a HIP savant
>will tell me of any errors, so I can fix them.
>
>2. LIN6 appears to be a transport-layer host identifier paradigm, with new
>administration of the addresses and then a mapping between the transport-layer
>id and one or more classic IP-layer addresses.  By contrast, MAST
>introduces *no* new addresses on the wire.  New addresses within the end-nodes
>are not required, though internal use of private IP addresses is discussed as
>an implementation choice.
>
>3. The LIN6 specification also provides for the rendezvous function, using
>DNS, which MAST chooses to defer. The LIN6 rendezvous mechanism appears to be
>two-stage.  Stage one is a domain name, with a new, MA record.  Stage two is a
>dynamic mapping service, using the transport-level id and any IP-level
>addresses that are currently operational.
>
>Without worrying about the fine-grained details of this mechanism, I'll say
>that I think it is generally the right approach, when the initiator of an
>association must find a mobile host. My guess is that DNS is better for
>"sticky" values and that anything that is more dynamic should use something
>else. To this end, I find myself thinking in terms of a "presence" service, a
>la instant messaging.
>
>
>SD> - I like your awareness of NATs in IPv4 networks as a deployment
>SD> issue.
>
>Be friendly to the installed base and minimize adoption dependencies (ie,
>number of changes to make and number of new mechanisms required.) Also, avoid
>changing the infrastructure if at all possible.
>
>Adoption of a new mechanism will be a lot easier.
>
>
>SD> - I understand why you are thinking "end hosts only". You might also
>SD> want to think about MAST proxies to allow MAST mobility against an
>SD> unmodified correspondent host (to use the MIP term).
>
>Section 8.3 of the MAST proposal is relevant, here. It does not use quite the
>same language, but I think the functionality is exactly what you are
>describing, or only needs a bit more. If not, please elaborate.
>
>
>SD> - MAST seems to be very agnostic about the "bootstrap" IP address.
>...
>SD> mobile-initiated, but much less on how two mobile hosts find each
>SD> other.
>
>See above. DNS + distributed, dynamic bulletin boards (presence) function
>seems like the right approach to me.
>
>Basically, I think such a mechanism is very important and involves major
>effort. It deserves its own focus.
>
>MAST defers this type of mobility out of respect for its difficulty. I think
>we do not need to put solving the rendezvous problem into the critical path of
>the multi-homing and "client mobility" uses.
>
>
>SD> - One HIP issue I've wondered about, but have not mentioned in public,
>SD> is how an application might make of "whatever it THINKS is the IP
>SD> address" (because a mobile address/identifier looks like any other
>SD> address). What happens if an application expects to do a reverse DNS
>SD> lookup of a HIP HI, for instance? Per your 8.1, I THINK any IP
>SD> addresses your transports/applications see are really IP addresses,
>SD> but they may not be routable or reachable at any given moment... I'm
>SD> not the application guy here, I'm just wondering out loud.
>
>Any application that uses IP addresses is a problem for any translation
>function. To handle it, something has to change. The mapping code needs to
>know about the application, or the application needs to know about the new
>address, or the "address" needs to be something newly assigned thing (end
>point identifier) that stays constant. Whatever the choice, it is a big deal.
>
>
>SD> - I agree with Matataka's note that selecting an interface is not an
>SD> easy problem.
>
>I agree.  That's why MAST says a) it's a hard problem, worthy of study, and b)
>until we understand it better, be simplistic and conservative.
>
>
>SD> When I've asked about this in places like DNA, the pushback is that this
>SD> decision is internal to a host, and need not/should not be standardized in
>SD> IETF.
>
>That is like saying that the TCP retransmission algorithm is internal to a
>host and need not/should not be standardized in the IETF.
>
>This is something that has a direct impact on the rest of the Internet. A bad
>scheme, implemented in lots of hosts, is going to do a lot of operational
>damage.
>
>It needs to be standardized.
>
>
>SD> You might want to think about
>SD> this, and mention your position on this explicitly.
>
>Section 7 tries to do this.  While the current text might seem like a cop-out,
>it is not meant to be.
>
>Again, I have too much respect for the complexity and sensitivity of this bit
>of mechanism to believe it should be set into concrete too soon, other than
>for a simple, safe mechanism just to get things started. More interesting
>address selection -- I'm not fond of calling it path selection -- mechanisms
>are needed, but again, this can be taken out of the initial critical path for
>development and deployment.
>
>
>SD> - I'm wondering if you have looked at RSIP lately (Experimental
>SD> protocol), re: NAT traversal, or at STUN - it looks like you're
>SD> including some STUN functionality in PROBE.
>
>I haven't.  Suggestions for what to change, in the PROBE function, would be
>welcome.
>
>
>SD> - I'm wondering how much you have thought about the use of PROBEs to
>SD> verify path connectivity from time to time.
>
>Second bullet of the first list under 5.4.  Yes?
>
>
>SD> The transport view of the
>SD> world is that this is really an application-level responsibility,
>SD> because the transport (hence, the MAST) doesn't know how often to
>
>My original thinking was that the module that knows about the multiple
>addresses should check for their continued validity, especially since the
>higher levels do not even know that the multiple addresses exist (in the MAST
>proposal). In that sense, I think we need to distinguish things like
>application-level aliveness tests from link-level keep-alives. In that sense,
>MAST's PROBE is a lower-layers function.
>
>
>SD> verify path connectivity - too often risks punting on paths that are
>SD> broken now but will be healed before they are needed, and too seldom
>SD> forces the application to probe,
>
>This is all standard routing-table maintenance stuff, isn't it?  Hence we
>should be able to re-use the learning from that task, in terms of balancing
>switchover delay, versus flapping.
>
>I don't have any religion on this, other than appreciating the challenge of
>getting it right.
>
>
>SD> - When you're moving forward from proposal to specification, you'll
>SD> need someone smarter than I am about security on the design team.
>
>I had not known about the Purpose-Built Key internet-draft.  It seems perfect
>for the security MAST needs to provide, specifically to avoid hijacking the
>MAST association.
>
>
>
>IvB> But is it realistic to expect to deploy a technology in IPv4 that uses
>IvB> up additional address space?
>
>MAST does not use up new address space in IPv4 or IPv6.  None.
>
>This point appears to be easy to miss, so let me summarize this aspect of
>MAST again:
>
>     MAST uses simple domain names as public, unique end-point identifiers.
>     Oddly, MAST doesn't do much with them, yet, for the portion of the
>     problem space that MAST attacks.
>
>     MAST creates no new addresses.  None.  Internal to a MAST host, there
>     might be a mapping of the changing IP addresses to a stable one that is
>     private to that host.  Again oddly, this is like having a NAT function
>     just inside the host, between transport and IP.
>
>     
>>> - I'm wondering how much you have thought about the use of PROBEs to
>>> verify path connectivity from time to time.
>IvB> If you only have two paths you're going to try the second one anyway
>IvB> when the first fails because there is no reasonable alternative course 
>IvB> of action. If you have more paths there is a signicant chance that 
>IvB> several of them will fail because of the same underlying problem.
>
>Round-robin is sometimes a fine approach.  Sometimes it has problems.  Just
>because a re-try is necessary does not automatically making trying an
>alternative address the right thing to do.
>
>
>IvB> If you really want to be cool, _use_ the different paths concurrently.
>IvB> I'm convinced that as soon as we've got the basic multiadressing 
>IvB> mechanisms in place, load balancing single TCP sessions over multiple 
>IvB> paths will be the next big thing.
>
>I've always felt that the fastest way to switchover to an alternate path is to
>already be using it.  Still, this is sensitive stuff and needs to be
>approached carefully.
>
>
>d/
>--
> Dave Crocker <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking <http://www.brandenburg.com>
> Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>






From owner-multi6@ops.ietf.org  Tue Sep  9 12:05:34 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19475
	for <multi6-archive@lists.ietf.org>; Tue, 9 Sep 2003 12:05:33 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wkyK-000Lqd-NJ
	for multi6-data@psg.com; Tue, 09 Sep 2003 16:04:04 +0000
Received: from [209.20.253.166] (helo=ran.psg.com)
	by psg.com with esmtp (Exim 4.22)
	id 19wkxo-000Lne-GI
	for multi6@ops.ietf.org; Tue, 09 Sep 2003 16:03:32 +0000
Received: from localhost ([127.0.0.1] helo=ran.psg.com)
	by ran.psg.com with esmtp (Exim 4.22)
	id 19wkxo-000CZw-0P
	for multi6@ops.ietf.org; Tue, 09 Sep 2003 09:03:32 -0700
Approved: ops 
Message-ID: <20030909142722.GA28569@alicia.nttmcl.com>
References: <11456125594.20030908234907@brandenburg.com> <200309090823.RAA25347@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200309090823.RAA25347@necom830.hpcl.titech.ac.jp>
Date: Tue, 9 Sep 2003 07:27:27 -0700
From: "Eugene M. Kim" <gene@nttmcl.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: Dave Crocker <dcrocker@brandenburg.com>, multi6@ops.ietf.org
Subject: Re: Fwd: A comment about MAST
X-Spam-Status: No, hits=-6.0 required=5.0
	tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Mr. Ohta, I'm afraid you are misinterpreting (and misrepresenting) me;
I do hate NAT, and I am a firm believer in IPv6.

Granted, we need some architecturally solid and sound solution, i.e. the
ultimate, long-term goal, to the ID/LOC problem.  However, that will
probably mean introducing a new namespace for either identifier or
locator (depending on which purpose we decide to use the current IP
address space for), and applications must adapt itself to the new world
order.

On the other hand, applications can start benefiting from MAST almost
immediately, especially when they do not care about communication
endpoint addresses.  And a lot of existing applications fall into this
category.  I think, therefore, MAST can serve as a good stopgap while
a permanant solution is being developed and deployed.

This is not some ten years ago when people started (ab)using NAT without
realizing its full consequence.  Provided we have some bigger picture,
or a roadmap, I think MAST still has its merits when used accordingly to
the roadmap even though it inherits some of the same problematic natures
from NAT as you pointed out.

As for the roadmap itself, I think I just explained my crude idea about
it; make a permanant solution that cleanly separates identifiers from
locators, and use MAST as a stopgap. =)

Regards,
Eugene

On Tue, Sep 09, 2003 at 05:23:25PM +0859, Masataka Ohta wrote:
> Dave;
> 
> > Forwarded, at the author's request. my reply follows.
> 
> > My understanding of the architectural model as described and illustrated
> > in 4.1 suggests that the address changes and handovers will be
> > completely hidden from upper-level applications so they will still
> > identify the connection as between IP.a, Port.l, and IP.y, Port.r
> > (communication endpoints).  Although this is the least intrusive
> > approach,
> 
> That is the stupidity not to be overlooked.
> 
> What we learned from NAT is that NAT is worst intrusive.
> 
> > I think this is not enough if applications that `leak' those
> > endpoints over the wire were to benefit from MAST.  This is somewhat
> > similar to the classic NAT problem.
> 
> > Complex applications (and
> > protocols they implement) that do care about and use endpoint
> > identifiers over the wire can be modified to utilize MAST and this new
> > API so they can propagate address changes accordingly.
> 
> That is the old argument for NAT lovers.
> 
> > API so they can propagate address changes accordingly.  If they ignore
> > the new API, their operation will break at the moment an original
> > endpoint address, local or remote, becomes invalid; but since they will
> > break anyway without MAST at all at that moment, this seems to be a
> > non-issue.
> 
> Wrong.
> 
> It is merely that NAT approach unnecessarily break some application.
> 
> It is, of course, possible to have NAT penetration protocol and
> its API and you can argue as "If they ignore the new API, ... this
> seems to be a non-issue".
> 
> In addition, the statement:
> 
> 	their operation will break at the moment an original
> 	endpoint address, local or remote, becomes invalid;
> 
> assumes a lot of restriction on when to change addresses, lack
> of argument on which is, as has been pointed out by some, the
> fatal flaw of MAST draft.
> 
> People who believe NAT least intrusive should keep using IPv4 with
> NAT.
> 
> Rest of us work on IPv6.
> 
> PERIOD.
> 
> 							Masataka Ohta





From owner-multi6@ops.ietf.org  Wed Sep 10 02:30:04 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17481
	for <multi6-archive@lists.ietf.org>; Wed, 10 Sep 2003 02:30:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wyOm-000P99-Ni
	for multi6-data@psg.com; Wed, 10 Sep 2003 06:24:16 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19wyOG-000P7B-Cm
	for multi6@ops.ietf.org; Wed, 10 Sep 2003 06:23:44 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8A6SdP06128;
	Tue, 9 Sep 2003 23:28:40 -0700
Date: Tue, 9 Sep 2003 23:23:33 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <7255593018.20030909232333@brandenburg.com>
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
CC: multi6@ops.ietf.org
Subject: Re: Mast vs HIP (was Re: Comments on draft-crocker-mast-proposal-00.txt)
In-Reply-To: <3F5C6037.6010403@nomadiclab.com>
References: <11438719956.20030906195815@brandenburg.com>
 <3F5C6037.6010403@nomadiclab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
	      REPLY_WITH_QUOTES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka,

Many thanks for the comments.


PN> Well, HIP does demonstratably work with IPv4.

yes.  sorry for my confusion.


PN> What HIP does not do that well is IPv4 API support.  That is,
PN> while most current IPv4 applications will work just fine,
PN> including the most common FTP scenarios, there are applications
PN> and use cases where HIP may (mostly indeterministically) fail.

I assume the problematic applications are those that embed IP addresses in
them. What others are there?


PN> Actually, HIP is even slightly more ambitious here.  It aims
PN> to provide application interoperability between the IPv4 and
PN> IPv6 APIs.  That is, with HIP an IPv4 client can talk directly
PN> to an IPv6 server,

I do not recall seeing the HIP specification call for IPv4/IPv6 packet
translation.  So I do not see how an IPv4-only host can talk with an IPv6-only
host, as a consequence of their both using HIP.  Where is this described in
the specification?

Hmmm.  Thinking a bit more, I think you mean IPv4 _application_, running on a
host that has IPv6, or vice-versa.  This would be expected to work because HIP
maps all address to a common type, from the perspective of the application.
(Sounds like a NAT between IP and Transport, doesn't it?)

When an application opens a connection by specifying the target's domain name,
I can see this working.  When the application does the DNS query and then
hands to address to TCP to do the open, there will be a problem, no?  The
application has to carry the address for a brief time.


PN> The base HIP specification expects very little administrative
PN> overhead.  Basically, what is needed is to store the host
PN> identifiers (or HITs) to the DNS.

HITs are a new, global name space.  Hence there needs to be a new, global
administrative structure for managing HIT assignments.


PN>   However, HIP is able to work
PN> even without them, in the opportunistic mode.

And that's where things get confusing for me.  If HIP works with
randomly-generated HITs, then why are globally-assigned ones needed?


>> By contrast, MAST introduces *no* new addresses on the wire.  New
>> addresses within the end-nodes are not required, though internal use
>> of private IP addresses is discussed as an implementation choice.

PN> HIP explicitly uses "private IP addresses" within the stack, in order
PN> to help the kernel to differentiate between HITs/LSIs and normal
PN> IP addresses.

Yes, it does seem to take care of the different scenarios.  I must admit that
a scheme that calls for up to 3 different strings, to refer to the same thing
-- in addition to domain name and IP address(es) -- strikes me as rather
daunting.


PN> Some people have suggested that it might be possible to implement
PN> HIP in an external box and using the HITs/LSIs in the place of
PN> IP addresses even locally in the wire.

Note the MAST section called "MAST in NAT".  It occurred to me, too, that it
might be possible to hide all of this from the hosts on a subnet, by placing
all the functionality on an access gateway.


>> 3. The LIN6 specification also provides for the rendezvous function,
>> using DNS, which MAST chooses to defer. 

PN> We have removed rendezvous from the HIP base specifications, and
PN> plan to address is separately for first time rendezvous
PN> (using DNS) and for mobility (new infrastructure).

ok.


PN> To make reverse lookup work, some serious work is needed.

mumble.  yes.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Wed Sep 10 02:33:49 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19316
	for <multi6-archive@lists.ietf.org>; Wed, 10 Sep 2003 02:33:48 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wyXP-00007T-V9
	for multi6-data@psg.com; Wed, 10 Sep 2003 06:33:11 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19wyXN-000076-Qe
	for multi6@ops.ietf.org; Wed, 10 Sep 2003 06:33:09 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8A6c6P06599;
	Tue, 9 Sep 2003 23:38:07 -0700
Date: Tue, 9 Sep 2003 23:33:01 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <12056160494.20030909233301@brandenburg.com>
To: Fumio Teraoka <tera@ics.keio.ac.jp>
CC: multi6@ops.ietf.org
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
In-Reply-To: <5.1.1.9.2.20030909213202.056ec170@127.0.0.1>
References: <11438719956.20030906195815@brandenburg.com>
 <5.1.1.9.2.20030909213202.056ec170@127.0.0.1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: base64
X-Spam-Status: No, hits=2.3 required=5.0
	tests=BASE64_ENC_TEXT,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Level: **
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: base64

RnVtaW8tc2FuLA0KDQoNClRoYW5rIHlvdSBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLiAgKEl0
IHdhcyBub3QgbGF0ZSBhdCBhbGwuKQ0KDQoNCkZUPiBMSU42IGludHJvZHVjZXMgYSA2NC1i
aXQgIm5vZGUgaWRlbnRpZmllciAobm9kZSBpZCkiIHdoaWNoIGlzDQpGVD4gYXNzaWduZWQg
dG8gYSBub2RlLiBUaGUgbm9kZSBpZCBpcyBub3Qgb25seSBhIHRyYW5zcG9ydCBsYXllcg0K
RlQ+IGlkZW50aWZpZXIuIFRoZSBub2RlIGlkIGluIExJTjYgaXMgdXNlZCBpbiB0aGUgYXBw
bGljYXRpb24gbGF5ZXIsDQpGVD4gdGhlIHRyYW5zcG9ydCBsYXllciwgYW5kIHRoZSBuZXR3
b3JrIGxheWVyIChwb3NzaWJseSwgaW4gdGhlIGxpbmsNCkZUPiBsYXllcikuDQoNCkFsdGhv
dWdoIHRoZSBub2RlIGlkIG1pZ2h0IGNvbWUgZnJvbSB0aGUgbGluayBsYXllciBpZCwgaXQg
dGFrZXMgb24gaXRzDQpwcm9wZXJ0eSBhcyBhIExJTjYgbm9kZSBpZCBpbiB0aGUgTElONiBt
b2R1bGUuIEkgZGlkIG5vdCBzZWUgdGhhdCBpdCB3YXMgdXNlZA0KaW4gdGhlIElQIGxheWVy
LiBIYXZlIEkgbWlzc2VkIHNvbWV0aGluZz8NCg0KTGV0IG1lIGV4cGxhaW4gd2h5IEkgYW0g
Y2FsbGluZyB0aGUgTElONiBub2RlIGlkIGEgdHJhbnNwb3J0LWxldmVsIHZhbHVlOg0KDQpG
cm9tIG15IHJlYWRpbmcgb2YgdGhlIExJTjYgc3BlY2lmaWNhdGlvbiwgSSBiZWxpZXZlIHRo
YXQgdGhlIHByaW1hcnkgcHVycG9zZQ0Kb2YgdGhlIG5vZGUgaWQgaXMgZm9yIHRoZSB0cmFu
c3BvcnQgbGF5ZXIsIHNvIHRoYXQgdGhlIHRyYW5zcG9ydCBsYXllciB3aWxsDQpub3Qgc2Vl
IHRoZSBjaGFuZ2luZyBJUCBhZGRyZXNzZXMuIFllcywgaXQgbWlnaHQgYWxzbyBiZSBwYXNz
ZWQgdXAgdG8gdGhlDQphcHBsaWNhdGlvbiwgYnV0IHRoYXQgaXMgbm90IGl0cyBwcmltYXJ5
IHB1cnBvc2Ugb3IgdXNlLiBJUCBhZGRyZXNzZXMgYWxzbyBnZXQNCnBhc3NlZCB0byBhcHBs
aWNhdGlvbiwgYnV0IHdlIGNvbnNpZGVyIHRoZW0gYSBJbnRlcm5ldC1sYXllciB2YWx1ZS4N
Cg0KU28sIHllcywgb25lIGNvdWxkIGNhbGwgdGhlIG5vZGUgaWQgYSBuZXR3b3JrLWxldmVs
IHZhbHVlLiBPciBhDQp0cmFuc3BvcnQtYW5kLWFib3ZlIHZhbHVlLiAgQXMgSSB3YXMgcmVh
ZGluZyBMSU42LCBJIGZvdW5kIGl0IG1vcmUgaGVscGZ1bA0Kc2ltcGx5IHRvIHRoaW5rIG9m
IGl0IGFzIGEgdHJhbnNwb3J0LWxldmVsIHZhbHVlLg0KDQoNCg0KDQpkLw0KLS0NCiBEYXZl
IENyb2NrZXIgPGRjcm9ja2VyLWF0LWJyYW5kZW5idXJnLWRvdC1jb20+DQogQnJhbmRlbmJ1
cmcgSW50ZXJuZXRXb3JraW5nIDx3d3cuYnJhbmRlbmJ1cmcuY29tPg0KIFN1bm55dmFsZSwg
Q0EgIFVTQSA8dGVsOisxLjQwOC4yNDYuODI1Mz4NCg==




From owner-multi6@ops.ietf.org  Wed Sep 10 03:25:36 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20850
	for <multi6-archive@lists.ietf.org>; Wed, 10 Sep 2003 03:25:36 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19wzGh-0004fY-5a
	for multi6-data@psg.com; Wed, 10 Sep 2003 07:19:59 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19wzGc-0004en-C7
	for multi6@ops.ietf.org; Wed, 10 Sep 2003 07:19:54 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309100712.QAA08253@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id QAA08253; Wed, 10 Sep 2003 16:12:07 +0900
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
In-Reply-To: <12056160494.20030909233301@brandenburg.com> from Dave Crocker at
 "Sep 9, 2003 11:33:01 pm"
To: Dave Crocker <dcrocker@brandenburg.com>
Date: Wed, 10 Sep 2003 16:12:06 +0859 ()
CC: Fumio Teraoka <tera@ics.keio.ac.jp>, multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=0.0 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Dave;

> So, yes, one could call the node id a network-level value. Or a
> transport-and-above value.  As I was reading LIN6, I found it more helpful
> simply to think of it as a transport-level value.

You are arguing that one could call a host identification function of
a host address is at network-level or transport-and-above and that
it is more helpful simply to think of it at transport-level.

The argument is obviously wrong.

> I did not see that it was used
> in the IP layer. Have I missed something?

Yes, it is and you have.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Wed Sep 10 04:33:44 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22686
	for <multi6-archive@lists.ietf.org>; Wed, 10 Sep 2003 04:33:44 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19x0MH-000BIc-PP
	for multi6-data@psg.com; Wed, 10 Sep 2003 08:29:49 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19x0MD-000BI4-Ft
	for multi6@ops.ietf.org; Wed, 10 Sep 2003 08:29:45 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309100821.RAA08807@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id RAA08807; Wed, 10 Sep 2003 17:21:10 +0900
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <20030909142722.GA28569@alicia.nttmcl.com> from "Eugene M. Kim"
 at "Sep 9, 2003 07:27:27 am"
To: "Eugene M. Kim" <gene@nttmcl.com>
Date: Wed, 10 Sep 2003 17:21:09 +0859 ()
CC: Dave Crocker <dcrocker@brandenburg.com>, multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=0.0 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Eugene;

> Granted, we need some architecturally solid and sound solution, i.e. the
> ultimate, long-term goal, to the ID/LOC problem.  However, that will
> probably mean introducing a new namespace for either identifier or
> locator (depending on which purpose we decide to use the current IP
> address space for), and applications must adapt itself to the new world
> order.

Granted, we need some architecturally solid and sound solution, i.e. the
ultimate, long-term goal, to the address exhaustion problem.  However,
that will probably mean changing the IP protocol and applications must
adapt itself to the new world order.

And, NAT was introduced.

> I do hate NAT,

You don't, really.

						Masataka Ohta

PS

With proper API, most applications works as is even with ID/LOC
separation.



From owner-multi6@ops.ietf.org  Wed Sep 10 07:15:07 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25597
	for <multi6-archive@lists.ietf.org>; Wed, 10 Sep 2003 07:15:07 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19x2q3-000OtU-ER
	for multi6-data@psg.com; Wed, 10 Sep 2003 11:08:43 +0000
Received: from [212.68.5.99] (helo=n97.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 19x2pW-000Opx-Lu
	for multi6@ops.ietf.org; Wed, 10 Sep 2003 11:08:10 +0000
Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id DE2801C; Wed, 10 Sep 2003 14:21:32 +0300 (EEST)
Message-ID: <3F5F0619.8010003@nomadiclab.com>
Date: Wed, 10 Sep 2003 14:08:09 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: multi6@ops.ietf.org
Subject: Re: Mast vs HIP (was Re: Comments on draft-crocker-mast-proposal-00.txt)
References: <11438719956.20030906195815@brandenburg.com> <3F5C6037.6010403@nomadiclab.com> <7255593018.20030909232333@brandenburg.com>
In-Reply-To: <7255593018.20030909232333@brandenburg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-2.2 required=5.0
	tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave Crocker wrote:
> PN> What HIP does not do that well is IPv4 API support.  That is,
> PN> while most current IPv4 applications will work just fine,
> PN> including the most common FTP scenarios, there are applications
> PN> and use cases where HIP may (mostly indeterministically) fail.
> 
> I assume the problematic applications are those that embed IP addresses in
> them. What others are there?

There are two classes of IPv4 applications that will have problems
with HIP:

  1. Applications that embed addresses in application datagrams,
     e.g., FTP and SIP.  These will mostly work, but will in some
     fairly rare corner cases fail, sometimes "mysteriously".  (With
     "mysteriosly" I mean that the user is likely to be confused.)

  2. Applications that interpret the structure of IP addresses and
     try to understand it.  Many of these will work, too, since
     HIP LSIs look like vanilla IPv4 unicast address from 1.0.0.0/8
     subnet.

As far as I can see, all other IPv4 applications should just work.

What comes to IPv6 applications, the probability of the above
mentioned "mysterious" failures becomes so low that it can be
safely ignored.  (Less than the probablity of randomly picking
a given atom in the universe, or in the order of 2^-250.)  On the
other hand, administrative applications that do interpret the
structure of IP addresses probably need to be updated.

> PN> Actually, HIP is even slightly more ambitious here.  It aims
> PN> to provide application interoperability between the IPv4 and
> PN> IPv6 APIs.  That is, with HIP an IPv4 client can talk directly
> PN> to an IPv6 server,
> 
> I do not recall seeing the HIP specification call for IPv4/IPv6 packet
> translation.  So I do not see how an IPv4-only host can talk with an IPv6-only
> host, as a consequence of their both using HIP.  Where is this described in
> the specification?

If you have a HIP aware IPv4-IPv6 NAT box, why not?  Such a
NAT box just NAPTs the IP headers, leaving the ESP and its
content untouched.  (No, this has not been explicitly defined
in the specifications yet, but it should be fairly trivial.  See also
http://www.tml.hut.fi/~pnr/HIP/draft-nikander-hip-nat-00.txt )

> Hmmm.  Thinking a bit more, I think you mean IPv4 _application_, running on a
> host that has IPv6, or vice-versa.  This would be expected to work because HIP
> maps all address to a common type, from the perspective of the application.

Exactly.  See draft-moskowitz-hip-07.txt, Section 3.5.

> (Sounds like a NAT between IP and Transport, doesn't it?)

Well, one view to HIP is that HIP contains a specialized form of
Bellovin's HostNAT.  See also
http://www.tml.hut.fi/~pnr/BEET/draft-nikander-esp-beet-mode-00.txt
(Another draft that I haven't submitted yet.)

> When an application opens a connection by specifying the target's domain name,
> I can see this working.  When the application does the DNS query and then
> hands to address to TCP to do the open, there will be a problem, no?  The
> application has to carry the address for a brief time.

When an application does a DNS query, it gets an LSI or a HIT as
a result.  An easy change to the DNS library.

> HITs are a new, global name space.  Hence there needs to be a new, global
> administrative structure for managing HIT assignments.
> 
> And that's where things get confusing for me.  If HIP works with
> randomly-generated HITs, then why are globally-assigned ones needed?

There are two types of HITs.  The randomly generated ones are those
that are specified in the current base spec.  A previous version of
the base spec also defined globally-assigned ones, but that has been
moved to a future specification due to dependencies with the DNS.
The base specification only contains a placeholder for the
globally-assigned ones.

I have to admit that I don't really remember the reason for having
globally-assigned ones.  Bob should be able to answer, though.
(Here I will just carry on Bob's ideas and make sure that
the HIP-DNS spec will define the globally-assigned ones in
a precise enough way.)

> ....  I must admit that
> a scheme that calls for up to 3 different strings, to refer to the same thing
> -- in addition to domain name and IP address(es) -- strikes me as rather
> daunting.

Sometimes you have to pay a price for backwards compatibility.  I have
a student working on a native AF_HIP socket API.

--Pekka Nikander





From owner-multi6@ops.ietf.org  Wed Sep 10 12:33:26 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07017
	for <multi6-archive@lists.ietf.org>; Wed, 10 Sep 2003 12:33:26 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19x7pp-000KD6-Hx
	for multi6-data@psg.com; Wed, 10 Sep 2003 16:28:49 +0000
Received: from [216.69.69.10] (helo=alicia.nttmcl.com)
	by psg.com with esmtp (Exim 4.22)
	id 19x7pK-000KAW-3P
	for multi6@ops.ietf.org; Wed, 10 Sep 2003 16:28:18 +0000
Received: from alicia.nttmcl.com (localhost [127.0.0.1])
	by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h8AGS6HB003510;
	Wed, 10 Sep 2003 09:28:06 -0700 (PDT)
	(envelope-from gene@alicia.nttmcl.com)
Received: (from gene@localhost)
	by alicia.nttmcl.com (8.12.9/8.12.5/Submit) id h8AGS3K0003509;
	Wed, 10 Sep 2003 09:28:03 -0700 (PDT)
	(envelope-from gene)
Date: Wed, 10 Sep 2003 09:28:03 -0700
From: "Eugene M. Kim" <gene@nttmcl.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: Dave Crocker <dcrocker@brandenburg.com>, multi6@ops.ietf.org
Subject: Re: Fwd: A comment about MAST
Message-ID: <20030910162803.GA2295@alicia.nttmcl.com>
References: <20030909142722.GA28569@alicia.nttmcl.com> <200309100821.RAA08807@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200309100821.RAA08807@necom830.hpcl.titech.ac.jp>
User-Agent: Mutt/1.4i
X-Spam-Status: No, hits=-5.0 required=5.0
	tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Sorry, you seem to have filtered `this isn't some 10 years ago' part.  I
do admit that MAST is strikingly similar to NAT in a sense you have
pointed out below.  What intended to be a short term solution becoming
prevalent.  Yes, very unfortunate.

Now, what led to that NAT havoc?  IMO there are two reasons.  One is
lack of the long-term solution developed in reasonable timeline, and
the other is difficulty of phasing out NAT.  The former is as simple as
developing a new solution (which I hope is something we are here for :p)
so I don't think it is too terrible a situation for it's a ball in our
hands.

The latter is what people might be worried about, because, if MAST is as
hard to phase out as NAT is, it will be very frustrating when we finally
have the real solution ready for deployment.  But no, IMO, MAST is a lot
less harmful than NAT is in that sense.

NAT affects the entire network design, namely what address is being
allocated to each and every machine in the network.  Having to redesign
and reconfigure an entire network is every network administrator's
nightmare, especially considering what will result in when he makes a
mistake doing so (which is an entire network broken, of course).  So,
unless there is a *very* compelling reason that affects the everyday
operation, they will simply refuse to give up NAT.

However, MAST does not affect the network design and configuration
because it is a host-to-host protocol.  That means there will be a lot
less network structural changes, and in turn, less administrative
overhead, less headache for administrators.  They will have to upgrade
networking stack of operating systems running on their machines, but
they don't have to do it all at once (provided the new solution can
coexist with MAST, which I think must be done and is not terribly hard
to achieve); they can start upgrading less critical machines first, one
by one, then they can tackle more critical machines.  As you see here, a
conservative and gradual phase-out is possible, making its risk a lot
lower than phase-out risk of NAT.

Finally, I'm afraid I cannot fully see what you said in your postscript;
could you elaborate?

Eugene

P.S. Yes, I do hate NAT.  I just try to have a calmed-down view about
it, so I don't hate things just because they resemble NAT in some
aspect. =)

On Wed, Sep 10, 2003 at 05:21:09PM +0859, Masataka Ohta wrote:
> Eugene;
> 
> > Granted, we need some architecturally solid and sound solution, i.e. the
> > ultimate, long-term goal, to the ID/LOC problem.  However, that will
> > probably mean introducing a new namespace for either identifier or
> > locator (depending on which purpose we decide to use the current IP
> > address space for), and applications must adapt itself to the new world
> > order.
> 
> Granted, we need some architecturally solid and sound solution, i.e. the
> ultimate, long-term goal, to the address exhaustion problem.  However,
> that will probably mean changing the IP protocol and applications must
> adapt itself to the new world order.
> 
> And, NAT was introduced.
> 
> > I do hate NAT,
> 
> You don't, really.
> 
> 						Masataka Ohta
> 
> PS
> 
> With proper API, most applications works as is even with ID/LOC
> separation.



From owner-multi6@ops.ietf.org  Wed Sep 10 23:55:08 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28589
	for <multi6-archive@lists.ietf.org>; Wed, 10 Sep 2003 23:55:08 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xITL-0006le-Vf
	for multi6-data@psg.com; Thu, 11 Sep 2003 03:50:19 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19xISp-0006hJ-Gd
	for multi6@ops.ietf.org; Thu, 11 Sep 2003 03:49:47 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309110340.MAA15613@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id MAA15613; Thu, 11 Sep 2003 12:40:10 +0900
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <20030910162803.GA2295@alicia.nttmcl.com> from "Eugene M. Kim" at
 "Sep 10, 2003 09:28:03 am"
To: "Eugene M. Kim" <gene@nttmcl.com>
Date: Thu, 11 Sep 2003 12:40:09 +0859 ()
CC: Dave Crocker <dcrocker@brandenburg.com>, multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Eugene;

> Sorry, you seem to have filtered `this isn't some 10 years ago' part.  I
> do admit that MAST is strikingly similar to NAT in a sense you have
> pointed out below.  What intended to be a short term solution becoming
> prevalent.  Yes, very unfortunate.

A permanent solution which does not require any change to
most applicaitons already desinged, implemented and has been running
for more than a year.

> Now, what led to that NAT havoc?  IMO there are two reasons.  One is
> lack of the long-term solution developed in reasonable timeline, and
> the other is difficulty of phasing out NAT.

> NAT affects the entire network design, namely what address is being
> allocated to each and every machine in the network.  Having to redesign
> and reconfigure an entire network is every network administrator's
> nightmare,

Wrong.

Removal of NAT boxes is as easy as upgrading of routers.

The difficulty is in reconfiguring all the end systems.

But, that is not you argument, at all.

You proposed to have API to accomodate MAST which also accomodate NAT,
which shows your love for NAT.

Your proposal is to keep MAST and NAT forever.

> Finally, I'm afraid I cannot fully see what you said in your postscript;
> could you elaborate?

Just say LIN6.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Thu Sep 11 01:24:38 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29839
	for <multi6-archive@lists.ietf.org>; Thu, 11 Sep 2003 01:24:37 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xJt9-000B03-Fk
	for multi6-data@psg.com; Thu, 11 Sep 2003 05:21:03 +0000
Received: from [216.69.69.10] (helo=alicia.nttmcl.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xJt3-000Azc-Ck
	for multi6@ops.ietf.org; Thu, 11 Sep 2003 05:20:57 +0000
Received: from alicia.nttmcl.com (localhost [127.0.0.1])
	by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h8B5KkHB022523;
	Wed, 10 Sep 2003 22:20:46 -0700 (PDT)
	(envelope-from gene@alicia.nttmcl.com)
Received: (from gene@localhost)
	by alicia.nttmcl.com (8.12.9/8.12.5/Submit) id h8B5KkV4022522;
	Wed, 10 Sep 2003 22:20:46 -0700 (PDT)
	(envelope-from gene)
Date: Wed, 10 Sep 2003 22:20:46 -0700
From: "Eugene M. Kim" <gene@nttmcl.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: Dave Crocker <dcrocker@brandenburg.com>, multi6@ops.ietf.org
Subject: Re: Fwd: A comment about MAST
Message-ID: <20030911052046.GA22377@alicia.nttmcl.com>
References: <20030910162803.GA2295@alicia.nttmcl.com> <200309110340.MAA15613@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200309110340.MAA15613@necom830.hpcl.titech.ac.jp>
User-Agent: Mutt/1.4i
X-Spam-Status: No, hits=-5.8 required=5.0
	tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES,
	      USER_AGENT_MUTT
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

On Thu, Sep 11, 2003 at 12:40:09PM +0859, Masataka Ohta wrote:
> But, that is not you argument, at all.
> 
> You proposed to have API to accomodate MAST which also accomodate NAT,
> which shows your love for NAT.
> 
> Your proposal is to keep MAST and NAT forever.

I don't understand.  What I proposed is an API that communicates socket
endpoint address changes to the application layer; how does that API
accomodate/facilitate NAT?

> 
> > Finally, I'm afraid I cannot fully see what you said in your postscript;
> > could you elaborate?
> 
> Just say LIN6.

Thank you for the pointer. =)

Eugene



From owner-multi6@ops.ietf.org  Thu Sep 11 02:44:32 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13516
	for <multi6-archive@lists.ietf.org>; Thu, 11 Sep 2003 02:44:32 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xL7w-000ER3-1G
	for multi6-data@psg.com; Thu, 11 Sep 2003 06:40:24 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19xL7Q-000EPE-GY
	for multi6@ops.ietf.org; Thu, 11 Sep 2003 06:39:52 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309110624.PAA16159@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id PAA16159; Thu, 11 Sep 2003 15:23:49 +0859
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <20030911052046.GA22377@alicia.nttmcl.com> from "Eugene M. Kim"
 at "Sep 10, 2003 10:20:46 pm"
To: "Eugene M. Kim" <gene@nttmcl.com>
Date: Thu, 11 Sep 2003 15:23:49 +0859 ()
CC: Dave Crocker <dcrocker@brandenburg.com>, multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Eugene;

> > Your proposal is to keep MAST and NAT forever.
> 
> I don't understand.  What I proposed is an API that communicates socket
> endpoint address changes to the application layer; how does that API
> accomodate/facilitate NAT?

Read ML log for my past reply.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Thu Sep 11 16:49:43 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13229
	for <multi6-archive@lists.ietf.org>; Thu, 11 Sep 2003 16:49:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xYKL-000P7d-KY
	for multi6-data@psg.com; Thu, 11 Sep 2003 20:46:05 +0000
Received: from [216.69.69.10] (helo=alicia.nttmcl.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xYIH-000Osq-LH
	for multi6@ops.ietf.org; Thu, 11 Sep 2003 20:43:57 +0000
Received: from daal (dhcp245.nttmcl.com [216.69.69.245])
	by alicia.nttmcl.com (8.12.9/8.12.5) with SMTP id h8BKhrHB039035;
	Thu, 11 Sep 2003 13:43:54 -0700 (PDT)
	(envelope-from gene@nttmcl.com)
Message-ID: <003101c378a5$681c54d0$f54545d8@daal>
From: "Eugene M. Kim" <gene@nttmcl.com>
To: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp>
Cc: <multi6@ops.ietf.org>
References: <200309110624.PAA16159@necom830.hpcl.titech.ac.jp>
Subject: Re: Fwd: A comment about MAST
Date: Thu, 11 Sep 2003 13:43:49 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=-0.4 required=5.0
	tests=QUOTED_EMAIL_TEXT,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

If you meant your original reply to what Dave forwarded here, all that
there is seems to be `This argument is so similar to what NAT lovers say
(in order to defend NAT), so it must be automatically shot down.'  I can
see your frustration there, but it would be appreciated if you gave a
technical, not political, insight about how the proposed API for MAST
also technically, not politically, accomodated NAT.

If you were referring not to that post but to an earlier one, could you
give a pointer?  It's almost impossible to read all your posts here one
by one over a slow HTML archive.

BTW, is there an archive of this list in plain UNIX mbox format? (-- to
other ML subscribers)

Thanks,
Eugene

----- Original Message ----- 
From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp>
To: "Eugene M. Kim" <gene@nttmcl.com>
Cc: "Dave Crocker" <dcrocker@brandenburg.com>; <multi6@ops.ietf.org>
Sent: Wednesday, September 10, 2003 11:24 PM
Subject: Re: Fwd: A comment about MAST


> Eugene;
>
> > > Your proposal is to keep MAST and NAT forever.
> >
> > I don't understand.  What I proposed is an API that communicates
socket
> > endpoint address changes to the application layer; how does that API
> > accomodate/facilitate NAT?
>
> Read ML log for my past reply.
>
> Masataka Ohta
>




From owner-multi6@ops.ietf.org  Thu Sep 11 19:14:13 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18002
	for <multi6-archive@lists.ietf.org>; Thu, 11 Sep 2003 19:14:13 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xaZe-000Ahz-PA
	for multi6-data@psg.com; Thu, 11 Sep 2003 23:10:02 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19xaZJ-000Ah0-Ay
	for multi6@ops.ietf.org; Thu, 11 Sep 2003 23:09:41 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309112244.HAA20354@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id HAA20354; Fri, 12 Sep 2003 07:44:44 +0900
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <003101c378a5$681c54d0$f54545d8@daal> from "Eugene M. Kim" at "Sep
 11, 2003 01:43:49 pm"
To: "Eugene M. Kim" <gene@nttmcl.com>
Date: Fri, 12 Sep 2003 07:44:42 +0859 ()
CC: multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=0.4 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Eugene;

My mail reader says on your mail:

	[Charset ks_c_5601-1987 unsupported, skipping...]

Use ASCII.

						Masataka Ohta

PS

ISO-8859-1, which some people are carelessly (or arrogantly?) using,
is also bad, though my mailer filters out non-ASCII part.



From owner-multi6@ops.ietf.org  Thu Sep 11 20:02:59 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19274
	for <multi6-archive@lists.ietf.org>; Thu, 11 Sep 2003 20:02:59 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xbM5-000EC8-4E
	for multi6-data@psg.com; Fri, 12 Sep 2003 00:00:05 +0000
Received: from [216.69.69.10] (helo=alicia.nttmcl.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xbLZ-000E8G-SM
	for multi6@ops.ietf.org; Thu, 11 Sep 2003 23:59:33 +0000
Received: from daal (dhcp245.nttmcl.com [216.69.69.245])
	by alicia.nttmcl.com (8.12.9/8.12.5) with SMTP id h8BNwGHB043394;
	Thu, 11 Sep 2003 16:58:16 -0700 (PDT)
	(envelope-from gene@nttmcl.com)
Message-ID: <009101c378c0$916ed680$f54545d8@daal>
From: "Eugene M. Kim" <gene@nttmcl.com>
To: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp>
Cc: <multi6@ops.ietf.org>
References: <200309112244.HAA20354@necom830.hpcl.titech.ac.jp>
Subject: Re: Fwd: A comment about MAST
Date: Thu, 11 Sep 2003 16:58:08 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=-0.4 required=5.0
	tests=QUOTED_EMAIL_TEXT,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Oops, sorry, especially if a lot of other people could not read the
message either (although KSC 5601-1987, or KS X 1001, is backwards
compatible with ASCII with just one exception; the backslash is
displayed as the Korean currency sign).

Anyhow, here's the link from the web archive:
http://ops.ietf.org/lists/multi6/multi6.2003/msg01598.html (displays in
ISO 8859-1).

Eugene

----- Original Message ----- 
From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp>
To: "Eugene M. Kim" <gene@nttmcl.com>
Cc: <multi6@ops.ietf.org>
Sent: Thursday, September 11, 2003 3:45 PM
Subject: Re: Fwd: A comment about MAST


> Eugene;
>
> My mail reader says on your mail:
>
> [Charset ks_c_5601-1987 unsupported, skipping...]
>
> Use ASCII.
>
> Masataka Ohta
>
> PS
>
> ISO-8859-1, which some people are carelessly (or arrogantly?) using,
> is also bad, though my mailer filters out non-ASCII part.
>




From owner-multi6@ops.ietf.org  Fri Sep 12 02:26:43 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10276
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 02:26:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xhHd-000BoW-31
	for multi6-data@psg.com; Fri, 12 Sep 2003 06:19:53 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19xhHW-000Bo8-FK
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 06:19:46 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309120606.PAA22073@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id PAA22073; Fri, 12 Sep 2003 15:06:16 +0900
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <009101c378c0$916ed680$f54545d8@daal> from "Eugene M. Kim" at "Sep
 11, 2003 04:58:08 pm"
To: "Eugene M. Kim" <gene@nttmcl.com>
Date: Fri, 12 Sep 2003 15:06:15 +0859 ()
CC: multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=0.0 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Eugene;

My mail reader now complains:

	[Charset iso-8859-1 unsupported, filtering to ASCII...]

> Oops, sorry, especially if a lot of other people could not read the
> message either (although KSC 5601-1987, or KS X 1001, is backwards
> compatible with ASCII with just one exception; the backslash is
> displayed as the Korean currency sign).

ISO-8859-1 includes 96 characters with 8th bit on and is local
to scripts of western europe that it is worse than KSC 5601-1987 for
the International communication.

Use ASCII.

> Anyhow, here's the link from the web archive:
> http://ops.ietf.org/lists/multi6/multi6.2003/msg01598.html (displays in
> ISO 8859-1).

OK. My comment on the API extension is right on the thread at:

	http://ops.ietf.org/lists/multi6/multi6.2003/msg01586.html

I'm afraind you still don't recognize the technical nature of the API.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Fri Sep 12 11:17:51 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28193
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 11:17:50 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xpcp-000PQx-8T
	for multi6-data@psg.com; Fri, 12 Sep 2003 15:14:19 +0000
Received: from [216.69.69.10] (helo=alicia.nttmcl.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xpcI-000PP4-Fb
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 15:13:46 +0000
Received: from alicia.nttmcl.com (localhost [127.0.0.1])
	by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h8CFDgHB060019;
	Fri, 12 Sep 2003 08:13:42 -0700 (PDT)
	(envelope-from gene@alicia.nttmcl.com)
Received: (from gene@localhost)
	by alicia.nttmcl.com (8.12.9/8.12.5/Submit) id h8CFDgYM060018;
	Fri, 12 Sep 2003 08:13:42 -0700 (PDT)
	(envelope-from gene)
Date: Fri, 12 Sep 2003 08:13:42 -0700
From: "Eugene M. Kim" <gene@nttmcl.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: multi6@ops.ietf.org
Subject: Re: Fwd: A comment about MAST
Message-ID: <20030912151341.GA59651@alicia.nttmcl.com>
References: <009101c378c0$916ed680$f54545d8@daal> <200309120606.PAA22073@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200309120606.PAA22073@necom830.hpcl.titech.ac.jp>
User-Agent: Mutt/1.4i
X-Spam-Status: No, hits=-6.7 required=5.0
	tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Hello,

Thank you for the pointer.

If I understood you correctly, your concern seems to be that, with the
proposed MAST API, some applications are required to be modified just to
suit MAST as they had to with NAT.  Is this correct?

Assuming the answer is yes, I still don't think it's a definitively
prohibiting reason against the API.  I say this under the assumption
that MAST will be just a transition protocol, or a stopgap, with which,
again, simple applications can work without any modifications.  I am
also assuming that MAST will be deprecated in a strong manner with,
for example, a MUST clause in a formal deprecation document.

With these two assumptions, authors of complicated application (i.e.
those that must be modified to take advantage of MAST) have two choices:

1. They wait until the long-term solution is established, then opt for
the new solution, once and for good.
2. They first opt for MAST, then later switch to the new solution.

Opting for MAST and not switching to the new solution is not an option
here because MAST will be deprecated (for example, it will not be part
of newer operating systems).

One may argue that `application authors will try to save time by
just waiting for the new solution, so the MAST API does not have any
merit'.  However, I do think that there will be a number of application
authors who feel they need MAST despite the additional work involved
because they decide that the amount of work is outweighed by other
reasons that call for MAST, e.g. customer feedback/market pressure.

Thanks,
Eugene

On Fri, Sep 12, 2003 at 03:06:15PM +0859, Masataka Ohta wrote:
> Eugene;
> 
> > Anyhow, here's the link from the web archive:
> > http://ops.ietf.org/lists/multi6/multi6.2003/msg01598.html (displays in
> > ISO 8859-1).
> 
> OK. My comment on the API extension is right on the thread at:
> 
> 	http://ops.ietf.org/lists/multi6/multi6.2003/msg01586.html
> 
> I'm afraind you still don't recognize the technical nature of the API.
> 
> 							Masataka Ohta



From owner-multi6@ops.ietf.org  Fri Sep 12 12:00:57 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29402
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 12:00:57 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xqLG-0003j7-B7
	for multi6-data@psg.com; Fri, 12 Sep 2003 16:00:14 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19xqL7-0003gY-S5
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 16:00:06 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309121548.AAA00736@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id AAA00736; Sat, 13 Sep 2003 00:48:21 +0900
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <20030912151341.GA59651@alicia.nttmcl.com> from "Eugene M. Kim"
 at "Sep 12, 2003 08:13:42 am"
To: "Eugene M. Kim" <gene@nttmcl.com>
Date: Sat, 13 Sep 2003 00:48:20 +0859 ()
CC: multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=0.0 required=5.0
	tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Eugene;

> If I understood you correctly, your concern seems to be that, with the
> proposed MAST API, some applications are required to be modified just to
> suit MAST as they had to with NAT.  Is this correct?

Wrong. There is no MAST API. It is NAT API. Applications for the API
is, behind NAT, notified address of a NAT box and tell it to its peer.

Of course, application on the peer also need modification, which is
practically impossible.

Try to design the API of a host and its peer, for example, for FTP.

> Assuming the answer is yes, I still don't think it's a definitively
> prohibiting reason against the API.  I say this under the assumption
> that MAST will be just a transition protocol, or a stopgap, with which,
> again, simple applications can work without any modifications.

You miss the point that MAST does not solve *THE* problem
and is useless even as an intermediate solution.

Worse, you miss the other point that no intermediate solution
is necessary.

Worst, your hidden assumption is that almost all the hosts use MAST,
which is not a sound assumption for an intermediate, if any, solution.

> With these two assumptions, authors of complicated application (i.e.
> those that must be modified to take advantage of MAST) have two choices:

Completely wrong.

Those applications that must be modified to take advantage of
multihoming with multiple addresses have a single choice to
be modified so with no further modification.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Fri Sep 12 12:40:07 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02889
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 12:40:06 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xqvZ-0006rr-N6
	for multi6-data@psg.com; Fri, 12 Sep 2003 16:37:45 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xqvN-0006qy-36
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 16:37:33 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8CGgWP20328;
	Fri, 12 Sep 2003 09:42:32 -0700
Date: Fri, 12 Sep 2003 09:37:24 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: dcrocker@brandenburg.com
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <1268624727.20030912093724@brandenburg.com>
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
CC: multi6@ops.ietf.org
Subject: Re: Mast vs HIP (was Re: Comments on draft-crocker-mast-proposal-00.txt)
In-Reply-To: <3F5F0619.8010003@nomadiclab.com>
References: <11438719956.20030906195815@brandenburg.com>
 <3F5C6037.6010403@nomadiclab.com> <7255593018.20030909232333@brandenburg.com>
 <3F5F0619.8010003@nomadiclab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-0.8 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,
	      REFERENCES,REPLY_WITH_QUOTES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka,

>> PN> Actually, HIP is even slightly more ambitious here.  It aims
>> PN> to provide application interoperability between the IPv4 and
>> PN> IPv6 APIs.  That is, with HIP an IPv4 client can talk directly
>> PN> to an IPv6 server,
>> I do not recall seeing the HIP specification call for IPv4/IPv6 packet
>> translation.  So I do not see how an IPv4-only host can talk with an IPv6-only
>> host, as a consequence of their both using HIP.  Where is this described in
>> the specification?

PN> If you have a HIP aware IPv4-IPv6 NAT box, why not?

translating gateways that are aware of new services can usually cover a host
(small pun) of sins.

forgive me for suggesting that this is like saying that I can spend dollars in
EU countries.  all I need is to have a currency exchange in every EU store.


PN> Such a
PN> NAT box just NAPTs the IP headers, leaving the ESP and its
PN> content untouched.

The issue is how much change to the infrastructure is required, and when.


>> ....  I must admit that
>> a scheme that calls for up to 3 different strings, to refer to the same thing
>> -- in addition to domain name and IP address(es) -- strikes me as rather
>> daunting.

PN> Sometimes you have to pay a price for backwards compatibility.

And sometimes you don't.

This is yet-another reason MAST avoids a new public namespace,


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Fri Sep 12 13:41:49 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06450
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 13:41:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xrtI-000CRT-5s
	for multi6-data@psg.com; Fri, 12 Sep 2003 17:39:28 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xrsm-000COY-HR
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 17:38:56 +0000
Received: from bebop.France.Sun.COM ([129.157.174.15])
	by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h8CHcs1v009517;
	Fri, 12 Sep 2003 11:38:55 -0600 (MDT)
Received: from par (par.Eng.Sun.COM [129.146.89.82])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8CHcqQ26121;
	Fri, 12 Sep 2003 19:38:52 +0200 (MEST)
Date: Fri, 12 Sep 2003 10:38:46 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: multi6@ops.ietf.org
In-Reply-To: "Your message with ID" <11438719956.20030906195815@brandenburg.com>
Message-ID: <Roam.SIMC.2.0.6.1063388326.968.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Spam-Status: No, hits=-0.4 required=5.0
	tests=BAYES_30,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

> I had not known about the Purpose-Built Key internet-draft.  It seems perfect
> for the security MAST needs to provide, specifically to avoid hijacking the
> MAST association.

A perhaps useful data point is that during the exercise of securing MIPv6
binding updates to arbitrary correspondents I originally thought that
something  like PBK would be the result, but some careful anaylsis resulted in
a simpler  scheme which just uses 3-way handshake to effictive establish a
cookie. (Both PBK and MIPv6 with this technique are subject to MiTM attacks
by somebody on the path over which the packets travel, so the
resulting security is close to the same.)

YMMV - multihoming locator switching might have some other factors to
take into account when doing the tradeoffs on how to provide security.

  Erik




From owner-multi6@ops.ietf.org  Fri Sep 12 14:07:19 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07522
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 14:07:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xsGt-000F4T-Lh
	for multi6-data@psg.com; Fri, 12 Sep 2003 18:03:51 +0000
Received: from [212.68.5.99] (helo=n97.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xsFb-000EyX-Gk
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 18:02:31 +0000
Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id 5F33B1C; Fri, 12 Sep 2003 21:15:53 +0300 (EEST)
Message-ID: <3F620A37.6050409@nomadiclab.com>
Date: Fri, 12 Sep 2003 21:02:31 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dcrocker@brandenburg.com
Cc: multi6@ops.ietf.org
Subject: Re: Mast vs HIP (was Re: Comments on draft-crocker-mast-proposal-00.txt)
References: <11438719956.20030906195815@brandenburg.com> <3F5C6037.6010403@nomadiclab.com> <7255593018.20030909232333@brandenburg.com> <3F5F0619.8010003@nomadiclab.com> <1268624727.20030912093724@brandenburg.com>
In-Reply-To: <1268624727.20030912093724@brandenburg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-2.2 required=5.0
	tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,

Dave Crocker wrote:

>>> So I do not see how an IPv4-only host can talk with an IPv6-only
>>> host, as a consequence of their both using HIP.  Where is this described in
>>> the specification?
> 
> PN> If you have a HIP aware IPv4-IPv6 NAT box, why not?
> 
> translating gateways that are aware of new services can usually cover a host
> (small pun) of sins.
> 
> forgive me for suggesting that this is like saying that I can spend dollars in
> EU countries.  all I need is to have a currency exchange in every EU store.

Well, I would say that it is more like a service that allows us to
buy goods from US web stores using euros.  There just will be a box
in between which translates the dollar figures in euro figures,
and the bank will do the rest :-)  That is, you get the feeling that
you are using only euros, while you are not.  It is natural that
someone has to do something to make it work.

> The issue is how much change to the infrastructure is required, and when.

You have to pay a price for IPv4-IPv6 interoperability anyway.
If the HIP price is lower than the NATPT/SIIT/... price, it may
make HIP more acceptable or even lucrative at the market.

> PN> Sometimes you have to pay a price for backwards compatibility.
> 
> And sometimes you don't.

HIP may be slightly more expensive than something else, but you
get so much more in the box. :-) And better design quality, too :-)

Maybe HIP will be the mac while MAST the windows of this field :-)
You get what you pay for.  :-)

--Pekka





From owner-multi6@ops.ietf.org  Fri Sep 12 16:50:55 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15124
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 16:50:54 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xuoo-000HlL-8o
	for multi6-data@psg.com; Fri, 12 Sep 2003 20:47:02 +0000
Received: from [216.69.69.10] (helo=alicia.nttmcl.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xuoI-000Hgb-MH
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 20:46:30 +0000
Received: from alicia.nttmcl.com (localhost [127.0.0.1])
	by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h8CKkQHB068085;
	Fri, 12 Sep 2003 13:46:26 -0700 (PDT)
	(envelope-from gene@alicia.nttmcl.com)
Received: (from gene@localhost)
	by alicia.nttmcl.com (8.12.9/8.12.5/Submit) id h8CKkPAn068084;
	Fri, 12 Sep 2003 13:46:25 -0700 (PDT)
	(envelope-from gene)
Date: Fri, 12 Sep 2003 13:46:25 -0700
From: "Eugene M. Kim" <gene@nttmcl.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: multi6@ops.ietf.org
Subject: Re: Fwd: A comment about MAST
Message-ID: <20030912204625.GA64027@alicia.nttmcl.com>
References: <20030912151341.GA59651@alicia.nttmcl.com> <200309121548.AAA00736@necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200309121548.AAA00736@necom830.hpcl.titech.ac.jp>
User-Agent: Mutt/1.4i
X-Spam-Status: No, hits=-6.7 required=5.0
	tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

On Sat, Sep 13, 2003 at 12:48:20AM +0859, Masataka Ohta wrote:
> Eugene;
> 
> > If I understood you correctly, your concern seems to be that, with the
> > proposed MAST API, some applications are required to be modified just to
> > suit MAST as they had to with NAT.  Is this correct?
> 
> Wrong. There is no MAST API. It is NAT API. Applications for the API
> is, behind NAT, notified address of a NAT box and tell it to its peer.

Not verbatim.  In order for that to work, a new protocol is needed
between a NAT gateway and machines behind it so the gateway can notify
address changes to them.  To the best of my knowledge, none of the
existing IETF protocols do this, much less can MAST.  I think you are
worried about something that does not even exist.  If you or anyone else
could point me to an existing, widely implemented standard that serves
this purpose, I would stand corrected.

> 
> Of course, application on the peer also need modification, which is
> practically impossible.
> 
> Try to design the API of a host and its peer, for example, for FTP.

Do we have to modify FTP further than RFC 2428 in order to accomodate
MAST if it provided the API to get the up-to-date peer address for the
control connection?  If so, why?

> 
> > Assuming the answer is yes, I still don't think it's a definitively
> > prohibiting reason against the API.  I say this under the assumption
> > that MAST will be just a transition protocol, or a stopgap, with which,
> > again, simple applications can work without any modifications.
> 
> You miss the point that MAST does not solve *THE* problem
> and is useless even as an intermediate solution.

I'm afraid you did not communicate what was `*THE* problem' you were
trying to solve here.  And before putting your answer in a short phrase
such as `multihoming' or `roaming', please bear in mind that there are
people who lock on different facets of those vague subjects.

OT: Actually I was reading your E2E multihoming draft this morning then
encountered a similar problem; you apparently believed in the concept of
E2E by using phrases like `end to end _principle_' but failed to clarify
what `end-to-end' exactly implied.  If you meant some concept widely
believed in by other people, perhaps adding at the end of the draft a
reference to some other document that discusses the concept would help
the uninformed camp (including me) understand you and your proposal
better.

> 
> Worse, you miss the other point that no intermediate solution
> is necessary.

Only if we can come up with a real solution in rather a short timeframe.
I thought it would be rash to draft, implement and adopt something as a
standard in such a short timeframe that existing needs need not be met
at all in the meantime.

> 
> Worst, your hidden assumption is that almost all the hosts use MAST,
> which is not a sound assumption for an intermediate, if any, solution.

MAST does not worsen the case where one host knows MAST and the other
does not, because it is designed in such a way that it does not impede
the transport later without first verifying that the peer also knows how
to do it.  So it need not be worried about if the peer doesn't speak
MAST, because in that case MAST will not kick in but the communication
will proceed as if neither party knew MAST.

> 
> > With these two assumptions, authors of complicated application (i.e.
> > those that must be modified to take advantage of MAST) have two choices:
> 
> Completely wrong.
> 
> Those applications that must be modified to take advantage of
> multihoming with multiple addresses have a single choice to
> be modified so with no further modification.

Again, you seem to be assuming that we can come up with the long-term
solution in a really short timeframe.  Unless you can show me some
proposal is already up for that task, including deployment plans and
scenarios, I still think such an assumption is rash.

Thanks,
Eugene



From owner-multi6@ops.ietf.org  Fri Sep 12 17:21:39 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17166
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 17:21:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xvKW-000Nl0-GR
	for multi6-data@psg.com; Fri, 12 Sep 2003 21:19:48 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xvKD-000Nh1-CV
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 21:19:29 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8CLOAP05750;
	Fri, 12 Sep 2003 14:24:10 -0700
Date: Fri, 12 Sep 2003 14:19:03 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <17385523936.20030912141903@brandenburg.com>
To: "Eugene M. Kim" <gene@nttmcl.com>
CC: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>, multi6@ops.ietf.org
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <20030912204625.GA64027@alicia.nttmcl.com>
References: <20030912151341.GA59651@alicia.nttmcl.com>
 <200309121548.AAA00736@necom830.hpcl.titech.ac.jp>
 <20030912204625.GA64027@alicia.nttmcl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-0.8 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,
	      REFERENCES,REPLY_WITH_QUOTES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eugene, et al,

>> > If I understood you correctly, your concern seems to be that, with the
>> > proposed MAST API, some applications are required to be modified just to
>> > suit MAST as they had to with NAT.  Is this correct?
>> Wrong. There is no MAST API. It is NAT API. Applications for the API
>> is, behind NAT, notified address of a NAT box and tell it to its peer.

EMK> Not verbatim.  In order for that to work, a new protocol is needed
EMK> between a NAT gateway and machines behind it so the gateway can notify
EMK> address changes to them.

NAT boxes do address translation and MAST does address translation. In a very
theoretical sense there is, therefore, some similarity between them. However
MAST is not a "network" address translation service and it really has nothing
to do with the controversy surrounding NATs.

So I am not understanding criticism of MAST that is essentially a continuation
of the criticism about NATs.  They are separate and I think the debates should
be kept separate.

As for a "MAST API", none is needed.

MAST hides the multiple addresses from transport and above.  That is one of
its features.

I believe that any application protocol that uses direct IP addresses has a
problem with any multi-homing/mobility solution.

Also, as soon as the application needs to benefit from knowing about -- and
giving guidance about -- the availability of multiple addresses, then it needs
an be nice to enhanced API. That is true for any multi-addressing solution,
not just MAST.


EMK> To the best of my knowledge, none of the
EMK> existing IETF protocols do this, much less can MAST.

Correct.


EMK>   I think you are
EMK> worried about something that does not even exist.

Correct.


>> You miss the point that MAST does not solve *THE* problem
>> and is useless even as an intermediate solution.

EMK> I'm afraid you did not communicate what was `*THE* problem' you were
EMK> trying to solve here.

Yes, it would be nice to hear a clear and coherent description of "the"
problem.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Fri Sep 12 17:40:00 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17963
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 17:40:00 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xvaw-0000hT-Gx
	for multi6-data@psg.com; Fri, 12 Sep 2003 21:36:46 +0000
Received: from [216.69.69.10] (helo=alicia.nttmcl.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xvaR-0000dD-0H
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 21:36:15 +0000
Received: from alicia.nttmcl.com (localhost [127.0.0.1])
	by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h8CLaEHB069368;
	Fri, 12 Sep 2003 14:36:14 -0700 (PDT)
	(envelope-from gene@alicia.nttmcl.com)
Received: (from gene@localhost)
	by alicia.nttmcl.com (8.12.9/8.12.5/Submit) id h8CLaEiS069367;
	Fri, 12 Sep 2003 14:36:14 -0700 (PDT)
	(envelope-from gene)
Date: Fri, 12 Sep 2003 14:36:14 -0700
From: "Eugene M. Kim" <gene@nttmcl.com>
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: multi6@ops.ietf.org
Subject: Re: Fwd: A comment about MAST
Message-ID: <20030912213614.GB64027@alicia.nttmcl.com>
References: <20030912151341.GA59651@alicia.nttmcl.com> <200309121548.AAA00736@necom830.hpcl.titech.ac.jp> <20030912204625.GA64027@alicia.nttmcl.com> <17385523936.20030912141903@brandenburg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <17385523936.20030912141903@brandenburg.com>
User-Agent: Mutt/1.4i
X-Spam-Status: No, hits=-9.1 required=5.0
	tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,
	      REPLY_WITH_QUOTES,USER_AGENT_MUTT
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Dave,

On Fri, Sep 12, 2003 at 02:19:03PM -0700, Dave Crocker wrote:
> 
> NAT boxes do address translation and MAST does address translation. In a very
> theoretical sense there is, therefore, some similarity between them. However
> MAST is not a "network" address translation service and it really has nothing
> to do with the controversy surrounding NATs.
> 
> So I am not understanding criticism of MAST that is essentially a continuation
> of the criticism about NATs.  They are separate and I think the debates should
> be kept separate.

Agreed.

> 
> As for a "MAST API", none is needed.
> 
> MAST hides the multiple addresses from transport and above.  That is one of
> its features.

I see.  Looks like I misunderstood MAST in that sense. =)

> 
> I believe that any application protocol that uses direct IP addresses has a
> problem with any multi-homing/mobility solution.
> 
> Also, as soon as the application needs to benefit from knowing about -- and
> giving guidance about -- the availability of multiple addresses, then it needs
> an be nice to enhanced API. That is true for any multi-addressing solution,
> not just MAST.

Also agreed.

A random idea: How about making MAST support these two operating mode?

1. The original scenario, where the transport layer such as TCP does not
know how to handle multiple endpoint addresses nor requests MAST to
notify about address changes.  MAST operates as originally proposed in
this case.

2. The new scenario, where the transport layer such as TCP knows how to
handle multiple endpoint addresses and requests MAST to notify about
address changes.  MAST then propagates such changes up to the transport
layer, which, in turn, may decide to propagate such changes up to the
applications via a suitable API.  What I meant by `the MAST API' was,
in fact, this.

Thanks,
Eugene



From owner-multi6@ops.ietf.org  Fri Sep 12 17:45:03 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18095
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 17:45:02 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xvhA-0001t6-CG
	for multi6-data@psg.com; Fri, 12 Sep 2003 21:43:12 +0000
Received: from [216.69.69.10] (helo=alicia.nttmcl.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xvge-0001oi-9D
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 21:42:40 +0000
Received: from alicia.nttmcl.com (localhost [127.0.0.1])
	by alicia.nttmcl.com (8.12.9/8.12.5) with ESMTP id h8CLgaHB069503;
	Fri, 12 Sep 2003 14:42:36 -0700 (PDT)
	(envelope-from gene@alicia.nttmcl.com)
Received: (from gene@localhost)
	by alicia.nttmcl.com (8.12.9/8.12.5/Submit) id h8CLgao9069502;
	Fri, 12 Sep 2003 14:42:36 -0700 (PDT)
	(envelope-from gene)
Date: Fri, 12 Sep 2003 14:42:36 -0700
From: "Eugene M. Kim" <gene@nttmcl.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: multi6@ops.ietf.org
Subject: The End-to-End Principle (was Re: Fwd: A comment about MAST)
Message-ID: <20030912214236.GC64027@alicia.nttmcl.com>
References: <20030912151341.GA59651@alicia.nttmcl.com> <200309121548.AAA00736@necom830.hpcl.titech.ac.jp> <20030912204625.GA64027@alicia.nttmcl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030912204625.GA64027@alicia.nttmcl.com>
User-Agent: Mutt/1.4i
X-Spam-Status: No, hits=-9.5 required=5.0
	tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

On Fri, Sep 12, 2003 at 01:46:25PM -0700, Eugene M. Kim wrote:
> 
> OT: Actually I was reading your E2E multihoming draft this morning then
> encountered a similar problem; you apparently believed in the concept of
> E2E by using phrases like `end to end _principle_' but failed to clarify
> what `end-to-end' exactly implied.  If you meant some concept widely
> believed in by other people, perhaps adding at the end of the draft a
> reference to some other document that discusses the concept would help
> the uninformed camp (including me) understand you and your proposal
> better.

A mea-culpa self-reply... =)  It seems that concept has been already
documented for more than 20 years: Saltzer et al, `End-to-End Arguments
in System Design', found online at
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt; could
you add this to your e2e-multihoming draft as a reference?

Thanks,
Eugene



From owner-multi6@ops.ietf.org  Fri Sep 12 19:21:39 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21831
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 19:21:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xxBg-000J8h-L4
	for multi6-data@psg.com; Fri, 12 Sep 2003 23:18:48 +0000
Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk)
	by psg.com with esmtp (Exim 4.22)
	id 19xxB2-000J0G-Fh
	for multi6@ops.ietf.org; Fri, 12 Sep 2003 23:18:08 +0000
Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1])
	by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA21881;
	Sat, 13 Sep 2003 00:18:06 +0100 (BST)
Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162])
	by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id AAA16082;
	Sat, 13 Sep 2003 00:18:00 +0100 (BST)
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h8CNI6h09067;
	Sat, 13 Sep 2003 00:18:06 +0100
Date: Sat, 13 Sep 2003 00:18:06 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: multi6@ops.ietf.org
Cc: harald@alvestrand.no
Subject: Re: The End-to-End Principle (was Re: Fwd: A comment about MAST)
Message-ID: <20030912231806.GE8893@login.ecs.soton.ac.uk>
Mail-Followup-To: multi6@ops.ietf.org, harald@alvestrand.no
References: <20030912151341.GA59651@alicia.nttmcl.com> <200309121548.AAA00736@necom830.hpcl.titech.ac.jp> <20030912204625.GA64027@alicia.nttmcl.com> <20030912214236.GC64027@alicia.nttmcl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030912214236.GC64027@alicia.nttmcl.com>
User-Agent: Mutt/1.4i
X-Spam-Status: No, hits=-6.7 required=5.0
	tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

There was a nice presentation on this topic by Harald Alvestrand at
Nordunet 2003.   Unfortunately his slides aren't online after the event,
but he may be able to point you at them somewhere online ("Where is the 
'End' in end-to-end")

Tim

On Fri, Sep 12, 2003 at 02:42:36PM -0700, Eugene M. Kim wrote:
> On Fri, Sep 12, 2003 at 01:46:25PM -0700, Eugene M. Kim wrote:
> > 
> > OT: Actually I was reading your E2E multihoming draft this morning then
> > encountered a similar problem; you apparently believed in the concept of
> > E2E by using phrases like `end to end _principle_' but failed to clarify
> > what `end-to-end' exactly implied.  If you meant some concept widely
> > believed in by other people, perhaps adding at the end of the draft a
> > reference to some other document that discusses the concept would help
> > the uninformed camp (including me) understand you and your proposal
> > better.
> 
> A mea-culpa self-reply... =)  It seems that concept has been already
> documented for more than 20 years: Saltzer et al, `End-to-End Arguments
> in System Design', found online at
> http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.txt; could
> you add this to your e2e-multihoming draft as a reference?
> 
> Thanks,
> Eugene



From owner-multi6@ops.ietf.org  Fri Sep 12 20:04:18 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22791
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 20:04:18 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xxqJ-0000eB-S6
	for multi6-data@psg.com; Sat, 13 Sep 2003 00:00:47 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19xxpo-0000WU-6Z
	for multi6@ops.ietf.org; Sat, 13 Sep 2003 00:00:16 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309122343.IAA12541@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id IAA12541; Sat, 13 Sep 2003 08:43:20 +0900
Subject: Re: The End-to-End Principle (was Re: Fwd: A comment about MAST)
In-Reply-To: <20030912214236.GC64027@alicia.nttmcl.com> from "Eugene M. Kim"
 at "Sep 12, 2003 02:42:36 pm"
To: "Eugene M. Kim" <gene@nttmcl.com>
Date: Sat, 13 Sep 2003 08:43:19 +0859 ()
CC: multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=-2.6 required=5.0
	tests=BAYES_20,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Eugene;

> > OT: Actually I was reading your E2E multihoming draft this morning then
> > encountered a similar problem; you apparently believed in the concept of
> > E2E by using phrases like `end to end _principle_' but failed to clarify
> > what `end-to-end' exactly implied.

Nor did I clarify what the Internet implied.

> A mea-culpa self-reply... =)  It seems that concept has been already
> documented for more than 20 years:

And, it is *THE* principle of the Internet that anyonw who don't know
the principle does not understand the Internet.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Fri Sep 12 20:04:56 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22826
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 20:04:55 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xxqr-0000jw-Vf
	for multi6-data@psg.com; Sat, 13 Sep 2003 00:01:21 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19xxpy-0000al-9R
	for multi6@ops.ietf.org; Sat, 13 Sep 2003 00:00:26 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309122351.IAA12562@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id IAA12562; Sat, 13 Sep 2003 08:51:28 +0900
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <17385523936.20030912141903@brandenburg.com> from Dave Crocker at
 "Sep 12, 2003 02:19:03 pm"
To: Dave Crocker <dcrocker@brandenburg.com>
Date: Sat, 13 Sep 2003 08:51:27 +0859 ()
CC: "Eugene M. Kim" <gene@nttmcl.com>, multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=-2.6 required=5.0
	tests=BAYES_20,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Eugene and Dave;

> >> > If I understood you correctly, your concern seems to be that, with the
> >> > proposed MAST API, some applications are required to be modified just to
> >> > suit MAST as they had to with NAT.  Is this correct?
> >> Wrong. There is no MAST API. It is NAT API. Applications for the API
> >> is, behind NAT, notified address of a NAT box and tell it to its peer.
> 
> EMK> Not verbatim. 

The API is verbatim.

> In order for that to work, a new protocol is needed
> EMK> between a NAT gateway and machines behind it so the gateway can notify
> EMK> address changes to them.

and NAT lovers are working on it.

> NAT boxes do address translation and MAST does address translation. In a very
> theoretical sense there is, therefore, some similarity between them. However
> MAST is not a "network" address translation service and it really has nothing
> to do with the controversy surrounding NATs.

NAT translate "network address". MAST is identical.

> As for a "MAST API", none is needed.
> 
> MAST hides the multiple addresses from transport and above.  That is one of
> its features.

Dave, Eugene point it out it is untrue, just as NAT does not hide
the multiple addresses.

> I believe that any application protocol that uses direct IP addresses has a
> problem with any multi-homing/mobility solution.

Wrong concept.

Any application protocol that uses direct IP identifiers does not have a
problem with a multi-homing/mobility solution.

Instead, any application protocol that uses direct IP addresses has a
problem with NAT (and MAST, of course).

> Also, as soon as the application needs to benefit from knowing about -- and
> giving guidance about -- the availability of multiple addresses, then it needs
> an be nice to enhanced API. That is true for any multi-addressing solution,
> not just MAST.

Wrong concept. See above.

> EMK>   I think you are
> EMK> worried about something that does not even exist.
> 
> Correct.

It's nice that MAST dose not exist.

> >> You miss the point that MAST does not solve *THE* problem
> >> and is useless even as an intermediate solution.
> 
> EMK> I'm afraid you did not communicate what was `*THE* problem' you were
> EMK> trying to solve here.
> 
> Yes, it would be nice to hear a clear and coherent description of "the"
> problem.

Read the draft or my response to MAST.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Fri Sep 12 20:22:03 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23070
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 20:22:03 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xy8d-00048L-8y
	for multi6-data@psg.com; Sat, 13 Sep 2003 00:19:43 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xy8b-00047t-HB
	for multi6@ops.ietf.org; Sat, 13 Sep 2003 00:19:41 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8D0OcP15398;
	Fri, 12 Sep 2003 17:24:38 -0700
Date: Fri, 12 Sep 2003 17:19:30 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: dcrocker@brandenburg.com
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <19596351135.20030912171930@brandenburg.com>
To: "Eugene M. Kim" <gene@nttmcl.com>
CC: multi6@ops.ietf.org
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <20030912213614.GB64027@alicia.nttmcl.com>
References: <20030912151341.GA59651@alicia.nttmcl.com>
 <200309121548.AAA00736@necom830.hpcl.titech.ac.jp>
 <20030912204625.GA64027@alicia.nttmcl.com>
 <17385523936.20030912141903@brandenburg.com>
 <20030912213614.GB64027@alicia.nttmcl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.5 required=5.0
	tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eugene,

>> MAST hides the multiple addresses from transport and above.  That is one of
>> its features.

EMK> I see.  Looks like I misunderstood MAST in that sense. =)

the next version of the proposal should make things clearer.


EMK> A random idea: How about making MAST support these two operating mode?

excellent. you are anticipating some of the changes I am plan for the next
version. thank you...

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Fri Sep 12 20:22:40 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23103
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 20:22:40 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xy9D-0004EW-W4
	for multi6-data@psg.com; Sat, 13 Sep 2003 00:20:19 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp)
	by psg.com with esmtp (Exim 4.22)
	id 19xy9B-0004DW-IE
	for multi6@ops.ietf.org; Sat, 13 Sep 2003 00:20:17 +0000
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <200309130004.JAA13393@necom830.hpcl.titech.ac.jp>
Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
	id JAA13393; Sat, 13 Sep 2003 09:03:54 +0859
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <20030912204625.GA64027@alicia.nttmcl.com> from "Eugene M. Kim"
 at "Sep 12, 2003 01:46:25 pm"
To: "Eugene M. Kim" <gene@nttmcl.com>
Date: Sat, 13 Sep 2003 09:03:53 +0859 ()
CC: multi6@ops.ietf.org
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=BAYES_20,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

Eugene;

> > Of course, application on the peer also need modification, which is
> > practically impossible.
> > 
> > Try to design the API of a host and its peer, for example, for FTP.
> 
> Do we have to modify FTP further than RFC 2428 in order to accomodate
> MAST if it provided the API to get the up-to-date peer address for the
> control connection?  If so, why?

What is your point?

RFC 2428 is "FTP Extensions for IPv6 and NATs" and, as I said, "the
peer also need modification".

It is nothing more than an illusion that NAT/MAST were transparent.

> I thought it would be rash to draft, implement and adopt something as a
> standard in such a short timeframe that existing needs need not be met
> at all in the meantime.

Good argument against MAST, which does not worse implementation and
adoptation effort.

We should deploy only a long term solution with the interoperability to
leagacy protocols in mind.

> > Worst, your hidden assumption is that almost all the hosts use MAST,
> > which is not a sound assumption for an intermediate, if any, solution.
> 
> MAST does not worsen the case where one host knows MAST and the other
> does not, because it is designed in such a way that it does not impede
> the transport later without first verifying that the peer also knows how
> to do it.  So it need not be worried about if the peer doesn't speak
> MAST, because in that case MAST will not kick in but the communication
> will proceed as if neither party knew MAST.

Exactly, and there is no reason to have MAST.

> > > With these two assumptions, authors of complicated application (i.e.
> > > those that must be modified to take advantage of MAST) have two choices:
> > 
> > Completely wrong.
> > 
> > Those applications that must be modified to take advantage of
> > multihoming with multiple addresses have a single choice to
> > be modified so with no further modification.
> 
> Again, you seem to be assuming that we can come up with the long-term
> solution in a really short timeframe.  Unless you can show me some
> proposal is already up for that task, including deployment plans and
> scenarios, I still think such an assumption is rash.

As was presented at Vienna, the long term solution based on LIN6
is running and is interoperating with leagacy stack.

							Masataka Ohta



From owner-multi6@ops.ietf.org  Fri Sep 12 22:03:48 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25424
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 22:03:48 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19xzh7-000MNa-Pc
	for multi6-data@psg.com; Sat, 13 Sep 2003 01:59:25 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19xzh1-000MK9-QS
	for multi6@ops.ietf.org; Sat, 13 Sep 2003 01:59:19 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8D24LP19641;
	Fri, 12 Sep 2003 19:04:21 -0700
Date: Fri, 12 Sep 2003 18:59:13 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: dcrocker@brandenburg.com
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <70102333607.20030912185913@brandenburg.com>
To: Erik Nordmark <Erik.Nordmark@sun.com>
CC: multi6@ops.ietf.org
Subject: Re: Comments on draft-crocker-mast-proposal-00.txt
In-Reply-To: <Roam.SIMC.2.0.6.1063388326.968.nordmark@bebop.france>
References: "Your message with ID" <11438719956.20030906195815@brandenburg.com>
 <Roam.SIMC.2.0.6.1063388326.968.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.5 required=5.0
	tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Erik,

EN>... I originally thought that
EN> something  like PBK would be the result, but some careful anaylsis resulted in
EN> a simpler  scheme which just uses 3-way handshake to effictive establish a

This is pretty interesting. I know enough about security issues to appreciate
their difficulty and to be able to compare different designs. I don't know
enough to be clever in designing one myself.

Still, I had originally thought that a basic 4-way notification/response sequence
-- each side notifies the other of the nonce it will use and the other side
confirms -- ought to provide enough security for this purpose.

In any event, what is clear is that there are a number of adequate choices
available. For the purposes of MAST's design approach, any of them is fine.

Whatever folks prefer -- as long as it does not require going to an outside
certificate authority, or the like -- is certainly acceptable to me.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Fri Sep 12 23:00:36 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26375
	for <multi6-archive@lists.ietf.org>; Fri, 12 Sep 2003 23:00:35 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19y0cY-0006YK-M8
	for multi6-data@psg.com; Sat, 13 Sep 2003 02:58:46 +0000
Received: from [158.38.152.233] (helo=eikenes.alvestrand.no)
	by psg.com with esmtp (Exim 4.22)
	id 19y0cS-0006XH-Cp
	for multi6@ops.ietf.org; Sat, 13 Sep 2003 02:58:40 +0000
Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1])
	by eikenes.alvestrand.no (Postfix) with ESMTP
	id C31A561B90; Sat, 13 Sep 2003 04:58:38 +0200 (CEST)
Date: Fri, 12 Sep 2003 19:21:43 -0700
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: Tim Chown <tjc@ecs.soton.ac.uk>, multi6@ops.ietf.org
Subject: Re: The End-to-End Principle (was Re: Fwd: A comment about MAST)
Message-ID: <158924000.1063394503@localhost>
In-Reply-To: <20030912231806.GE8893@login.ecs.soton.ac.uk>
References: <20030912151341.GA59651@alicia.nttmcl.com>
 <200309121548.AAA00736@necom830.hpcl.titech.ac.jp>
 <20030912204625.GA64027@alicia.nttmcl.com>
 <20030912214236.GC64027@alicia.nttmcl.com>
 <20030912231806.GE8893@login.ecs.soton.ac.uk>
X-Mailer: Mulberry/3.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Status: No, hits=-0.8 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,
	      REFERENCES,REPLY_WITH_QUOTES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

since you asked:

http://www.alvestrand.no/speeches/end2end-iceland.pdf

have fun - but don't expect too much :-)

--On 13. september 2003 00:18 +0100 Tim Chown <tjc@ecs.soton.ac.uk> wrote:

> There was a nice presentation on this topic by Harald Alvestrand at
> Nordunet 2003.   Unfortunately his slides aren't online after the event,
> but he may be able to point you at them somewhere online ("Where is the
> 'End' in end-to-end")
>







From owner-multi6@ops.ietf.org  Sun Sep 14 06:17:12 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26014
	for <multi6-archive@lists.ietf.org>; Sun, 14 Sep 2003 06:17:12 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19yTsn-000NJz-4c
	for multi6-data@psg.com; Sun, 14 Sep 2003 10:13:29 +0000
Received: from [163.117.136.122] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 19yTsI-000NEy-4b
	for multi6@ops.ietf.org; Sun, 14 Sep 2003 10:12:58 +0000
Received: from smtp02.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id 0C0A64323F; Sun, 14 Sep 2003 12:12:51 +0200 (CEST)
Received: from lolo (vpn-252-64.uc3m.es [163.117.252.64])
	by smtp02.uc3m.es (Postfix) with SMTP
	id 22E1099FC4; Sun, 14 Sep 2003 12:12:49 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: <dhc@dcrocker.net>
Cc: <multi6@ops.ietf.org>
Subject: MAST and mip based solution
Date: Sun, 14 Sep 2003 12:08:30 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAOEDPDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Status: No, hits=0.8 required=5.0
	tests=MSGID_GOOD_EXCHANGE,RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Dave,

I really like the MAST draft, it is really clear and attempts to benefit
from already available work.
I also liked the roadmap proposed by P. Nikander (i think it was him).
Start with a solution based in MIP, with the minimum changes to mip and then
to evolve to an optimized solution which can be something like MAST.

so i think it is important to compare mast to a mip based solution (it seems
that everyone wants to compare mast with something :-)

I can identify the following relevant points (imho)
- Deployment. I think that it is clear that mip will be available much
sooner than a mast solution. Even if some changes are required in mip to
support mh, i think that the changes imposed to nodes outside the
multi-homed site will be very limited (if not, i don't know if a mip
solution makes much sense). So i think that it is reasonable to consider a
mip based solution as a short term solution
- Overhead/MTU. I think that one of the main benefits of mast over a mip
based solution is related to the overhead and MTU reduction imposed by mip.
I mean, mip requires the usage of the HoA dest option and the type 2 routing
header when using alternative addresses. This imposes overhead and implies
MTU reduction. MAST solves these issues, since packets only carry one
address. This is a desirable feature of a more longer term solution.

However, i think that mip signaling is really similar to the one required by
MAST. for instance bu messages contain alternative address information. I
mean, i think it should be interesting to evaluate if mip messages can be
used in a MAST implementation. Moreover, i think that the mip solution can
be optimized by just avoiding the usage of the HoA destination address and
the routing header.
I mean, once that the BU has been performed, you really don't need to carry
both addresses in every packet since this state information is already at
the end nodes. This is what MAST does. so a mip based solution can evolve
towards mast in this way, i.e. conserving the packet format for signaling
and improving certain aspects as this one. Clearly much more study is
required to see how this fits.

what do you think?

Finally, the main problem that i find in mast is, as always, the security. I
mean, mast is vulnerable to time shifting attack and can be used to generate
flooding attacks, so more stuff is needed, just as in a mip based solution.

Regards, marcelo




From owner-multi6@ops.ietf.org  Mon Sep 15 06:06:53 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21089
	for <multi6-archive@lists.ietf.org>; Mon, 15 Sep 2003 06:06:53 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19yqDL-000EkG-64
	for multi6-data@psg.com; Mon, 15 Sep 2003 10:04:11 +0000
Received: from [192.71.80.74] (helo=localhost.kurtis.pp.se)
	by psg.com with esmtp (Exim 4.22)
	id 19yqBX-000EQU-7Z
	for multi6@ops.ietf.org; Mon, 15 Sep 2003 10:02:19 +0000
Received: from kurtis.pp.se (localhost [127.0.0.1])
	by localhost.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h8FA2U09001674;
	Mon, 15 Sep 2003 12:02:33 +0200 (CEST)
Date: Mon, 15 Sep 2003 12:02:29 +0200
Subject: Re: MAST and mip based solution
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: <dhc@dcrocker.net>, <multi6@ops.ietf.org>
To: <mbagnulo@ing.uc3m.es>
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
In-Reply-To: <LIEEJBCNFDJHFFKJJDPAOEDPDAAA.marcelo@it.uc3m.es>
Message-Id: <B75CA70A-E763-11D7-8DC0-000A95880ECC@kurtis.pp.se>
Content-Transfer-Encoding: quoted-printable
X-Mailer: Apple Mail (2.552)
X-Spam-Status: No, hits=-2.2 required=5.0
	tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable


On s=F6ndag, sep 14, 2003, at 12:08 Europe/Stockholm, marcelo bagnulo=20
wrote:

> I can identify the following relevant points (imho)
> - Deployment. I think that it is clear that mip will be available much
> sooner than a mast solution. Even if some changes are required in mip=20=

> to
> support mh, i think that the changes imposed to nodes outside the
> multi-homed site will be very limited (if not, i don't know if a mip
> solution makes much sense). So i think that it is reasonable to=20
> consider a
> mip based solution as a short term solution
>

But for an intermediary solution where MIP already exists, will that=20
actually need any modification or adoption for trying to solve=20
multihoming?

- kurtis -




From owner-multi6@ops.ietf.org  Mon Sep 15 11:01:34 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06058
	for <multi6-archive@lists.ietf.org>; Mon, 15 Sep 2003 11:01:32 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19yulK-000HZC-Ba
	for multi6-data@psg.com; Mon, 15 Sep 2003 14:55:34 +0000
Received: from [163.117.136.122] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 19yukN-000HNj-Kv
	for multi6@ops.ietf.org; Mon, 15 Sep 2003 14:54:35 +0000
Received: from smtp02.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id D5EA843197; Mon, 15 Sep 2003 16:54:34 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.67])
	by smtp02.uc3m.es (Postfix) with SMTP
	id DA96999FC7; Mon, 15 Sep 2003 16:54:33 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Kurt Erik Lindqvist" <kurtis@kurtis.pp.se>, <mbagnulo@ing.uc3m.es>
Cc: <dhc@dcrocker.net>, <multi6@ops.ietf.org>
Subject: RE: MAST and mip based solution
Date: Mon, 15 Sep 2003 16:50:12 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAOEEODAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <B75CA70A-E763-11D7-8DC0-000A95880ECC@kurtis.pp.se>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi Kurtis,

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Kurt Erik Lindqvist
> Enviado el: lunes, 15 de septiembre de 2003 12:02
> Para: mbagnulo@ing.uc3m.es
> CC: dhc@dcrocker.net; multi6@ops.ietf.org
> Asunto: Re: MAST and mip based solution
>
>
>
> On söndag, sep 14, 2003, at 12:08 Europe/Stockholm, marcelo bagnulo
> wrote:
>
> > I can identify the following relevant points (imho)
> > - Deployment. I think that it is clear that mip will be available much
> > sooner than a mast solution. Even if some changes are required in mip
> > to
> > support mh, i think that the changes imposed to nodes outside the
> > multi-homed site will be very limited (if not, i don't know if a mip
> > solution makes much sense). So i think that it is reasonable to
> > consider a
> > mip based solution as a short term solution
> >
>
> But for an intermediary solution where MIP already exists, will that
> actually need any modification or adoption for trying to solve
> multihoming?
>

I guess it would require some changes, the options that i can identfy are:

- Extend the maximum lifetime of binding entries (BCE) in the correspondent
nodes to some acceptable value for multi-homing support, for isntance a
couple of hours. The problem is that the current value is set to 7 minutes
and it is a security measure for preventing time shifting attacks.

- Use ICMP to differentiate a broken path from a time shifting attack. I
mean, mip uses return routability to prove address ownership. This means
that a node is entitled to use a given address if it can receive the packets
sent to this address. MIP return routability check is performed
periodically, so that time shifting attacks can be minimized (this means,
that it isn't enough that i can prove that once i could receive packets to a
certain address to prove that i own that address, instead i have to prove
that i can always recive packets to this address) (this implies that if an
attacker wants to pretend to own an address it must be intercepting the
packets to this address during the complete duration of the attack)
The problem is the return routability cannot be applied directly to the
multi-homed environment, becuase a mh host won't be able to prove address
ownership after an outage has occurred. So we need some way to differentiate
a path outage from a time shifting attack. This implies some form of network
to user signaling, informing that an outage has occurred. This is done using
icmp. The problem with this is icmp filtering. If icmp is filtered, the cn
will consider that an attack is in place and will drop the communication. So
this solution is as robust as icmp messaging... i am not sure if this is
good enough...

So possible changes are minor i guess, but i am not sure whether the
solution achieved is good enough


I am not sure that if this is a satisfactory answer to your question
tough....

Regards, marcelo

PS: i think this issues are pretty general, i mean they are true not only
for a mip based solution.

> - kurtis -
>
>




From owner-multi6@ops.ietf.org  Mon Sep 15 14:41:18 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18442
	for <multi6-archive@lists.ietf.org>; Mon, 15 Sep 2003 14:41:17 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19yyFW-0009xh-Fn
	for multi6-data@psg.com; Mon, 15 Sep 2003 18:38:58 +0000
Received: from [139.175.54.7] (helo=seed.net.tw)
	by psg.com with esmtp (Exim 4.22)
	id 19yyF0-0009sO-Hr
	for multi6@ops.ietf.org; Mon, 15 Sep 2003 18:38:26 +0000
Received: from [211.74.73.240] (port=3329 helo=companyua5it71)
	by seed.net.tw with smtp (Seednet 4.14:1)
	id 19yyEy-000LT4-VD
	for multi6@ops.ietf.org; Tue, 16 Sep 2003 02:38:25 +0800
Message-ID: <001201c37bb8$8a081410$0100a8c0@companyua5it71>
From: "Su Po-chou" <supc@locust.csie.ncku.edu.tw>
To: <multi6@ops.ietf.org>
Subject: router renumbering
Date: Tue, 16 Sep 2003 02:38:20 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Status: No, hits=1.9 required=5.0
	tests=BAYES_60,RCVD_IN_NJABL
	version=2.55
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear All,
               Where can I find router renumbering tools or source code ?
               I wanna know how to implement it in code.
               
               Thanks for your help.

Regards,
PC





From owner-multi6@ops.ietf.org  Tue Sep 16 20:41:00 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21295
	for <multi6-archive@lists.ietf.org>; Tue, 16 Sep 2003 20:40:59 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19zQIT-000Aqq-VX
	for multi6-data@psg.com; Wed, 17 Sep 2003 00:35:53 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19zQIN-000Apl-PE
	for multi6@ops.ietf.org; Wed, 17 Sep 2003 00:35:47 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8H0etP09745
	for <multi6@ops.ietf.org>; Tue, 16 Sep 2003 17:40:55 -0700
Date: Tue, 16 Sep 2003 17:35:42 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <4181528992.20030916173542@brandenburg.com>
To: multi6@ops.ietf.org
Subject: New multiaddressing review and new MAST draft
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.9 required=5.0
	tests=RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Howdy.

I've just submitted some new mobility/multihoming I-Ds for
distribution. Meanwhile, they are available from my website, in text and MS
Word formats.

The first breaks out the "discussion" section of the original MAST paper and
expands on it:

     Choices for Support of Multiaddressing

     Text:
       <http://brandenburg.com/specifications/draft-crocker-mast-analysis-00.txt>
     MSWord :
       <http://brandenburg.com/specifications/draft-crocker-mast-analysis-00.doc>


The second is the revised draft proposal:

     Multiple Address Service For Transport (MAST):
     An Extended Proposal

     Text:
        <http://brandenburg.com/specifications/draft-crocker-mast-proposal-01.txt>
     MSWord:
        <http://brandenburg.com/specifications/draft-crocker-mast-proposal-01.doc>

d/
----- 
 Dave Crocker <mailto:dcrocker@brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA USA <tel: +1.408.246.8253>; <fax: +1.408.850.1850>




From owner-multi6@ops.ietf.org  Wed Sep 17 07:02:17 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05287
	for <multi6-archive@lists.ietf.org>; Wed, 17 Sep 2003 07:02:17 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19zZzl-000EYZ-2f
	for multi6-data@psg.com; Wed, 17 Sep 2003 10:57:13 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 19zZza-000EWk-5Z
	for multi6@ops.ietf.org; Wed, 17 Sep 2003 10:57:02 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id 54F95433F5; Wed, 17 Sep 2003 12:57:01 +0200 (CEST)
Received: from lolo (unknown [163.117.139.67])
	by smtp03.uc3m.es (Postfix) with SMTP
	id AACC22B68B; Wed, 17 Sep 2003 12:57:00 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Dave Crocker" <dcrocker@brandenburg.com>, <multi6@ops.ietf.org>
Subject: multi-addressing review (was:RE: New multiaddressing review and new MAST draft)
Date: Wed, 17 Sep 2003 12:52:37 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAOEHIDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <4181528992.20030916173542@brandenburg.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=0.0 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Dave,

I think it is valuable to have a document covering the issues related to
multi-addressing, so thanks for doing it.

My main comment about the document is that the security section seems
incomplete to me.

The only considered threat is connection hijacking. I guess there much other
issues to consider.

IMHO the security section is focused on the threats reffered to the parties
involved in the communication. However, it is also important to consider the
new threats that the adoption of multi-addressing mechanisms means for other
hosts in the internet (for instance non-mobile, non multi-homed hosts)
For instance, flooding attacks, dos attacks.

Other type of attacks should also be considered such as time shifting
attacks.

I would recomend considering the analysis contained in
draft-nikander-mobileip-v6-ro-sec as an input. It contain a detailed
analysis of different attacks related to mobility.

Regards, marcelo

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Dave Crocker
> Enviado el: miercoles, 17 de septiembre de 2003 2:36
> Para: multi6@ops.ietf.org
> Asunto: New multiaddressing review and new MAST draft
>
>
> Howdy.
>
> I've just submitted some new mobility/multihoming I-Ds for
> distribution. Meanwhile, they are available from my website, in
> text and MS
> Word formats.
>
> The first breaks out the "discussion" section of the original
> MAST paper and
> expands on it:
>
>      Choices for Support of Multiaddressing
>
>      Text:
>
> <http://brandenburg.com/specifications/draft-crocker-mast-analysis-00.txt>
>      MSWord :
>
> <http://brandenburg.com/specifications/draft-crocker-mast-analysis-00.doc>
>
>
> The second is the revised draft proposal:
>
>      Multiple Address Service For Transport (MAST):
>      An Extended Proposal
>
>      Text:
>
> <http://brandenburg.com/specifications/draft-crocker-mast-proposal-01.txt>
>      MSWord:
>
> <http://brandenburg.com/specifications/draft-crocker-mast-proposal-01.doc>
>
> d/
> -----
>  Dave Crocker <mailto:dcrocker@brandenburg.com>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA USA <tel: +1.408.246.8253>; <fax: +1.408.850.1850>
>
>




From owner-multi6@ops.ietf.org  Wed Sep 17 08:05:11 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07829
	for <multi6-archive@lists.ietf.org>; Wed, 17 Sep 2003 08:05:10 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19zb19-0002hY-7V
	for multi6-data@psg.com; Wed, 17 Sep 2003 12:02:43 +0000
Received: from [212.68.5.99] (helo=n97.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 19zb0d-0002cH-Qu
	for multi6@ops.ietf.org; Wed, 17 Sep 2003 12:02:12 +0000
Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id 36F9A1C; Wed, 17 Sep 2003 15:15:32 +0300 (EEST)
Message-ID: <3F684D41.6090607@nomadiclab.com>
Date: Wed, 17 Sep 2003 15:02:09 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: multi6@ops.ietf.org
Subject: Re: New multiaddressing review and new MAST draft
References: <4181528992.20030916173542@brandenburg.com>
In-Reply-To: <4181528992.20030916173542@brandenburg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-3.4 required=5.0
	tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
	      REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,

Firstly, I very much agree with Marcelo wrt. his comment
about security.

Secondly, some specific comments about the HIP section:

>      3.5.2.    Host Identity Protocol (HIP)
>      
>      HIP works with IPv4 and IPv6.  Also, it:
>      
>           *    Creates a new, globally unique name space

You may consider adding "probabilistically", since the only
currently defined type of HIs are public keys.  HIP does not
assume any key registry, and therefore the uniqueness of host
identifiers is only probabilistic.

(I also suspect that none of the current implementations supports
  resolving HIT conflicts, even if the spec requires that.  However,
  even with that the probability of conflicts is very low.)

>           *    Uses strong, cryptographically based protocol details,
>                overloading some HIP functionality with security 
>                functionality

I am not quite sure about the word "overload".  That is, I don't
quite understand what you imply with it.

HIP was initially designed to solve other identity related
problems but mobility and multi-homing, with strong focus
on security.  Rudimentary mobility support was there from
fairly early on, but real mobility support (with rendezvous)
and multi-homing came only afterwards, around the time I
joined the HIP gang a couple of years ago.  And the exact
details for those are still being worked on.

>           *    Is tied significantly to [IPSEC]

Well, while that is technically correct, the word "significantly"
may give a wrong impression (see below).  Furthermore, there are
some thoughts of loosening those ties.  The problem is that we
haven't found any way to do so without compromising the some
security aspects.  It may be possible in the future, though.

>           *    Creates a new DNS RR entry

Correct.  However, for the time being we will use IPSECKEY,
which is in IESG review, I think.

>           *    Requires a Rendezvous server for mobility support

Well, it requires rendezvous for con-current mobility.  Client
mobility or slow server mobility (with dyndns updates) works
pretty well without any rendezvous servers.  In fact, the
rendezvous function has not been fully specified.

Hence, I would suggest changing "mobility" to "con-current" mobility
(or something equivalent that matches with your overall terminology).

>           *    Requires that NATs be aware of HIP

This was an explicit design choice.  It would be possible to
make HIP work using UDP tunneling, but we chose not to do so.
At least not yet.  If there is real need for that, such support
could be added, but the result would not be pretty any more.

>      Many of the HIP features are appealing, such as the cleanliness
>      of the architectural model depicted in Section 4 of the HIP
>      architecture document.  Were the Internet stack being created
>      now, HIP well might be an excellent approach. 

Thank you.

>      However
>      retrofitting this approach into the existing, deployed Internet
>      entails serious barriers to adoption, such as its dependence on
>      IPSec.

I am not quite sure how serious the alledged barriers are.
HIP does require changes to the stack, yes.  It introduces
a kind of shim or wedge, just like MAST or LIN6.  It does
not work with current NAT boxes, but that has been an explicit
design choice for the time being.

A word about dependence with IPsec.  HIP uses only a small
portion of IPsec, and supports only a small subset of the
current functionality that full IPsec implementations support.
On the other hand, HIP requires virtually no configuration,
while the current IPsec implementations require a considerable
amount of configuration and expertese.

To be more specific, HIP uses ESP as its packet transport
mechanism.  It integrates well with the current IPsec
processing model, and is able to co-exist with other
IPsec based secure connections.  On the other hand, it is
also possible to implement the ESP functions that HIP
requires completely independent on any IPsec code in the
stack.  One of the existing implementations uses this
approach, and contains a user level ESP implementation.

Hence, I don't immeditely see any serious barries for HIP.
But maybe I am blind in this issue.  Well, if you consider
the NAT issue as such, then be it so.  Otherwise I would
fairly strongly disagree with your statement.

>      In general, addition of a DNS SRV record can be useful for
>      achieving efficient rendezvous, with or without mobility.  It
>      permits participants to know whether a service is supported by
>      its partner, without requiring a probe packet.  While beneficial,
>      this enhancement to DNS data structures is not required for
>      multihoming or client (initiator) mobility.

I am not quite sure what the paragraph above has to do with HIP.

--Pekka Nikander




From owner-multi6@ops.ietf.org  Wed Sep 17 09:18:50 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10315
	for <multi6-archive@lists.ietf.org>; Wed, 17 Sep 2003 09:18:50 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19zc8z-000Hqi-Q0
	for multi6-data@psg.com; Wed, 17 Sep 2003 13:14:53 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19zc8S-000Hkm-Tt
	for multi6@ops.ietf.org; Wed, 17 Sep 2003 13:14:20 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8HDJOP14224;
	Wed, 17 Sep 2003 06:19:24 -0700
Date: Wed, 17 Sep 2003 06:14:10 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <4024648472.20030917061410@brandenburg.com>
To: "marcelo bagnulo" <marcelo@it.uc3m.es>
CC: multi6@ops.ietf.org, mbagnulo@ing.uc3m.es
Subject: Re: multi-addressing review (was:RE: New multiaddressing review and new MAST draft)
In-Reply-To: <LIEEJBCNFDJHFFKJJDPAOEHIDAAA.marcelo@it.uc3m.es>
References: <4181528992.20030916173542@brandenburg.com>
 <LIEEJBCNFDJHFFKJJDPAOEHIDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-0.4 required=5.0
	tests=IN_REP_TO,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

marcelo,

mb> The only considered threat is connection hijacking. I guess there much other
mb> issues to consider.

Thank you for raising this point.  I'll start by commenting that I expected
folks to take exception with the paper, on this matter, and that I think it is
extremely important to have consensus about the security issues that need to
be covered for multiaddressing.

I took an extreme position, in the paper, because I think we need to make sure
that the number and type of security issues are kept to the bare minimum
necessary.

The key question is:  What are security issues are created by
multiaddressing and alter the existing IP security?


mb> However, it is also important to consider the
mb> new threats that the adoption of multi-addressing mechanisms means for other
mb> hosts in the internet (for instance non-mobile, non multi-homed hosts)
mb> For instance, flooding attacks, dos attacks.

However, existing IP is subject to these attacks, is it not?


mb> Other type of attacks should also be considered such as time shifting
mb> attacks.

What is a "time shifting attack"?


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Wed Sep 17 11:30:20 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17172
	for <multi6-archive@lists.ietf.org>; Wed, 17 Sep 2003 11:30:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19zeC9-000ICh-Qc
	for multi6-data@psg.com; Wed, 17 Sep 2003 15:26:17 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 19zeBq-000I7p-0H
	for multi6@ops.ietf.org; Wed, 17 Sep 2003 15:25:58 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id 95147433C4; Wed, 17 Sep 2003 17:25:56 +0200 (CEST)
Received: from lolo (unknown [163.117.139.67])
	by smtp03.uc3m.es (Postfix) with SMTP
	id 396552B674; Wed, 17 Sep 2003 17:25:56 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Dave Crocker" <dcrocker@brandenburg.com>
Cc: <multi6@ops.ietf.org>, <mbagnulo@ing.uc3m.es>
Subject: RE: multi-addressing review (was:RE: New multiaddressing review and new MAST draft)
Date: Wed, 17 Sep 2003 17:21:32 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPACEHPDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <4024648472.20030917061410@brandenburg.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=0.0 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



> -----Mensaje original-----
> De: Dave Crocker [mailto:dhc@dcrocker.net]
> Enviado el: miercoles, 17 de septiembre de 2003 15:14
> Para: marcelo bagnulo
> CC: multi6@ops.ietf.org; mbagnulo@ing.uc3m.es
> Asunto: Re: multi-addressing review (was:RE: New multiaddressing review
> and new MAST draft)
>
>
> marcelo,
>
> mb> The only considered threat is connection hijacking. I guess
> there much other
> mb> issues to consider.
>
> Thank you for raising this point.  I'll start by commenting that
> I expected
> folks to take exception with the paper, on this matter, and that
> I think it is
> extremely important to have consensus about the security issues
> that need to
> be covered for multiaddressing.
>
> I took an extreme position, in the paper, because I think we need
> to make sure
> that the number and type of security issues are kept to the bare minimum
> necessary.
>
> The key question is:  What are security issues are created by
> multiaddressing and alter the existing IP security?
>

Right.
I think that there are other people in the list who can provide a so much
better answer to this question than me...
Anyway, Tony Li's design team has promised a security analysis from a great
expert, so we are waiting.

>
> mb> However, it is also important to consider the
> mb> new threats that the adoption of multi-addressing mechanisms
> means for other
> mb> hosts in the internet (for instance non-mobile, non multi-homed hosts)
> mb> For instance, flooding attacks, dos attacks.
>
> However, existing IP is subject to these attacks, is it not?
>

I think so, but we have to make sure that deploying a multi-addressing
solution just don't enable more of them.

For instance, suppose that you have no security at all and you enable to
send BU to move a connection from an ip address to another.

You can create a flooding attack by just initiating a communication with a
streaming server and then just move to the target host (you can find a
better explanation in section 3.2.1 basic flooding of the ro sec draft)

>
> mb> Other type of attacks should also be considered such as time shifting
> mb> attacks.
>
> What is a "time shifting attack"?
>

In current ipv4, if an attacker wnats to pretend to be at a given ip address
(steal the address, impersonate, whatever), the attacker must be on place,
intercepting the packets in order to receive them.
However, if you enable something such as BU that allows you to say to the
other node that from now on he must send packets to an alternative address
(i.e. and alternative location), the attacker can divert the traffic to a
more confortable location for him. So the attacker is not required to be on
place during the complete period of the attack. Or in other words, the
attacker can leave the location where it intercepts the packets and still
perform the attack. (Again a much better explanation of this can be found in
the ro sec document section 4.3 Quick expiration of the BCE and section 5.1
Time Shifting attacks)

Regards, marcelo

>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>




From owner-multi6@ops.ietf.org  Wed Sep 17 13:50:10 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21667
	for <multi6-archive@lists.ietf.org>; Wed, 17 Sep 2003 13:50:10 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19zgM8-000Mxv-2J
	for multi6-data@psg.com; Wed, 17 Sep 2003 17:44:44 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19zgLa-000Mpn-EN
	for multi6@ops.ietf.org; Wed, 17 Sep 2003 17:44:10 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8HHnFP31580;
	Wed, 17 Sep 2003 10:49:17 -0700
Date: Wed, 17 Sep 2003 10:44:00 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <13640838192.20030917104400@brandenburg.com>
To: "marcelo bagnulo" <marcelo@it.uc3m.es>
CC: multi6@ops.ietf.org
Subject: Re: MAST and mip based solution
In-Reply-To: <LIEEJBCNFDJHFFKJJDPAOEDPDAAA.marcelo@it.uc3m.es>
References: <LIEEJBCNFDJHFFKJJDPAOEDPDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.5 required=5.0
	tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Marcelo,

thanks for the comments on MAST;

mb> I also liked the roadmap proposed by P. Nikander (i think it was him).

I like it, but have to note that the Internet is not very good at following
roadmaps.

That is one reason I try very hard to reduce the dependencies that new work
has on other new work.  Development gets delays.  Deployment gets delayed.


mb> - Deployment. I think that it is clear that mip will be available much

Unless I am missing something very basic -- and I readily admit that that is
likely -- then MIP has problematic barriers to adoption.

These barriers come in 3 ways:

1. How much software has to be built or changed.

2. How much infrastructure has to be changed (new software and/or new
operational procedures.)

3. How difficult is it to use?

I think that MIP loses on all 3 counts.  It requires modification to the user
stacks, and requires enhancements to infrastructure software and operations.

The user platform must have a formal "home" network.

All of the bells and whistles are required for even the simplest use.

And mip works for mobility but not multihoming.  If it offered major
advantages over some of the alternative solutions, that might be fine.  But I
do not see those advantages.


mb> - Overhead/MTU. I think that one of the main benefits of mast over a mip
mb> based solution is related to the overhead and MTU reduction imposed by mip.

yes.  this benefit also applies to the transport-level solutions.


mb> However, i think that mip signaling is really similar to the one required by
mb> MAST. for instance bu messages contain alternative address information. I
mb> mean, i think it should be interesting to evaluate if mip messages can be
mb> used in a MAST implementation. Moreover, i think that the mip solution can
mb> be optimized by just avoiding the usage of the HoA destination address and
mb> the routing header.

You are talking in terms that look like an effort to "converge" two or more
designs.  That will be excellent, if it can happen.

The history of such efforts in the IETF is not all that positive, but I think
that attempts to synthesize different proposals together always produces
better understanding, if not fewer specifications.


mb> Finally, the main problem that i find in mast is, as always, the security. I
mb> mean, mast is vulnerable to time shifting attack and can be used to generate
mb> flooding attacks, so more stuff is needed, just as in a mip based solution.

As I've noted elsewhere, MAST is intentionally limited in what security it
tries to provide.  It can be made stronger and broader, but I think there
needs to be a very clear understanding of the reasons more security is
needed... for multiaddressing, rather than for overall enhancement of the
Internet.

As I have said, the latter goal is laudable... but it is an additional goal that is
not essential to multiaddressing support.



d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Wed Sep 17 18:51:19 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04564
	for <multi6-archive@lists.ietf.org>; Wed, 17 Sep 2003 18:51:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19zl2r-000Cmf-Q5
	for multi6-data@psg.com; Wed, 17 Sep 2003 22:45:09 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 19zl2p-000Cm3-77
	for multi6@ops.ietf.org; Wed, 17 Sep 2003 22:45:07 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8HMoAP18532;
	Wed, 17 Sep 2003 15:50:10 -0700
Date: Wed, 17 Sep 2003 15:44:57 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <12158892492.20030917154457@brandenburg.com>
To: "Eugene M. Kim" <gene@nttmcl.com>
CC: multi6@ops.ietf.org
Subject: Re: Fwd: A comment about MAST
In-Reply-To: <20030912213614.GB64027@alicia.nttmcl.com>
References: <20030912151341.GA59651@alicia.nttmcl.com>
 <200309121548.AAA00736@necom830.hpcl.titech.ac.jp>
 <20030912204625.GA64027@alicia.nttmcl.com>
 <17385523936.20030912141903@brandenburg.com>
 <20030912213614.GB64027@alicia.nttmcl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.5 required=5.0
	tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Eugene,

>> As for a "MAST API", none is needed.
>> 
>> MAST hides the multiple addresses from transport and above.  That is one of
>> its features.

EMK> I see.  Looks like I misunderstood MAST in that sense. =)

The first draft of the proposal was rather confusing, about a number of
issues.  Please let me know if the second draft (released last night) is more
clear about this.


>> Also, as soon as the application needs to benefit from knowing about -- and
>> giving guidance about -- the availability of multiple addresses, then it needs
>> an be nice to enhanced API. That is true for any multi-addressing solution,
>> not just MAST.

EMK> Also agreed.

EMK> A random idea: How about making MAST support these two operating mode?

EMK> 1. The original scenario, where the transport layer such as TCP does not
EMK> know how to handle multiple endpoint addresses nor requests MAST to
EMK> notify about address changes.  MAST operates as originally proposed in
EMK> this case.

EMK> 2. The new scenario, where the transport layer such as TCP knows how to
EMK> handle multiple endpoint addresses and requests MAST to notify about
EMK> address changes.

This sounds like a very good proposal to me.  A core API that is backward
compatible -- in fact, it _is_ the old API.  And then an extended API for the
extended functionality.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Thu Sep 18 08:23:42 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08930
	for <multi6-archive@lists.ietf.org>; Thu, 18 Sep 2003 08:23:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19zxhC-000PPj-BI
	for multi6-data@psg.com; Thu, 18 Sep 2003 12:15:38 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 19zxge-000PE0-CT
	for multi6@ops.ietf.org; Thu, 18 Sep 2003 12:15:04 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id B2B85432B6; Thu, 18 Sep 2003 14:15:03 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.67])
	by smtp03.uc3m.es (Postfix) with SMTP
	id A82C82B681; Thu, 18 Sep 2003 14:15:03 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Dave Crocker" <dcrocker@brandenburg.com>
Cc: <multi6@ops.ietf.org>
Subject: RE: MAST and mip based solution
Date: Thu, 18 Sep 2003 14:10:36 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAIEIODAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <13640838192.20030917104400@brandenburg.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,



> -----Mensaje original-----
> De: Dave Crocker [mailto:dhc@dcrocker.net]
> Enviado el: miercoles, 17 de septiembre de 2003 19:44

[...]

> mb> - Deployment. I think that it is clear that mip will be available much
>
> Unless I am missing something very basic -- and I readily admit
> that that is
> likely -- then MIP has problematic barriers to adoption.
>
> These barriers come in 3 ways:
>
> 1. How much software has to be built or changed.
>
> 2. How much infrastructure has to be changed (new software and/or new
> operational procedures.)
>
> 3. How difficult is it to use?
>
> I think that MIP loses on all 3 counts.  It requires modification
> to the user
> stacks, and requires enhancements to infrastructure software and
> operations.
>
> The user platform must have a formal "home" network.
>
> All of the bells and whistles are required for even the simplest use.
>

Well, i would like to mention a coouple of issues about this:

Note that the functionality that it is required (at least from my pov) is
onlt the CN functionality. I mean, the idea is to try to benefit from
capabilities that are being inlcuded in end-hosts code right now.
So CN capabilities are not the most complex part. for instance, al the home
network complexity is not included

The other thing is that i don't think that mip has artificial complexity.
I mean, mip is complex, agree. But my question is, how do you manage to
provide a solution with al the required functionality and that it doesn't
introduce new security vulnerabilities to the internet without all this
complexity.

You can argue that for instance MAST is much simpler (i choose mast just as
an example), but how simple will it be when you provide proper security
features. My guess is that it will be at least as complex as mip.

> And mip works for mobility but not multihoming.  If it offered major
> advantages over some of the alternative solutions, that might be
> fine.  But I
> do not see those advantages.

About mip for multi-homing.
Yes, mip has some issues when trying to use it for multi-homing.

If you assume that an end-host solution is required (i include here
solutions that use some form of proxy in the site's network), you will find
that it is very difficult to provide a solution that doesn?t introduce new
security issues.

As far as i can see, the only solution that provide this is HIP.
The problem with hip is that it is a bit too revolutionary and requires a
lot of changes, not only in code but also in paradigm. We need to gain
experience and moving to hip will take some time IMHO.
So we need a bridge.
An option is to use current ipv4 style, just as Kurtis proposed a long time
ago...
The other option is to use a solution that it is not as secure as we would
like.
But when considering adopting a transient solution that is not optimal,
probably you want to minimize the effort, so it can deployed as fast as
possible.
IMHO a mip based solution suits fine with this constraints.


Regards, marcelo

>
>
> mb> - Overhead/MTU. I think that one of the main benefits of mast
> over a mip
> mb> based solution is related to the overhead and MTU reduction
> imposed by mip.
>
> yes.  this benefit also applies to the transport-level solutions.
>
>
> mb> However, i think that mip signaling is really similar to the
> one required by
> mb> MAST. for instance bu messages contain alternative address
> information. I
> mb> mean, i think it should be interesting to evaluate if mip
> messages can be
> mb> used in a MAST implementation. Moreover, i think that the mip
> solution can
> mb> be optimized by just avoiding the usage of the HoA
> destination address and
> mb> the routing header.
>
> You are talking in terms that look like an effort to "converge"
> two or more
> designs.  That will be excellent, if it can happen.
>
> The history of such efforts in the IETF is not all that positive,
> but I think
> that attempts to synthesize different proposals together always produces
> better understanding, if not fewer specifications.
>
>
> mb> Finally, the main problem that i find in mast is, as always,
> the security. I
> mb> mean, mast is vulnerable to time shifting attack and can be
> used to generate
> mb> flooding attacks, so more stuff is needed, just as in a mip
> based solution.
>
> As I've noted elsewhere, MAST is intentionally limited in what security it
> tries to provide.  It can be made stronger and broader, but I think there
> needs to be a very clear understanding of the reasons more security is
> needed... for multiaddressing, rather than for overall enhancement of the
> Internet.
>
> As I have said, the latter goal is laudable... but it is an
> additional goal that is
> not essential to multiaddressing support.
>
>
>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>




From owner-multi6@ops.ietf.org  Thu Sep 18 10:21:40 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14551
	for <multi6-archive@lists.ietf.org>; Thu, 18 Sep 2003 10:21:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 19zzaV-00098g-Uh
	for multi6-data@psg.com; Thu, 18 Sep 2003 14:16:51 +0000
Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net)
	by psg.com with esmtp (Exim 4.22)
	id 19zza0-00097c-M1
	for multi6@ops.ietf.org; Thu, 18 Sep 2003 14:16:20 +0000
Received: from dfnjgl21 (12-237-229-250.client.attbi.com[12.237.229.250])
          by comcast.net (sccrmhc12) with SMTP
          id <2003091814161901200su67ge>
          (Authid: sdawkins@comcast.net);
          Thu, 18 Sep 2003 14:16:19 +0000
Message-ID: <06f901c37def$70c76f80$040010ac@DFNJGL21>
Reply-To: "Spencer Dawkins" <spencer@mcsr-labs.org>
From: "Spencer Dawkins" <spencer@mcsr-labs.org>
To: <multi6@ops.ietf.org>
References: <LIEEJBCNFDJHFFKJJDPAIEIODAAA.marcelo@it.uc3m.es>
Subject: Re: MAST and mip based solution
Date: Thu, 18 Sep 2003 09:16:23 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Spam-Status: No, hits=0.5 required=5.0
	tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
> About mip for multi-homing.
> Yes, mip has some issues when trying to use it for multi-homing.
>
> If you assume that an end-host solution is required (i include here
> solutions that use some form of proxy in the site's network), you
will find
> that it is very difficult to provide a solution that doesn?t
introduce new
> security issues.

[deleted down to ]

> The other option is to use a solution that it is not as secure as we
would
> like.

This is only my opinion, but I would expect we would get more
simplification from dropping the requirement to support simultaneous
movement at both ends than we would from relaxing security - the
requirement for a rendezvous function in the network comes from
simultaneous movement, and that gives us dependencies on network
infrastructure changes.

The vast majority of today's mobile ("portable") users have TCP
connections on IPv4 devices that break when they cross subnet
boundaries. Supporting movement at one end would be an improvement.
Supporting simultaneous movement at both ends would be lovely, but so
far, we haven't widely deployed a solution that provides that
capability. Meanwhile, they continue to run client-server applications
with short connection lifetimes because that's what works in today's
networks.

End-to-end MAST really could help us move to peer-to-peer applications
in many, but not all, environments. MIP is certainly a more complete
solution, and I'm not bashing MIP here, only suggesting that MAST may
really have a role for multihoming support, without reducing security.
MAST or HIP? I think that's the question for multihoming.

Just my opinion here, and not all that clearly thought out...

Spencer

Spencer




From owner-multi6@ops.ietf.org  Thu Sep 18 11:06:12 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16705
	for <multi6-archive@lists.ietf.org>; Thu, 18 Sep 2003 11:06:11 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A00IL-000Id3-9o
	for multi6-data@psg.com; Thu, 18 Sep 2003 15:02:09 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A00Ht-000ITT-F8
	for multi6@ops.ietf.org; Thu, 18 Sep 2003 15:01:41 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id B56B343257; Thu, 18 Sep 2003 17:01:40 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.67])
	by smtp03.uc3m.es (Postfix) with SMTP
	id 788332B67E; Thu, 18 Sep 2003 17:01:40 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Spencer Dawkins" <spencer@mcsr-labs.org>, <multi6@ops.ietf.org>
Subject: RE: MAST and mip based solution
Date: Thu, 18 Sep 2003 16:57:13 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAOEJBDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <06f901c37def$70c76f80$040010ac@DFNJGL21>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=0.0 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi Spencer,

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Spencer Dawkins
> Enviado el: jueves, 18 de septiembre de 2003 16:16
> Para: multi6@ops.ietf.org
> Asunto: Re: MAST and mip based solution
>
>
> >
> > About mip for multi-homing.
> > Yes, mip has some issues when trying to use it for multi-homing.
> >
> > If you assume that an end-host solution is required (i include here
> > solutions that use some form of proxy in the site's network), you
> will find
> > that it is very difficult to provide a solution that doesn?t
> introduce new
> > security issues.
>
> [deleted down to ]
>
> > The other option is to use a solution that it is not as secure as we
> would
> > like.
>
> This is only my opinion, but I would expect we would get more
> simplification from dropping the requirement to support simultaneous
> movement at both ends than we would from relaxing security - the
> requirement for a rendezvous function in the network comes from
> simultaneous movement, and that gives us dependencies on network
> infrastructure changes.
>

actually i would be satisfied if we could build a solution to provide just
multi-homing support (i.e a solution for multi-homing without support for
mobility (note that this is the charter of this wg :-)), but i think that
this is also very hard with the current security requirements.
So, i agree with you, simultaneous movement is really a plus plus...

> The vast majority of today's mobile ("portable") users have TCP
> connections on IPv4 devices that break when they cross subnet
> boundaries. Supporting movement at one end would be an improvement.
> Supporting simultaneous movement at both ends would be lovely, but so
> far, we haven't widely deployed a solution that provides that
> capability. Meanwhile, they continue to run client-server applications
> with short connection lifetimes because that's what works in today's
> networks.
>
> End-to-end MAST really could help us move to peer-to-peer applications
> in many, but not all, environments. MIP is certainly a more complete
> solution, and I'm not bashing MIP here, only suggesting that MAST may
> really have a role for multihoming support, without reducing security.

Here is where we disagree. I don´t think you can provide the current ipv4
level of security with mast if you don't use cryptographically generated
identifiers i.e. HIP.

But let's try to do it.
Let's try to define a security solution for MAST and see what happens (i am
willing to contribute)
But unless we come up with some new thinking here, we have a very similar
problem than what mip people had when they where designing mip, so problably
we will end up in the same place, with the same problems, but i guess we can
only be sure of this if we try.

> MAST or HIP? I think that's the question for multihoming.
>

For me there are many questions, but if you are considering end-host based
solutions, the question is mip-type or hip-type, meaning by mip-type those
solutions that don't use crypto identifiers and use other means to provide
security and hip-type those solutions that use crypto identifiers.

Regards, marcelo

> Just my opinion here, and not all that clearly thought out...
>
> Spencer
>
> Spencer
>
>




From owner-multi6@ops.ietf.org  Fri Sep 19 12:26:20 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10715
	for <multi6-archive@lists.ietf.org>; Fri, 19 Sep 2003 12:26:20 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A0G2Y-000CBk-R4
	for multi6-data@psg.com; Fri, 19 Sep 2003 07:50:54 +0000
Received: from [212.68.5.99] (helo=n97.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A0G21-000C0l-Vf
	for multi6@ops.ietf.org; Fri, 19 Sep 2003 07:50:22 +0000
Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id EFD8B1C; Fri, 19 Sep 2003 11:03:41 +0300 (EEST)
Message-ID: <3F6AB53D.8010005@nomadiclab.com>
Date: Fri, 19 Sep 2003 10:50:21 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
Reply-To: hipsec@honor.trusecure.com
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: IPv6 WG <ipv6@ietf.org>, Multi6 WG <multi6@ops.ietf.org>
Cc: hipsec@honor.trusecure.com
Subject: Renewed HIP mailing list & BOF and WG proposals
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=BAYES_30,USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

[Aplogies for cross-posting]

Folks,

The Host Identity Protocol (HIP) mailing list was restored
in July at @honor.trusecure.com.  The mailing list existed
previously @lists.freeswan.org, but there were some technical
problems which necessitated the move of the mailing list.

We have now started a discussion on a possible HIP BOF and WG.
If you want to participate to the discussion, join the mailing
list.  However, before doing so, please read the archives,
at least the most recent ones.

The archive is available at
http://honor.trusecure.com/pipermail/hipsec/

The most important messages at this point, related to
the WG proposal, are the following:

http://honor.trusecure.com/pipermail/hipsec/2003-July/000004.html
http://honor.trusecure.com/pipermail/hipsec/2003-September/000070.html
http://honor.trusecure.com/pipermail/hipsec/2003-September/000071.html

Subscription information is available at:

http://honor.trusecure.com/mailman/listinfo/hipsec

--Pekka Nikander





From owner-multi6@ops.ietf.org  Fri Sep 19 13:15:49 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10713
	for <multi6-archive@lists.ietf.org>; Fri, 19 Sep 2003 12:26:20 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A0NCt-000EDi-90
	for multi6-data@psg.com; Fri, 19 Sep 2003 15:30:03 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A0NCI-000E7t-Fi
	for multi6@ops.ietf.org; Fri, 19 Sep 2003 15:29:26 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id C0477433B8; Fri, 19 Sep 2003 17:29:25 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.67])
	by smtp03.uc3m.es (Postfix) with SMTP
	id 215582B68B; Fri, 19 Sep 2003 17:29:25 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Dave Crocker" <dcrocker@brandenburg.com>
Cc: "Spencer Dawkins" <spencer@mcsr-labs.org>, <multi6@ops.ietf.org>,
        <mbagnulo@ing.uc3m.es>
Subject: RE: MAST and mip based solution
Date: Fri, 19 Sep 2003 17:24:53 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAGEJPDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <155138682955.20030918135448@brandenburg.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dave,

> -----Mensaje original-----
> De: Dave Crocker [mailto:dcrocker@brandenburg.com]
> Enviado el: jueves, 18 de septiembre de 2003 22:55
> Para: marcelo bagnulo
> CC: Spencer Dawkins; multi6@ops.ietf.org; mbagnulo@ing.uc3m.es
> Asunto: Re: MAST and mip based solution
>
>
> marcelo,
>
> >> I think that MIP loses on all 3 counts.  It requires modification
> >> to the user
> >> stacks, and requires enhancements to infrastructure software and
> >> operations.
> >>
>
>
> mb> You can argue that for instance MAST is much simpler (i
> choose mast just as
> mb> an example), but how simple will it be when you provide
> proper security
> mb> features. My guess is that it will be at least as complex as mip.
>
> It appears that one can specify adequate security without
> creating or using
> any infrastructure services.  From my perspective, complexity and
> barriers to
> adoption primarily depend upon the number and placing of system
> components,
> rather than the specific algorithms that are used.
>
> MIP needs infrastructure.  MAST does not.
>

Uh? Which infrasturcture does MIP needs to provide multi-homing?

>
>
> >> This is only my opinion, but I would expect we would get more
> >> simplification from dropping the requirement to support simultaneous
> >> movement at both ends than we would from relaxing security
>
>
> mb> actually i would be satisfied if we could build a solution to
> provide just
> mb> multi-homing support (i.e a solution for multi-homing without
> support for
> mb> mobility (note that this is the charter of this wg :-)), but
> i think that
> mb> this is also very hard with the current security requirements.
>
> As I discuss in the -choice- paper, it is increasingly looking to me as if
> multihoming and mobility can and should be viewed as two sides of the same
> topic.  That's why I combined them under the term multiaddressing.
>
> Clearly one can separate them.  But to either of them completely, you must
> include some features from the other.
>

Yes, that's why i think that we could apply mip stuff to multi-homing, but i
just wanted to point that if we find a multi-homing solution that solves all
the mh problems but that doesn't provides mobility support, i would find it
completelly acceptable.

>
> mb> So, i agree with you, simultaneous movement is really a plus plus...
>
> Even without mutual mobility.  Simple initiator mobility (where
> the target is
> static) does not require the significant, extra functionality to support a
> mobile target. However even then mobility can encounter having
> the old and new
> addresses available at the same time.  That sounds like multihoming.
>
>
> >> End-to-end MAST really could help us move to peer-to-peer applications
> >> in many, but not all, environments. MIP is certainly a more complete
> >> solution, and I'm not bashing MIP here, only suggesting that MAST may
> >> really have a role for multihoming support, without reducing security.
>
> mb> Here is where we disagree.
>
> Actually, I think you agree. I know _I_ agree with you (or
> rather, I disagree
> that we disagree...)
>
>
> and here's why:
>
> mb> I don´t think you can provide the current ipv4
> mb> level of security with mast if you don't use
> cryptographically generated
> mb> identifiers i.e. HIP.
>
> Correct.  That's why the MAST proposal called for crypt-gen-id's:
>
>      draft-crocker-mast-proposal-01.txt:
>
>      3.2. Association Attributes
>
>      An MAST association is between a pair of hosts, defined by
>      endpoint identifiers, an association label and a transaction
>      sequence identifier.
>
>      It comprises a domain name double, an Association Nonce double,
>      and a transaction sequence number (TSN) double:
>
>           Endpoint       Globally unique, macro-labels
>           identifiers:   comprising a domain name for each host
>
>           Endpoint       Association nonce, with cryptographic
>           association    protection against hijacking. It is an
>           label:         internal identifier for the MAST
>                          association; it comprises a random
>                          value, such as defined in Section
>                          6.4.2, "Connection Nonce Feature" and
>                          used in Section 6.4.3, "Identification
>                          Option", in [DCCP].  Also see [RAND].
>
> A critical question is where the cryptographic string comes from.
>  I believe
> it is acceptable to have it be independently generated, so that it has
> statistical uniqueness, rather than guaranteed uniqueness.
>
>
> mb> But let's try to do it.
> mb> Let's try to define a security solution for MAST and see what
> happens (i am
> mb> willing to contribute)
>
> Thanks.  My current guess is that PBK is plenty, although Erik
> Nordmark has
> suggested a simpler mechanism will suffice.
>
> The core of the algorithm seems to be to have each side generate
> a random --
> and therefore unguessable -- string and then do a hand-shake to reliably
> exchange it with the other side. The string is then presented in
> each message
> as a context (association) identifier.
>
> If more is needed, then what and why?
>

There is an important difference between hip and pbk, if i understand it
correctly, which is the following:

PBK allows you to be sure that once you have contacted the other end, it
will remain being the same, no matter if the ip address change
OTOH HIP allows to to be certain that the other end is who you want to
communicate with, even before you establish the communication.

This basically because in a pbk are transient identifiers, so host recognize
each other using ip addresses (after a while that they don't talk each
other) (for instance you don't store pbks in the DNS)
HI are permanent identifiers, so hosts recognize each others using hi

Example:

Today you identify the other end of a communication through an ip address.
This means that if i know i want to communicate with A, i have to know A's
ip address. Put it in another way, i use ip addresses to recognize host that
i already know.

PBK doesn't change this. So if I want to communicate with a certain ip
address IPA and i use PBK,
i establish the communication with IPA,
i make a DH excahnge to generate a shared key
and then we can both change our addresses and still be able to recognize
each other.

However, this doesn't prevent attacks where the attacker is trying to steal
your ip address.
Actually, using pbk enable address stealing shifted in time.

I mean, suppose i want to impersonate A. I establish a communication using
IPA
The other end recognizes me because i am using IPA
Then we start the pbk dh exchange (the attacker has to intercept these
packets)
Once the pbks are generated, the attacker can leave the place and use an
alternative ip address and he is recognized as being A because he has the
pbk.

If you use hip, hosts recognize each other through the HI. You cannot
pretend to own someone else' s hi because you won't be able to prove it (you
just don't have the private key that is required)

Regards, marcelo

>
>
>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>




From owner-multi6@ops.ietf.org  Fri Sep 19 16:13:49 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20568
	for <multi6-archive@lists.ietf.org>; Fri, 19 Sep 2003 16:13:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A0RXk-00011b-EL
	for multi6-data@psg.com; Fri, 19 Sep 2003 20:07:52 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A0RXE-0000wh-Ee
	for multi6@ops.ietf.org; Fri, 19 Sep 2003 20:07:20 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8JKCQP25407;
	Fri, 19 Sep 2003 13:12:26 -0700
Date: Fri, 19 Sep 2003 13:07:07 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <13256401180.20030919130707@brandenburg.com>
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
CC: multi6@ops.ietf.org
Subject: Re: New multiaddressing review and new MAST draft
In-Reply-To: <3F684D41.6090607@nomadiclab.com>
References: <4181528992.20030916173542@brandenburg.com>
 <3F684D41.6090607@nomadiclab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
	      REPLY_WITH_QUOTES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka,

PN> Firstly, I very much agree with Marcelo wrt. his comment about security.

The key here, is to be clear about the requirements for security. In
particular, I think we need to be diligent in separating the requirements that
are strictly due to adding multiaddressing, versus the changes that are more
generally interesting and useful.

Let me again stress that I'm not trying to make light of those additional
goals, but want to make sure that we are clear that they are additional. If
satisfying those goals imposes significant challenges to the basic design of
multiaddressing support, then the effort for them should be separated out.


>>      3.5.2.    Host Identity Protocol (HIP)
>>           *    Creates a new, globally unique name space

PN> You may consider adding "probabilistically", since the only currently
PN> defined type of HIs are public keys. HIP does not assume any key registry,
PN> and therefore the uniqueness of host identifiers is only probabilistic.

Oh.  Thank you. I completely misunderstood this.


>>           *    Uses strong, cryptographically based protocol details,
>>                overloading some HIP functionality with security 
>>                functionality
PN> I am not quite sure about the word "overload".  That is, I don't
PN> quite understand what you imply with it.
PN> HIP was initially designed to solve other identity related problems but
PN> mobility and multi-homing, with strong focus on security. Rudimentary
PN> mobility support was there from fairly early on, but real mobility support
PN> (with rendezvous) and multi-homing came only afterwards, around the time I
PN> joined the HIP gang a couple of years ago. And the exact details for those
PN> are still being worked on.

Your reference to solving "other identity related problems" is what I meant. I
think the scope of HIP has been broader than just enabling multiaddressing.
And I fear that that makes the design more complicated.


>>           *    Is tied significantly to [IPSEC]

PN> Well, while that is technically correct, the word "significantly"
PN> may give a wrong impression (see below).

My point was not about concepts, but about implementation and operation.  So I
think the concern I was raising was that a system cannot use HIP without being
required to also support IPSec.  Is my understanding of this incorrect?

Taking ideas and algorithms from other specs, and even "cohabiting" bits of
functionality can be excellent.  I like to do that as much as possible.

However having implementation and operation dependencies -- especially when
neither service is yet universal -- is problematic.


PN> Furthermore, there are some thoughts of loosening those ties. The problem
PN> is that we haven't found any way to do so without compromising the some
PN> security aspects. It may be possible in the future, though.

I understand.  And that is a strong reason I'm looking to make the
security requirements be as few as is reasonable to support multiaddressing.


>>           *    Creates a new DNS RR entry

PN> Correct. However, for the time being we will use IPSECKEY, which is in
PN> IESG review, I think.

If this is an adjunct feature, then it's probably fine.  If it is required for
the basic service, then it is a barrier to adoption.


>>           *    Requires a Rendezvous server for mobility support

PN> Well, it requires rendezvous for con-current mobility. Client mobility or
PN> slow server mobility (with dyndns updates) works pretty well without any
PN> rendezvous servers.

Cool! Again, I had misunderstood this, and thought that the rendezvous server
was required for basic HIT use.


PN> In fact, the rendezvous function has not been fully specified.

(Feel free to take a look at MAST's latest attempt to suggest one...)


>>           *    Requires that NATs be aware of HIP

PN> This was an explicit design choice. It would be possible to make HIP work
PN> using UDP tunneling, but we chose not to do so. At least not yet. If there
PN> is real need for that, such support could be added, but the result would
PN> not be pretty any more.

My point is that requiring NAT support is a huge barrier to adoption.


>>      Many of the HIP features are appealing, such as the cleanliness
>>      of the architectural model depicted in Section 4 of the HIP
>>      architecture document.  Were the Internet stack being created
>>      now, HIP well might be an excellent approach. 

PN> Thank you.

No. Thank _you_. I've been stymied on this topic for some years, and it was
only the HIP and SCTP/PBK analysis work that made it possible for me to think
about this more.


>>      However
>>      retrofitting this approach into the existing, deployed Internet
>>      entails serious barriers to adoption, such as its dependence on
>>      IPSec.

PN> To be more specific, HIP uses ESP as its packet transport mechanism.

Does this not mean that you cannot use HIP unless you also support IPSec?  I
think that is frankly an significant barrier.  (I think that your next
paragraph means that I am misunderstanding this.)


PN> It integrates well with the current IPsec processing model, and is able to
PN> co-exist with other IPsec based secure connections. On the other hand, it
PN> is also possible to implement the ESP functions that HIP requires
PN> completely independent on any IPsec code in the stack. One of the existing
PN> implementations uses this approach, and contains a user level ESP
PN> implementation.

Interesting.


>> In general, addition of a DNS SRV record can be useful for achieving
>> efficient rendezvous, with or without mobility. It permits participants to
>> know whether a service is supported by its partner, without requiring a
>> probe packet. While beneficial, this enhancement to DNS data structures is
>> not required for multihoming or client (initiator) mobility.

PN> I am not quite sure what the paragraph above has to do with HIP.

it probably needs to be moved elsewhere.

Many thanks for the clarifications.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Tue Sep 23 13:50:39 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27291
	for <multi6-archive@lists.ietf.org>; Tue, 23 Sep 2003 13:50:38 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A1rF8-0002BQ-G7
	for multi6-data@psg.com; Tue, 23 Sep 2003 17:46:30 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A1rEx-000299-V0
	for multi6@ops.ietf.org; Tue, 23 Sep 2003 17:46:20 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id 4A45543455; Tue, 23 Sep 2003 19:46:19 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.245])
	by smtp03.uc3m.es (Postfix) with SMTP
	id DC09C2B666; Tue, 23 Sep 2003 19:46:18 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Dave Crocker" <dcrocker@brandenburg.com>,
        "Pekka Nikander" <pekka.nikander@nomadiclab.com>
Cc: <multi6@ops.ietf.org>
Subject: RE: New multiaddressing review and new MAST draft
Date: Tue, 23 Sep 2003 19:41:44 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAIENHDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <13256401180.20030919130707@brandenburg.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=BAYES_30,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Dave,


> PN> Firstly, I very much agree with Marcelo wrt. his comment
> about security.
>
> The key here, is to be clear about the requirements for security.

I guess that the goal should be that the resulting Internet (with the
multi-addressing mechanism) should be "as secure as the IPv4 Internet"


This was the design goal for mobileip and many folks have mentioned this
goal on the list, but is there consensus about this?

Thanks, marcelo




From owner-multi6@ops.ietf.org  Tue Sep 23 14:10:58 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28470
	for <multi6-archive@lists.ietf.org>; Tue, 23 Sep 2003 14:10:57 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A1rb9-00045o-Im
	for multi6-data@psg.com; Tue, 23 Sep 2003 18:09:15 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A1rad-00043y-Fj
	for multi6@ops.ietf.org; Tue, 23 Sep 2003 18:08:43 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8NIDjP07436;
	Tue, 23 Sep 2003 11:13:48 -0700
Date: Tue, 23 Sep 2003 11:08:17 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: dcrocker@brandenburg.com
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <19585924162.20030923110817@brandenburg.com>
To: "marcelo bagnulo" <marcelo@it.uc3m.es>
CC: "Pekka Nikander" <pekka.nikander@nomadiclab.com>, mbagnulo@ing.uc3m.es,
        multi6@ops.ietf.org
Subject: Re: New multiaddressing review and new MAST draft
In-Reply-To: <LIEEJBCNFDJHFFKJJDPAIENHDAAA.marcelo@it.uc3m.es>
References: <13256401180.20030919130707@brandenburg.com>
 <LIEEJBCNFDJHFFKJJDPAIENHDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-0.8 required=5.0
	tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

marcelo,

>> The key here, is to be clear about the requirements for security.

mb> I guess that the goal should be that the resulting Internet (with the
mb> multi-addressing mechanism) should be "as secure as the IPv4 Internet"


Thank you, yes.  This is the right place to start from, in order to make sure
that we are all trying to achieve the right (or same) goal.


mb> This was the design goal for mobileip and many folks have mentioned this
mb> goal on the list, but is there consensus about this?

I suspect that we do have consensus with the statement.  I suspect the
differences in opinion are about what the security of the current IPv4
Internet is.

Most of the features that I have questioned look like they are a good idea.
However they appear to be a) redundant with existing solutions elsewhere in
the stack, and/or b) beyond "the security of the current IPv4 Internet".


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Wed Sep 24 03:25:09 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28552
	for <multi6-archive@lists.ietf.org>; Wed, 24 Sep 2003 03:25:08 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A23wQ-000Bfs-Be
	for multi6-data@psg.com; Wed, 24 Sep 2003 07:20:02 +0000
Received: from [131.160.193.2] (helo=n2.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A23vn-000Bbn-UC
	for multi6@ops.ietf.org; Wed, 24 Sep 2003 07:19:24 +0000
Received: from outside.nomadiclab.com (d2.nomadiclab.com [131.160.194.2])
	by n2.nomadiclab.com (Postfix) with ESMTP
	id 1C0F7CBA50; Wed, 24 Sep 2003 10:19:23 +0300 (EEST)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by outside.nomadiclab.com (Postfix) with ESMTP
	id 9FD92113E2E; Wed, 24 Sep 2003 10:19:22 +0300 (EEST)
Message-ID: <3F707A32.1020902@nomadiclab.com>
Date: Tue, 23 Sep 2003 18:52:02 +0200
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: multi6@ops.ietf.org
Subject: Clarifications about HIP (was Re: New multiaddressing review and
 new MAST draft)
References: <4181528992.20030916173542@brandenburg.com> <3F684D41.6090607@nomadiclab.com> <13256401180.20030919130707@brandenburg.com>
In-Reply-To: <13256401180.20030919130707@brandenburg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-2.1 required=5.0
	tests=BAYES_20,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES,
	      USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

 >>>          *    Uses strong, cryptographically based protocol details,
 >>>               overloading some HIP functionality with security
 >>>               functionality
 >
...
 > Your reference to solving "other identity related problems" is
 > what I meant. I think the scope of HIP has been broader than
 > just enabling multiaddressing.

I understand.  But maybe you should consider rephrasing.
IMHO, the statement is hard to understand.

 >>>          *    Is tied significantly to [IPSEC]

 > My point was not about concepts, but about implementation
 > and operation.  So I think the concern I was raising was
 > that a system cannot use HIP without being required to
 > also support IPSec.  Is my understanding of this incorrect?

As I tried to point out, you can implement ESP for HIP yourself,
and then you don't need any IPsec support from the underlying
platform.

 > However having implementation and operation dependencies
 > -- especially when neither service is yet universal -- is
 > problematic.

As I tried to clarify, HIP *can* co-exist with other IPsec usage,
and utilize the ESP implementation from IPsec if it is available.
(Some more details on that can be found in the ongoing charter
discussion on the HIP mailing list.)

 >>>          *    Creates a new DNS RR entry
 >
 > If this is an adjunct feature, then it's probably fine.  If it
 > is required for the basic service, then it is a barrier to adoption.

HIP can be used without any DNS entries, in the so called opportunistic
mode.  However, the details still need some thinking to make the
opportunistic mode more efficient.  On the other hand, storing any
long term HIP public keys into the DNS looks like a good practise,
and shouldn't be too hard.  Most people that can modify their kernel
can also change some (forward) DNS entries, too.

 >>>          *    Requires that NATs be aware of HIP
 >
 > My point is that requiring NAT support is a huge barrier to adoption.

With HIP, the NAT issue is really beaty vs. supporting current NAT.
My current, personal preference is to prioritize beaty.  Running the
HIP protocol on the top of UDP instead of IP is not such a big deal,
but running ESP on the top of UDP is pain.  You really should be able
to mux packets based on SPI as well as you can mux them based on
UDP ports.  The trick is to learn the association between the SPIs
in the two directions, and HIP allows the NAT boxes to learn that.

On the other hand, if we do find a way of using HIP without
requiring ESP, then it might make more sense to specify how
to run the HIP protocol over UDP.

 > PN> To be more specific, HIP uses ESP as its packet transport
 > PN> mechanism.
 >
 > Does this not mean that you cannot use HIP unless you also
 > support IPSec?

Second time:  The answer depends on what exactly you mean
with "support IPsec".  The system must implement ESP
(but not AH or IKE or IKEv2 or claim IPsec compliance).
It doesn't much matter whether ESP is implemented as a
part of HIP, or separately by the system.

--Pekka Nikander





From owner-multi6@ops.ietf.org  Wed Sep 24 03:25:42 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28575
	for <multi6-archive@lists.ietf.org>; Wed, 24 Sep 2003 03:25:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A23wI-000Bf9-HD
	for multi6-data@psg.com; Wed, 24 Sep 2003 07:19:54 +0000
Received: from [131.160.193.2] (helo=n2.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A23vm-000Bbk-Rz
	for multi6@ops.ietf.org; Wed, 24 Sep 2003 07:19:23 +0000
Received: from outside.nomadiclab.com (d2.nomadiclab.com [131.160.194.2])
	by n2.nomadiclab.com (Postfix) with ESMTP
	id 854B1CBA4D; Wed, 24 Sep 2003 10:19:21 +0300 (EEST)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by outside.nomadiclab.com (Postfix) with ESMTP
	id 0D301113E2E; Wed, 24 Sep 2003 10:19:21 +0300 (EEST)
Message-ID: <3F70786D.5000900@nomadiclab.com>
Date: Tue, 23 Sep 2003 18:44:29 +0200
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: multi6@ops.ietf.org
Subject: About security requirements and complexity (was Re: New multiaddressing
 review and new MAST draft)
References: <4181528992.20030916173542@brandenburg.com> <3F684D41.6090607@nomadiclab.com> <13256401180.20030919130707@brandenburg.com>
In-Reply-To: <13256401180.20030919130707@brandenburg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
	      REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,

> The key here, is to be clear about the requirements for security. In
> particular, I think we need to be diligent in separating the requirements that
> are strictly due to adding multiaddressing, versus the changes that are more
> generally interesting and useful.

I completely agree.  On the other hand, I also think that most people
underestimate the security consequences of introducing genuine
multi-addressing, with the capability of changing the addresses on the
fly.  I certainly underestimated it myself before starting to seriously
work on the area.

> Let me again stress that I'm not trying to make light of those additional
> goals, but want to make sure that we are clear that they are additional. If
> satisfying those goals imposes significant challenges to the basic design of
> multiaddressing support, then the effort for them should be separated out.

Well, the basic differences in terms of cost seems to come from two
sources:
- public key crypto or just hash functions etc
- number of messages and round trips

 From this point of view, HIP can be certainly critisized for relying
on public key crypto, and therefore being heavier than absolutely
necessary.  On the other hand, it is *possible* to use HIP with
very short key lengths, with the obvious (or perhaps not so :-)
consequences.

Complexity wise I don't see any big difference.  There are other
factors that basically necessitate you to use either a three-way
or four-way handshake anyway.  For DoS reasons four-way "stateless"
handshakes seem to be better.  What comes to the complexity of
changes to the stack, there is no big difference.  The real differences,
if any, are in the complexity of the control protocol.  It looks like
that you can't make authenticated Diffie-Hellman with DoS protection
much more simpler than what HIP does.  Hence, the question really is
whether you want to use PK authentication or not, since if you do not,
then you don't need Diffie-Hellman either.

Clarifications about HIP in a separate message.

--Pekka Nikander





From owner-multi6@ops.ietf.org  Wed Sep 24 03:50:59 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29732
	for <multi6-archive@lists.ietf.org>; Wed, 24 Sep 2003 03:50:58 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A24PB-000EUP-Io
	for multi6-data@psg.com; Wed, 24 Sep 2003 07:49:45 +0000
Received: from [131.160.193.2] (helo=n2.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A24P2-000ETn-Er
	for multi6@ops.ietf.org; Wed, 24 Sep 2003 07:49:36 +0000
Received: from outside.nomadiclab.com (d2.nomadiclab.com [131.160.194.2])
	by n2.nomadiclab.com (Postfix) with ESMTP
	id 60498CBA4D; Wed, 24 Sep 2003 10:49:35 +0300 (EEST)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by outside.nomadiclab.com (Postfix) with ESMTP
	id 9C90A113E2E; Wed, 24 Sep 2003 10:49:34 +0300 (EEST)
Message-ID: <3F714C8E.4070205@nomadiclab.com>
Date: Wed, 24 Sep 2003 09:49:34 +0200
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Multi6 WG <multi6@ops.ietf.org>, hipsec@honor.trusecure.com
Subject: Security requirements for identification
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.0 required=5.0
	tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In my previous message (to hipsec&ipv6 ml) I proposed dividing
identification to the following three subcategories:

    a) identification in mobility and multi-homing
    b) identification in referral or rendezvous
    c) identification in other, e.g. administrative, contexts

I also discussed rendezvous and referral, in order to
make the point that identifying a node and locating it
are really two distinct functions.

The previous message is available at
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00056.html

In this message I will try to analyze the security
requirements for identification in the sense of a)
and b).  Analyzing c) in isolation does not make any
sense, since the security requirements depend on the
context.  In the end of this message, I try to give
some conclusions based on the analysis; if you are
busy, you may want to see the conclusions first.

I am focusing here solely on the identification
function, and not touching the security requirements
of the location function.  It should be noted, however,
that these two are related in real life.  Analyzing that
is for another message.


a) identification for mobility and multi-homing
-----------------------------------------------

As I wrote earlier, here we are only interested in gaining
assurance that the peer remains the *same*.  That is, we
do not really care *whom* we are communicating with, but
only that the peer end-point is not changed in mid-
communication.  (We probably did care the "real identity"
of the peer when we first initiated the communication, but
that is a different issue, with different security
requirements.)

There are two basic dangers related identification in mobility
and multi-homing.  One is connection hijacking, i.e., somebody
"stealing" the connection and replacing one of the peers without
being noticed.  The other, less obvious one, is flooding.
Flooding is an attack where a genuine peer lies about its
location(s), with the purpose of choking a victim on excess
traffic.  That is, the attacker claims to move/be better
reachable at the location of a victim, thereby directing the
traffic to the victim.

Flooding is a serious attack since the amounts of redirected
traffic can be large.  Consider a public streaming server.
Anyone can make a connection to it, and start downloading a
stream.  For the stream to run, acknowledgments must be sent
back.  This is easy, since an attacker can open a stream,
redirect the stream (using some mobility or multi-homing
mechanism) to a victim address, and *continue* sending
acknowledgments.  Anticipating when and what kinds of acks to
send is easy enough.  This makes the stream running independent
on the actions by the poor victim.

Hence, for the purpose of mobility and multi-homing, the
identification mechanism has to keep sure that the peer really
remains the same, on all changes of locators.  Furthermore, the
mechanism must not blindly trust what the peer claims about its 
locations, but must check that the same peer really *is*
at all the claimed addresses.

If we really do not care who the initial peer really is,
then a simple protocol is sufficient; the protocol first
creates a shared secret between the peers and then uses
the secret to verify persistence of the identity.  The
protocol may even be vulnerable to MitM attackers in its
initialization state; our requirement states that a MitM
attacker is equally good to the "real" intended peer,
since we don't care about the "real identity".

The requirements can be summarized as follows:

   R1. Verification that the peer is the same one
       after all changes of locators.
   R2. Verification that the same peer is reachable
       at all claimed (and used) locations.

The MIPv6 RR protocol is a (somewhat convoluted) example of
a protocol fulfilling the requirements.  (It also fulfills
other, Mobile IPv6 specific security requirements.)


b) identification for referral or rendezvous
--------------------------------------------

In the case of referral or rendezvous, an initiating party
possesses an identifier that it wants to use as a means
of identifying another party.  The target party may have
no idea of the intentions of the first party, and it may
have never met the first party.  In other words, the parties
do not share any state but the identifier itself and any
state in the target party that is associated with the
identifier.

 From a security point of view, the requirement is that
the party that responds to a communication request really
is the party denoted by the identifier, and someone else.
That is, the requirement is that the target party really
is the intended target party.

If we assumed that everybody is honest, any unique bit
string would serve well as an identifier.  The initiating
party just sends the bit string to the target party, and
asks the target party to verify that the bit string really
is its identifier.  The problem is that we cannot necessarily
assume everybody to be honest.

If we assume dishonest parties, we get two sub cases.  In
the first case, the initiating party must send the identifier
in clear, for some reason, or the identifier is otherwise
public and known by the dishonest parties.  In the second
case, the initiating party is able to keep the identifier in
secret.

In the first case, the only secure way of performing
identification seem to be public key cryptography (or any of
its variants, like zero knowledge protocol).  The reason for
this is the following.  Since the identifier is public
knowledge, we cannot use the identifier directly.  Instead,
there must be some secret that only the right party
knows and is able to prove to know.  The identifier and the
secret must be linked.  Only public key crypto (or a variant)
seems to fulfill these requirements.

The second case is more interesting, since it allows for
some simple cryptographic protocols that show to the
target party that the initiating party knows its secret
identifier without revealing it, and where the target
party is conversely able to show to the initiator that it
also knows the secret identifier.  In effect, in this
case the identifier is a shared secret.  However, it is
also almost completely impractical, since one cannot
share such a secret with anyone, nor put it into a public
directory.  (There are some special cases where this kind
of identification may be useful, but one cannot build a
generic Internet wide architecture on such assumptions.)

Hence, if we want to do referral and rendezvous in a
secure way, we seem to need public keys as identifiers.
It looks best to use public keys as primary identifiers.
It is also possible to use public keys only as secondary
identifiers, and bind them to some primary identifiers,
but that costs more since it requires a PKI.   Using public
keys directly as primary identifiers does not, as such,
require a PKI.

To summarize, the requirement is

   R3. Verification that the target party really is the
       party denoted by the identifier.

With public identifiers and under the assumption that there
may be man-in-the-middle or masquerading attackers, public
keys (or variants) seem like the only known technology
that securely fulfills this requirement.  It should be noted,
however, that we do not necessarily need to care about
potential man-in-the-middle or masquerading attackers.
Whether to do so or not is a design choice.

Discussion
----------

To my best knowledge, the discussion above describes the
essence of the difference between the current architecture
and one where identifiers and locators are separated.
In the current architecture, the mobility and multi-homing
problem does not exist, since one is not allowed to change
ones locators on the fly.  What comes to rendezvous and
referral, the practice of using locators as identifiers
offers a somewhat weak but very important form of security.
Effectively, the practice limits the number of potential
attackers hugely, from all nodes in the Internet to only
those nodes that are on the path between the initiating
party and the target address.

It is extremely important to understand that if we really
separate identifiers and locators, we become more vulnerable.
Fortunately the class of potential attackers will not be
everyone in the Internet, but only those that can tamper
with the identifier -> locator mapping or otherwise get
on the path between the initiating party and some locator.

Conclusions
-----------

Separating identifiers and locators has security implications.
To address these, we basically have a number of possibilities:

   1) Design a _secure enough_ identifier -> locator mapping
      service, thereby limiting the potential attackers to
      those that can either tamper with the service or otherwise
      receive packets sent to the (initially used) locator.
      What is "secure enough" is a design choice.  The service
      must be dynamic because it must be possible to update
      the set of locators.

   2) Decide to use public keys as primary identifiers,
      and rely on public key cryptography for identification.

   3) Design a _secure enough_ identifier -> public key mapping
      service, thereby limiting the potential attackers
      to those that can tamper with the service.  This is
      effectively a PKI, but not necessarily as secure as what
      people traditionally understand with a PKI.  The difference
      to 1) is that here we are not vulnerable to attackers that
      just get to the path but can't tamper with the service.
      The service may be fairly static, since there is seldom
      need to chance one's public key.

   4) Go only half way, and stop where the identifiers can
      be still used as (limited) locators.  The class of
      attackers depends heavily on details, and cannot be
      easily summarized.

I refrain from making comments on any practical designs (like
DNS), since that requires one to consider also other aspects
but security.

Questions
---------

Does this analysis help?
Do we have other choices but the four outlined above?
Should create an I-D from this and the previus message? If so,
should it be accepted by some WG as a working item?

--Pekka Nikander





From owner-multi6@ops.ietf.org  Wed Sep 24 13:11:02 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26833
	for <multi6-archive@lists.ietf.org>; Wed, 24 Sep 2003 13:11:01 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A2D5m-000NYD-MA
	for multi6-data@psg.com; Wed, 24 Sep 2003 17:06:18 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A2D5e-000NXg-OF
	for multi6@ops.ietf.org; Wed, 24 Sep 2003 17:06:10 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id A53D4434D3; Wed, 24 Sep 2003 18:58:55 +0200 (CEST)
Received: from lolo (unknown [163.117.139.245])
	by smtp03.uc3m.es (Postfix) with SMTP
	id 169912B670; Wed, 24 Sep 2003 18:58:55 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Pekka Nikander" <pekka.nikander@nomadiclab.com>,
        "Multi6 WG" <multi6@ops.ietf.org>, <hipsec@honor.trusecure.com>
Subject: RE: Security requirements for identification
Date: Wed, 24 Sep 2003 18:54:16 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAAEPCDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3F714C8E.4070205@nomadiclab.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=0.0 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka,

thanks for the posting, some questions below...

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Pekka Nikander
> Enviado el: miercoles, 24 de septiembre de 2003 9:50
> Para: Multi6 WG; hipsec@honor.trusecure.com
> Asunto: Security requirements for identification
>
>
> In my previous message (to hipsec&ipv6 ml) I proposed dividing
> identification to the following three subcategories:
>
>     a) identification in mobility and multi-homing
>     b) identification in referral or rendezvous
>     c) identification in other, e.g. administrative, contexts
>
> I also discussed rendezvous and referral, in order to
> make the point that identifying a node and locating it
> are really two distinct functions.
>
> The previous message is available at
> http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg0
> 0056.html
>
> In this message I will try to analyze the security
> requirements for identification in the sense of a)
> and b).  Analyzing c) in isolation does not make any
> sense, since the security requirements depend on the
> context.  In the end of this message, I try to give
> some conclusions based on the analysis; if you are
> busy, you may want to see the conclusions first.
>
> I am focusing here solely on the identification
> function, and not touching the security requirements
> of the location function.  It should be noted, however,
> that these two are related in real life.  Analyzing that
> is for another message.
>
>
> a) identification for mobility and multi-homing
> -----------------------------------------------
>
> As I wrote earlier, here we are only interested in gaining
> assurance that the peer remains the *same*.  That is, we
> do not really care *whom* we are communicating with, but
> only that the peer end-point is not changed in mid-
> communication.  (We probably did care the "real identity"
> of the peer when we first initiated the communication, but
> that is a different issue, with different security
> requirements.)

I am not sure if i understand this...
I mean, we do care about recognizing the other end of a communication,
right?

Usually, when a host establish a communication, the host wants to establish
the communications with a certain host, it is not the case that we want to
communicate with any host available. So this is expressed by the ip address
of the target host. This means that we do care who the other end is.In other
words, IP addresses are used today for recognizing the other end.


So perhpaps i don't agree with a statement from your previous mail:

"1a) To me, identification for mobility and multi-homing seems to
    be the easiest one.  There we are only interested in gaining
assurance that the peer remains the same.  That is, for the
sole purpose of mobility or multi-homing, we do not really
care with whom we are communicating with, but only that the
peer end-point is not changed in mid-communication due to
mobility, multi-homing, or attacks based on mobility or
multi-homing mechanisms."

I guess we always care with who we are communicating with i.e. we always
need a permanent identifier -
This is true for at least for one end of the communication, the end that is
initiating the communication. Perhaps the server side of the communication
does not know who the initiator is and perhaps he doesn't even care, (as
long as it remains the same)

If you use a transient identifier, actually you are using two identifiers:
first the IP address as a permanent identifier to recognize the host and
then the transient identifier to recongnize the host when it changes its
address.

So i guess that what is needed is:
- a permanent identifier (so you can talk with who you really want to talk)
- A locator (so you can reach it)
- something to bind them (which can be a transient identifier, but you can
use some other stuff)

So i would say that ephemeral identifiers are not enough to provide
identification support for multi-homing and mobility support, we need more,
i.e. permanent identifiers.

Regards, marcelo

>
> There are two basic dangers related identification in mobility
> and multi-homing.  One is connection hijacking, i.e., somebody
> "stealing" the connection and replacing one of the peers without
> being noticed.  The other, less obvious one, is flooding.
> Flooding is an attack where a genuine peer lies about its
> location(s), with the purpose of choking a victim on excess
> traffic.  That is, the attacker claims to move/be better
> reachable at the location of a victim, thereby directing the
> traffic to the victim.
>
> Flooding is a serious attack since the amounts of redirected
> traffic can be large.  Consider a public streaming server.
> Anyone can make a connection to it, and start downloading a
> stream.  For the stream to run, acknowledgments must be sent
> back.  This is easy, since an attacker can open a stream,
> redirect the stream (using some mobility or multi-homing
> mechanism) to a victim address, and *continue* sending
> acknowledgments.  Anticipating when and what kinds of acks to
> send is easy enough.  This makes the stream running independent
> on the actions by the poor victim.
>
> Hence, for the purpose of mobility and multi-homing, the
> identification mechanism has to keep sure that the peer really
> remains the same, on all changes of locators.  Furthermore, the
> mechanism must not blindly trust what the peer claims about its
> locations, but must check that the same peer really *is*
> at all the claimed addresses.
>
> If we really do not care who the initial peer really is,
> then a simple protocol is sufficient; the protocol first
> creates a shared secret between the peers and then uses
> the secret to verify persistence of the identity.  The
> protocol may even be vulnerable to MitM attackers in its
> initialization state; our requirement states that a MitM
> attacker is equally good to the "real" intended peer,
> since we don't care about the "real identity".
>
> The requirements can be summarized as follows:
>
>    R1. Verification that the peer is the same one
>        after all changes of locators.
>    R2. Verification that the same peer is reachable
>        at all claimed (and used) locations.
>
> The MIPv6 RR protocol is a (somewhat convoluted) example of
> a protocol fulfilling the requirements.  (It also fulfills
> other, Mobile IPv6 specific security requirements.)
>
>
> b) identification for referral or rendezvous
> --------------------------------------------
>
> In the case of referral or rendezvous, an initiating party
> possesses an identifier that it wants to use as a means
> of identifying another party.  The target party may have
> no idea of the intentions of the first party, and it may
> have never met the first party.  In other words, the parties
> do not share any state but the identifier itself and any
> state in the target party that is associated with the
> identifier.
>
>  From a security point of view, the requirement is that
> the party that responds to a communication request really
> is the party denoted by the identifier, and someone else.
> That is, the requirement is that the target party really
> is the intended target party.
>
> If we assumed that everybody is honest, any unique bit
> string would serve well as an identifier.  The initiating
> party just sends the bit string to the target party, and
> asks the target party to verify that the bit string really
> is its identifier.  The problem is that we cannot necessarily
> assume everybody to be honest.
>
> If we assume dishonest parties, we get two sub cases.  In
> the first case, the initiating party must send the identifier
> in clear, for some reason, or the identifier is otherwise
> public and known by the dishonest parties.  In the second
> case, the initiating party is able to keep the identifier in
> secret.
>
> In the first case, the only secure way of performing
> identification seem to be public key cryptography (or any of
> its variants, like zero knowledge protocol).  The reason for
> this is the following.  Since the identifier is public
> knowledge, we cannot use the identifier directly.  Instead,
> there must be some secret that only the right party
> knows and is able to prove to know.  The identifier and the
> secret must be linked.  Only public key crypto (or a variant)
> seems to fulfill these requirements.
>
> The second case is more interesting, since it allows for
> some simple cryptographic protocols that show to the
> target party that the initiating party knows its secret
> identifier without revealing it, and where the target
> party is conversely able to show to the initiator that it
> also knows the secret identifier.  In effect, in this
> case the identifier is a shared secret.  However, it is
> also almost completely impractical, since one cannot
> share such a secret with anyone, nor put it into a public
> directory.  (There are some special cases where this kind
> of identification may be useful, but one cannot build a
> generic Internet wide architecture on such assumptions.)
>
> Hence, if we want to do referral and rendezvous in a
> secure way, we seem to need public keys as identifiers.
> It looks best to use public keys as primary identifiers.
> It is also possible to use public keys only as secondary
> identifiers, and bind them to some primary identifiers,
> but that costs more since it requires a PKI.   Using public
> keys directly as primary identifiers does not, as such,
> require a PKI.
>
> To summarize, the requirement is
>
>    R3. Verification that the target party really is the
>        party denoted by the identifier.
>
> With public identifiers and under the assumption that there
> may be man-in-the-middle or masquerading attackers, public
> keys (or variants) seem like the only known technology
> that securely fulfills this requirement.  It should be noted,
> however, that we do not necessarily need to care about
> potential man-in-the-middle or masquerading attackers.
> Whether to do so or not is a design choice.
>
> Discussion
> ----------
>
> To my best knowledge, the discussion above describes the
> essence of the difference between the current architecture
> and one where identifiers and locators are separated.
> In the current architecture, the mobility and multi-homing
> problem does not exist, since one is not allowed to change
> ones locators on the fly.  What comes to rendezvous and
> referral, the practice of using locators as identifiers
> offers a somewhat weak but very important form of security.
> Effectively, the practice limits the number of potential
> attackers hugely, from all nodes in the Internet to only
> those nodes that are on the path between the initiating
> party and the target address.
>
> It is extremely important to understand that if we really
> separate identifiers and locators, we become more vulnerable.
> Fortunately the class of potential attackers will not be
> everyone in the Internet, but only those that can tamper
> with the identifier -> locator mapping or otherwise get
> on the path between the initiating party and some locator.
>
> Conclusions
> -----------
>
> Separating identifiers and locators has security implications.
> To address these, we basically have a number of possibilities:
>
>    1) Design a _secure enough_ identifier -> locator mapping
>       service, thereby limiting the potential attackers to
>       those that can either tamper with the service or otherwise
>       receive packets sent to the (initially used) locator.
>       What is "secure enough" is a design choice.  The service
>       must be dynamic because it must be possible to update
>       the set of locators.
>
>    2) Decide to use public keys as primary identifiers,
>       and rely on public key cryptography for identification.
>
>    3) Design a _secure enough_ identifier -> public key mapping
>       service, thereby limiting the potential attackers
>       to those that can tamper with the service.  This is
>       effectively a PKI, but not necessarily as secure as what
>       people traditionally understand with a PKI.  The difference
>       to 1) is that here we are not vulnerable to attackers that
>       just get to the path but can't tamper with the service.
>       The service may be fairly static, since there is seldom
>       need to chance one's public key.
>
>    4) Go only half way, and stop where the identifiers can
>       be still used as (limited) locators.  The class of
>       attackers depends heavily on details, and cannot be
>       easily summarized.
>
> I refrain from making comments on any practical designs (like
> DNS), since that requires one to consider also other aspects
> but security.
>
> Questions
> ---------
>
> Does this analysis help?
> Do we have other choices but the four outlined above?
> Should create an I-D from this and the previus message? If so,
> should it be accepted by some WG as a working item?
>
> --Pekka Nikander
>
>
>




From owner-multi6@ops.ietf.org  Thu Sep 25 03:34:37 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11722
	for <multi6-archive@lists.ietf.org>; Thu, 25 Sep 2003 03:34:36 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A2QZb-00021s-0e
	for multi6-data@psg.com; Thu, 25 Sep 2003 07:29:59 +0000
Received: from [131.160.193.2] (helo=n2.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A2QZ4-0001zF-IX
	for multi6@ops.ietf.org; Thu, 25 Sep 2003 07:29:26 +0000
Received: from outside.nomadiclab.com (d2.nomadiclab.com [131.160.194.2])
	by n2.nomadiclab.com (Postfix) with ESMTP
	id 1239ACBA53; Thu, 25 Sep 2003 10:29:25 +0300 (EEST)
Received: from nomadiclab.com (localhost [127.0.0.1])
	by outside.nomadiclab.com (Postfix) with ESMTP
	id 536ED113E2E; Thu, 25 Sep 2003 10:29:24 +0300 (EEST)
Message-ID: <3F729955.4070409@nomadiclab.com>
Date: Thu, 25 Sep 2003 09:29:25 +0200
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mbagnulo@ing.uc3m.es
Cc: Multi6 WG <multi6@ops.ietf.org>, hipsec@honor.trusecure.com
Subject: Re: Security requirements for identification
References: <LIEEJBCNFDJHFFKJJDPAAEPCDAAA.marcelo@it.uc3m.es>
In-Reply-To: <LIEEJBCNFDJHFFKJJDPAAEPCDAAA.marcelo@it.uc3m.es>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
	      REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Marcelo,

>> a) identification for mobility and multi-homing
>> -----------------------------------------------
>>
>> As I wrote earlier, here we are only interested in gaining
>> assurance that the peer remains the *same*.  That is, we
>> do not really care *whom* we are communicating with, but
>> only that the peer end-point is not changed in mid-
>> communication.  (We probably did care the "real identity"
>> of the peer when we first initiated the communication, but
>> that is a different issue, with different security
>> requirements.)
> 
> I am not sure if i understand this...
> I mean, we do care about recognizing the other end of a communication,
> right?

Yes, we do care.  But we do not care for the very specific
purpose of "mobility and multi-homing", as I write.

A very important point in the analysis is to make a distinction
between identification in the beginning of a session,
and subsequent identifications that are needed during the
session, for various purposes.

Hence, the point is that _solely_ for *mobility* or *multi-homing*
you don't care about who, or any application level identity.
You only care about that the peer is not changed in mid communications.
Other parts of the system probably have other concerns, but not
the mobility / multi-homing mechanism.

> Usually, when a host establish a communication, the host wants to establish
> the communications with a certain host, it is not the case that we want to
> communicate with any host available. So this is expressed by the ip address
> of the target host. This means that we do care who the other end is.In other
> words, IP addresses are used today for recognizing the other end.

Yes.  What you describe is what I called in the previous
analysis as "initial rendezvous".  Things do get mixed in
real life.  However, when you try to understand the roots
of phenomena, you have to make distinctions and draw lines,
even if sometimes they first seem bizarre.

>> "1a) To me, identification for mobility and multi-homing seems to
>>     be the easiest one.  There we are only interested in gaining
>> assurance that the peer remains the same.  That is, for the
>> sole purpose of mobility or multi-homing, we do not really
>> care with whom we are communicating with, but only that the
>> peer end-point is not changed in mid-communication due to
>> mobility, multi-homing, or attacks based on mobility or
>> multi-homing mechanisms."
> 
> I guess we always care with who we are communicating with i.e. we always
> need a permanent identifier -

That may well be the case in most communications.  But _only_,
_solely_, _exclusively_ for mobility and multi-homing, you
do not *need* to care.

This may be deep, but this is one of the very points of the
analysis.  Make distinctions.

> If you use a transient identifier, actually you are using two identifiers:
> first the IP address as a permanent identifier to recognize the host and
> then the transient identifier to recongnize the host when it changes its
> address.

Now, that might be perfectly reasonable.  You are using the
permanent IP address for initial rendezvous, and then you use
a transient identifier to secure mobility.  In fact, that is
exactly what happens in Mobile IPv6 RO today.  You have the
home address, and you have Kbm, which is a kind of transient
identifier.

> So i guess that what is needed is:
> - a permanent identifier (so you can talk with who you really want to talk)

You need that for identification in the rendezvous sense.

> - A locator (so you can reach it)

You need that for reachability, not for identification.

> - something to bind them (which can be a transient identifier, but you can
> use some other stuff)

Yes.  But I haven't got that far yet :-)

> So i would say that ephemeral identifiers are not enough to provide
> identification support for multi-homing and mobility support, we need more,
> i.e. permanent identifiers.

I think that we are not (yet) on the same baseline with respect
to understanding the various components in the game.

--Pekka Nikander







From owner-multi6@ops.ietf.org  Thu Sep 25 05:21:52 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15328
	for <multi6-archive@lists.ietf.org>; Thu, 25 Sep 2003 05:21:52 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A2SFg-00092H-9S
	for multi6-data@psg.com; Thu, 25 Sep 2003 09:17:32 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A2SF5-00090k-I0
	for multi6@ops.ietf.org; Thu, 25 Sep 2003 09:16:55 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id D0246433F3; Thu, 25 Sep 2003 11:16:54 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.245])
	by smtp03.uc3m.es (Postfix) with SMTP
	id 7D1F12B695; Thu, 25 Sep 2003 11:16:54 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Pekka Nikander" <pekka.nikander@nomadiclab.com>, <mbagnulo@ing.uc3m.es>
Cc: "Multi6 WG" <multi6@ops.ietf.org>, <hipsec@honor.trusecure.com>
Subject: RE: Security requirements for identification
Date: Thu, 25 Sep 2003 11:12:14 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAMEPMDAAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3F729955.4070409@nomadiclab.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka,

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Pekka Nikander
> Enviado el: jueves, 25 de septiembre de 2003 9:29
> Para: mbagnulo@ing.uc3m.es
> CC: Multi6 WG; hipsec@honor.trusecure.com
> Asunto: Re: Security requirements for identification
>
>
> Marcelo,
>
> >> a) identification for mobility and multi-homing
> >> -----------------------------------------------
> >>
> >> As I wrote earlier, here we are only interested in gaining
> >> assurance that the peer remains the *same*.  That is, we
> >> do not really care *whom* we are communicating with, but
> >> only that the peer end-point is not changed in mid-
> >> communication.  (We probably did care the "real identity"
> >> of the peer when we first initiated the communication, but
> >> that is a different issue, with different security
> >> requirements.)
> >
> > I am not sure if i understand this...
> > I mean, we do care about recognizing the other end of a communication,
> > right?
>
> Yes, we do care.  But we do not care for the very specific
> purpose of "mobility and multi-homing", as I write.
>
> A very important point in the analysis is to make a distinction
> between identification in the beginning of a session,
> and subsequent identifications that are needed during the
> session, for various purposes.
>
> Hence, the point is that _solely_ for *mobility* or *multi-homing*
> you don't care about who, or any application level identity.
> You only care about that the peer is not changed in mid communications.
> Other parts of the system probably have other concerns, but not
> the mobility / multi-homing mechanism.
>
> > Usually, when a host establish a communication, the host wants
> to establish
> > the communications with a certain host, it is not the case that
> we want to
> > communicate with any host available. So this is expressed by
> the ip address
> > of the target host. This means that we do care who the other
> end is.In other
> > words, IP addresses are used today for recognizing the other end.
>
> Yes.  What you describe is what I called in the previous
> analysis as "initial rendezvous".  Things do get mixed in
> real life.  However, when you try to understand the roots
> of phenomena, you have to make distinctions and draw lines,
> even if sometimes they first seem bizarre.
>

Ok. I think i see what you mean.

> >> "1a) To me, identification for mobility and multi-homing seems to
> >>     be the easiest one.  There we are only interested in gaining
> >> assurance that the peer remains the same.  That is, for the
> >> sole purpose of mobility or multi-homing, we do not really
> >> care with whom we are communicating with, but only that the
> >> peer end-point is not changed in mid-communication due to
> >> mobility, multi-homing, or attacks based on mobility or
> >> multi-homing mechanisms."
> >
> > I guess we always care with who we are communicating with i.e. we always
> > need a permanent identifier -
>
> That may well be the case in most communications.  But _only_,
> _solely_, _exclusively_ for mobility and multi-homing, you
> do not *need* to care.
>
> This may be deep, but this is one of the very points of the
> analysis.  Make distinctions.
>
> > If you use a transient identifier, actually you are using two
> identifiers:
> > first the IP address as a permanent identifier to recognize the host and
> > then the transient identifier to recongnize the host when it changes its
> > address.
>
> Now, that might be perfectly reasonable.  You are using the
> permanent IP address for initial rendezvous, and then you use
> a transient identifier to secure mobility.  In fact, that is
> exactly what happens in Mobile IPv6 RO today.  You have the
> home address, and you have Kbm, which is a kind of transient
> identifier.
>
> > So i guess that what is needed is:
> > - a permanent identifier (so you can talk with who you really
> want to talk)
>
> You need that for identification in the rendezvous sense.
>

Ok

> > - A locator (so you can reach it)
>
> You need that for reachability, not for identification.
>

Ok

> > - something to bind them (which can be a transient identifier,
> but you can
> > use some other stuff)
>
> Yes.  But I haven't got that far yet :-)
>


Well, i been re-considering this point and i think i would like to re-state
it in the following way.

I guess that identifiers make sense if you can prove that you own them.
I mean i can tell you that i have identifier A but if i cannot prove that i
own it it isn't really useful.
So, usually we use IP addresses as identifiers, and the proof of ownership
is provided by the routing system.
Now the problem is that when we move or change the path to alternative
provider, we connot longer prove that we own our identifier.
So here is when a ephemeral identifier can help, since you can start using
the permanent idenfitifier (ip address) when you are capable of proving its
ownership, and at this moment create an ephemeral identifier, which you can
prove that you own by other means than the routing system i.e. crypto. And
then just forget about the permanent identifier and keep track of the
identity of the other end by just using the ephemeral identifier.
So, you don't need the ephemeral identifier to make a safe mapping to a
locator, but you need it to provide an alternative identifier whose
ownership can be proven when you cannot longer prove the ownership of the
permanent identifier.

Obviously, you could just solve the problem by using an identifier that
doesn't uses the routing system in order to prove its ownership, and it uses
a location idenpendent mean to prove it (just like public keys ;-)
However, the problem of initial rendezvous remains in this case.



> > So i would say that ephemeral identifiers are not enough to provide
> > identification support for multi-homing and mobility support,
> we need more,
> > i.e. permanent identifiers.
>
> I think that we are not (yet) on the same baseline with respect
> to understanding the various components in the game.
>

I think that your postings are being really useful to understand these
issues.
Thanks, marcelo

> --Pekka Nikander
>
>
>
>
>




From owner-multi6@ops.ietf.org  Thu Sep 25 17:40:20 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22577
	for <multi6-archive@lists.ietf.org>; Thu, 25 Sep 2003 17:40:20 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A2dnA-000IID-J6
	for multi6-data@psg.com; Thu, 25 Sep 2003 21:36:52 +0000
Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A2dmf-000IGz-75
	for multi6@ops.ietf.org; Thu, 25 Sep 2003 21:36:21 +0000
Received: from bebop.France.Sun.COM ([129.157.174.15])
	by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h8PLa5Vo017874;
	Thu, 25 Sep 2003 14:36:06 -0700 (PDT)
Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8PLa3Q12402;
	Thu, 25 Sep 2003 23:36:03 +0200 (MEST)
Date: Thu, 25 Sep 2003 23:15:04 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: RE: Security requirements for identification
To: mbagnulo@ing.uc3m.es
Cc: Pekka Nikander <pekka.nikander@nomadiclab.com>,
        Multi6 WG <multi6@ops.ietf.org>, hipsec@honor.trusecure.com
In-Reply-To: "Your message with ID" <LIEEJBCNFDJHFFKJJDPAAEPCDAAA.marcelo@it.uc3m.es>
Message-ID: <Roam.SIMC.2.0.6.1064524504.6763.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

> If you use a transient identifier, actually you are using two identifiers:
> first the IP address as a permanent identifier to recognize the host and
> then the transient identifier to recongnize the host when it changes its
> address.
> 
> So i guess that what is needed is:
> - a permanent identifier (so you can talk with who you really want to talk)
> - A locator (so you can reach it)
> - something to bind them (which can be a transient identifier, but you can
> use some other stuff)
> 
> So i would say that ephemeral identifiers are not enough to provide
> identification support for multi-homing and mobility support, we need more,
> i.e. permanent identifiers.

I think the security requirements are far from clear.

What is clear is that a mechanism that allows connections to survive
multihoming by being able to replace the identifiers that are used for a
connection, need to prevent redirection attacks where a connection is
accidentally or maliciously redirected to somebody else.

What is also clear is that any new system for mapping identifiers to
locators need to be concerned about security so that the chain
of starting with a FQDN and ending up with a packet received at the
peer isn't weaker than it is today, and that DNSsec applied to the parts
(e.g. FQDN->identifier lookup) can help make the security of that chain
stronger.

But the security requirements beyond this depend on what else we want
to use the locators for.
One possible use is a stable handle on a peer that has a longer lifetime
than both the locators and the FQDNs; if a node receives a packet
from an identifier and its the same identifier as was used 3 years ago, the
node can be sure it is the same node.

Another possible use is as a handle into some policy where the identifer
might have some hirarchy so that a node can tell e.g. whether a peer's
identifer belong to the same or different site as the node.

So I don't know if we have consensus that we need long-term stable identifiers
as part of id/locator separation. Perhaps we need multiple flavors of
identifers with some being long-term stable.

  Erik




From owner-multi6@ops.ietf.org  Fri Sep 26 11:17:35 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10377
	for <multi6-archive@lists.ietf.org>; Fri, 26 Sep 2003 11:17:34 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A2uIm-000LsM-LT
	for multi6-data@psg.com; Fri, 26 Sep 2003 15:14:36 +0000
Received: from [209.20.253.166] (helo=ran.psg.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A2uIH-000LoT-AD
	for multi6@ops.ietf.org; Fri, 26 Sep 2003 15:14:05 +0000
Received: from localhost ([127.0.0.1] helo=ran.psg.com)
	by ran.psg.com with esmtp (Exim 4.22)
	id 1A2uIG-000IaT-RF
	for multi6@ops.ietf.org; Fri, 26 Sep 2003 08:14:04 -0700
Message-ID: <LIEEJBCNFDJHFFKJJDPAEEBADBAA.mbagnulo@ing.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Roam.SIMC.2.0.6.1064524504.6763.nordmark@bebop.france>
From: "marcelo bagnulo" <mbagnulo@ing.uc3m.es>
To: "Erik Nordmark" <Erik.Nordmark@sun.com>, <mbagnulo@ing.uc3m.es>
Cc: "Pekka Nikander" <pekka.nikander@nomadiclab.com>,
        "Multi6 WG" <multi6@ops.ietf.org>, <hipsec@honor.trusecure.com>
Subject: RE: Security requirements for identification
Date: Fri, 26 Sep 2003 17:03:29 +0200
X-Spam-Status: No, hits=-1.8 required=5.0
	tests=BAYES_30,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi Erik,

> -----Mensaje original-----
> De: Erik Nordmark [mailto:Erik.Nordmark@sun.com]
> Enviado el: jueves, 25 de septiembre de 2003 23:15
> Para: mbagnulo@ing.uc3m.es
> CC: Pekka Nikander; Multi6 WG; hipsec@honor.trusecure.com
> Asunto: RE: Security requirements for identification
>
>
> > If you use a transient identifier, actually you are using two
> identifiers:
> > first the IP address as a permanent identifier to recognize the host and
> > then the transient identifier to recongnize the host when it changes its
> > address.
> >
> > So i guess that what is needed is:
> > - a permanent identifier (so you can talk with who you really
> want to talk)
> > - A locator (so you can reach it)
> > - something to bind them (which can be a transient identifier,
> but you can
> > use some other stuff)
> >
> > So i would say that ephemeral identifiers are not enough to provide
> > identification support for multi-homing and mobility support,
> we need more,
> > i.e. permanent identifiers.
>
> I think the security requirements are far from clear.
>

Agree, but i think we are making some progress here.
I think i would be a good idea to accept Pekka's offert, and put some of his
postings in a ID format. IMHO this could be good starting point to
understand the requirements.

> What is clear is that a mechanism that allows connections to survive
> multihoming by being able to replace the identifiers that are used for a
> connection, need to prevent redirection attacks where a connection is
> accidentally or maliciously redirected to somebody else.
>
> What is also clear is that any new system for mapping identifiers to
> locators need to be concerned about security so that the chain
> of starting with a FQDN and ending up with a packet received at the
> peer isn't weaker than it is today,

We should also preserve the security of communications that don't use the
DNS i.e. they use IP address directly. I mean, it is safer to use directly
IP addresses than using names (without DNS). This capability has to be
preserved. This means that not only the chain starting from a FQDN and
ending in the packet delivery has to remain as safe as it is today, but also
it has to be possible to establish a communication with the same level of
security of the one obtained today when sending packets directly to ip
addresses without using the DNS.

> and that DNSsec applied to the parts
> (e.g. FQDN->identifier lookup) can help make the security of that chain
> stronger.
>
> But the security requirements beyond this depend on what else we want
> to use the locators for.
> One possible use is a stable handle on a peer that has a longer lifetime
> than both the locators and the FQDNs; if a node receives a packet
> from an identifier and its the same identifier as was used 3
> years ago, the
> node can be sure it is the same node.
>
> Another possible use is as a handle into some policy where the identifer
> might have some hirarchy so that a node can tell e.g. whether a peer's
> identifer belong to the same or different site as the node.
>
> So I don't know if we have consensus that we need long-term
> stable identifiers
> as part of id/locator separation.

Ok, this depends on what do you call stable.
But, i guess we agree that in order to able to establish a communication,
the initiating party has to be capable of identifying the other party, so
that it can define who he wants to talk to. This means that some form of
stable identifier is needed at least for the server party of the
communication.

Perhap we can see the IPv4 situation and evaluate which kind of identifiers
are needed.
An intersting point is that some hosts never have a permanent identifier and
perhaps they don't need it (for instance hosts through dial-up with dhcp)
On the other hand, servers need stable identifiers so they can be reached.

> Perhaps we need multiple flavors of
> identifers with some being long-term stable.
>

indeed, perhaps we do.

Thanks, marcelo

>   Erik
>






From owner-multi6@ops.ietf.org  Fri Sep 26 12:56:29 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13752
	for <multi6-archive@lists.ietf.org>; Fri, 26 Sep 2003 12:56:28 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A2vog-0004NN-D1
	for multi6-data@psg.com; Fri, 26 Sep 2003 16:51:38 +0000
Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A2voA-0004HV-6q
	for multi6@ops.ietf.org; Fri, 26 Sep 2003 16:51:06 +0000
Received: from bebop.France.Sun.COM ([129.157.174.15])
	by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h8QGorVo002470;
	Fri, 26 Sep 2003 09:50:54 -0700 (PDT)
Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8QGooQ01182;
	Fri, 26 Sep 2003 18:50:50 +0200 (MEST)
Date: Fri, 26 Sep 2003 18:45:48 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: RE: Security requirements for identification
To: marcelo bagnulo <mbagnulo@ing.uc3m.es>
Cc: Erik Nordmark <Erik.Nordmark@sun.com>,
        Pekka Nikander <pekka.nikander@nomadiclab.com>,
        Multi6 WG <multi6@ops.ietf.org>, hipsec@honor.trusecure.com
In-Reply-To: "Your message with ID" <LIEEJBCNFDJHFFKJJDPAEEBADBAA.mbagnulo@ing.uc3m.es>
Message-ID: <Roam.SIMC.2.0.6.1064594748.2326.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Spam-Status: No, hits=-0.8 required=5.0
	tests=IN_REP_TO,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

> Agree, but i think we are making some progress here.
> I think i would be a good idea to accept Pekka's offert, and put some of his
> postings in a ID format. IMHO this could be good starting point to
> understand the requirements.

Agreed.

> We should also preserve the security of communications that don't use the
> DNS i.e. they use IP address directly. I mean, it is safer to use directly
> IP addresses than using names (without DNS). This capability has to be
> preserved. This means that not only the chain starting from a FQDN and
> ending in the packet delivery has to remain as safe as it is today, but also
> it has to be possible to establish a communication with the same level of
> security of the one obtained today when sending packets directly to ip
> addresses without using the DNS.

You use the term "IP address" which I've removed from
my vocabulary in this context; are you talking about an identifier or
a locator?

> Ok, this depends on what do you call stable.
> But, i guess we agree that in order to able to establish a communication,
> the initiating party has to be capable of identifying the other party, so
> that it can define who he wants to talk to. This means that some form of
> stable identifier is needed at least for the server party of the
> communication.

Yes, but potentially such a number doesn't need to be globally unique.
I can envision potential solutions, their desirability aside,
where each server would pick a random number at its identifier
with no global coordination, publish that number in the DNS
(e.g. using a new ID record) together with the locators published as AAAA 
records.
This would allow the client to use the fqdn to find both this identifier
and the locators for the service and communicate. Such "identifiers" do
not need to be globally unique, and they might change as frequently
as it is feasible to update the DNS ID record.
So I hope the above illustrates that there isn't an inherent requirement
from the multi6 problem set to make the identifiers globally unique or stable.

That doesn't mean that it is a good idea to make them unstable. Since we need
to prevent redirection attacks there has to be a way to check who is authorized
to redirect the packet flow for a given identifier to some new locator. That
would be quite confusing if multiple nodes happen to use the same identifier
while communicating with the same peer; "redirect packets for id=X" would then
affect traffic to two separate nodes thus the authorization question can't be
answered.

So I think the multi6 problem set requires very low probability that two
nodes use the same identifier when communicating with a given peer.

But I don't think it is until you also look at other problems, like
identifiers that can be used by applications for rendez-vous and referral,
that the stability issue comes to the forefront.
(One could argue that from the perspective of the UDP/IP stack, an
application over UDP behaves in ways that look like applications doing
rendez-vous; the only difference might be implicit assumptions about what
the elapsed time is between receiving something and trying to send something
back.)

So I'm all for stable identifiers for general application using being
part of the free lunch; but oops - there is no free lunch :-)
Thus we need to try to tease apart the different uses of identifiers
and understand the requirements a bit more.

> Perhap we can see the IPv4 situation and evaluate which kind of identifiers
> are needed.
> An intersting point is that some hosts never have a permanent identifier and
> perhaps they don't need it (for instance hosts through dial-up with dhcp)
> On the other hand, servers need stable identifiers so they can be reached.

But is this ("clients" not have stable IP or DNS names) a feature or a bug?

Turning things around, one could ask what the benefits would be of having
an identifier which 1) doesn't change when you change ISP and 2) doesn't
change due to some administrative mistake (like not renewing your domain
name with the registrar).

  Erik




From owner-multi6@ops.ietf.org  Fri Sep 26 20:33:19 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00574
	for <multi6-archive@lists.ietf.org>; Fri, 26 Sep 2003 20:33:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A32xg-000PGP-Oz
	for multi6-data@psg.com; Sat, 27 Sep 2003 00:29:24 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A32xA-000PCF-VE
	for multi6@ops.ietf.org; Sat, 27 Sep 2003 00:28:53 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8R0Y1P30463;
	Fri, 26 Sep 2003 17:34:02 -0700
Date: Fri, 26 Sep 2003 17:28:37 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <5921363068.20030926172837@brandenburg.com>
To: Pekka Nikander <pekka.nikander@nomadiclab.com>
CC: Multi6 WG <multi6@ops.ietf.org>, hipsec@honor.trusecure.com
Subject: Re: Security requirements for identification
In-Reply-To: <3F714C8E.4070205@nomadiclab.com>
References: <3F714C8E.4070205@nomadiclab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-0.4 required=5.0
	tests=IN_REP_TO,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pekka,

I think I said this last time, but just in case:  thanks for working on
cohesive discussion about needs and issues for identification.  It makes it so
much easier to debate specifics...

My comments, below, are tuned for multiaddressing, since that it the
motivation du jour. If the scope of this discussion is meant to be broader
than dealing with mobility and multihoming, please forgive my error.


PN> a) identification for mobility and multi-homing
PN> As I wrote earlier, here we are only interested in gaining
PN> assurance that the peer remains the *same*.

yes.


PN> There are two basic dangers related identification in mobility
PN> and multi-homing.  One is connection hijacking,

yes.

PN> being noticed.  The other, less obvious one, is flooding.

I am only now finally understanding why this is a problem "created" by
multiaddressing.   Hijacking is directing traffic to oneself.  Flooding is
directing traffic to someone else.  One is to intercept data and the other is
to overload a victim.  Both problems are created by being able to ... redirect
traffic to a new address.

Thank you!


PN> Hence, for the purpose of mobility and multi-homing, the
PN> identification mechanism has to keep sure that the peer really
PN> remains the same, on all changes of locators.  Furthermore, the
PN> mechanism must not blindly trust what the peer claims about its 
PN> locations, but must check that the same peer really *is*
PN> at all the claimed addresses.

Hmmm. Carried to the extreme the requirement seems to specify would probably
require having every packet be encrypted -- so it could only be decoded by the
correct recipient -- and acknowledged with a signature.

At most, I suspect you really mean that there must be a "useful" confirmation
when a new target address is used for the first time. For example, if there
are nonce-based association identifiers,

    1) the initiator using the target address for the first includes the
    target's nonce in some sort of "hello again" packet, and

    2) the target responds with a packet containing the initiator's nonce.

This goes beyond the safety provided in current, mono-addressing IP, but
certainly is focused on problems caused (or exacerbated) by the introduction
of multiaddressing.

    
PN> b) identification for referral or rendezvous

PN> In the case of referral or rendezvous, an initiating party
PN> possesses an identifier that it wants to use as a means
PN> of identifying another party.

In spite of the above language, you do not define rendezvous and referral. I
have been assuming the latter means "moving an association from one endpoint
to another". That is, "hand off" of one end of an association to a new
endpoint.

So, please clarify what you mean by both terms and how they relate to the
distinction between identifying versus locating.

I believe the two terms can, and should, refer to two different things (unless
there is already an established practise of using them synonymously)

Rendezvous is a means of one endpoint finding another. It often uses a
third-party intermediary. It may or may not occur when there already is
context between the two endpoints.

Referral is a means by which one host in an association can replace itself
with another host.  That is, it transfers the association context to a third
host.


PN> If we assumed that everybody is honest, any unique bit
PN> string would serve well as an identifier.  The initiating
PN> party just sends the bit string to the target party, and
PN> asks the target party to verify that the bit string really
PN> is its identifier.  The problem is that we cannot necessarily
PN> assume everybody to be honest.

PN> If we assume dishonest parties, we get two sub cases.  In
PN> the first case, the initiating party must send the identifier
PN> in clear, for some reason, or the identifier is otherwise
PN> public and known by the dishonest parties.  In the second
PN> case, the initiating party is able to keep the identifier in
PN> secret.

This line of thinking appears to go quite a bit beyond the current world of IP
mon-addressing.  And I believe it involves concerns not created by
multiaddressing.

However validly, we trust DNS entries and IP routing.  As soon as you worry
about whether to send an identifier in the clear, you are considering
something far broader than problems caused by multiaddressing.


PN> In the first case, the only secure way of performing
PN> identification seem to be public key cryptography (or any of
PN> its variants, like zero knowledge protocol).  The reason for
PN> this is the following.  Since the identifier is public
PN> knowledge, we cannot use the identifier directly.

Today, we use domain names and IP addresses in the clear.  And things work
pretty well.

To use Marcelo's phrasing, we do not "prove we own" the domain names are IP
addresses we use.

So, why must we start encrypting identifiers?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




From owner-multi6@ops.ietf.org  Sun Sep 28 06:23:19 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13579
	for <multi6-archive@lists.ietf.org>; Sun, 28 Sep 2003 06:23:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A3YcC-0001nB-7b
	for multi6-data@psg.com; Sun, 28 Sep 2003 10:17:20 +0000
Received: from [213.221.138.98] (helo=kurtis-lindqvists-computer.local)
	by psg.com with esmtp (Exim 4.22)
	id 1A3Ybg-0001mQ-IG
	for multi6@ops.ietf.org; Sun, 28 Sep 2003 10:16:48 +0000
Received: from kurtis.pp.se (localhost [127.0.0.1])
	by kurtis-lindqvists-computer.local (8.12.9/8.10.2) with ESMTP id h8SAGWdV000813;
	Sun, 28 Sep 2003 12:16:32 +0200 (CEST)
Date: Thu, 25 Sep 2003 17:21:30 +0200
Subject: Re: Security requirements for identification
Content-Type: text/plain; charset=US-ASCII; format=fixed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: Multi6 WG <multi6@ops.ietf.org>, hipsec@honor.trusecure.com
To: Pekka Nikander <pekka.nikander@nomadiclab.com>, Randy Bush <randy@psg.com>,
        Christian Huitema <huitema@windows.microsoft.com>,
        Tony Li <Tony.Li@procket.com>
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
In-Reply-To: <3F714C8E.4070205@nomadiclab.com>
Message-Id: <F0420111-EF6B-11D7-B2E8-0003936663F8@kurtis.pp.se>
Content-Transfer-Encoding: 7bit
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.552)
X-Spam-Status: No, hits=-4.5 required=5.0
	tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE,
	      QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On onsdag, sep 24, 2003, at 09:49 Europe/Stockholm, Pekka Nikander 
wrote:

> Does this analysis help?

I think it does raise / point out some interesting facts on what can / 
can't be properties of identifiers.

> Do we have other choices but the four outlined above?
> Should create an I-D from this and the previus message? If so,
> should it be accepted by some WG as a working item?

I have two question to the WG, and especially to the DT chairs and the 
AD :

1) Would we consider it useful to have a WG document on properties of 
identifiers, in terms of security? Maybe even call it "Security 
requirements"? From Tony's ad-hoc poll, there seems to be a clear 
majority in favor of some sort of id/loc split, with reservations on 
what each of them really is.

2) Do we think we could get rough consensus around such a document? In 
some other words, the WG will still of course be free to choose not to 
adapt a document by Pekka. But as the discussion following Tonys 
question showed, there are very different views on what an identifier 
is/might be. I think we at some point need to start to narrow this 
down. This is of course part of what the DT's are working on, that is 
why I also ask the DT chairs if they would consider this helpful.

I do realize that such a document will have to make certain assumptions 
on what an identifier is. But I also think that might be issues we 
could sort out as the DTs present at we get better understanding.

Ok, so....<making room in mail folder>...:-)

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBP3MH/KarNKXTPFCVEQIynwCfVBjy3u+XYMtC+49r2Q9PmmaKatIAoMQR
sxP4p9jm4KBzA3SkeUYhj84y
=dT/c
-----END PGP SIGNATURE-----




From owner-multi6@ops.ietf.org  Sun Sep 28 13:50:15 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25115
	for <multi6-archive@lists.ietf.org>; Sun, 28 Sep 2003 13:50:14 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A3fag-0000e8-Mj
	for multi6-data@psg.com; Sun, 28 Sep 2003 17:44:14 +0000
Received: from [65.174.124.36] (helo=dmz1.procket.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A3fZX-0000aQ-EZ
	for multi6@ops.ietf.org; Sun, 28 Sep 2003 17:43:03 +0000
Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60])
	by dmz1.procket.com (Postfix) with ESMTP
	id 4930123C48; Sun, 28 Sep 2003 09:51:46 -0700 (PDT)
Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8])
	by miata.procket.com (8.12.1/8.12.1) with ESMTP id h8SHgxYB023376;
	Sun, 28 Sep 2003 10:42:59 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Security requirements for identification
Date: Sun, 28 Sep 2003 10:42:58 -0700
Message-ID: <D2EC481073504E498A8DB9C0687E8CAF067D327D@EXCHANGE0-0.na.procket.com>
Thread-Topic: Security requirements for identification
Thread-Index: AcOFqakFPcIxEyrERHaHFjElhAibCQAO+yfA
From: "Tony Li" <Tony.Li@procket.com>
To: "Kurt Erik Lindqvist" <kurtis@kurtis.pp.se>,
        "Pekka Nikander" <pekka.nikander@nomadiclab.com>,
        "Randy Bush" <randy@psg.com>,
        "Christian Huitema" <huitema@windows.microsoft.com>
Cc: "Multi6 WG" <multi6@ops.ietf.org>, <hipsec@honor.trusecure.com>
X-Spam-Status: No, hits=0.0 required=5.0
	tests=none
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable



Hmmm....  I suppose that I should respond.  ;-)

Yes, I think that that some kind of consensus on the properties
of identifiers is a necessity.  There is a long discussion
to get there.  Could we get rough consensus on it?  Yes, I think
so, but it might be very rough.  And it might take a very long
time.  Certainly the discussions within our design team have taken
awhile and that's with a much smaller number of people.  It may
well be faster to start the discussion with the output of one of
the design teams, so that the discussion can revolve around an
entire design, rather than effectively throwing open design discussions
to the entire WG.  I'm flexible in this regard.

However, as a Loyal Opponent of Bureaucracy, I have to question
whether this needs to be a document.  And whether this needs to
be an official WG document, given that it will not become end
product.

In the Good Olde Days, the IETF use to be far more cooperative than it
is today.  Some of that was undoubtedly due to the money grubbing
effects that were introducd by the bubble.  However, with the=20
bubble behind us, I would very much like to see if we can
recapture that cooperative spirit and avoid some of the
unnecessary squabbling that goes on.  IMHO, having dueling
drafts is one of the more destructive forces against cooperation.
As soon as there is a draft, the authors have a 'position', and
they need to defend it.  And the squabbling begins.

In the Good Olde Days, the WG chair was a neutral discussion
leader and tried to establish consensus by ensuring that=20
differing points of view were represented in the work output
and that the group came to rough consensus on very small points
in a gradual manner.  This is not the only way that these things
can happen, but a reminder of what once was.  I leave it to the
WG to choose the best path.

Yours in cooperation,
Tony



From owner-multi6@ops.ietf.org  Mon Sep 29 07:15:00 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04727
	for <multi6-archive@lists.ietf.org>; Mon, 29 Sep 2003 07:14:59 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A3vtY-000MYY-Gn
	for multi6-data@psg.com; Mon, 29 Sep 2003 11:08:48 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A3vt1-000MXw-Jp
	for multi6@ops.ietf.org; Mon, 29 Sep 2003 11:08:15 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id DCBDF43366; Mon, 29 Sep 2003 13:08:14 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.245])
	by smtp03.uc3m.es (Postfix) with SMTP
	id B0CF52B67D; Mon, 29 Sep 2003 13:08:14 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Erik Nordmark" <Erik.Nordmark@sun.com>,
        "marcelo bagnulo" <mbagnulo@ing.uc3m.es>
Cc: "Pekka Nikander" <pekka.nikander@nomadiclab.com>,
        "Multi6 WG" <multi6@ops.ietf.org>, <hipsec@honor.trusecure.com>
Subject: RE: Security requirements for identification
Date: Mon, 29 Sep 2003 13:03:29 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAGECDDBAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.1064594748.2326.nordmark@bebop.france>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=-0.9 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> > We should also preserve the security of communications that
> don't use the
> > DNS i.e. they use IP address directly. I mean, it is safer to
> use directly
> > IP addresses than using names (without DNS). This capability has to be
> > preserved. This means that not only the chain starting from a FQDN and
> > ending in the packet delivery has to remain as safe as it is
> today, but also
> > it has to be possible to establish a communication with the
> same level of
> > security of the one obtained today when sending packets directly to ip
> > addresses without using the DNS.
>
> You use the term "IP address" which I've removed from
> my vocabulary in this context; are you talking about an identifier or
> a locator?

I am considering the current use of ip addresses i.e. before the loc/id
split, so ip addresses are both locators and identifiers.
What i mean is that currenlty you can use ip addresses in order to obtain
some added security. For instance you can use directly ip addresses (no
FQDN) so that you don't have to turst in the DNS, and you can also use the
IP address to allow incoming communications an so on.


>
> > Ok, this depends on what do you call stable.
> > But, i guess we agree that in order to able to establish a
> communication,
> > the initiating party has to be capable of identifying the other
> party, so
> > that it can define who he wants to talk to. This means that some form of
> > stable identifier is needed at least for the server party of the
> > communication.
>
> Yes, but potentially such a number doesn't need to be globally unique.
> I can envision potential solutions, their desirability aside,
> where each server would pick a random number at its identifier
> with no global coordination, publish that number in the DNS
> (e.g. using a new ID record) together with the locators published as AAAA
> records.
> This would allow the client to use the fqdn to find both this identifier
> and the locators for the service and communicate. Such "identifiers" do
> not need to be globally unique, and they might change as frequently
> as it is feasible to update the DNS ID record.
> So I hope the above illustrates that there isn't an inherent requirement
> from the multi6 problem set to make the identifiers globally
> unique or stable.

Actually what you are really doing is to use fqdn as permanent identifiers
and the DNS as a rendez-vous system, so it provides you with the transient
identifier and also with the locator.

I mean, if you want to establish a communication with someone you already
know, you need a mean to express his identity, and that is a permanent
identifier.

(the other option that i could think of are limited lifetime identifiers
that overlap in time so that you can provide one and obtain the next one,
which will be valid for the next period)
However i think that we could focus on the case that atr least for some
hosts, a permanent identifier is needed, or put it in another way, we can
provide differents types of identifiers, but one of these types should be a
permentent one.

>
> That doesn't mean that it is a good idea to make them unstable.
> Since we need
> to prevent redirection attacks there has to be a way to check who
> is authorized
> to redirect the packet flow for a given identifier to some new
> locator. That
> would be quite confusing if multiple nodes happen to use the same
> identifier
> while communicating with the same peer; "redirect packets for
> id=X" would then
> affect traffic to two separate nodes thus the authorization
> question can't be
> answered.
>
> So I think the multi6 problem set requires very low probability that two
> nodes use the same identifier when communicating with a given peer.
>
> But I don't think it is until you also look at other problems, like
> identifiers that can be used by applications for rendez-vous and referral,
> that the stability issue comes to the forefront.

But you need initial rendez vous if you want to provide a multi-homing
solution that works, so it is part of the multi-homing problem

> (One could argue that from the perspective of the UDP/IP stack, an
> application over UDP behaves in ways that look like applications doing
> rendez-vous; the only difference might be implicit assumptions about what
> the elapsed time is between receiving something and trying to
> send something
> back.)
>
> So I'm all for stable identifiers for general application using being
> part of the free lunch; but oops - there is no free lunch :-)
> Thus we need to try to tease apart the different uses of identifiers
> and understand the requirements a bit more.
>
> > Perhap we can see the IPv4 situation and evaluate which kind of
> identifiers
> > are needed.
> > An intersting point is that some hosts never have a permanent
> identifier and
> > perhaps they don't need it (for instance hosts through dial-up
> with dhcp)
> > On the other hand, servers need stable identifiers so they can
> be reached.
>
> But is this ("clients" not have stable IP or DNS names) a feature
> or a bug?
>
> Turning things around, one could ask what the benefits would be of having
> an identifier which 1) doesn't change when you change ISP and 2) doesn't
> change due to some administrative mistake (like not renewing your domain
> name with the registrar).
>

Agree, i can see many benefits in those cases, but are those features
essential to a multi-homing solution? or are they just a nice-to-have
feature? Would you inlcude them in the MUST list of a loc/id split solution
for multi-homing?

Thanks, marcelo

>   Erik
>
>




From owner-multi6@ops.ietf.org  Mon Sep 29 07:43:57 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05418
	for <multi6-archive@lists.ietf.org>; Mon, 29 Sep 2003 07:43:56 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A3wPp-000Os2-3y
	for multi6-data@psg.com; Mon, 29 Sep 2003 11:42:09 +0000
Received: from [163.117.136.123] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A3wPI-000On1-Aw
	for multi6@ops.ietf.org; Mon, 29 Sep 2003 11:41:36 +0000
Received: from smtp03.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id 6DEF543490; Mon, 29 Sep 2003 13:41:35 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.245])
	by smtp03.uc3m.es (Postfix) with SMTP
	id BC9352B680; Mon, 29 Sep 2003 13:41:34 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Dave Crocker" <dcrocker@brandenburg.com>,
        "Pekka Nikander" <pekka.nikander@nomadiclab.com>
Cc: "Multi6 WG" <multi6@ops.ietf.org>, <hipsec@honor.trusecure.com>
Subject: RE: Security requirements for identification
Date: Mon, 29 Sep 2003 13:36:49 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAEECFDBAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <5921363068.20030926172837@brandenburg.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=0.0 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Dave,
>
> PN> Hence, for the purpose of mobility and multi-homing, the
> PN> identification mechanism has to keep sure that the peer really
> PN> remains the same, on all changes of locators.  Furthermore, the
> PN> mechanism must not blindly trust what the peer claims about its
> PN> locations, but must check that the same peer really *is*
> PN> at all the claimed addresses.
>
> Hmmm. Carried to the extreme the requirement seems to specify
> would probably
> require having every packet be encrypted -- so it could only be
> decoded by the
> correct recipient -- and acknowledged with a signature.
>
> At most, I suspect you really mean that there must be a "useful"
> confirmation
> when a new target address is used for the first time. For
> example, if there
> are nonce-based association identifiers,
>
>     1) the initiator using the target address for the first includes the
>     target's nonce in some sort of "hello again" packet, and
>
>     2) the target responds with a packet containing the initiator's nonce.
>
> This goes beyond the safety provided in current, mono-addressing IP, but
> certainly is focused on problems caused (or exacerbated) by the
> introduction
> of multiaddressing.

Not really. Current mono-addressing IP security relies on routing (id=loc so
if you trust the routing system then it will deliver the packet to the
correct IP==ID)
So current mono-address ip does perform a verification that the other end of
the communication remains the same in EVERY packet.
This scheme of nonce validation only verifies the id of the other end at the
begining of the communication (or when a new address is included). So, it is
stronger for the moment when this exchange occurs, but it opens the
possibility of attacks shifted in time, since this scheme does not verifies
the identity all the time.
So, the nonce based scheme it is stronger in one sense but it is weaker in
another sense

(To overcome this issue, mip demands a periodical exchange of nonces so that
the identity of the other end of the communication is verified periodically)

>
>
> PN> b) identification for referral or rendezvous
>
> PN> In the case of referral or rendezvous, an initiating party
> PN> possesses an identifier that it wants to use as a means
> PN> of identifying another party.
>
> In spite of the above language, you do not define rendezvous and
> referral. I
> have been assuming the latter means "moving an association from
> one endpoint
> to another". That is, "hand off" of one end of an association to a new
> endpoint.
>
> So, please clarify what you mean by both terms and how they relate to the
> distinction between identifying versus locating.
>
> I believe the two terms can, and should, refer to two different
> things (unless
> there is already an established practise of using them synonymously)
>
> Rendezvous is a means of one endpoint finding another. It often uses a
> third-party intermediary. It may or may not occur when there already is
> context between the two endpoints.
>
> Referral is a means by which one host in an association can replace itself
> with another host.  That is, it transfers the association context
> to a third
> host.
>
>
> PN> If we assumed that everybody is honest, any unique bit
> PN> string would serve well as an identifier.  The initiating
> PN> party just sends the bit string to the target party, and
> PN> asks the target party to verify that the bit string really
> PN> is its identifier.  The problem is that we cannot necessarily
> PN> assume everybody to be honest.
>
> PN> If we assume dishonest parties, we get two sub cases.  In
> PN> the first case, the initiating party must send the identifier
> PN> in clear, for some reason, or the identifier is otherwise
> PN> public and known by the dishonest parties.  In the second
> PN> case, the initiating party is able to keep the identifier in
> PN> secret.
>
> This line of thinking appears to go quite a bit beyond the
> current world of IP
> mon-addressing.  And I believe it involves concerns not created by
> multiaddressing.
>
> However validly, we trust DNS entries and IP routing.  As soon as
> you worry
> about whether to send an identifier in the clear, you are considering
> something far broader than problems caused by multiaddressing.
>

I don't completelly agree.
Today you can establish a communication using only an IP address (you can
avoid using the DNS for security reasons)
So i don't think is reasonable to say that all ip addresses are as weak as a
communication that involves a dns query (if we can say this, the security
problems would be greatly reduced).
I do agree with the routing part.

>
> PN> In the first case, the only secure way of performing
> PN> identification seem to be public key cryptography (or any of
> PN> its variants, like zero knowledge protocol).  The reason for
> PN> this is the following.  Since the identifier is public
> PN> knowledge, we cannot use the identifier directly.
>
> Today, we use domain names and IP addresses in the clear.  And things work
> pretty well.
>
> To use Marcelo's phrasing, we do not "prove we own" the domain
> names are IP
> addresses we use.

You do prove that you own the IP address, the routing system does it.
About the DNS, see my comment below i.e. you can establish a communication
without using the DNS today and i don't think it is reasonable to design a
solution imposing the dns security level to all possible communications.

(BTW I read the address ownership expression fro the first time in Pekka's
draft "An Address Ownership Problem in IPv6"
(<draft-nikander-ipng-address-ownership-00.txt>))

Regards, marcelo

>
> So, why must we start encrypting identifiers?
>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>
>




From owner-multi6@ops.ietf.org  Mon Sep 29 10:19:19 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17451
	for <multi6-archive@lists.ietf.org>; Mon, 29 Sep 2003 10:19:18 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A3ynx-000B1L-0q
	for multi6-data@psg.com; Mon, 29 Sep 2003 14:15:13 +0000
Received: from [217.29.64.36] (helo=kurtis-lindqvists-computer.local)
	by psg.com with esmtp (Exim 4.22)
	id 1A3ymX-000Arv-8w
	for multi6@ops.ietf.org; Mon, 29 Sep 2003 14:13:45 +0000
Received: from kurtis.pp.se (localhost [127.0.0.1])
	by kurtis-lindqvists-computer.local (8.12.9/8.10.2) with ESMTP id h8TEDidV001272
	for <multi6@ops.ietf.org>; Mon, 29 Sep 2003 16:13:45 +0200 (CEST)
Date: Mon, 29 Sep 2003 16:13:40 +0200
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=fixed
Subject: Minneapolis
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
To: multi6@ops.ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <20121D22-F287-11D7-B8C3-0003936663F8@kurtis.pp.se>
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.552)
X-Spam-Status: No, hits=-2.2 required=5.0
	tests=BAYES_30,PGP_SIGNATURE,UPPERCASE_25_50,USER_AGENT_APPLEMAIL
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



I need to start to put together an agenda for Minneapolis. If you have 
something you want to present, please mail me off-list.

Best regards,

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBP3g+FqarNKXTPFCVEQJTyACfb2fno6/NBUbptQen8L72lPKxcYAAoMOY
KB8EEqF32yxrILHQTYwIU2ji
=VWtR
-----END PGP SIGNATURE-----




From owner-multi6@ops.ietf.org  Mon Sep 29 12:24:42 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27127
	for <multi6-archive@lists.ietf.org>; Mon, 29 Sep 2003 12:24:42 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A40lM-000NsO-9f
	for multi6-data@psg.com; Mon, 29 Sep 2003 16:20:40 +0000
Received: from [209.20.253.166] (helo=ran.psg.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A40ju-000Nkn-6k
	for multi6@ops.ietf.org; Mon, 29 Sep 2003 16:19:10 +0000
Received: from localhost ([127.0.0.1] helo=ran.psg.com)
	by ran.psg.com with esmtp (Exim 4.22)
	id 1A40jt-000CBe-1e
	for multi6@ops.ietf.org; Mon, 29 Sep 2003 09:19:09 -0700
Message-ID: <683463363.20030929091236@brandenburg.com>
In-Reply-To: <LIEEJBCNFDJHFFKJJDPAEECFDBAA.marcelo@it.uc3m.es>
References: <5921363068.20030926172837@brandenburg.com>
 <LIEEJBCNFDJHFFKJJDPAEECFDBAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 29 Sep 2003 09:12:36 -0700
From: Dave Crocker <dhc@dcrocker.net>
To: "marcelo bagnulo" <marcelo@it.uc3m.es>
CC: "Multi6 WG" <multi6@ops.ietf.org>
Subject: Re: Security requirements for identification
X-Spam-Status: No, hits=0.1 required=5.0
	tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,
	      REFERENCES,REPLY_WITH_QUOTES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

marcelo,

(I subscribe under different addresses, to multi6 vs. hipsec.  So my replies
are only making it to multi6. I think that that is the right venue for this
discussion. )


mb> Not really. Current mono-addressing IP security relies on routing (id=loc so
mb> if you trust the routing system then it will deliver the packet to the
mb> correct IP==ID)

The question is how the IP address is obtained. _Using_ an IP address when
there is multiaddressing also relies on the routing system to deliver the
packet to the correct IP address.

What is different is that multiaddressing introduces a way of _changing_ that
original IP address into another one. Although the sender still chooses which
IP address to use, the multiaddressing proposals all provide new, automated
ways of slipping those new addresses in.

So my point is that multiaddressing creates a security challenge not because
delivery is changed but because address selection is changed.  In the past,
address selection really was easy.  Somehow you decided on using one.  Then
you stayed with it.  Now you may not.


mb> So current mono-address ip does perform a verification that the other end of
mb> the communication remains the same in EVERY packet.
mb> This scheme of nonce validation only verifies the id of the other end at the
mb> begining of the communication (or when a new address is included).

With mono-addressing, the target gets a packet with a destination IP address
and validates that it -- the target -- is that IP address.  With multiaddress,
this does not change.

With mono-addressing, the target gets a packet with a source IP addresses.  It
might or might not "validate" it by sending a return packet.  With
multiaddressing, this does not change.

So, the per-packet validation that is created by adding a per-packet nonce
does a validation that is new. It well might be a useful validation, but it
really has nothing to do with multiaddressing.

I claim that the validation that needs to be performed, as a result of using
multiaddressing, is at the time of address _selection_. This is at the
initiator's side, prior to use. The only reasonable way to do that is for the
initiator to have a basis for trusting the pool of available addresses. Hence,
it is the process of building that pool that requires a serious validation
mechanism, not the process of using addresses from the pool.


mb> (To overcome this issue, mip demands a periodical exchange of nonces so that
mb> the identity of the other end of the communication is verified periodically)

Let's ask: What does the periodic exchange detect or fixe? It uses a secure ID
to ensure that the IP addresses being used are legitimately among the pool
associated with the endpoints belonging to their respective identifiers. More
importantly, it validates that things have not _changed_. What could have
changed between uses of the nonce?

Could the routing system have started sending packets with the same IP address
to a different place? If this is the concern, it certainly is legitimate, but
has nothing to do with multiaddressing.

Or is the concern that the IP address now being used for the target is not
valid? This is certainly a problem that already exists with monoaddressing,
but it is significantly exacerbated by multiaddressing, since multiaddressing
introduces an automated mechanism for adding new IP addresses to the pool.
However it is not the _use_ of the address that is the problem.

It is the event of adding a new target address to the initiator's pool of
addresses for the target. Regular use of the nonce in packets might detect a
failure condition. However, strongly protecting the mechanism for adding to
the pool will accomplish the same thing, and it will do it with lower packet
overhead. And it will do it as pre-hoc prevention, rather than post-hoc
detection.


>> However validly, we trust DNS entries and IP routing. As soon as you worry
>> about whether to send an identifier in the clear, you are considering
>> something far broader than problems caused by multiaddressing.
mb> I don't completelly agree. Today you can establish a communication using
mb> only an IP address (you can avoid using the DNS for security reasons) So i
mb> don't think is reasonable to say that all ip addresses are as weak as a
mb> communication that involves a dns query (if we can say this, the security
mb> problems would be greatly reduced). I do agree with the routing part.

My reference to DNS was simply not note that domain names serve as identifiers
and that the mapping to IP addresses is a process that is used with serious
expectations of validity. Yes, the packet service does not require you to use
it. But the application-level Internet really does rely on the validity of the
mapping.


>> PN> In the first case, the only secure way of performing
>> PN> identification seem to be public key cryptography (or any of
>> PN> its variants, like zero knowledge protocol).  The reason for
>> PN> this is the following.  Since the identifier is public
>> PN> knowledge, we cannot use the identifier directly.
>>
>> Today, we use domain names and IP addresses in the clear.  And things work
>> pretty well.
>>
>> To use Marcelo's phrasing, we do not "prove we own" the domain
>> names are IP addresses we use.

mb> You do prove that you own the IP address, the routing system does it.

The routing system validates the association between the target (destination)
IP address as an address and the IP address as an identifier.

It does not validate the initiator (source) address. Any such validation is
performed by a return packet, using the larger context of the endpoint
association.


mb> (BTW I read the address ownership expression fro the first time in Pekka's
mb> draft "An Address Ownership Problem in IPv6"
mb> (<draft-nikander-ipng-address-ownership-00.txt>))

Sounds interesting, but I am not finding that in the I-D depository.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>






From owner-multi6@ops.ietf.org  Mon Sep 29 13:26:51 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29746
	for <multi6-archive@lists.ietf.org>; Mon, 29 Sep 2003 13:26:50 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A41k9-0004QR-Km
	for multi6-data@psg.com; Mon, 29 Sep 2003 17:23:29 +0000
Received: from [131.107.3.125] (helo=mail1.microsoft.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A41ic-0004HP-2p
	for multi6@ops.ietf.org; Mon, 29 Sep 2003 17:21:54 +0000
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 29 Sep 2003 10:21:43 -0700
Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Sep 2003 10:21:53 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 29 Sep 2003 10:21:54 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060);
	 Mon, 29 Sep 2003 10:21:52 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069);
	 Mon, 29 Sep 2003 10:21:52 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Security requirements for identification
Date: Mon, 29 Sep 2003 10:21:37 -0700
Message-ID: <DAC3FCB50E31C54987CD10797DA511BA055A8A61@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Security requirements for identification
thread-index: AcOGpwLDT5GN0KHwSr2wTdgi/Uv/8AABpBPQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Dave Crocker" <dhc@dcrocker.net>, "marcelo bagnulo" <marcelo@it.uc3m.es>
Cc: "Multi6 WG" <multi6@ops.ietf.org>
X-OriginalArrivalTime: 29 Sep 2003 17:21:52.0196 (UTC) FILETIME=[2C49A040:01C386AE]
X-Spam-Status: No, hits=-0.4 required=5.0
	tests=QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

> What is different is that multiaddressing introduces a way of
_changing_
> that
> original IP address into another one. Although the sender still
chooses
> which
> IP address to use, the multiaddressing proposals all provide new,
> automated
> ways of slipping those new addresses in.

Actually, multi-addressing does not in itself introduce a way of
changing addresses. There are lots of applications that will do just
fine with a simple strategy of picking one of the multiple addresses and
using it for the duration of the association. The proper statement is
that multi-addressing, combined with a procedure to dynamically change
the addresses used in an association, can provide additional benefits,
such as using redundancy for surviving network re-homing events.

-- Christian Huitema




From owner-multi6@ops.ietf.org  Mon Sep 29 13:55:21 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00866
	for <multi6-archive@lists.ietf.org>; Mon, 29 Sep 2003 13:55:21 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A42BI-0007jr-Iu
	for multi6-data@psg.com; Mon, 29 Sep 2003 17:51:32 +0000
Received: from [208.184.79.7] (helo=joy.songbird.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A42Am-0007i4-1D
	for multi6@ops.ietf.org; Mon, 29 Sep 2003 17:51:00 +0000
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h8THuOP30547;
	Mon, 29 Sep 2003 10:56:24 -0700
Date: Mon, 29 Sep 2003 10:50:53 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00.18)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <1189360032.20030929105053@brandenburg.com>
To: "Christian Huitema" <huitema@windows.microsoft.com>
CC: "Multi6 WG" <multi6@ops.ietf.org>
Subject: Re: Security requirements for identification
In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA055A8A61@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
References: 
 <DAC3FCB50E31C54987CD10797DA511BA055A8A61@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.5 required=5.0
	tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Christian,

CH>  The proper statement is
CH> that multi-addressing, combined with a procedure to dynamically change
CH> the addresses used in an association, can provide additional benefits,
CH> such as using redundancy for surviving network re-homing events.


Absent a long-standing convention on the definition of "multiaddressing" I am
using the basis in

  <http://brandenburg.com//specifications/draft-crocker-mast-analysis-00.txt>(*)

In fact, one of the major difficulties in discussing this topic is the absence
of consistent and precise terminology, in any of the fora I have been
tracking.

All of the multiaddressing proposals encompass both the use of multiple
addresses and a means of adding to the set of addresses.

Separating the two constructs does seem interesting, from a formal standpoint,
but I'm not sure how it is relevant from the standpoint of engineering any
solutions or the standpoint of any current proposals.

d/

(*)  I submitted the draft to the internet-drafts folks twice over the last
2 weeks but it not seen it announced, yet, though the I-D folks say it is
coming out today.  So the link to my own site is simply as a backup
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>





From owner-multi6@ops.ietf.org  Mon Sep 29 19:10:52 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16851
	for <multi6-archive@lists.ietf.org>; Mon, 29 Sep 2003 19:10:51 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A471I-0006Zv-Uo
	for multi6-data@psg.com; Mon, 29 Sep 2003 23:01:32 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A470X-0006XW-Lj
	for multi6@ops.ietf.org; Mon, 29 Sep 2003 23:00:45 +0000
Received: from bebop.France.Sun.COM ([129.157.174.15])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h8TN0Ukv020337;
	Mon, 29 Sep 2003 17:00:31 -0600 (MDT)
Received: from lillen (d-usca03-225-226.SFBay.Sun.COM [129.145.225.226])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8TN0SQ03551;
	Tue, 30 Sep 2003 01:00:28 +0200 (MEST)
Date: Mon, 29 Sep 2003 23:31:34 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: RE: Security requirements for identification
To: mbagnulo@ing.uc3m.es
Cc: Erik Nordmark <Erik.Nordmark@sun.com>,
        Pekka Nikander <pekka.nikander@nomadiclab.com>,
        Multi6 WG <multi6@ops.ietf.org>, hipsec@honor.trusecure.com
In-Reply-To: "Your message with ID" <LIEEJBCNFDJHFFKJJDPAGECDDBAA.marcelo@it.uc3m.es>
Message-ID: <Roam.SIMC.2.0.6.1064871094.20955.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Spam-Status: No, hits=-0.8 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

> > So I hope the above illustrates that there isn't an inherent requirement
> > from the multi6 problem set to make the identifiers globally
> > unique or stable.
> 
> Actually what you are really doing is to use fqdn as permanent identifiers
> and the DNS as a rendez-vous system, so it provides you with the transient
> identifier and also with the locator.

Yes.

> I mean, if you want to establish a communication with someone you already
> know, you need a mean to express his identity, and that is a permanent
> identifier.

Terminology issue alert. It is presumably sufficient to express a name
(and there can be a many to one mapping from name to identity.)

> (the other option that i could think of are limited lifetime identifiers
> that overlap in time so that you can provide one and obtain the next one,
> which will be valid for the next period)
> However i think that we could focus on the case that atr least for some
> hosts, a permanent identifier is needed, or put it in another way, we can
> provide differents types of identifiers, but one of these types should be a
> permentent one.

Agreed.
But what does permanence mean?
I think we would all agree that having it be stable across changing ISP
connectivity, whether due to multihoming or renumbering, is a useful
characteristic.
Is it also useful to have it be independent of your fqdn so that if you forgot
to pay the registration fees or there is a domain name dispute, you would
still retain your IP level identifier?


> > But I don't think it is until you also look at other problems, like
> > identifiers that can be used by applications for rendez-vous and referral,
> > that the stability issue comes to the forefront.
> 
> But you need initial rendez vous if you want to provide a multi-homing
> solution that works, so it is part of the multi-homing problem

Not so fast. If you want to understand the space of epehemeral identifiers
you need to dive a bit deeper.
In that space the identifier might not be needed before communication
is established, but can actually be exchanged as part of establishing
the communication between two hosts.
A concrete example would using FQDNs to find an (initial, possibly not all 
working) set of locators and then exchanging the identifiers of the
endpoints by the peers communicating.
(There are of course several issues in here, such as needing the know
the identifiers in order to get things like TCP initial state established,
but it is still useful to understand that emphemeral identifier corner of
the design space.)


> > Turning things around, one could ask what the benefits would be of having
> > an identifier which 1) doesn't change when you change ISP and 2) doesn't
> > change due to some administrative mistake (like not renewing your domain
> > name with the registrar).
> >
> 
> Agree, i can see many benefits in those cases, but are those features
> essential to a multi-homing solution? or are they just a nice-to-have
> feature? Would you inlcude them in the MUST list of a loc/id split solution
> for multi-homing?

I think it is part of the tradeoffs in this space.
Having them be independent of your ISP(s) is probably something many want,
so perhaps we must make that.
If it is realatively inexpensive (in terms of complexity, overhead, deployment
constraints, etc) to make it independent of some "registry infrastructure"
that would be a useful thing.

Another tradeoffs with high-level visibility are:
 - whether the ID can be used as the solve information to initiate
communication
   with the entity.
   (one can envision solutions where one can verify that a peer using a
   ID is in fact the same entity that used it a long time ago, without
   being able to use the identifier itself to find the location of the
   entity.)

  Erik




From owner-multi6@ops.ietf.org  Tue Sep 30 05:01:23 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13155
	for <multi6-archive@lists.ietf.org>; Tue, 30 Sep 2003 05:01:23 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A4GKS-000N31-5N
	for multi6-data@psg.com; Tue, 30 Sep 2003 08:57:56 +0000
Received: from [212.68.5.99] (helo=n97.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A4GJw-000N2O-8w
	for multi6@ops.ietf.org; Tue, 30 Sep 2003 08:57:24 +0000
Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id 91CE21C; Tue, 30 Sep 2003 12:10:41 +0300 (EEST)
Message-ID: <3F794577.2030805@nomadiclab.com>
Date: Tue, 30 Sep 2003 11:57:27 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Crocker <dhc@dcrocker.net>
Cc: marcelo bagnulo <marcelo@it.uc3m.es>, Multi6 WG <multi6@ops.ietf.org>
Subject: Re: Security requirements for identification
References: <5921363068.20030926172837@brandenburg.com> <LIEEJBCNFDJHFFKJJDPAEECFDBAA.marcelo@it.uc3m.es> <683463363.20030929091236@brandenburg.com>
In-Reply-To: <683463363.20030929091236@brandenburg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
	      REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,

> I claim that the validation that needs to be performed, as a result 
> of using multiaddressing, is at the time of address _selection_. ...
> The only reasonable way to do that is for the initiator to have a
> basis for trusting the pool of available addresses. Hence, it is the
> process of building that pool that requires a serious validation
> mechanism, not the process of using addresses from the pool.

I pretty much agree with the statement above, with a small caveat,
explained below.

mb> (To overcome this issue, mip demands a periodical exchange of
mb> nonces so that the identity of the other end of the communication
mb> is verified periodically)

> Let's ask: What does the periodic exchange detect or fix? ...
> 
> Or is the concern that the IP address now being used for the target 
> is not valid?

More or less yes.  This is one example of what are called
"time shifting" attacks in the MIPv6 security terminology.

> This is certainly a problem that already exists with monoaddressing,
> but it is significantly exacerbated by multiaddressing, since
> multiaddressing introduces an automated mechanism for adding new IP
> addresses to the pool. However it is not the _use_ of the address
> that is the problem.

Well, it is not the _use_ of the address itself which is the
problem.  It is the expected dynamic nature of IPv6 addresses.
That is, if we expect that all IP addresses become more or less
ephemeral in the IPv6 world, then we must also expect addresses
to be passed over from one node to another.  Even subnet prefixes
will be passed from one organization to another.  This may cause
prolems with multi-addressing.

The problem is fairly subtle, though, and may not be very bad.
It becomes bad only if you can *anticipate* an address someone
else is going to use in the future, arrange yourself at that
address (so that you can pass the test of adding the address to
the pool at your peer), leave, and wait for your victim to
arrive.  Then, at that point, you can flood your victim by
claiming that you are no more available at your other addresses,
thereby forcing the peer to use the (now) victim's address.
You claim will be trusted since the address is already in the
pool.

> It is the event of adding a new target address to the initiator's 
> pool of addresses for the target. Regular use of the nonce in packets
> might detect a failure condition. However, strongly protecting the 
> mechanism for adding to the pool will accomplish the same thing, and 
> it will do it with lower packet overhead. And it will do it as 
> pre-hoc prevention, rather than post-hoc detection.

In my opinion, strongly protecting the adding mechanism is really
the most important point.  It may be also useful to include a
check whenever you start to use a locator after a long period of
inactivity, even if the locator is already in the pool.

Arranging an attack where you use a given address and stop using
it just before your victim arrives and starts to use it seems
to be very hard, and probably not worth worrying about.

> mb> (BTW I read the address ownership expression fro the first time 
> in Pekka's mb> draft "An Address Ownership Problem in IPv6" mb> 
> (<draft-nikander-ipng-address-ownership-00.txt>))
> 
> Sounds interesting, but I am not finding that in the I-D depository.

It was two or three years back, long expired.  A backup copy can
be found on my web site,

http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-address-ownership-00.txt

--Pekka Nikander





From owner-multi6@ops.ietf.org  Tue Sep 30 05:22:41 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13801
	for <multi6-archive@lists.ietf.org>; Tue, 30 Sep 2003 05:22:41 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A4GgG-000OkT-Oo
	for multi6-data@psg.com; Tue, 30 Sep 2003 09:20:28 +0000
Received: from [212.68.5.99] (helo=n97.nomadiclab.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A4Gf4-000Og9-RA
	for multi6@ops.ietf.org; Tue, 30 Sep 2003 09:19:15 +0000
Received: from nomadiclab.com (teldanex.local.nikander.com [192.168.0.194])
	by n97.nomadiclab.com (Postfix) with ESMTP
	id 8C8401C; Tue, 30 Sep 2003 12:32:32 +0300 (EEST)
Message-ID: <3F794A96.70205@nomadiclab.com>
Date: Tue, 30 Sep 2003 12:19:18 +0300
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: Multi6 WG <multi6@ops.ietf.org>
Subject: Re: Security requirements for identification
References: <3F714C8E.4070205@nomadiclab.com> <5921363068.20030926172837@brandenburg.com>
In-Reply-To: <5921363068.20030926172837@brandenburg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-0.8 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,

PN> Hence, for the purpose of mobility and multi-homing, the
PN> identification mechanism has to keep sure that the peer really
PN> remains the same, on all changes of locators.  Furthermore, the
PN> mechanism must not blindly trust what the peer claims about its
PN> locations, but must check that the same peer really *is*
PN> at all the claimed addresses.

> Hmmm. Carried to the extreme the requirement seems to specify would
> probably require having every packet be encrypted -- so it could only
> be decoded by the correct recipient -- and acknowledged with a
> signature.

Yes.  But going such extreme is probably silly.  See my previous
message on the same topic.

PN> b) identification for referral or rendezvous

PN> In the case of referral or rendezvous, an initiating party
PN> possesses an identifier that it wants to use as a means
PN> of identifying another party.
> 
> In spite of the above language, you do not define rendezvous and
> referral. 

I tried in my previous message to ipv6 list, but apparently failed.
Especially, my definition for referral there and yours below
do not match:

> I have been assuming the latter means "moving an
> association from one endpoint to another". That is, "hand off" of one
> end of an association to a new endpoint.

We clearly need two different words for two different actions:

   1. Handing over an "identifier" from one end-point to another,
      with the intention of the receiving end-point being able to
      contact the "identified" end-point in the future.

   2. Handing over an end of an (active) association from one
      end-point to another.

I was using the term "referral" in the first sense, while you
seem to be using in the second sense.

> So, please clarify what you mean by both terms and how they relate to
> the distinction between identifying versus locating.

Maybe you want to reread my message to IPv6:
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00056.html

I tried to give definitions there, but seem to have failed.

PN> If we assume dishonest parties, we get two sub cases.  In
PN> the first case, the initiating party must send the identifier
PN> in clear, for some reason, or the identifier is otherwise
PN> public and known by the dishonest parties.  In the second
PN> case, the initiating party is able to keep the identifier in
PN> secret.

> This line of thinking appears to go quite a bit beyond the current
> world of IP mon-addressing.  And I believe it involves concerns not
> created by multiaddressing.

Well, certainly I go well beyound the current architecture.
I am trying to figure out what we need to do if we really separate
identifiers and locators, and cannot rely on the routing infrastructure
to provide any kind of security for the identifiers.  In other
words, the current practise where IP address are also identifiers
is good from a security point of view.  It just doesn't work well
with multi-addressing.

I tried to outline four possibilities:

   - create another kind of an infrastructure to "secure" identifiers
   - use "self-securing" identifiers, i.e., public keys
   - use a PKI
   - go only half way, somehow still relying on the routing
     infrastructure

(Note that I am putting "secure" and "self-secure" in quotes since
I am using them here in a purposefully vague way.  We still don't know
what the real security goals are, other than this "no worse than
mono-addressing IPv4" statement.)

It may well be that I go beyound multi-addressing.  In fact, I don't
so much care just about multi-addressing, but really understanding
the consequences of the id/loc split.

--Pekka Nikander




From owner-multi6@ops.ietf.org  Tue Sep 30 07:12:49 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16432
	for <multi6-archive@lists.ietf.org>; Tue, 30 Sep 2003 07:12:49 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A4INW-0006By-LF
	for multi6-data@psg.com; Tue, 30 Sep 2003 11:09:14 +0000
Received: from [163.117.136.122] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A4IN1-00069V-Ar
	for multi6@ops.ietf.org; Tue, 30 Sep 2003 11:08:43 +0000
Received: from smtp02.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id C9EA4433E0; Tue, 30 Sep 2003 13:08:19 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.245])
	by smtp02.uc3m.es (Postfix) with SMTP
	id A58F299FCA; Tue, 30 Sep 2003 13:08:19 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Pekka Nikander" <pekka.nikander@nomadiclab.com>,
        "Dave Crocker" <dhc@dcrocker.net>
Cc: "Multi6 WG" <multi6@ops.ietf.org>
Subject: RE: Security requirements for identification
Date: Tue, 30 Sep 2003 13:03:31 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAIEDNDBAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3F794577.2030805@nomadiclab.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=0.0 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pekka,
>
> The problem is fairly subtle, though, and may not be very bad.
> It becomes bad only if you can *anticipate* an address someone
> else is going to use in the future, arrange yourself at that
> address (so that you can pass the test of adding the address to
> the pool at your peer), leave, and wait for your victim to
> arrive.  Then, at that point, you can flood your victim by
> claiming that you are no more available at your other addresses,
> thereby forcing the peer to use the (now) victim's address.
> You claim will be trusted since the address is already in the
> pool.
>
> > It is the event of adding a new target address to the initiator's
> > pool of addresses for the target. Regular use of the nonce in packets
> > might detect a failure condition. However, strongly protecting the
> > mechanism for adding to the pool will accomplish the same thing, and
> > it will do it with lower packet overhead. And it will do it as
> > pre-hoc prevention, rather than post-hoc detection.
>
> In my opinion, strongly protecting the adding mechanism is really
> the most important point.  It may be also useful to include a
> check whenever you start to use a locator after a long period of
> inactivity, even if the locator is already in the pool.
>
> Arranging an attack where you use a given address and stop using
> it just before your victim arrives and starts to use it seems
> to be very hard, and probably not worth worrying about.

Well, then why don't we just extend mip BCE maximum lifetime then?
If i understand correctly, this is exaclty the type of attack that the
maximum BCE lifetime bound prevents.

I mean, if we do extend the maximum BCE lifetime, we can have a very
important part of a multi-homing available easily which is the support of
multi-homing in nodes outside the multi-homed site.


Regards, marcelo




From owner-multi6@ops.ietf.org  Tue Sep 30 07:13:19 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16456
	for <multi6-archive@lists.ietf.org>; Tue, 30 Sep 2003 07:13:19 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A4IMc-00068A-Ls
	for multi6-data@psg.com; Tue, 30 Sep 2003 11:08:18 +0000
Received: from [163.117.136.122] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A4IM3-00066r-Ny
	for multi6@ops.ietf.org; Tue, 30 Sep 2003 11:07:43 +0000
Received: from smtp02.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id 8C413433F2; Tue, 30 Sep 2003 12:58:17 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.245])
	by smtp02.uc3m.es (Postfix) with SMTP
	id 7729299FAB; Tue, 30 Sep 2003 12:58:17 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Dave Crocker" <dhc@dcrocker.net>
Cc: "Multi6 WG" <multi6@ops.ietf.org>
Subject: RE: Security requirements for identification
Date: Tue, 30 Sep 2003 12:53:29 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAEEDNDBAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <683463363.20030929091236@brandenburg.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=0.0 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,

> mb> Not really. Current mono-addressing IP security relies on
> routing (id=loc so
> mb> if you trust the routing system then it will deliver the packet to the
> mb> correct IP==ID)
>
> The question is how the IP address is obtained. _Using_ an IP address when
> there is multiaddressing also relies on the routing system to deliver the
> packet to the correct IP address.
>
> What is different is that multiaddressing introduces a way of
> _changing_ that
> original IP address into another one. Although the sender still
> chooses which
> IP address to use, the multiaddressing proposals all provide new,
> automated
> ways of slipping those new addresses in.
>
> So my point is that multiaddressing creates a security challenge
> not because
> delivery is changed but because address selection is changed.  In
> the past,
> address selection really was easy.  Somehow you decided on using
> one.  Then
> you stayed with it.  Now you may not.

Well, i think the problem is that the application (perhaps not even the
transport layer) is not aware of the change.
I mean, suppose you establish a tcp connection with a host far away using
its IP address IPA. In the mono-addressing scheme, you know that this
address will remain the same.
In the multi-address, the  layer below tranpsort may change the address
being used to IPB but this is not visible to the transport layer and above,
i mean, the transport and above still think that the connection is
established with IPA. (this is the case where you use an IP address as
identifier, such as mip)
So now the ip address used in the communication has changed and the only way
to prove the address ownership has been lost, but for the other end of the
communication the IP address involved in the communication is still the same
(IPA)


>
>
> mb> So current mono-address ip does perform a verification that
> the other end of
> mb> the communication remains the same in EVERY packet.
> mb> This scheme of nonce validation only verifies the id of the
> other end at the
> mb> begining of the communication (or when a new address is included).
>
> With mono-addressing, the target gets a packet with a destination
> IP address
> and validates that it -- the target -- is that IP address.  With
> multiaddress,
> this does not change.
>

I guess the key point is who performs the validation...
In multi-addressimg the validation is performed by the new shim-wedge layer
that handles the multiple addresses, but the application is not aware of the
change.

Let's consider an example.
Suppose that i want to establish a communication with a server A. In order
to do that i have to know its address, IPA. HEre is where the validation is
done for this address IPA. I mean i have to know IPA somehow (this is not
part of the things that IP layer does for you). Once that i Know IPA and i
have validated it, i can establish the communication. Now, ip gives me some
guarantees that packets will be delivered to the server A as long as the
destiantion address included in packets is IPA.

If multi-addressing is enabled, and i try to do the same. Then i have to
discover one IP address of the server A, (IPA) and validate it in the same
way than before (i.e. IP layer doesn't do this for me). Now i establish a
communication with server A sending packets to IPA. Now, if multi-addressing
is enabled, alternative IP addresses can be exchanged by the shim layer and
they will be used to reach server A. This means that while my tcp connection
is still established with IPA (that i have validated with some mechanism),
packets can be actually addressed to other addresses that have been
validated by the shim layer (and the worst and also the best part is that
not even tcp is aware of the situation)


The other option is to let the application to be aware of all the addresses.
In this case, the validation of all addresses can be performed in the same
way (not done by the ip layer, done in some other way)
The problem here is that you have to modify all the apps to let them handle
multiple addresses.

> With mono-addressing, the target gets a packet with a source IP
> addresses.  It
> might or might not "validate" it by sending a return packet.  With
> multiaddressing, this does not change.
>
> So, the per-packet validation that is created by adding a per-packet nonce
> does a validation that is new. It well might be a useful
> validation, but it
> really has nothing to do with multiaddressing.
>
> I claim that the validation that needs to be performed, as a
> result of using
> multiaddressing, is at the time of address _selection_. This is at the
> initiator's side, prior to use. The only reasonable way to do
> that is for the
> initiator to have a basis for trusting the pool of available
> addresses. Hence,
> it is the process of building that pool that requires a serious validation
> mechanism, not the process of using addresses from the pool.
>

I think i covered this above but let me synthetize.
With mono addressing all you need to know that a given server A has a given
IP address IPA
With multi-addressing you have two options AFAICS:
First, you idscover all the addresses available in the other end in the same
way that you discover IPA in the mono address sheme, for server A, you
discover somehow that it has IPA1, IPA2,...
This option is not really good enough because you have to know all the
possible addresses to be used a priori (which would be acceptable for
multi-homing but it is not good enough for mobility) and because it implies
that all apps have to be modified to support this. So the goal is to leave
the apps as they are and handle the multiple address issue transparently.

The second option is that you discover one address as in the mono-address
situation IPA, and then the shim layer discover address that are equivalent
to the initial IPA. This validation is different than th initial one and has
to be performed in a transparent manner.

>
> mb> (To overcome this issue, mip demands a periodical exchange of
> nonces so that
> mb> the identity of the other end of the communication is
> verified periodically)
>
> Let's ask: What does the periodic exchange detect or fixe? It
> uses a secure ID
> to ensure that the IP addresses being used are legitimately among the pool
> associated with the endpoints belonging to their respective
> identifiers. More
> importantly, it validates that things have not _changed_. What could have
> changed between uses of the nonce?
>
> Could the routing system have started sending packets with the
> same IP address
> to a different place? If this is the concern, it certainly is
> legitimate, but
> has nothing to do with multiaddressing.
>
> Or is the concern that the IP address now being used for the target is not
> valid? This is certainly a problem that already exists with
> monoaddressing,
> but it is significantly exacerbated by multiaddressing, since
> multiaddressing
> introduces an automated mechanism for adding new IP addresses to the pool.
> However it is not the _use_ of the address that is the problem.
>
> It is the event of adding a new target address to the initiator's pool of
> addresses for the target. Regular use of the nonce in packets
> might detect a
> failure condition. However, strongly protecting the mechanism for
> adding to
> the pool will accomplish the same thing, and it will do it with
> lower packet
> overhead. And it will do it as pre-hoc prevention, rather than post-hoc
> detection.

Pekka's has already answered this, i guess.


>
>
> >> However validly, we trust DNS entries and IP routing. As soon
> as you worry
> >> about whether to send an identifier in the clear, you are considering
> >> something far broader than problems caused by multiaddressing.
> mb> I don't completelly agree. Today you can establish a
> communication using
> mb> only an IP address (you can avoid using the DNS for security
> reasons) So i
> mb> don't think is reasonable to say that all ip addresses are as
> weak as a
> mb> communication that involves a dns query (if we can say this,
> the security
> mb> problems would be greatly reduced). I do agree with the routing part.
>
> My reference to DNS was simply not note that domain names serve
> as identifiers
> and that the mapping to IP addresses is a process that is used
> with serious
> expectations of validity. Yes, the packet service does not
> require you to use
> it. But the application-level Internet really does rely on the
> validity of the
> mapping.
>

I agree with you.
My point is that current architecture provides the ability to establish
communication that are more secure than those that use the DNS (i.e. using
IP addresses direclty)
If we introduce a id to locators mapping like the DNS and its usage becomes
mandatory to establish a communication,, the result is that communications
are less secure, since you don't have the cappability of avoiding the
threats introduced by the DNS-like mapping system.

>
> >> PN> In the first case, the only secure way of performing
> >> PN> identification seem to be public key cryptography (or any of
> >> PN> its variants, like zero knowledge protocol).  The reason for
> >> PN> this is the following.  Since the identifier is public
> >> PN> knowledge, we cannot use the identifier directly.
> >>
> >> Today, we use domain names and IP addresses in the clear.  And
> things work
> >> pretty well.
> >>
> >> To use Marcelo's phrasing, we do not "prove we own" the domain
> >> names are IP addresses we use.
>
> mb> You do prove that you own the IP address, the routing system does it.
>
> The routing system validates the association between the target
> (destination)
> IP address as an address and the IP address as an identifier.
>
> It does not validate the initiator (source) address. Any such
> validation is
> performed by a return packet, using the larger context of the endpoint
> association.
>

Agree.

Regards, marcelo

>
> mb> (BTW I read the address ownership expression fro the first
> time in Pekka's
> mb> draft "An Address Ownership Problem in IPv6"
> mb> (<draft-nikander-ipng-address-ownership-00.txt>))
>
> Sounds interesting, but I am not finding that in the I-D depository.
>
>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>
>
>
>




From owner-multi6@ops.ietf.org  Tue Sep 30 10:43:52 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24524
	for <multi6-archive@lists.ietf.org>; Tue, 30 Sep 2003 10:43:52 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A4LfJ-000I2b-3D
	for multi6-data@psg.com; Tue, 30 Sep 2003 14:39:49 +0000
Received: from [163.117.136.122] (helo=smtp.uc3m.es)
	by psg.com with esmtp (Exim 4.22)
	id 1A4Len-000I0J-1D
	for multi6@ops.ietf.org; Tue, 30 Sep 2003 14:39:17 +0000
Received: from smtp02.uc3m.es (localhost [127.0.0.1])
	by smtp.uc3m.es (Postfix) with ESMTP
	id 443D843169; Tue, 30 Sep 2003 16:39:16 +0200 (CEST)
Received: from lolo (lolo.it.uc3m.es [163.117.139.245])
	by smtp02.uc3m.es (Postfix) with SMTP
	id 7BBC999FCB; Tue, 30 Sep 2003 16:39:15 +0200 (CEST)
Reply-To: <mbagnulo@ing.uc3m.es>
From: "marcelo bagnulo" <marcelo@it.uc3m.es>
To: "Erik Nordmark" <Erik.Nordmark@sun.com>, <mbagnulo@ing.uc3m.es>
Cc: "Pekka Nikander" <pekka.nikander@nomadiclab.com>,
        "Multi6 WG" <multi6@ops.ietf.org>, <hipsec@honor.trusecure.com>
Subject: RE: Security requirements for identification
Date: Tue, 30 Sep 2003 16:34:26 +0200
Message-ID: <LIEEJBCNFDJHFFKJJDPAAEEBDBAA.marcelo@it.uc3m.es>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.1064871094.20955.nordmark@bebop.france>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Spam-Status: No, hits=0.0 required=5.0
	tests=IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Erik,

>
> > > So I hope the above illustrates that there isn't an inherent
> requirement
> > > from the multi6 problem set to make the identifiers globally
> > > unique or stable.
> >
> > Actually what you are really doing is to use fqdn as permanent
> identifiers
> > and the DNS as a rendez-vous system, so it provides you with
> the transient
> > identifier and also with the locator.
>
> Yes.
>
> > I mean, if you want to establish a communication with someone
> you already
> > know, you need a mean to express his identity, and that is a permanent
> > identifier.
>
> Terminology issue alert. It is presumably sufficient to express a name
> (and there can be a many to one mapping from name to identity.)

Good point.
I guess that we can try to be a bit more precise about this:

As you mention, there are multiple times that i don't really need to know
the identifier of the end-point that i want to communicate to, but what i
want is the identifier of the service that i want to contact (is this what
you meant?)

So in this case, the fqdn act as a service identifier. So if i have a
permanent service identifier (i.e. a fqdn), it is enough to have ephemeral
end-points identifier, since when i want to establish a communication with a
given service i just look for the currently valid ephermeral endpoint
identifier.

The next question then is whether this is enough... I mean can we just live
with ephemeral endpoint identifiers and stable service identifiers?

>
> > (the other option that i could think of are limited lifetime identifiers
> > that overlap in time so that you can provide one and obtain the
> next one,
> > which will be valid for the next period)
> > However i think that we could focus on the case that atr least for some
> > hosts, a permanent identifier is needed, or put it in another
> way, we can
> > provide differents types of identifiers, but one of these types
> should be a
> > permentent one.
>
> Agreed.
> But what does permanence mean?
> I think we would all agree that having it be stable across changing ISP
> connectivity, whether due to multihoming or renumbering, is a useful
> characteristic.
> Is it also useful to have it be independent of your fqdn so that
> if you forgot
> to pay the registration fees or there is a domain name dispute, you would
> still retain your IP level identifier?
>

>
> > > But I don't think it is until you also look at other problems, like
> > > identifiers that can be used by applications for rendez-vous
> and referral,
> > > that the stability issue comes to the forefront.
> >
> > But you need initial rendez vous if you want to provide a multi-homing
> > solution that works, so it is part of the multi-homing problem
>
> Not so fast. If you want to understand the space of epehemeral identifiers
> you need to dive a bit deeper.
> In that space the identifier might not be needed before communication
> is established, but can actually be exchanged as part of establishing
> the communication between two hosts.
> A concrete example would using FQDNs to find an (initial,
> possibly not all
> working) set of locators and then exchanging the identifiers of the
> endpoints by the peers communicating.

Not so sure, i mean, you are using the fqdn to make the initial contact, so
the fqdn is an permanent identifier. You can consider that the fqdn is a
service identifier. Ok, then when contact the other end through the locators
that you have obtained through the DNS, you will exchange a ephemeral
identifier, but this ephemeral identifier is a *service* ephemeral
identifier, isn't it? i mean you know that a service is at given location
and then you exchange an identifier to be sure that you always talk to the
same entity, this would be a service identifier, i guess.

So the point is, you can use a fqdn as a service or endpoint stable
identifier and then exchange service or endpoint ephemeral identifiers, but
you always need the stable identifier to make initial contact, so you can
express who do you want to talk to.

> (There are of course several issues in here, such as needing the know
> the identifiers in order to get things like TCP initial state established,
> but it is still useful to understand that emphemeral identifier corner of
> the design space.)
>
>
> > > Turning things around, one could ask what the benefits would
> be of having
> > > an identifier which 1) doesn't change when you change ISP and
> 2) doesn't
> > > change due to some administrative mistake (like not renewing
> your domain
> > > name with the registrar).
> > >
> >
> > Agree, i can see many benefits in those cases, but are those features
> > essential to a multi-homing solution? or are they just a nice-to-have
> > feature? Would you inlcude them in the MUST list of a loc/id
> split solution
> > for multi-homing?
>
> I think it is part of the tradeoffs in this space.
> Having them be independent of your ISP(s) is probably something many want,
> so perhaps we must make that.
> If it is realatively inexpensive (in terms of complexity,
> overhead, deployment
> constraints, etc) to make it independent of some "registry infrastructure"
> that would be a useful thing.
>
> Another tradeoffs with high-level visibility are:
>  - whether the ID can be used as the solve information to initiate
> communication
>    with the entity.
>    (one can envision solutions where one can verify that a peer using a
>    ID is in fact the same entity that used it a long time ago, without
>    being able to use the identifier itself to find the location of the
>    entity.)

Been re-reading JNC's Endpoints and Endpoint's Names where there is a great
compilation of many relevant characteristics of the endpoint identifer,
where most of these are included somehow, and the point is that there are
many aspects to consider.

So my question is whether we should focus on providing a multi-homing
solution based on the loc/id split or we should design a loc/id split that
covers as many as possible of the apsects related with the overloaded model
of identifiers in current IP, such as the ones that you mention or the ones
covered in JNC's paper.
Clearly the second option seems the wise thing to do, but there are many
operational issues here, such the time requiered for this (during this time
we will not provide a multi-homing solution which seems to be a pressing
issue right now), the appropriate forum for this (not only because of the
formal issues related to this, but more because of the people that should be
involved and whose opinions are relevant for this, may not be here).
So perhaps the practical thing to do is to provide a multi-homing solution
now, focusing only on multi-homing problems.

Regards, marcelo

>
>   Erik
>




From owner-multi6@ops.ietf.org  Tue Sep 30 15:52:28 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12378
	for <multi6-archive@lists.ietf.org>; Tue, 30 Sep 2003 15:52:28 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A4QTm-000Doe-OX
	for multi6-data@psg.com; Tue, 30 Sep 2003 19:48:14 +0000
Received: from [195.43.225.70] (helo=kurtis-lindqvists-computer.local)
	by psg.com with esmtp (Exim 4.22)
	id 1A4QTG-000DkX-Nq
	for multi6@ops.ietf.org; Tue, 30 Sep 2003 19:47:43 +0000
Received: from kurtis.pp.se (localhost [127.0.0.1])
	by kurtis-lindqvists-computer.local (8.12.9/8.10.2) with ESMTP id h8UJlLdV002073;
	Tue, 30 Sep 2003 21:47:22 +0200 (CEST)
Date: Tue, 30 Sep 2003 21:47:16 +0200
Subject: Re: Security requirements for identification
Content-Type: text/plain; charset=US-ASCII; format=fixed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: "Pekka Nikander" <pekka.nikander@nomadiclab.com>,
        "Randy Bush" <randy@psg.com>,
        "Christian Huitema" <huitema@windows.microsoft.com>,
        "Multi6 WG" <multi6@ops.ietf.org>, <hipsec@honor.trusecure.com>
To: "Tony Li" <Tony.Li@procket.com>
From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
In-Reply-To: <D2EC481073504E498A8DB9C0687E8CAF067D327D@EXCHANGE0-0.na.procket.com>
Message-Id: <E52A8166-F37E-11D7-B967-0003936663F8@kurtis.pp.se>
Content-Transfer-Encoding: 7bit
X-Pgp-Rfc2646-Fix: 1
X-Mailer: Apple Mail (2.552)
X-Spam-Status: No, hits=-3.1 required=5.0
	tests=BAYES_30,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT,
	      RCVD_IN_OSIRUSOFT_COM,USER_AGENT_APPLEMAIL
	autolearn=ham version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Hmmm....  I suppose that I should respond.  ;-)

Thanks! :-)

> Yes, I think that that some kind of consensus on the properties
> of identifiers is a necessity.  There is a long discussion
> to get there.  Could we get rough consensus on it?  Yes, I think
> so, but it might be very rough.

I think we need a point to start at anyway.

>  And it might take a very long
> time.  Certainly the discussions within our design team have taken
> awhile and that's with a much smaller number of people.  It may
> well be faster to start the discussion with the output of one of
> the design teams, so that the discussion can revolve around an
> entire design, rather than effectively throwing open design discussions
> to the entire WG.  I'm flexible in this regard.

I am just trying to get a feeling of what people think. I do agree that 
working on the output of the DTs might be the fastest way, on the other 
hand, whatever we could do in parallel is just an added value.

> However, as a Loyal Opponent of Bureaucracy, I have to question
> whether this needs to be a document.  And whether this needs to
> be an official WG document, given that it will not become end
> product.

It could become a product, question is if that would help us. I will be 
the first to agree to cut down the amount of drafts published, so if we 
can do without, the better. I just have a feeling that we lack actual 
text to discuss around. We are just adding more ideas, but not 
producing real consensus one way or the other.

> In the Good Olde Days, the WG chair was a neutral discussion
> leader and tried to establish consensus by ensuring that
> differing points of view were represented in the work output
> and that the group came to rough consensus on very small points
> in a gradual manner.  This is not the only way that these things
> can happen, but a reminder of what once was.  I leave it to the
> WG to choose the best path.

I agree with the above. I have at least _tried_  to be neutral, maybe 
even to neutral to get the discussion going in a direction. But from 
above, I think this would also be easier on my part if we actually had 
real text to discuss around.

But I have no strong feeling one way or the other on the original 
question.

Best regards,

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBP3ndx6arNKXTPFCVEQJu8QCgrbj5uTfbhbO/6fkMQ+MuKiPg+QEAoPa0
zCV52StE3RrhRBiHeVmpOAOR
=XeGK
-----END PGP SIGNATURE-----




From owner-multi6@ops.ietf.org  Tue Sep 30 16:14:14 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14107
	for <multi6-archive@lists.ietf.org>; Tue, 30 Sep 2003 16:14:14 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A4QrH-000Fzn-AM
	for multi6-data@psg.com; Tue, 30 Sep 2003 20:12:31 +0000
Received: from [65.174.124.37] (helo=dmz2.procket.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A4QqO-000FwW-5f; Tue, 30 Sep 2003 20:11:36 +0000
Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60])
	by dmz2.procket.com (8.12.8p1/8.12.1) with ESMTP id h8UMFSjg066823;
	Tue, 30 Sep 2003 15:15:28 -0700 (PDT)
Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8])
	by miata.procket.com (8.12.1/8.12.1) with ESMTP id h8UK3lYB010871;
	Tue, 30 Sep 2003 13:03:47 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Security requirements for identification
Date: Tue, 30 Sep 2003 13:03:46 -0700
Message-ID: <D2EC481073504E498A8DB9C0687E8CAF067D3282@EXCHANGE0-0.na.procket.com>
Thread-Topic: Security requirements for identification
Thread-Index: AcOHi74M2ndfBxxaTwadz8/J4iA7JgAARo8A
From: "Tony Li" <Tony.Li@procket.com>
To: "Kurt Erik Lindqvist" <kurtis@kurtis.pp.se>
Cc: "Pekka Nikander" <pekka.nikander@nomadiclab.com>,
        "Randy Bush" <randy@psg.com>,
        "Christian Huitema" <huitema@windows.microsoft.com>,
        "Multi6 WG" <multi6@ops.ietf.org>, <hipsec@honor.trusecure.com>
X-Spam-Status: No, hits=0.0 required=5.0
	tests=none
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable



Ok, let me see if I can give a taxonomy of possible
identifier properties:

1. Syntax
   Fixed length
	Partitioned
	    Fixed size partitions
	    Variable sized partitions
      Atomic
   Variable length

2. Global Semantics
	None
	Globally unique
		Database key
		No further semantics

3. Local Semantics
	None
	Locally unique
		No further semantics
		Expresses local geography
		Expresses local topology
		Expresses other local properties

3. Generation
   Random bit string
   Cryptographic hash
   Hierarchical assignment

Tony



From owner-multi6@ops.ietf.org  Tue Sep 30 18:52:23 2003
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19875
	for <multi6-archive@lists.ietf.org>; Tue, 30 Sep 2003 18:52:20 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 4.22)
	id 1A4THt-0001y9-Mv
	for multi6-data@psg.com; Tue, 30 Sep 2003 22:48:09 +0000
Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com)
	by psg.com with esmtp (Exim 4.22)
	id 1A4THO-0001vO-24
	for multi6@ops.ietf.org; Tue, 30 Sep 2003 22:47:38 +0000
Received: from bebop.France.Sun.COM ([129.157.174.15])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h8UMlQkv020415;
	Tue, 30 Sep 2003 16:47:27 -0600 (MDT)
Received: from lillen (d-mpk17-89-241.Eng.Sun.COM [129.146.89.241])
	by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h8UMlOQ10020;
	Wed, 1 Oct 2003 00:47:24 +0200 (MEST)
Date: Wed, 1 Oct 2003 00:31:38 +0200 (CEST)
From: Erik Nordmark <Erik.Nordmark@sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@sun.com>
Subject: RE: Security requirements for identification
To: mbagnulo@ing.uc3m.es
Cc: Erik Nordmark <Erik.Nordmark@sun.com>,
        Pekka Nikander <pekka.nikander@nomadiclab.com>,
        Multi6 WG <multi6@ops.ietf.org>, hipsec@honor.trusecure.com
In-Reply-To: "Your message with ID" <LIEEJBCNFDJHFFKJJDPAAEEBDBAA.marcelo@it.uc3m.es>
Message-ID: <Roam.SIMC.2.0.6.1064961098.11407.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT
	version=2.55
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
Sender: owner-multi6@ops.ietf.org
Precedence: bulk

> As you mention, there are multiple times that i don't really need to know
> the identifier of the end-point that i want to communicate to, but what i
> want is the identifier of the service that i want to contact (is this what
> you meant?)

Yep.

> So in this case, the fqdn act as a service identifier. So if i have a
> permanent service identifier (i.e. a fqdn), it is enough to have ephemeral
> end-points identifier, since when i want to establish a communication with a
> given service i just look for the currently valid ephermeral endpoint
> identifier.
> 
> The next question then is whether this is enough... I mean can we just live
> with ephemeral endpoint identifiers and stable service identifiers?

From the perspective of handling at least a narrow interpretation of
multi6 I think this is enough.
But it doesn't make the identifiers first class objects in the architecture;
it would be impossible to use them as the sole handle for referrals and 
perhaps also for rendez-vous (in Keith's definition of that term; "call me back
when you are done")

I think this means that we can use it to make transport protocols
and simple applications protocols unaware of multihoming, but richer
application protocols would need something else. Whether that means passing
around a list of locators to represent a peer, or do use a fqdn to designate
a peer (which requires work to avoid confusing with fqdns which designate
a service), or something else I don't know.

> Not so sure, i mean, you are using the fqdn to make the initial contact, so
> the fqdn is an permanent identifier. You can consider that the fqdn is a
> service identifier. Ok, then when contact the other end through the locators
> that you have obtained through the DNS, you will exchange a ephemeral
> identifier, but this ephemeral identifier is a *service* ephemeral
> identifier, isn't it? i mean you know that a service is at given location
> and then you exchange an identifier to be sure that you always talk to the
> same entity, this would be a service identifier, i guess.

The FQDN could be viewed as an identifier for the service i.e.
consistent with current usage of fqdns.
You'd exchange the ephemeral identifier with a peer node thus you'd
presumably get an ID for that node (a stack name), and not an ID
for the service.
You would need to find out which of the locators refer to that identity
so that you don't try to redirect the traffic to go to a different node.
Perhaps that could also be exchanged as part of the handshake that exchanges
the emphemeral ids.

> So my question is whether we should focus on providing a multi-homing
> solution based on the loc/id split or we should design a loc/id split that
> covers as many as possible of the apsects related with the overloaded model
> of identifiers in current IP, such as the ones that you mention or the ones
> covered in JNC's paper.

If it was "free" I think the more general problem would be the right one.
But designing and deploying a system capable of looking up identifiers
(with desirable properties; they would be flat or near-flat ids I think)
is clearly something which will take time.
In practice I think we need to figure out something which can be
incrementally deployed providing incremental multihoming benefits along the
way. If we can do this and maintain the ability add the lookup system
along the way it the lookup system wouldn't be a gating factor for deployment
of a solution to the multi6 connection rehoming problem.

   Erik