From owner-multi6@ops.ietf.org Sat Nov 1 06:30:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04325 for ; Sat, 1 Nov 2003 06:30:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFtuF-000GKI-Kk for multi6-data@psg.com; Sat, 01 Nov 2003 11:26:59 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFtuD-000GK5-5I for multi6@ops.ietf.org; Sat, 01 Nov 2003 11:26:57 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA1BQjed062918; Sat, 1 Nov 2003 12:26:45 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4BA38C09-0C5E-11D8-A100-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Crypto-based host identifiers Date: Sat, 1 Nov 2003 12:26:54 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 31 okt 2003, at 13:49, Erik Nordmark wrote: > Another mechanism to limit the exposure by short hashes is > that the first time a host performs the PK challenge with the peer > it records the actual public key. Yes, this is a very good way to handle this. This is what SSH does. But why stop there if you can simply download *all* site keys and store them locally beforehand if you're sufficiently paranoid? From owner-multi6@ops.ietf.org Sat Nov 1 07:11: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 HAA04897 for ; Sat, 1 Nov 2003 07:11:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFuah-000ILq-Ji for multi6-data@psg.com; Sat, 01 Nov 2003 12:10:51 +0000 Received: from [213.221.138.98] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFuac-000IL7-Eg for multi6@ops.ietf.org; Sat, 01 Nov 2003 12:10:46 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hA1CAR50000648; Sat, 1 Nov 2003 13:10:28 +0100 (CET) Date: Fri, 31 Oct 2003 17:14:08 +0100 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: Tentative agenda for Multi6 in Minneapolis From: Kurt Erik Lindqvist To: multi6@ops.ietf.org, agenda@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <415E4703-0BBD-11D8-9AE2-000A9598A184@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (I hope I have not missed any requests) TUESDAY, November 11, 2003 1545-1645 Afternoon Sessions III ******************************** * Bashing and administrivia (5 minutes) * Marcelo Bagnulo / David Kessens (5 minutes) - DT2 Update * Dave Crocker (15 minutes) - draft-crocker-mast-analysis-01.txt - draft-crocker-mast-proposal-01.txt * Arifumi Matsumoto (10 minutes) * Masataka Ohta (15 minutes) - draft-ohta-multihomed-isps-00.txt * Kenji Ohira (10 minutes) - draft-ohira-assign-select-e2e-multihome-02.txt - some research results about implementation of SABR 1700-1800 Afternoon Sessions IV * Discussions / Open mike WEDNESDAY, November 12, 2003 0900-1130 Morning Sessions ******************************* * Erik Nordmark (15 minutes) - draft-nordmark-multi6-noid-01.txt - draft-nordmark-multi6-sim-01.txt - draft-nordmark-multi6-threats-00.txt * Discussions / Open mike -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6KKUqarNKXTPFCVEQJN0QCghDU6lyfjIappr1+gU97qq7D7+j0AoJz2 A7trXTOXeyTUKG92vpZ/nfWw =fIOK -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sat Nov 1 07:37: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 HAA05279 for ; Sat, 1 Nov 2003 07:37:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFuyY-000Jev-18 for multi6-data@psg.com; Sat, 01 Nov 2003 12:35:30 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFuyS-000JeW-OR for multi6@ops.ietf.org; Sat, 01 Nov 2003 12:35:25 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA1CXsed063604; Sat, 1 Nov 2003 13:33:54 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20031031125844.24BBAC6C702@guns.icir.org> References: <20031031125844.24BBAC6C702@guns.icir.org> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Notes on draft-crocker-mast-analysis-01.txt Date: Sat, 1 Nov 2003 13:34:02 +0100 To: mallman@icir.org X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 31 okt 2003, at 13:58, Mark Allman wrote: > There have been measurement studies conducted (e.g., Partiridge, > et. al. in Dec/1999 ToN) that show reordering is not as rare as one > might think. And, furthermore, it can be fairly significant > reordering (i.e., not just swapping two packets). I remember reading a study about reordering on MAE East, which also showed considerable reordering. However, IRRC this turned out to be mostly due to the parallel processing in the switches that were used. Today, router and switch vendors incorporate features to make sure that a "session" always flows over a single link. Sometimes it's even impossible to turn this off and the definition of a session is such that using two or more links in parallel doesn't work in practice because (nearly) all traffic is considered part of the same session. > It seems from reading these few messages I have seen that there are > really two issues with how reordering affects performance... > * Implementation efficiency. I.e., with reordering we have to > hold, manage and process data in the receiver in ways that are > different and less efficient (from what I hear) than the > techniques used for in-order arrival. This seems intuitive to > me. (Although, stack implementation is not my forte.) Yes, processing packets out of order is going to take a bit more time. But I believe this is fairly minimal, assuming that upon reception, packets are copied to memory where they can sit for a while without causing problems. The processing required to handle this is completely insignificant compared to interrupt handling, memcopies and checksum calculations. (And if these are offloaded to the NIC, offloading reordering too isn't a big stretch.) > * Algorithmic response. As has been noted TCP's congestion > control algorithms (RFC2581) are fairly intolerant to large > amounts of reordering. This is been shown in a number of > studies (Blanton/Allman Jan/2002 CCR; Floyd, et. al.'s 2002 ICIR > tech report; Bhandarkar, et.al.'s TCP-DCR work). The > mitigations proposed in those studies vary, but the general > theme is that in networks where reordering can be detected the > interpretation of duplicate ACKs as a loss signal should be made > more conservative to accomodate the reordering. Right. Problem solved. :-) >> Implementations just need to change a bit to avoid unnecessary >> fast retransmits if they want to support using parallel links. I >> don't think this is a huge deal. > It might not be a "huge deal", but I do not think we have good > consensus on the right approach at this point. Remember what Brian said: this stuff is probably going to be around for a long time, and today's limitations aren't necessarily going to be relevant in the future. So I think that we shouldn't introduce reordering if we can avoid it at no or little cost, but on the other hand not shy away from doing things that do so if this leads to significant advantages elsewhere. >> One thing that bothers me about TCP and that also doesn't do us >> any favors here is that it sends packet trains back-to-back all >> the time. This can at times be very harmful as it unnecessarily >> increases burstiness. Especially cheap switches that must convert >> between different ethernet speeds don't have the buffering to >> handle this properly. > A different issue, but one I happen to be working on at the moment. :-) > There is a paper that was presented at the Internet Measurement > Conference earlier this week that shows the impact of such > burstiness on the network as a whole. I am more focused on a > narrower question that goes something like: If my TCP connection is > bursty, how does that impact my performance? > I'd be interested to hear about the "very harmful" behavior of TCP > in this regard. Just recently I worked on a setup where we transported broadcast quality TV signals from one place to another over an IP network. The problem was that the devices we used don't support retransmissions, so each and every lost packet becomes a visible artifact. Another problem was that the encoder supports 100 Mbps ethernet but the decoder only 10 Mbps. So somewhere along the path there must be a conversion from 100 to 10 Mbps. Despite the fact that the average bitrate for the MPEG-2 stream was 7 Mbps or lower, we had all kinds of trouble with lost packets when we used switches (especially but not only with cheap unmanaged ones) for this. Fortunately, the problems went away when we let routers do the speed conversion. It turned out that the encoder spat out packets at a rate of one every 160 to 250 microseconds for up to 3.5 milliseconds, and was then quiet for up to 40 milliseconds. However, at 10 Mbps it takes 900 microseconds to transmit one of these packets so one of those 3.5 ms bursts requires a buffering capacity of at least 10 packets. Apparently this is not something that switches consistently supply. With TCP similar things will happen, although during normal operation TCP will usually only transit two packets back to back in response to an ack. However, there are numerous situations where TCP emits much larger packet trains, for instance, when the congestion window grows, when the application releases a lot of data after being quiet for a while, after recieving an ack again when one or more previous ones were missed and so on. So this means TCP reacts much more violently to lost packets than expected, because the resulting packet trains trigger more congestion. But the real fun starts when running many TCP sessions at the same time and they start to synchronize. At some point this will start happening automatically when there is enough traffic, but there are also applications that have many TCP sessions that all receive data at the same time because of events in the application. For example, when I ran an Gnutella peer to peer file sharing client and I became an "ultrapeer", it was the job of my computer to reflect incoming requests out to 30 other systems. So that's at least 30 packets (from different TCP sessions) in quick succession. I experienced significant packet loss despite the fact that my ADSL line wasn't even close to 100% utilization. I think the solution to these problems would be for TCP to traffic shape both individual sessions and the aggregate traffic from different sessions flowing over the same path. This would have two additional advantages: less buffer utilization along the way, and lower delays. This in turn leads to better RTT measurements which should improve recovery from lost packets. The price would be more processing as TCP would have to wake up more often to transmit smaller amounts of data. The bandwidth / rate limit for an individual session wouldn't be too hard to figure out, especially if one end is configured with this information. Doing someting similar across sesions would be harder. > (And, offline may be best ... I must confess that I > am not sure how any of this relates to multi-homing and IPv6 and I > may be way off-topic here myself. If so, I'm certainly sorry.) Yes, if this discussion continues we should take it off-list. However a good understanding of TCP is important to multihoming :-) so I decided to reply on-list this time. From owner-multi6@ops.ietf.org Sat Nov 1 07:52: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 HAA05535 for ; Sat, 1 Nov 2003 07:52:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFvEw-000KZY-3e for multi6-data@psg.com; Sat, 01 Nov 2003 12:52:26 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFvEr-000KZC-Iu for multi6@ops.ietf.org; Sat, 01 Nov 2003 12:52:21 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc11) with SMTP id <2003110112522001300penmse> (Authid: sdawkins@comcast.net); Sat, 1 Nov 2003 12:52:20 +0000 Message-ID: <0e7801c3a077$0c4b9c20$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: Cc: "Multi6 Mailing List" References: <20031031125844.24BBAC6C702@guns.icir.org> Subject: Re: Notes on draft-crocker-mast-analysis-01.txt Date: Sat, 1 Nov 2003 06:52:45 -0600 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Iljitsch van Beijnum" To: Cc: "Multi6 Mailing List" Sent: Saturday, November 01, 2003 6:34 AM Subject: Re: Notes on draft-crocker-mast-analysis-01.txt > Yes, if this discussion continues we should take it off-list. However a > good understanding of TCP is important to multihoming :-) so I > decided to reply on-list this time. I definitely agree with Iljitsch - Mark, thank you for helping us improve our understanding of TCP. Spencer From owner-multi6@ops.ietf.org Sat Nov 1 08:14: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 IAA05964 for ; Sat, 1 Nov 2003 08:14:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFvaD-000LQY-9u for multi6-data@psg.com; Sat, 01 Nov 2003 13:14:25 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFvaA-000LQI-De for multi6@ops.ietf.org; Sat, 01 Nov 2003 13:14:22 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA1DEAed064050; Sat, 1 Nov 2003 14:14:11 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4D50289A-0C6D-11D8-A100-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: "Multi6 Mailing List" From: Iljitsch van Beijnum Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Sat, 1 Nov 2003 14:14:19 +0100 To: X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 31 okt 2003, at 14:38, marcelo bagnulo wrote: >>> The problem is that to detect that there is no route to a certain, >>> all >>> the alternative routes with increasing AS path are tried, which is >>> inherently slow. >> Only if there are no alternatives. If there are, the path for those is >> probably not that long so they show up pretty quickly. Only when the >> last/only path goes down you'll see the following problem: > Ok, but this is the case that we care, right? > From ISPA prespective, there is no longer a route to the destiantion, > so the > multi-homed site detects that and tries the alternative ISP (ISPB). > So the case that we care is the reconvergence of BGP within the portin > of > the network where a route to the destiantion address no longer exist No, fortunately it works a bit better than that. Consider: ISP A / | \ X | Y \ | / ISP B If X gets transit from both A and B, both A and B will always see the path to X over the other. (This is required because if X didn't get transit from B but only from A, B would _have_ to reach X over A.) So B's routing table would show: prefix next hop as path 10.11.12.0/24 x x a a x If the direct connection to X now disappears, B's routing table shows: prefix next hop as path 10.11.12.0/24 a a x This happens within seconds of the BGP session between X and B going down. BGP only propagates the best path, so before the outage Y would see: prefix next hop as path 10.11.12.0/24 a a x b b x and after: prefix next hop as path 10.11.12.0/24 a a x b b a x > Anyway, i guess that the reconvergence time is only part of the > problem. > Another part of the problem is the time required to detect the outage. > Only > this factor would render the solution inacceptable for many > applications. Agree. Fortunately work is underway in this area so hopefully this will get better in the future. From owner-multi6@ops.ietf.org Sat Nov 1 08:22: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 IAA06070 for ; Sat, 1 Nov 2003 08:22:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFvhM-000LoJ-Lf for multi6-data@psg.com; Sat, 01 Nov 2003 13:21:48 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFvhI-000Lno-OT for multi6@ops.ietf.org; Sat, 01 Nov 2003 13:21:45 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA1Cwded063873; Sat, 1 Nov 2003 13:58:40 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <22558442-0C6B-11D8-A100-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: "Multi6 Mailing List" From: Iljitsch van Beijnum Subject: Re: survivability, rewriting Date: Sat, 1 Nov 2003 13:58:48 +0100 To: X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 31 okt 2003, at 14:38, marcelo bagnulo wrote: >> One thing we haven't discussed so far: if upper layers provide us with >> a hint, what exactly does the multihoming layer do after receiving >> such >> a hint? > I thought this was what we were discussing with Erik in the Preserving > established sessiones thread :-) We may want to do some extra checking before immediately failing over. For real time stuff, transport protocols are usually implemented inside applications. This means the mh layer may receive far too many hints from the transport layer to actually act on each one of them. Also, it might be beneficial to find out which alternatives still work before selecting them to continue the session over. I'm thinking along the lines of sending out packets with all possible source/dest locator combinations and then see what comes back and how fast. Obviously we don't want to set off such a "ping bomb" too often. And we very likely don't want to use actual ICMP echos for this, but what do we want to use? > IMHO, i would like to explore alternative approaches first. > What about when recieving a ULP hint that there is a problem, change > both > source and destiantion locators and send the packet with rewrite ok > bit not > set? > A more aggresive option would be to send multiple packets in paralel, > each > one with a different combination of source and destiantion address, > and see > which reply comes first. Yes. But I don't think we want to do this with actual data packets. In fact, there may not be any data packets available when this is triggered by a hint. >> However, this doesn't solve what we should do when rewriting isn't >> permitted. Obviously we could come up with a multihoming mechanism >> where rewriting is always allowed, > I don't see how. If we put a 64 bit identifier in the low order bits of the 128 bit address and then either make transport work on these 64 bit ids (a la 8+8) or we expand the 64 bit id into a 128 bit one as explained in my http://www.muada.com/drafts/cryptoid.txt non-draft. Then there is no problem with arbitrarily changing source locators. (Except some minor security points.) > I mean, we are going to have two mechanisms, one based on bgp + > rewriting > and the other one is based on ULP hints. BGP is a non-starter as there can always be failures that don't show up in BGP because of aggregation. > Now it is expected that the ULP hints mechanism will be have a better > response time i.e. it will detect problems faster, right? That's the idea. > However, the ULP hints mechanism works in the host itself and the > bgp+rewrite mechanism is in the routers. This means that even if the > ULP > hint mechanism has detected a problem and changed the locator, if the > final > word about this belongs to the routing system, the bgp+rewriting > mechanism > will overrule the decisions made by the ULP hint mechanism which is > exaclty > what we don?t want Indeed. > So we need a mechanism to force the routing system to accept choices > made by > the host, since the host is better detecting problems in the path. > Such a mechanism seems to require the capability to express that > rewriting > is not permited. Or useful. >> But "legacy" IPv6 also doesn't permit >> rewriting, so we must be prepared to handle this. The obvious solution >> is source address based routing, but it doesn't seem like everyone is >> convinced. > Well, we could use a routing header. You mean a routing header indicates permission to rewrite? That seems rather extreme. I'd use a different link layer encapsulation (= ethertype) or even IP version number first. > Even we could define a routing headers > that is elimated by the exit routers, in order to addresss the MTU > reduction > problem. That would only work if the first hop has a higher MTU than the rest of the path... Also removing some data in the middle of a packet is an extremely expensive operation in software. > An obvious comment about source address based routing is that source > address > based routing only has to be implemented within the multihomed site. Yes. It is not unthinkable that a host or even a small site has connections to two or more ISPs and/or larger sites. For instance, a laptop may be connected to the multihomed enterprise network while at the same time connecting to a GPRS ISP, or a home user could have an ISP connection and a VPN back to the multihomed enterprise network. But I think source address based routing or rewriting doesn't have to be arbitrarily stackable without the layers knowing about eachother. From owner-multi6@ops.ietf.org Sat Nov 1 14:16: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 OAA12697 for ; Sat, 1 Nov 2003 14:16:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AG1Bs-0009G2-FL for multi6-data@psg.com; Sat, 01 Nov 2003 19:13:40 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AG1Bk-0009FY-Uv for multi6@ops.ietf.org; Sat, 01 Nov 2003 19:13:33 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9627B395; Sat, 1 Nov 2003 20:13:31 +0100 (CET) Received: from lolo (vpn-252-67.uc3m.es [163.117.252.67]) by smtp03.uc3m.es (Postfix) with SMTP id E3427390; Sat, 1 Nov 2003 20:13:29 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Sat, 1 Nov 2003 20:07:49 +0100 Message-ID: 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <22558442-0C6B-11D8-A100-00039388672E@muada.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > We may want to do some extra checking before immediately failing over. > For real time stuff, transport protocols are usually implemented inside > applications. This means the mh layer may receive far too many hints > from the transport layer to actually act on each one of them. Good point. I guess that the M6 layer will have to react to a hint and then ignore the next hints for a certain period > Also, it > might be beneficial to find out which alternatives still work before > selecting them to continue the session over. Ok, but wouldn't this delay the reovery? i.e. the response time would be worse (see below) > > I'm thinking along the lines of sending out packets with all possible > source/dest locator combinations and then see what comes back and how > fast. Obviously we don't want to set off such a "ping bomb" too often. > And we very likely don't want to use actual ICMP echos for this, but > what do we want to use? > [...] > Yes. But I don't think we want to do this with actual data packets. In > fact, there may not be any data packets available when this is > triggered by a hint. > I can think of two types of hints: - a first type where the sending endpoint timeouts, so it detects the failure by itself. This is the case where ack are used such as tcp. In this case the ULP of the endpoint that is sending hints the M6 layer of the sending endpoint (this is the easy case, i guess) - a second type where no ack are used, so the ones that detects the failure is the receiving end who detects the failure because it no longer receives packets at the expected rate. In this case, the receiving end has to communicate the problem to the sending endpoint. So in this case, the ULP of the receiving endpoint has to hint the M6 layer of the sending endpoint. Does thus makes sense? can you think of other scenarios? Then in the first case, the sending enpoint always has packets, since it has detected the failure because of retransmissions, i guess. So, why don't you think it should not try every possible path with data packets? In the second case, in order to discover which path is working, you will need a message exchange, since probably there will be no packets back from the receiving endpoint to the sending endpoint that allow the sending endpoint to find out which is the combination of source and destination address that it is actually working. So i guess that in this case, it would make sense to have a protocol in the M6 layer to perform the available path discovery. [...] > > I mean, we are going to have two mechanisms, one based on bgp + > > rewriting > > and the other one is based on ULP hints. > > BGP is a non-starter as there can always be failures that don't show up > in BGP because of aggregation. > IMHO BGP is too slow, as we already agreed, but i am not uderstanding your point about the aggregation. I do understand it when you use bgp from the sending endpoint, so you cannot see if the target endpoint is really reachable because aggregation hides it from you. But if you use BGP plus rewriting as Erik suggests, then aggregation is not a problem, because you use bgp as a mean to discover the available path, not to see which address you should use. The information about what address to use is carried in the source address field of the received packet. Anyway, could you put an example where tha aggregation cause the problems that you mention? (sorry to ask you this, but i really fail to see the problem here) [...] > >> But "legacy" IPv6 also doesn't permit > >> rewriting, so we must be prepared to handle this. The obvious solution > >> is source address based routing, but it doesn't seem like everyone is > >> convinced. > > > Well, we could use a routing header. > > You mean a routing header indicates permission to rewrite? No. sorry for not being more explicit. I was suggesting using a routing header to allow the host to force the exit ISP i.e. as an alternative to the source address based routing > That seems > rather extreme. I'd use a different link layer encapsulation (= > ethertype) or even IP version number first. > > > Even we could define a routing headers > > that is elimated by the exit routers, in order to addresss the MTU > > reduction > > problem. > > That would only work if the first hop has a higher MTU than the rest of > the path... Also removing some data in the middle of a packet is an > extremely expensive operation in software. > Yes, but isn't this the most usual case? > > An obvious comment about source address based routing is that source > > address > > based routing only has to be implemented within the multihomed site. > > Yes. It is not unthinkable that a host or even a small site has > connections to two or more ISPs and/or larger sites. For instance, a > laptop may be connected to the multihomed enterprise network while at > the same time connecting to a GPRS ISP, or a home user could have an > ISP connection and a VPN back to the multihomed enterprise network. But > I think source address based routing or rewriting doesn't have to be > arbitrarily stackable without the layers knowing about eachother. > I think that i agree with you. I think that we need a mechanism to allow the host to indicate if it allows rewriting in the packets, is this what you mean? Regard, marcelo From owner-multi6@ops.ietf.org Sat Nov 1 14:31: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 OAA13051 for ; Sat, 1 Nov 2003 14:31:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AG1SX-0009v1-0i for multi6-data@psg.com; Sat, 01 Nov 2003 19:30:53 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AG1ST-0009up-S9 for multi6@ops.ietf.org; Sat, 01 Nov 2003 19:30:50 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F2ECF379; Sat, 1 Nov 2003 20:30:48 +0100 (CET) Received: from lolo (vpn-252-68.uc3m.es [163.117.252.68]) by smtp03.uc3m.es (Postfix) with SMTP id 80D98340; Sat, 1 Nov 2003 20:30:47 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: Cc: Subject: about draft-ohta-multihomed-isps-00.txt Date: Sat, 1 Nov 2003 20:25:07 +0100 Message-ID: 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Masataka, I wonder, wouldn't this issues be more related to RIR policy than to the IETF (in particular multi6 wg)? I mean, if i understand correclty, what it is being proposed in the draft is somehow similar to what was included in the deprecated aggrgatable global unicast format (the draft even uses the TLA NLA terminology), and if i understand correclty, this was decided to be a RIR issue, right? OTOH, i guess that you are concerned about isp multihoming. IMHO this is a relevant issue that would be interesting to discuss, but i guess this is not the appropriate wg for this (considering that it is the SITE multi-homing wg and that we already have a lot of work to do to make site multihoming work :-). So perhaps it would be an intersting idea to make an interest list to discuss this issue without interferring with the work of multi6, what do you think? Regards, marcelo From owner-multi6@ops.ietf.org Sun Nov 2 07:11:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14003 for ; Sun, 2 Nov 2003 07:11:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGH1S-000KYX-VE for multi6-data@psg.com; Sun, 02 Nov 2003 12:07:58 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGH1G-000KY1-PI for multi6@ops.ietf.org; Sun, 02 Nov 2003 12:07:47 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA2C7Jed078547; Sun, 2 Nov 2003 13:07:19 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <415E4703-0BBD-11D8-9AE2-000A9598A184@kurtis.pp.se> References: <415E4703-0BBD-11D8-9AE2-000A9598A184@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <20BEB9BA-0D2D-11D8-BC3D-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: agenda@ietf.org, multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Tentative agenda for Multi6 in Minneapolis Date: Sun, 2 Nov 2003 13:07:28 +0100 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 31 okt 2003, at 17:14, Kurt Erik Lindqvist wrote: > 1700-1800 Afternoon Sessions IV Kurtis, I know the IETF has a long standing tradition of having sessions that are relevant to the same broad interest groups overlap, but tuesday 17 - 18 hours multi6 overlaps with the ipv6 wg. This seems rather insane. Is there anything that can be done about this? From owner-multi6@ops.ietf.org Sun Nov 2 07:30: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 HAA14306 for ; Sun, 2 Nov 2003 07:30:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGHMr-000LNS-JD for multi6-data@psg.com; Sun, 02 Nov 2003 12:30:05 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGHMf-000LM5-AU for multi6@ops.ietf.org; Sun, 02 Nov 2003 12:29:53 +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 MAA14624; Sun, 2 Nov 2003 12:29:41 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA19326; Sun, 2 Nov 2003 12:29:41 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA2CTeM01978; Sun, 2 Nov 2003 12:29:40 GMT Date: Sun, 2 Nov 2003 12:29:40 +0000 From: Tim Chown To: Iljitsch van Beijnum Cc: Kurt Erik Lindqvist , agenda@ietf.org, multi6@ops.ietf.org Subject: Re: Tentative agenda for Multi6 in Minneapolis Message-ID: <20031102122940.GD1866@login.ecs.soton.ac.uk> Mail-Followup-To: Iljitsch van Beijnum , Kurt Erik Lindqvist , agenda@ietf.org, multi6@ops.ietf.org References: <415E4703-0BBD-11D8-9AE2-000A9598A184@kurtis.pp.se> <20BEB9BA-0D2D-11D8-BC3D-00039388672E@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20BEB9BA-0D2D-11D8-BC3D-00039388672E@muada.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk A good spot Iljitsch - this one has to be fixed. Tim On Sun, Nov 02, 2003 at 01:07:28PM +0100, Iljitsch van Beijnum wrote: > On 31 okt 2003, at 17:14, Kurt Erik Lindqvist wrote: > > >1700-1800 Afternoon Sessions IV > > Kurtis, I know the IETF has a long standing tradition of having > sessions that are relevant to the same broad interest groups overlap, > but tuesday 17 - 18 hours multi6 overlaps with the ipv6 wg. This seems > rather insane. Is there anything that can be done about this? > From owner-multi6@ops.ietf.org Sun Nov 2 12:35: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 MAA20661 for ; Sun, 2 Nov 2003 12:35:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGM5k-0006Vc-Em for multi6-data@psg.com; Sun, 02 Nov 2003 17:32:44 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGM5X-0006Us-RZ for multi6@ops.ietf.org; Sun, 02 Nov 2003 17:32:31 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hA2Hccf27972; Sun, 2 Nov 2003 09:38:38 -0800 Date: Sun, 2 Nov 2003 09:31:30 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <101408265424.20031102093130@brandenburg.com> To: Erik Nordmark CC: multi6@ops.ietf.org Subject: Re: I-D ACTION:draft-nordmark-multi6-sim-01.txt (Fwd) In-Reply-To: References: "Your message with ID" <200310272146.QAA15161@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, EN> Title : Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128) It would be helpful for the different proposals and specifications to discussion adoption, administration, use and performance issues, as well as design rationale. Your spec has the Protocol Walthrough, which gives detail about some of the usage effort. Explicit discussion about the critical adoption requirements would be particularly helpful. I am probably not reading the specification correctly, but it appears that SIM requires: ADOPTION 1. Modification to both endpoints, using a shim layer directly above IP 2. Addition of a DNS record type and expected modification of DNS servers, to do differential processing, based on presence or absence of records of that type, when a query for that record type is made 3. Modification of intermediate routers, to do locator re-writing. DESIGN As the spec notes, deferred validation of new locators adds complexity to the protocol. My question is, therefore, why you chose deferred validation, versus automatic validation? In general, it would be helpful to understand the reasons for the various choices made in SIM. The use of context tags in every packet appears intended to provide a higher level of protection than exists in current IP. 1) What is to prevent a wire-tapper from using the copying the tag? 2) If sites want this kind of per-packet extra protection, why not use IPSec or TLS? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Nov 3 01:13:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08356 for ; Mon, 3 Nov 2003 01:13:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGXvo-000ANQ-Ou for multi6-data@psg.com; Mon, 03 Nov 2003 06:11:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AGXvb-000AN2-UI for multi6@ops.ietf.org; Mon, 03 Nov 2003 06:11:04 +0000 Received: (qmail 24211 invoked from network); 3 Nov 2003 06:15:37 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 3 Nov 2003 06:15:37 -0000 Message-ID: <3FA5F1CB.6010507@necom830.hpcl.titech.ac.jp> Date: Mon, 03 Nov 2003 15:12:27 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Spencer Dawkins CC: multi6@ops.ietf.org Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) References: <0d3201c39f61$8eb3d4a0$0400a8c0@DFNJGL21> In-Reply-To: <0d3201c39f61$8eb3d4a0$0400a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Spencer Dawkins; > My apologies for not being clearer. What I meant was, multi6 should > pick a targer for survivability, whether measured in tens of minutes > (TCP), tens of seconds (HTTP with a human in the loop) or hundreds of > milliseconds (VoIP). Wrong. First of all, you confuse timeout to try alternative addresses (for HTTP (over TCP) and VoIP) and timeout to disconnect (for TCP (including TCP under HTTP). Then, you properly mention, for both cases of timeout, the target value differs application by application that there can be no meaningful target defined by multi6. What's necessary is a set of API for TCP/VoIP layers. > By doing so, communities can consider their needs vis-a-vis the > target. If your needs are met by the target, you can rely on multi6 > for survivability, and if not, you can start working on > special-purpose survivability mechanisms. Wrong. In most of the cases, we can rely on TCP for survivability, just as TCP is the default mechanism for error free transmission. They are all described in my draft for these years. Masataka Ohta From owner-multi6@ops.ietf.org Mon Nov 3 02: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 CAA23086 for ; Mon, 3 Nov 2003 02:52:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGZUL-000ETg-8k for multi6-data@psg.com; Mon, 03 Nov 2003 07:51:01 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AGZU8-000ESX-3p for multi6@ops.ietf.org; Mon, 03 Nov 2003 07:50:48 +0000 Received: (qmail 24484 invoked from network); 3 Nov 2003 07:55:24 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 3 Nov 2003 07:55:24 -0000 Message-ID: <3FA6092D.7000105@necom830.hpcl.titech.ac.jp> Date: Mon, 03 Nov 2003 16:52:13 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Erik Nordmark , Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: survivability, rewriting References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>Is that true when you have a tree of reseller ISPs? >> >>For instance >> >> DFZ >> / | \ >> ISP1 ISP2 ISP3 >> / \ / \ / \ >> ISPA ISPB ISPC ISPD >> \ / >> my site >> >> > > > Good question IMHO... It is a case addressed in draft-ohta-multihomed-isps-00.txt. > But IMHO this is not how provider multihoming will be. IMHO ISPs will be > able to get a /32 each one, especially those ISP that are multi-homed to > multilpe upstream providers. That you are trying to reserve space for 2^32 (or 2^29) such ISPs means that you must expect that many routing table entries, which is no acceptable. Masataka Ohta From owner-multi6@ops.ietf.org Mon Nov 3 03:02: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 DAA23222 for ; Mon, 3 Nov 2003 03:02:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGZeh-000Ev9-FG for multi6-data@psg.com; Mon, 03 Nov 2003 08:01:43 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AGZeU-000EuA-NM for multi6@ops.ietf.org; Mon, 03 Nov 2003 08:01:31 +0000 Received: (qmail 24525 invoked from network); 3 Nov 2003 08:06:06 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 3 Nov 2003 08:06:06 -0000 Message-ID: <3FA60BAF.4010701@necom830.hpcl.titech.ac.jp> Date: Mon, 03 Nov 2003 17:02:55 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: multi6@ops.ietf.org Subject: Re: about draft-ohta-multihomed-isps-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; > Hi Masataka, > > I wonder, wouldn't this issues be more related to RIR policy than to the > IETF (in particular multi6 wg)? It isn't. RIRs are currently discussing to assign unique address range to multihomed sites and that is best possible to them who must discuss base on an existing poor protocol. > I mean, if i understand correclty, what it is being proposed in the draft is > somehow similar to what was included in the deprecated aggrgatable global > unicast format (the draft even uses the TLA NLA terminology), and if i > understand correclty, this was decided to be a RIR issue, right? Was decided? No, I didn't. That IPv6 WG failed to develop a reasonable protocol is not my problem. > OTOH, i guess that you are concerned about isp multihoming. IMHO this is a > relevant issue that would be interesting to discuss, but i guess this is not > the appropriate wg for this (considering that it is the SITE multi-homing wg > and that we already have a lot of work to do to make site multihoming work > :-). So perhaps it would be an intersting idea to make an interest list to > discuss this issue without interferring with the work of multi6, what do you > think? I have no interest to join such a list. Masataka Ohta From owner-multi6@ops.ietf.org Mon Nov 3 03:34: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 DAA23694 for ; Mon, 3 Nov 2003 03:34:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGa9L-000Fu6-E0 for multi6-data@psg.com; Mon, 03 Nov 2003 08:33:23 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AGa95-000Ftn-Un for multi6@ops.ietf.org; Mon, 03 Nov 2003 08:33:08 +0000 Received: (qmail 24600 invoked from network); 3 Nov 2003 08:37:44 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 3 Nov 2003 08:37:44 -0000 Message-ID: <3FA61319.8080805@necom830.hpcl.titech.ac.jp> Date: Mon, 03 Nov 2003 17:34:33 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Elementary fact on cryptographic security Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A elementary fact on cryptographic security is that related parties must be securely configured in advance with some information on keys. Otherwise, a system is, as is exemplified by DH key exchange, subject to MITM attack. However, there are people trying to make something impossible possible by complicated engineering. Some of them ignore laws of thermodynamics and try to invent complicated perpetual motion machines. Others write complicated drafts with plain DNS to supply signatures of insecure public keys to improve security ignoring the fact that plain DNS is an easy victim of the MITM attack. Masataka Ohta PS The next obvious step for them is autocnfiguration of secure DNS. :-) From owner-multi6@ops.ietf.org Mon Nov 3 04:48: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 EAA25439 for ; Mon, 3 Nov 2003 04:48:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGbHp-000IdE-Ix for multi6-data@psg.com; Mon, 03 Nov 2003 09:46:13 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGbHd-000Ich-KU for multi6@ops.ietf.org; Mon, 03 Nov 2003 09:46:01 +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 hA39jt5u028963; Mon, 3 Nov 2003 02:45:56 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA39jsS13195; Mon, 3 Nov 2003 10:45:54 +0100 (MET) Date: Mon, 3 Nov 2003 10:45:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > IMHO You would want to use the source address based routing when you don't > want to use source address rewriting. > There are some situations where you don't want the rewrite to take place and > you want source address based routing. I can think of the following: > - The external host don't support M6 > - The M6 context has not been established yet > - An ULP hint made the M6 layer to select a different path, so you want to > let the host select the ISP and not the routing system I understand why the first bullet doesn't want source rewriting, but from that it doesn't follow that source address based routing is needed. The second case can be made to handle rewriting by carrying the identifiers explicitly in those packets. This has the cost of additional overhead during the M6 context establishment, but might have benefits in terms of more quickly being able to detect failures during that establishment; need to understand the details in that tradeoff. > So a possible approach would be that if the rewrite ok bit is set, then you > perform destination address routing and if the rewrite ok bit is not set you > do source address based routing. > Does this makes sense? I don't understand what pieces of the total routing system needs to be changed to support source address based routing, so I'm not sure this makes any sense. Erik From owner-multi6@ops.ietf.org Mon Nov 3 04:53:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25553 for ; Mon, 3 Nov 2003 04:53:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGbNj-000IwT-O3 for multi6-data@psg.com; Mon, 03 Nov 2003 09:52:19 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGbNW-000Ive-U1 for multi6@ops.ietf.org; Mon, 03 Nov 2003 09:52:06 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA39puxA019669; Mon, 3 Nov 2003 01:51:57 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA39ptS13575; Mon, 3 Nov 2003 10:51:55 +0100 (MET) Date: Mon, 3 Nov 2003 10:51:24 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: survivability, rewriting To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , Multi6 Mailing List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I assume that in your example above you are considering the case where ISPA > obtains addresses form ISP1 and ISPB from (ISP1 and ISP2), and ISPC from > (ISP2 and ISP3), right? Yep. > This implies that my site has 4 prefixes and in that case source address > based routing is also required in ISPB and ISPC, correct? That is what it would seem to imply; if you want to be able to use the source address as a way to select between the "upper layer" ISPs to whom the site isn't directly connected. > But IMHO this is not how provider multihoming will be. IMHO ISPs will be > able to get a /32 each one, especially those ISP that are multi-homed to > multilpe upstream providers. That is an address allocation policy issue and I don't think the answer is that obvious. If anybody that says "I'm an ISP" can get a /32 then I can get one for my house since I provide network service for all members of my family - hence I'm an ISP! :-) To avoid giving everybody a /32 that asks there has to be some notion of size taken into account in the policy. This means that a neighborhood ISP might not be able to get a /32 - and for good reasons. I think it would be shortsighted to assume that the word in which a multihoming solution exists only consists of sites and of ISPs large enough to warrant a /32 allocation. Perhaps that will be the future, but keeping the door open for the existance of smaller ISPs would make a lot of sense to me. Erik From owner-multi6@ops.ietf.org Mon Nov 3 05:00: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 FAA25764 for ; Mon, 3 Nov 2003 05:00:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGbUp-000JN3-QW for multi6-data@psg.com; Mon, 03 Nov 2003 09:59:39 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGbUd-000JM1-N6 for multi6@ops.ietf.org; Mon, 03 Nov 2003 09:59:27 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA39xHxA022079; Mon, 3 Nov 2003 01:59:18 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA39xGS14071; Mon, 3 Nov 2003 10:59:16 +0100 (MET) Date: Mon, 3 Nov 2003 10:58:46 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: survivability, rewriting To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , Multi6 Mailing List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > 1. The ULPs need to know the addresses of the node itself to be able > > to perform certain forms of referal. But that doesn't prevent > > the node to issue IP packets with a source locator that doesn't > > include the upper bits of the address *as long as* the host knows > > that there is a rewriting router along the path. > > > I am sorry, Erik, but i don't understand this argument. > Those rewritable addresses wouldn't be passed for referrals purposes, they > are just an artifact to let the M6 layer to notify the border router that > they should complete with a real prefix. The application would only be aware > of the AID. The referals would contain real locators. I guess i am missing > your point here :-( I guess I wasn't very clear - there are two separate issues mixed together. One could allocate a prefix, such a 0::/48 if you ignore that there is some other use for that, for use as the source locator. Thus the host could send packets with that source *IF* it knows that there is a rewriting router in the path which will insert the correct high-order bits in the source locator. But this is tricky to migrate to since the host would need to be able to tell whether its site has such rewriting routers at the boundary; if the 0::/48 makes it to a remote peer it will not be able to respond. How can it do this? Having the source send packets with the actual source locator prefix plus indicating that it is ok to rewrite it doesn't have this issue; if there is no rewriting router in the path the source locator stays unmodified but it still usable for the peer to respond. Second part is just the observation that having the node send packets with a fixed source prefix (such as 0::/48) doesn't remove the need for the ULP/apps to know the actual source locator, since it might need this as part of referals. Erik From owner-multi6@ops.ietf.org Mon Nov 3 05:47: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 FAA27074 for ; Mon, 3 Nov 2003 05:47:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGcDl-000L92-Fv for multi6-data@psg.com; Mon, 03 Nov 2003 10:46:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AGcDZ-000L89-BR for multi6@ops.ietf.org; Mon, 03 Nov 2003 10:45:53 +0000 Received: (qmail 25010 invoked from network); 3 Nov 2003 10:50:28 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 3 Nov 2003 10:50:28 -0000 Message-ID: <3FA63233.9050803@necom830.hpcl.titech.ac.jp> Date: Mon, 03 Nov 2003 19:47:15 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Ray Plzak CC: multi6@ops.ietf.org Subject: Re: Routing table size? References: <000401c39180$76ad34d0$728888c0@arin.net> In-Reply-To: <000401c39180$76ad34d0$728888c0@arin.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ray; I'd like to confirm your points. > The policy can only be for existing protocols/technology. It is a statement for RIRs, because it is RIRs, not IETF, which considers the policy for existing protocols/technology. > It doesn't > hurt to consider what an allocation policy should be when considering a > new or revised protocol. It is a statement for multi6, because it is multi6, not RIRs, which is considering the new or revised protocol. Right? Masataka Ohta From owner-multi6@ops.ietf.org Mon Nov 3 07:28: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 HAA29221 for ; Mon, 3 Nov 2003 07:28:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGdmP-000Oey-2R for multi6-data@psg.com; Mon, 03 Nov 2003 12:25:57 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGdmC-000OeP-Ck for multi6@ops.ietf.org; Mon, 03 Nov 2003 12:25:44 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc13) with SMTP id <20031103122543015000h4foe> (Authid: sdawkins@comcast.net); Mon, 3 Nov 2003 12:25:43 +0000 Message-ID: <0ff101c3a205$ab9f35e0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <0d3201c39f61$8eb3d4a0$0400a8c0@DFNJGL21> <3FA5F1CB.6010507@necom830.hpcl.titech.ac.jp> Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 3 Nov 2003 06:26:12 -0600 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sigh. Has anyone ever made a helpful suggestion? anyway. ----- Original Message ----- > Spencer Dawkins; > > > My apologies for not being clearer. What I meant was, multi6 should > > pick a targer for survivability, whether measured in tens of minutes > > (TCP), tens of seconds (HTTP with a human in the loop) or hundreds of > > milliseconds (VoIP). > > Wrong. > > First of all, you confuse timeout to try alternative addresses > (for HTTP (over TCP) and VoIP) and timeout to disconnect (for > TCP (including TCP under HTTP). > > Then, you properly mention, for both cases of timeout, the target > value differs application by application that there can be no > meaningful target defined by multi6. My point here was that humans-in-the-loop give up orders of magnitude sooner than FTP over TCP (to use one example). Your point, that "giving up" may involve different strategies for different applications, is helpful, but seems orthogonal to my point. > > What's necessary is a set of API for TCP/VoIP layers. I usually understand your terse comments, but not this one. You don't mean TCP/VoIP, do you? You mean "TCP and VoIP"? If not, I am hopelessly confused. > > > By doing so, communities can consider their needs vis-a-vis the > > target. If your needs are met by the target, you can rely on multi6 > > for survivability, and if not, you can start working on > > special-purpose survivability mechanisms. > > Wrong. > > In most of the cases, we can rely on TCP for survivability, just > as TCP is the default mechanism for error free transmission. If by "most of the cases" you believe that end users will sit quietly while TCP recovers, over a period of minutes, you and I are not solving the same problem. In the case of a computer using FTP as part of a cron job, I agree with you, but my experience is that this portion of Internet traffic is small and declining. > > They are all described in my draft for these years. I think (to rephrase in terms of my post) you have already chosen a target for connection survivability (and it's something timeframes appropriate for TCP), and are expecting applications with a shorter target to use an API that includes trying alternative addresses before TCP connections disconnect. That's certainly one alternative. I am asking that we make our choice explicit, perhaps in a *current* *working group* Internet Draft... > > Masataka Ohta > > From owner-multi6@ops.ietf.org Mon Nov 3 08:18: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 IAA00789 for ; Mon, 3 Nov 2003 08:18:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGea9-0000VQ-SM for multi6-data@psg.com; Mon, 03 Nov 2003 13:17:21 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGeZx-0000UX-Lg for multi6@ops.ietf.org; Mon, 03 Nov 2003 13:17:09 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA3DH2xA029824; Mon, 3 Nov 2003 05:17:03 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA3DH1S14429; Mon, 3 Nov 2003 14:17:01 +0100 (MET) Date: Mon, 3 Nov 2003 14:16:31 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-nordmark-multi6-sim-01.txt (Fwd) To: Dave Crocker Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <101408265424.20031102093130@brandenburg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > ADOPTION > > 1. Modification to both endpoints, using a shim layer directly above IP Yes. > 2. Addition of a DNS record type and expected modification of DNS servers, to > do differential processing, based on presence or absence of records of that > type, when a query for that record type is made There is a new DNS rr type needed, but there is no differential processing in the DNS servers. The hosts query for the new "ID" record and AAAA records. > 3. Modification of intermediate routers, to do locator re-writing. Not required from the outset, but for some failures having locator re-writing simplifies and speeds up failure recovery. Thus one could start deploying this type of approach without any upgraded routers. > DESIGN > > As the spec notes, deferred validation of new locators adds complexity to the > protocol. > > My question is, therefore, why you chose deferred validation, versus > automatic validation? In general, it would be helpful to understand the > reasons for the various choices made in SIM. The overhead of performing a public-key signed response to the challenge is the concern that made me explore the omitted validation (until there is a peer locator change). I don't claim to fully understand the tradeoffs here, but playing around with when validation is performed, perhaps also combining it with different strength validation, is something we should do to explore the design space. > The use of context tags in every packet appears intended to provide a higher > level of protection than exists in current IP. Don't think so. The context tag is needed to be able to identify the replacement needed for the IP address fields before passing the packet to the ULP. Since the locators in the packet are not used for this there has to be some "key" in the packet to indicate the replacement needed. There is also a security aspect of the tag having to do with packet injection. See section 4.4. "Accepting Packets from Unknown Locators" in draft-nordmark-multi6-threats for the threat. I can think of 2 ways to address that threat: - a packet with an unknown source locator is dropped (or queued by the receiver) until the source locator has been verified. - a packet with an unknown source locator is accepted if it contains the correct tag SIM takes the second approach. The first approach would be more secure than today's Internet with some deployment of ingress filtering. > 1) What is to prevent a wire-tapper from using the copying the tag? Nothing - which is why it isn't any stronger that today's Internet - today an on-path attacker can inject packets and even ingress filtering can't prevent that. > 2) If sites want this kind of per-packet extra protection, why not use IPSec > or TLS? It isn't extra if you consider that there is some deployment of ingress filtering which prevents injecting packets with spoofed source addresses from many, but far from all, attachments to the Internet. Erik From owner-multi6@ops.ietf.org Mon Nov 3 08:45: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 IAA01661 for ; Mon, 3 Nov 2003 08:45:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGezS-0001Xl-2N for multi6-data@psg.com; Mon, 03 Nov 2003 13:43:30 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGez7-0001XP-Gf for multi6@ops.ietf.org; Mon, 03 Nov 2003 13:43:09 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA3Dgted095071; Mon, 3 Nov 2003 14:42:55 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <0ff101c3a205$ab9f35e0$0400a8c0@DFNJGL21> References: <0d3201c39f61$8eb3d4a0$0400a8c0@DFNJGL21> <3FA5F1CB.6010507@necom830.hpcl.titech.ac.jp> <0ff101c3a205$ab9f35e0$0400a8c0@DFNJGL21> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Iljitsch van Beijnum Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 3 Nov 2003 14:43:06 +0100 To: "Spencer Dawkins" X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3 nov 2003, at 13:26, Spencer Dawkins wrote: >> Then, you properly mention, for both cases of timeout, the target >> value differs application by application that there can be no >> meaningful target defined by multi6. > My point here was that humans-in-the-loop give up orders of magnitude > sooner than FTP over TCP (to use one example). Your point, that > "giving up" may involve different strategies for different > applications, is helpful, but seems orthogonal to my point. Users giving up before applications or protocols is a feature rather than a bug. When Apple first came out with its Safari web browser, it would only wait 30 seconds for a page to load. Now for normal pages 30 seconds is a very long time, so this seemed to make sense. (I'm usually much more impatient than 30 seconds, though.) However, some types of pages, such as very long ones or ones that generate a lot of work for the server (searching for a flight online...) need more than 30 seconds. I that case, the user will wait. Having the application give up when the user knows useful results are still forthcoming is infuriating. So as long as the user has the option to terminate the session and retry, there shouldn't be any problems. > If by "most of the cases" you believe that end users will sit quietly > while TCP recovers, over a period of minutes, you and I are not > solving the same problem. So what is it you want to do to avoid this situation? > In the case of a computer using FTP as part > of a cron job, I agree with you, but my experience is that this > portion of Internet traffic is small and declining. I don't think _any_ type of traffic on the internet is declining in absolute terms. :-) From owner-multi6@ops.ietf.org Mon Nov 3 09:04: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 JAA02166 for ; Mon, 3 Nov 2003 09:04:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGfIa-0002MY-O6 for multi6-data@psg.com; Mon, 03 Nov 2003 14:03:16 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AGfI8-0002LR-5O for multi6@ops.ietf.org; Mon, 03 Nov 2003 14:02:48 +0000 Received: (qmail 25601 invoked from network); 3 Nov 2003 14:07:28 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 3 Nov 2003 14:07:28 -0000 Message-ID: <3FA6605D.6060005@necom830.hpcl.titech.ac.jp> Date: Mon, 03 Nov 2003 23:04:13 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Spencer Dawkins CC: multi6@ops.ietf.org Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) References: <0d3201c39f61$8eb3d4a0$0400a8c0@DFNJGL21> <3FA5F1CB.6010507@necom830.hpcl.titech.ac.jp> <0ff101c3a205$ab9f35e0$0400a8c0@DFNJGL21> In-Reply-To: <0ff101c3a205$ab9f35e0$0400a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Spencer; > Sigh. Has anyone ever made a helpful suggestion? anyway. Sigh... >>>My apologies for not being clearer. What I meant was, multi6 > > should > >>>pick a targer for survivability, whether measured in tens of > > minutes > >>>(TCP), tens of seconds (HTTP with a human in the loop) or hundreds > > of > >>>milliseconds (VoIP). >> >>Wrong. >> >>First of all, you confuse timeout to try alternative addresses >>(for HTTP (over TCP) and VoIP) and timeout to disconnect (for >>TCP (including TCP under HTTP). >> >>Then, you properly mention, for both cases of timeout, the target >>value differs application by application that there can be no >>meaningful target defined by multi6. > > > My point here was that humans-in-the-loop give up orders of magnitude > sooner than FTP over TCP (to use one example). Your point, that > "giving up" may involve different strategies for different > applications, is helpful, but seems orthogonal to my point. Your mistake here is that you said "HTTP", which, just as "TCP", does NOT involve human beings. Even if you have said "web browser application with a human in the loop", you are still wrong. See below. >>What's necessary is a set of API for TCP/VoIP layers. > I usually understand your terse comments, but not this one. You don't > mean TCP/VoIP, do you? You mean "TCP and VoIP"? If not, I am > hopelessly confused. I mean TCP, VoIP or any application/transport where notion of timeout can be found. >>>By doing so, communities can consider their needs vis-a-vis the >>>target. If your needs are met by the target, you can rely on > > multi6 > >>>for survivability, and if not, you can start working on >>>special-purpose survivability mechanisms. >> >>Wrong. >> >>In most of the cases, we can rely on TCP for survivability, just >>as TCP is the default mechanism for error free transmission. > > > If by "most of the cases" you believe that end users will sit quietly > while TCP recovers, over a period of minutes, you and I are not > solving the same problem. In the case of a computer using FTP as part > of a cron job, I agree with you, but my experience is that this > portion of Internet traffic is small and declining. Typical end users do not wait timeout of a web browser and just push "resend" or "stop" button. The users have their own timeout controlled by neither TCP, HTTP or web browser and definitely not by multi6 WG. >>They are all described in my draft for these years. > > > I think (to rephrase in terms of my post) you have already chosen a > target for connection survivability (and it's something timeframes > appropriate for TCP), No. No timeframe can be assumed at the IP layer, as there is no notion of time (except for maximum TTL of 255 seconds of IPv4, which is not useful here). > and are expecting applications with a shorter > target to use an API that includes trying alternative addresses before > TCP connections disconnect. Wrong. Most applications do nothing and just expect TCP try alternative addresses, though VoIP won't rely on TCP, which is why I wrote "TCP/VoIP". > That's certainly one alternative. I am > asking that we make our choice explicit, perhaps in a *current* > *working group* Internet Draft... That's not my choice. Masataka Ohta From owner-multi6@ops.ietf.org Mon Nov 3 09:11:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02377 for ; Mon, 3 Nov 2003 09:11:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGfPx-0002fY-Ip for multi6-data@psg.com; Mon, 03 Nov 2003 14:10:53 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGfPl-0002ex-Ox for multi6@ops.ietf.org; Mon, 03 Nov 2003 14:10:41 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F3B20237; Mon, 3 Nov 2003 15:10:40 +0100 (CET) Received: from lolo (vpn-252-71.uc3m.es [163.117.252.71]) by smtp03.uc3m.es (Postfix) with SMTP id CE0D0235; Mon, 3 Nov 2003 15:10:39 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Dave Crocker" , "Erik Nordmark" Cc: Subject: RE: I-D ACTION:draft-nordmark-multi6-sim-01.txt (Fwd) Date: Mon, 3 Nov 2003 15:04:56 +0100 Message-ID: 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: <101408265424.20031102093130@brandenburg.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > As the spec notes, deferred validation of new locators adds > complexity to the protocol. > > My question is, therefore, why you chose deferred validation, > versus automatic validation? I like defferred validation, becuase you don't incurr in aditional costs until you really need to. I guess that most of the communication will only use one locator during its lifetime, so it seems wasteful to verify multiple locators in this case. Regards, marcelo From owner-multi6@ops.ietf.org Mon Nov 3 09:12: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 JAA02403 for ; Mon, 3 Nov 2003 09:12:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGfQg-0002jG-JZ for multi6-data@psg.com; Mon, 03 Nov 2003 14:11:38 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGfQD-0002gc-VE for multi6@ops.ietf.org; Mon, 03 Nov 2003 14:11:10 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0BBD4234; Mon, 3 Nov 2003 15:11:09 +0100 (CET) Received: from lolo (vpn-252-71.uc3m.es [163.117.252.71]) by smtp03.uc3m.es (Postfix) with SMTP id BF2B7231; Mon, 3 Nov 2003 15:11:07 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Mon, 3 Nov 2003 15:05:24 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > One could allocate a prefix, such a 0::/48 if you ignore that > there is some other use for that, for use as the source locator. > Thus the host could send packets with that source *IF* it knows that there > is a rewriting router in the path which will insert the correct > high-order bits in the source locator. > But this is tricky to migrate to since the host would need to be able > to tell whether its site has such rewriting routers at the boundary; > if the 0::/48 makes it to a remote peer it will not be able to respond. > How can it do this? I guess that if a host has the M6 mechanism working, it would be reasonable to assume that the site supports M6 and so that exit routers would rewrite the source address. But anyway you could also use a bit in the router advertisement to communicate it to the hosts, right? > Having the source send packets with the actual source locator prefix > plus indicating that it is ok to rewrite it doesn't have this issue; > if there is no rewriting router in the path the source locator > stays unmodified but it still usable for the peer to respond. > > Second part is just the observation that having the node send packets with > a fixed source prefix (such as 0::/48) doesn't remove the need for > the ULP/apps to know the actual source locator, since it might need > this as part of referals. > Agree but why this a problem? If i undestand correclty, Iljistch just wanted: "The obvious place to put an indication that the address may be rewritten is... in the address. " I don't see why the second part is conflicting with Iljistch goal... Regards, marcelo > Erik > From owner-multi6@ops.ietf.org Mon Nov 3 09:12: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 JAA02422 for ; Mon, 3 Nov 2003 09:12:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGfQR-0002hn-O9 for multi6-data@psg.com; Mon, 03 Nov 2003 14:11:23 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGfQC-0002gL-A0 for multi6@ops.ietf.org; Mon, 03 Nov 2003 14:11:08 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 799A0233; Mon, 3 Nov 2003 15:11:07 +0100 (CET) Received: from lolo (vpn-252-71.uc3m.es [163.117.252.71]) by smtp03.uc3m.es (Postfix) with SMTP id E13C0231; Mon, 3 Nov 2003 15:11:05 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , Subject: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 3 Nov 2003 15:05:22 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > IMHO You would want to use the source address based routing > > when you don't want to use source address rewriting. > > There are some situations where you don't want the rewrite to > > take place and you want source address based routing. > > I can think of the following: > > - The external host don't support M6 > > - The M6 context has not been established yet > > - An ULP hint made the M6 layer to select a different path, so > > you want to let the host select the ISP and not the routing system > > I understand why the first bullet doesn't want source rewriting, but from > that it doesn't follow that source address based routing is needed. Sorry, you are right. You don't want source address rewriting and you need an ingress filtering compatibility mechanism, which could be source address based routing. There are other options for this as decribed in Christian's draft, such as - a routing header (or tunnel) initiated from the host - an icmp source address error from the exit routers back to the host - tunnels between exit router (sort of source address based routing limited to the exit router) > > The second case can be made to handle rewriting by carrying the > identifiers explicitly in those packets. This has the cost of > additional overhead during the M6 context establishment, but might have > benefits in terms of more quickly being able to detect failures during > that establishment; need to understand the details in that tradeoff. > Ok. And the third case could be also addressed with some of the mechanisms mentioned above, i guess that source address based routing or routing header can be used for this case. ICMP and tunnel between exit router are not good. So, backward compatibility with non M6 enabled host require a alternative mechanism to source address rewriting. ULP hints would also require it. And packets exchanged before context establishement would also benefit from it. The identified mechanisms to provide this would be source address routing or a routing header. Do you agree with this summary? [...] > I don't understand what pieces of the total routing system > needs to be changed to support source address based routing, so I'm not > sure this makes any sense. Ok. The question here is whether every multi-homed ISP will be able to get an allocation or it will have to obtain addresses form its upstream providers, right? Well let's assume that it will obtain addresses from their upstream provider. Let's asume that ingress filtering will be in place, ok? Now, how would you deal with this without source address based routing? Let's start with ingress filtering compatibility: the options were: - source address based routing. besides the multihomed site all isps that don't have its own allocation would need to implement it - routing header. this would require n addresses in the routing header, one per upstream isp than don't have its own allocation, imposing extra overhead, and besides, i am not quite sure how the end host would discover the addresses of all the exit routers in the the path ( i am not sure how it will find out n, neither) - icmp back to the host. You have already mentioned some security concerns about letting externally generated ICMPs influence the path selected by hosts - tunnel between exit router. well, i guess that this would be really complex, since you would require tunnels between all exit router of the isp If you want to support ULP hint mechanism you only have the first two options. So, IMHO even if not all the multihomed isps won't get a direct allocation from the rirs, source address based routing seems the simplest option. Regards, marcelo > > Erik > From owner-multi6@ops.ietf.org Mon Nov 3 09:31: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 JAA03329 for ; Mon, 3 Nov 2003 09:31:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGfjL-0003sI-LZ for multi6-data@psg.com; Mon, 03 Nov 2003 14:30:55 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGfj9-0003ru-AE for multi6@ops.ietf.org; Mon, 03 Nov 2003 14:30:43 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA3EUQed095627; Mon, 3 Nov 2003 15:30:26 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4B1F3854-0E0A-11D8-A5FC-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 3 Nov 2003 15:30:38 +0100 To: X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3 nov 2003, at 15:05, marcelo bagnulo wrote: > You don't want source address rewriting and you need an ingress > filtering > compatibility mechanism, which could be source address based routing. > There > are other options for this as decribed in Christian's draft, such as > - a routing header (or tunnel) initiated from the host > - an icmp source address error from the exit routers back to the host > - tunnels between exit router (sort of source address based routing > limited > to the exit router) Another way to handle this would be to bascially build two networks all the way down to the host: ISP A ISP B | | Router Router | | Router Router \ / Host So the ISP selection happens inside the host, once a network is selected it is no longer possible to deviate from the path intended by the host. > The question here is whether every multi-homed ISP will be able to get > an > allocation or it will have to obtain addresses form its upstream > providers, > right? Current rules say you must have 200 customers that take IPv6 addresses from you in two years. Now obviously there are going to be ISPs for which this is a problem, but I don't see how we can arrive at very large numbers of multihomed sites that use ISPs with less than 200 customers. An alternative here would be for the ISP to set up routing with such a multihomed customer over only one of its own ISPs. > - icmp back to the host. You have already mentioned some security > concerns > about letting externally generated ICMPs influence the path selected by > hosts This isn't a solution as packets that belong to existing sessions can't be retransmitted with different source adddresses. > - tunnel between exit router. well, i guess that this would be really > complex, since you would require tunnels between all exit router of > the isp This is really the same thing as my "two separate networks" thing above, except that no actual hardware is used. From owner-multi6@ops.ietf.org Mon Nov 3 09:33: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 JAA03420 for ; Mon, 3 Nov 2003 09:33:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGflF-0003xl-IM for multi6-data@psg.com; Mon, 03 Nov 2003 14:32:53 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AGfl3-0003xI-N7 for multi6@ops.ietf.org; Mon, 03 Nov 2003 14:32:42 +0000 Received: (qmail 25701 invoked from network); 3 Nov 2003 14:37:22 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 3 Nov 2003 14:37:22 -0000 Message-ID: <3FA6675E.8030003@necom830.hpcl.titech.ac.jp> Date: Mon, 03 Nov 2003 23:34:06 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Erik Nordmark , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; See my draft on how end systems know proper source addresses corresponding to chosen destination addresses. Masataka Ohta From owner-multi6@ops.ietf.org Mon Nov 3 11:25: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 LAA09052 for ; Mon, 3 Nov 2003 11:25:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGhTY-0008zw-Br for multi6-data@psg.com; Mon, 03 Nov 2003 16:22:44 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGhTM-0008zF-9F for multi6@ops.ietf.org; Mon, 03 Nov 2003 16:22:32 +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 hA3GMQ5u015177; Mon, 3 Nov 2003 09:22:27 -0700 (MST) Received: from lillen (vpn-129-156-97-50.EMEA.Sun.COM [129.156.97.50]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA3GMOS14263; Mon, 3 Nov 2003 17:22:24 +0100 (MET) Date: Mon, 3 Nov 2003 17:21:54 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > So, backward compatibility with non M6 enabled host require a alternative > mechanism to source address rewriting. ULP hints would also require it. And > packets exchanged before context establishement would also benefit from it. > The identified mechanisms to provide this would be source address routing or > a routing header. > Do you agree with this summary? Another possible solution in some scenarios is that the ISP's ingress filtering is relaxed to allow all the prefixes assigned to the site. That might not be realistic for the low-end services for home users, but it might be a useful approach in other cases. > The question here is whether every multi-homed ISP will be able to get an > allocation or it will have to obtain addresses form its upstream providers, > right? > > Well let's assume that it will obtain addresses from their upstream > provider. > Let's asume that ingress filtering will be in place, ok? > > Now, how would you deal with this without source address based routing? Not doing strict RPF ingress filtering between the ISPs seem to be the current operational approach for such problems. My gut feel currently is that one would need a really strong case to make the routing system operate on source and destination addresses. I've yet to see such a strong case. But perhaps tweaking the routing system to do so is downright trivial and I should sit down and shut up. Erik From owner-multi6@ops.ietf.org Mon Nov 3 11:29: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 LAA09227 for ; Mon, 3 Nov 2003 11:29:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGhZW-0009IG-Ed for multi6-data@psg.com; Mon, 03 Nov 2003 16:28:54 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGhZK-0009Hg-CG for multi6@ops.ietf.org; Mon, 03 Nov 2003 16:28:42 +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 hA3GSb5u018491; Mon, 3 Nov 2003 09:28:37 -0700 (MST) Received: from lillen (vpn-129-156-97-50.EMEA.Sun.COM [129.156.97.50]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA3GSZS15039; Mon, 3 Nov 2003 17:28:35 +0100 (MET) Date: Mon, 3 Nov 2003 17:28:02 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: survivability, rewriting To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , Multi6 Mailing List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I guess that if a host has the M6 mechanism working, it would be reasonable > to assume that the site supports M6 and so that exit routers would rewrite > the source address. How so? If we decide to standardize something which goes in the stack then it will hopefully appear in future versions of various stack implementations asynchonously and hosts with those new versions will appear in an uncoordinated way in various parts of the network. Thus you can't assume that somehow the site network admin is in charge of what OS/stack version is installed on all the hosts in their site. > But anyway you could also use a bit in the router advertisement to > communicate it to the hosts, right? Yes, but you also need a way to get this information into all the routers in the site. If the router renumbering RFC was widely implemented and used it would provide a mechanism on which to add such additional information, but that protocol doesn't seem to be implemented much. My point is that if there are mechanisms which do not require such coordination between the site border routers and the hosts in the site they are preferable (all other things being equal) since this coordination is additional complexity i.e. additional places where things can go wrong. > I don't see why the second part is conflicting with Iljistch goal... It doesn't, which is why I called it "an observation" in the clarification. Erik From owner-multi6@ops.ietf.org Mon Nov 3 11:46: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 LAA09816 for ; Mon, 3 Nov 2003 11:46:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGhpF-000AFP-26 for multi6-data@psg.com; Mon, 03 Nov 2003 16:45:09 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGhp1-000ADf-Rk for multi6@ops.ietf.org; Mon, 03 Nov 2003 16:44:55 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA3GisxA012078 for ; Mon, 3 Nov 2003 08:44:54 -0800 (PST) Received: from lillen (vpn-129-156-97-50.EMEA.Sun.COM [129.156.97.50]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA3GiqS20462 for ; Mon, 3 Nov 2003 17:44:52 +0100 (MET) Date: Mon, 3 Nov 2003 17:44:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: multi6-threats-00.txt vs. MIPv6 - different strength verifications? To: multi6@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Comparing the threats in draft-nordmark-multi6-threats-00.txt and the residual threats in mobile IPv6 there are some interesting differences. These differences are natural in that Tony and I try to based the multi6-threats on the existing IPv4 Internet. One case where MIPv6 is weaker than today's Internet is that an attacker which is on the path for a few seconds can redirect packets for a few minutes. In today's Internet an attacker needs to be on the path all the time in order to be able to redirect packets to some other destination (for instance by spoofing ARP on an Ethernet between two routers). MIPv6 explicitly allows this but does limits the exposure to a few minutes. Trying to compare different multi6 schemes and MIPv6 from a security perspective there seems to be different types of verification going on. In MIPv6 the strongest (which isn't very strong in this case) verification of the identity is that it is reachable at the home address i.e. there isn't a MiTM between the correspondent and the home agent. Once a node has be so verified the resulting redirection to a Care-of-address remain valid for a few minutes and then needs to be renewed. One can envision similar things for multihoming solutions. We can have weak initial verification, for instance the first packet arrived from some identifier/locator pair, and return traffic goes back to the same node. Then we can have strong verification, for instance using the DNS or the CBID property with public key crypto, to verify that the peer indeed "owns" the claimed identifier hence is authorized to specify the locators to use with it. But, based on the MIPv6 model, one could also envision a weak but time limited verification that builds on some earlier verification (whether the earlier verification was weak or strong). For instance, if the peer shows that it knows a clear-text random number which was exchanged during the earlier verification, then it might be reasonable to allow redirection to a new locator *for a limited time*. An on-path attacker could use this, but would have to repeat the attack every few minutes i.e. it is not sufficient for the attacker to "drive by" some link and launch an attack that lasts forever. If the attacker needs to be on the path all the time the residual threat wouldn't be much different than what an on-path attacker could do today. Comments? Erik From owner-multi6@ops.ietf.org Mon Nov 3 11:52: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 LAA10018 for ; Mon, 3 Nov 2003 11:52:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGhvo-000Abd-Ig for multi6-data@psg.com; Mon, 03 Nov 2003 16:51:56 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGhvc-000Ab4-3B for multi6@ops.ietf.org; Mon, 03 Nov 2003 16:51:44 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA3GpXxA015873; Mon, 3 Nov 2003 08:51:34 -0800 (PST) Received: from lillen (vpn-129-156-97-50.EMEA.Sun.COM [129.156.97.50]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA3GpVS21125; Mon, 3 Nov 2003 17:51:31 +0100 (MET) Date: Mon, 3 Nov 2003 17:50:59 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: Iljitsch van Beijnum Cc: mbagnulo@ing.uc3m.es, Multi6 Mailing List In-Reply-To: "Your message with ID" <4B1F3854-0E0A-11D8-A5FC-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Another way to handle this would be to bascially build two networks all > the way down to the host: > > > ISP A ISP B > | | > Router Router > | | > Router Router > \ / > Host > > So the ISP selection happens inside the host, once a network is > selected it is no longer possible to deviate from the path intended by > the host. Isn't that what source address based routing implies conceptually? It can be implemented while sharing the routers as long as the routing table has the entries learned from ISPA as tagged to only apply to packets with a source address from A's prefix and vice versa. Erik From owner-multi6@ops.ietf.org Mon Nov 3 14:23: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 OAA15758 for ; Mon, 3 Nov 2003 14:23:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGkHD-000He1-QS for multi6-data@psg.com; Mon, 03 Nov 2003 19:22:11 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGkGl-000HcU-B0 for multi6@ops.ietf.org; Mon, 03 Nov 2003 19:21:43 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 95155431E2; Mon, 3 Nov 2003 20:21:42 +0100 (CET) Received: from lolo (vpn-252-72.uc3m.es [163.117.252.72]) by smtp02.uc3m.es (Postfix) with SMTP id E17959A039; Mon, 3 Nov 2003 20:21:40 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Mon, 3 Nov 2003 20:15:57 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I guess that if a host has the M6 mechanism working, it would > be reasonable > > to assume that the site supports M6 and so that exit routers > would rewrite > > the source address. > > How so? > If we decide to standardize something which goes in the stack > then it will hopefully appear in future versions of various stack > implementations asynchonously and hosts with those new versions > will appear in > an uncoordinated way in various parts of the network. > Thus you can't assume that somehow the site network admin is > in charge of what OS/stack version is installed on all the hosts > in their site. No, but the mechanism doesn't have to be on by default, i guess. I mean, the same problem would happen if you place host in a single homed site and that you have configured multiple IPs for whatever reason. In this case you don't want that the host starts using M6 mechanism, just becuase it has multiple IPs configured. So M6 is off by default (to ensure compatibility with single homed sites) and it is turned on by the admin, who should do it if the site is multihomed and routers are capable of rewriting packets. > > > But anyway you could also use a bit in the router advertisement to > > communicate it to the hosts, right? > > Yes, but you also need a way to get this information into all the routers > in the site. If the router renumbering RFC was widely implemented and used > it would provide a mechanism on which to add such additional information, > but that protocol doesn't seem to be implemented much. > > My point is that if there are mechanisms which do not require such > coordination between the site border routers and the hosts in the site > they are preferable (all other things being equal) since this coordination > is additional complexity i.e. additional places where things can go wrong. > Agree... So you would need a mechanism to discover that the host is in a multihomed site, right? > > I don't see why the second part is conflicting with Iljistch goal... > > It doesn't, which is why I called it "an observation" in the > clarification. > Ok Regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Mon Nov 3 14:23: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 OAA15777 for ; Mon, 3 Nov 2003 14:23:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGkHV-000Heq-Ky for multi6-data@psg.com; Mon, 03 Nov 2003 19:22:29 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGkGn-000Hcb-7K for multi6@ops.ietf.org; Mon, 03 Nov 2003 19:21:45 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 75603431E6; Mon, 3 Nov 2003 20:21:44 +0100 (CET) Received: from lolo (vpn-252-72.uc3m.es [163.117.252.72]) by smtp02.uc3m.es (Postfix) with SMTP id 395249A039; Mon, 3 Nov 2003 20:21:43 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" , Subject: RE: multi6-threats-00.txt vs. MIPv6 - different strength verifications? Date: Mon, 3 Nov 2003 20:15:59 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > But, based on the MIPv6 model, one could also envision a weak but > time limited > verification that builds on some earlier verification (whether the earlier > verification was weak or strong). > For instance, if the peer shows that it knows a clear-text random number > which was exchanged during the earlier verification, then it > might be reasonable to allow redirection to a new locator *for a > limited time*. The problem here is how to extend the lifetime of the binding after an outage. (using mip terminology) The clear text random number has to be exchanged form both locators the initial one (HoA) and the new one (CoA) Once the outage has occurred, you cannot longer verify the HoA, since it has become unreachable. So the resulting solution only preserved established communications for the *limited time* that the redirection last for. this IMHO is an inherent problem of using IP addresses as identifiers and it due to the fact that the way to prove the ownership is only provided by the routing system( a possible workaround is to use an external authority to secure the binding, such as the DNS), but in the nature of the IP address, the only verifiable characteristic is the routability The other possible workaround would be not to limit in time the binding but limit it by connection, so that checks are performed when a connection is set up, In this case, an attacker can hijack a connection but not a complete IP address (in its identifier role). This would change the scope of permitted attacks from some minutes in the case of MIP to a single connection. Regards, marcelo > An on-path attacker could use this, but would have to repeat the > attack every > few minutes i.e. it is not sufficient for the attacker to "drive by" some > link and launch an attack that lasts forever. > If the attacker needs to be on the path all the time the residual threat > wouldn't be much different than what an on-path attacker could do today. > > Comments? > Erik > > From owner-multi6@ops.ietf.org Mon Nov 3 14:24: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 OAA15793 for ; Mon, 3 Nov 2003 14:24:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGkGx-000Hd2-PB for multi6-data@psg.com; Mon, 03 Nov 2003 19:21:55 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGkGj-000HcF-Ez for multi6@ops.ietf.org; Mon, 03 Nov 2003 19:21:41 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id B1E19431E4; Mon, 3 Nov 2003 20:21:40 +0100 (CET) Received: from lolo (vpn-252-72.uc3m.es [163.117.252.72]) by smtp02.uc3m.es (Postfix) with SMTP id 0935C9A03A; Mon, 3 Nov 2003 20:21:39 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , Subject: RE: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Mon, 3 Nov 2003 20:15:55 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Another possible solution in some scenarios is that the ISP's > ingress filtering > is relaxed to allow all the prefixes assigned to the site. That > might not be > realistic for the low-end services for home users, but it might > be a useful > approach in other cases. Ok, as it is stated in Christian's draft, this will definitely be the case for some sites for it is also certain that for other smaller sites this will not be the case. > > > The question here is whether every multi-homed ISP will be able > to get an > > allocation or it will have to obtain addresses form its > upstream providers, > > right? > > > > Well let's assume that it will obtain addresses from their upstream > > provider. > > Let's asume that ingress filtering will be in place, ok? > > > > Now, how would you deal with this without source address based routing? > > Not doing strict RPF ingress filtering between the ISPs seem to be the > current operational approach for such problems. > > My gut feel currently is that one would need a really strong case > to make the routing system operate on source and destination addresses. > I've yet to see such a strong case. > > But perhaps tweaking the routing system to do so is downright trivial > and I should sit down and shut up. > Well, IMHO source address based routing is a good option for small sites (at least). you can easily implment it is this case, since you can use currenlty available Policy based routing mannually configurated in the (few) routers on the site. For larger sites, this *may* be more difficult, and it also presents additinal difficulties, such as the fact that policing is performed by the hosts (which is seen as a problem by some site admins) (BTW the same admins have claimed that multiaddressing is a problem for them too) So we are again in the situation where one size fits all solution seems more difficult than a per case situation. Some people have expressed that big sites will continue doing multihoming as they do now in IPv4 and that that is ok. Do you think that we should look for different solutions depending on the characteristics of the site? and,do you think that for small sites source address based routing seems to make sense? Regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Tue Nov 4 05:19: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 FAA06953 for ; Tue, 4 Nov 2003 05:19:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGyFw-0006QQ-EM for multi6-data@psg.com; Tue, 04 Nov 2003 10:17:48 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGyFk-0006Pi-Fs for multi6@ops.ietf.org; Tue, 04 Nov 2003 10:17:36 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA4AHUPh020228; Tue, 4 Nov 2003 03:17:30 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA4AHTS15372; Tue, 4 Nov 2003 11:17:29 +0100 (MET) Date: Tue, 4 Nov 2003 11:16:57 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: survivability, rewriting To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , Multi6 Mailing List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > No, but the mechanism doesn't have to be on by default, i guess. > I mean, the same problem would happen if you place host in a single homed > site and that you have configured multiple IPs for whatever reason. > In this case you don't want that the host starts using M6 mechanism, just > becuase it has multiple IPs configured. Why would you have multiple IP addresses configured and you don't want to use them for multihoming? > So M6 is off by default (to ensure compatibility with single homed sites) > and it is turned on by the admin, who should do it if the site is multihomed > and routers are capable of rewriting packets. Why does it have to be off by default? Nothing would break if it is turned on if the hosts use some information from the DNS lookup to determine whether the peer supports multi6. > So you would need a mechanism to discover that the host is in a multihomed > site, right? I haven't seen why this would be required. In fact you want multi6 capable hosts to invoke the multi6 mechanisms because the peer might be multi6 capable. Erik From owner-multi6@ops.ietf.org Tue Nov 4 05:22:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07123 for ; Tue, 4 Nov 2003 05:22:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGyKF-0006gs-3q for multi6-data@psg.com; Tue, 04 Nov 2003 10:22:15 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGyK3-0006fx-9K for multi6@ops.ietf.org; Tue, 04 Nov 2003 10:22:03 +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 hA4ALq5u025298; Tue, 4 Nov 2003 03:21:53 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA4ALpS15858; Tue, 4 Nov 2003 11:21:51 +0100 (MET) Date: Tue, 4 Nov 2003 11:21:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > So we are again in the situation where one size fits all solution seems more > difficult than a per case situation. > Some people have expressed that big sites will continue doing multihoming as > they do now in IPv4 and that that is ok. > Do you think that we should look for different solutions depending on the > characteristics of the site? > and,do you think that for small sites source address based routing seems to > make sense? I actually currently trying to understand what will all be needed to provide flexible source address based routing. For instance, - is there an impact on routing protocols needing to carry additional information? - is there an assumption about who wins when the sender has specified a source address but the routing system knows that sending packets out that ISP doesn't work? is less likely to work than sending it out some other ISP? Once I understand it a bit more maybe I can answer your question whether we need different approaches for different types of sites. Erik From owner-multi6@ops.ietf.org Tue Nov 4 06:03:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08911 for ; Tue, 4 Nov 2003 06:03:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGyxR-0008fL-DT for multi6-data@psg.com; Tue, 04 Nov 2003 11:02:45 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGyx6-0008eo-Jp for multi6@ops.ietf.org; Tue, 04 Nov 2003 11:02:24 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A34A5433C9; Tue, 4 Nov 2003 12:02:23 +0100 (CET) Received: from lolo (unknown [163.117.139.245]) by smtp02.uc3m.es (Postfix) with SMTP id 6A8059A042; Tue, 4 Nov 2003 12:02:23 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , Subject: RE: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Tue, 4 Nov 2003 11:56:40 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I actually currently trying to understand what will all be needed > to provide > flexible source address based routing. For instance, > - is there an impact on routing protocols needing to carry additional > information? Source address based routing needs as many routes as different prefixes it has configured, ok? For example, if a site is dual homed and it has two different prefixes, then the source address based routing system requires two routes. Moreover, these routes have to point to the site exit router corresponding to the ISP that has delegated the prefix. This don't need to be dynamic, since the isp that delegated the prefix doesn't change So i guess that there is no need for special routing protocols to support source address based routing > - is there an assumption about who wins when the sender has specified > a source address but the routing system knows that sending packets > out that ISP doesn't work? is less likely to work than sending it > out some other ISP? > I guess this is what we were discussing when we were considreing the rewrite ok bit. I think that the host should be able to decide if the packet will be routed according the destiantion address (in which case rewriting is probably needed to deal with ingress filtering) or it will be routed based on the source address (in which case no rewriting occurs) I see source address based routing as a mechanism to let the host source address selection act as ISP selection mechanism that overrules the isp selection performed by the routing system. The host then would force the ISP selection in cases when it knows better (ULP hints) or when it knowns it can't use source address rewriting (the other end in not M6 enabled) Regards, marcelo > Once I understand it a bit more maybe I can answer your question whether > we need different approaches for different types of sites. > > Erik > > From owner-multi6@ops.ietf.org Tue Nov 4 06:42: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 GAA10042 for ; Tue, 4 Nov 2003 06:42:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGzXf-000ASK-7V for multi6-data@psg.com; Tue, 04 Nov 2003 11:40:11 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGzXS-000AQr-Gf for multi6@ops.ietf.org; Tue, 04 Nov 2003 11:39:58 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA4BdtPh018212; Tue, 4 Nov 2003 04:39:55 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA4BdsS02314; Tue, 4 Nov 2003 12:39:54 +0100 (MET) Date: Tue, 4 Nov 2003 12:39:22 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: multi6-threats-00.txt vs. MIPv6 - different strength verifications? To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > The problem here is how to extend the lifetime of the binding after an > outage. (using mip terminology) > The clear text random number has to be exchanged form both locators the > initial one (HoA) and the new one (CoA) > Once the outage has occurred, you cannot longer verify the HoA, since it has > become unreachable. > So the resulting solution only preserved established communications for the > *limited time* that the redirection last for. Yes, but this gives you additional time to do a more heavy-weight verification (whether using the DNS or PK for verification). Before a failure is likely to occur it is desirable to have a strong verification for at least one alternate locator for the peer. But if you don't, this weak verification could be used for some time (a few minutes was the number that was picked for MIPv6). > this IMHO is an inherent problem of using IP addresses as identifiers and it > due to the fact that the way to prove the ownership is only provided by the > routing system( a possible workaround is to use an external authority to > secure the binding, such as the DNS), but in the nature of the IP address, > the only verifiable characteristic is the routability That is true for MIPv6. But in multi6 there are approaches like using the DNS or public key CBIDs for a strong verification. > The other possible workaround would be not to limit in time the binding but > limit it by connection, so that checks are performed when a connection is > set up, In this case, an attacker can hijack a connection but not a complete > IP address (in its identifier role). > This would change the scope of permitted attacks from some minutes in the > case of MIP to a single connection. I don't know how that interacts with application assumptions. The fact that some applications, in order to perform some work, creates multiple parallel or sequential transport connections, means that an application might implicitly assume that such connections to the same IP address actually reach the same peer. Then there is the issue when the ULPs notion of "connection" isn't known to the multi6 layer; for example applications layered over UDP. My gut feel is that the time limited weak verification has more predictable behavior than basing things on some notion of ULP "connection". But the point of my note was really that MIPv6 provides an example of another building block that can be considered when looking at performance/security tradeoffs for multi6. Erik From owner-multi6@ops.ietf.org Tue Nov 4 06:47: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 GAA10165 for ; Tue, 4 Nov 2003 06:47:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGzeJ-000AlV-8h for multi6-data@psg.com; Tue, 04 Nov 2003 11:47:03 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AGze6-000Akc-Jt for multi6@ops.ietf.org; Tue, 04 Nov 2003 11:46:51 +0000 Received: (qmail 29597 invoked from network); 4 Nov 2003 11:51:45 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 4 Nov 2003 11:51:45 -0000 Message-ID: <3FA791FE.2090208@necom830.hpcl.titech.ac.jp> Date: Tue, 04 Nov 2003 20:48:14 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Erik Nordmark , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>I actually currently trying to understand what will all be needed >>to provide >>flexible source address based routing. For instance, >> - is there an impact on routing protocols needing to carry additional >> information? > > > Source address based routing needs as many routes as different prefixes it > has configured, ok? > For example, if a site is dual homed and it has two different prefixes, then > the source address based routing system requires two routes. > Moreover, these routes have to point to the site exit router corresponding > to the ISP that has delegated the prefix. And the site exit router is determined by the destination address. > This don't need to be dynamic, since the isp that delegated the prefix > doesn't change Wrong. Source address is not an independent variable. Destination address is. > So i guess that there is no need for special routing protocols to support > source address based routing Yes, of course. We can just use an existing or a new routing protocol to compute the proper source address for a destination address. Masataka Ohta From owner-multi6@ops.ietf.org Tue Nov 4 07:02: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 HAA10810 for ; Tue, 4 Nov 2003 07:02:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGzsa-000BaZ-2i for multi6-data@psg.com; Tue, 04 Nov 2003 12:01:48 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AGzsO-000BZa-0b for multi6@ops.ietf.org; Tue, 04 Nov 2003 12:01:36 +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 hA4C1U5u027884; Tue, 4 Nov 2003 05:01:30 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA4C1TS04198; Tue, 4 Nov 2003 13:01:29 +0100 (MET) Date: Tue, 4 Nov 2003 13:00:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > So i guess that there is no need for special routing protocols to support > source address based routing So you would envision manually installing the rules in each internal router that says "packets with source address prefix X gravitate towards exit router Rx"? Or do you envision internal routers infering this from information already present in the IGP? Or do you envision tunnels between the exit routers to get the packets to the correct exit based on the source address prefix? > I think that the host should be able to decide if the packet will be routed > according the destiantion address (in which case rewriting is probably > needed to deal with ingress filtering) or it will be routed based on the > source address (in which case no rewriting occurs) In the latter case, if the packet arrives at an exit router and the ISP matching the source address is known to be down, should the router just drop the packet? What if there never was a matching or preferred route for the destination address through that ISP? I think when source address based routing is used it is benefitial to also look at the destination address when chosing routes. One question is the details of the relationship between the source based lookup and the destination based lookup. > I see source address based routing as a mechanism to let the host source > address selection act as ISP selection mechanism that overrules the isp > selection performed by the routing system. > The host then would force the ISP selection in cases when it knows better > (ULP hints) or when it knowns it can't use source address rewriting (the > other end in not M6 enabled) But the host will never know better than the routing system because it is operating on aggregated information. What the host might know better than the routing system is that the last N packets sent using a given source and destination didn't result in packets being returned from the peer, thus something might be broken. Thus for the host to tell the routing system "please try sending this packet over a different path than the default one" might be useful. But that is quite different than having the routing system blindly honor the source address for routing lookups. Erik From owner-multi6@ops.ietf.org Tue Nov 4 07:03: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 HAA10832 for ; Tue, 4 Nov 2003 07:03:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AGzta-000BdT-B2 for multi6-data@psg.com; Tue, 04 Nov 2003 12:02:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AGztN-000Bce-AW for multi6@ops.ietf.org; Tue, 04 Nov 2003 12:02:37 +0000 Received: (qmail 29658 invoked from network); 4 Nov 2003 12:07:34 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 4 Nov 2003 12:07:34 -0000 Message-ID: <3FA795B2.7090708@necom830.hpcl.titech.ac.jp> Date: Tue, 04 Nov 2003 21:04:02 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: multi6@ops.ietf.org Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik; > One case where MIPv6 is weaker than today's Internet is that an attacker > which is on the path for a few seconds can redirect packets for a few minutes. One case where MIPv6 is no weaker than today's Internet is that an attacker which is on the path for a few seconds can, by modifying DNS answer, redirect packets for weeks. In addition, an elementary fact on serious security is that once an attack to a system is successful, the system is kept to be contaminated unless the system is fully initialized. That is, > One case where MIPv6 is weaker than today's Internet is that an attacker > which is on the path for a few seconds can redirect packets for a few minutes. > In today's Internet an attacker needs to be on the path all the time in order > to be able to redirect packets to some other destination (for instance > by spoofing ARP on an Ethernet between two routers). > MIPv6 explicitly allows this but does limits the exposure to a few minutes. is not a serious argument on security, at all. However, the argument is even more pointless from the beginning. MIPv6 and M6 share a property that they handle multiple addresses but nothing beyond that. That is, comparison of security of MIPv6 and M6 is nothing more than an abstract nonsense. Masataka Ohta PS Can you discontinue the thread on false threats? From owner-multi6@ops.ietf.org Tue Nov 4 07:36: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 HAA11991 for ; Tue, 4 Nov 2003 07:36:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH0HZ-000Cq9-Qm for multi6-data@psg.com; Tue, 04 Nov 2003 12:27:37 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH0HN-000CpN-4i for multi6@ops.ietf.org; Tue, 04 Nov 2003 12:27:25 +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 hA4CQrUP020875; Tue, 4 Nov 2003 04:26:54 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA4CQrS06223; Tue, 4 Nov 2003 13:26:53 +0100 (MET) Date: Tue, 4 Nov 2003 13:26:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? To: masataka ohta Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3FA795B2.7090708@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > One case where MIPv6 is no weaker than today's Internet is that > an attacker which is on the path for a few seconds can, by modifying > DNS answer, redirect packets for weeks. Correct if the attacker is on the path between the host and the DNS infrastructure. But part of the point is that there is a solution to make DNS more secure. Once that is starting to get deployed it would be nice if we haven't designed a multihoming solution which makes the network less secure again. Erik From owner-multi6@ops.ietf.org Tue Nov 4 07:54: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 HAA12810 for ; Tue, 4 Nov 2003 07:54:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH0fF-000Djm-V2 for multi6-data@psg.com; Tue, 04 Nov 2003 12:52:05 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH0f1-000Dj8-K5 for multi6@ops.ietf.org; Tue, 04 Nov 2003 12:51:51 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA4CT1ed010327; Tue, 4 Nov 2003 13:29:01 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7EC2A402-0EC2-11D8-94BB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: "Multi6 Mailing List" From: Iljitsch van Beijnum Subject: Re: survivability, rewriting Date: Tue, 4 Nov 2003 13:29:12 +0100 To: X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 1 nov 2003, at 20:07, marcelo bagnulo wrote: >> Also, it >> might be beneficial to find out which alternatives still work before >> selecting them to continue the session over. > Ok, but wouldn't this delay the reovery? i.e. the response time would > be > worse That is a possibility, but on the other hand rehoming in the blind also has its risks. For instance, if an upper layer protocol provides too many hints, we could be rehoming when there was just some incidental packet loss. I'm pretty sure rehoming will have to trigger slow start in TCP, which is not something you want to happen if isn't absolutely necessary. Or, in the case of a relatively large number of possible paths, several paths may share some infrastructure and go down at the same time. In that case, checking all paths helps avoid choosing a backup path that is also down. If we indeed go for the ping bomb approach there is the advantage that we immediately see which path is fastest, which is also a good feature and it only takes a single round trip. >> Yes. But I don't think we want to do this with actual data packets. In >> fact, there may not be any data packets available when this is >> triggered by a hint. > I can think of two types of hints: > - a first type where the sending endpoint timeouts, so it detects the > failure by itself. This is the case where ack are used such as tcp. In > this > case the ULP of the endpoint that is sending hints the M6 layer of the > sending endpoint (this is the easy case, i guess) > - a second type where no ack are used, so the ones that detects the > failure > is the receiving end who detects the failure because it no longer > receives > packets at the expected rate. In this case, the receiving end has to > communicate the problem to the sending endpoint. So in this case, the > ULP of > the receiving endpoint has to hint the M6 layer of the sending > endpoint. Hm, doesn't the other side determine that something is wrong because it doesn't see any acks? If the ULP supports nacks then the receiving end can send those to get the message across sooner. > Does thus makes sense? can you think of other scenarios? Another possibility would be that a receiver sees consistent duplicate packets, which indicates that the acks aren't getting back to the sender. We may also want to trigger re-evaluation of reachability in some other cases. For instance, when a session has been idle for a long time, or upon some kind of hardware or routing event. > Then in the first case, the sending enpoint always has packets, since > it has > detected the failure because of retransmissions, i guess. So, why > don't you > think it should not try every possible path with data packets? Might be an implementation issue. Might not be a problem, though. > In the second case, in order to discover which path is working, you > will > need a message exchange, since probably there will be no packets back > from > the receiving endpoint to the sending endpoint that allow the sending > endpoint to find out which is the combination of source and destination > address that it is actually working. So i guess that in this case, it > would > make sense to have a protocol in the M6 layer to perform the available > path > discovery. Yes. >> BGP is a non-starter as there can always be failures that don't show >> up >> in BGP because of aggregation. > IMHO BGP is too slow, as we already agreed, but i am not uderstanding > your > point about the aggregation. > I do understand it when you use bgp from the sending endpoint, so you > cannot > see if the target endpoint is really reachable because aggregation > hides it > from you. Right, that was my point. > But if you use BGP plus rewriting as Erik suggests, then aggregation > is not > a problem, because you use bgp as a mean to discover the available > path, not > to see which address you should use. Ah, I see: the host selects a destination address, then the router uses BGP to determine which ISP would be the best one to use to reach this address. Yes, this makes sense. However, there are two problems that are somewhat related to this: 1. the source address may be incompatible with the exit ISP 2. the destination address may be unreachable The first can be fixed by rewriting. The second must be handled by the host. But if the host must handle selecting a destination address anyway, why not slightly extend this capability and let the host select a source/destination combo? Assume hosts X and Y, X has ISPs A and B, Y has C and D and R means "rewriting allowed". Assume BGP prefers path X->A->C->Y and X->B->E->F->D->Y. 1 = routers with no special capabilities 2 = routers support source address based routing but not rewriting 3 = routers support source address based routing and also rewriting 1 2 3 X(A)->Y(C): + + + X(A)->Y(D): - + + X(B)->Y(C): - + + X(B)->Y(D): + + + X(R)->Y(C): - - + X(R)->Y(D): - - + I think it's pretty clear that situation 1 is very sub-optimal but the added value of the rewriting feature is quationable. In situation 2 all the paths that are available in situation 3 are also available, it just may take a little longer to find the best one. > I was suggesting using a routing header to allow the host to force the > exit > ISP i.e. as an alternative to the source address based routing That wouldn't work, as "legacy" IPv6 hosts would have to insert such a header in order to function in a multihomed site. Iljitsch From owner-multi6@ops.ietf.org Tue Nov 4 08:19:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13508 for ; Tue, 4 Nov 2003 08:19:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH14V-000F6d-Bx for multi6-data@psg.com; Tue, 04 Nov 2003 13:18:11 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH14A-000F5J-Lu for multi6@ops.ietf.org; Tue, 04 Nov 2003 13:17:51 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA4DHbed010872; Tue, 4 Nov 2003 14:17:37 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48C27965-0EC9-11D8-94BB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? Date: Tue, 4 Nov 2003 14:17:47 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3 nov 2003, at 17:44, Erik Nordmark wrote: > But, based on the MIPv6 model, one could also envision a weak but time > limited > verification that builds on some earlier verification (whether the > earlier > verification was weak or strong). No, this is no good at all. In multihoming, when a line goes down it may not come back up again. Ever. > For instance, if the peer shows that it knows a clear-text random > number > which was exchanged during the earlier verification, then it > might be reasonable to allow redirection to a new locator *for a > limited time*. This is susceptible to a "man listening at the sidelines" attack. That's a relatively common capability. However, we can do better than this with by adding some hashing and gradual release of previously secret information. This is only susceptible to actual man in the middle attacks, but then so is everything else, as a MITM can always blackhole traffic if nothing else. From owner-multi6@ops.ietf.org Tue Nov 4 08:23: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 IAA13588 for ; Tue, 4 Nov 2003 08:23:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH18t-000FNa-HB for multi6-data@psg.com; Tue, 04 Nov 2003 13:22:43 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH18h-000FMl-Dm for multi6@ops.ietf.org; Tue, 04 Nov 2003 13:22:31 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA4DMHed010938; Tue, 4 Nov 2003 14:22:18 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: mbagnulo@ing.uc3m.es, Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Tue, 4 Nov 2003 14:22:28 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3 nov 2003, at 17:50, Erik Nordmark wrote: >> Another way to handle this would be to bascially build two networks >> all >> the way down to the host: >> ISP A ISP B >> | | >> Router Router >> | | >> Router Router >> \ / >> Host >> So the ISP selection happens inside the host, once a network is >> selected it is no longer possible to deviate from the path intended by >> the host. > Isn't that what source address based routing implies conceptually? I suppose. But the important thing here is that only the host needs to have the SABR capability, in this picture the routers must do it: ISP A ISP B | | Router Router \ / Router | Host > It can be implemented while sharing the routers as long as the routing > table has the entries learned from ISPA as tagged to only apply to > packets > with a source address from A's prefix and vice versa. In essence we'd be doing type of service routing here, but rather than use different types of service we use different source prefixes. But as discussed before, simply bypassing normal routing and forward based on the source prefix exclusively is simpler. From owner-multi6@ops.ietf.org Tue Nov 4 08:30: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 IAA13797 for ; Tue, 4 Nov 2003 08:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH1Fv-000Frz-ON for multi6-data@psg.com; Tue, 04 Nov 2003 13:29:59 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH1FL-000FpW-Tw for multi6@ops.ietf.org; Tue, 04 Nov 2003 13:29:23 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA4DTGPh028712; Tue, 4 Nov 2003 06:29:17 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA4DTFS17325; Tue, 4 Nov 2003 14:29:15 +0100 (MET) Date: Tue, 4 Nov 2003 14:28:42 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <48C27965-0EC9-11D8-94BB-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > No, this is no good at all. In multihoming, when a line goes down it > may not come back up again. Ever. Yes, but a weak verification can be converted to a strong verification at any time by invoking the strong verification mechanism (be it DNS or CBID-based). > This is susceptible to a "man listening at the sidelines" attack. You mean somebody which is on the path and can see the content of packets, but is unable to prevent packets from being deliverd on the correct path? > That's a relatively common capability. Do you have examples where seeing the content of packets is possible or significanty easier than also being able to supressing the delivery of packets or modifying the packets? > However, we can do better than > this with by adding some hashing and gradual release of previously > secret information. This is only susceptible to actual man in the > middle attacks, but then so is everything else, as a MITM can always > blackhole traffic if nothing else. Good point. One can do a limited length hash chain and reveal it in reverse reverse order as an improvement. If the chains are short enough (length 10?) the cost of creating them might not be that significant; just run MD5 (or SHA1) 10 times. Should the chain run out, then one can fallback to the stronger verification. Erik From owner-multi6@ops.ietf.org Tue Nov 4 08:37: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 IAA14105 for ; Tue, 4 Nov 2003 08:37:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH1Mo-000GL4-8i for multi6-data@psg.com; Tue, 04 Nov 2003 13:37:06 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH1Ma-000GJP-Sy for multi6@ops.ietf.org; Tue, 04 Nov 2003 13:36:53 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA4Daded011127; Tue, 4 Nov 2003 14:36:39 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Tue, 4 Nov 2003 14:36:49 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 4 nov 2003, at 13:00, Erik Nordmark wrote: > But the host will never know better than the routing system because it > is operating on aggregated information. The host??? No, hosts only know about individual correspondent addresses, they don't aggregate under normal circumstances. > What the host might know better than the routing system is that the > last N packets sent using a given source and destination didn't result > in packets being returned from the peer, thus something might be > broken. > Thus for the host to tell the routing system "please try sending this > packet > over a different path than the default one" might be useful. But that > is quite > different than having the routing system blindly honor the source > address > for routing lookups. So when we finally find that unused field in the IPv6 header (should have stuck to v4, there we can steal identification if DF is set which it nearly always is) we can use this field to say "I didn't care much for the connectivity provided by your previous routing decisions, please try something else". This field would be an index for finding the preferred route among the ones available. So if the packets don't make it using the best route (as determined by the router), the host increases the value of the field and the second best route is selected. Hm, one way to do this would be to manipulate the hop limit field. Under normal circumstances, the hop limit a router sees in packets from hosts in the local network should be very consistent. The host could raise or lower the initial value for the hop limit to get the router to change its behavior. From owner-multi6@ops.ietf.org Tue Nov 4 08:43: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 IAA14384 for ; Tue, 4 Nov 2003 08:43:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH1SV-000GnC-G1 for multi6-data@psg.com; Tue, 04 Nov 2003 13:42:59 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH1SI-000GmG-Rq for multi6@ops.ietf.org; Tue, 04 Nov 2003 13:42:47 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA4DgYed011185; Tue, 4 Nov 2003 14:42:34 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? Date: Tue, 4 Nov 2003 14:42:44 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 4 nov 2003, at 14:28, Erik Nordmark wrote: >> No, this is no good at all. In multihoming, when a line goes down it >> may not come back up again. Ever. > Yes, but a weak verification can be converted to a strong verification > at any time by invoking the strong verification mechanism (be it DNS > or CBID-based). Why not go for the strong stuff immediately? >> This is susceptible to a "man listening at the sidelines" attack. > You mean somebody which is on the path and can see the content of > packets, but > is unable to prevent packets from being deliverd on the correct path? Yes. >> That's a relatively common capability. > Do you have examples where seeing the content of packets is possible or > significanty easier than also being able to supressing the delivery of > packets or modifying the packets? Wireless networks are a good example. Many switches provide monitoring capabilities and fibers are not that hard to sniff. So someone with physical access can look at the traffic with relative ease. However, in order to block selected packets the attacker needs to redirect traffic or install equipment in the middle. I suppose that's doable on wireless lans but not so much when tapping into existing monitoring capabilities. >> However, we can do better than >> this with by adding some hashing and gradual release of previously >> secret information. This is only susceptible to actual man in the >> middle attacks, but then so is everything else, as a MITM can always >> blackhole traffic if nothing else. > Good point. > One can do a limited length hash chain and reveal it in reverse > reverse order as an improvement. If the chains are short enough > (length 10?) > the cost of creating them might not be that significant; just run MD5 > (or SHA1) > 10 times. Should the chain run out, then one can fallback to the > stronger > verification. Or use the last step to authenticate a new one. From owner-multi6@ops.ietf.org Tue Nov 4 08:44: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 IAA14462 for ; Tue, 4 Nov 2003 08:44:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH1Sy-000God-Kq for multi6-data@psg.com; Tue, 04 Nov 2003 13:43:28 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH1Sm-000Go7-H3 for multi6@ops.ietf.org; Tue, 04 Nov 2003 13:43:16 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C11AB4314C; Tue, 4 Nov 2003 14:43:15 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp02.uc3m.es (Postfix) with SMTP id 680919A03A; Tue, 4 Nov 2003 14:43:15 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" , "masataka ohta" Cc: Subject: RE: multi6-threats-00.txt vs. MIPv6 - different strength verifications? Date: Tue, 4 Nov 2003 14:37:31 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > But part of the point is that there is a solution to make DNS more secure. > Once that is starting to get deployed it would be nice if we haven't > designed a multihoming solution which makes the network less secure again. Fully agree besides not all of the communications actually use the DNS, you can establish a communication direclty using IP addresses. Regards, marcelo > > Erik > > From owner-multi6@ops.ietf.org Tue Nov 4 09:05: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 JAA15157 for ; Tue, 4 Nov 2003 09:05:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH1mQ-000I9h-O5 for multi6-data@psg.com; Tue, 04 Nov 2003 14:03:34 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH1mE-000I93-AJ for multi6@ops.ietf.org; Tue, 04 Nov 2003 14:03:22 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 88C76433E3; Tue, 4 Nov 2003 15:03:21 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp02.uc3m.es (Postfix) with SMTP id 54E5C9A03F; Tue, 4 Nov 2003 15:03:21 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: Subject: RE: multi6-threats-00.txt vs. MIPv6 - different strength verifications? Date: Tue, 4 Nov 2003 14:57:37 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Yes, but this gives you additional time to do a more heavy-weight > verification > (whether using the DNS or PK for verification). Ok, agree that this is an option, but it is an expensive option, i guess. You will have to echange packets periodically (HoTI/HoT CoTI/CoT like exchange) to always have valid authorization information available (if authorization information lifetime is long you expose the host to more dangerous attacks) So, i guess that we would better off if we don't use such a mechanism (if we can) and we just use the strong one. But i agree that we should keep it in mind as a last resourse [....] > > The other possible workaround would be not to limit in time the > binding but > > limit it by connection, so that checks are performed when a > connection is > > set up, In this case, an attacker can hijack a connection but > not a complete > > IP address (in its identifier role). > > This would change the scope of permitted attacks from some > minutes in the > > case of MIP to a single connection. > > I don't know how that interacts with application assumptions. > The fact that some applications, in order to perform some work, > creates multiple parallel or sequential transport connections, > means that an application might implicitly assume that such connections to > the same IP address actually reach the same peer. > Then there is the issue when the ULPs notion of "connection" > isn't known to > the multi6 layer; for example applications layered over UDP. Well we could generate an ephemeral AID so that the every app has a different AID. So we can distinguish every communication using its AID. The other option is not to do it at the M6 layer, but do it at the TCP layer > > My gut feel is that the time limited weak verification has more > predictable > behavior than basing things on some notion of ULP "connection". > Yes, i may agree with that. But the time limited option has a very important drawback: it is time limited :-) So it can be used as a bridge solution while you verify the binding with stronger methods, as you mention, but not for much more than that. The connection oriented solution can be used without any additional strong mechanism Regards, marcelo > But the point of my note was really that MIPv6 provides an example of > another building block that can be considered when looking > at performance/security tradeoffs for multi6. > > Erik > > From owner-multi6@ops.ietf.org Tue Nov 4 09:14: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 JAA15340 for ; Tue, 4 Nov 2003 09:14:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH1wD-000IjH-Vx for multi6-data@psg.com; Tue, 04 Nov 2003 14:13:41 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH1w2-000IiS-8L for multi6@ops.ietf.org; Tue, 04 Nov 2003 14:13:30 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 35283434B0; Tue, 4 Nov 2003 15:13:29 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp02.uc3m.es (Postfix) with SMTP id BD01F9A03A; Tue, 4 Nov 2003 15:13:24 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , "Erik Nordmark" Cc: Subject: RE: multi6-threats-00.txt vs. MIPv6 - different strength verifications? Date: Tue, 4 Nov 2003 15:07:41 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Or use the last step to authenticate a new one. > I don't see how could you do this, since the path to the initial address is down, so you cannot exchange information using this address. Am i missing something? Regards, marcelo > From owner-multi6@ops.ietf.org Tue Nov 4 09:34: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 JAA15909 for ; Tue, 4 Nov 2003 09:34:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH2Fd-000Jtt-Tj for multi6-data@psg.com; Tue, 04 Nov 2003 14:33:45 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH2FQ-000JtD-Ds for multi6@ops.ietf.org; Tue, 04 Nov 2003 14:33:32 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9A200434BA; Tue, 4 Nov 2003 15:33:31 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp02.uc3m.es (Postfix) with SMTP id 59BE39A03C; Tue, 4 Nov 2003 15:33:31 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , Subject: RE: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Date: Tue, 4 Nov 2003 15:27:47 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So you would envision manually installing the rules in each > internal router > that says "packets with source address prefix X gravitate towards exit > router Rx"? That was my initial idea, yes Note that this is not a dynamic information, since it only changes when the site changes ISP or when the ISP renumbers, and both events shouldn't be very frequent (at least not so frequent to demand a dynamic protocol) > Or do you envision internal routers infering this from information already > present in the IGP? No > Or do you envision tunnels between the exit routers to get the packets > to the correct exit based on the source address prefix? > Actually this is an alternative to source address based routing, but i find it not very optimal, since it implies MTU reduction and sub optimal routing > > I think that the host should be able to decide if the packet > will be routed > > according the destiantion address (in which case rewriting is probably > > needed to deal with ingress filtering) or it will be routed based on the > > source address (in which case no rewriting occurs) > > In the latter case, if the packet arrives at an exit router and > the ISP matching the source address is known to be down, should the router > just drop the packet? Well if a router don't have a route to route a packet, it should discard it but that case would depend on the behaviour of the host, let's see this below... [...] > But the host will never know better than the routing system because it > is operating on aggregated information. Don't understand this... The routing system is the one who works with aggregated information implying information loss. The host deals with no aggregated host information > What the host might know better than the routing system is that the > last N packets sent using a given source and destination didn't result > in packets being returned from the peer, thus something might be > broken. > Well, there are different approaches, here... For instance when the host receives such an information it could just try with all the source destiantion address cobination available for that communication, and see which one returns faster. Such approach would not only provide detection of available path but also some idea of the faster path. Clearly it may be expensive The other option would be just to change both source and destiantion address and see what happens and if it doesn't work try another combiantion. The problem here is response time. > Thus for the host to tell the routing system "please try sending > this packet > over a different path than the default one" might be useful. This may work... ( i mean i don't see any reasons why not :-) And what would be the benefits of such approach in wrt source address based routing? This feature is clearly not available in routers today, it requires a bit to inform it to the routers and also that it would ony be usefull to deal with M6 capable communications. We still have to provide some way to provide ingress filtering compatibility for non M6 capable communications. The benefit of source address based routing is that it also addresses both situations (or kind of) Regrds, marcelo But > that is quite > different than having the routing system blindly honor the source address > for routing lookups. > > Erik > > From owner-multi6@ops.ietf.org Tue Nov 4 10:05: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 KAA16907 for ; Tue, 4 Nov 2003 10:05:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH2in-000LSa-IM for multi6-data@psg.com; Tue, 04 Nov 2003 15:03:53 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH2iZ-000LRd-FP for multi6@ops.ietf.org; Tue, 04 Nov 2003 15:03:39 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A7C09434C1; Tue, 4 Nov 2003 16:03:38 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.245]) by smtp02.uc3m.es (Postfix) with SMTP id 964EA9A043; Tue, 4 Nov 2003 16:03:38 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Tue, 4 Nov 2003 15:57:54 +0100 Message-ID: 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: <7EC2A402-0EC2-11D8-94BB-00039388672E@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > That is a possibility, but on the other hand rehoming in the blind also > has its risks. For instance, if an upper layer protocol provides too > many hints, we could be rehoming when there was just some incidental > packet loss. I'm pretty sure rehoming will have to trigger slow start > in TCP, which is not something you want to happen if isn't absolutely > necessary. Or, in the case of a relatively large number of possible > paths, several paths may share some infrastructure and go down at the > same time. In that case, checking all paths helps avoid choosing a > backup path that is also down. If we indeed go for the ping bomb > approach there is the advantage that we immediately see which path is > fastest, which is also a good feature and it only takes a single round > trip. Agree. My question is why don't just send a replicated data packet instead of pings? I mean, i have a hint that something is wrong, so if i have data packet available, i send it replicated as many times as possible source dest address combinations i have available. > > >> Yes. But I don't think we want to do this with actual data packets. In > >> fact, there may not be any data packets available when this is > >> triggered by a hint. > > > I can think of two types of hints: > > - a first type where the sending endpoint timeouts, so it detects the > > failure by itself. This is the case where ack are used such as tcp. In > > this > > case the ULP of the endpoint that is sending hints the M6 layer of the > > sending endpoint (this is the easy case, i guess) > > > - a second type where no ack are used, so the ones that detects the > > failure > > is the receiving end who detects the failure because it no longer > > receives > > packets at the expected rate. In this case, the receiving end has to > > communicate the problem to the sending endpoint. So in this case, the > > ULP of > > the receiving endpoint has to hint the M6 layer of the sending > > endpoint. > > Hm, doesn't the other side determine that something is wrong because it > doesn't see any acks? I am supposing a communication that don't use acks, data streaming and the like. > If the ULP supports nacks then the receiving end > can send those to get the message across sooner. > I am considering a communication that don't use nack neither, just one way stream. > > Does thus makes sense? can you think of other scenarios? > > Another possibility would be that a receiver sees consistent duplicate > packets, which indicates that the acks aren't getting back to the > sender. > > We may also want to trigger re-evaluation of reachability in some other > cases. For instance, when a session has been idle for a long time, or > upon some kind of hardware or routing event. Ok > > > Then in the first case, the sending enpoint always has packets, since > > it has > > detected the failure because of retransmissions, i guess. So, why > > don't you > > think it should not try every possible path with data packets? > > Might be an implementation issue. Might not be a problem, though. > > > In the second case, in order to discover which path is working, you > > will > > need a message exchange, since probably there will be no packets back > > from > > the receiving endpoint to the sending endpoint that allow the sending > > endpoint to find out which is the combination of source and destination > > address that it is actually working. So i guess that in this case, it > > would > > make sense to have a protocol in the M6 layer to perform the available > > path > > discovery. > > Yes. > > >> BGP is a non-starter as there can always be failures that don't show > >> up > >> in BGP because of aggregation. > > > IMHO BGP is too slow, as we already agreed, but i am not uderstanding > > your > > point about the aggregation. > > > I do understand it when you use bgp from the sending endpoint, so you > > cannot > > see if the target endpoint is really reachable because aggregation > > hides it > > from you. > > Right, that was my point. > > > But if you use BGP plus rewriting as Erik suggests, then aggregation > > is not > > a problem, because you use bgp as a mean to discover the available > > path, not > > to see which address you should use. > > Ah, I see: the host selects a destination address, then the router uses > BGP to determine which ISP would be the best one to use to reach this > address. Yes, this makes sense. However, there are two problems that > are somewhat related to this: > > 1. the source address may be incompatible with the exit ISP > 2. the destination address may be unreachable > > The first can be fixed by rewriting. The second must be handled by the > host. But if the host must handle selecting a destination address > anyway, why not slightly extend this capability and let the host select > a source/destination combo? > You don't have to convince me :-) > Assume hosts X and Y, X has ISPs A and B, Y has C and D and R means > "rewriting allowed". Assume BGP prefers path X->A->C->Y and > X->B->E->F->D->Y. > > 1 = routers with no special capabilities > 2 = routers support source address based routing but not rewriting > 3 = routers support source address based routing and also rewriting > > 1 2 3 > X(A)->Y(C): + + + > X(A)->Y(D): - + + > X(B)->Y(C): - + + > X(B)->Y(D): + + + > X(R)->Y(C): - - + > X(R)->Y(D): - - + > I guess that X(A)-> Y(C) means that you are using as as source address the address of X containing the prefix delegated from ISPA and as destination address the address of Y with prefix delegated by ISPC, right? and, what do you mean by + and -? > I think it's pretty clear that situation 1 is very sub-optimal but the > added value of the rewriting feature is quationable. In situation 2 all > the paths that are available in situation 3 are also available, it just > may take a little longer to find the best one. > > > I was suggesting using a routing header to allow the host to force the > > exit > > ISP i.e. as an alternative to the source address based routing > > That wouldn't work, as "legacy" IPv6 hosts would have to insert such a > header in order to function in a multihomed site. > Well, if we restrict ourselves only to legacy IPv6 host compatible mechanisms, i guess that the only options is some form of source address based routing (whether in all the site or only in the exit routers), which is fine by me :-) More seriously, i think that this is a relevant point to evaluate different approaches: Different approaches to deal with ingress filtering can be compatible with legacy internal hoats and legacy external hosts. Source address rewriting is not compatible with none of them i.e. you need modification in both ends to support it, so you need an additional mechanism to deal with ingress filtering in those cases. Source address based routing is compatible with both internal and external legacy hosts A routing header, as you note, is compatible with external legacy hosts but not with internal legacy hosts Regards, marcelo > Iljitsch > > From owner-multi6@ops.ietf.org Tue Nov 4 11:10:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20600 for ; Tue, 4 Nov 2003 11:10:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH3ju-0000DC-6D for multi6-data@psg.com; Tue, 04 Nov 2003 16:09:06 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AH3jQ-0000Am-F3 for multi6@ops.ietf.org; Tue, 04 Nov 2003 16:08:36 +0000 Received: (qmail 30638 invoked from network); 4 Nov 2003 16:13:35 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 4 Nov 2003 16:13:35 -0000 Message-ID: <3FA7CF59.9080004@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Nov 2003 01:10:01 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: multi6@ops.ietf.org Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik; >>One case where MIPv6 is no weaker than today's Internet is that >>an attacker which is on the path for a few seconds can, by modifying >>DNS answer, redirect packets for weeks. > > > Correct if the attacker is on the path between the host and the DNS > infrastructure. > > But part of the point is that Your point is that you said "today's Internet". > there is a solution to make DNS more secure. If you are talking about secure DNS, it was proposed even before IPv6 and still is not deployed at all. And, there are reasons why it is not deployed. In short, it is useless. But, your argument is broken in other ways, too. So, let's assume that we were talking about an imaginary IP network where secure DNS were deployed and a pair of hosts were actually using it for their forward and reverse domains. > Once that is starting to get deployed it would be nice if we haven't > designed a multihoming solution which makes the network less secure again. Then, there is no reason to make some part of address of a host a hash of host's public key, as the host can simply put its full public key in DNS. Then, the pair of hosts can and will exchange a session key with which the communication, including parts for multihoming control, is secured. Still, you may argue that DoS of telling wrong locators should be possible. But, you are wrong because MITM can issue as much DoS as he wants regardless of security mechanism used. DoS by MITM, agaist which cookies does not work, is fatally efficient, if public key (that is, *EXPENSIVE*) cryptography is used. Finally, as a set of locators of a host can be securely obtained from secure DNS that there is no need to dynamically authenticate the set, which is the fundamental difference between MIPv6 and M6. That is, comparison to MIPv6 has been pointless, from the beginning both on the today's Internet and the imaginary IP network. Masataka Ohta From owner-multi6@ops.ietf.org Tue Nov 4 11:19: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 LAA21077 for ; Tue, 4 Nov 2003 11:19:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH3tj-0000wS-HV for multi6-data@psg.com; Tue, 04 Nov 2003 16:19:15 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AH3tW-0000uz-MZ for multi6@ops.ietf.org; Tue, 04 Nov 2003 16:19:02 +0000 Received: (qmail 30673 invoked from network); 4 Nov 2003 16:24:03 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 4 Nov 2003 16:24:03 -0000 Message-ID: <3FA7D1CC.5060204@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Nov 2003 01:20:28 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Erik Nordmark , multi6@ops.ietf.org Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> Do you have examples where seeing the content of packets is possible or >> significanty easier than also being able to supressing the delivery of >> packets or modifying the packets? > > > Wireless networks are a good example. Many switches provide monitoring > capabilities and fibers are not that hard to sniff. So someone with > physical access can look at the traffic with relative ease. However, in > order to block selected packets the attacker needs to redirect traffic > or install equipment in the middle. I suppose that's doable on wireless > lans but not so much when tapping into existing monitoring capabilities. An elementary fact on security is that DoS is so easy. In this case, attackers block all the packets and relay almost all the packets (except for a few selected packets) by themselves copying everything include MAC addresses, which hides the attack from monitoring, which is easy both on wireless and wired lans. Masataka Ohta From owner-multi6@ops.ietf.org Tue Nov 4 15:32: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 PAA04071 for ; Tue, 4 Nov 2003 15:32:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AH7p6-000HNZ-77 for multi6-data@psg.com; Tue, 04 Nov 2003 20:30:44 +0000 Received: from [62.44.180.103] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AH7os-000HM1-HH for multi6@ops.ietf.org; Tue, 04 Nov 2003 20:30:30 +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 hA4KTwVc001114; Tue, 4 Nov 2003 21:29:59 +0100 (CET) Date: Tue, 4 Nov 2003 20:37:37 +0100 Subject: Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Erik Nordmark" , , To: From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <5897CAF8-0EFE-11D8-8572-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On torsdag, okt 30, 2003, at 15:56 Europe/Stockholm, marcelo bagnulo wrote: > Kurtis wrote: > >> Isn't this simply expectation management? The reason we changed the >> requirements into goals was because the items in the document where >> either contradictory; we realized that we couldn't get it all so make >> it all requirements wasn't an option; and we couldn't decide on what >> issues where needed more than others; ? >> > > Well i am not sure this the case of session survivability, at least > right > now. I mean, i don't think that providing transport session > survivability is > contradictory with another of the requirements, it is just that > providing it > is expensive. So we are back to what is the definition of "having survived"? How long is reasonable before a session times out? This has been discussed in several other discussions such as site-local as well. There is no easy answer. >> I think that connection survivability is a nice to have, > > IMHO is more than that. It is the main problem that we have. > I mean, all other aspects of multihoming are simpler to solve than > this one > i guess. Again. Depends on the timeout value. > The preservation of established sessions is the only requirements that > its > support imposes modifications of both sites of the communication. this > implies that hosts *outside* the multihomed site will need to be > upgraded in > order to support this feature of the multi-homing solution. This is > IMHO a > great effort with a really important cost. This cost is justified only > if it > is an important feature, i guess. Agreed. Note that "nice to have" is not the same as "shouldn't have". I agree that it is a really important criteria, but it's not THE criteria. > If session preservation is a nce to have feature, we could just don't > provide it and provide a multi-homing solution that only imposes > modifications to the multi-homed site. We could. But if we can, we should address it. I am trying introduce a gray scale here... > So the approach that is proposed would be: > The general M6 layer provides a general service, for instance based in > current bgp response times Ok, that is a good definition of my gray scale..:-) > Also, the M6 accepts hints from modified ULP that have more demanding > requirements. This would enable that if an ULP is capable of detecting > outages more quickly than the generic M6 layer it can signal it to the > M6 > layer so that it can react somehow Ok, I am still worried over this hints thing... >> More, if there is also a rerouting event causing >> distribution of bad news, and perhaps a new set of locators, or the >> signaling to move to new locators, this might trigger a "race-like" >> condition, depending in what order the priorities are set and in which >> order they arrive where, and then actually making the case worse - no? > > I guess that we should try to see if it is possible to design a > solution > that a avoids that. Oh, I think it is. I just think we need to keep that in mind. >> >> "restoration" time is due to these X factors, they can be influenced >> by >> this - but they are not an issue per se for the multi6 layer. > > Yes, but IMHO we should define those potential hints and also define > the > interaction among them. Do you agree? Yes. But I am not convinced that is where we should start. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6gABaarNKXTPFCVEQKBZQCeMxHeEwp8hzcmnrq2eeRr5y/FAwUAoJUY 9FP++DhY6Wznp/tjLx3jewye =3zeS -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Nov 4 23:42: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 XAA23142 for ; Tue, 4 Nov 2003 23:42:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHFU3-000EpA-Vk for multi6-data@psg.com; Wed, 05 Nov 2003 04:41:31 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHFTr-000EoQ-Io for multi6@ops.ietf.org; Wed, 05 Nov 2003 04:41:19 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc11) with SMTP id <20031105044118013007ifche> (Authid: sdawkins@comcast.net); Wed, 5 Nov 2003 04:41:18 +0000 Message-ID: <118701c3a357$219f8310$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6 Mailing List" References: <7EC2A402-0EC2-11D8-94BB-00039388672E@muada.com> Subject: Re: survivability, rewriting Date: Tue, 4 Nov 2003 22:41:50 -0600 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a minor comment: ----- Original Message ----- From: "Iljitsch van Beijnum" To: Cc: "Multi6 Mailing List" Sent: Tuesday, November 04, 2003 6:29 AM Subject: Re: survivability, rewriting > > That is a possibility, but on the other hand rehoming in the blind also > has its risks. For instance, if an upper layer protocol provides too > many hints, we could be rehoming when there was just some incidental > packet loss. I'm pretty sure rehoming will have to trigger slow start > in TCP, which is not something you want to happen if isn't absolutely > necessary. In some unrelated conversations in TRIGTRAN, we were saying that Slow Start is conceptually the right thing to do for path changes, but Slow Start works fine if you lose something - why not wait to see what you lose, and only Slow Start if you need to? If you lose packets during rehoming, you'll fast retransmit/fast recover at a minimum, so it's not like you're switching paths at the same sending rate. But this is probably a good TSVWG question. Spencer From owner-multi6@ops.ietf.org Wed Nov 5 05:08: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 FAA29044 for ; Wed, 5 Nov 2003 05:08:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHKYJ-0002mo-2p for multi6-data@psg.com; Wed, 05 Nov 2003 10:06:15 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHKY7-0002m7-5O for multi6@ops.ietf.org; Wed, 05 Nov 2003 10:06:03 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA5A5pxA009791; Wed, 5 Nov 2003 02:05:51 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA5A5oS21408; Wed, 5 Nov 2003 11:05:50 +0100 (MET) Date: Wed, 5 Nov 2003 11:05:15 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: survivability, rewriting To: mbagnulo@ing.uc3m.es Cc: Iljitsch van Beijnum , Multi6 Mailing List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > My question is why don't just send a replicated data packet instead of > pings? > I mean, i have a hint that something is wrong, so if i have data packet > available, i send it replicated as many times as possible source dest > address combinations i have available. That can work as long as you can tell from the returned packets which of the replicated data packets made it. I think this is hard. If you take a ULP packet and send it with different src/dst locators and then after one RTT there is a response (a ULP ack for instance) how can you tell which of the src/dst locator pairs worked? The scheme does work when the ULP has been designed with this in mind as in SCTP, but for other ULPs I think you need to add something akin to the icmp echo sequence number that would be returned in the responses. It might be easier to just use separate packets for the "pings". Erik From owner-multi6@ops.ietf.org Wed Nov 5 05:20: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 FAA29408 for ; Wed, 5 Nov 2003 05:20:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHKlP-0003U9-Pf for multi6-data@psg.com; Wed, 05 Nov 2003 10:19:47 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHKlD-0003T0-E2 for multi6@ops.ietf.org; Wed, 05 Nov 2003 10:19:35 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA5AJQxA014230; Wed, 5 Nov 2003 02:19:27 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA5AJQS22844; Wed, 5 Nov 2003 11:19:26 +0100 (MET) Date: Wed, 5 Nov 2003 11:18:50 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Yes, but a weak verification can be converted to a strong verification > > at any time by invoking the strong verification mechanism (be it DNS > > or CBID-based). > > Why not go for the strong stuff immediately? Because it is likely to be more expensive; for CBID schemes you'd need a public key challenge response (signing by the peer, verification at your end) and for DNS schemes like NOID you'd need at least a reverse lookup of the new locator. If the new locator is from a revious unused ISP DNS cachaes might not help and if DNSsec is used this implies verifying at least 3 (or it is 6 with delegation signer?) since there are likely to be 3 new delegations to find the previously unused ip6.arpa entry. Hence I think it is useful to explore different weak schemes that defers stronger verification until it is actually needed (for instance, until the peer rehomes to different locators). > Wireless networks are a good example. Many switches provide monitoring > capabilities and fibers are not that hard to sniff. So someone with > physical access can look at the traffic with relative ease. However, in > order to block selected packets the attacker needs to redirect traffic > or install equipment in the middle. I suppose that's doable on wireless > lans but not so much when tapping into existing monitoring > capabilities. ARP/ND spoofing works well for any LAN I suspect. Hadn't thought about using monitoring capabailities. Do these require physical access, or can they be exploited remotely due to poor access control in the switches? If the attacker has physical access I don't know if there is that much different between installing some inductive coupling on a wire and installing a box on that wire. Remember that we assume that security sensitive traffic secure its payload (IPsec, TLS, etc) thus for that traffic the worst attack is a DoS. And an attacker with physical access can accomplish a DoS by just cutting the wire. Granted that there is a slight difference between cutting a wire and selectively redirecting a single connection/host-pair communication to a black hole; the former is much more likely to be detected and promptly repaired. Erik From owner-multi6@ops.ietf.org Wed Nov 5 05:36: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 FAA29907 for ; Wed, 5 Nov 2003 05:36:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHL0X-0004Qc-W2 for multi6-data@psg.com; Wed, 05 Nov 2003 10:35:25 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHL0K-0004Ox-SB for multi6@ops.ietf.org; Wed, 05 Nov 2003 10:35:13 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 23B6043151; Wed, 5 Nov 2003 11:35:12 +0100 (CET) Received: from lolo (vpn-252-70.uc3m.es [163.117.252.70]) by smtp01.uc3m.es (Postfix) with SMTP id B6D2899F48; Wed, 5 Nov 2003 11:35:10 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , "Multi6 Mailing List" Subject: RE: survivability, rewriting Date: Wed, 5 Nov 2003 11:29:26 +0100 Message-ID: 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It might be easier to just use separate packets for the "pings". Ok, what about replicating data packets and include in them a M6 destiantion option that means the ping? So, if there are data packets available we can piggyback ping into data packets (both forward and reverse path) My concern is about the sending host having to wait until the ping reply is received. An additional concern is that i don't think that we could trust ICMP end to end, becuase of icmp filtering. Regards, marcelo > > Erik > > From owner-multi6@ops.ietf.org Wed Nov 5 05:43:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00106 for ; Wed, 5 Nov 2003 05:43:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHL7t-0004rx-Oh for multi6-data@psg.com; Wed, 05 Nov 2003 10:43:01 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHL7g-0004qh-2v for multi6@ops.ietf.org; Wed, 05 Nov 2003 10:42:48 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA5AgYed025220; Wed, 5 Nov 2003 11:42:34 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: survivability, rewriting Date: Wed, 5 Nov 2003 11:42:45 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 5 nov 2003, at 11:05, Erik Nordmark wrote: >> My question is why don't just send a replicated data packet instead of >> pings? >> I mean, i have a hint that something is wrong, so if i have data >> packet >> available, i send it replicated as many times as possible source dest >> address combinations i have available. > That can work as long as you can tell from the returned packets which > of the replicated data packets made it. > I think this is hard. If you take a ULP packet and send it with > different > src/dst locators and then after one RTT there is a response (a ULP ack > for > instance) how can you tell which of the src/dst locator pairs worked? Right. Also, data packets are presumably large, while probe packets can be small. Sending four 80 byte probes to test four combinations of two sources and two destinations is less expensive than sending one 500 or 1500 byte data packet. On low bandwidth links having small probes also means the RTT for the reply is much faster: on a 56k link 80 vs 1500 bytes makes a 400 ms difference. These savings are especially significant when the active path is still available after all. From owner-multi6@ops.ietf.org Wed Nov 5 06:46: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 GAA01580 for ; Wed, 5 Nov 2003 06:46:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHM5U-00084L-MP for multi6-data@psg.com; Wed, 05 Nov 2003 11:44:36 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHM5H-00082v-3J for multi6@ops.ietf.org; Wed, 05 Nov 2003 11:44:23 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA5Bi9ed025865; Wed, 5 Nov 2003 12:44:09 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <640139A8-0F85-11D8-94BB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? Date: Wed, 5 Nov 2003 12:44:19 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 5 nov 2003, at 11:18, Erik Nordmark wrote: >>> Yes, but a weak verification can be converted to a strong >>> verification >>> at any time by invoking the strong verification mechanism (be it DNS >>> or CBID-based). >> Why not go for the strong stuff immediately? > Because it is likely to be more expensive; for CBID schemes you'd need > a public key challenge response (signing by the peer, verification at > your end) and for DNS schemes like NOID you'd need at least a reverse > lookup of the new locator. Good point. Still, I don't think a clear text cookie isn't the best tradeoff here. Doing one or two MD5 hashes over a few dozen bytes is enough to get rid of attackers who can sniff, but not block traffic. > If the new locator is from a revious unused ISP DNS cachaes might > not help and if DNSsec is used this implies verifying at least 3 (or > it is 6 > with delegation signer?) since there are likely to be 3 new > delegations to > find the previously unused ip6.arpa entry. I think we have to assume that DNSSEC won't be used. >> Wireless networks are a good example. Many switches provide monitoring >> capabilities and fibers are not that hard to sniff. So someone with >> physical access can look at the traffic with relative ease. However, >> in >> order to block selected packets the attacker needs to redirect traffic >> or install equipment in the middle. I suppose that's doable on >> wireless >> lans but not so much when tapping into existing monitoring >> capabilities. > ARP/ND spoofing works well for any LAN I suspect. But that's something that operators can fix if they care enough. > Hadn't thought about using monitoring capabailities. > Do these require physical access, or can they be exploited remotely > due to poor access control in the switches? Hard to say. But remember that ISPs and service providers higher up the stack in very many cases house their equipment in colo facilities where it's often not too hard for someone with legitimate access (ie, who rents some rack space there too) to mess around with someone else's equipment. > If the attacker has physical access I don't know if there > is that much different between installing some inductive coupling on > a wire and installing a box on that wire. I suppose not, but often the monitoring facilities are already in place. It's just a question of connecting a notebook to a monitoring port on a switch > Remember that we assume that security sensitive traffic secure its > payload > (IPsec, TLS, etc) thus for that traffic the worst attack is a DoS. And > an > attacker with physical access can accomplish a DoS by just cutting the > wire. True, but that will be detected very quickly. Monitoring may remain undetected for a long time. Maybe in quantum physics looking at something is on the same scale as manipulating it, but in networks this isn't exactly the case. :-) My point is that trying to prevent man in the middle attacks doesn't make any sense for what we're trying to do here, but making our stuff such that someone with just sniffing and packet injection capability but who can't block the real traffic, is helpful. From owner-multi6@ops.ietf.org Wed Nov 5 06:47: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 GAA01628 for ; Wed, 5 Nov 2003 06:47:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHM7p-0008D9-Ni for multi6-data@psg.com; Wed, 05 Nov 2003 11:47:01 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHM7V-0008Bl-7l for multi6@ops.ietf.org; Wed, 05 Nov 2003 11:46:41 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA5Bk7xA011945; Wed, 5 Nov 2003 03:46:08 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA5Bk6S10725; Wed, 5 Nov 2003 12:46:06 +0100 (MET) Date: Wed, 5 Nov 2003 12:45:31 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? To: masataka ohta Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3FA7CF59.9080004@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > So, let's assume that we were talking about an imaginary IP network > where secure DNS were deployed and a pair of hosts were actually > using it for their forward and reverse domains. > > Then, there is no reason to make some part of address of a host > a hash of host's public key, as the host can simply put its full > public key in DNS. > > Then, the pair of hosts can and will exchange a session key with > which the communication, including parts for multihoming control, > is secured. Yes, but this implies doing a full key exchange to form the session keys for every pair of hosts that communicate. That might be acceptable if those hosts want cryptographical strength integrity and/or confidentiality, but feels like a lot of resources to spend for the off-chance that during their communication one or both of them will need to use different locators. Your argument also assumes that all hosts will be in the DNS so that they have a FQDN under which they can store their public key. That isn't the case in IPv4 today and I haven't seen a strong driver for this changing with IPv6. Thus I think it is important to enable multihoming support when only one end of the communication has information in the DNS. I haven't seen a proposal for how to do this using public keys stored in the DNS. If you have one please explain it. > Still, you may argue that DoS of telling wrong locators should be > possible. But, you are wrong because MITM can issue as much DoS > as he wants regardless of security mechanism used. DoS by MITM, > agaist which cookies does not work, is fatally efficient, if > public key (that is, *EXPENSIVE*) cryptography is used. DoS from MiTM isn't the main DoS concern in the threats draft. In fact it points out that such DoS attacks are possible in today's Internet. One concern added by multihoming are around 3rd party DoS attacks, where the redirection capability inherent in multihoming could potentially be used to redirect large, sustained packet flows to a 3rd party. See the draft for details. The other DoS concern is about opportunities potentially created by the multihoming mechanisms themselves; creating state or doing large amounts of processing on an initial packet for instance. > Finally, as a set of locators of a host can be securely obtained > from secure DNS that there is no need to dynamically authenticate > the set, which is the fundamental difference between MIPv6 and M6. As the NOID draft discusses, if you want to use the DNS for verification, one actually has to verify not only that the node/fdqn claims to use a locator, but also that the locator points back at the fqdn. Otherwise, such a mechanism could be used for 3rd party DoS. Erik From owner-multi6@ops.ietf.org Wed Nov 5 06:51: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 GAA01844 for ; Wed, 5 Nov 2003 06:51:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHMC6-0008Tf-2d for multi6-data@psg.com; Wed, 05 Nov 2003 11:51:26 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHMBt-0008Sv-Jo for multi6@ops.ietf.org; Wed, 05 Nov 2003 11:51:13 +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 hA5Bp1UP026177; Wed, 5 Nov 2003 03:51:02 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA5Bp0S10980; Wed, 5 Nov 2003 12:51:00 +0100 (MET) Date: Wed, 5 Nov 2003 12:50:25 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: survivability, rewriting To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , Multi6 Mailing List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Ok, what about replicating data packets and include in them a M6 destiantion > option that means the ping? Could do that or other forms of piggybacking (an extension hdr which is followed by the payload packet) if there is a need for this. > So, if there are data packets available we can piggyback ping into data > packets (both forward and reverse path) > My concern is about the sending host having to wait until the ping reply is > received. Why would it have to wait? It can be optimistic (the same way e.g. neighbor unreachability detection is optimistic) by sending the data packet and separately sending the reachability test packet. Whether optimizing that to be one larger packet instead of two is worth-while is a detail we need to talk about once we understand the bigger picture choices. > An additional concern is that i don't think that we could trust ICMP end to > end, becuase of icmp filtering. Agreed they might not be reliably delivered. Erik From owner-multi6@ops.ietf.org Wed Nov 5 06:56: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 GAA01901 for ; Wed, 5 Nov 2003 06:56:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHMGN-0008pM-Rb for multi6-data@psg.com; Wed, 05 Nov 2003 11:55:51 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHMGB-0008oC-Mu for multi6@ops.ietf.org; Wed, 05 Nov 2003 11:55:39 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA5BtVxA014641; Wed, 5 Nov 2003 03:55:32 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA5BtUS11295; Wed, 5 Nov 2003 12:55:30 +0100 (MET) Date: Wed, 5 Nov 2003 12:54:55 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <640139A8-0F85-11D8-94BB-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I think we have to assume that DNSSEC won't be used. We (unfortunately) can't rely on it being deployed, but I think we need to understand how both performance and security of a multihoming solution changes when/where DNSsec gets deployed. > Good point. Still, I don't think a clear text cookie isn't the best > tradeoff here. Doing one or two MD5 hashes over a few dozen bytes is > enough to get rid of attackers who can sniff, but not block traffic. Agreed. > My point is that trying to prevent man in the middle attacks doesn't > make any sense for what we're trying to do here, but making our stuff > such that someone with just sniffing and packet injection capability > but who can't block the real traffic, is helpful. I agree. We should put some discussion about this in the threats draft. Erik From owner-multi6@ops.ietf.org Wed Nov 5 07:16: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 HAA02483 for ; Wed, 5 Nov 2003 07:16:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHMZ0-0009xe-Ai for multi6-data@psg.com; Wed, 05 Nov 2003 12:15:06 +0000 Received: from [2001:888:1dde:2::1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHMYo-0009wY-5U for multi6@ops.ietf.org; Wed, 05 Nov 2003 12:14:54 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hA5CEfed026254; Wed, 5 Nov 2003 13:14:41 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: survivability, rewriting Date: Wed, 5 Nov 2003 13:14:51 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.604) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 5 nov 2003, at 12:50, Erik Nordmark wrote: >> An additional concern is that i don't think that we could trust ICMP >> end to >> end, becuase of icmp filtering. > Agreed they might not be reliably delivered. People who filter ICMP get what they ask for... Alternatively, we can ask ULPs to supply a probe packet along with the hint. For instance, TCP could make a very small packet that triggers an ack from the other side. The mh layer can then send out these probes with some additional info needed to see what works and what doesn't in an option/header. If the ULP doesn't supply a probe (or a hint, for that matter) the mh layer sends just the option/header with no upper layer, the option/header with an ICMP echo request or an UDP packet that addresses the mh layer on the other side. Iljitsch From owner-multi6@ops.ietf.org Wed Nov 5 07:51:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03592 for ; Wed, 5 Nov 2003 07:51:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHN5c-000Bn4-AL for multi6-data@psg.com; Wed, 05 Nov 2003 12:48:48 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHN5Q-000Blj-Dt for multi6@ops.ietf.org; Wed, 05 Nov 2003 12:48:36 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hA5CmUPh017784; Wed, 5 Nov 2003 05:48:31 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA5CmTS18378; Wed, 5 Nov 2003 13:48:29 +0100 (MET) Date: Wed, 5 Nov 2003 13:47:55 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: mbagnulo@ing.uc3m.es Cc: Erik Nordmark , Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > But the host will never know better than the routing system because it > > is operating on aggregated information. > > Don't understand this... > The routing system is the one who works with aggregated information implying > information loss. > The host deals with no aggregated host information I guess my statement wasn't very clear. While the host has some information about reachability of src/dst locator pairs, it does not have information on how this maps to the exit paths from the site. For instance, if the host could choose between 3 destination locators it wouldn't know that for instance the first two result in the same exit path being used. That level of information is known in the routing system. > We still have to provide some way to provide > ingress filtering compatibility for non M6 capable communications. The > benefit of source address based routing is that it also addresses both > situations (or kind of) I'm upleveling this part of the discussion a bit. I think the goal should be a workable and deployable multihoming solution. Whether that also provides incremental benefits for steps along the way (such as current ingress filtering issues for sites that have multiple prefixes and multiple ISPs) doesn't look like the highest priority to me; if that bogs us down so that we can't come up with a multihoming solution then I think we need to ignore it. If we don't have that attitude we might become so entangled by incrementalism that we can never design the necessary multihoming solution. Erik From owner-multi6@ops.ietf.org Wed Nov 5 07:58: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 HAA03793 for ; Wed, 5 Nov 2003 07:58:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHNEb-000CI7-GP for multi6-data@psg.com; Wed, 05 Nov 2003 12:58:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AHNEO-000CHB-0g for multi6@ops.ietf.org; Wed, 05 Nov 2003 12:57:52 +0000 Received: (qmail 34472 invoked from network); 5 Nov 2003 13:03:06 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 5 Nov 2003 13:03:06 -0000 Message-ID: <3FA8F423.1000007@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Nov 2003 21:59:15 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: multi6@ops.ietf.org Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik; >>So, let's assume that we were talking about an imaginary IP network >>where secure DNS were deployed and a pair of hosts were actually >>using it for their forward and reverse domains. >> >>Then, there is no reason to make some part of address of a host >>a hash of host's public key, as the host can simply put its full >>public key in DNS. >> >>Then, the pair of hosts can and will exchange a session key with >>which the communication, including parts for multihoming control, >>is secured. > Yes, but this implies doing a full key exchange to form the session keys > for every pair of hosts that communicate. > That might be acceptable if those hosts want cryptographical strength > integrity and/or confidentiality, Urrr, what, are you saying, "acceptable"? Apparently, you don't know that secure DNS is *EXPENSIVE*. It take more computation to retrieve information from secure DNS, or anything with hierarchical CAs, than to exchange a session key for cryptographical strength integrity and/or confidentiality. > but feels like a lot of resources to > spend for the off-chance that during their communication one or both > of them will need to use different locators. Huh? "exchange a session key" for cryptographical strength integrity and/or confidentiality at the beginning of communication means that a shared secret session key is exchanged helped by public key cryptography. After that, cryptographical computaions are secrete key ones and are inexpensive. > Your argument also assumes that all hosts will be in the DNS so that they > have a FQDN under which they can store their public key. It is *YOUR* assumption. > That isn't the case in IPv4 today and I haven't seen a strong driver for > this changing with IPv6. Thus Thus, even though you use public key cryptography with keys authenticated by plain DNS, it is as secure as just believe plain DNS. > I think it is important to enable multihoming > support when only one end of the communication has information in the DNS. > I haven't seen a proposal for how to do this using public keys stored > in the DNS. If you have one please explain it. See above. It is easy to have a proposal using public keys. However, that your proposal use public keys wrongly does not mean your proposal has reasonable security. >>Still, you may argue that DoS of telling wrong locators should be >>possible. But, you are wrong because MITM can issue as much DoS >>as he wants regardless of security mechanism used. DoS by MITM, >>agaist which cookies does not work, is fatally efficient, if >>public key (that is, *EXPENSIVE*) cryptography is used. > DoS from MiTM isn't the main DoS concern in the threats draft. That is a problem of your draft. > where the redirection capability inherent in multihoming Wrong. > could potentially > be used to redirect large, sustained packet flows to a 3rd party. > See the draft for details. See previous mails on how it can be done with DNS without M6. > The other DoS concern is about opportunities potentially created by > the multihoming mechanisms themselves; creating state or doing large amounts > of processing on an initial packet for instance. An elementary fact on security is that DoS is so eacy. That you happen to find a way of DoS attack for M6 does not mean that similar attack is not possible for other protocols. For example, secure DNS is subject to similar DoS attacks. >>Finally, as a set of locators of a host can be securely obtained >>from secure DNS that there is no need to dynamically authenticate >>the set, which is the fundamental difference between MIPv6 and M6. > As the NOID draft discusses, if you want to use the DNS for verification, > one actually has to verify not only that the node/fdqn claims to use a locator, > but also that the locator points back at the fqdn. And it is identical to reverse-then-forward look up of DNS for verification widely used today with no M6 specific issues. Unlike secure DNS, it is easy, useful, inexpensive, reliable and proven to work. Masataka Ohta PS Learn elementary security. From owner-multi6@ops.ietf.org Wed Nov 5 08:16: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 IAA04572 for ; Wed, 5 Nov 2003 08:16:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHNVb-000DNy-O5 for multi6-data@psg.com; Wed, 05 Nov 2003 13:15:39 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHNVP-000DNL-Oa for multi6@ops.ietf.org; Wed, 05 Nov 2003 13:15:27 +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 hA5DErUP027166; Wed, 5 Nov 2003 05:14:53 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA5DEqS20253; Wed, 5 Nov 2003 14:14:52 +0100 (MET) Date: Wed, 5 Nov 2003 14:14:15 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? To: masataka ohta Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3FA8F423.1000007@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk masataka, > It is *YOUR* assumption. Nope - it was *YOU* who suggested to use DNSsec to store public keys. An outline of a suggestion of mine is in draft-nordmark-multi6-sim-01.txt and it doesn't add any use of DNS, secure or not. Erik From owner-multi6@ops.ietf.org Wed Nov 5 08:21: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 IAA04821 for ; Wed, 5 Nov 2003 08:21:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHNaz-000Dnx-HX for multi6-data@psg.com; Wed, 05 Nov 2003 13:21:13 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AHNan-000Dmw-CY for multi6@ops.ietf.org; Wed, 05 Nov 2003 13:21:02 +0000 Received: (qmail 34554 invoked from network); 5 Nov 2003 13:26:17 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 5 Nov 2003 13:26:17 -0000 Message-ID: <3FA8F995.4090003@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Nov 2003 22:22:29 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: mbagnulo@ing.uc3m.es, Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik; > While the host has some information about reachability of src/dst locator > pairs, it does not have information on how this maps to the exit paths from > the site. For instance, if the host could choose between 3 destination > locators it wouldn't know that for instance the first two result in the same > exit path being used. > That level of information is known in the routing system. Why do you think host can not get infromation from the routing system? In good old days when IPv4 routing table was not bloated, it was usual for UNIX box to run routed (in quite mode) even if a host is singly homed. Masataka Ohta From owner-multi6@ops.ietf.org Wed Nov 5 08:27: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 IAA04961 for ; Wed, 5 Nov 2003 08:27:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHNh4-000EFD-0e for multi6-data@psg.com; Wed, 05 Nov 2003 13:27:30 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AHNgr-000EEQ-LJ for multi6@ops.ietf.org; Wed, 05 Nov 2003 13:27:17 +0000 Received: (qmail 34568 invoked from network); 5 Nov 2003 13:32:33 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 5 Nov 2003 13:32:33 -0000 Message-ID: <3FA8FB0D.3080301@necom830.hpcl.titech.ac.jp> Date: Wed, 05 Nov 2003 22:28:45 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: multi6@ops.ietf.org Subject: Re: multi6-threats-00.txt vs. MIPv6 - different strength verifications? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik; >>It is *YOUR* assumption. > > > Nope - it was *YOU* who suggested to use DNSsec to store public keys. It has nothing to do with *YOUR* assumption. Read your mail on what was *YOUR* assumption, if you still insist on your broken analysis and proposals. Masataka Ohta From owner-multi6@ops.ietf.org Wed Nov 5 09:32: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 JAA06721 for ; Wed, 5 Nov 2003 09:31:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHOg7-000IF8-1A for multi6-data@psg.com; Wed, 05 Nov 2003 14:30:35 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHOft-000IDa-W0 for multi6@ops.ietf.org; Wed, 05 Nov 2003 14:30:22 +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 hA5ETfUP001917; Wed, 5 Nov 2003 06:29:42 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hA5ETdS01989; Wed, 5 Nov 2003 15:29:40 +0100 (MET) Date: Wed, 5 Nov 2003 15:29:03 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) To: masataka ohta Cc: Erik Nordmark , mbagnulo@ing.uc3m.es, Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <3FA8F995.4090003@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Why do you think host can not get infromation from the routing > system? > > In good old days when IPv4 routing table was not bloated, it was > usual for UNIX box to run routed (in quite mode) even if a host > is singly homed. I recall reading a draft and slides which proposed using something like RIPv2 to distribute all the external routes from all the edges to the internal routers and hosts (draft-ohta-e2e-multihoming). Two issues with that aspect of that proposal: 1. Folks seem to be want to put IP connectivity in smaller and smaller devices. Thus even though a laptop with a few hundered meg of memory can easily handle the full routing table, it isn't obvious to me that it is a good thing assuming that all hosts that want to benefit from site multihoming will want to store the full routing table. 2. Efficiency/timeliness; when a different exit path should taken from a site for a given prefix/address this needs to be communicated rapidly and efficiently so that packets can use the new path. Sending all updates to the Internet routing table to all hosts is one way to convey this, but this means that updates to prefixes which nobody in the site care about might be communicated to hundereds of routers and thousands of hosts. And when a single or a few hosts indeed are interested in that update, it will potentially take some time to propagate, especially with a distance vector protocol as the distribution mechanism. A possible alternative is a packet driven approach at the border router where the arrival of a packet causes a signal back to the host. This signal could be either a source locator rewrite (which will return to the host in packets coming from the peer) or some new ICMP error directly to the host. It would be good if the WG could explore the tradeoffs in this part of the multihoming puzzle. Erik From owner-multi6@ops.ietf.org Wed Nov 5 13:10: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 NAA15386 for ; Wed, 5 Nov 2003 13:10:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHS50-0005cg-N4 for multi6-data@psg.com; Wed, 05 Nov 2003 18:08:30 +0000 Received: from [163.117.136.121] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHS4l-0005bK-Sm for multi6@ops.ietf.org; Wed, 05 Nov 2003 18:08:16 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 158D1431A7; Wed, 5 Nov 2003 19:08:15 +0100 (CET) Received: from lolo (vpn-252-71.uc3m.es [163.117.252.71]) by smtp01.uc3m.es (Postfix) with SMTP id 0D92899F4D; Wed, 5 Nov 2003 19:08:11 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , Cc: Subject: Options for preserving established communications Date: Wed, 5 Nov 2003 19:02:25 +0100 Message-ID: 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is an attempt to summarize the options that have came up in the on-going thread about preserving established communications in order to evaluate the different possibilities. A mechanism for preserving established communications requires the following mechanisms: - A mechanism to detect outages in the currenlty used path - A mechanism to identify alternative paths that are working - A mechanism to change from the broken path to the new path Explored possibilities for each of those mechanism include: - Possible option for detecting outages in the currenlty used path The timing requirement for preserving established communcations vary with the considered application. The different options cosidered are: - End-to-end keepalives with two flavors: - fixed frequency - frequency determined by the ULP - BGP detection mechanisms - ULP detection mechanisms - Churn detection mechanism - ICMP errors - Possible options for identifing alternative paths that are working - ping bomb with three flavors: - ICMP - replicated data packets - new M6 message piggybacked in data packets - BGP plus rewriting source address - None, just blindly try with alternative ones - A mechanism to change from the broken path to the new path This depends on the type of failure. One type of failure is related to the Destination address, so the option is change the destiantion address. The other type of failures is related to the exit ISP, so the options to deal with this are: - Source address based routing - a bit in the header that informs the routing system that alternative path is needed - Routing header - BGP routes injected in the site Regards, marcelo From owner-multi6@ops.ietf.org Wed Nov 5 17:48:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28113 for ; Wed, 5 Nov 2003 17:48:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHWQ5-0003PO-V1 for multi6-data@psg.com; Wed, 05 Nov 2003 22:46:33 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AHWPt-0003Oz-92 for multi6@ops.ietf.org; Wed, 05 Nov 2003 22:46:21 +0000 Received: (qmail 36588 invoked from network); 5 Nov 2003 22:51:43 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 5 Nov 2003 22:51:43 -0000 Message-ID: <3FA97E14.4040303@necom830.hpcl.titech.ac.jp> Date: Thu, 06 Nov 2003 07:47:48 +0900 From: masataka ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: mbagnulo@ing.uc3m.es, Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik; > I recall reading a draft and slides which proposed using something like RIPv2 > to distribute all the external routes from all the edges to the internal > routers and hosts (draft-ohta-e2e-multihoming). > > Two issues with that aspect of that proposal: > 1. Folks seem to be want to put IP connectivity in smaller and smaller devices. > Thus even though a laptop with a few hundered meg of memory can easily > handle > the full routing table, it isn't obvious to me that it is a good thing > assuming that all hosts that want to benefit from site multihoming will > want to store the full routing table. Smaller device? Read the draft. It says: But, with smaller full routing table and larger scale of integration, there is no reason not to have full routing table on every end system. That is, my draft takes care of those who don't have much knowledge on trend of integration scale. But, I can't help those who don't read it. Smaller and smaller devices are having more and more memory. In addition, the draft says: One may still be allowed, though discouraged, to have local configuration with dumb end systems and an intelligent proxy. But, such configuration should be implemented with a protocol for purely local use without damaging the global protocol. that people who don't accept the trend of integration are also taken care of. Do read the draft. > 2. Efficiency/timeliness; when a different exit path should taken from > a site for a given prefix/address this needs to be communicated rapidly > and efficiently so that packets can use the new path. > Sending all updates to the Internet routing table to all hosts is one way > to convey this, but this means that updates to prefixes which nobody in > the site care about might be communicated to hundereds of routers and > thousands of hosts. But it is non issue with smaller full routing table and larger scale of integration, and faster network speed. > And when a single or a few hosts indeed are interested > in that update, it will potentially take some time to propagate, especially > with a distance vector protocol as the distribution mechanism. A route can be used only after it is processed by the routing system. So, it all depends on the routing protocol used. Those who use RIPv2++ on networks with complex loop topology will suffer a lot of delay. Those who use OSPF (not OSPF++ but OSPF as is as it has fields to carry information required for source address selection) on the topology won't see much delay. > A possible alternative is a packet driven approach at the border router > where the arrival of a packet causes a signal back to the host. > This signal could be either a source locator rewrite (which will return > to the host in packets coming from the peer) or some new ICMP error > directly to the host. For the discouraged case, I prefer using an intelligent proxy server to choose a source address for a dumb end system. > It would be good if the WG could explore the tradeoffs in this part of > the multihoming puzzle. Before doing that, do you know how much memory can be put on a typical chip? Do you know how much memory is consumed for typical code for TCP/IP stack? Do you know how much memory is consumed for a typical routing table entry? These are the basic figures for constructive discussion. Masataka Ohta From owner-multi6@ops.ietf.org Thu Nov 6 01:18: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 BAA12546 for ; Thu, 6 Nov 2003 01:18:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHdQe-000Lt4-DC for multi6-data@psg.com; Thu, 06 Nov 2003 06:15:36 +0000 Received: from [195.43.225.73] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHdQR-000Ls0-Re for multi6@ops.ietf.org; Thu, 06 Nov 2003 06:15:24 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hA66Eh5h001484; Thu, 6 Nov 2003 07:14:46 +0100 (CET) Date: Thu, 6 Nov 2003 07:14:40 +0100 Subject: Re: Tentative agenda for Multi6 in Minneapolis Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: agenda@ietf.org, multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20BEB9BA-0D2D-11D8-BC3D-00039388672E@muada.com> Message-Id: <814BA15B-1020-11D8-8572-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> 1700-1800 Afternoon Sessions IV > > Kurtis, I know the IETF has a long standing tradition of having > sessions that are relevant to the same broad interest groups overlap, > but tuesday 17 - 18 hours multi6 overlaps with the ipv6 wg. This seems > rather insane. Is there anything that can be done about this? To reply in public as well. This is being looked at - but I would not hold my breath. Scheduling seems to have been really hard this time. I will let you all know. Best regards, - - - kurtis - - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6iqKaarNKXTPFCVEQJ8OACg4jSAkb3fz1rOhIS9fxWC0eVFMJgAoPRV Kko9yxk8OodCMNYum0/yJxgQ =tO1R - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6nm0qarNKXTPFCVEQJ9EwCaAl4cjerOrSM3k6IK1GYekwH7nhMAnA6t +Pf2wZBoQPmR/Qtq9qiq3vEB =64gS -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 6 05:57: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 FAA03852 for ; Thu, 6 Nov 2003 05:57:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHhmp-000Hwy-JN for multi6-data@psg.com; Thu, 06 Nov 2003 10:54:47 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHhmd-000HwL-0S for multi6@ops.ietf.org; Thu, 06 Nov 2003 10:54:35 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hA6Arx5h001677; Thu, 6 Nov 2003 11:54:00 +0100 (CET) Date: Thu, 6 Nov 2003 11:53:55 +0100 Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) Content-Type: text/plain; charset=ISO-8859-1; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: , Multi6 Mailing List To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <4B1F3854-0E0A-11D8-A5FC-00039388672E@muada.com> Message-Id: <8473A37A-1047-11D8-8572-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: quoted-printable X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On m=E5ndag, nov 3, 2003, at 15:30 Europe/Stockholm, Iljitsch van = Beijnum=20 wrote: > > Current rules say you must have 200 customers that take IPv6 addresses=20= > from you in two years. Now obviously there are going to be ISPs for=20 > which this is a problem, but I don't see how we can arrive at very=20 > large numbers of multihomed sites that use ISPs with less than 200=20 > customers. This is being changed though. See the discussion in ARIN and RIPE. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6ooRaarNKXTPFCVEQISNgCdHhW8HWpN00l7npbuZ2Q1PF4SLDYAoPc6 sJgPVK5CNGPo+5Uq7FNCK+Gf =3Dsyi/ -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 6 14:05: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 OAA23333 for ; Thu, 6 Nov 2003 14:05:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHpQY-000EZN-SE for multi6-data@psg.com; Thu, 06 Nov 2003 19:04:18 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHpQU-000ERU-UX for multi6@ops.ietf.org; Thu, 06 Nov 2003 19:04:15 +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 TAA15310; Thu, 6 Nov 2003 19:02:41 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA04152; Thu, 6 Nov 2003 19:02:41 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id hA6J2fC21271; Thu, 6 Nov 2003 19:02:41 GMT Date: Thu, 6 Nov 2003 19:02:41 +0000 From: Tim Chown To: agenda@ietf.org, multi6@ops.ietf.org, ipv6@ietf.org Subject: Re: Clash of IPv6 and Multi6 WG meetings Message-ID: <20031106190241.GF20850@login.ecs.soton.ac.uk> Mail-Followup-To: agenda@ietf.org, multi6@ops.ietf.org, ipv6@ietf.org References: <20BEB9BA-0D2D-11D8-BC3D-00039388672E@muada.com> <814BA15B-1020-11D8-8572-000A9598A184@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814BA15B-1020-11D8-8572-000A9598A184@kurtis.pp.se> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Nov 06, 2003 at 07:14:40AM +0100, Kurt Erik Lindqvist wrote: > > To reply in public as well. This is being looked at - but I would not > hold my breath. Scheduling seems to have been really hard this time. I > will let you all know. It seems the "final agenda" has ipv6 and multi6 clashing at 5pm Tuesday. However, we have three multi6 WG slots: 15:45- 16:45 Tuesday 17:00- 18:00 Tuesday (clashing with multi6) 09:00- 11:30 Wednesday If this stays as is, I would hope the multi6 WG chairs will fund some way to make the key discussions happen in slots 1 and 3 :) But let's hope there's still scope for a fix, or compression of essential multi6 into the two slots. Tim From owner-multi6@ops.ietf.org Thu Nov 6 14:25: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 OAA24186 for ; Thu, 6 Nov 2003 14:25:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHpkD-000I7K-26 for multi6-data@psg.com; Thu, 06 Nov 2003 19:24:37 +0000 Received: from [195.43.225.73] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHpk9-000I6w-EZ for multi6@ops.ietf.org; Thu, 06 Nov 2003 19:24:33 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hA6JO55h001805; Thu, 6 Nov 2003 20:24:05 +0100 (CET) Date: Thu, 6 Nov 2003 20:24:01 +0100 Subject: Re: Clash of IPv6 and Multi6 WG meetings Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: agenda@ietf.org, multi6@ops.ietf.org, ipv6@ietf.org To: Tim Chown From: Kurt Erik Lindqvist In-Reply-To: <20031106190241.GF20850@login.ecs.soton.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From what I hear this is still being worked on. - - kurtis - On torsdag, nov 6, 2003, at 20:02 Europe/Stockholm, Tim Chown wrote: > On Thu, Nov 06, 2003 at 07:14:40AM +0100, Kurt Erik Lindqvist wrote: >> >> To reply in public as well. This is being looked at - but I would not >> hold my breath. Scheduling seems to have been really hard this time. I >> will let you all know. > > It seems the "final agenda" has ipv6 and multi6 clashing at 5pm > Tuesday. > > However, we have three multi6 WG slots: > > 15:45- 16:45 Tuesday > 17:00- 18:00 Tuesday (clashing with multi6) > 09:00- 11:30 Wednesday > > If this stays as is, I would hope the multi6 WG chairs will fund some > way > to make the key discussions happen in slots 1 and 3 :) But let's > hope > there's still scope for a fix, or compression of essential multi6 into > the > two slots. > > Tim > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6qf1KarNKXTPFCVEQL87gCdFHVKrRzK24RxP2hg7/ky0C4QysQAnj9V e14IOt3GOLev5YA52LBmoAtz =fkwW -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Nov 7 00:41: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 AAA17801 for ; Fri, 7 Nov 2003 00:41:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AHzL3-000C31-P5 for multi6-data@psg.com; Fri, 07 Nov 2003 05:39:17 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AHzKz-000C2j-1D for multi6@ops.ietf.org; Fri, 07 Nov 2003 05:39:13 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 58971137AE for ; Fri, 7 Nov 2003 00:39:12 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 Nov 2003 00:39:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3A4F1.7886F12C" Subject: MAST Review JimBo Date: Fri, 7 Nov 2003 00:39:11 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122598@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: yes Thread-Topic: MAST Review JimBo Thread-Index: AcOk8Xt4ghMaeyEuSTut9JLrHqdrbQ== From: "Bound, Jim" To: X-OriginalArrivalTime: 07 Nov 2003 05:39:11.0925 (UTC) FILETIME=[78EB0E50:01C3A4F1] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_00,REMOVE_REMOVAL_2WORD autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C3A4F1.7886F12C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dave, Attached are revs of MAST and CHOICE. Bottom line is I think MAST should just stick to multiaddreses injection btw transport and IP layer. But, I think SCTP does this fine and any extensions your model proposes is input to SCTP. =20 I think also you should label MAST as a "Reference Model" stage no one could implement this except maybe a rapid base prototype and then only by consulting with you. Not ideal for implementation. So for now I believe you have a model. But I see no advantage at all over SCTP and SCTP does this naturally to support multiple addreses and has mechanisms to add them and delete them. The model discussion is fine here and part of the multi6 charter for problem to solve at hand. But the actual work on a real architecture and spec I think would be done as new WG in Transport Area. But as I said SCTP solves this problem. =20 On CHOICE I think this should become two drafts and orthogonal to MAST. One is a draft on emerging terminology that would exists next to our multi6 requirements. The other one would be the long list of "assumptions" you state about our required terminology. These should be separate efforts and have nothing to do with MAST. Regards, /jim ------_=_NextPart_001_01C3A4F1.7886F12C Content-Type: text/plain; name="bound_rev_draft-crocker-mast-proposal-01.txt" Content-Description: bound_rev_draft-crocker-mast-proposal-01.txt Content-Disposition: attachment; filename="bound_rev_draft-crocker-mast-proposal-01.txt" Content-Transfer-Encoding: base64 ICAgICANCiAgICAgQUJTVFJBQ1QNCiAgICAgDQogICAgIENsYXNzaWMgSW50ZXJuZXQgdHJhbnNw b3J0IHByb3RvY29scyB1c2UgYSBzaW5nbGUgc291cmNlIElQDQogICAgIGFkZHJlc3MgYW5kIGEg c2luZ2xlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MsIGFzIHBhcnQgb2YgdGhlDQogICAgIGlkZW50 aWZpY2F0aW9uIGZvciBhbiBpbmRpdmlkdWFsIGRhdGEgZmxvdy4gIFRDUCBpbmNsdWRlcyB0aGVz ZQ0KICAgICBpbiBpdHMgZGVmaW5pdGlvbiBvZiBhIGNvbm5lY3Rpb24gYW5kIGl0cyBjYWxjdWxh dGlvbiBvZiB0aGUNCiAgICAgaGVhZGVyIGNoZWNrc3VtLiAgSGVuY2UgdGhlIHRyYW5zcG9ydCBz ZXJ2aWNlIGlzIHRpZWQgdG8gYQ0KICAgICBwYXJ0aWN1bGFyIElQIGFkZHJlc3MgcGFpci4gVGhp cyBpcyBwcm9ibGVtYXRpYyBmb3IgbXVsdGlob21lZA0KICAgICBob3N0cyBhbmQgZm9yIG1vYmls ZSBob3N0cy4gVGhleSBjYW5ub3QgdXNlIG1vcmUgdGhhbiBvbmUsIGZvcg0KICAgICBhbnkgc2lu Z2xlIHRyYW5zcG9ydCBhc3NvY2lhdGlvbiAoY29udGV4dCkuICBNdWx0aXBsZSBBZGRyZXNzDQog ICAgIFNlcnZpY2UgZm9yIFRyYW5zcG9ydCAoTUFTVCkgZGVmaW5lcyBhIG1lY2hhbmlzbSB0aGF0 IHN1cHBvcnRzDQogICAgIGFzc29jaWF0aW9uIG9mIG11bHRpcGxlIElQIGFkZHJlc3NlcyB3aXRo IGFueSB0cmFuc3BvcnQNCiAgICAgYXNzb2NpYXRpb24uICBJdCByZXF1aXJlcyBubyBjaGFuZ2Ug dG8gdGhlIEludGVybmV0DQogICAgIGluZnJhc3RydWN0dXJlLCBubyBjaGFuZ2UgdG8gSVAgbW9k dWxlcyBvciB0cmFuc3BvcnQgbW9kdWxlcyBpbg0KICAgICB0aGUgZW5kLXN5c3RlbXMsIGFuZCBu byBuZXcgYWRtaW5pc3RyYXRpdmUgZWZmb3J0LiBJbnN0ZWFkLCBpdA0KICAgICBkZWZpbmVzIGEg bGF5ZXIgYmV0d2VlbiBjbGFzc2ljIElQIGFuZCB0cmFuc3BvcnQgdGhhdCBvcGVyYXRlcw0KICAg ICBvbmx5IGluIHRoZSBlbmQgc3lzdGVtcyBhbmQgYWZmZWN0cyBvbmx5IHBhcnRpY2lwYXRpbmcg aG9zdHMuDQogICAgIEFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBpcyBvYnRhaW5lZCBieSB1c2Ug b2YgYSBETlMgYW5kDQogICAgICJwcmVzZW5jZSIgcmVuZGV6dm91cyBzZXJ2aWNlLg0KDQpKQj4g QWRkaW5nIGEgbGF5ZXIgYmV0d2VlbiB0aGUgdHJhbnNwb3J0IGFuZCBJUCBsYXllciB0aGF0IHN1 cHBvcnRzIHRoZQ0KSW50ZXJuZXQgUHJvdG9jb2wgc3VpdGUgaXMgbm90IHRyaXZpYWwsIHNpZ25p ZmljYW50IHRvIGltcGxlbWVudGF0aW9ucywgYW5kIA0KbXVzdCBtYWludGFpbiBjb2hlc2lvbiBi ZXR3ZWVuIHRoZSB0d28gbGF5ZXJzIHJlZ2FyZGluZyBzdGF0ZSBvZiBhIA0KY29ubmVjdGlvbi4g IA0KICAgICANCiAgICAgQ09OVEVOVFMNCiAgICAgDQogICAgIDEuICAgSU5UUk9EVUNUSU9ODQog ICAgIDEuMS4gVEVSTUlOT0xPR1kNCiAgICAgMS4yLiBESVNDVVNTSU9OIFZFTlVFDQogICAgIDEu My4gRE9DVU1FTlQgSElTVE9SWQ0KICAgICANCiAgICAgMi4gICBSRVFVSVJFTUVOVFMNCiAgICAg DQogICAgIDMuICAgUFJPVE9DT0wNCiAgICAgMy4xLiBUUkFOU0FDVElPTiBNT0RFTA0KICAgICAz LjIuIEFTU09DSUFUSU9OIEFUVFJJQlVURVMNCiAgICAgMy4zLiBUSEUgSU5JVCBPUEVSQVRJT04N CiAgICAgMy40LiBUSEUgU0VUIE9QRVJBVElPTg0KICAgICAzLjUuIFRIRSBQUk9CRSBPUEVSQVRJ T04NCiAgICAgMy42LiBUSEUgU0hVVCBPUEVSQVRJT04NCiAgICAgMy43LiBUSEUgRVJSIE9QRVJB VElPTg0KICAgICANCiAgICAgNC4gICBUUkFOU0ZFUiBTRVJWSUNFDQogICAgIA0KICAgICA1LiAg IFNPVVJDRSBWQUxJREFUSU9ODQogICAgIA0KICAgICA2LiAgIFJFTkRFWlZPVVMNCiAgICAgNi4x LiBETlMNCiAgICAgNi4yLiBQUkVTRU5DRQ0KICAgICANCiAgICAgNy4gICBQQVRIIFNFTEVDVElP Tg0KICAgICANCiAgICAgOC4gICBJTVBMRU1FTlRBVElPTg0KICAgICA4LjEuIFRZUElDQUwgVFJB TlNQT1JUIElOVEVSRkFDSU5HDQogICAgIDguMi4gTUFTVCBUSFJPVUdIIE5BVA0KICAgICA4LjMu IE1BU1QgQUdFTlQNCiAgICAgDQogICAgIDkuICAgU0VDVVJJVFkgQ09OU0lERVJBVElPTlMNCiAg ICAgDQogICAgIEFQUEVORElYDQogICAgIEEuICAgQUNLTk9XTEVER0VNRU5UUw0KICAgICBCLiAg IFJFRkVSRU5DRVMNCiAgICAgQy4gICBBVVRIT1InUyBBRFJFU1MNCiAgICAgRC4gICBGVUxMIENP UFlSSUdIVCBTVEFURU1FTlQNCg0KSkI+IFRPQyBzaG91bGQgaGF2ZSBwYWdlIG51bWJlcnMuDQoN Cg0KICAgICBJTlRST0RVQ1RJT04NCiAgICAgDQogICAgIENsYXNzaWMgSW50ZXJuZXQgdHJhbnNw b3J0IHByb3RvY29scyB1c2UgYSBzaW5nbGUgc291cmNlIElQDQogICAgIGFkZHJlc3MgYW5kIGEg c2luZ2xlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MsIGFzIHBhcnQgb2YgdGhlDQogICAgIGlkZW50 aWZpY2F0aW9uIGZvciBhbiBpbmRpdmlkdWFsIHRyYW5zcG9ydCBkYXRhIGZsb3cuICBGb3INCiAg ICAgZXhhbXBsZSwgVENQIGluY2x1ZGVzIHRoZXNlIGluIGl0cyBkZWZpbml0aW9uIG9mIGEgY29u bmVjdGlvbiBhbmQNCiAgICAgaXRzIGNhbGN1bGF0aW9uIG9mIHRoZSBoZWFkZXIgY2hlY2tzdW0u ICBIZW5jZSBhIGNsYXNzaWMNCiAgICAgdHJhbnNwb3J0IGFzc29jaWF0aW9uIGlzIHRpZWQgdG8g YSBwYXJ0aWN1bGFyIElQIGFkZHJlc3MgcGFpci4NCiAgICAgVGhpcyBpcyBwcm9ibGVtYXRpYyBm b3IgbXVsdGlob21lZCBob3N0cyBhbmQgZm9yIG1vYmlsZSBob3N0cy4NCiAgICAgQm90aCBoYXZl IGFjY2VzcyB0byBtdWx0aXBsZSBJUCBhZGRyZXNzZXMsIGJ1dCB0aGV5IGFyZSBwcmV2ZW50ZWQN CiAgICAgZnJvbSB1c2luZyBtb3JlIHRoYW4gb25lIHdpdGhpbiBhbiBleGlzdGluZyB0cmFuc3Bv cnQgZXhjaGFuZ2UuDQogICAgIEZvciBhIGhvc3QgdG8gdXNlIGEgZGlmZmVyZW50IElQIGFkZHJl c3MgcGFpciwgcGFydGljaXBhbnRzIG11c3QNCiAgICAgaW5pdGlhdGUgYSBuZXcgZXhjaGFuZ2Uu ICBJbiB0aGUgY2FzZSBvZiBUQ1AsIHRoaXMgbWVhbnMgYSBuZXcNCiAgICAgY29ubmVjdGlvbi4N CiAgICAgDQogICAgIEluIHJlY2VudCB5ZWFycywgdGhlcmUgaGF2ZSBiZWVuIGVmZm9ydHMgdG8g b3ZlcmNvbWUgbWFueSBvZg0KICAgICB0aGVzZSBsaW1pdGF0aW9ucywgdGhyb3VnaCBkaWZmZXJl bnQgYXBwcm9hY2hlcyBhdCBkaWZmZXJlbnQNCiAgICAgcGxhY2VzIGluIHRoZSBJbnRlcm5ldCBh cmNoaXRlY3R1cmUuIFNvbWUgbW9kaWZ5IHRoZSBJUA0KICAgICBpbmZyYXN0cnVjdHVyZSwgd2l0 aCBlbWJlZGRlZCByZWRpcmVjdGlvbiBzZXJ2aWNlcy4gIFNvbWUgZGVmaW5lDQogICAgIHRyYW5z cG9ydCBlbmhhbmNlbWVudHMgdG8gc3VwcG9ydCBhIHNldCBvZiBhZGRyZXNzZXMgZGlyZWN0bHks DQogICAgIGFuZCBzb21lIGRlZmluZSBhIGxheWVyIGJldHdlZW4gY2xhc3NpYyBJUCBhbmQgY2xh c3NpYyB0cmFuc3BvcnQuDQogICAgIEVhY2ggb2YgdGhlIGV4aXN0aW5nIHByb3Bvc2FscyBoYXMg bm90YWJsZSBsaW1pdGF0aW9ucyBpbg0KICAgICBmdW5jdGlvbmFsaXR5LCBpbXBsZW1lbnRhdGlv biwgZGVwbG95bWVudCBvciB1c2UuIEEgZGlzY3Vzc2lvbiBvZg0KICAgICB0aGUgYXJjaGl0ZWN0 dXJhbCBjaG9pY2VzIGFuZCBzdW1tYXJ5IG9mIGV4aXN0aW5nIG11bHRpYWRkcmVzc2luZw0KICAg ICBwcm9qZWN0cyBpcyBpbiBbQ0hPSUNFXS4NCg0KSkI+IENvbW1lbnRzIGFyZSBwcm92aWRlZCB0 byBbQ0hPSUNFfSBpbiBvdGhlciByZXZpZXcuDQogICAgIA0KICAgICBNdWx0aXBsZSBBZGRyZXNz IFNlcnZpY2UgZm9yIFRyYW5zcG9ydCAoTUFTVCkgc3VwcG9ydHMNCiAgICAgYXNzb2NpYXRpb24g b2YgbXVsdGlwbGUgSVAgYWRkcmVzc2VzIGR1cmluZyB0aGUgbGlmZSBvZiBhbnkNCiAgICAgdHJh bnNwb3J0IGluc3RhbnRpYXRpb24sIGJ5IGRlZmluaW5nIGEgbGF5ZXIgYmV0d2VlbiBJUCBhbmQN CiAgICAgdHJhbnNwb3J0LiBJdCBvcGVyYXRlcyBvbmx5IGluIHRoZSBlbmQgc3lzdGVtcyBhbmQg YWZmZWN0cyBvbmx5DQogICAgIHBhcnRpY2lwYXRpbmcgaG9zdHMuIE1BU1QgZG9lcyBub3QgcmVx dWlyZSBtb2RpZmljYXRpb24gdG8gdGhlDQogICAgIEludGVybmV0IGluZnJhc3RydWN0dXJlIGFu ZCBkb2VzIG5vdCByZXF1aXJlIG1vZGlmaWNhdGlvbiB0byBhbnkNCiAgICAgaG9zdCdzIElQIG9y IHRyYW5zcG9ydCBtb2R1bGVzLCBhbHRob3VnaCBpbXByb3ZlZCBmdW5jdGlvbmFsaXR5DQogICAg IGNhbiBiZSBvYnRhaW5lZCB3aXRoIHNvbWUgY2hhbmdlcy4NCg0KSkI+IEFkZGluZyBhIGxheWVy IGJldHdlZW4gdGhlIHRyYW5zcG9ydCBhbmQgSVAgbGF5ZXIgdGhhdCBzdXBwb3J0cyB0aGUNCklu dGVybmV0IFByb3RvY29sIHN1aXRlIGlzIG5vdCB0cml2aWFsLCBzaWduaWZpY2FudCB0byBpbXBs ZW1lbnRhdGlvbnMsIGFuZCANCm11c3QgbWFpbnRhaW4gY29oZXNpb24gYmV0d2VlbiB0aGUgdHdv IGxheWVycyByZWdhcmRpbmcgc3RhdGUgb2YgYSANCmNvbm5lY3Rpb24uIA0KICAgICANCiAgICAg RnVydGhlciwgTUFTVCB3b3JrcyB3aXRoIGV4aXN0aW5nIElQdjQgYW5kIElQdjYgdHJhbnNwb3J0 DQogICAgIHNlcnZpY2VzIGFuZCBpdCBpcyB1c2VmdWwgdG8gYW55IHR3byBob3N0cyB0aGF0IHRy eSB0byB1c2UgaXQNCg0KSkI+IFRoZSB0cmFuc3BvcnQgc2VydmljZSBvdGhlciB0aGFuIGNoZWNr c3VtIGlzIG5vIGRpZmZlcmVudCBiZXR3ZWVuIA0KSVB2NCBhbmQgSVB2Ni4gIFRoaXMgc3RhdGVt ZW50IGlzIG1pc3MgbGVhZGluZyB0aGUgcmVhZGVyLg0KDQogICAgIHdpdGggZWFjaCBvdGhlci4g SXQgZG9lcyBub3QgZGVmaW5lIGFueSBuZXcgbmFtaW5nIG9yIGFkZHJlc3NpbmcNCiAgICAgc3Ry dWN0dXJlLiBJdCBoYXMgbm8gYWRkaXRpb25hbCBwYWNrZXQgaGVhZGVyIG92ZXJoZWFkIGFuZA0K ICAgICBtaW5pbWFsIGFkZGl0aW9uYWwgcGFja2V0LXByb2Nlc3Npbmcgb3ZlcmhlYWQuIEl0IGVt cGxveXMNCiAgICAgZXhpc3RpbmcgYWRtaW5pc3RyYXRpdmUgc3RydWN0dXJlcy4gSGVuY2UgTUFT VCBoYXMgYSBsb3cgYmFycmllcg0KICAgICB0byBhZG9wdGlvbiBhbmQgdXNlLCB3aGlsZSBwZXJt aXR0aW5nIG1vcmUgYWR2YW5jZWQgZnVuY3Rpb25zDQogICAgIHdpdGggbW9yZSBleHRlbnNpdmUg YWRvcHRpb24gYW5kIG1vZGlmaWNhdGlvbi4NCg0KSkI+IEFueSBjaGFuZ2VzIHRvIHRoZSBJUCBz dGFjayBvbiBhbnkgaW1wbGVtZW50YXRpb24gcmVxdWlyZXMgDQpleHRlbnNpdmUgcmV2aWV3IGFu ZCBhbmFseXNpcyBhbmQgbXVzdCBiZSBjaGVja2VkIGZvciBwZXJmb3JtYW5jZQ0KY29zdHMgYW5k IGFmZmVjdCB0byB0aGUgcm9idXN0bmVzcyBvZiB0aGF0IG5ldyBjb2RlLiBUaGUgYWJvdmUNCnNo b3VsZCBzdGF0ZSB0aGF0IGZvciB0aGUgY2F1c3VhbCByZWFkZXIuICBBYm92ZSBpbXBsaWVzIG90 aGVyIA0Kd2lzZS4NCiAgICAgDQogICAgIE1BU1QgbWF5IGJlIGludm9rZWQgYXQgYW55IHRpbWUs IGJlZm9yZSBvciBkdXJpbmcgYSB0cmFuc3BvcnQNCiAgICAgYXNzb2NpYXRpb24uIEEgaG9zdCBt YXkgaW5pdGlhdGUgYW5kIGNvbmR1Y3QgYSBjbGFzc2ljLCBzaW5nbGUgSVAtDQogICAgIHBhaXIg VENQIGNvbm5lY3Rpb24uIEl0IG1heSB0aGVuIHNlcGFyYXRlbHkgcXVlcnkgZm9yIHJlbW90ZSBo b3N0DQogICAgIHN1cHBvcnQgb2YgTUFTVCBhbmQgaW5pdGlhdGUgYSBNQVNUIGV4Y2hhbmdlIHRv IGJlIHVzZWQgYnkgdGhhdA0KICAgICBjb25uZWN0aXZpdHkuICBFaXRoZXIgcGFydGljaXBhbnQg aXMgdGhlbiBmcmVlIHRvIGFkZCBvciByZW1vdmUNCiAgICAgYWRkcmVzc2VzLiBPZiBjb3Vyc2Us IHVzZSBvZiBNQVNUIG1heSBpbnN0ZWFkIGJlIHBlcmZvcm1lZCBiZWZvcmUNCiAgICAgYSB0cmFu c3BvcnQgY29udGV4dCBpcyBlc3RhYmxpc2hlZCwgc28gdGhhdCBmdXR1cmUgY29udGV4dHMNCiAg ICAgaW1tZWRpYXRlbHkgaGF2ZSBhY2Nlc3MgdG8gbXVsdGlwbGUgSVAgYWRkcmVzc2VzLg0KDQpK Qj4gU0NUUCBkb2VzIHRoaXMgdmVyeSB3ZWxsIGFuZCBpcyB3ZWxsIGRlZmluZWQgdHJhbnNwb3J0 IA0KcHJvdG9jb2wgd2lkZWx5IGltcGxlbWVudGVkIGFuZCBhdmFpbGFibGUgdG9kYXkgaW4gcHJv ZHVjdHMuDQpJIHVuZGVyc3RhbmQgaXQgaXMgZGlzY3Vzc2VkIGluIENIT0lDRSBidXQgaXQgc2hv dWxkIGJlIA0KbWVudGlvbmVkIGhlcmUgc28gYSByZWFkZXIga25vd3MgdGhlcmUgaXMgYSBzaWdu aWZpY2FudA0KYWx0ZXJuYXRpdmUgYW5kIHdvcmtlZCBvbiBpbiB0aGUgSUVURiBjb21tdW5pdHku IA0KICAgICANCiAgICAgRm9yIGEgbXVsdGlob21lZCBob3N0LCBpdCB3aWxsIGJlIHJlYXNvbmFi bGUgdG8gYXNzb2NpYXRlDQogICAgIG11bHRpcGxlIElQIGFkZHJlc3NlcyB3aXRoIGEgdHJhbnNw b3J0IGNvbnRleHQgYXQgdGhlIHRpbWUgdGhlDQoNCkpCPiBSZXBsYWNlIGNvbnRleHQgd2l0aCBh c3NvY2lhdGlvbiBhYm92ZSBhbmQgdGhyb3VnaG91dCB0aGUgZG9jLg0KDQogICAgIGZpcnN0IGNv bnRleHQgYmV0d2VlbiB0aGF0IGhvc3QtcGFpciBpcyBpbml0aWF0ZWQuICBGb3IgYSBtb2JpbGUN CiAgICAgaG9zdCwgYWRkcmVzc2VzIG1heSBiZSBhZGRlZCBhbmQgcmVtb3ZlZCBhcyB0aGUgaG9z dCBtb3ZlcyBhY3Jvc3MNCiAgICAgdGhlIEludGVybmV0IGZhYnJpYywgYWNxdWlyaW5nIGFuZCBs b3NpbmcgdXNlIG9mIGRpZmZlcmVudCBJUA0KICAgICBhZGRyZXNzZXMuDQoNCkpCPiBSZXBsYWNl IGFjcXVpcmluZy9sb3Npbmcgd2l0aCBhZGRpbmcvcmVtb3ZpbmcuICBSZW1vdmUgImZhYnJpYyIN Cml0IGlzIHJlZHVuZGFudCB3b3JkIG5leHQgdG8gSW50ZXJuZXQgaW4gdGhpcyBjb250ZXh0Lg0K DQogICAgIE92ZXIgdGhlIGxpZmUgb2YgYSBtb2JpbGUgdHJhbnNwb3J0IGNvbnRleHQsDQogICAg IGRpZmZlcmVudCBhZGRyZXNzZXMgbWlnaHQgYmUgYWN0aXZlIGF0IGRpZmZlcmVudCB0aW1lcy4g U3VwcG9ydA0KICAgICBpcyBwcm92aWRlZCBmb3IgY29udGludWF0aW9uIG9mIHNlcnZpY2UgYWNy b3NzIGNvbXBsZXRlDQogICAgIGNvbm5lY3Rpdml0eSBpbnRlcnJ1cHRpb25zIHRvIG1vYmlsZSBo b3N0cywgd2hlbiBhIGhvc3QncyBzZXQgb2YNCiAgICAgYXZhaWxhYmxlIElQIGFkZHJlc3NlcyBi ZWNvbWVzIGVtcHR5IGFuZCB0aGUgaG9zdCBsYXRlciByZS0NCiAgICAgYWNxdWlyZXMgYSB1c2Fi bGUgSVAgYWRkcmVzcy4NCg0KSkI+IFRoZSBhYm92ZSBtb2JpbGUgd29yZGluZyBpcyB2ZXJ5IHBv b3IgaGF2ZSB5b3UgcmVhZCBNSVB2NiANCnRoZSBJRVRGIGhhcyBjbGVhciB0ZXJtcyBhbmQgbWV0 aG9kcyB0byByZWZlciB0byB0aGlzIHBsZWFzZSANCmJlIGNvbnNpc3RlbnQgd2l0aCBvdXIgd29y ayBpbiBvdGhlciBncm91cHMuDQogICAgICAgICAgICAgICANCiAgICAgTk9URTogICAgIFRoZSBN QVNUIHByb3Bvc2FsIGV4cGxvaXRzIHRoZSBjb25zaWRlcmFibGUNCiAgICAgICAgICAgICAgIEhJ UCB3b3JrIGRvbmUgdG8gdW5jb3ZlciB1c2FiaWxpdHkgaXNzdWVzIGFuZA0KICAgICAgICAgICAg ICAgZWRnZSBjb25kaXRpb25zLiAgTUFTVCBzdWdnZXN0cyB0aGUgc2FtZSBjb3JlDQogICAgICAg ICAgICAgICBmdW5jdGlvbmFsaXR5IGFzIEhJUCBhbmQgTElONiwgYW5kIGEgc2ltaWxhcg0KICAg ICAgICAgICAgICAgYXBwcm9hY2gsIGJ1dCB1c2VzIGEgc2ltcGxlciBwcm90b2NvbCwgd2l0aCBh DQogICAgICAgICAgICAgICBzb21ld2hhdCBuYXJyb3dlciBmdW5jdGlvbmFsIGZvY3VzLg0KDQpK Qj4gSSBmaW5kIHRoaXMgdG8gYmUgaGFuZHdhdmluZyBhbmQgcG9saXRpY2FsIHRvIHB1c2ggdGhp cw0Kc3BlYyBpbiB0aGUgc2FtZSB3YXkgdGVjaG5pY2FsbHkgYXMgSElQIGFuZCBMSU42IGFuZCB0 aGlzIA0KaXMgbm90IHRoZSBjYXNlLiAgVGhpcyBzcGVjIGlzIG5vdCBldmVuIGNsb3NlIHRvIHRo ZSB0eXBlDQpvZiB0ZWNobmljYWwgbmFyYXRpdmUgYXMgSElQIGFuZCBMSU42LCBhdCB0aGlzIHRp bWUuIA0KQUxzbyByZWZlcmVuY2VzIGluIHRoaXMgc3BlYyB3aGVyZSB0aGlzIGlzIHByb3ZlbiBv cg0KQ0hPSUNFIHNob3VsZCBiZSBzdXBwb3J0ZWQgb3IgdGhpcyBOT1RFIHNob3VsZCBiZSANCnJl bW92ZWQuDQoNCg0KMS4xLiBUZXJtaW5vbG9neQ0KICAgICANCiAgICAgVGhpcyBwcm9wb3NhbCBj b25zaWRlcnMgYSBtZXRob2QgdGhhdCB3aWxsIGVuYWJsZSBhbiBlbmRwb2ludA0KICAgICAoaG9z dCkgdG8gdXNlIG11bHRpcGxlIGFkZHJlc3NlcyBkdXJpbmcgc2luZ2xlIGFwcGxpY2F0aW9uDQog ICAgIGFzc29jaWF0aW9ucyAoc2Vzc2lvbnMpLg0KICAgICANCiAgICAgIkFnZW50IiByZWZlcnMg dG8gYSBmb3J3YXJkaW5nIHNlcnZpY2UgdGhhdCByZXByZXNlbnRzIGFuDQogICAgIGVuZHBvaW50 IGZvciBtdWx0aWFkZHJlc3NpbmcuDQoNCkpCPiBUaGlzIGlzIGFsbCB0aGF0IGlzIG5lZWRlZCBm b3IgVGVybWlub2xvZ3kgdGhlIGJlbG93IGlzIA0Kbm90IHJlbGF0aXZlLg0KDQogICAgIEZvciBt b2JpbGl0eSwgdGhlIGFnZW50IHJlc2lkZXMgb24NCiAgICAgdGhlICJob21lIiBuZXR3b3JrIGFu ZCByZWxheXMgZGF0YWdyYW1zIHRvIHRoZSBlbmRwb2ludHMgYWN0dWFsDQogICAgIGxvY2F0aW9u IG9uIHRoZSBJbnRlcm5ldC4gIFRoZSBlbmRwb2ludHMgYXJlIG1vZGlmaWVkIHRvIHN1cHBvcnQN CiAgICAgdGhpcyBmb3J3YXJkaW5nIHRlY2huaXF1ZS4gRm9yIG11bHRpaG9taW5nLCBhbiBhZ2Vu dCBoaWRlcyB0aGUNCiAgICAgcHJlc2VuY2Ugb2YgbXVsdGlwbGUgYWRkcmVzc2VzIGZyb20gdGhl IGVuZHBvaW50IGxvY2F0ZWQgb24gdGhlDQogICAgIGxvY2FsIG5ldHdvcmsuDQogICAgIA0KICAg ICAiTW9iaWxpdHkiIHJlZmVycyB0byB0aGUgYXZhaWxhYmlsaXR5IG9mIGRpZmZlcmVudCBhZGRy ZXNzZXMgb3Zlcg0KICAgICB0aW1lLg0KDQpKQj4gU2FtZSBjb21tZW50IGFzIGFib3ZlLiAgVGhp cyBpcyBjb21wbGV0ZWx5IGRpZmZlcmVudCB0aGFuIGV2ZXJ5b25lDQplbHNlcyBkZWZpbml0aW9u IG9mIG1vYmlsaXR5IGluIHRoZSBJRVRGIEkga25vdyBidXQgb2sgaXRzIHlvdXIgc3BlYy4NCg0K ICAgICBUaGlzIG1heSBldmVuIGluY2x1ZGUgZGlzY29udGludWl0aWVzLCB3aXRoIG5vIGF2YWls YWJsZQ0KICAgICBhZGRyZXNzZXMsIGF0IHRpbWVzLiBJdCBhbHNvIG1heSBpbmNsdWRlIG92ZXJs YXBwaW5nIGF2YWlsYWJpbGl0eQ0KICAgICBvZiBhZGRyZXNzZXMuIEludGVyZXN0aW5nbHksIHRo aXMgbG9va3MgdGhlIHNhbWUgYXMgbXVsdGlob21pbmcuDQogICAgICANCiAgICAgIk11bHRpaG9t aW5nIiByZWZlcnMgdG8gdGhlIGF2YWlsYWJpbGl0eSBvZiBtdWx0aXBsZSBhZGRyZXNzZXMNCiAg ICAgc2ltdWx0YW5lb3VzbHkuDQoNCkpCPiBUaGlzIGlzIGNvbXBsZXRlbHkgd3JvbmcgYW5kIHNl ZSBNdWx0aTYgUmVxdWlyZW1lbnMgZG9jdW1lbnQgZm9yIG9uZQ0KZGVmaW5pdGlvbiBvZiBtdWx0 aWhvbWluZy4gIFNhbWUgY29tbWVudCBhcyBhYm92ZS4NCg0KICAgICBJdCBpcyB0eXBpY2FsbHkg dXNlZCB0byByZWZlciB0byBtdWx0aXBsZSBuZXR3b3JrDQogICAgIGF0dGFjaG1lbnRzIGZvciBh IGhvc3QsIGJ1dCB3b3JrcyBlcXVhbGx5IHdlbGwgZm9yIG11bHRpcGxlDQogICAgIHVwc3RyZWFt IG5ldHdvcmsgYXR0YWNobWVudHMgYnkgdGhlIGxvY2FsIG5ldHdvcmssIHdoZW4gdGhlDQogICAg IGRpZmZlcmVudCB1cHN0cmVhbSBhZGRyZXNzZXMgYXJlIHZpc2libGUgdG8gdGhlIGhvc3QuDQog ICAgIEludGVyZXN0aW5nbHksIG11bHRpaG9tZWQgZW52aXJvbm1lbnRzIG9mdGVuIG11c3Qgc3Vw cG9ydCBkeW5hbWljDQogICAgIGNoYW5nZXMsIHN1Y2ggYXMgd2hlbiBhZGRpbmcgYSBuZXcgdXBz dHJlYW0gcHJvdmlkZXIuIFRoZXJlZm9yZSwNCiAgICAgbXVsdGlob21pbmcgY2FuIGluY2x1ZGUg bW9iaWxpdHkgZmVhdHVyZXMgYW5kIG1vYmlsaXR5IGNhbg0KICAgICBpbmNsdWRlIG11bHRpaG9t aW5nIGZlYXR1cmVzLg0KICAgICANCiAgICAgIlBhdGggZGlzY292ZXJ5IiBwcm92aWRlcyBhIHNl bmRlciB3aXRoIHRoZSBtZWFucyBmb3IgbGVhcm5pbmcNCiAgICAgYWJvdXQgdGhlIGFkZHJlc3Nl cyBmcm9tIHdoaWNoIHRoZXkgY2FuIHNlbmQuDQoNCkpCPiBUaGlzIGlzIGFkZHJlc3MgZGlzY292 ZXJ5IG5vdCBwYXRoIGRpc2NvdmVyeS4gIEJsb2F0aW5nIA0KYW5kIG92ZXJsb2FkaW5nIHRlcm1z IHRvIGJlIHBlcmNlaXZlZCB0byBiZSBzb21ldGhpbmcgb3RoZXIgdGhhbg0Kd2hhdCBpdCBpcyBk b2VzIG5vdCBoZWxwIHRoaXMgc3BlY3MgY2xhcml0eS4NCiAgICAgDQogICAgICJQYXRoIHNlbGVj dGlvbiIgaXMgcmVxdWlyZWQgd2hlbiBtb3JlIHRoYW4gb25lIGFkZHJlc3MgaXMNCiAgICAgYXZh aWxhYmxlIHRvIHRoZSBzZW5kZXIuIEFsdGhvdWdoIHRoZSBzZW5kZXIgaXMgbGltaXRlZCB0bw0K ICAgICBzcGVjaWZ5aW5nIGFuIGFkZHJlc3MsIHJhdGhlciB0aGFuIGEgcGF0aCwgaXQgYXBwZWFy cyB0aGF0DQogICAgIHRoaW5raW5nIG9mIGl0IGFzIHBhdGggc2VsZWN0aW9uIGFpZCBjb25zaWRl cmF0aW9uIG9mIHNvbHV0aW9ucy4NCiAgICAgSW4gZWZmZWN0LCBpdCBmb3JtdWxhdGVzIHRoZSBz ZWxlY3Rpb24gdGFzayBhcyBiZWluZyBzaW1pbGFyIHRvDQogICAgIHRoZSBqb2Igb2Ygcm91dGVy cy4NCg0KSkI+IFNlbnRlbmNlIGlzIGZhciB0byBsb25nIGFuZCBuZWVkcyB0byBiZSBicm9rZW4g dXAgYXQgYSANCm1pbmltdW0uICBCdXQgaW1wbGVtZW50b3JzIGhhdmUgdG8gY29kZSB0byB3aGF0 IGlzIGluIHRoZSANCnNwZWMgbm90IHdoYXQgaXQgY2FuIG1ha2Ugb25lIHRoaW5rIG9mIGluIGEg c3BlYz8gIEFkZHJlc3MgDQpzZWxlY3Rpb24gaXMgYmV0dGVyLiAgSSBzdXNwZWN0IHlvdXIgdHJ5 aW5nIHRvIGJlIGFsbCB0aGluZ3MNCnRvIGFsbCBwZW9wbGUgd2hvIHJlYWQgdGhpcyBmb3IgaWRl bnRpZmllcnMgYW5kIGxvY2F0b3JzLiBCYWQNCnRvIHN1cHBvcnQgcG9saXRpY3MgaW4gc3BlY3Mu DQoNCg0KICAgICBSb3V0ZSBmb3JtdWxhdGlvbiBpcyBtYXR1cmUgdGVjaG5vbG9neSwgc28NCiAg ICAgdGhhdCB0aGlzIGFzcGVjdCBvZiBtdWx0aWFkZHJlc3MgcHJvY2Vzc2luZyB3aWxsIGJlIHRy YWN0YWJsZSwgaWYNCiAgICAgbm90IHN0cmFpZ2h0Zm9yd2FyZC4NCg0KSkI+IFNvPyAgV2hhdHMg eW91ciBwb2ludD8NCiAgICAgDQogICAgICJSZW5kZXp2b3VzIiBwZXJtaXRzIGEgaG9zdCB0aGF0 IGlzIGluaXRpYXRpbmcgYW4gYXNzb2NpYXRpb24gdG8NCiAgICAgZmluZCB0aGUgdGFyZ2V0IG9m IHRoZSBhc3NvY2lhdGlvbiwgc3VjaCBhcyBhIGNsaWVudCBmaW5kaW5nIGENCiAgICAgc2VydmVy LiAiRmluZGluZyIgbWVhbnMgb2J0YWluaW5nIGEgdmFsaWQgYWRkcmVzcyBmb3IgdGhlIHRhcmdl dC4NCiAgICAgQSBwdWJsaWMgcHJvY2VzcyBpcyByZXF1aXJlZCBmb3IgcmVuZGV6dm91cy4gVGhl IHByaW1hcnkgSW50ZXJuZXQNCiAgICAgbWVjaGFuaXNtIGZvciByZW5kZXp2b3VzIGhhcyBiZWVu IHRoZSBEb21haW4gTmFtZSBTZXJ2aWNlIChETlMpLg0KICAgICBUaGUgRE5TIHVzZWQgbG9uZywg dmFyaWFibGUtbGVuZ3RoIHN0cmluZ3MgKG5hbWVzKSBhbmQgaXMNCiAgICAgdGFpbG9yZWQgZm9y IGxhcmdlLXNjYWxlIHJlbmRlenZvdXMgd2l0aCBuYW1lcyBhbmQgYWRkcmVzc2VzDQogICAgICht YXBwaW5ncykgdGhhdCBjaGFuZ2UgaW5mcmVxdWVudGx5Lg0KDQoNCjEuMi4gRGlzY3Vzc2lvbiBW ZW51ZQ0KICAgICANCiAgICAgRGlzY3Vzc2lvbiBhbmQgY29tbWVudGFyeSBhcmUgZW5jb3VyYWdl ZCBhYm91dCB0aGUgdG9waWNzDQogICAgIHByZXNlbnRlZCBpbiB0aGlzIGRvY3VtZW50LiBUaGUg cHJlZmVycmVkIGZvcnVtIGlzIHRoZQ0KICAgICA8bWFpbHRvOm11bHRpNkBvcHMuaWV0Zi5vcmc+ IG1haWxpbmcgbGlzdCwgZm9yIHdoaWNoIGFyY2hpdmVzIGFuZA0KICAgICBzdWJzY3JpcHRpb24g aW5mb3JtYXRpb24gYXJlIGF2YWlsYWJsZSBhdA0KICAgICA8aHR0cDovL2lldGYub3JnL2h0bWwu Y2hhcnRlcnMvbXVsdGk2LWNoYXJ0ZXIuaHRtbD4uDQoNCg0KMS4zLiBEb2N1bWVudCBIaXN0b3J5 DQogICAgICAgICAgICAgIA0KICAgICAtMDAgICAgICBJbml0aWFsIHByb3Bvc2FsLiBCYXNpYyBj b25jZXB0cy4gSGVhdnkgcmVsaWFuY2UNCiAgICAgICAgICAgICAgb24gU0NUUCBhbmQgRENDUCBm b3Igc3R5bGUgb2Ygc29sdXRpb25zIGFuZA0KICAgICAgICAgICAgICBpbXBsaWVkIGRldGFpbC4N CiAgICAgICAgICAgICAgIA0KICAgICAtMDEgICAgICAgICAgICBTdWJzdGFudGlhbCByZW9yZ2Fu aXphdGlvbi4NCiAgICAgICAgICAgICAgIEFkZGVkIG1vcmUgZGV0YWlsIHRvIE1BU1QsIGluY2x1 ZGluZyByZW5kZXp2b3VzDQogICAgICAgICAgICAgICAgICAgIGFuZCBhZ2VudCwgYWRqdW5jdCBz ZXJ2aWNlcw0KICAgICAgICAgICAgICAgRXh0ZW5kZWQgZGlzY3Vzc2lvbnMgYWJvdXQgYWx0ZXJu YXRpdmUgcHJvcG9zYWxzDQogICAgICAgICAgICAgICAgICAgIGFuZCBhcmNoaXRlY3R1cmFsIGlz c3VlcywgbW92ZWQgdG8gLWFuYWx5c2lzLQ0KICAgICAgICAgICAgICAgICAgICBkcmFmdC4NCiAg ICAgICAgICAgICAgIFJlbW92ZWQgZXhwbGljaXQgU0NUUC9EQ0NQIHVzYWdlLg0KICAgICAgICAg ICAgICAgUmVtb3ZlZCBOQVQgcmVmZXJlbmNlcyBmcm9tIGFyY2hpdGVjdHVyZQ0KICAgICAgICAg ICAgICAgICAgICBkaXNjdXNzaW9ucy4NCg0KDQoNCjIuICAgUkVRVUlSRU1FTlRTDQogICAgIA0K ICAgICBNQVNUIGhhcyBmb3VyIHJlcXVpcmVtZW50czoNCiAgICAgDQogICAgIGEpICAgVGhlIGdv YWwgZm9yIHRoaXMgc2VydmljZSBpcyB0byBzdXBwb3J0IHRoZSB1c2Ugb2YgbXVsdGlwbGUgSVAN CiAgICAgICAgICBhZGRyZXNzZXMgYnkgZWl0aGVyIHBhcnRpY2lwYW50IGluIGEgdHJhbnNwb3J0 IGFzc29jaWF0aW9uLg0KDQpKQj4gQ2hhbmdlIHBhcnRpY2lwYW50IHRvIHBlZXIuDQoNCiAgICAg YikgICBUaGUgc2VydmljZSBzaG91bGQgcmVxdWlyZSBubyBjaGFuZ2VzIHRvIHRoZSBJUCBuZXR3 b3JrDQogICAgICAgICAgaW5mcmFzdHJ1Y3R1cmUsIHRvIHRoZSBJUCBsYXllciBpbiBlbmQtc3lz dGVtcywgb3IgdG8gdGhlIA0KICAgICAgICAgIHRyYW5zcG9ydCBsYXllciBpbiB0aGUgZW5kLXN5 c3RlbXMuDQogICAgICAgICAgDQogICAgICAgICAgQWxsIGtub3dsZWRnZSBvZiB0aGUgc2Vydmlj ZSwgYW5kIGFsbCBhY3Rpdml0eSBhYm91dCBpdCwNCiAgICAgICAgICBtdXN0IHJlc2lkZSBvbmx5 IGluIHRoZSBlbmQtc3lzdGVtcyB1c2luZyBpdC4gSW4gb3JkZXIgdG8NCiAgICAgICAgICBhdm9p ZCBzdGFydC1vZi1hc3NvY2lhdGlvbiBvcGVyYXRpb24sIHRoZSBzZXJ2aWNlIG11c3QNCiAgICAg ICAgICBzdXBwb3J0IG9wZXJhdGlvbiBvZiBjbGFzc2ljIHRyYW5zcG9ydCBhc3NvY2lhdGlvbnMs IHdpdGgNCiAgICAgICAgICBwb3N0LWhvYyBpbnRyb2R1Y3Rpb24gb2YgdGhlIG11bHRpYWRkcmVz cyBtZWNoYW5pc20uDQogICAgIA0KICAgICBjKSAgIFRoZSBzZXJ2aWNlIG11c3QgYmUgcmVzaWxp ZW50IGFnYWluc3QgY2xhc3NpYywgYmFzaWMgc2VjdXJpdHkNCiAgICAgICAgICB0aHJlYXRzLCBl c3BlY2lhbGx5IHNwb29maW5nIChhc3NvY2lhdGlvbiBoaWphY2tpbmcpLg0KDQogICAgIGQpICAg VGhlIHNlcnZpY2UgbXVzdCBvcGVyYXRlIGFjcm9zcyBhZG1pbmlzdHJhdGl2ZSBhbmQgb3BlcmF0 aW9uYWwNCiAgICAgICAgICBib3VuZGFyaWVzIGFuZCBhY3Jvc3MgYWRkcmVzcyB0cmFuc2xhdGlv biBib3VuZGFyaWVzIChOQVQpLg0KDQoNCg0KMy4gICBQUk9UT0NPTA0KICAgICANCiAgICAgVGhp cyBzZWN0aW9uIGRpc2N1c3NlcyBNQVNUIG9wZXJhdGlvbnMgYmV0d2VlbiBwYXJ0aWNpcGF0aW5n DQogICAgIGhvc3RzLg0KDQoNCjMuMS4gVHJhbnNhY3Rpb24gbW9kZWwNCiAgICAgDQogICAgIE1B U1QgdXNlcyBhIHNpbXBsZSByZXF1ZXN0L3Jlc3BvbnNlLiBFYWNoIHJlcXVlc3QgcmVjZWl2ZXMg YQ0KICAgICByZXNwb25zZS4gVGhlIHJlc3BvbnNlIGZvcm1zIHRoZSBiYXNpcyBvZiBNQVNUIHRy YW5zYWN0aW9uDQogICAgIHJlbGlhYmlsaXR5LiAgQSByZXF1ZXN0IGlzIHJldHJhbnNtaXR0ZWQg d2hlbiBhIHJlc3BvbnNlIGlzIG5vdA0KICAgICByZWNlaXZlZC4gIFJldHJhbnNtaXNzaW9uIHJ1 bGVzIHVzZSB0aGUgdXN1YWwgZXhwb25lbnRpYWwNCiAgICAgYmFja29mZi4NCg0KSkI+IEhvdyBh cmUgdGhlIHJlcXVlc3QvcmVzcG9uc2UgdHJhbnNtaXR0ZWQ/DQogICAgICAgICAgICAgICAgICAg DQogICAgIDxTVEFURSAgICAgICAgQXMgZ3VpZGFuY2UgYWJvdXQgdGhlIGFzc29jaWF0aW9uDQog ICAgIERJQUdSQU0+ICAgICAgcmVsYXRpb25zaGlwIGJldHdlZW4gdHdvIHBhcnRpY2lwYXRpbmcg TUFTVA0KICAgICAgICAgICAgICAgICAgIGhvc3RzLCBTQ1RQIFNlY3Rpb24gNCwgIlNDVFAgQXNz b2NpYXRpb24NCiAgICAgICAgICAgICAgICAgICBTdGF0ZSBEaWFncmFtIiBwcm92aWRlcyBhIHVz ZWZ1bCwgc3RhcnRpbmcNCiAgICAgICAgICAgICAgICAgICBmcmFtZXdvcmsuIFNlZSBbU0NUUE1P Ql0gZm9yIGRpc2N1c3Npb24gb2YNCiAgICAgICAgICAgICAgICAgICBtb2JpbGl0eSBlbmhhbmNl bWVudHMgdGhhdCBhcmUgYXBwbGljYWJsZQ0KICAgICAgICAgICAgICAgICAgIHRvIE1BU1QuDQoN CkpCPiBJIHJlYWxseSBoYXZlIGFuIGlzc3VlIHdpdGggdGhpcy4gIFB1dCBhIE1BU1QgZGlhZ3Jh bSBpbiBoZXJlDQp0aGlzIGlzIHRoZSBmaXJzdCByZWZlcmVuY2UgdG8gU0NUUCBpbiB0aGUgc3Bl YyBub3cuICBNQVNUIHNwZWMgDQpzaG91bGQgYnVpbGQgYW5kIHNob3cgaXRzIG93biBzdGF0ZSBk aWFncmFtLg0KDQpKQj4gQWxzbyB0aGlzIHNlY3Rpb24gMywxIG5lZWRzIHRvIGRpc2N1c3MgdGhl IHRyYW5zYWN0aW9uIG1vZGVsIGFuZCBpcw0KY29tcGxldGVseSBtaXNzaW5nIGhlcmUuIEl0IGlz IG5vdCBkaXNjdXNzZWQgZnVydGhlciBkb3duIGluIHRoZSBzcGVjDQplaXRoZXIuICBUaGlzIGlz IGEgaHVnZSBob2xlLg0KDQoNCjMuMi4gQXNzb2NpYXRpb24gQXR0cmlidXRlcw0KICAgICANCiAg ICAgQW4gTUFTVCBhc3NvY2lhdGlvbiBpcyBiZXR3ZWVuIGEgcGFpciBvZiBob3N0cywgZGVmaW5l ZCBieQ0KICAgICBlbmRwb2ludCBpZGVudGlmaWVycywgYW4gYXNzb2NpYXRpb24gbGFiZWwgYW5k IGEgdHJhbnNhY3Rpb24NCiAgICAgc2VxdWVuY2UgaWRlbnRpZmllci4NCiAgICAgDQogICAgIEl0 IGNvbXByaXNlcyBhIGRvbWFpbiBuYW1lIGRvdWJsZSwgYW4gQXNzb2NpYXRpb24gTm9uY2UgZG91 YmxlLA0KICAgICBhbmQgYSB0cmFuc2FjdGlvbiBzZXF1ZW5jZSBudW1iZXIgKFRTTikgZG91Ymxl Og0KICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgIEVuZHBvaW50ICAgICAgIEds b2JhbGx5IHVuaXF1ZSwgbWFjcm8tbGFiZWxzDQogICAgICAgICAgaWRlbnRpZmllcnM6ICAgY29t cHJpc2luZyBhIGRvbWFpbiBuYW1lIGZvciBlYWNoIGhvc3QNCiAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICBFbmRwb2ludCAgICAgICBBc3NvY2lhdGlvbiBub25jZSwgd2l0aCBj cnlwdG9ncmFwaGljDQogICAgICAgICAgYXNzb2NpYXRpb24gICAgcHJvdGVjdGlvbiBhZ2FpbnN0 IGhpamFja2luZy4gSXQgaXMgYW4NCiAgICAgICAgICBsYWJlbDogICAgICAgICBpbnRlcm5hbCBp ZGVudGlmaWVyIGZvciB0aGUgTUFTVA0KICAgICAgICAgICAgICAgICAgICAgICAgIGFzc29jaWF0 aW9uOyBpdCBjb21wcmlzZXMgYSByYW5kb20NCiAgICAgICAgICAgICAgICAgICAgICAgICB2YWx1 ZSwgc3VjaCBhcyBkZWZpbmVkIGluIFNlY3Rpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICA2 LjQuMiwgIkNvbm5lY3Rpb24gTm9uY2UgRmVhdHVyZSIgYW5kDQogICAgICAgICAgICAgICAgICAg ICAgICAgdXNlZCBpbiBTZWN0aW9uIDYuNC4zLCAiSWRlbnRpZmljYXRpb24NCiAgICAgICAgICAg ICAgICAgICAgICAgICBPcHRpb24iLCBpbiBbRENDUF0uICBBbHNvIHNlZSBbUkFORF0uDQogICAg ICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgU2VxdWVuY2UgICAgICAgQSBUcmFuc2Fj dGlvbiBTZXF1ZW5jZSBOdW1iZXIgKFRTTikNCiAgICAgICAgICBsYWJlbDogICAgICAgICBpbmRp Y2F0ZXMgZGF0YSBmbG93IGR1cmluZyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICBhc3Nv Y2lhdGlvbiBhbmQgaXMgdXNlZCBmb3IgZGV0ZWN0aW5nDQogICAgICAgICAgICAgICAgICAgICAg ICAgZHVwbGljYXRlcywgZGV0ZWN0aW5nIG1pc3NpbmcgZGF0YSwNCiAgICAgICAgICAgICAgICAg ICAgICAgICBhbmQgY29ycmVsYXRpbmcgcmVzcG9uc2VzDQogICAgIA0KICAgICANCiAgICAgICAg ICAgICAgIA0KICAgICBOT1RFOiAgICAgTW9yZSBjb21wbGV4IGFzc29jaWF0aW9uIGJlaGF2aW9y cyBhcmUNCiAgICAgICAgICAgICAgIHBvc3NpYmxlLCBzdWNoIGFzIHBlcm1pdHRpbmcgc3BlY2lm aWNhdGlvbiBvZg0KICAgICAgICAgICAgICAgYWRkcmVzcyBzdWJzZXRzIGZvciBkaWZmZXJlbnQg dHJhbnNwb3J0DQogICAgICAgICAgICAgICBjb250ZXh0LiBUaGlzIGxldmVsIG9mIHNvcGhpc3Rp Y2F0aW9uIGlzIGJleW9uZA0KICAgICAgICAgICAgICAgdGhlIHNjb3BlIG9mIHRoZSBjdXJyZW50 IGVmZm9ydCwgYnV0IHdpbGwgYmUNCiAgICAgICAgICAgICAgIGludGVyZXN0aW5nIHRvIGV4cGxv cmUgYWZ0ZXIgYSBiYXNpYyBjYXBhYmlsaXR5DQogICAgICAgICAgICAgICBpcyBhY2hpZXZlZC4N Cg0KSkI+IFRoZSBhYm92ZSBpcyBub3QgZGVzY3JpcHRpdmUgZW5vdWdoIGV2ZW4gZm9yIGEgbW9k ZWwNCnBpZWNlIG9mIHdvcmsgbGV0IGFsb25lIGFuZCBhcmNoaXRlY3R1cmUgb3IgaW1wbGVtZW50 YXRpb24NCnNwZWMuDQoNCg0KMy4zLiBUaGUgSU5JVCBPcGVyYXRpb24NCg0KSkI+IFRoZSB0cmFu c2FjdGlvbiBtb2RlbCBuZWVkcyBtb3JlIGRlZmluaXRpb24gYmVmb3JlIHRoaXMgDQpzZWN0aW9u Lg0KICAgICANCiAgICAgQXQgdGhlIGJlZ2lubmluZyBvZiBhIE1BU1Qgc2Vzc2lvbiwgZWFjaCBo b3N0IHNlbmRzIGFuICJpbml0Ig0KICAgICBlbGVtZW50LCB0byBjcmVhdGUgYSBob3N0LXBhaXIg YXNzb2NpYXRpb24gYW5kIGRlZmluZSB0aGUgaW5pdGlhbA0KICAgICBzZXQgb2YgdmFsaWQgYWRk cmVzc2VzIHRoYXQgbWF5IGJlIHVzZWQuIFRoZSBhc3NvY2lhdGlvbiBpcyBmdWxseQ0KICAgICBl c3RhYmxpc2hlZCBhZnRlciBlYWNoIGhvc3QgaGFzIHJlY2VpdmVkIGFuIGFja25vd2xlZGdlbWVu dCB0bw0KICAgICB0aGUgImluaXQiIG9wZXJhdGlvbiB0aGF0IGl0IHNlbnQuDQoNCkpCPiBXaGF0 IGRvZXMgYmVnaW5uaW5nIHRvIGFib3ZlIHJlZmVyIHRvbz8gIEkgYW0gbG9zdD8gSXMgdGhlIGlu aXQNCmluIGEgVENQIHBhY2tldD8gIEEgVURQIHBhY2tldCBldGM/ICANCiAgICAgDQogICAgIFRo ZSAiaW5pdCIgb3BlcmF0aW9uIGluY2x1ZGVzOg0KICAgICAgICAgIA0KICAgICAgICAgICogICAg U2VuZGVyIGFuZCBSZWNlaXZlciBkb21haW4gbmFtZXMNCiAgICAgICAgICAqICAgIEFzc29jaWF0 aW9uIE5vbmNlDQogICAgICAgICAgKiAgICBUU04NCiAgICAgICAgICAqICAgIExpc3Qgb2Ygc2Vu ZGVyIElQdjQgYW5kIElQdjYgYWRkcmVzc2VzDQoNCkpCPiBTbyB0aGUgaG9zdCBhYm92ZSBoYXMg dG8gZ28gb3V0IG9mIGJhbmQgKG5vdGUgaW4gbW9zdCBpbXBsZW1lbnRhdGlvbnMNCnRoYXQgaXMg aW4gdGhlIGtlcm5lbCB3aGVyZSBuZXR3b3JrIHN1YnN5c3RlbXMgZXhpc3QpIGFuZCBmaW5kIHRo ZSBkb21haW4NCm5hbWVzPyBPZiB0aGUgc3JjL2RzdCBhZGRyZXNzPyAgSXRzIG5vdCBjbGVhciBh Ym92ZS4NCg0KSkI+IFlvdSBwcmVzZW50IGEgbW9kZWwgbm90IGEgc3BlYyBvciBhcmNoaWN0ZWN0 dXJlIGlzIHdoYXQgSSB0aGluayBub3cuDQpTQ1RQIGlzIGZ1bGx5IHNwZWNpZmllZCBwcm90b2Nv bCB5b3Ugc2hvdWxkIG5vdCBjb21wYXJlIHRoaXMgdG8gU0NUUA0KaW4gYW55IHdheSBvdGhlciB0 aGFuIGEgbW9kZWwgYW5kIHRoZSBtb2RlbCBuZWVkcyBtb3JlIHdvcmsgaGVyZS4NCg0KMy40LiBU aGUgU0VUIE9wZXJhdGlvbg0KICAgICANCiAgICAgV2hlbiBhIGhvc3Qgd2FudHMgdG8gc3BlY2lm eSBhIG5ldyBsaXN0IG9mIGl0cyBvd24gSVAgYWRkcmVzc2VzLA0KICAgICBzdXBwb3J0ZWQgaW4g dGhpcyBNQVNUIGFzc29jaWF0aW9uIHdpdGggdGhlIG90aGVyIGhvc3QsIGl0IHNlbmRzDQogICAg IGEgIlNFVCIgb3BlcmF0aW9uIHRvIHRoZSBvdGhlciBob3N0Lg0KICAgICANCiAgICAgVGhpcyBm dW5jdGlvbiBpcyBpc29tb3JwaGljIHdpdGggdGhlIElOSVQgb3BlcmF0aW9uLCBleGNlcHQgdGhh dA0KICAgICBpdCB1c2VzIHRoZSBleGlzdGluZyAiQXNzb2NpYXRpb24gTm9uY2UiIGFuZCBjb250 aW51ZXMgdGhlDQogICAgIGV4aXN0aW5nIFRTTiBzZXF1ZW5jZS4NCg0KSkI+IEhvdyBjYW4gaXQg YmUgaXNvbW9ycGhpYyBhbmQgbWFpbnRhaW4gc2FtZSBUU04gc3BhY2U/DQoNCiAgICAgVGhlIGRv bWFpbiBuYW1lcyBtdXN0IGJlIHRoZSBzYW1lIGFzIHdlcmUNCiAgICAgdXNlZCBpbiB0aGUgImlu aXQiIG9wZXJhdGlvbiBmb3IgdGhpcyBhc3NvY2lhdGlvbi4NCiAgICAgDQogICAgIEEgU0VUIG9w ZXJhdGlvbiBtYXkgb2NjdXIgYWZ0ZXIgYSBjb21wbGV0ZSBpbnRlcnJ1cHRpb24gb2YNCiAgICAg c2VydmljZSwgc3VjaCBhcyB3aGVuIGEgbW9iaWxlIGhvc3QgaGFzIG5vdCBoYWQgY29ubmVjdGl2 aXR5IGZvcg0KICAgICBhIHRpbWUsIGFuZCB0aGVuIHJlYWNxdWlyZXMgYWNjZXNzIHRvIHRoZSBu ZXR3b3JrLiAgSW4gdGhpcyBjYXNlLA0KICAgICB0aGUgc2V0IG9mIHNlbmRlciBhZGRyZXNzZXMg aXMgbGlrZWx5IHRvIGhhdmUgbm8gbWVtYmVycyBpbg0KICAgICBjb21tb24gd2l0aCB0aGUgc2V0 IHRoYXQgd2FzIHZhbGlkIGJlZm9yZSB0aGUgaW50ZXJydXB0aW9uLg0KICAgICAgICAgICAgICAg IA0KICAgICBOT1RFOiAgICAgIEEgY29tcGxldGUgbGlzdCBvZiB2YWxpZCBhZGRyZXNzZXMgaXMg aW5jbHVkZWQsDQogICAgICAgICAgICAgICAgcmF0aGVyIHRoYW4gc3BlY2lmeWluZyBvbmx5IGlu Y3JlbWVudGFsDQogICAgICAgICAgICAgICAgY2hhbmdlcy4gVGhlIGxpc3Qgb2YgdmFsaWQgYWRk cmVzc2VzIGlzIHNtYWxsDQogICAgICAgICAgICAgICAgYW5kIGRvZXMgbm90IHJlcXVpcmUgdGhl IHN5bmNocm9uaXphdGlvbg0KICAgICAgICAgICAgICAgIGNvbXBsZXhpdHkgb2YgYW4gaW5jcmVt ZW50YWwgZnVuY3Rpb24uDQoNCkpCPiBUaGlzIHNob3VsZCBiZSBtb3JlIHRoYW4gYSBub3RlIGJ1 dCBpbnRlZ3JhbCB0byB0aGUgZGlzY3Vzc2lvbi4NCg0KDQozLjUuIFRoZSBQUk9CRSBPcGVyYXRp b24NCiAgICAgDQogICAgIFN0YXR1cyBvZiB0aGUgYXNzb2NpYXRpb24gaXMgcXVlcmllZCB3aXRo IHRoZSAicHJvYmUiIG9wZXJhdGlvbi4NCiAgICAgSXQgc2VydmVzIHRocmVlIGZ1bmN0aW9uczoN Cg0KSkI+IFdoaWNoIG5vZGVzIGFyZSB5b3Ugc3BlYWtpbmcgb2YgbmVlZHMgdG8gYmUgaW5jbHVk ZWQgZm9yIGNvbnRleHQuDQogICAgICAgICAgDQogICAgICAgICAgKiAgICBQZXJtaXQgYSBzZW5k ZXIgdG8gZGlzY292ZXIgdGhlIElQIGFkZHJlc3MgYW5kIHBvcnQgbnVtYmVyLCANCiAgICAgICAg ICAgICAgIGJlaW5nIHByZXNlbnRlZCB0byBhIHJlY2VpdmVyLCBpZiBzdWJqZWN0IHRvIE5BVCAN CiAgICAgICAgICAgICAgIHRyYW5zZm9ybWF0aW9uczsgdGhlIHJlY2VpdmluZyBNQVNUIHBhcnRp Y2lwYW50IHJlc3BvbmRzIHdpdGggDQogICAgICAgICAgICAgICB0aGUgc2VuZGVyJ3MgSVAgYWRk cmVzcyBhbmQgcG9ydCBudW1iZXIgaXQgcmVjZWl2ZWQgaW4gdGhlIElQIA0KICAgICAgICAgICAg ICAgZGF0YWdyYW0gZm9yIHRoZSBQUk9CRSBvcGVyYXRpb24uDQogICAgICAgIA0KICAgICAgICAg ICogICAgQ29uZmlybSB0aGUgY29udGludWVkIHV0aWxpdHkgb2YgdGhlIGRlc3RpbmF0aW9uIGFk ZHJlc3MgdXNlZCANCiAgICAgICAgICAgICAgIGZvciB0aGUgUFJPQkUgb3BlcmF0aW9uLg0KDQpK Qj4gV2hhdCBkb2VzIGNvbmZpcm0gdGhlIGNvbnRpbnVlZCB1dGlsaXR5IG1lYW4/DQoNCiAgICAg ICAgICAqICAgIFByb3ZpZGUgYW4gYXNzb2NpYXRpb24ga2VlcC1hLWxpdmUuDQoNCkpCPiBIb3cg aXMgdGhpcyBkb25lIGV4YWN0bHk/ICBJIGtub3cgd2hhdCBUQ1Aga2VlcC1hLWxpdmUgaXM/DQog ICAgIA0KICAgICBUaGUgInByb2JlIiBvcGVyYXRpb24gaW5jbHVkZXM6DQogICAgICAgICAgDQog ICAgICAgICAgKiAgICBBc3NvY2lhdGlvbiBOb25jZQ0KICAgICAgICAgICogICAgVFNODQogICAg ICAgICAgKiAgICBTZW5kZXIgYW5kIFJlY2VpdmVyIElQIGFkZHJlc3Nlcw0KICAgICANCiAgICAg VGhlIElQIGFkZHJlc3NlcyBpbiB0aGUgInByb2JlIiBvcGVyYXRpb24gYXJlIHRoZSBzYW1lIGFz IGFyZQ0KICAgICBzcGVjaWZpZWQgYnkgdGhlIHNlbmRlciBpbiB0aGUgY29udGFpbmluZyBJUCBk YXRhZ3JhbS4NCiAgICAgDQogICAgIFRoZSAicHJvYmUgcmVzcG9uc2UiIG9wZXJhdGlvbiBpbmNs dWRlczoNCiAgICAgICAgICANCiAgICAgICAgICAqICAgIEFzc29jaWF0aW9uIE5vbmNlDQogICAg ICAgICAgKiAgICBUU04NCiAgICAgICAgICAqICAgIFJlY2VpdmVkIE1BU1QgUHJvYmUtbGV2ZWwg U2VuZGVyIGFuZCBSZWNlaXZlciBJUCANCiAgICAgICAgICAgICAgIGFkZHJlc3Nlcw0KICAgICAg ICAgICogICAgUmVjZWl2ZWQgSVAtbGV2ZWwgU2VuZGVyIGFuZCBSZWNlaXZlciBJUCBhZGRyZXNz ZXMNCg0KDQozLjYuIFRoZSBTSFVUIE9wZXJhdGlvbg0KICAgICANCiAgICAgVGhlIFNIVVQgb3Bl cmF0aW9uIHRlcm1pbmF0ZXMgdXNlIG9mIE1BU1QgYmV0d2VlbiBhIGhvc3QtcGFpcjsgaXQNCiAg ICAgdXNlcyBhIDMtd2F5IGdyYWNlZnVsIGNsb3NlLCB3aXRoIG5vIGhhbGYtb3BlbiBzdGF0ZS4N CiAgICAgDQogICAgIFRoZSAic2h1dCIgb3BlcmF0aW9uIGluY2x1ZGVzOg0KICAgICAgICAgIA0K ICAgICAgICAgICogICAgQXNzb2NpYXRpb24gTm9uY2UNCiAgICAgICAgICAqICAgIFRTTg0KICAg ICAgICAgICogICAgU2VuZGVyIGFuZCBSZWNlaXZlciBkb21haW4gbmFtZXMNCg0KDQozLjcuIFRo ZSBFUlIgT3BlcmF0aW9uDQogICAgIA0KICAgICBFUlIgZWxlbWVudHMgYXJlIHNlbnQsIGluIE1B U1QsIHdoZW4gdGhlcmUgaXMgYW4gZXJyb3IuDQogICAgIA0KICAgICBUaGUgImVyciIgb3BlcmF0 aW9uIGluY2x1ZGVzOg0KICAgICAgICAgIA0KICAgICAgICAgICogICAgQXNzb2NpYXRpb24gTm9u Y2UNCiAgICAgICAgICAqICAgIFRTTg0KICAgICAgICAgICogICAgRXJyb3IgaW5mb3JtYXRpb24N Cg0KSkI+IEFsbCBvZiB0aGUgYWJvdmUgc2VjdGlvbiBuZWVkcyBtb3JlIGRlc2NyaXB0aW9uIGFu ZCB0ZWNobmljYWwgZGVwdGggDQp3aXRoIGV4cGxhbmF0aW9uIGFuZCBuZWVkcyB0byBiZSBleHBh bmRlZC4gSXQgaXMgcXVpdGUgdW5jbGVhci4NCg0KDQoNCjQuICAgVFJBTlNGRVIgU0VSVklDRQ0K ICAgICANCiAgICAgVGhlIE1BU1QgY29udHJvbCBleGNoYW5nZSBoYXMgbW9kZXN0IHRyYW5zZmVy ICh0cmFuc3BvcnQpDQogICAgIHJlcXVpcmVtZW50cywgZXhjZXB0IHRoYXQgaXQgbXVzdCBpdHNl bGYgYmUgYWJsZSB0byBvcGVyYXRlIGJ5DQogICAgIHVzaW5nIG11bHRpcGxlIElQIGFkZHJlc3Nl cyBmb3IgZWFjaCBob3N0LiAgVHJhbnNhY3Rpb25zIGFyZQ0KICAgICBzbWFsbCBhbmQgYXJlIGV4 cGVjdGVkIHRvIGJlIGluZnJlcXVlbnQuICBIb3dldmVyIHRoZXkgbXVzdCBiZQ0KICAgICByZWxp YWJseSBkZWxpdmVyZWQsIGFuZCB0aGV5IG11c3QgYmUgc2VjdXJlLCB3aXRoIHJlc3BlY3QgdG8N CiAgICAgcmVkaXJlY3Rpb24gYW5kIHJlcGxheSBhdHRhY2tzIGJ5IHRoaXJkIHBhcnRpZXMuDQog ICAgIA0KICAgICBBIHNpbXBsZSB1c2Ugb2YgVURQIHdpbGwgc3VmZmljZSwgd2l0aCBNQVNUIHJl c3BvbnNlcyBwcm92aWRpbmcNCiAgICAgdGhlIG5lZWRlZCB0cmFuc2ZlciBhY2tub3dsZWRnZW1l bnQuIFRoZSBmdWxsIHNwZWNpZmljYXRpb24gd2lsbA0KICAgICBwcm92aWRlIGZvciByZXRyYW5z bWlzc2lvbiBjb250cm9scy4NCg0KSkI+IE9rIHRoZW4gY2FsbCB0aGlzIGEgbW9kZWwuDQogICAg IA0KICAgICBTZWN1cml0eSBpcyBidWlsdCBpbnRvIHRoZSBNQVNUIHByb3RvY29sLCByYXRoZXIg dGhhbiBpdHMNCiAgICAgdHJhbnNmZXIgc2VydmljZS4NCg0KSkI+IFRodXMgZmFyIEkgc2VlIG5v IHByb3RvY29sIGRlZmluZWQgZm9yIE1BU1Qgc28gSSBkb24ndCBrbm93DQpob3cgdG8gZ2F1Z2Ug d2hhdCB0aGF0IG1lYW5zIGFuZCB2ZXJpZnkgdGhpcyBpcyB0cnVlIGZyb20gcmVhZGluZw0KdGhp cyBzcGVjLg0KDQoNCg0KNS4gICBTT1VSQ0UgVkFMSURBVElPTg0KICAgICANCiAgICAgVGhlIG1p bmltYWwgbGV2ZWwgb2YgaW1wbGljaXQgc291cmNlIHZhbGlkYXRpb24gdGhhdCBleGlzdHMNCiAg ICAgd2l0aGluIGV4aXN0aW5nIHRyYW5zcG9ydCBzZXJ2aWNlcycgdXNlIG9mIElQIGlzIGVsaW1p bmF0ZWQgd2l0aA0KICAgICBtdWx0aWFkZHJlc3NpbmcuICBUaGlzIGludml0ZXMgaGlqYWNraW5n IGF0dGFja3MuDQoNCkpCPiBVaC4uLi4uLi4uLmhlbHAgbWUgaG93IGRvIHlvdSBub3QgdXNlIElQ IGFnYWluPz8/Pz8/Pz8/Pz8/Pz8NCk5vdCBjbGVhciB3aGF0IHlvdXIgdHJ5aW5nIHRvIGRlZmlu ZSBvciBzYXkuDQogICAgIA0KICAgICBBdCB0aGUgc3RhcnQgb2YgYW4gYXNzb2NpYXRpb24sIE1B U1QgZXN0YWJsaXNoZXMgYXNzb2NpYXRpb24NCiAgICAgbm9uY2UgdGhhdCBpcyB1c2VkIGZvciBs YXRlciBleGNoYW5nZXMuICBUaGlzIG5vbmNlIGlzIGNyZWF0ZWQNCiAgICAgd2hpbGUgb25seSBv bmUgYWRkcmVzcyBpcyBpbiBmb3JjZS4NCiAgICAgDQogICAgIFRoZSBtZXRob2Qgb2YgZXN0YWJs aXNoaW5nIHRoZSBub25jZSB3aWxsIGZvbGxvdyB0aGUgbGluZXMgb2YNCiAgICAgUEJLLCBTQ1RQ IG9yIERDQ1AsIGFzIGRpY3RhdGVkIGJ5IHRoZSBsaW1pdGVkIHNlY3VyaXR5DQogICAgIHJlcXVp cmVtZW50cyB0byBwcmV2ZW50IGhpamFja2luZy4NCg0KDQoNCjYuICAgUkVOREVaVk9VUw0KICAg ICANCiAgICAgSG93IGRvZXMgb25lIGVuZHBvaW50IGZpbmQgYW5vdGhlcj8gVGhlIGN1cnJlbnQg YW5zd2VyIGlzIEROUy4NCiAgICAgSG93ZXZlciBtdWx0aWFkZHJlc3NpbmcgaW50cm9kdWNlcyBz b21lIGNoYWxsZW5nZXMuIENsYXNzaWMgRE5TDQogICAgIHVzZSBwZXJtaXRzIGZpbmRpbmcgYSBz ZXQgb2YgYWRkcmVzc2VzIGFzc29jaWF0ZWQgd2l0aCBhIGRvbWFpbg0KICAgICBuYW1lLiBGb3Ig ZmluZGluZyBhIHN0YXRpYywgbXVsdGlob21lZCB0YXJnZXQsIHRoaXMgaXMgcHJvYmFibHkNCiAg ICAgc3VmZmljaWVudC4gVGhlIGZhY3QgdGhhdCB0aGUgaW5pdGlhdG9yIGlzIG1vYmlsZSBjYW4g YmUNCiAgICAgY29tbXVuaWNhdGVkIHRvIHRoZSB0YXJnZXQgYnkgdGhlIGluaXRpYXRvci4NCg0K SkI+IFRoaXMgbWVhbnMgbm9kZXMgYXJlIGRvaW5nIEROUyBsb29rdXBzIHR3aWNlIG9yIGluIGEg dGhlIG1vZGVsIA0KTUFTVCBmb3JjZXMgYWRkaXRpb25hbCBuYW1lIHNlcnZpY2UgbG9va3VwIG9u Y2UgcG90ZW50aWFsbHkgaW4gDQp1c2VyIHNwYWNlIHRvIGdldCB0aGUgYWRkcmVzcyBub3cgaW4g dGhlIGtlcm5lbCB0byBnZXQgYW5vdGhlcg0KYWRkcmVzcy4gIER1cmluZyBhIFRDUCB0cmFuc2Fj dGlvbiB0aGF0IGNvdWxkIGJlIGEgcHJvYmxlbSANCmVzcGVjaWFsbHkgd2hlbiBhIG5vZGUgaXMg bW92aW5nIGF0IDEwMDAgbXBoLg0KICAgICANCiAgICAgSG93ZXZlciB3aGVuIHRoZSB0YXJnZXQg aXMgbW9iaWxlLCBhbiBhZGRpdGlvbmFsIHN1cHBvcnQNCiAgICAgbWVjaGFuaXNtIGlzIG5lZWRl ZC4gVGhpcyBzZWN0aW9uIGRlZmluZXMgYW4gYWRqdW5jdCBzZXJ2aWNlIHRvDQogICAgIGZpbmRp bmcgbW9iaWxlIHRhcmdldHMuDQoNCkpCPiBPSyBzbyBub3cgeW91IGhhbmQgd2F2ZS4gIEp1c3Qg dGFrZSBtb2JpbGl0eSBvdXQgb2YgdGhpcyBzcGVjIGlzDQpteSBhZHZpY2UuDQoNCg0KNi4xLiBE TlMNCiAgICAgDQogICAgIFJlbmRlenZvdXMgd2l0aCBtb2JpbGUgdGFyZ2V0cyBpcyBzdXBwb3J0 ZWQgdGhyb3VnaCBhIHR3by1zdGFnZQ0KICAgICBwcm9jZXNzLiAgQSBkb21haW4gbmFtZSBpcyB1 c2VkIGFzIHRoZSBzdGFibGUsIHB1YmxpYyBFSUQuDQoNCkpCPiBXZSBoYXZlIG5vdCBldmVuIGFn cmVlZCB0byB3aGF0IGFuIEVJRCBpcyBpbiBtdXRsaTYgSSBkb3VidCB5b3VyDQpnb2luZyB0byBn ZXQgYXdheSB3aXRoIHRoaXMgaGVyZS4NCiAgICAgDQogICAgIEFuIFNSViByZWNvcmQgaXMgZGVm aW5lZCB0byByZWZlcmVuY2UgYSBkeW5hbWljICJwcmVzZW5jZSINCiAgICAgc2VydmljZSB0aHJv dWdoIHdoaWNoIGFuIGVuZHBvaW50IGNhbiByZWdpc3RlciBpdHMgY3VycmVudCBzZXQgb2YNCiAg ICAgSVAgYWRkcmVzc2VzLg0KDQpKQj4gRXJycnJycnJycnJyLiBUaGlzIGlzIGZhciB0byBtdWNo IG92ZXJoZWFkIHRvIGRvIGluIGFuIElQIHN0YWNrDQpiZXR3ZWVudCB0aGUgdHJhbnNwb3J0IGFu ZCBJUCBsYXllci4gIFNDVFAgd2FzIGludmVudGVkIGFuZCBidWlsdCB0bw0Kc29sdmUgdGhpcyBw cm9ibGVtLiAgRGF2ZSB0YmlzIGlzIGEgaGFjayBqb2IgdG8gdGhlIHN0YWNrLg0KDQoNCg0KNi4y LiBQcmVzZW5jZQ0KICAgICANCiAgICAgVGhlIHJlcXVpcmVtZW50IHRvIGRpc2NvdmVyIGN1cnJl bnQgSVAgYWRkcmVzc2VzIGZvciBhbiBlbmRwb2ludCwNCiAgICAgYW5kIHRvIGJlIG5vdGlmaWVk IHdoZW4gdGhleSBjaGFuZ2UsIHN1aXRzIGV4aXN0aW5nIHByZXNlbmNlDQogICAgIHNlcnZpY2Ug bW9kZWxzIHJhdGhlciBuaWNlbHkuDQogICAgIA0KICAgICBNQVNUIGlzIGRlZmluZWQgdG8gdXNl IHRoZSBwcmVzZW5jZSBzZXJ2aWNlIGF2YWlsYWJsZSB0aHJvdWdoDQogICAgIFtYTVBQXS4gVGhl IGRlZmluaXRpb24gb2YgdGhpcyBtZWNoYW5pc20gd2lsbCBiZSBmb3Igc3RhbmRhcmQNCiAgICAg WE1QUCwgd2l0aCBzb21lIGFkZHJlc3NpbmcgY29udmVudGlvbnMgdG8gc3BlY2lmeSB0aGUgdGFy Z2V0DQogICAgIHN5c3RlbSdzIGRvbWFpbiBuYW1lIGF0IGEgcGFydGljdWxhciBwcmVzZW5jZSBz ZXJ2ZXIuDQogICAgIA0KICAgICBEZXZlbG9wbWVudCBvZiB0aGUgZGV0YWlsZWQgc3BlY2lmaWNh dGlvbiBtYXkgbGVhZCB0byBjaG9vc2luZyBhDQogICAgIGRpZmZlcmVudCBzZXJ2aWNlLiBIb3dl dmVyLCBkeW5hbWljIHJlbmRlenZvdXMgaXMgYW4gYWRqdW5jdA0KICAgICBmdW5jdGlvbiBmb3Ig TUFTVC4gIEhlbmNlIGl0IGlzIG5vdCBlc3NlbnRpYWwgdG8gZGV2ZWxvcCB0aGlzDQogICAgIGNh cGFiaWxpdHkgZm9yIGluaXRpYWwgdXNlIG9mIHRoZSBzZXJ2aWNlLg0KDQpKQj4gSGF2ZSB0byBz ZWUgdGhlIHVzZSBjYXNlIGFuZCBzcGVjIGFkZGl0aW9uLiAgTm8gY29tbWVudC4NCg0KDQoNCjcu ICAgUEFUSCBTRUxFQ1RJT04NCiAgICAgDQogICAgIEhhdmluZyBnYWluZWQgYWNjZXNzIHRvIHRo ZSBsaXN0IG9mIElQIGFkZHJlc3NlcyBieSB3aGljaCBhDQogICAgIGRlc3RpbmF0aW9uIGhvc3Qg bWF5IGJlIHJlYWNoZWQsIGEgc2VuZGVyIG11c3Qgc2VsZWN0IG9uZSwgZm9yDQogICAgIHRoZSBu ZXh0IHNldCBvZiBkYXRhLiBBcyB3aXRoIGFueSBkeW5hbWljIHJlc291cmNlIHNlbGVjdGlvbg0K ICAgICBvcHBvcnR1bml0eSwgdGhlIGNob2ljZSBvZiBzY2hlbWVzIGlzIGV4dGVuc2l2ZSBhbmQg Y2FuIGJlIHF1aXRlDQogICAgIHNvcGhpc3RpY2F0ZWQuIEhvd2V2ZXIgdW50aWwgdGhlcmUgaXMg ZXhwZXJpZW5jZSB3aXRoIHRoZSBiYXNpYw0KICAgICBkeW5hbWljcyBvZiB0aGlzIHNlcnZpY2Us IGNvbnNlcnZhdGl2ZSB1c2FnZSBtb2RlbHMgYXJlDQogICAgIGVuY291cmFnZWQuDQogICAgIA0K ICAgICBBcyB3aXRoIFNDVFAsIHRoZSBjb25zZXJ2YXRpdmUgYXBwcm9hY2ggaXMgdG8gY2hvb3Nl IGEgcHJpbWFyeQ0KICAgICBhZGRyZXNzIGFuZCB1c2Ugb3RoZXJzIGFzIGFsdGVybmF0aXZlcyBv bmx5IHRvIGVuc3VyZSByb2J1c3RuZXNzDQogICAgIHRvIHRoZSBhc3NvY2lhdGlvbi4gIFBlcmlv ZGljIHVzZSBvZiB0aGUgUFJPQkUgb3BlcmF0aW9uIHRvIGVhY2gNCiAgICAgYWRkcmVzc2VzIHRo YXQgdGhlIG90aGVyIHNpZGUgcHVycG9ydHMgdG8gaGF2ZSBhdmFpbGFibGUgd2lsbA0KICAgICBw cm92aWRlIGJhc2ljIHBhdGggYXZhaWxhYmlsaXR5IGFuZCBwZXJmb3JtYW5jZSBkYXRhLg0KDQpK Qj4gTm8gY29tbWVudCBob3cgeW91IGNhbiBldmVuIGNvbXBhcmUgdGhpcyB0byBTQ1RQIGlzIGJl eW9uZCBtZS4NClNDVFAgaXMgYSBmaW5lbHkgdHVuZWQgdHJhbnNwb3J0IHByb3RvY29sIHRoaXMg aXMgYXQgYmVzdCBhbiBpZGVhLg0KDQoNCg0KOC4gICBJTVBMRU1FTlRBVElPTg0KICAgICANCiAg ICAgVGhlIE1BU1QgcHJvdG9jb2wgb25seSBwcm92aWRlcyBmb3IgY29udHJvbGxlZCBhbmQgcHJv dGVjdGVkDQogICAgIGV4Y2hhbmdlIG9mIGFkZHJlc3MgbGlzdHMuICBUaGUgdXRpbGl0eSBvZiB0 aGVzZSBsaXN0cyBoaW5nZXMgb24NCiAgICAgdGhlaXIgaW50ZWdyYXRpb24gaW50byBob3N0IG5l dHdvcmtpbmcgc3RhY2sgc2VydmljZXMuDQoNCg0KOC4xLiBUeXBpY2FsIFRyYW5zcG9ydCBJbnRl cmZhY2luZw0KICAgICANCiAgICAgVGhpcyBkaXNjdXNzaW9uIGNvbnNpZGVycyBhZGRpdGlvbiBv ZiBNQVNUIHRvIGFuIGV4aXN0aW5nDQogICAgIEludGVybmV0IHByb3RvY29sIHN0YWNrLiBJdCBp cyBwb3NzaWJsZSB0byBpbnRlZ3JhdGUgTUFTVCBtb3JlDQogICAgIHRpZ2h0bHkgYW5kIGVmZmlj aWVudGx5LCBidXQgdGhpcyBpcyBub3QgYW4gaW1tZWRpYXRlIGNvbmNlcm4gZm9yDQogICAgIGVh cmx5IGFkb3B0aW9uIG9mIHRoZSBzZXJ2aWNlLg0KDQpKQj4gRG8geW91IG1lYW4gcmFwaWQgcHJv dG90eXBpbmcgZm9yIHByb29mIG9mIGNvbmNlcHQgd2hpY2ggaXMgbG9uZw0KYmVmb3JlIGVhcmx5 IGFkb3B0aW9uLg0KICAgICANCiAgICAgTUFTVCBtdXN0IGJlIGFkZGVkIHRvIGEgaG9zdCBpbXBs ZW1lbnRhdGlvbiBvZiBJbnRlcm5ldCBQcm90b2NvbA0KICAgICBhbmQgYXNzb2NpYXRlZCB0cmFu c3BvcnQgc2VydmljZXMsIGluIGEgd2F5IHRoYXQgaXMgdHJhbnNwYXJlbnQNCiAgICAgdG8gdGhl IElQIG1vZHVsZSBhbmQgdGhlIHRyYW5zcG9ydCBtb2R1bGVzLiAgSXQgaXMgaW5qZWN0ZWQNCiAg ICAgYmV0d2VlbiBJUCBhbmQgdHJhbnNwb3J0LiAgSW50ZXJmYWNpbmcgdG8gSVAgdHJhbnNwYXJl bnRseSBpcw0KICAgICBzdHJhaWdodGZvcndhcmQuDQoNCkpCPiBBcyBpbXBsZW1lbnRvciB0aGF0 IGlzIG5vdCBjbGVhciB0byBtZSBmcm9tIHRoaXMgc3BlYz8NCiAgICAgDQogICAgIEZvciBjbGFz c2ljIHRyYW5zcG9ydCBzZXJ2aWNlcyB0aGF0IHVzZSBJUCBhZGRyZXNzZXMsIGl0IGlzDQogICAg IG5lY2Vzc2FyeSB0byBwcmVzZW50IGEgc2luZ2xlLCBjb25zaXN0ZW50IGFkZHJlc3MgZHVyaW5n IHRoZSBsaWZlDQogICAgIG9mIHRoZSBhc3NvY2lhdGlvbi4gIFdoZW4gTUFTVCBpcyBpbnZva2Vk IGFmdGVyIHRoZSBzdGFydCBvZiBhDQogICAgIHRyYW5zcG9ydCBhc3NvY2lhdGlvbiwgdGhlIHRy YW5zcG9ydCBzZXJ2aWNlIHdpbGwgYWxyZWFkeSBoYXZlIGENCiAgICAgcGFydGljdWxhciBhZGRy ZXNzIHRoYXQgaXQgYXNzb2NpYXRlcyB3aXRoIHRoZSBvdGhlciBwYXJ0aWNpcGFudC4NCiAgICAg SW4gdGhpcyBjYXNlLCBpdCBpcyBlYXNpZXN0IHRvIG1hcCB0aGUgcGFja2V0cyBiZWluZyBoYW5k ZWQgdXAgdG8NCiAgICAgdGhlIHRyYW5zcG9ydCBsYXllciwgZnJvbSBhZGRpdGlvbmFsIGFkZHJl c3NlcyBpbnRvIHRoZSBvcmlnaW5hbA0KICAgICBvbmUuDQoNCkpCPiBJIGNhbiBndWVzcyBvay4g IEFyZSB5b3Ugc2F5aW5nIHRoaXMgaXMgYSBjYWxsIG91dCB0byBpbmplY3QgYXMgDQp5b3Ugc2F5 IGFib3ZlIGluIHRoZSBzdGFjaz8gIEkgY291bGQgYXJndWUgdGhpcyBjb3VsZCBiZSBkb25lIA0K aW4gdXNlciBzcGFjZSB0b28uICBCdXQgbm90IG5vdy4NCiAgICAgDQogICAgIEFub3RoZXIgYXBw cm9hY2ggaXMgdG8gbWFrZSBhbGwgZGVzdGluYXRpb24gYWRkcmVzc2VzIGFwcGVhciB0bw0KICAg ICB0aGUgdHJhbnNwb3J0IHNlcnZpY2UgYXMgY29taW5nIGZyb20gYW4gaW50ZXJuYWxseSBhbGxv Y2F0ZWQNCiAgICAgYWRkcmVzcywgc3VjaCBhcyBvbmUgYWxsb2NhdGVkIGluIFtQUklWXS4gIEEg bmV0d29ya2luZyBzb2Z0d2FyZQ0KICAgICBzdGFjayB3b3VsZCB1c2UgcHVibGljIElQIGFkZHJl c3NlcyBmb3IgcmVuZGV6dm91cyBmdW5jdGlvbnMsIGJ1dA0KICAgICB0cmFuc3BvcnQgd291bGQg cmUtdXNlIGFkZHJlc3NlcyBmcm9tIHRoaXMgcHJpdmF0ZSwgaW50ZXJuYWwNCiAgICAgYWRkcmVz cyBzcGFjZS4NCg0KSkI+IFl1Y2suICBUaGF0cyBwdXR0aW5nIE5BVCBpbnRvIG15IHN0YWNrLiAg SSBkb24ndCB0aGluayBzbyBEYXZlLg0KDQoNCjguMi4gTUFTVCB0aHJvdWdoIE5BVA0KICAgICAN CiAgICAgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0aW9uIFtOQVRdIGRldmljZXMgbWFwIG9uZSBh ZGRyZXNzIHNwYWNlDQogICAgIGludG8gYW5vdGhlciwgdHlwaWNhbGx5IGJldHdlZW4gYW4gaW50 cmFuZXQgc2V0IG9mIGhvc3QgYWRkcmVzc2VzDQogICAgIHRvIGEgc21hbGxlciBzZXQgb2YgSW50 ZXJuZXQgYWRkcmVzc2VzLiAgSW4gZWZmZWN0LCB0aGV5IHVzZSBwb3J0DQogICAgIG51bWJlcnMg YXMgYSBtZWFucyBvZiBtYXBwaW5nIGludGVybmFsIGhvc3RzIHRvIHRoZSBzbWFsbGVyIHNldA0K ICAgICBvZiBleHRlcm5hbCBhZGRyZXNzZXMuDQogICAgIA0KICAgICBUaGlzIGNhdXNlcyBwcm9i bGVtcyBmb3IgYW55IHRyYW5zcG9ydCB0aGF0IHBlcmZvcm1zIGVuZC1zeXN0ZW0NCiAgICAgY2Fs Y3VsYXRpb25zIHRoYXQgdXNpbmcgSVAgYWRkcmVzc2VzLiAgVGhlIGVuZCBzeXN0ZW0gZG9lcyB0 aGUNCiAgICAgY2FsY3VsYXRpb25zIG9uIG9uZSBzZXQgb2YgYWRkcmVzc2VzLCBidXQgdGhlIE5B VCBkZXZpY2UgY2hhbmdlcw0KICAgICBhbiBhZGRyZXNzLCBzbyB0aGF0IHRoZSBjYWxjdWxhdGlv biBieSB0aGUgcmVjZWl2aW5nIHBhcnR5IHdpbGwNCiAgICAgbm90IGJlIGNvcnJlY3QuICBIZW5j ZSwgTkFUIGRldmljZXMgYWxzbyBuZWVkIHRvIGtub3cgYWJvdXQNCiAgICAgdHJhbnNwb3J0LWxl dmVsIHVzZSBvZiBJUCBhZGRyZXNzZXMgYW5kIG11c3QgYWRqdXN0IHRoZSB2YWx1ZXMNCiAgICAg Zm9yIHRob3NlIGNhbGN1bGF0aW9ucyBjYXJyaWVkIGluIHRyYW5zcG9ydCAob3IgYWJvdmUpIGhl YWRlcnMuDQogICAgIA0KICAgICBNQVNUIGV4YWNlcmJhdGVzIHRoaXMgc2l0dWF0aW9uLCBzaW5j ZSB0aGUgbWFwcGluZyBiZXR3ZWVuIElQDQogICAgIGFkZHJlc3MgYW5kIHRyYW5zcG9ydCBjYWxj dWxhdGlvbnMgaXMgbW9yZSBjb21wbGljYXRlZC4gIFdoZXJlYXMNCiAgICAgdGhlcmUgdXNlZCB0 byBiZSBvbmx5IG9uZSBJUCBhZGRyZXNzIHRvIHdvcnJ5IGFib3V0LCBub3cgdGhlcmUNCiAgICAg Y2FuIGJlIG1vcmUuDQogICAgIA0KICAgICBOb3RlIHRoZSBzZWN0aW9uIDQuMyBzcGVjaWZpY2F0 aW9uIG9mIHRoZSAicHJvYmUiIG9wZXJhdGlvbiwgdG8NCiAgICAgZGlzY292ZXIgTkFUIHRyYW5z Zm9ybWF0aW9uIG9uIHRoZSBzZW5kZXIncyBhZGRyZXNzLg0KDQpKQj4gTm8gY29tbWVudCBob3Bl ZnVsbHkgTkFUIGlzIGRlYWQgd2l0aCBJUHY2IGZvciBtb3N0IGNhc2VzLg0KDQoNCjguMy4gTUFT VCBBZ2VudA0KICAgICANCiAgICAgTXVsdGlob21pbmcgaXMgb2Z0ZW4gYSBmZWF0dXJlIG9mIGEg bmV0d29yaywgcmF0aGVyIHRoYW4gYSBob3N0Lg0KICAgICBIb3N0cyBvZnRlbiBkbyBub3Qga25v dyB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBJbnRlcm5ldA0KICAgICBjb25uZWN0aW9ucywgZXNw ZWNpYWxseSB3aGVuIHRoZSBsb2NhbCBuZXR3b3JrIHVzZXMgaW50ZXJuYWwNCiAgICAgKHByaXZh dGUpIGFkZHJlc3NpbmcgdGhhdCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgbmV0d29yaydzIHB1Ymxp Yw0KICAgICBhZGRyZXNzLg0KICAgICANCiAgICAgSW4gdGhlc2UgY2FzZXMsIGl0IG1pZ2h0IGJl IHBvc3NpYmxlIGZvciBNQVNUIHRvIGJlIGltcGxlbWVudGVkDQogICAgIGFzIGEgZmVhdHVyZSBv ZiB0aGUgbG9jYWwgbmV0d29yaydzIE5BVCBmdW5jdGlvbiwgcmF0aGVyIHRoYW4gaW4NCiAgICAg dGhlIGVuZC1zeXN0ZW0uIFNpbmNlIHRoZSBOQVQgaXMgYWxyZWFkeSBkb2luZyBhZGRyZXNzDQog ICAgIHRyYW5zbGF0aW9uLCBhZGRpbmcgTUFTVCBvbmx5IHJlcXVpcmVzIHRoYXQgdGhlIE5BVCBx dWVyeSB0aGUNCiAgICAgb3RoZXIgZW5kIG9mIHRoZSBjb21tdW5pY2F0aW9uLCB0byBvYnRhaW4g cGVybWlzc2lvbiB0byBhZGQgTUFTVA0KICAgICBleGNoYW5nZXMgYW5kIG11bHRpcGxlIGFkZHJl c3Nlcy4NCg0K ------_=_NextPart_001_01C3A4F1.7886F12C Content-Type: text/plain; name="bound_rev_draft-crocker-mast-analysis-01.txt" Content-Description: bound_rev_draft-crocker-mast-analysis-01.txt Content-Disposition: attachment; filename="bound_rev_draft-crocker-mast-analysis-01.txt" Content-Transfer-Encoding: base64 ICAgIEFwcGVuZGl4DQogICAgICAgICAgQS4xLiBBY2tub3dsZWRnZW1lbnRzDQogICAgICAgICAg QS4yLiBSZWZlcmVuY2VzDQogICAgICAgICAgQS4zLiBBdXRob3IncyBBZHJlc3MNCiAgICAgICAg ICBBLjQuIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0KDQpKQj4gUGxlYXNlIGhhdmUgcGFnZSBu dW1iZXJzIGZvciB0aGUgVE9DDQoNCg0KDQoNCjEuICAgSU5UUk9EVUNUSU9ODQogICAgICAgICAg DQogICAgICAgICAgIldlIG5lZWQgYSB3YXkgZm9yIHNpdGVzIHRvIGJlIGludGVybmFsbHkgc3Rh YmxlIGV2ZW4NCiAgICAgICAgICB3aGVuIHRoZWlyIHJlbGF0aW9uc2hpcCB0byB0aGUgd29ybGQg YXJvdW5kIHRoZW0NCiAgICAgICAgICBjaGFuZ2VzIGZvciB3aGF0ZXZlciByZWFzb24uIg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIEUu IExlYXINCg0KSkI+IEkgZGlzYWdyZWUuICBDaGFvcyBpcyB0aGUgbmF0dXJhbCBvcmRlciBvZiB0 aGluZ3MsIHRyeWluZyB0byBtYWtlIHRoaW5ncw0Kc3RhYmxlIGluIG5hdHVyZSBtdXRhdGVzIG5h dHVyZXMgcHVycG9zZSBhbmQgcG9sbHV0ZXMgdGhlIHBsYW5ldCBlYXJ0aA0Kd2l0aCBhbGwgc29y dHMgb2YgcHJvYmxlbXMgd2UgbGF0ZXIgZGVhbCB3aXRoLiAgSXQgaXMgYmV0dGVyIHRvIGFkYXB0 IHRvDQpjaGFvcyB0aHJvdWdoIHByb2Nlc2VzIHRoYXQgYWNjZXB0IHRoZSBjaGFvcy4gIFNhbWUg Zm9yIG5ldHdvcmtpbmcuDQogICAgIA0KICAgICBBbiBJUCBBZGRyZXNzIHNlcnZlcyBhcyByZWZl cmVuY2VzIHRvIGEgInBsYWNlIiBvbiB0aGUgSW50ZXJuZXQNCiAgICAgYW5kIHRvIGEgaG9zdCBv biB0aGUgSW50ZXJuZXQuIFRoZXNlIHR3byByb2xlcyBhcmUgZ2VuZXJhbGx5DQogICAgIGxhYmVs ZWQgImxvY2F0b3IiIGFuZCAiaWRlbnRpZmllciIsIHJlc3BlY3RpdmVseS4gU3lzdGVtcyB0aGF0 DQogICAgIHVzZSBJUCBBZGRyZXNzZXMgYXMgaWRlbnRpZmllcnMgdHlwaWNhbGx5IGNhbm5vdCBz dXBwb3J0IGR5bmFtaWMNCiAgICAgY2hhbmdlcyBpbiB0aGUgbWFwcGluZyBiZXR3ZWVuIHRoZSBp ZGVudGlmaWVyIGFuZCB0aGUgbG9jYXRvci4NCiAgICAgRm9yIGV4YW1wbGUsIFRDUCBpbmNsdWRl cyBhIHNpbmdsZSBzb3VyY2UvZGVzdGluYXRpb24gSVAgQWRkcmVzcw0KICAgICBwYWlyIGluIGl0 cyBkZWZpbml0aW9uIG9mIGEgY29ubmVjdGlvbi4gIEhlbmNlIGl0cyB0cmFuc3BvcnQNCiAgICAg YXNzb2NpYXRpb24gaXMgdGllZCB0byB0aGF0IHBhaXIuIFRoaXMgaXMgcHJvYmxlbWF0aWMgZm9y IGhvc3RzDQogICAgIHRoYXQgYXJlIG11bHRpaG9tZWQgb3IgbW9iaWxlLiAgQm90aCBoYXZlIGFj Y2VzcyB0byBtdWx0aXBsZSBJUA0KICAgICBBZGRyZXNzZXMsIGJ1dCB0aGV5IGFyZSBwcmV2ZW50 ZWQgZnJvbSB1c2luZyBtb3JlIHRoYW4gb25lIHdpdGhpbg0KICAgICBhbiBleGlzdGluZyBjb250 ZXh0LCBiZWNhdXNlIHRoZSBjb250ZXh0IGlzIG5hbWVkIGJ5IHRoYXQgcGFpci4NCiAgICAgRm9y IGEgc3lzdGVtIHRvIHVzZSBhIGRpZmZlcmVudCBJUCBBZGRyZXNzIHBhaXIsIHBhcnRpY2lwYW50 cw0KICAgICBtdXN0IGluaXRpYXRlIGEgbmV3IGV4Y2hhbmdlLiAgSW4gdGhlIGNhc2Ugb2YgVENQ LCB0aGlzIG1lYW5zIGENCiAgICAgbmV3IGNvbm5lY3Rpb24uDQoNCkpCPiBNb2JpbGUgaXMgd2lk ZSB0b3BpYyBzdWdnZXN0IHlvdSByZW1vdmUgdGhpcyBmcm9tIHRoZSBpbnRyb2R1Y3Rpb24uDQog ICAgIA0KICAgICBJbiByZWNlbnQgeWVhcnMsIHRoZXJlIGhhdmUgYmVlbiBlZmZvcnRzIHRvIG92 ZXJjb21lIHRoaXMNCiAgICAgbGltaXRhdGlvbiwgdGhyb3VnaCBkaWZmZXJlbnQgYXBwcm9hY2hl cyBhdCBkaWZmZXJlbnQgcGxhY2VzIGluDQogICAgIHRoZSBJbnRlcm5ldCBhcmNoaXRlY3R1cmUu IFNvbWUgYXBwcm9hY2hlcyBtb2RpZnkgdGhlIElQDQogICAgIGluZnJhc3RydWN0dXJlLCB3aXRo IGVtYmVkZGVkIHJlZGlyZWN0aW9uIHNlcnZpY2VzLiAgU29tZSBkZWZpbmUNCiAgICAgdHJhbnNw b3J0IGVuaGFuY2VtZW50cyB0byBzdXBwb3J0IGEgc2V0IG9mIGxvY2F0b3JzIGRpcmVjdGx5LCBh bmQNCiAgICAgc29tZSBkZWZpbmUgYSBsYXllciBiZXR3ZWVuIGNsYXNzaWMgSVAgYW5kIGNsYXNz aWMgdHJhbnNwb3J0LiBUaGUNCiAgICAgcHJpbWFyeSBnb2FsIG9mIHRoZXNlIG11bHRpYWRkcmVz c2luZyBlZmZvcnRzIGlzIHRvIHByZXNlcnZlDQogICAgIGVzdGFibGlzaGVkIGNvbm5lY3Rpb25z IHdoZW4gYW4gSVAgQWRkcmVzcyBjaGFuZ2VzLiBFYWNoIG9mIHRoZQ0KICAgICBleGlzdGluZyBw cm9wb3NhbHMgaGFzIG5vdGFibGUgbGltaXRhdGlvbnMgaW4gZnVuY3Rpb25hbGl0eSwNCiAgICAg aW1wbGVtZW50YXRpb24sIGRlcGxveW1lbnQgb3IgdXNlLg0KDQpKQj4gRXhhY3RseSB3aGljaCBw cm9ibGVtcyBhbmQgd2hpY2ggb25lcyB3ZXJlIGFkZHJlc3NlZCBwbGVhc2UuDQogICAgIA0KICAg ICBUaGlzIHBhcGVyIHJldmlld3MgdGhlIGJhc2ljIHJlcXVpcmVtZW50cyBmb3Igc3VwcG9ydCBv Zg0KICAgICBtdWx0aWFkZHJlc3NpbmcgKG1vYmlsaXR5IGFuZCBtdWx0aWhvbWluZyksIGFuZCB0 aGUgZWZmb3J0cyB0bw0KICAgICBzdXBwb3J0IHRoZW0uIEJhcnJpZXJzIHRvIGFkb3B0aW9uLCBh ZG1pbmlzdHJhdGl2ZSBvdmVyaGVhZCwgYW5kDQogICAgIG9wZXJhdGlvbmFsIGVmZmljaWVuY3kg YXJlIG9mIHBhcnRpY3VsYXIgY29uY2Vybi4gSW4gYWRkaXRpb24sDQogICAgIHRoZSBhbmFseXNp cyBjb25zaWRlcnMgZW5oYW5jZWQgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIHBvc3NpYmxlDQogICAg IGZyb20gdGhlIHVzZSBvZiBtdWx0aWFkZHJlc3NpbmcsIHN1Y2ggYXMgcGVyZm9ybWFuY2UtYmFz ZWQgbG9hZC0NCiAgICAgc2hhcmluZywgYWNyb3NzIHRoZSBkaWZmZXJlbnQgbG9jYXRvcnMgYXZh aWxhYmxlIHRvIGEgbXVsdGlob21lZA0KICAgICBob3N0Lg0KDQpKQj4gUmVtb3ZlIG1vYmlsaXR5 IGFib3ZlIGFuZCBzdGljayB0byBtdWx0aWhvbWluZy4NCg0KDQoxLjEuIFNjZW5hcmlvcw0KICAg ICANCiAgICAgV2hhdCBhcmUgdGhlIHNpdHVhdGlvbnMgYW5kIGNvbmNlcm5zIHRoYXQgYWZmZWN0 IGRlc2lnbiBhbmQgdXNlDQogICAgIG9mIGEgbWVjaGFuaXNtIGZvciB0aGUgc3VwcG9ydCBvZiBt dWx0aWFkZHJlc3Npbmc/DQogICAgICAgICAgDQogICAgICAgICAgU2VjdGlvbiAzIG9mIFtNT0JN SF0sIGhhcyBhbiBleGNlbGxlbnQgZGlzY3Vzc2lvbiBvZiB0aGVzZQ0KICAgICAgICAgIGlzc3Vl cy4NCiAgICAgICAgICBJdCBpcyBpbmNsdWRlZCBoZXJlIGJ5IHJlZmVyZW5jZSB3aXRob3V0IHNl Y3Rpb24gMy4yLg0KICAgICAgICAgIFNlY3Rpb24gMy4yIGNvdmVycyBhbiBpbnRlcmVzdGluZyB0 b3BpYyB0aGF0IGFwcGVhcnMgdG8gYmUNCiAgICAgICAgICBpbmRlcGVuZGVudCBvZiBtdWx0aWFk ZHJlc3NpbmcuDQogICAgICAgICAgVGhlIGluY2x1ZGVkIHRleHQgY29tcHJpc2VzIHRoZSBmb2xs b3dpbmcgc3ViLQ0KICAgICAgICAgIHNlY3Rpb25zOg0KICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAzLiAgICAgVXNhZ2Ugc2NlbmFyaW9zDQogICAgICAgICAgMy4xICAgIEVuZC1ob3N0IG1v YmlsaXR5DQogICAgICAgICAgMy4yICAgIExvY2F0aW9uIHByaXZhY3kg4A0KICAgICAgICAgIDMu MyAgICBFbmQtaG9zdCBtdWx0aS1ob21pbmcNCiAgICAgICAgICAzLjQgICAgU2l0ZSBtdWx0aS1o b21pbmcNCiAgICAgICAgICAzLjUgICAgQ29tYmluZWQgbW9iaWxpdHkgYW5kIG11bHRpLWhvbWlu Zw0KICAgICAgICAgIDMuNiAgICBOZXR3b3JrIHJlbnVtYmVyaW5nDQogICAgICAgICAgMy43ICAg IENvbWJpbmVkIGFsbA0KDQpKQj4gU3BlYyBzaG91bGQgcHV0IHRoaXMgaW4gdGhlIHNwZWMgb3Ig ZGlzY3VzcyBpdCBtb3JlIHRoYW4NCmp1c3RuIHJlZmVyZW5jZS4NCg0KDQoxLjIuIElFVEYgQmFj a2dyb3VuZA0KICAgICANCiAgICAgSGlzdG9yaWNhbGx5LCBJRVRGIGZvY3VzIG9uIG1vYmlsaXR5 IGhhcyBzcGxpdCBiZXR3ZWVuIGluaXRpYWwNCiAgICAgYXR0YWNobWVudCBjb25maWd1cmF0aW9u cywgaW50byBhbiBvdGhlcndpc2Ugc3RhdGljIGVudmlyb25tZW50DQogICAgIHN1Y2ggYXMgYnkg dXNpbmcgREhDUCwgdmVyc3VzIGZvcndhcmRpbmcgbWVjaGFuaXNtcywgc3VjaCBhcyBieQ0KICAg ICBtb2RpZnlpbmcgdGhlIElQIGluZnJhc3RydWN0dXJlIHdpdGggTW9iaWxlIElQLiAgTXVsdGlo b21pbmcgaGFzDQogICAgIGxhcmdlbHkgYmVlbiBpZ25vcmVkLCBleGNlcHQgaW4gcm91dGluZyBw cm90b2NvbCB3b3JrLiBSZWNlbnQNCiAgICAgZWZmb3J0cyBhcmUgcHVyc3VpbmcgZGlyZWN0IGVu aGFuY2VtZW50cyB0byB0cmFuc3BvcnQgb3INCiAgICAgaW5zZXJ0aW9uIG9mIGEgbWFwcGluZyBs YXllciBiZXR3ZWVuIElQIGFuZCB0cmFuc3BvcnQuIFRoZXJlIGhhcw0KICAgICBhbHNvIGJlZW4g YWRqdW5jdCBhY3Rpdml0eSwgcmVsZXZhbnQgdG8gdGhpcyB0b3BpYy4NCiAgICAgDQogICAgIFRo ZSBmb2xsb3dpbmcgc3VtbWFyeSBvZiBJRVRGIGFjdGl2aXRpZXMgZHJhd3Mgb24gdGV4dCBmcm9t IHRoZQ0KICAgICBBYnN0cmFjdHMgb2YgZG9jdW1lbnRzIGZvciB0aG9zZSBhY3Rpdml0aWVzLiBJ biBhZGRpdGlvbiwgdGhlcmUNCiAgICAgaXMgYSB1c2VmdWwgYW5hbHlzaXMgb2YgdGhlIGRpZmZl cmVudCBhcmNoaXRlY3R1cmFsIGFuZCBwcm90b2NvbA0KICAgICBlZmZvcnRzIGlzIGluIFNlY3Rp b24gMywgIkludGVybmV0IFN0YWNrIFBsYWNlbWVudCIgaW4gW05TUkddLg0KICAgICBTcGVjaWZp Y2F0aW9uIGVmZm9ydHMgYXJlIGRpc2N1c3NlZCBpbiBtb3JlIGRldGFpbCBpbiBTZWN0aW9uDQog ICAgICAgICAgDQogICAgICAgICAgVGhlIE5hbWUgU3BhY2UgUmVzZWFyY2ggR3JvdXAgW05TUkdd IGNvbnNpZGVyZWQNCiAgICAgICAgICBtb2RpZmljYXRpb25zIHRvIHRoZSBJbnRlcm5ldCBhcmNo aXRlY3R1cmUsIGluY2x1ZGluZw0KICAgICAgICAgIHdoZXRoZXIgYW4gYWRkaXRpb25hbCBsZXZl bCBvZiBuYW1pbmcgaXMgbmVlZGVkLCBhYm92ZSBsYXllcg0KICAgICAgICAgIDMgYnV0IGJlbG93 IHRoZSBhcHBsaWNhdGlvbiBsYXllci4gUHVycG9zZS1CdWlsdCBLZXlzIFtQQktdDQogICAgICAg ICAgc3BlY2lmaWVzIGEgdGVtcGxhdGUgZm9yIHRoZSB1c2Ugb2Ygc3BlY2lhbGx5IGdlbmVyYXRl ZA0KICAgICAgICAgIHB1YmxpYy9wcml2YXRlIGtleSBwYWlycywgdG8gcHJvdmlkZSBhc3N1cmFu Y2UgdGhhdA0KICAgICAgICAgIHN1Y2Nlc3NpdmUgbWVzc2FnZXMgaW4gdGhlIGNvbW11bmljYXRp b24gY29tZSBmcm9tIHRoZSBzYW1lDQogICAgICAgICAgc291cmNlLiBUaGlzIGlzIGFjY29tcGxp c2hlZCB3aXRob3V0IHRoZSB1c2Ugb2YgZXh0ZXJuYWwNCiAgICAgICAgICBjZXJ0aWZpY2F0aW9u IGF1dGhvcml0aWVzLiBIZW5jZSBpdCBlbnN1cmVzIGF1dGhlbnRpYw0KICAgICAgICAgIGNvbnRp bnVpdHkgZHVyaW5nIGEgc2Vzc2lvbiwgYnV0IGRvZXMgbm90IHByb3ZpZGUgImdsb2JhbCINCiAg ICAgICAgICBvciAiYWJzb2x1dGUiIGF1dGhlbnRpY2F0aW9uLg0KICAgICAgICAgIA0KICAgICAg ICAgIFN0cmVhbSBDb250cm9sIFRyYW5zbWlzc2lvbiBQcm90b2NvbCBbU0NUUF0gaXMgYSByZWxp YWJsZQ0KICAgICAgICAgIHRyYW5zcG9ydCBwcm90b2NvbCBmb3IgbXVsdGlwbGV4ZWQgZGF0YSBz dHJlYW1zLiAgSXQNCiAgICAgICAgICBpbmNsdWRlcyBtb2Rlcm4gbWVjaGFuaXNtcyBmb3Igc2Fm ZSBpbml0aWF0aW9uIG9mIGENCiAgICAgICAgICBjb25uZWN0aW9uLCBhcyB3ZWxsIGFzIHRoZSBu ZWNlc3NhcnkgdG9vbHMgZm9yIHJlbGlhYmlsaXR5DQogICAgICAgICAgYW5kIGNvbmdlc3Rpb24g Y29udHJvbC4gIEl0IGFsc28gaGFzIGEgbWVjaGFuaXNtIGZvcg0KICAgICAgICAgIGNvbW11bmlj YXRpb24gYWNjZXNzIHRvIG11bHRpcGxlIElQIEFkZHJlc3NlcyBiZXR3ZWVuIHRoZQ0KICAgICAg ICAgIHBhcnRpY2lwYXRpb24gaG9zdCBwYWlyLiAgW1RDUC1NSF0gdXNlcyBUQ1Agb3B0aW9ucyB0 bw0KICAgICAgICAgIHN1cHBvcnQgbXVsdGlob21pbmcuIERhdGFncmFtIENvbmdlc3Rpb24gQ29u dHJvbCBQcm90b2NvbA0KICAgICAgICAgIFtEQ0NQXSBpcyBhIHByb3Bvc2FsIGZvciBhIG5ldHdv cmstZnJpZW5kbHksIHVucmVsaWFibGUNCiAgICAgICAgICB0cmFuc3BvcnQtbGV2ZWwgZGF0YWdy YW0gZGVsaXZlcnkgc2VydmljZS4NCiAgICAgICAgICANCiAgICAgICAgICBNb2JpbGUgSVAgd29y ayBoYXMgZGl2aWRlZCBiZXR3ZWVuIElQdjQgYW5kIElQdjYuIFtNSVA0XSBhbmQNCiAgICAgICAg ICBbTUlQNl0gYWxsb3cgYSBub2RlIHRvIGNvbnRpbnVlIHVzaW5nIGl0cyAicGVybWFuZW50IiBo b21lDQogICAgICAgICAgYWRkcmVzcyBhcyBpdCBtb3ZlcyBhcm91bmQgdGhlIGludGVybmV0Lg0K ICAgICAgICAgIA0KICAgICAgICAgIEhvc3QgSWRlbnRpdHkgUHJvdG9jb2wgW0hJUF0gaXMgdXNl ZCB0byBlc3RhYmxpc2ggYSByYXBpZA0KICAgICAgICAgIGF1dGhlbnRpY2F0aW9uIGJldHdlZW4g dHdvIGhvc3RzIGFuZCB0byBwcm92aWRlIGNvbnRpbnVpdHkNCiAgICAgICAgICBvZiBjb21tdW5p Y2F0aW9ucyBiZXR3ZWVuIHRob3NlIGhvc3RzIGluZGVwZW5kZW50IG9mIHRoZQ0KICAgICAgICAg IG5ldHdvcmtpbmcgbGF5ZXIuIFRoZSBbTElONl0gcHJvdG9jb2wgZGVmaW5lcyBhIGxheWVyIHRo YXQNCiAgICAgICAgICBzdXBwb3J0cyBtdWx0aXBsZSBsb2NhdG9ycywgYmV0d2VlbiBJUHY2IGFu ZCB0cmFuc3BvcnQuDQogICAgICAgICAgTXVsdGlwbGUgQWRkcmVzcyBTZXJ2aWNlIGZvciBUcmFu c3BvcnQgW01BU1RdIHN1cHBvcnRzDQogICAgICAgICAgYXNzb2NpYXRpb24gb2YgbXVsdGlwbGUg SVAgQWRkcmVzc2VzIGR1cmluZyB0aGUgbGlmZSBvZiBhbnkNCiAgICAgICAgICB0cmFuc3BvcnQg aW5zdGFudGlhdGlvbiwgYnkgZGVmaW5pbmcgYSBsYXllciBiZXR3ZWVuIElQIGFuZA0KICAgICAg ICAgIHRyYW5zcG9ydC4gSXQgb3BlcmF0ZXMgb25seSBpbiB0aGUgZW5kcG9pbnRzIGFuZCB3b3Jr cyB3aXRoDQogICAgICAgICAgSVB2NCBhbmQgSVB2Ni4NCg0KSkI+IFlvdXIgcG9pbnQgaXM/ICAN Cg0KDQoxLjMuIERpc2N1c3Npb24gVmVudWUNCiAgICAgDQogICAgIERpc2N1c3Npb24gYW5kIGNv bW1lbnRhcnkgYXJlIGVuY291cmFnZWQgYWJvdXQgdGhlIHRvcGljcw0KICAgICBwcmVzZW50ZWQg aW4gdGhpcyBkb2N1bWVudC4gVGhlIHByZWZlcnJlZCBmb3J1bSBpcyB0aGUNCiAgICAgPG1haWx0 bzptdWx0aTZAb3BzLmlldGYub3JnPiBtYWlsaW5nIGxpc3QsIGZvciB3aGljaCBhcmNoaXZlcyBh bmQNCiAgICAgc3Vic2NyaXB0aW9uIGluZm9ybWF0aW9uIGFyZSBhdmFpbGFibGUgYXQNCiAgICAg PGh0dHA6Ly9pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL211bHRpNi1jaGFydGVyLmh0bWw+Lg0KICAg ICAgICAgICAgICAgDQogICAgIE5PVEU6ICAgIFRoZSBlYXJseSBkcmFmdHMgb2YgYSByZXZpZXcg ZG9jdW1lbnQsIGxpa2UgdGhpcywNCiAgICAgICAgICAgICAgYXJlIGNlcnRhaW4gdG8gaGF2ZSBz aWduaWZpY2FudCBlcnJvcnMuICBUaGUNCiAgICAgICAgICAgICAgYXV0aG9yIHN0cm9uZ2x5IHJl cXVlc3RzIGd1aWRhbmNlIGZvciBjbGFyaWZ5aW5nDQogICAgICAgICAgICAgIGFuZCBjb3JyZWN0 aW5nIGFueSBwcm9ibGVtYXRpYyB0ZXh0Lg0KICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg SW4gcGFydGljdWxhciwgdGhvc2Ugd29ya2luZyBvbiB0aGUgcHJvcG9zYWxzIGFuZA0KICAgICAg ICAgICAgICBzcGVjaWZpY2F0aW9ucyBkaXNjdXNzZWQgaGVyZSBhcmUgZW5jb3VyYWdlZCB0bw0K ICAgICAgICAgICAgICBwcm92aWRlIGNvcnJlY3Rpb25zIGFuZCBhZGRpdGlvbmFsIHRleHQsIHRv DQogICAgICAgICAgICAgIGVuc3VyZSBhY2N1cmFjeS4NCg0KDQoNCg0KMS40LiBEb2N1bWVudCBI aXN0b3J5DQogICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgIC0wMCAgICAgICAgICAgICAg ICBEZXJpdmVkIGZyb20gZHJhZnQtY3JvY2tlci1tYXN0LXByb3Bvc2FsLTAwLg0KICAgICAgICAg ICAgICAgICAgICAgICAgRXh0ZW5kZWQgZGlzY3Vzc2lvbnMgYWJvdXQgYWx0ZXJuYXRpdmUgcHJv cG9zYWxzDQogICAgICAgICAgICAgICAgICAgICAgICBhbmQgYXJjaGl0ZWN0dXJhbCBpc3N1ZXMs IHNlcGFyYXRlZCBmcm9tIHRoZSAtDQogICAgICAgICAgICAgICAgICAgICAgICBwcm9wb3NhbC0g ZHJhZnQuDQogICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgIC0wMSAgICAgICAgICAgICAg ICBTdWJzdGFudGlhbCByZXZpc2lvbnMgdG8gYWxsIHNlY3Rpb25zLiAgTW9yZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgY29tcGxldGUgcmV2aWV3IG9mIGVmZm9ydHMuIE1vcmUgZXh0ZW5zaXZl DQogICAgICAgICAgICAgICAgICAgICAgICB0ZXJtaW5vbG9neSBkZWZpbml0aW9ucy4gU2VjdGlv biAzIHJlbmFtZWQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICJDb25zaWRlcmF0aW9ucyIu IE1hdGVyaWFsIHRoYXQgZXZhbHVhdGVzDQogICAgICAgICAgICAgICAgICAgICAgICBwcm9wb3Nh bHMgaXMgbW92ZWQgb3V0IG9mIGl0LCB0byB0aGUgbmV4dA0KICAgICAgICAgICAgICAgICAgICAg ICAgc2VjdGlvbi4NCiAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAgICAgTGF0ZXIgdmVyc2lvbnMgbmVlZCBjbGVhbmVyIHNlcGFyYXRpb24gb2YgdG9waWNzLA0K ICAgICAgICAgICAgICAgICAgICAgICAgc3VjaCBhcyByZXF1aXJlbWVudHMgYW5kIGRlZmluaXRp b24gb2Ygd2hhdCBtdWx0aS0NCiAgICAgICAgICAgICAgICAgICAgICAgIGFkZHJlc3Npbmcgc3Vw cG9ydCByZWFsbHkgbWVhbnMgaW4gZGlmZmVyZW50DQogICAgICAgICAgICAgICAgICAgICAgICBz aXR1YXRpb25zLg0KICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICBOZWVkIHRvIGFkZCBhIGNoYXJ0IHRoYXQgY29tcGFyZXMgdGhlIHByb3Bvc2Fscy4NCiAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgTmVlZCB0byBp bmNvcnBvcmF0ZSB0aGUgcmVtYWluZGVyIG9mIE1hcmNlbG8ncw0KICAgICAgICAgICAgICAgICAg ICAgICAgc3VnZ2VzdGVkIGNoYW5nZXMuDQogICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg ICAgICAgICAgICAgICAgICAgIE5lZWQgdG8gZGlzY3VzcyBlbmhhbmNlbWVudHMgbWFkZSBwb3Nz aWJsZSBieQ0KICAgICAgICAgICAgICAgICAgICAgICAgbXVsdGlhZGRyZXNzaW5nIHN1cHBvcnQu DQogICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICBOT1RFOiAgICAgICAgICAg ICAgRC4gQ3JvY2tlciBoYXMgcHV0IGZvcndhcmQgdGhlIE1BU1QgcHJvcG9zYWwuDQogICAgICAg ICAgICAgICAgICAgICAgICBUaGF0IG1heSBoYXZlIGNvbG9yZWQgdGhlIHBlcnNwZWN0aXZlcyBp biB0aGlzDQogICAgICAgICAgICAgICAgICAgICAgICBkaXNjdXNzaW9uIHBhcGVyLg0KDQoNCg0K DQoyLiAgIFRFUk1JTk9MT0dZDQogICAgIA0KICAgICBUaGlzIHBhcGVyIGRpc2N1c3NlcyByZXF1 aXJlbWVudHMgYW5kIG1ldGhvZHMgZm9yIGVuYWJsaW5nIGFuDQogICAgIGVuZHBvaW50IHRvIHVz ZSBtdWx0aXBsZSBsb2NhdG9ycyBkdXJpbmcgc2luZ2xlIGFwcGxpY2F0aW9uDQogICAgIGFzc29j aWF0aW9ucy4gVGhpcyB0b3BpYyBkb2VzIG5vdCB5ZXQgaGF2ZSBhIHN0YWJsZSwgY29yZSBzZXQg b2YNCiAgICAgdGVybXMgaW4gZ2VuZXJhbCB1c2UuICBUaGUgZm9sbG93aW5nIGRlZmluaXRpb25z IGFyZSBpbnRlbmRlZCB0bw0KICAgICByZW1lZHkgdGhhdCBkZWZpY2llbmN5OyB0aGV5IGFyZSB0 YWtlbiBmcm9tIGV4aXN0aW5nIGRlZmluaXRpb25zLA0KICAgICB3aGVuIGF2YWlsYWJsZS4gV29y ayBvbiBtdWx0aWFkZHJlc3MgZW5oYW5jZXMgZXhpc3RpbmcNCiAgICAgaW5mcmFzdHJ1Y3R1cmUg Y2FwYWJpbGl0aWVzLiAgVGhpcyB3b3JrIGlzIHVuY292ZXJpbmcgYW1iaWd1aXRpZXMNCiAgICAg dG8gdGVybXMgdGhhdCBoYXZlIGJlZW4gdXNlZC4gIEZvciBtdWx0aWFkZHJlc3NpbmcsIGl0IGlz DQogICAgIHRoZXJlZm9yZSBjb25mdXNpbmcgdG8gdXNlIHNvbWUgY29tbW9uIHRlcm1zLCBub3Rh Ymx5ICJhZGRyZXNzIi4NCiAgICAgSGVuY2UgdGhleSBTSE9VTEQgTk9UIGJlIHVzZWQuDQoNCg0K Mi4xLiBSZWNvbW1lbmRlZA0KICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICBBZ2VudCAg ICAgICAgICAgICAgIHJlZmVycyB0byBhIHRoaXJkLXBhcnR5IHRoYXQgaXMgaGFuZGxpbmcNCiAg ICAgICAgICAgICAgICAgICAgICAgICBzb21ldGhpbmcgb24gYmVoYWxmIG9mIG9uZSBvciBtb3Jl IG90aGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgcGFydGllcy4gIFRoZSB0ZXJtIGluZGlj YXRlcyB0aGUgc2VwYXJhdGVuZXNzDQogICAgICAgICAgICAgICAgICAgICAgICAgb2YgdGhlIGVu dGl0eSwgYXMgd2VsbCBhcyBpdHMga2V5DQogICAgICAgICAgICAgICAgICAgICAgICAgcmVsYXRp b25zaGlwIHRvIHRoZSBvdGhlciBlbnRpdGllcy4gSW4NCiAgICAgICAgICAgICAgICAgICAgICAg ICBtdWx0aWFkZHJlc3NpbmcsIGl0IHJlZmVycyB0byBhbiBpbnRlcm1lZGlhcnkNCiAgICAgICAg ICAgICAgICAgICAgICAgICBzZXJ2aWNlIHRoYXQgcmVwcmVzZW50cyBhbiBlbmRwb2ludCwgZm9y IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgIHB1cnBvc2VzIG9mIHJlZmVycmFsIGFuZC9v ciByZWxheWluZy4NCiAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgQXNzb2NpYXRpb24g ICAgICAgICByZWZlcnMgdG8gYW4gZXN0YWJsaXNoZWQgY29tbXVuaWNhdGlvbg0KICAgICAgICAg ICAgICAgICAgICAgICAgIGNvbnRleHQgYmV0d2VlbiBlbmRwb2ludHMsIHN1Y2ggYXMgYSBUQ1AN CiAgICAgICAgICAgICAgICAgICAgICAgICBjb25uZWN0aW9uLg0KICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICBFbmRwb2ludCAgICAgICAgICAgIHJlZmVycyB0byAidGhlIGZ1bmRhbWVu dGFsIGFnZW50IG9mIGVuZC1lbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICBjb21tdW5pY2F0 aW9uIiBbRUlEXS4gSXQgaXMgYW4gZW5kLXN5c3RlbQ0KICAgICAgICAgICAgICAgICAgICAgICAg IHRoYXQgcGFydGljaXBhdGVzIGluIGFuIGFzc29jaWF0aW9uLg0KICAgICAgICAgICAgICAgICAg ICAgICAgIEVuZHBvaW50cyBhcmUgZGlzdGluZ3Vpc2hlZCBmcm9tDQogICAgICAgICAgICAgICAg ICAgICAgICAgaW50ZXJtZWRpYXRlLCBpbmZyYXN0cnVjdHVyZSBub2RlcyBhbmQgaG9zdHMuDQoN CkpCPiBOb3QgY2xlYXIgYWxsIGFncmVlIEVJRCA9PSB0aGlzIGRlZmluaXRpb24/ICBJcyByZWZl cmVuY2luZyBFSUQgDQpjb3JyZWN0IGhlcmU/DQogICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgIElkZW50aWZpZXIgICAgICAgICAgcmVmZXJzIHRvIGEgdW5pcXVlIGxhYmVsIGZvciBhbiBl bmRwb2ludC4gVGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgbGFiZWwgaXMgdXNlZCBzaW1w bHkgZm9yIGRpc3Rpbmd1aXNoaW5nIG9uZQ0KICAgICAgICAgICAgICAgICAgICAgICAgIGVuZHBv aW50IGZyb20gYW5vdGhlci4gQmVjYXVzZSBhIGxvY2F0b3IgaXMNCiAgICAgICAgICAgICAgICAg ICAgICAgICB1c3VhbGx5IGdsb2JhbGx5IHVuaXF1ZSwgaXQgbWlnaHQgYmUgYWJsZSB0bw0KICAg ICAgICAgICAgICAgICAgICAgICAgIHNlcnZlIGFzIGFuIGlkZW50aWZpZXIuIEhvd2V2ZXIgdGhp cyB1c2Ugd2lsbA0KICAgICAgICAgICAgICAgICAgICAgICAgIG9mdGVuIHN1ZmZlciBhZG1pbmlz dHJhdGl2ZSBhbmQgcmVmZXJlbnRpYWwNCiAgICAgICAgICAgICAgICAgICAgICAgICBsaW1pdGF0 aW9ucyBhcyBhIGdsb2JhbCBpZGVudGlmaWVyIGZvciBtb2JpbGUNCiAgICAgICAgICAgICAgICAg ICAgICAgICBlbmRwb2ludHMuIFRoaXMgaXMgZXhlbXBsaWZpZWQgYnkgdGhlIGN1cnJlbnQNCiAg ICAgICAgICAgICAgICAgICAgICAgICBwcm9ibGVtcyBleHBlcmllbmNlZCB3aXRoIHRoZSBkdWFs IHJvbGUgb2YgSVANCiAgICAgICAgICAgICAgICAgICAgICAgICBBZGRyZXNzZXMuDQogICAgICAg ICAgICAgICAgICAgICAgICAgDQogICAgIEluaXRpYXRvciAgICAgICAgICAgcmVmZXJzIHRvIGFu IGVuZHBvaW50IHRoYXQgaW5pdGlhdGVzIGNvbnRhY3QNCiAgICAgICAgICAgICAgICAgICAgICAg ICB3aXRoIGEgdGFyZ2V0IGVuZHBvaW50LiBJbiBjbGllbnQvc2VydmVyDQogICAgICAgICAgICAg ICAgICAgICAgICAgYXJjaGl0ZWN0dXJlIGl0IGlzIHRoZSBjbGllbnQuDQogICAgICAgICAgICAg ICAgICAgICAgICAgDQogICAgIElQIEFkZHJlc3MgICAgICAgICAgc3BlY2lmaWVzIGEgdG9wb2xv Z2ljYWwgbmV0d29yayBhY2Nlc3MgcG9pbnQuDQogICAgICAgICAgICAgICAgICAgICAgICAgVGhl IHRlcm0gaXMgdXN1YWxseSBjb25zaWRlcmVkIHRvIHNwZWNpZnkgYW4NCiAgICAgICAgICAgICAg ICAgICAgICAgICBlbmRwb2ludCBpbnRlcmZhY2UuICBIb3dldmVyIGRpc2N1c3Npb25zDQogICAg ICAgICAgICAgICAgICAgICAgICAgYWJvdXQgbW9iaWxpdHkgYXJlIG5vdGFibHkgY2xhcmlmaWVk IGJ5DQogICAgICAgICAgICAgICAgICAgICAgICAgdmlld2luZyB0aGUgdmFsdWUgYXMgYmVsb25n aW5nIHRvIHRoZSBuZXR3b3JrDQogICAgICAgICAgICAgICAgICAgICAgICAgKGludGVyZmFjZSkg cmF0aGVyIHRoYW4gdG8gdGhlIGVuZHBvaW50Lg0KICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICBMb2NhdG9yICAgICAgICAgICAgIHJlZmVycyB0byBhICJ0aGUgbmFtZSBvZiBhIG5ldHdv cmsgYXR0YWNobWVudA0KICAgICAgICAgICAgICAgICAgICAgICAgIHBvaW50IiBbU0FMVF0sIHVz dWFsbHkgaW4gdGVybXMgb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgbmV0d29yaydz IHRvcG9sb2d5LiBMb2NhdG9ycyB0eXBpY2FsbHkNCiAgICAgICAgICAgICAgICAgICAgICAgICBm YWNpbGl0YXRlIG1hcHBpbmcgaW50byByb3V0ZXMsIHN1Y2ggYXMgYnkNCiAgICAgICAgICAgICAg ICAgICAgICAgICBpbmRpY2F0aW5nIGEgdG9wb2xvZ2ljYWwgaGllcmFyY2h5LiBJUA0KICAgICAg ICAgICAgICAgICAgICAgICAgIEFkZHJlc3NlcyBzcGVjaWZ5IGEgdG9wb2xvZ2ljYWwgbmV0d29y aw0KICAgICAgICAgICAgICAgICAgICAgICAgIGFjY2VzcyBwb2ludC4gVGhleSB1c3VhbGx5IGFy ZSBjb25zaWRlcmVkIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lmeSBhbiBlbmRw b2ludCBpbnRlcmZhY2UuICBIb3dldmVyDQogICAgICAgICAgICAgICAgICAgICAgICAgZGlzY3Vz c2lvbnMgYWJvdXQgbW9iaWxpdHkgYXJlIGVuaGFuY2VkIGJ5DQogICAgICAgICAgICAgICAgICAg ICAgICAgdmlld2luZyB0aGUgdmFsdWUgYXMgYmVsb25naW5nIHRvIHRoZSBuZXR3b3JrDQogICAg ICAgICAgICAgICAgICAgICAgICAgKGludGVyZmFjZSkgcmF0aGVyIHRoYW4gdG8gdGhlIGVuZHBv aW50Lg0KICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICBNb2JpbGl0eSAgICAgICAgICAg IHJlZmVycyB0byBhbiBlbmRwb2ludCdzIGhhdmluZyBkaWZmZXJlbnQNCiAgICAgICAgICAgICAg ICAgICAgICAgICBsb2NhdG9ycyBvdmVyIHRpbWUuIFRoaXMgbWF5IGV2ZW4gaW5jbHVkZQ0KICAg ICAgICAgICAgICAgICAgICAgICAgIGRpc2NvbnRpbnVpdGllcywgZHVyaW5nIHdoaWNoIGFuIGVu ZHBvaW50IGhhcw0KICAgICAgICAgICAgICAgICAgICAgICAgIG5vIHZhbGlkIGxvY2F0b3JzLiBJ biBhZGRpdGlvbiwgdGhlIG5hdHVyZSBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgIGEgdHJh bnNpdGlvbiBmcm9tIG9uZSBsb2NhdG9yIHRvIGFub3RoZXIgbWF5DQogICAgICAgICAgICAgICAg ICAgICAgICAgaW5jbHVkZSBvdmVybGFwcGluZyBhdmFpbGFiaWxpdHkgb2YgbG9jYXRvcnMuDQog ICAgICAgICAgICAgICAgICAgICAgICAgSW50ZXJlc3RpbmdseSwgdGhpcyBsb29rcyB0aGUgc2Ft ZSBhcw0KICAgICAgICAgICAgICAgICAgICAgICAgIG11bHRpaG9taW5nLiBNb2JpbGl0eSBtYXkg YmUgZm9yIGEgc2luZ2xlDQogICAgICAgICAgICAgICAgICAgICAgICAgZW5kcG9pbnQgb3IgZm9y IHRoZSBzdWJuZXR3b3JrIHRvIHdoaWNoIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgIGVu ZHBvaW50IGlzIGF0dGFjaGVkLiBJbiB0aGUgbGF0dGVyIGNhc2UsIHRoZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgIGVuZHBvaW50IGNvbm5lY3Rpb24gaXMgc3RhYmxlLCB3aXRoIHJlc3BlY3QN CiAgICAgICAgICAgICAgICAgICAgICAgICB0byBpdHMgc3ViLW5ldHdvcmssIGJ1dCB0aGUgc3Vi LW5ldHdvcmsNCiAgICAgICAgICAgICAgICAgICAgICAgICBwcm9wb2dhdGVzIGNvbm5lY3Rpdml0 eSBjaGFuZ2UgaW5mb3JtYXRpb24gdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZW5k cG9pbnQuDQogICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgIE11bHRpYWRkcmVzc2luZyAg ICAgcmVmZXJzIHRvIGFuIGVuZHBvaW50J3MgaGF2aW5nIG1vcmUgdGhhbiBvbmUNCiAgICAgICAg ICAgICAgICAgICAgICAgICBsb2NhdG9yIGF2YWlsYWJsZSwgb3ZlciB0aGUgbGlmZXRpbWUgb2Yg YW4NCiAgICAgICAgICAgICAgICAgICAgICAgICBhc3NvY2lhdGlvbi4gSXQgZW5jb21wYXNzZXMg Ym90aCBtdWx0aWhvbWluZw0KICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBtb2JpbGl0eS4g VGhlIGNvcmUgcmVxdWlyZW1lbnQgZm9yDQogICAgICAgICAgICAgICAgICAgICAgICAgbXVsdGlh ZGRyZXNzaW5nIGlzIHByZXNlcnZhdGlvbiBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgIGVz dGFibGlzaGVkIGNvbW11bmljYXRpb25zLCBhY3Jvc3MgdGhlIHVzZSBvZg0KICAgICAgICAgICAg ICAgICAgICAgICAgIGRpZmZlcmVudCBsb2NhdG9ycy4NCg0KSkI+IFRoaXMgaXMgd2hhdCBNQVNU IHNob3VsZCBiZSBmb2N1c2luZyBvbiBvciBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIGVmZm9ydC4N CiAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgTXVsdGlob21pbmcgICAgICAgICByZWZl cnMgdG8gdGhlIGF2YWlsYWJpbGl0eSBvZiBtdWx0aXBsZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgIGVuZHBvaW50IGxvY2F0b3JzIGF0IHRoZSBzYW1lIGVuZHBvaW50LA0KICAgICAgICAgICAg ICAgICAgICAgICAgIHNpbXVsdGFuZW91c2x5LiBJdCBpcyB0eXBpY2FsbHkgdXNlZCB0byByZWZl cg0KICAgICAgICAgICAgICAgICAgICAgICAgIHRvIG11bHRpcGxlIG5ldHdvcmsgYXR0YWNobWVu dHMgZm9yIGEgaG9zdCwNCiAgICAgICAgICAgICAgICAgICAgICAgICBidXQgd29ya3MgZXF1YWxs eSB3ZWxsIGZvciBtdWx0aXBsZSB1cHN0cmVhbQ0KICAgICAgICAgICAgICAgICAgICAgICAgIG5l dHdvcmsgYXR0YWNobWVudHMgYnkgdGhlIGxvY2FsIG5ldHdvcmssDQogICAgICAgICAgICAgICAg ICAgICAgICAgd2hlbiB0aGUgZGlmZmVyZW50IHVwc3RyZWFtIGxvY2F0b3JzIGFyZQ0KICAgICAg ICAgICAgICAgICAgICAgICAgIHZpc2libGUgdG8gdGhlIGhvc3QuIEludGVyZXN0aW5nbHksDQog ICAgICAgICAgICAgICAgICAgICAgICAgbXVsdGlob21lZCBlbnZpcm9ubWVudHMgb2Z0ZW4gbXVz dCBzdXBwb3J0DQogICAgICAgICAgICAgICAgICAgICAgICAgZHluYW1pYyBjaGFuZ2VzLCBzdWNo IGFzIHdoZW4gYWRkaW5nIGEgbmV3DQogICAgICAgICAgICAgICAgICAgICAgICAgdXBzdHJlYW0g cHJvdmlkZXIuIFRoZXJlZm9yZSwgbXVsdGlob21pbmcgY2FuDQogICAgICAgICAgICAgICAgICAg ICAgICAgaW5jbHVkZSBtb2JpbGl0eSBmZWF0dXJlcyBhbmQgbW9iaWxpdHkgY2FuDQogICAgICAg ICAgICAgICAgICAgICAgICAgaW5jbHVkZSBtdWx0aWhvbWluZyBmZWF0dXJlcy4gV2hlbiBuZWVk aW5nIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgcmVudW1iZXIgYSBuZXR3b3JrLCBkdWUg dG8gY2hhbmdlcyBpbiB1cC0NCiAgICAgICAgICAgICAgICAgICAgICAgICBzdHJlYW0gc2Vydmlj ZSwgdGhlIHByb2Nlc3MgY2FuIGJlIG9wZXJhdGVkDQogICAgICAgICAgICAgICAgICAgICAgICAg YXMgZHluYW1pYyBtdWx0aWhvbWluZy4NCiAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAg UGF0aCBkaXNjb3ZlcnkgICAgICBwcm92aWRlcyBhIHNlbmRlciB3aXRoIHRoZSBtZWFucyBmb3Ig bGVhcm5pbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICBhYm91dCB0aGUgbG9jYXRvcnMgZnJv bSB3aGljaCB0aGV5IGNhbiBzZW5kLg0KICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICBQ YXRoIHNlbGVjdGlvbiAgICAgIGlzIHJlcXVpcmVkIHdoZW4gbW9yZSB0aGFuIG9uZSBsb2NhdG9y IGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgYXZhaWxhYmxlIHRvIHRoZSBzZW5kZXIuIEFs dGhvdWdoIHRoZSBzZW5kZXINCiAgICAgICAgICAgICAgICAgICAgICAgICBpcyBsaW1pdGVkIHRv IHNwZWNpZnlpbmcgYW4gbG9jYXRvciwgcmF0aGVyDQogICAgICAgICAgICAgICAgICAgICAgICAg dGhhbiBhIHBhdGgsIGl0IGFwcGVhcnMgdGhhdCB0aGlua2luZyBvZiBpdA0KICAgICAgICAgICAg ICAgICAgICAgICAgIGFzIHBhdGggc2VsZWN0aW9uIGFpZHMgY29uc2lkZXJhdGlvbiBvZg0KICAg ICAgICAgICAgICAgICAgICAgICAgIHNvbHV0aW9ucy4gSW4gZWZmZWN0LCBpdCBmb3JtdWxhdGVz IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgIHNlbGVjdGlvbiB0YXNrIGFzIGJlaW5nIHNp bWlsYXIgdG8gdGhlIGpvYiBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgIHJvdXRlcnMuIFJv dXRlIGZvcm11bGF0aW9uIGlzIG1hdHVyZQ0KICAgICAgICAgICAgICAgICAgICAgICAgIHRlY2hu b2xvZ3ksIHNvIHRoYXQgdGhpcyBhc3BlY3Qgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICBt dWx0aWFkZHJlc3MgcHJvY2Vzc2luZyB3aWxsIGJlIHRyYWN0YWJsZSwgaWYNCiAgICAgICAgICAg ICAgICAgICAgICAgICBub3Qgc3RyYWlnaHRmb3J3YXJkLg0KICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICBSZWZlcnJhbCAgICAgICAgICAgIHBlcm1pdHMgYW4gaW5pdGlhdG9yIHRvIG9i dGFpbiBhIGxvY2F0b3IgZm9yDQogICAgICAgICAgICAgICAgICAgICAgICAgYSB0YXJnZXQsIHN1 Y2ggYXMgYSBjbGllbnQgYmVpbmcgcmVmZXJyZWQgdG8NCiAgICAgICAgICAgICAgICAgICAgICAg ICBhIHNlcnZlci4gQSB0aGlyZC1wYXJ0eSBwcm9jZXNzIGlzIHJlcXVpcmVkDQogICAgICAgICAg ICAgICAgICAgICAgICAgZm9yIHJlZmVycmFsLCBpbiB0aGUgYWJzZW5jZSBvZiBhbg0KICAgICAg ICAgICAgICAgICAgICAgICAgIGFzc29jaWF0aW9uLiBGb3IgZXhpc3RpbmcgYXNzb2NpYXRpb25z LA0KICAgICAgICAgICAgICAgICAgICAgICAgIHBhcnRpY2lwYXRpbmcgZW5kcG9pbnRzIG1pZ2h0 IGJlIGFibGUgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICBzdXBwbHkgdGhlaXIgb3duIHJl ZmVycmFscy4gVGhlIHByaW1hcnkNCiAgICAgICAgICAgICAgICAgICAgICAgICBJbnRlcm5ldCBt ZWNoYW5pc20gZm9yIHJlZmVycmFsIGhhcyBiZWVuIHRoZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgIERvbWFpbiBOYW1lIFNlcnZpY2UgKEROUykuICBUaGUgRE5TIHVzZXMNCiAgICAgICAgICAg ICAgICAgICAgICAgICBsb25nLCB2YXJpYWJsZS1sZW5ndGggc3RyaW5ncyAobmFtZXMpIGFuZCBp cw0KICAgICAgICAgICAgICAgICAgICAgICAgIHRhaWxvcmVkIGZvciBsYXJnZS1zY2FsZSByZWZl cnJhbCB3aXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgaWRlbnRpZmllcnMgYW5kIGxvY2F0 b3JzIChtYXBwaW5ncykgdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgIGNoYW5nZSBpbmZy ZXF1ZW50bHkuDQogICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgIFJlZmVycmFsIEFnZW50 ICAgICAgcmVmZXJzIHRvIHRoZSBmdW5jdGlvbiB0aGF0IG1haW50YWlucyB0aGUNCiAgICAgICAg ICAgICAgICAgICAgICAgICBtYXBwaW5nIGJldHdlZW4gYSBtb2JpbGUgbm9kZSdzIGlkZW50aWZp ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgaXRzIGxvY2F0b3IocykuIFtMSU42XSBj YWxscyB0aGlzIGENCiAgICAgICAgICAgICAgICAgICAgICAgICBNYXBwaW5nIEFnZW50Lg0KICAg ICAgICAgICAgICAgICAgICAgICAgIA0KICAgICBSZWhvbWluZyAgICAgICAgICAgIHJlZmVycyB0 byBhbiBlbmRwb2ludCdzIGNoYW5naW5nIGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgYXNz b2NpYXRpb24gZnJvbSBvbmUgbG9jYXRvciB0byBhbm90aGVyLA0KICAgICAgICAgICAgICAgICAg ICAgICAgIA0KICAgICBSZWxheWluZyAgICAgICAgICAgIHJlZmVycyB0byB0aGUgcmVkaXJlY3Rp b24gb2YgcGFja2V0cywgb24NCiAgICAgICAgICAgICAgICAgICAgICAgICBiZWhhbGYgb2YgYW4g ZW5kcG9pbnQuIE90aGVyIGVuZHBvaW50cyBzZWUgYQ0KICAgICAgICAgICAgICAgICAgICAgICAg IHN0YWJsZSBsb2NhdG9yIGZvciB0aGUgZW5kcG9pbnQgb2J0YWluaW5nIHRoZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgIHJlbGF5aW5nIHNlcnZpY2UuDQogICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgIFJlbGF5aW5nIEFnZW50ICAgICAgcmVmZXJzIHRvIGFuIGFnZW50IHRoYXQgcGVy Zm9ybXMgcGFja2V0DQogICAgICAgICAgICAgICAgICAgICAgICAgZm9yd2FyZGluZyAocmVsYXlp bmcpIG9uIGJlaGFsZiBvZiBhbg0KICAgICAgICAgICAgICAgICAgICAgICAgIGVuZHBvaW50LiAg VGhlIFJlbGF5aW5nIEFnZW50IHRoZXJlYnkNCiAgICAgICAgICAgICAgICAgICAgICAgICBwZXJz ZW50cyBhIHN0YWJsZSBsb2NhdG9yIHRvIHRoZSBJbnRlcm5ldCwNCiAgICAgICAgICAgICAgICAg ICAgICAgICBmb3IgdGhlIGVuZHBvaW50LiBGb3IgbW9iaWxpdHksIHRoZSBhZ2VudA0KICAgICAg ICAgICAgICAgICAgICAgICAgIHJlc2lkZXMgb24gYW4gZW5kcG9pbnQncyAiaG9tZSIgbmV0d29y ayBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICByZWxheXMgZGF0YWdyYW1zIHRvIHRoZSBl bmRwb2ludCdzIGFjdHVhbA0KICAgICAgICAgICAgICAgICAgICAgICAgIGxvY2F0aW9uIG9uIHRo ZSBJbnRlcm5ldC4gIFRoZSBlbmRwb2ludCBpcw0KICAgICAgICAgICAgICAgICAgICAgICAgIG1v ZGlmaWVkIHRvIHN1cHBvcnQgdGhpcyBmb3J3YXJkaW5nDQogICAgICAgICAgICAgICAgICAgICAg ICAgdGVjaG5pcXVlLg0KICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICBSZW5kZXp2b3Vz ICAgICAgICAgIHJlZmVycyB0byBvbmUgZW5kcG9pbnQgbWFraW5nIGNvbnRhY3Qgd2l0aCBhbg0K ICAgICAgICAgICAgICAgICAgICAgICAgIGV4cGxpY2l0bHkgaWRlbnRpZmllZCAgIG90aGVyIGVu ZHBvaW50Lg0KICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICBUYXJnZXQgICAgICAgICAg ICAgIHJlZmVycyB0byBhbiBlbmRwb2ludCB0aGF0IHJlY2VpdmVzIGNvbnRhY3QNCiAgICAgICAg ICAgICAgICAgICAgICAgICBmcm9tIGFuIEluaXRpYXRvciBlbmRwb2ludC4gSW4gYQ0KICAgICAg ICAgICAgICAgICAgICAgICAgIGNsaWVudC9zZXJ2ZXIgYXJjaGl0ZWN0dXJlLCB0aGlzIGlzIHRo ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZlci4NCg0KSkI+IEkgaGF2ZSBpc3N1ZXMg d2l0aCBzb21lIG9mIHRoZSBkZWZpbml0aW9ucy4gSSBzdWdnZXN0IGEgZHJhZnQgYWxsIGJ5IGl0 IA0Kc2VsZiB0byBkZWZpbmUgdGVybXMgYW5kIHJlbW92ZSBNQVNUIGZyb20gdGhlIHRpdGxlIGNh bGwgaXQgc29tZXRoaW5nIGVsc2UuDQpCZSBhIGdvb2QgbXVsdGk2IGRyYWZ0IHRvby4NCiAgICAg DQogICAgIA0KDQoNCjIuMi4gRGVwcmVjYXRlZA0KICAgICAgICAgICAgICAgICAgICAgICAgIA0K ICAgICBBZGRyZXNzICAgICAgICAgICAgIFJlZmVycyB0byAidGhlIG5hbWUgb2Ygc29tZSBuZXR3 b3JrDQogICAgICAgICAgICAgICAgICAgICAgICAgYXR0YWNobWVudCBwb2ludC4iIFtTQUxUXSBU aGUgdGVybSBoYXMgYmVjb21lDQogICAgICAgICAgICAgICAgICAgICAgICAgYSBwcm9ibGVtYXRp YyBiZWNhdXNlIGFkZHJlc3NlcyBvZnRlbiBhcmUNCiAgICAgICAgICAgICAgICAgICAgICAgICB1 c2VkIGZvciB0d28sIGRpc3RpbmN0IGZ1bmN0aW9ucy4gIEhlbmNlIHRoZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgIHRlcm0gc2hvdWxkIG5vdCBiZSB1c2VkIGJ5IGl0c2VsZiwgZm9yIHRoZXNl DQogICAgICAgICAgICAgICAgICAgICAgICAgZGlzY3Vzc2lvbnMsIGV4Y2VwdCB3aXRoIHJlZmVy ZW5jZSB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgIHBhcnRpY3VsYXIgcHJvdG9jb2wgc3Bl Y2lmaWNhdGlvbnMsIHN1Y2ggYXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAiSVAgQWRkcmVz cyIuICBJbnN0ZWFkLCB1c2UgImlkZW50aWZlciIgYW5kDQogICAgICAgICAgICAgICAgICAgICAg ICAgImxvY2F0b3IiLCBhcyBhcHByb3ByaWF0ZS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgQ29ubmVjdGlvbiAgICAgICAgICBBIHN0YXRlIG9mIGFzc29jaWF0aW9uIGJldHdlZW4g dHdvIGVuZHBvaW50cy4NCiAgICAgICAgICAgICAgICAgICAgICAgICBCZWNhdXNlIHRoZSB0ZXJt IGlzIHR5cGljYWxseSB1c2VkIGZvciB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgIHJlZmVy IHRvIHRyYW5zcG9ydC1sYXllciBzdGF0ZSwgZGlzY3Vzc2lvbnMNCiAgICAgICAgICAgICAgICAg ICAgICAgICBhYm91dCBtdWx0aWFkZHJlc3Npbmcgc2hvdWxkIHVzZSB0aGUgbW9yZQ0KICAgICAg ICAgICAgICAgICAgICAgICAgIGdlbmVyYWwgdGVybSAiYXNzb2NpYXRpb24iLCBleGNlcHQgd2l0 aA0KICAgICAgICAgICAgICAgICAgICAgICAgIHJlZmVyZW5jZSB0byBwYXJ0aWN1bGFyIHByb3Rv Y29sDQogICAgICAgICAgICAgICAgICAgICAgICAgc3BlY2lmaWNhdGlvbiwgc3VjaCBhcyAiVENQ IENvbm5lY3Rpb24iLg0KDQpKQj4gSSBkb24ndCBzdXBwb3J0IHRoaXMgdW50aWwgd2UgZG8gcHJl dmlvdXMgcmVzcG9uc2UgYW5kIGEgbG90IG9mIHdvcmsuDQoNCg0KDQoNCjMuICAgQ09OU0lERVJB VElPTlMNCiAgICAgDQogICAgIFRoZSBjb3JlIHJlcXVpcmVtZW50IGZvciBtdWx0aWFkZHJlc3Np bmcgaXMgY29udGludWl0eSBvZiBhY2Nlc3MNCiAgICAgd2l0aGluIGFuIGFzc29jaWF0aW9uLiBI b3dldmVyIGFwcGxpY2F0aW9ucyBoYXZpbmcgdGhpcyBhcyBhDQogICAgIGNvbXBlbGxpbmcgcmVx dWlyZW1lbnQgaGF2ZSBub3QgeWV0IGJlZW4gZXZpZGVudCBvbiB0aGUgSW50ZXJuZXQuDQogICAg IEhlbmNlIHRoZXJlIGl1cyBzb21lIHJpc2sgdGhhdCBwcm9wb3NlZCBtZWNoYW5pc21zIHRvIHNv bHZlIHRoZQ0KICAgICByZXF1aXJlbWVudCB3aWxsIG5vdCBjb3JyZWN0bHkgYW5jaXRpcGF0ZSB0 aGUgZGV0YWlscyBvZiB0aGUNCiAgICAgcmVxdWlyZW1lbnQuDQogICAgIA0KICAgICBUaGlzIHNl Y3Rpb24gaXMgYSBnZW5lcmFsIGRpc2N1c3Npb24gb2YgcmVxdWlyZW1lbnRzLCBjb25zdHJhaW50 cw0KICAgICBhbmQgY29uY2VybnMuIEl0IGRvZXMgbm90IGF0dGVtcHQgdG8gb2ZmZXIgYSBmb3Jt YWwgc2V0IG9mDQogICAgIHJlcXVpcmVtZW50cyBvciByZWNvbW1lbmRhdGlvbnMuDQoNCg0KMy4x LiBNb2JpbGl0eQ0KICAgICANCiAgICAgTW9iaWxpdHkgaXMgdGltZS12YXJ5aW5nIGFjY2VzcyB0 byBtdWx0aXBsZSBsb2NhdG9ycyBmb3IgdGhlIHNhbWUNCiAgICAgZW5kcG9pbnQuIEtleSBwYXJh bWV0ZXJzIHRvIG1vYmlsaXR5IGFyZSBzY29wZSBvZiBjaGFuZ2UsIHJhdGUgb2YNCiAgICAgY2hh bmdlIGFuZCBzb3VyY2Uocykgb2YgdGhlIGNoYW5nZS4gT3ZlciB3aGF0IHBvcnRpb24gb2YgdGhl DQogICAgIEludGVybmV0IHRvcG9sb2d5IG1pZ2h0IGEgY2hhbmdlIHRha2UgcGxhY2U7IGhvdyBv ZnRlbiB3aWxsDQogICAgIGNoYW5nZXMgb2NjdXI7IGFuZCB3aGljaCBvZiB0aGUgcGFydGljaXBh bnRzIHdpbGwgY2hhbmdlIHRoZWlyDQogICAgIGxvY2F0b3JzPw0KDQpKQj4gT3V0IG9mIHNjb3Bl IGFuZCBjaGFydGVyIGZvciBtdWx0aTYuICBUYWtlIHRoaXMgdG8gQURzIGFuZCBmaW5kIG91dA0K d2hlcmUgdGhpcyBkaXNjdXNzaW9uIGJlbG9uZ3MgSSBhbSBub3Qgc3VyZSBidXQgaXRzIG5vdCBt dWxpdDYuDQogICAgIA0KICAgICANCiAgICAgMy4xLjEuICAgIFJhcGlkLCBMb2NhbCBJbml0aWF0 b3JzDQogICAgIA0KICAgICBJdCBpcyBnZW5lcmFsbHkgYWNjZXB0ZWQgdGhhdCByYXBpZCwgbG9j YWwgY2hhbmdlcyBzaG91bGQgYmUNCiAgICAgaGFuZGxlZCBieSBhIGxheWVyIGJlbG93IElQLiBU aGVzZSBjaGFuZ2VzIGFyZSB0aGVyZWZvcmUNCiAgICAgaW52aXNpYmxlIHRvIElQIGFuZCBhYm92 ZSwgc28gdGhhdCBhc3NvY2lhdGlvbnMgYXJlIGF1dG9tYXRpY2FsbHkNCiAgICAgcHJlc2VydmVk IGFjcm9zcyBjaGFuZ2UuDQogICAgIA0KICAgICANCiAgICAgMy4xLjIuICAgIFJhcmUsIERpc3Rh bnQgSW5pdGlhdG9ycw0KICAgICANCiAgICAgRm9yIGluaXRpYXRvciBlbmRwb2ludHMgdGhhdCBh cmUgc3ViamVjdCB0byBvY2Nhc2lvbmFsIGRldGFjaG1lbnQNCiAgICAgYW5kIGV2ZW50dWFsIHJl Y29ubmVjdGlvbiwgdGhlIGN1cnJlbnQgc2V0IG9mIHRlY2hub2xvZ2llcyBpcw0KICAgICBwcm9i YWJseSBzdWZmaWNpZW50LiBUaGVzZSByZXF1aXJlIHJlY29uZmlndXJhdGlvbiwgc3VjaCBhcw0K ICAgICB0aHJvdWdoIERIQ1AsIGFuZCBlc3RhYmxpc2hpbmcgbmV3IGFzc29jaWF0aW9ucy4gQXBw bGljYXRpb25zDQogICAgIHdpc2hpbmcgdG8gcmV0YWluIGFzc29jaWF0aW9uIHN0YXRlLCBhY3Jv c3MgdGhlc2UgdHJhbnNpdGlvbnMsIGRvDQogICAgIHNvIGFib3ZlIHRoZSB0cmFuc3BvcnQgbGF5 ZXIuIFRoZXkgYXJlIGNhcGFibGUgb2YgZXN0YWJsaXNoaW5nDQogICAgIG5ldyB0cmFuc3BvcnQg YXNzb2NpYXRpb25zLCBhcyBuZWVkZWQuDQogICAgIA0KICAgICANCiAgICAgMy4xLjMuICAgIFBl cmlvZGljLCBNb2RlcmF0ZQ0KICAgICANCiAgICAgV2hhdCBpcyBtaXNzaW5nIGZyb20gdGhlIG9w ZXJhdGlvbmFsIEludGVybmV0IGlzIHN1cHBvcnQgZm9yDQogICAgIGluaXRpYXRvciBhbmQgdGFy Z2V0IHN5c3RlbXMgdGhhdCBtb3ZlIG92ZXIgdGhlIGNvdXJzZSBvZiBtaW51dGVzDQogICAgIG9y IGhvdXJzIGFuZCBuZWVkIHRvIG1haW50YWluIGV4aXN0aW5nIHRyYW5zcG9ydCBhc3NvY2lhdGlv bnMgb3INCiAgICAgbmVlZCB0byBtYWludGFpbiB0aGVpciBhdmFpbGFiaWxpdHkgZm9yIG5ldyBh c3NvY2lhdGlvbnMuDQogICAgIA0KICAgICBUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIG1vYmlsaXR5 IHByaW9yIHRvIGluaXRpYWwgY29udGFjdCBhbmQNCiAgICAgbW9iaWxpdHkgZHVyaW5nIGFuIGV4 aXN0aW5nIGFzc29jaWF0aW9uIGlzIHNpZ25pZmljYW50LiAgSW4gdGhlDQogICAgIGxhdHRlciBj YXNlLCB0aGUgbW9iaWxlIGhvc3QgY2FuIHVzZSB0aGUgYXNzb2NpYXRpb24gc3RhdGUgd2hlbg0K ICAgICBuZWVkaW5nIHRvIGluZm9ybSB0aGUgb3RoZXIgZW5kcG9pbnQgYWJvdXQgdGhlIGNoYW5n ZS4gIFByaW9yIHRvDQogICAgIGFuIGFzc29jaWF0aW9uIC0tIG9yIHdoZW4gYm90aCBlbmRwb2lu dHMgYXJlIG11dHVhbGx5IG1vYmlsZSAtLQ0KICAgICBhbiBpbmRlcGVuZGVudCByZWZlcnJhbCBz ZXJ2aWNlIGlzIHJlcXVpcmVkLg0KICAgICANCiAgICAgVGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBp bml0aWF0b3IgbW9iaWxpdHkgYW5kIHRhcmdldCBtb2JpbGl0eSBpcw0KICAgICBhbHNvIHNpZ25p ZmljYW50LCB3aXRoIHJlc3BlY3QgdG8gaW5pdGlhbCBjb250YWN0LiAgSW4gcGFydGljdWxhcg0K ICAgICB0aGUgaW5pdGlhdG9yIG5lZWRzIHRvIGJlIGFibGUgdG8gb2J0YWluIGEgdmFsaWQgbG9j YXRvciBmb3IgdGhlDQogICAgIHRhcmdldC4gQWdhaW4sIHRoaXMgcmVxdWlyZXMgYSByZWZlcnJh bCBtZWNoYW5pc20sIHN1Y2ggYXMgaGF2aW5nDQogICAgIHRoZSByb3V0aW5nIHN5c3RlbSBtYXAg ZnJvbSBpZGVudGlmaWVycyB0byByb3V0ZXMsIHJhdGhlciB0aGFuDQogICAgIGxvY2F0b3JzIHRv IHJvdXRlcy4gIEVpdGhlciBpdCBtdXN0IGJlIHByb3ZpZGVkIGltcGxpY2l0bHkgd2l0aGluDQog ICAgIHRoZSBuZXR3b3JrIG9yIHRoZXJlIG11c3QgYmUgYW4gZXh0ZXJuYWwgInJlZmVycmFsIiBt ZWNoYW5pc20uDQogICAgIEZvciBzdGF0aWMgc2VydmVycywgdGhlIEROUyBhbHJlYWR5IHByb3Zp ZGVzIHRoaXMgcmVmZXJyYWwgcXVpdGUNCiAgICAgd2VsbC4gSG93ZXZlciBjdXJyZW50IEROUyB1 c2UgZG9lcyBub3Qgc3VwcG9ydCBmcmVxdWVudCBsb2NhdG9yDQogICAgIGNoYW5nZXMgb3ZlciBz aG9ydCBwZXJpb2RzLiBIZW5jZSBlbmhhbmNlbWVudHMgYXJlIG5lZWRlZCB0bw0KICAgICBzdXBw b3J0IHJlZmVycmFsIHdpdGggYSBtb2JpbGUgdGFyZ2V0Lg0KDQpKQj4gT3V0IG9mIHNjb3BlIGZv ciBtdWx0aTYgbm90IHN1cmUgd2hlcmUgaXQgYmVsb25ncyBpbiBJRVRGIG9mZg0KdGhlIHRvcCBv ZiBteSBoZWFkLg0KDQpKQj4gTm8gb3RoZXIgY29tbWVudHMuICBUaGlzIHNwZWMgZG9lcyBub3Qg ZGlzY3VzcyBvdGhlciBjaG9pY2VzIHRvIE1BU1QNCmJ1dCBkaXNjdXNzZXMgbXVsdGk2IGlzc3Vl cyBpdCBzaG91bGQgYmUgcmVuYW1lZCBhbmQgY2FsbGVkIG11dGxpNiB0ZXJtcw0KYW5hbHlzaXMg YW5kIG11bHRpNiBJUCBhcmNoaXRlY3R1cmUgYW5hbHlzaXMuDQoNCg== ------_=_NextPart_001_01C3A4F1.7886F12C-- From owner-multi6@ops.ietf.org Fri Nov 7 03:07: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 DAA04524 for ; Fri, 7 Nov 2003 03:07:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AI1cm-000PAj-Ng for multi6-data@psg.com; Fri, 07 Nov 2003 08:05:44 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AI1ci-000PAT-ED for multi6@ops.ietf.org; Fri, 07 Nov 2003 08:05:40 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hA78Bmf16742; Fri, 7 Nov 2003 00:11:48 -0800 Date: Fri, 7 Nov 2003 00:05:29 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <64162545858.20031107000529@brandenburg.com> To: "Bound, Jim" CC: multi6@ops.ietf.org Subject: Re: MAST Review JimBo In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B05122598@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B05122598@tayexc13.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, Many thanks for the detailed comments. I'll send detailed responses, later, but wanted to offer some quick reactions quickly: BJ> Attached are revs of MAST and CHOICE. Bottom line is I think MAST BJ> should just stick to multiaddreses injection btw transport and IP layer. That's what it does. However I think that your embedded suggested to just focus on multihoming, rather than including mobility, exactly misses the point behind the term "multiaddressing". As I suggest in the docs, mobility and multihoming should be viewed as two sides of the same requirements coin. The general form of each has properties of the other. BJ> But, I think SCTP does this fine and any extensions your model proposes BJ> is input to SCTP. As I note, putting the functionality inside transport is a reasonable approach. However I think that the nature of multiaddressing support really is independent of particular transports and am increasingly of the view that it needs to be in an "endpoint" IP layer, above the relaying IP layer. Basic IP handling is done well. We should not mess with it. So my own bias is increasingly against messing with the core of IP. Multiaddressing works quite well and an endpoint service. The use of an intermediary (such as a home agent, for the mobility folks) is an extremely useful adjunct, but is not essential to the model. BJ> I think also you should label MAST as a "Reference Model" stage no one BJ> could implement this except maybe a rapid base prototype and then only The document tries to make clear that it is not a specification. It defines functionality, sufficient to permit evaluating its essential architecture. It defers the specification tasks that are equivalent to "debating between commas and semicolons". BJ> believe you have a model. But I see no advantage at all over SCTP and SCTP is still developing its support for mobility. More importantly is that it offers nothing for the installed base of TCP, whereas MAST targets that base. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Sat Nov 8 23:30: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 XAA06783 for ; Sat, 8 Nov 2003 23:30:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIh8m-000GxO-Dy for multi6-data@psg.com; Sun, 09 Nov 2003 04:25:32 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIh8j-000GxC-E9 for multi6@ops.ietf.org; Sun, 09 Nov 2003 04:25:29 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hA94PRY04486 for ; Sun, 9 Nov 2003 06:25:27 +0200 Date: Sun, 9 Nov 2003 06:25:27 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: comments on nordmark-multi-threats Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I made a very quick pass through the document on the plane. The document is excellent, at least the parts that are there. I didn't go through the analysis to see if there might be some remainder threats. One thing the doc could maybe be slightly clearer on is which "security problems" the different attacks rely on (e.g., off-link TCP ACK spoofing, TCP seq number synchronization (could be very challenging if tryly random seq/ack numbers are used, etc.) A couple of observations and minor nits below, nothing major. Similarly, if DNS can be compromised, and a change can be made to an advertised resource record to advertise a different IP address for a hostname, effectively taking over that hostname. ==> does this imply DNS threats, in addition to just hacking thezone? Any system that is along the path from the source to the destination host can be compromised and used to redirect traffic. Systems may be added to the best path to accomplish this. Further, even systems that are on multi-access links that do not provide security can also be used to redirect traffic off of the normal path. For example, ARP and ND spoofing can be used to attract all traffic for the legitimate next hop across an Ethernet. ==> these apply to DNS the paths and links to the DNS server as well, of course. An attribute of this type of attack is that A will simply think that B is faulty since its flow and congestion control mechanisms don't seem to be working. Detecting that the stream of ACK packets is generated from X and not from A might be challenging, since the rate of ACK packets might be relatively low. This type of attack might not be common today because it requires that X remain on the path in order to sustain the DoS attack, but the addition of multihoming redirection mechanisms might potentially remove that constraint. ==> it is not readily apparent why X would need to remain on the path to continue this, but I didn't think this through. Maybe need spelling out? fully editorial --------------- traced to the attacker. An example of this is to use protocols which cause reflection with or without amplification [PAXSON01]. Reflection without amplification can be accomplished by an attacker ==> insert a new line after PAXSON ? this type of attack could either case redirection (so that the ==> s/case/cause/ network before any reassignment. Note that this does not require explicit mechanism. This can instead be implemented by locator reuse ==> s/require/require an/ multihoming solution would fail our "no worse than what we have now" litmus test. However, given that ingress filtering deployment is far ==> "litmus test" ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sun Nov 9 09:24: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 JAA29074 for ; Sun, 9 Nov 2003 09:24:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIqRC-000Ivy-SY for multi6-data@psg.com; Sun, 09 Nov 2003 14:21:10 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIqR6-000IvT-Bs for multi6@ops.ietf.org; Sun, 09 Nov 2003 14:21:04 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hA9EL1CU060712; Sun, 9 Nov 2003 14:21:01 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hA9EKob9248242; Sun, 9 Nov 2003 15:20:56 +0100 Received: from zurich.ibm.com (sig-9-145-145-112.de.ibm.com [9.145.145.112]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA19954; Sun, 9 Nov 2003 15:20:38 +0100 Message-ID: <3FACCF54.BF7F93D8@zurich.ibm.com> Date: Sat, 08 Nov 2003 12:11:16 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: multi6@ops.ietf.org Subject: Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > > > So you would envision manually installing the rules in each > > internal router > > that says "packets with source address prefix X gravitate towards exit > > router Rx"? > > That was my initial idea, yes > > Note that this is not a dynamic information, since it only changes when the > site changes ISP or when the ISP renumbers, and both events shouldn't be > very frequent (at least not so frequent to demand a dynamic protocol) I'm sorry, if we are trying for a mass-market solution we can't assume any ability to do manual config of routing tables. That doesn't exclude this approach, but it requires automatic configs (a.k.a. a routing protocol, or something like Router Renumbering on steroids). Brian From owner-multi6@ops.ietf.org Sun Nov 9 17:27: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 RAA12940 for ; Sun, 9 Nov 2003 17:27:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIxzb-000HR5-ED for multi6-data@psg.com; Sun, 09 Nov 2003 22:25:11 +0000 Received: from [130.129.141.225] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIxzY-000HQd-Vg; Sun, 09 Nov 2003 22:25:09 +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 hA9MOfr7005095; Sun, 9 Nov 2003 23:24:42 +0100 (CET) Date: Sun, 9 Nov 2003 23:23:59 +0100 Subject: Notetaker and jabber logger and scheduling Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush To: multi6@ops.ietf.org From: Kurt Erik Lindqvist Content-Transfer-Encoding: 7bit Message-Id: <69F2A460-1303-11D8-A700-000A9598A184@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If there are people who are volunteers as note takers for the two days, please mail me beforehand. If there are also volunteers to do a jabber log session, please mail me. On the scheduling side it doesn't look too bright. I will try and talk to Randy and the ipv6 chairs and see what we can come up with. On note though, I am really planning to keep questions during the presentations to a bare minimum and instead have all discussions during the long open mike session on wednesday. This means that the Tue afternoon slot should only be really interesting if you have clarification questions. But I will try and talk to the others tonight and get back later. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP66+gaarNKXTPFCVEQJL1QCfbwEI2DvjX3VUjhGaYMx48bX7ubwAn2zY 92P9UgbOVE0aUvBDa5q92Ch+ =VDrl -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Nov 9 18:24:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18682 for ; Sun, 9 Nov 2003 18:24:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AIysH-000K5G-3E for multi6-data@psg.com; Sun, 09 Nov 2003 23:21:41 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AIysD-000K53-PS for multi6@ops.ietf.org; Sun, 09 Nov 2003 23:21:37 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 4DBB3A231; Sun, 9 Nov 2003 18:21:37 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 9 Nov 2003 18:21:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: MAST Review JimBo Date: Sun, 9 Nov 2003 18:21:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0512262E@tayexc13.americas.cpqcorp.net> Thread-Topic: MAST Review JimBo Thread-Index: AcOlBfO2yu19THojQq221D/NAaRbCAB+3YqA From: "Bound, Jim" To: "Dave Crocker" Cc: X-OriginalArrivalTime: 09 Nov 2003 23:21:37.0100 (UTC) FILETIME=[38D458C0:01C3A718] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Dave, > Many thanks for the detailed comments. I'll send detailed > responses, later, but wanted to offer some quick reactions quickly: OK. >=20 >=20 > BJ> Attached are revs of MAST and CHOICE. Bottom line is I > think MAST > BJ> should just stick to multiaddreses injection btw transport and IP > BJ> layer. >=20 > That's what it does. I believe there is much other work going on in MAST that is not multiaddressing. >=20 > However I think that your embedded suggested to just focus on > multihoming, rather than including mobility, exactly misses=20 > the point behind the term "multiaddressing". As I suggest in=20 > the docs, mobility and multihoming should be viewed as two=20 > sides of the same requirements coin. The general form of=20 > each has properties of the other. Mutliaddressing technical depth work is a lot of work and will take time to finish your model, then to build an architecture, and then eventually a true protocol specificaiton. My point was to not confuse that work with the many discussions around multihoming and mobility (so both) stick to the technical work at hand with multihoming and mobility as input clearly. I am saying if this work is to be useful it requires very focused technical work as what your suggesting sits between the transport and IP layer in implementaitions and requires much analysis and thought.=20 But I also believe SCTP is the real way to solve this and until SCTP is deployed out of just Telco this will not be fixed. Multi6 could make SCTP a mandatory requirement for all platforms. >=20 >=20 > BJ> But, I think SCTP does this fine and any extensions your model > BJ> proposes is input to SCTP. >=20 > As I note, putting the functionality inside transport is a > reasonable approach. However I think that the nature of=20 > multiaddressing support really is independent of particular=20 > transports and am increasingly of the view that it needs to=20 > be in an "endpoint" IP layer, above the relaying IP layer. But SCTP already has it done. Including addition and deletion of addresses. So can you clarify what is missing in SCTP? >=20 > Basic IP handling is done well. We should not mess with it. > So my own bias is increasingly against messing with the core=20 > of IP. Multiaddressing works quite well and an endpoint=20 > service. The use of an intermediary (such as a home agent,=20 > for the mobility folks) is an extremely useful adjunct, but=20 > is not essential to the model. What does this mean? MIPv6 works? The issue here is orthogonal. It would help if you could clearly articulate in model terms what problem your trying to solve and then we can put it in terms of technical options. Movement Detection et al is another working group. >=20 >=20 > BJ> I think also you should label MAST as a "Reference Model" > stage no > BJ> one could implement this except maybe a rapid base prototype and > BJ> then only >=20 > The document tries to make clear that it is not a > specification. It defines functionality, sufficient to=20 > permit evaluating its essential architecture. It defers the=20 > specification tasks that are equivalent to "debating between=20 > commas and semicolons". Try just calling it a model that is far more clear than members guessing thats what you mean. >=20 >=20 > BJ> believe you have a model. But I see no advantage at all > over SCTP > BJ> and >=20 > SCTP is still developing its support for mobility. More > importantly is that it offers nothing for the installed base=20 > of TCP, whereas MAST targets that base. My view is if you want this to work with IPv6 you move to SCTP it will be a much cleaner and safer path than MAST hacking between the transport and IP layers and then call outs to the DNS et al tomorrow. Also most platforms support SCTP now because of Telco market. Randy is doing a poll now who has it and who don't. /jim >=20 >=20 > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA >=20 >=20 From owner-multi6@ops.ietf.org Mon Nov 10 14:02: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 OAA05859 for ; Mon, 10 Nov 2003 14:02:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJHGf-0001Gy-LK for multi6-data@psg.com; Mon, 10 Nov 2003 19:00:05 +0000 Received: from [130.129.141.225] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJHGX-0001ED-Fo; Mon, 10 Nov 2003 18:59:57 +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 hAAIxP46000578; Mon, 10 Nov 2003 19:59:25 +0100 (CET) Date: Mon, 10 Nov 2003 19:59:22 +0100 Subject: ipv6 / multi6 clash Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , Bob Fink , Bob Hinden , Brian Haberman To: multi6@ops.ietf.org From: Kurt Erik Lindqvist Content-Transfer-Encoding: 7bit Message-Id: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After looking at the agenda for Multi6 and talking to randy I have the following proposal (well, see this as fact..:-) ). We will run the first session until we are done, over the break. Once done, we can all go to the ipv6 WG. - - kurtis - TUESDAY, November 11, 2003 1545-1645 Afternoon Sessions III ******************************** * Bashing and administrivia (5 minutes) * Marcelo Bagnulo / David Kessens (5 minutes) - DT2 Update * Iljitsch van Beijnum (10 minutes) - DT1 update * Dave Crocker (15 minutes) - draft-crocker-mast-analysis-01.txt - draft-crocker-mast-proposal-01.txt * Arifumi Matsumoto (10 minutes) - draft-arifumi-tcp-mh-00.txt * Masataka Ohta (15 minutes) - draft-ohta-multihomed-isps-00.txt * Kenji Ohira (10 minutes) - draft-ohira-assign-select-e2e-multihome-02.txt - some research results about implementation of SABR 1700-1800 Afternoon Sessions IV Cancelled / ipv6-WG WEDNESDAY, November 12, 2003 0900-1130 Morning Sessions ******************************* * Erik Nordmark (5 minutes) - draft-nordmark-multi6-threats-00.txt * Erik Nordmark (10 minutes) - draft-nordmark-multi6-noid-01.txt - draft-nordmark-multi6-sim-01.txt * Discussions / Open mike -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP6/gDKarNKXTPFCVEQIfHgCgnEIdDx6IV9tBRLYMSvmOF/tKHaMAnRFq +Ta03G/gzpYeDtjzCMsiCL8N =rrNd -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Nov 10 23:37:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05093 for ; Mon, 10 Nov 2003 23:37:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJQFn-0009w3-Cl for multi6-data@psg.com; Tue, 11 Nov 2003 04:35:47 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJQFk-0009vj-SB for multi6@ops.ietf.org; Tue, 11 Nov 2003 04:35:45 +0000 Received: (qmail 58720 invoked from network); 11 Nov 2003 04:42:42 -0000 Received: from dyn071-231.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.71.231) by necom830.hpcl.titech.ac.jp with SMTP; 11 Nov 2003 04:42:42 -0000 Message-ID: <3FB06780.30708@necom830.hpcl.titech.ac.jp> Date: Tue, 11 Nov 2003 13:37:20 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: security requirement for multi6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Here is the security requirement for multihoming with or without DNS. A point is that a set of locators of a host is stable, which makes the requirement different from that for mobility. That is, if a set of all the locators of a host is obtained with certain security, it's OK. Peer of the host should accept any locator in the set. With DNS, a set of all the locators of a host can be simply obtained as a RR set with reasonable security. Those insisting on more complex security may use secure DNS (though secure DNS is impractical to deploy). Without DNS, a cookie and a set of all the locators of a host should be exchanged with the peer as 3 way handshake at the beginning of a communication. The cookie is to prevent DoS with source address spoofing. The handshaking may be performed as a special protocol or piggybacked on an existing protocol. Especially, the handshaking may be piggybacked on initial 3 way handshaking of TCP with sequence numbers as cookies. Even with DNS, the set of locators may still be exchanged, in which case, DNS reverse-forward lookup should be used to verify the set. As the entire process is light weighted (unless secure DNS is used, which is one of a reason why secure DNS is impractical), further attempt of DoS prevention is unreasonable only to increases the chance of DoS. Masataka Ohta From owner-multi6@ops.ietf.org Tue Nov 11 00:13: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 AAA06120 for ; Tue, 11 Nov 2003 00:13:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJQoq-000DUv-Gi for multi6-data@psg.com; Tue, 11 Nov 2003 05:12:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJQol-000DUV-20 for multi6@ops.ietf.org; Tue, 11 Nov 2003 05:11:55 +0000 Received: (qmail 58848 invoked from network); 11 Nov 2003 05:18:53 -0000 Received: from dyn133-168.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.133.168) by necom830.hpcl.titech.ac.jp with SMTP; 11 Nov 2003 05:18:53 -0000 Message-ID: <3FB06FFA.4040506@necom830.hpcl.titech.ac.jp> Date: Tue, 11 Nov 2003 14:13:30 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Spencer Dawkins CC: Multi6 Mailing List Subject: Re: survivability, rewriting References: <7EC2A402-0EC2-11D8-94BB-00039388672E@muada.com> <118701c3a357$219f8310$0400a8c0@DFNJGL21> In-Reply-To: <118701c3a357$219f8310$0400a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Spencer; > In some unrelated conversations in TRIGTRAN, we were saying that Slow > Start is conceptually the right thing to do for path changes, Agreed. However, path changes at the middle of the path are not noticable by end systems. Considering the diameter of the Internet and assuming that reliability of backbone and local ISPs are same, such path changes are expected to occur more often than rehoming. In addition, rehoming is a subset of path chang. So, we, multi6, are not required to address the issues related to path changes. Right? > But this is probably a good TSVWG question. How about let routers accumulate (with XOR or something like that) link CRC (or some psuedo random number involving link specific numbers such as MAC addresses of a hop) into (so far useless) flow label field to let upper layers notice the path change to trigger the transport layer? I myself am afraid that it is too late to change IPv6 router behaviour. So, I never proposed any multihoming solution involving router changes. However, I know transport people are actively proposing to change router behaviour to help TCP and they have better chance with IPv6. :-) Masataka Ohta From owner-multi6@ops.ietf.org Tue Nov 11 01:01: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 BAA07515 for ; Tue, 11 Nov 2003 01:01:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJRZk-000HWF-Jc for multi6-data@psg.com; Tue, 11 Nov 2003 06:00:28 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJRZf-000HVV-3g for multi6@ops.ietf.org; Tue, 11 Nov 2003 06:00:23 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hAB602ed018752; Tue, 11 Nov 2003 07:00:03 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FB06FFA.4040506@necom830.hpcl.titech.ac.jp> References: <7EC2A402-0EC2-11D8-94BB-00039388672E@muada.com> <118701c3a357$219f8310$0400a8c0@DFNJGL21> <3FB06FFA.4040506@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <52C916B3-140C-11D8-A1D0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: survivability, rewriting Date: Tue, 11 Nov 2003 00:00:16 -0600 To: Masataka Ohta X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10-nov-03, at 23:13, Masataka Ohta wrote: > How about let routers accumulate (with XOR or something like > that) link CRC (or some psuedo random number involving link > specific numbers such as MAC addresses of a hop) into (so far > useless) flow label field to let upper layers notice the path > change to trigger the transport layer? Similar to the record route option. > I myself am afraid that it is too late to change IPv6 router > behaviour. So, I never proposed any multihoming solution involving > router changes. Another way to detect path changes, but not a very reliable one, is to monitor the hop limit value in incoming packets. And of course the round trip time. > However, I know transport people are actively proposing to change > router behaviour to help TCP and they have better chance with IPv6. :-) Hm, maybe we can make a deal so that they change TCP behavior to help routers... From owner-multi6@ops.ietf.org Tue Nov 11 01:44: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 BAA08795 for ; Tue, 11 Nov 2003 01:44:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJSFl-000LIC-VG for multi6-data@psg.com; Tue, 11 Nov 2003 06:43:53 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJSFj-000LI0-T6 for multi6@ops.ietf.org; Tue, 11 Nov 2003 06:43:52 +0000 Received: (qmail 59108 invoked from network); 11 Nov 2003 06:50:51 -0000 Received: from dyn051-172.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.51.172) by necom830.hpcl.titech.ac.jp with SMTP; 11 Nov 2003 06:50:51 -0000 Message-ID: <3FB0857A.2040604@necom830.hpcl.titech.ac.jp> Date: Tue, 11 Nov 2003 15:45:14 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Mailing List Subject: Re: survivability, rewriting References: <7EC2A402-0EC2-11D8-94BB-00039388672E@muada.com> <118701c3a357$219f8310$0400a8c0@DFNJGL21> <3FB06FFA.4040506@necom830.hpcl.titech.ac.jp> <52C916B3-140C-11D8-A1D0-000A95CD987A@muada.com> In-Reply-To: <52C916B3-140C-11D8-A1D0-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> How about let routers accumulate (with XOR or something like >> that) link CRC (or some psuedo random number involving link >> specific numbers such as MAC addresses of a hop) into (so far >> useless) flow label field to let upper layers notice the path >> change to trigger the transport layer? > Similar to the record route option. The essential difference is to resuse a fixed length field without burdening routers. >> I myself am afraid that it is too late to change IPv6 router >> behaviour. So, I never proposed any multihoming solution involving >> router changes. > Another way to detect path changes, but not a very reliable one, is to > monitor the hop limit value in incoming packets. And of course the round > trip time. Surely, they can be helpful but are not so reliable. >> However, I know transport people are actively proposing to change >> router behaviour to help TCP and they have better chance with IPv6. :-) > Hm, maybe we can make a deal so that they change TCP behavior to help > routers... I'm, and most of transport layer people, are talking about behaviour at the IP layer, even though the bhaviour may be meaningful for connection oriented transport layers. Masataka Ohta From owner-multi6@ops.ietf.org Tue Nov 11 12:37: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 MAA12435 for ; Tue, 11 Nov 2003 12:37:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJcRA-000BJq-6Q for multi6-data@psg.com; Tue, 11 Nov 2003 17:36:20 +0000 Received: from [130.129.16.24] (helo=delicious.ietf58.ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJcR7-000BJS-97 for multi6@ops.ietf.org; Tue, 11 Nov 2003 17:36:17 +0000 Received: from lolo (dyn135-15.ietf58.ietf.org [130.129.135.15]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hABHaIKi010619; Tue, 11 Nov 2003 11:36:19 -0600 (CST) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" , Subject: RE: security requirement for multi6 Date: Tue, 11 Nov 2003 11:30:16 -0600 Message-ID: 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: <3FB06780.30708@necom830.hpcl.titech.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Masataka, > Here is the security requirement for multihoming with or without > DNS. > > A point is that a set of locators of a host is stable, which > makes the requirement different from that for mobility. This assumption does not take into account a renumbering event, but i agree that this is common scenario. > > That is, if a set of all the locators of a host is obtained > with certain security, it's OK. Peer of the host should accept > any locator in the set. > Agree > With DNS, a set of all the locators of a host can be simply > obtained as a RR set with reasonable security. Those insisting > on more complex security may use secure DNS (though secure DNS > is impractical to deploy). > agree > Without DNS, a cookie and a set of all the locators of a > host should be exchanged with the peer as 3 way handshake > at the beginning of a communication. The cookie is to prevent > DoS with source address spoofing. The handshaking may be > performed as a special protocol or piggybacked on an existing > protocol. Especially, the handshaking may be piggybacked on > initial 3 way handshaking of TCP with sequence numbers as cookies. > Could you expand a little bit how the mechanism would be? I mean how do you deal with threats detailed in section 4.3. Third Party Denial-of-Service Attacks of draft-nordmark-multi6-threats-00.txt. I think that you meant using a cookie, but i think that you will need to exchange the cookie using all of the locators of the set, right? I mean it is not enough to exchange cookie through a single locator, you need to do it through all locators. > Even with DNS, the set of locators may still be exchanged, in > which case, DNS reverse-forward lookup should be used > to verify the set. > Yes, that is noid, i think > As the entire process is light weighted (unless secure DNS is > used, which is one of a reason why secure DNS is impractical), > further attempt of DoS prevention is unreasonable only > to increases the chance of DoS. > The remaining attack AFAICS, is how do you prevent connection hijack from an attacker that intercept the initial three way handshake and then moves away. Note that currenlty an attacker can only hijack a connection as long as he stays in the path intercepting packets, so if you allow this type of attacks you are introducing a new vulnerability. BTW: Erik, in a quick scan i haven't seen this attack in the threats draft, but i guess it should be there, right? Regards, marcelo > Masataka Ohta > > From owner-multi6@ops.ietf.org Tue Nov 11 15:50:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21080 for ; Tue, 11 Nov 2003 15:50:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJfR6-00040a-Hf for multi6-data@psg.com; Tue, 11 Nov 2003 20:48:28 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJfR1-0003yR-Sf for multi6@ops.ietf.org; Tue, 11 Nov 2003 20:48:24 +0000 Received: (qmail 61687 invoked from network); 11 Nov 2003 20:55:33 -0000 Received: from dyn130-87.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.130.87) by necom830.hpcl.titech.ac.jp with SMTP; 11 Nov 2003 20:55:33 -0000 Message-ID: <3FB14B79.7050600@necom830.hpcl.titech.ac.jp> Date: Wed, 12 Nov 2003 05:50:01 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: multi6@ops.ietf.org Subject: Re: security requirement for multi6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, marcelo; >>Without DNS, a cookie and a set of all the locators of a >>host should be exchanged with the peer as 3 way handshake >>at the beginning of a communication. The cookie is to prevent >>DoS with source address spoofing. The handshaking may be >>performed as a special protocol or piggybacked on an existing >>protocol. Especially, the handshaking may be piggybacked on >>initial 3 way handshaking of TCP with sequence numbers as cookies. > Could you expand a little bit how the mechanism would be? I mean how do you > deal with threats detailed in section 4.3. Third Party Denial-of-Service > Attacks of draft-nordmark-multi6-threats-00.txt. > I think that you meant using a cookie, but i think that you will need to > exchange the cookie using all of the locators of the set, right? No. > I mean it is not enough to exchange cookie through a single locator, you > need to do it through all locators. Only thing we can do without DNS is to assure that the identity stays same. In addition, it is silently assumed that a host initiating a connection knows a locator of its peer but not all the set of locators (otherwise, just use the set). It is also assumed that peer initially knows nothing about the initiating host. So, a cookie is used by the initiating host to securely get a set of locators of its peer using the initial locator of the peer. Another cookie is used by the peer to securely get a set of locators of the initiating host using the locator initially used by the initiating host. >>As the entire process is light weighted (unless secure DNS is >>used, which is one of a reason why secure DNS is impractical), >>further attempt of DoS prevention is unreasonable only >>to increases the chance of DoS. > The remaining attack AFAICS, is how do you prevent connection hijack from an > attacker that intercept the initial three way handshake and then moves away. > Note that currenlty an attacker can only hijack a connection as long as he > stays in the path intercepting packets, Such a attack will be meaningful as a faked peer (server) of a host (client) initiating a connection. However, prevention of connection hijack against a temporary MITM is not a requirement, at all. > so if you allow this type of attacks > you are introducing a new vulnerability. No, it is not new. As I wrote to Erik, with DNS, if MITM intercepts initial DNS exchange to redirect a connection to his host elsewhere, the connection is hijacked by a host not currently on the path. That is, prevention of connection hijack against a temporary MITM is impossible without expensive security mechanism and is not a requirement here. Masataka Ohta PS Considering that it is not realistic to type raw IPv6 addresses, it may be reasonable to assume that addresses are obtained from DNS or some electric media, in either of which case, the entire set of locators can be stored that there is nothing to worry about. From owner-multi6@ops.ietf.org Tue Nov 11 17:52: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 RAA25962 for ; Tue, 11 Nov 2003 17:52:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJhLb-000GKK-RX for multi6-data@psg.com; Tue, 11 Nov 2003 22:50:55 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJhLZ-000GK4-Q8 for multi6@ops.ietf.org; Tue, 11 Nov 2003 22:50:53 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hABMoaed029760 for ; Tue, 11 Nov 2003 23:50:37 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3E44672F-FD67-11D7-B291-00039388672E@muada.com> References: <3E44672F-FD67-11D7-B291-00039388672E@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7E9167F4-1499-11D8-A1D0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Bash IETF, not RIRs Date: Tue, 11 Nov 2003 16:50:49 -0600 To: Multi6 Mailing List X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 13-okt-03, at 5:23, Iljitsch van Beijnum wrote: > Back to your idea of having a full routing table in each host. We've > talked about this and things haven't changed in the mean time. Without > aggregation, this makes sense, as a host then knows what's reachable > and what isn't, and maybe even gets to determine which path to a > certain destination is shorter. But all this very useful information > is hidden behind aggregation. For instance, if you want to determine > whether you want to reach me through my 3ffe:2500:310::/48 or my > 2001:888:1dde::/48 prefix, you're not going to be able to see whether > those are reachable, as the /48s aren't going to be in the global > routing table, just 3ffe:2500::/32 and 2001:888::/32. From owner-multi6@ops.ietf.org Tue Nov 11 18:52: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 SAA29269 for ; Tue, 11 Nov 2003 18:52:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJiHy-000Lh1-Gx for multi6-data@psg.com; Tue, 11 Nov 2003 23:51:14 +0000 Received: from [130.129.16.24] (helo=delicious.ietf58.ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJiHt-000Lgk-Ay for multi6@ops.ietf.org; Tue, 11 Nov 2003 23:51:09 +0000 Received: from lolo (dyn130-50.ietf58.ietf.org [130.129.130.50]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hABNowKg028458; Tue, 11 Nov 2003 17:51:02 -0600 (CST) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: security requirement for multi6 Date: Tue, 11 Nov 2003 17:44:57 -0600 Message-ID: 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: <3FB14B79.7050600@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So, a cookie is used by the initiating host to securely get a set > of locators of its peer using the initial locator of the peer. > > Another cookie is used by the peer to securely get a set of > locators of the initiating host using the locator initially > used by the initiating host. So if you don't use RR to verify address owbership for each of the locators, could you explain me how do you deal with threats detailed in section 4.3. Third Party Denial-of-Service Attacks of draft-nordmark-multi6-threats-00.txt? > > >>As the entire process is light weighted (unless secure DNS is > >>used, which is one of a reason why secure DNS is impractical), > >>further attempt of DoS prevention is unreasonable only > >>to increases the chance of DoS. > > > The remaining attack AFAICS, is how do you prevent connection > hijack from an > > attacker that intercept the initial three way handshake and > then moves away. > > Note that currenlty an attacker can only hijack a connection as > long as he > > stays in the path intercepting packets, > > Such a attack will be meaningful as a faked peer (server) of a > host (client) initiating a connection. > > However, prevention of connection hijack against a temporary MITM > is not a requirement, at all. I think it is. If it weren't we could just use MIPv6 and end of the story [...] > > Considering that it is not realistic to type raw IPv6 addresses, > it may be reasonable to assume that addresses are obtained from > DNS or some electric media, in either of which case, the entire > set of locators can be stored that there is nothing to worry > about. Let me see if i understand what you are saying: (please correct me if i am wrong, (i know you will ;-) - you assume that all communications will use DNS to obtain addresses - DNS is susceptible to temporary MITM attacks - so, the proposed solution should not protect against temporary MITM attacks since they are already there. is this right? Well i don't know if the first one is a reasonable assumption. This would imply that we would be actually make the internet weaker, since you won't be protected from temporary MITM attack eevn if you don't use DNS. Regards, marcelo > > > From owner-multi6@ops.ietf.org Tue Nov 11 18:59: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 SAA29458 for ; Tue, 11 Nov 2003 18:59:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJiPw-000MXl-S4 for multi6-data@psg.com; Tue, 11 Nov 2003 23:59:28 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJiPu-000MUF-5F for multi6@ops.ietf.org; Tue, 11 Nov 2003 23:59:26 +0000 Received: (qmail 62239 invoked from network); 12 Nov 2003 00:06:38 -0000 Received: from dyn071-231.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.71.231) by necom830.hpcl.titech.ac.jp with SMTP; 12 Nov 2003 00:06:38 -0000 Message-ID: <3FB1783F.3090400@necom830.hpcl.titech.ac.jp> Date: Wed, 12 Nov 2003 09:01:03 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Mailing List Subject: Re: Bash IETF, not RIRs References: <3E44672F-FD67-11D7-B291-00039388672E@muada.com> <7E9167F4-1499-11D8-A1D0-000A95CD987A@muada.com> In-Reply-To: <7E9167F4-1499-11D8-A1D0-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> Back to your idea of having a full routing table in each host. We've >> talked about this and things haven't changed in the mean time. Read the draft before talking or things won't change in your mind. With regard to multihoming, when an end system want to communicate with a multihomed end system, the end system must be able to select most appropriate (based on the local information) destination address of the multihomed end system. However, some think it of course to separate routers and nodes and let hosts not have routing information (which means the current IPv6 architecture is broken) and, worse, let most routers use default routes. With detailed route information, end systems can use the information as a hint to select the best destination address. However, with default route, end systems have no idea on what is the best address and must blindly try all the possibilities at random. >> Without >> aggregation, this makes sense, as a host then knows what's reachable >> and what isn't, and maybe even gets to determine which path to a >> certain destination is shorter. But all this very useful information >> is hidden behind aggregation. For instance, if you want to determine >> whether you want to reach me through my 3ffe:2500:310::/48 or my >> 2001:888:1dde::/48 prefix, you're not going to be able to see whether >> those are reachable, as the /48s aren't going to be in the global >> routing table, just 3ffe:2500::/32 and 2001:888::/32. If routing system tells you that some address is not reachable, which is impossible with a default route, the address is not reachable. But, don't expect routing system offer more accuracy. Aggregation is not essential. Even if you use host routes, exsiting of a host route does not guarantee that the host is reachable. It may be just a result of misconfiguration. Routing systems give hint to help hosts make efficient decisions. Note also that this is not the only reason to have full routing table. The fundamental reason is because it is end to end. Masataka Ohta From owner-multi6@ops.ietf.org Tue Nov 11 19: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 TAA00184 for ; Tue, 11 Nov 2003 19:25:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJioF-000Ohg-Fv for multi6-data@psg.com; Wed, 12 Nov 2003 00:24:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJioC-000OhH-MT for multi6@ops.ietf.org; Wed, 12 Nov 2003 00:24:32 +0000 Received: (qmail 62305 invoked from network); 12 Nov 2003 00:31:45 -0000 Received: from dyn071-231.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.71.231) by necom830.hpcl.titech.ac.jp with SMTP; 12 Nov 2003 00:31:45 -0000 Message-ID: <3FB17E22.6070904@necom830.hpcl.titech.ac.jp> Date: Wed, 12 Nov 2003 09:26:10 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: multi6@ops.ietf.org Subject: Re: security requirement for multi6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; > Let me see if i understand what you are saying: (please correct me if i am > wrong, (i know you will ;-) > - you assume that all communications will use DNS to obtain addresses > - DNS is susceptible to temporary MITM attacks > - so, the proposed solution should not protect against temporary MITM > attacks since they are already there. > > is this right? > > Well i don't know if the first one is a reasonable assumption. > This would imply that we would be actually make the internet weaker, since > you won't be protected from temporary MITM attack eevn if you don't use DNS. My point is that temporary MITM attacks are no new and common. If you don't like DNS, consider temporary MITM in FTP control channel to redirect data connection. Or, consider temporary MITM compromise a host in the middle, which works as a MITM to do anything. Prevention of connection hijack against a temporary MITM is not a requirement, at all. > If it weren't we could just use MIPv6 and end of the story At Vienna, I gave three reasons on why MIPv6 is hopeless and can not be used for M6. As you agreed with me: > >>A point is that a set of locators of a host is stable, which > >> makes the requirement different from that for mobility. > This assumption does not take into account a renumbering event, but i agree > that this is common scenario. Difference of security model requirement makes security mechanism different. The only interaction I can see so far between mobility and multihoming is that they should use same packet format, which should address the MTU problem of mobility forwarding. Masataka Ohta PS Renumbering can be addressed by making DNS query again after TTL expiration or by sending set of locators in TCP option again, though I'm not sure it worthes the effort. From owner-multi6@ops.ietf.org Wed Nov 12 03:00:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10289 for ; Wed, 12 Nov 2003 03:00:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJprc-000Dpv-Ch for multi6-data@psg.com; Wed, 12 Nov 2003 07:56:32 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJprZ-000DmJ-9J for multi6@ops.ietf.org; Wed, 12 Nov 2003 07:56:29 +0000 Received: (qmail 63553 invoked from network); 12 Nov 2003 08:03:46 -0000 Received: from dyn055-190.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.55.190) by necom830.hpcl.titech.ac.jp with SMTP; 12 Nov 2003 08:03:46 -0000 Message-ID: <3FB1E80F.6070204@necom830.hpcl.titech.ac.jp> Date: Wed, 12 Nov 2003 16:58:07 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: multi6@ops.ietf.org Subject: Re: security requirement for multi6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>Even with DNS, the set of locators may still be exchanged, in >>which case, DNS reverse-forward lookup should be used >>to verify the set. > Yes, that is noid, i think Wrong. DNS reverse-foward lookup of IPv4 is PTR and A lookup. DNS revers-forward lookup of IPv6 is PTR and A* lookup. No cryptographic technology should be involved only to extend valunerability by DoS. Masataka Ohta From owner-multi6@ops.ietf.org Wed Nov 12 09:57: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 JAA19786 for ; Wed, 12 Nov 2003 09:57:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJwOL-000Ias-2G for multi6-data@psg.com; Wed, 12 Nov 2003 14:54:45 +0000 Received: from [130.129.16.24] (helo=delicious.ietf58.ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJwOA-000IS4-0B for multi6@ops.ietf.org; Wed, 12 Nov 2003 14:54:34 +0000 Received: from lolo (dyn130-50.ietf58.ietf.org [130.129.130.50]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hACEsUKi026165; Wed, 12 Nov 2003 08:54:39 -0600 (CST) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" , "Iljitsch van Beijnum" Cc: "Multi6 Mailing List" Subject: RE: Bash IETF, not RIRs Date: Wed, 12 Nov 2003 08:48:32 -0600 Message-ID: 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: <3FB1783F.3090400@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Aggregation is not essential. > I guess this is not really what you mean. aggregation is essential to provide scalability of the routing system, as your draft about ISP multi-homing explains (sort of) > Even if you use host routes, exsiting of a host route does not > guarantee that the host is reachable. It may be just a result of > misconfiguration. > > Routing systems give hint to help hosts make efficient decisions. > Well i guess that the question then is it is worth it... If the table is very aggregated, you don't really have much information If it is not, the amount of information is huge and it is very expensive for a host to store it And all this effort, just for a hint. You will need another mechanism that actually detects and define which address to use, so why don't you just use it in the first place? Regards, marcelo > Masataka Ohta > > > From owner-multi6@ops.ietf.org Wed Nov 12 09:57: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 JAA19850 for ; Wed, 12 Nov 2003 09:57:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJwOC-000IWK-VK for multi6-data@psg.com; Wed, 12 Nov 2003 14:54:36 +0000 Received: from [130.129.16.24] (helo=delicious.ietf58.ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJwO9-000IS2-6a for multi6@ops.ietf.org; Wed, 12 Nov 2003 14:54:33 +0000 Received: from lolo (dyn130-50.ietf58.ietf.org [130.129.130.50]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hACEsUKg026165; Wed, 12 Nov 2003 08:54:32 -0600 (CST) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: security requirement for multi6 Date: Wed, 12 Nov 2003 08:48:25 -0600 Message-ID: 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: <3FB17E22.6070904@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Prevention of connection hijack against a temporary MITM > is not a requirement, at all. I would like other opinions about this particular issue... does anyone care to comment? > > > If it weren't we could just use MIPv6 and end of the story > > At Vienna, I gave three reasons on why MIPv6 is hopeless > and can not be used for M6. > Sorry i remeber the following ones: 1) timing in mip is not compatible with multi-homing My answer to this is that the idea is not to use mip as is, but use the packet format and the CN route optimization capabilities. So mip timing is not really being used, so i think this should not be an issue. the next one would be security as you mention, right? > Difference of security model requirement makes security mechanism > different. Well if you don't care about tmeporary MITM attacks, mip provides all the security that you need, so i don't see a problem here > > The only interaction I can see so far between mobility and > multihoming is that they should use same packet format, which > should address the MTU problem of mobility forwarding. Well as i mention above, not only packet format but CN route optimization capabilities, which IMHO is the main benefit of using mip, (i.e. you don't need to deploy new mechanisms in external hosts) I agree that PMTU is an issue, but i would say that we could do some optimizations to improve that, and that capability of re-using CN RO capabilities outweights this particular drawback IMHO Regards, marcelo > > Masataka Ohta > > PS > > Renumbering can be addressed by making DNS query again after > TTL expiration or by sending set of locators in TCP option again, > though I'm not sure it worthes the effort. > > > From owner-multi6@ops.ietf.org Wed Nov 12 10:10: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 KAA20770 for ; Wed, 12 Nov 2003 10:10:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJwct-000LIR-JU for multi6-data@psg.com; Wed, 12 Nov 2003 15:09:47 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AJwcn-000LI3-6b for multi6@ops.ietf.org; Wed, 12 Nov 2003 15:09:41 +0000 Received: (qmail 64909 invoked from network); 12 Nov 2003 15:17:03 -0000 Received: from dyn133-168.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.133.168) by necom830.hpcl.titech.ac.jp with SMTP; 12 Nov 2003 15:17:03 -0000 Message-ID: <3FB24D93.3070904@necom830.hpcl.titech.ac.jp> Date: Thu, 13 Nov 2003 00:11:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: Bash IETF, not RIRs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>Aggregation is not essential. > I guess this is not really what you mean. aggregation is essential to > provide scalability of the routing system, as your draft about ISP > multi-homing explains (sort of) Aggregation is not essential cause of the concern of Iljitsch. >>Even if you use host routes, exsiting of a host route does not >>guarantee that the host is reachable. It may be just a result of >>misconfiguration. >> >>Routing systems give hint to help hosts make efficient decisions. > Well i guess that the question then is it is worth it... I wronte: > Note also that this is not the only reason to have full routing table. > > The fundamental reason is because it is end to end. > If the table is very aggregated, you don't really have much information If the table have only a single entry, yes. > If it is not, the amount of information is huge and it is very expensive for > a host to store it My presentation yesterday quantatatively showed you are totally wrong. Masataka Ohta From owner-multi6@ops.ietf.org Wed Nov 12 10:25: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 KAA21847 for ; Wed, 12 Nov 2003 10:25:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AJwrP-000Nre-MA for multi6-data@psg.com; Wed, 12 Nov 2003 15:24:47 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AJwrL-000NqV-JB for multi6@ops.ietf.org; Wed, 12 Nov 2003 15:24:43 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACFOg624873 for ; Wed, 12 Nov 2003 17:24:42 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 12 Nov 2003 17:24:42 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 07:24:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Some Comments on ID/Loc Separation Proposals Date: Wed, 12 Nov 2003 10:24:35 -0500 Message-ID: Thread-Topic: Routing table size? Thread-Index: AcOQsRIxB4I8BHIRRCSjlnQS7yjaHgAaFmhgBgWce+A= From: To: X-OriginalArrivalTime: 12 Nov 2003 15:24:36.0132 (UTC) FILETIME=[14A47640:01C3A931] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I have been analyzing a few of the proposal for ID/Loc separation (HIP, NOID and MAST) and I have some comments (attached). =20 Unfortunately, I won't be in most of the multi6 meeting today=20 (I may pop in and out), but please consider this e-mail as input=20 to your discussion. Sorry for the cryptic nature of some of these comments. If there are any questions, let me know. I may try to write-up something more detailed later. Margaret General Thoughts: The combination of ID/Loc in IP (v4 and v6) is an architectural feature with good and bad trade-offs. It can be viewed as an ID/Loc system with: (1) Very efficient ID -> Loc mapping (they are the same), (2) An inflexible association between a single=20 ID and a specific Locator (they are the same). Property #1=20 allows convenient, high performance referrals. Property #2=20 causes difficulties for mobility, multihoming, etc. The use of the term "Identifier" or "ID" sweeps an important issue under the rug in some cases: Is this a host ID or an interface ID? The current IP (v4 and v6) architecture uses=20 interface IDs. IPv4 implementations are generally constrained=20 to one ID per interface, while IPv6 supports multiple IDs per=20 interface. ID selection is linked to outbound interface selection -- it is still unclear to me what implications this has for ID or Locator selection in ID/Loc separation protocols. --- Some things to consider for proposals: What are the mechanisms to support (and the costs of): - Initial end-to-end connection set-up. - Referrals. The question I ask is: Could this mechanism support FTP PASV mode -- I know no one uses it, but it is=20 a simple, well-understood referral. If a mechanism won't support FTP PASV, then it won't support any referral-based application. - What happens when two nodes try to establish connections to each other "simultaneously" (where "simultaneously" is defined to mean "during each others' connection set-up window"). - How does the mechanism avoid connection hijacking? Of course, there are many other interesting questions. --- NOID Feedback: Interesting proposal that offers at least some support for referrals and offers a zero-cost mapping from an ID to a=20 locator, by using one of the available locators as the ID. Supports multihoming and planned renumbering, but not=20 roaming/mobility. Specific comments/issues: - NOID is not compatible with local addressing or=20 "two-faced" DNS. Relies on consistent information being returned from the DNS at both ends. - NOID happens below frag/reassm, but may add 8 bytes to the packet length. ?? - NOID may have issues when two hosts both attempt to open a connection to the other within the NOID establishment phase (which may last for a while, as it involves two DNS lookups, etc.). If I am modeling this correctly, if NodeA is currently in the process of establishing a NOID connection to Node B (we have the state set-up on NodeA, but not on NodeB), NodeB's attempts to open a connection to NodeA will be discarded by NodeA because they don't contain the correct FlowID. Am I right? If so, is this a problem? - If the topological information in an AID is no=20 longer valid to reach the node, a referral will require two DNS lookups (reverse lookup, followed by forward lookup) before the new connection can be established. This represents a significant=20 change to the speed/performance of referrals. --- MAST Feedback: Uses a control protocol between the two end-nodes to=20 exchange address information. The current proposal is two sparsely defined to allow a full analysis of its properties. In particular the document does not describe when MAST control messages would be sent, and how the nodes would know when to send them. Specific Comments/Issues: - This proposal seems, to me, to sweep the entire problem under the rug of this mostly-unspecified control protocol.=20 - How do the end-points know when they need to=20 send SET operations to update the locators=20 being used on the ends of this connection? - The draft suggests using IPsec to secure the control connection, but IPsec doesn't support changing end-point addresses. - The PROBE message sounds (to me) similar to=20 the old proposal to use pings to detect dead gateways. What can we learn from the problems with that model that apply here? I have stored my knowledge of the issues here in long-term storage, and I'm still waiting to retrieve it. But, there are some serious issues with active keepalive mechanisms that we should probably consider here. --- HIP Feedback Very well-developed proposal for end-to-end ID/Loc separation. No ID->Locator mapping mechanism, so no support for referrals. Specific Feedback: - The lack of any ID->Locator mapping mechanism is a=20 blocking problem for using HIP (as currently defined) with anything but simple end-to-end applications. =20 From owner-multi6@ops.ietf.org Wed Nov 12 15: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 PAA04927 for ; Wed, 12 Nov 2003 15:04:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK1CD-0002HU-1f for multi6-data@psg.com; Wed, 12 Nov 2003 20:02:33 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK1Br-0002GI-0M for multi6@ops.ietf.org; Wed, 12 Nov 2003 20:02:11 +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 hACM6wOt017005 for ; Wed, 12 Nov 2003 14:06:58 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hACK24YB013015 for ; Wed, 12 Nov 2003 12:02:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Summary of work areas Date: Wed, 12 Nov 2003 12:02:03 -0800 Message-ID: Thread-Topic: Summary of work areas Thread-Index: AcOpV9t7VBSnSwMRR06XVy+lmYMtUg== From: "Tony Li" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, To help Elliot out, I'd like for us to start thinking about our top level work items. As top level items, they should, IMHO, be as independent as possible (tho not wholly independent). They should not be nested and they should not be about the details. Here's a strawman: Threat analysis Locator storage & distribution Mappings between locators, identifiers, and FQDNs Security solutions Exit addressing Additions, modifications? Tony From owner-multi6@ops.ietf.org Wed Nov 12 15:35: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 PAA07816 for ; Wed, 12 Nov 2003 15:35:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK1gz-0008M4-VV for multi6-data@psg.com; Wed, 12 Nov 2003 20:34:21 +0000 Received: from [130.129.16.24] (helo=delicious.ietf58.ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK1gx-0008Le-KE for multi6@ops.ietf.org; Wed, 12 Nov 2003 20:34:19 +0000 Received: from lolo (dyn133-51.ietf58.ietf.org [130.129.133.51]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hACKYPKg007439; Wed, 12 Nov 2003 14:34:26 -0600 (CST) Reply-To: From: "marcelo bagnulo" To: "Tony Li" , Subject: RE: Summary of work areas Date: Wed, 12 Nov 2003 14:28:17 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 5 (Lowest) X-MSMail-Priority: Low X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Low X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, I think that another issue that should be included is locator selection. Inside locator selection you have multiple related topics: First you have to split it in source locator selection and destination locator selection. Then other items fit in like: Locator selection for initial contact Locator selection during the communication lifetime Policing Load sharing Questions: by exit addressing you mean mechanism to ensure ingress filtering compatibility? By security solutions you mean security solutions to preserve established communications right? And also by Locator storage & distribution and Mappings between locators, identifiers, and FQDNs you are also considering this items in the context of preserving established communications, right? I mean, if i understand your items correclty, 3 or 4 of the 5 itmes are focused on preserving established communications, so perhaps an initial top level item could be preserving established communications? Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Tony Li > Enviado el: miercoles, 12 de noviembre de 2003 14:02 > Para: multi6@ops.ietf.org > Asunto: Summary of work areas > > > > Hi, > > To help Elliot out, I'd like for us to start thinking > about our top level work items. As top level items, > they should, IMHO, be as independent as possible (tho > not wholly independent). They should not be nested and > they should not be about the details. > > Here's a strawman: > > > Threat analysis > Locator storage & distribution > Mappings between locators, identifiers, and FQDNs > Security solutions > Exit addressing > > Additions, modifications? > > Tony > From owner-multi6@ops.ietf.org Wed Nov 12 15:51: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 PAA08829 for ; Wed, 12 Nov 2003 15:51:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK1wy-000AS5-OB for multi6-data@psg.com; Wed, 12 Nov 2003 20:50:52 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK1ww-000ARk-Dj for multi6@ops.ietf.org; Wed, 12 Nov 2003 20:50:50 +0000 Received: from dfnjgl21 (dyn132-29.ietf58.ietf.org[130.129.132.29]) by comcast.net (rwcrmhc13) with SMTP id <2003111220504901500ain0fe> (Authid: sdawkins@comcast.net); Wed, 12 Nov 2003 20:50:49 +0000 Message-ID: <001201c3a95e$a70a83d0$1d848182@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: Subject: Re: Summary of work areas Date: Wed, 12 Nov 2003 14:50:48 -0600 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My list may be more cross-area than multi6 has a stomach for, although I've been astonished at the sense of humor of the chairs so far, but I wonder about these related topics: - what multihoming switching looks like to applications (especially whether/how applications might select locators) - any possibilities for loadsharing - transport reaction to multihoming switching (or explicitly assume end-to-end adaptation continues to be the right answer) Although it's outside my own area, I also wonder about interaction of multihoming with renumbering. Spencer ----- Original Message ----- From: "Tony Li" To: Sent: Wednesday, November 12, 2003 2:02 PM Subject: Summary of work areas Hi, To help Elliot out, I'd like for us to start thinking about our top level work items. As top level items, they should, IMHO, be as independent as possible (tho not wholly independent). They should not be nested and they should not be about the details. Here's a strawman: Threat analysis Locator storage & distribution Mappings between locators, identifiers, and FQDNs Security solutions Exit addressing Additions, modifications? Tony From owner-multi6@ops.ietf.org Wed Nov 12 15:54: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 PAA09050 for ; Wed, 12 Nov 2003 15:54:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK20h-000Aqa-9V for multi6-data@psg.com; Wed, 12 Nov 2003 20:54:43 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AK20f-000AqF-3U for multi6@ops.ietf.org; Wed, 12 Nov 2003 20:54:41 +0000 Received: (qmail 66330 invoked from network); 12 Nov 2003 21:02:08 -0000 Received: from dyn055-190.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.55.190) by necom830.hpcl.titech.ac.jp with SMTP; 12 Nov 2003 21:02:08 -0000 Message-ID: <3FB29E1E.1090808@necom830.hpcl.titech.ac.jp> Date: Thu, 13 Nov 2003 05:54:54 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: multi6@ops.ietf.org Subject: Re: security requirement for multi6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>>If it weren't we could just use MIPv6 and end of the story >> >>At Vienna, I gave three reasons on why MIPv6 is hopeless >>and can not be used for M6. > Sorry i remeber the following ones: > 1) timing in mip is not compatible with multi-homing No, it is not. It, instead, is a reason on why MIPv6 mechanism can not be used for M6. But, let's continue. > My answer to this is that the idea is not to use mip as is, but use the > packet format and the CN route optimization capabilities. So mip timing is > not really being used, so i think this should not be an issue. With MIPv6, CN is expected to use a new locator. With M6, a host is free to choose any locator, which, in most cases, the host has from the beginning. > the next one would be security as you mention, right? Yup. >>Difference of security model requirement makes security mechanism >>different. > Well if you don't care about tmeporary MITM attacks, mip provides all the > security that you need, so i don't see a problem here I don't care about MITM between CN and HA. MITM between CN and MN, local environment of which is foreign, is a different matter. > Well as i mention above, not only packet format but CN route optimization > capabilities, which IMHO is the main benefit of using mip, (i.e. you don't > need to deploy new mechanisms in external hosts) No new mechanism even if timing and security are completely different? > I agree that PMTU is an issue That is a reason on why MIPv6 is hopeless, though it has less relevence to this WG. Other reasons are DAD and unnecessary complexities. Masataka Ohta From owner-multi6@ops.ietf.org Wed Nov 12 17:12:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12725 for ; Wed, 12 Nov 2003 17:12:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK3Bt-000K4u-5O for multi6-data@psg.com; Wed, 12 Nov 2003 22:10:21 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK3Bq-000K4U-Jq for multi6@ops.ietf.org; Wed, 12 Nov 2003 22:10:18 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hACM9fed045187; Wed, 12 Nov 2003 23:09:45 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FB17E22.6070904@necom830.hpcl.titech.ac.jp> References: <3FB17E22.6070904@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: security requirement for multi6 Date: Wed, 12 Nov 2003 16:09:00 -0600 To: Masataka Ohta X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 11-nov-03, at 18:26, Masataka Ohta wrote: > Prevention of connection hijack against a temporary MITM > is not a requirement, at all. The attack vector here would that an attacker opens a TCP session to a third party relay host and requests a large amount of data. When the data starts flowing, the attacker sends a false rehoming message that makes the relay host redirect the flow to the target. Then the attacker sends spoofed TCP ACKs that make the relay host keep sending data at high speed. The victim will start sending back TCP RSTs to get the relay host to stop sending data, but even if the relay host immediately stops sending, the attacker was able to generate abusive traffic for a round trip time. We're probably not talking megabits worth of data, but it would be enough to choke a limited bandwidth host. Also, the fake ACKs will probably make the RSTs fall outside the allowed window so they're ignored, so the attack doesn't stop regardless of RSTs. From owner-multi6@ops.ietf.org Wed Nov 12 18:11: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 SAA15724 for ; Wed, 12 Nov 2003 18:11:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK483-000PwD-2M for multi6-data@psg.com; Wed, 12 Nov 2003 23:10:27 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK47z-000PvF-7d for multi6@ops.ietf.org; Wed, 12 Nov 2003 23:10:23 +0000 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 12 Nov 2003 15:10:31 -0800 Received: from xbe-rtp-212.cisco.com (xbe-rtp-212.cisco.com [64.102.23.41]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hACNAKxg025094 for ; Wed, 12 Nov 2003 18:10:20 -0500 (EST) Received: from xfe-rtp-212.cisco.com ([64.102.23.37]) by xbe-rtp-212.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Nov 2003 18:10:20 -0500 Received: from [127.0.0.1] ([64.102.23.30]) by xfe-rtp-212.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 12 Nov 2003 18:10:16 -0500 Mime-Version: 1.0 (Apple Message framework v606) Content-Transfer-Encoding: 7bit Message-Id: <5EE8F860-1565-11D8-9562-000A959CF516@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: multi6@ops.ietf.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: noid and applications (generic requirements from applications) Date: Wed, 12 Nov 2003 17:10:13 -0600 X-Mailer: Apple Mail (2.606) X-OriginalArrivalTime: 12 Nov 2003 23:10:20.0227 (UTC) FILETIME=[249EF930:01C3A972] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have read through draft-nordmark-multi6-noid-01.txt from an applications perspective, and I have some generic questions. There are of course many parts of the draft which I don't understand, so there might be answers hidden somewhere. I like pictures though ;-) In draft-nordmark-multi6-noid-01.txt there is a picture: ---------------------- ---------------------- | Sender A | | Receiver B | | | | | | ULP | | ULP | | | src AID(A) | | ^ | | | dst AID(B) | | | src AID(A) | | v | | | dst AID(B) | | M6 | | M6 | | | src L1(A) | | ^ | | | dst L1(B) | | | src L2(A) | | v | | | dst L1(B) | | IP | | IP | ---------------------- ---------------------- | ^ -- cloud with some routers ------- src L2(A) [Rewritten] dst L1(B) Figure 2: Mapping with router rewriting of locators. In this picture A send thinsg to B, and use as src AID(A) and dst AID(B). Questions: If B send a packet back to A, can AID(B) be used as src, and AID(A) as dst? If B send a packet to C with src AID(B) and dst AID(C), can B send AID(A) to C so C can use src AID(C) and dst AID(A)? If both of these are true, let's dive into DNS/application issues... paf From owner-multi6@ops.ietf.org Wed Nov 12 18:25: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 SAA16924 for ; Wed, 12 Nov 2003 18:25:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK4LS-0001IN-2x for multi6-data@psg.com; Wed, 12 Nov 2003 23:24:18 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AK4LP-0001Hw-MI for multi6@ops.ietf.org; Wed, 12 Nov 2003 23:24:15 +0000 Received: (qmail 66773 invoked from network); 12 Nov 2003 23:31:45 -0000 Received: from dyn071-231.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.71.231) by necom830.hpcl.titech.ac.jp with SMTP; 12 Nov 2003 23:31:45 -0000 Message-ID: <3FB2C181.8090700@necom830.hpcl.titech.ac.jp> Date: Thu, 13 Nov 2003 08:25:53 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Mailing List Subject: Re: security requirement for multi6 References: <3FB17E22.6070904@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; I should state an elementary fact again. DoS is so easy. That is, that you happen to find a way of DoS does not mean other forms of DoS is not possible. >> Prevention of connection hijack against a temporary MITM >> is not a requirement, at all. > The attack vector here would that an attacker opens a TCP session to a > third party relay host and requests a large amount of data. When the > data starts flowing, the attacker sends a false rehoming message that > makes the relay host redirect the flow to the target. Then the attacker > sends spoofed TCP ACKs that make the relay host keep sending data at > high speed. The attacker as a temporary MITM opens a TCP session to a third party relay host with a spoofed source address of a target and requests a large amount of data. When the data starts flowing, the attacker moves away that makes the relay host direct the flow to the target. Then the attacker, now at a distance, sends spoofed TCP ACKs that make the relay host keep sending data at high speed. Masataka Ohta From owner-multi6@ops.ietf.org Wed Nov 12 18:33: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 SAA17216 for ; Wed, 12 Nov 2003 18:33:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK4UG-0002Kc-Uc for multi6-data@psg.com; Wed, 12 Nov 2003 23:33:24 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK4UC-0002JV-Qj for multi6@ops.ietf.org; Wed, 12 Nov 2003 23:33:20 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hACNX0ed046163; Thu, 13 Nov 2003 00:33:01 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FB2C181.8090700@necom830.hpcl.titech.ac.jp> References: <3FB17E22.6070904@necom830.hpcl.titech.ac.jp> <3FB2C181.8090700@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <968ACFD4-1568-11D8-A1D0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: security requirement for multi6 Date: Wed, 12 Nov 2003 17:33:15 -0600 To: Masataka Ohta X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12-nov-03, at 17:25, Masataka Ohta wrote: > I should state an elementary fact again. > DoS is so easy. Unfortunately that is true. > That is, that you happen to find a way of DoS does not mean other > forms of DoS is not possible. Still, I think this new kind of denial of service is bad enough that we shouldn't allow this to happen, even though other denial of service attacks are also possible today. Hopefully we'll be able to do something about that in the future. Iljitsch From owner-multi6@ops.ietf.org Wed Nov 12 18:44: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 SAA17671 for ; Wed, 12 Nov 2003 18:44:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK4ej-0003ca-A7 for multi6-data@psg.com; Wed, 12 Nov 2003 23:44:13 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AK4ea-0003aT-6f for multi6@ops.ietf.org; Wed, 12 Nov 2003 23:44:04 +0000 Received: (qmail 66860 invoked from network); 12 Nov 2003 23:51:34 -0000 Received: from dyn071-231.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.71.231) by necom830.hpcl.titech.ac.jp with SMTP; 12 Nov 2003 23:51:34 -0000 Message-ID: <3FB2C625.8000000@necom830.hpcl.titech.ac.jp> Date: Thu, 13 Nov 2003 08:45:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Mailing List Subject: Re: security requirement for multi6 References: <3FB17E22.6070904@necom830.hpcl.titech.ac.jp> <3FB2C181.8090700@necom830.hpcl.titech.ac.jp> <968ACFD4-1568-11D8-A1D0-000A95CD987A@muada.com> In-Reply-To: <968ACFD4-1568-11D8-A1D0-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> That is, that you happen to find a way of DoS does not mean other >> forms of DoS is not possible. > > > Still, I think this new kind of denial of service is bad enough that we > shouldn't allow this to happen, even though other denial of service > attacks are also possible today. Read my previous mail, again. The damages on the target by two attack forms are identical. > Hopefully we'll be able to do something > about that in the future. DoS is so easy. Masataka Ohta From owner-multi6@ops.ietf.org Wed Nov 12 21:47: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 VAA23435 for ; Wed, 12 Nov 2003 21:47:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK7Uw-000MI7-1j for multi6-data@psg.com; Thu, 13 Nov 2003 02:46:18 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK7Us-000MHl-0l for multi6@ops.ietf.org; Thu, 13 Nov 2003 02:46:14 +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 hAD2k95u011842; Wed, 12 Nov 2003 19:46:10 -0700 (MST) Received: from lillen (vpn-129-150-16-219.SFBay.Sun.COM [129.150.16.219]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAD2k5Q08156; Thu, 13 Nov 2003 03:46:05 +0100 (MET) Date: Thu, 13 Nov 2003 03:45:04 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: noid and applications (generic requirements from applications) To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <5EE8F860-1565-11D8-9562-000A959CF516@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > In this picture A send thinsg to B, and use as src AID(A) and dst > AID(B). > > Questions: > > If B send a packet back to A, can AID(B) be used as src, and AID(A) as > dst? Yes. That is what most ULPs will do. > If B send a packet to C with src AID(B) and dst AID(C), can B send > AID(A) to C so C can use src AID(C) and dst AID(A)? Yes, the AIDs can be used for referrals since they are not really different than today's IP addresses; they are locators. The only thing to consider is when AID(A) isn't working as a locator when C tries to contact it. There are two choices: C can detect that the locator doesn't work and do a reverse+forward DNS lookup to get the whole locator set (Ls(A)). or The referal can include Ls(A) instead of just the AID(A); this requires modifying existing IPv6 appication protocols which do referal. Erik From owner-multi6@ops.ietf.org Wed Nov 12 22:11: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 WAA24373 for ; Wed, 12 Nov 2003 22:11:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK7t3-000PGi-Km for multi6-data@psg.com; Thu, 13 Nov 2003 03:11:13 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK7t0-000PGK-JW for multi6@ops.ietf.org; Thu, 13 Nov 2003 03:11:10 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hAD3Aped048815; Thu, 13 Nov 2003 04:10:52 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <053B2AB4-1587-11D8-A1D0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: noid and applications (generic requirements from applications) Date: Wed, 12 Nov 2003 21:11:05 -0600 To: Erik Nordmark X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12-nov-03, at 20:45, Erik Nordmark wrote: > The only thing to consider is when AID(A) isn't working as a locator > when > C tries to contact it. > There are two choices: > C can detect that the locator doesn't work and do a reverse+forward DNS > lookup to get the whole locator set (Ls(A)). > or > The referal can include Ls(A) instead of just the AID(A); this requires > modifying existing IPv6 appication protocols which do referal. I think it would be a good idea to look at a referral API. Such an API would allow a host to ask the system to create a neat little package containing all the pertinent locator and identifier information, then it can transmit this package to a correspondent and the correspondent can then unwrap it and use the content to do whatever it needed the referral for. The advantage of such a system is that it could allow applications that need referral to be completely independent of lower layer technologies, such as the multihoming solution we're going to implement, and the differences between IPv4 and IPv6. The downside would be that this referral package could get significantly larger than a simple address. From owner-multi6@ops.ietf.org Wed Nov 12 22:39: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 WAA25180 for ; Wed, 12 Nov 2003 22:39:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8Jf-0002J6-KU for multi6-data@psg.com; Thu, 13 Nov 2003 03:38:43 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AK8Ja-0002Hh-U4 for multi6@ops.ietf.org; Thu, 13 Nov 2003 03:38:39 +0000 Received: (qmail 67597 invoked from network); 13 Nov 2003 03:46:11 -0000 Received: from dyn129-43.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.129.43) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 03:46:11 -0000 Message-ID: <3FB2FD21.6040601@necom830.hpcl.titech.ac.jp> Date: Thu, 13 Nov 2003 12:40:17 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Tony Li CC: multi6@ops.ietf.org Subject: Re: Summary of work areas References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to add the following items analysis on interaction with mobility analysis on interaction with IGP analysis on interaction with BGP (or any routing protocol used beyond the edge of a site) expected average and maximum number of locators of a site expected maximum (for the lifetime of IPv6) number of global routing table entries Masataka Ohta From owner-multi6@ops.ietf.org Wed Nov 12 22:43: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 WAA25332 for ; Wed, 12 Nov 2003 22:43:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8OE-00033J-N8 for multi6-data@psg.com; Thu, 13 Nov 2003 03:43:26 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8OA-00032w-Pd for multi6@ops.ietf.org; Thu, 13 Nov 2003 03:43:22 +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 hAD3gs46003539; Thu, 13 Nov 2003 04:42:55 +0100 (CET) Date: Thu, 13 Nov 2003 04:42:47 +0100 Subject: Re: Summary of work areas Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <727F4D19-158B-11D8-882E-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony, > To help Elliot out, I'd like for us to start thinking > about our top level work items. As top level items, > they should, IMHO, be as independent as possible (tho > not wholly independent). They should not be nested and > they should not be about the details. > > Here's a strawman: > > > Threat analysis > Locator storage & distribution > Mappings between locators, identifiers, and FQDNs > Security solutions > Exit addressing > > Additions, modifications? Are you saying that these are issues that you would like to see in Elliots draft or are you saying that these are issues that we need to break out as sub-pieces in general? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7L9vKarNKXTPFCVEQKy6wCeKCzrYv3lgIKK2r2iK24+6yOzFBcAoLb8 cDTGNppeY2w5BaVzVOuykuiP =K1RO -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Nov 12 22:44: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 WAA25363 for ; Wed, 12 Nov 2003 22:44:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8PI-0003Ds-5O for multi6-data@psg.com; Thu, 13 Nov 2003 03:44:32 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8PD-0003Cv-Bl for multi6@ops.ietf.org; Thu, 13 Nov 2003 03:44:27 +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 hAD5n9Ot023433; Wed, 12 Nov 2003 21:49:09 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hAD3iDYB005404; Wed, 12 Nov 2003 19:44:13 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: noid and applications (generic requirements from applications) Date: Wed, 12 Nov 2003 19:44:13 -0800 Message-ID: Thread-Topic: noid and applications (generic requirements from applications) Thread-Index: AcOpkcVj+SvLzFWJSTqGaS6cgVMFPQABoX4Q From: "Tony Li" To: "Erik Nordmark" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | The referal can include Ls(A) instead of just the AID(A);=20 | this requires | modifying existing IPv6 appication protocols which do referal. Of course, if we're going to open an implementation, we might want to make the point of referral the FQDN, not the locator(s). Tony From owner-multi6@ops.ietf.org Wed Nov 12 22:46: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 WAA25434 for ; Wed, 12 Nov 2003 22:46:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8Qt-0003Vb-CY for multi6-data@psg.com; Thu, 13 Nov 2003 03:46:11 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8Qr-0003V9-D1 for multi6@ops.ietf.org; Thu, 13 Nov 2003 03:46:09 +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 hAD3jd46003542; Thu, 13 Nov 2003 04:45:42 +0100 (CET) Date: Thu, 13 Nov 2003 04:45:32 +0100 Subject: Re: Summary of work areas Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh, and I think the bootstrap/start-up face that Margaret and others brought up is something that should be on the list. - - kurtis - On onsdag, nov 12, 2003, at 21:02 Europe/Stockholm, Tony Li wrote: > > Hi, > > To help Elliot out, I'd like for us to start thinking > about our top level work items. As top level items, > they should, IMHO, be as independent as possible (tho > not wholly independent). They should not be nested and > they should not be about the details. > > Here's a strawman: > > > Threat analysis > Locator storage & distribution > Mappings between locators, identifiers, and FQDNs > Security solutions > Exit addressing > > Additions, modifications? > > Tony > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7L+YKarNKXTPFCVEQICiACdFjR3qVo8No4pMrzHdLqJhZ628TUAoLpV CMtZwn3Q2m8V3ibnTY+sIHdn =J+q6 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Nov 12 22:52: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 WAA25672 for ; Wed, 12 Nov 2003 22:52:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8VQ-0004JC-EA for multi6-data@psg.com; Thu, 13 Nov 2003 03:50:52 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8VN-0004Ig-RO for multi6@ops.ietf.org; Thu, 13 Nov 2003 03:50:49 +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 hAD5tYOt023493; Wed, 12 Nov 2003 21:55:34 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hAD3ocYB005653; Wed, 12 Nov 2003 19:50:38 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Summary of work areas Date: Wed, 12 Nov 2003 19:50:38 -0800 Message-ID: Thread-Topic: Summary of work areas Thread-Index: AcOpmE5U+4cYRV4OR1aU1mUeDefCcgAADo2w From: "Tony Li" To: "Kurt Erik Lindqvist" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | > Threat analysis | > Locator storage & distribution | > Mappings between locators, identifiers, and FQDNs | > Security solutions | > Exit addressing | > | > Additions, modifications? | =20 | Are you saying that these are issues that you would like to see in=20 | Elliots draft or are you saying that these are issues that=20 | we need to=20 | break out as sub-pieces in general? Kurtis, I'm proposing that we divide-and-conquer on these issues. We send folks off to document the solution space for each of these, document the pros and cons, and then try to achieve subgroup consensus for each of these major decisions. =20 I want to stress that this is a PROPOSAL. If you wanna do something else, I'm game. All that I'm proposing is that we avoid proposal bashing and instead take a normal engineering subsystem approach to making decisions. Hierarchy is a fine goal for tackling scalability in our decision making processes as well. I was under the impression that Elliot was going to document these areas. If I'm confused, please push my reset. Regards, Tony From owner-multi6@ops.ietf.org Wed Nov 12 23:06: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 XAA26213 for ; Wed, 12 Nov 2003 23:06:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8jl-0006vf-4C for multi6-data@psg.com; Thu, 13 Nov 2003 04:05:41 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8ji-0006vH-38 for multi6@ops.ietf.org; Thu, 13 Nov 2003 04:05:38 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 20:05:33 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Nov 2003 20:05:37 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 Nov 2003 20:05:36 -0800 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.1069); Wed, 12 Nov 2003 20:05:37 -0800 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); Wed, 12 Nov 2003 20:05:30 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.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: Summary of work areas Date: Wed, 12 Nov 2003 20:05:39 -0800 Message-ID: Thread-Topic: Summary of work areas Thread-Index: AcOpmTJHEZA9jhOfQnGwOokgShnvHgAALNIQ From: "Christian Huitema" To: "Kurt Erik Lindqvist" , "Tony Li" Cc: X-OriginalArrivalTime: 13 Nov 2003 04:05:30.0925 (UTC) FILETIME=[610505D0:01C3A99B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable My own list of task includes: - description of an incremental roadmap that makes "business sense" - solving the egress filtering issue (including when addresses cannot be rewritten) - selection of a first pair of address/locator to "establish contact", either from application to TCP (as in the DT2 proposal or in the NOID proposal) or from identifier to locator (in the SIM proposal) - learning the set of addresses/locators associated to the "distinguished address/locator" (common to DT2 proposal and NOID -- the DNS is only one of many possibilities) - decision algorithm for actually triggering the use of a different set of addresses/locators for an ongoing TCP connection (we should consider the trade-off between routing events, mobility events, and transport events such as retransmit on timer) - threat model & possible mitigations of the various attacks -- Christian Huitema > -----Original Message----- > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org] On > Behalf Of Kurt Erik Lindqvist > Sent: Wednesday, November 12, 2003 7:46 PM > To: Tony Li > Cc: multi6@ops.ietf.org > Subject: Re: Summary of work areas >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > Oh, and I think the bootstrap/start-up face that Margaret and others > brought up is something that should be on the list. >=20 > - - kurtis - >=20 > On onsdag, nov 12, 2003, at 21:02 Europe/Stockholm, Tony Li wrote: >=20 > > > > Hi, > > > > To help Elliot out, I'd like for us to start thinking > > about our top level work items. As top level items, > > they should, IMHO, be as independent as possible (tho > > not wholly independent). They should not be nested and > > they should not be about the details. > > > > Here's a strawman: > > > > > > Threat analysis > > Locator storage & distribution > > Mappings between locators, identifiers, and FQDNs > > Security solutions > > Exit addressing > > > > Additions, modifications? > > > > Tony > > >=20 > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.2 >=20 > iQA/AwUBP7L+YKarNKXTPFCVEQICiACdFjR3qVo8No4pMrzHdLqJhZ628TUAoLpV > CMtZwn3Q2m8V3ibnTY+sIHdn > =3DJ+q6 > -----END PGP SIGNATURE----- >=20 From owner-multi6@ops.ietf.org Wed Nov 12 23:08: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 XAA26291 for ; Wed, 12 Nov 2003 23:08:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8m8-00079c-Ja for multi6-data@psg.com; Thu, 13 Nov 2003 04:08:08 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8m5-00079I-3R for multi6@ops.ietf.org; Thu, 13 Nov 2003 04:08:05 +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 hAD47H46003550; Thu, 13 Nov 2003 05:07:22 +0100 (CET) Date: Thu, 13 Nov 2003 05:07:05 +0100 Subject: Re: security requirement for multi6 Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Masataka Ohta , Multi6 Mailing List To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <968ACFD4-1568-11D8-A1D0-000A95CD987A@muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On torsdag, nov 13, 2003, at 00:33 Europe/Stockholm, Iljitsch van Beijnum wrote: > >> That is, that you happen to find a way of DoS does not mean other >> forms of DoS is not possible. > > Still, I think this new kind of denial of service is bad enough that > we shouldn't allow this to happen, even though other denial of service > attacks are also possible today. Hopefully we'll be able to do > something about that in the future. Just because there are DoS possibilities that we do not yet know about, does not mean that we should not fix the ones that we do know about, and also know how to fix. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7MDc6arNKXTPFCVEQKP9gCgmrXlIDufgH0oTTmMApuH/MbYT0AAoOpD 2XdyIYeP8hJV6stm1NrEeubW =BfOR -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Nov 12 23:20: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 XAA26749 for ; Wed, 12 Nov 2003 23:20:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK8xg-0008Ew-Lc for multi6-data@psg.com; Thu, 13 Nov 2003 04:20:04 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AK8xb-0008EA-6Q for multi6@ops.ietf.org; Thu, 13 Nov 2003 04:19:59 +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 hAD6OBOt023779; Wed, 12 Nov 2003 22:24:11 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hAD4JFYB007622; Wed, 12 Nov 2003 20:19:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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 requirement for multi6 Date: Wed, 12 Nov 2003 20:19:15 -0800 Message-ID: Thread-Topic: security requirement for multi6 Thread-Index: AcOpnNvJYez/icLlQjqcXKMrA3e+HAAAFN/g From: "Tony Li" To: "Kurt Erik Lindqvist" , "Iljitsch van Beijnum" Cc: "Masataka Ohta" , "Multi6 Mailing List" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Even more importantly, we shouldn't create new ones. =20 Especially ones that are hard to detect. This is an operations group: let's not make operations any harder than they already are. Tony | -----Original Message----- | From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se]=20 | Sent: Wednesday, November 12, 2003 8:07 PM | To: Iljitsch van Beijnum | Cc: Masataka Ohta; Multi6 Mailing List | Subject: Re: security requirement for multi6 | =20 | =20 | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | =20 | =20 | On torsdag, nov 13, 2003, at 00:33 Europe/Stockholm, Iljitsch van=20 | Beijnum wrote: | =20 | > | >> That is, that you happen to find a way of DoS does not mean other | >> forms of DoS is not possible. | > | > Still, I think this new kind of denial of service is bad=20 | enough that=20 | > we shouldn't allow this to happen, even though other=20 | denial of service=20 | > attacks are also possible today. Hopefully we'll be able to do=20 | > something about that in the future. | =20 | Just because there are DoS possibilities that we do not yet=20 | know about,=20 | does not mean that we should not fix the ones that we do know about,=20 | and also know how to fix. | =20 | - - kurtis - | =20 | -----BEGIN PGP SIGNATURE----- | Version: PGP 8.0.2 | =20 | iQA/AwUBP7MDc6arNKXTPFCVEQKP9gCgmrXlIDufgH0oTTmMApuH/MbYT0AAoOpD | 2XdyIYeP8hJV6stm1NrEeubW | =3DBfOR | -----END PGP SIGNATURE----- | =20 | =20 | =20 From owner-multi6@ops.ietf.org Wed Nov 12 23:26: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 XAA26913 for ; Wed, 12 Nov 2003 23:26:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK93V-0008gr-PO for multi6-data@psg.com; Thu, 13 Nov 2003 04:26:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AK93S-0008gL-Gb for multi6@ops.ietf.org; Thu, 13 Nov 2003 04:26:02 +0000 Received: (qmail 67821 invoked from network); 13 Nov 2003 04:33:36 -0000 Received: from dyn129-43.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.129.43) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 04:33:36 -0000 Message-ID: <3FB3083D.8040006@necom830.hpcl.titech.ac.jp> Date: Thu, 13 Nov 2003 13:27:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: security requirement for multi6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On torsdag, nov 13, 2003, at 00:33 Europe/Stockholm, Iljitsch van > Beijnum wrote: > Kurt; >>Still, I think this new kind of denial of service is bad enough that >>we shouldn't allow this to happen, even though other denial of service >>attacks are also possible today. Hopefully we'll be able to do >>something about that in the future. > > > Just because there are DoS possibilities that we do not yet know about, > does not mean that we should not fix the ones that we do know about, > and also know how to fix. What is your point? The current situation is that there are DoS possibilities that we (I, at least) already know about. Masataka Ohta From owner-multi6@ops.ietf.org Wed Nov 12 23:47: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 XAA27382 for ; Wed, 12 Nov 2003 23:47:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AK9Nd-000Ath-L6 for multi6-data@psg.com; Thu, 13 Nov 2003 04:46:53 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AK9NZ-000At5-JB for multi6@ops.ietf.org; Thu, 13 Nov 2003 04:46:50 +0000 Received: (qmail 67892 invoked from network); 13 Nov 2003 04:54:23 -0000 Received: from dyn129-43.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.129.43) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 04:54:23 -0000 Message-ID: <3FB30D19.5060305@necom830.hpcl.titech.ac.jp> Date: Thu, 13 Nov 2003 13:48:25 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Tony Li CC: Kurt Erik Lindqvist , Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: security requirement for multi6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony; > Even more importantly, we shouldn't create new ones. What do you mean "ones"? It is not a problem to create new form of DoS in an existing situation such as that there is temporal MITM. Otherwise, we can't develop new protocols. For example, with MITM assumed, cryptographic security, which is computationaly expensive, protection agaist which was cookie, which is ineffective against MITM, amplifies DoS effect, especially with public key one. However, we should be careful if we are creating a new situation to enable DoS, we should be careful. But, it does not mean that we can't use cryptographic security. > This is an operations group: That is, we are talking about situations. An advanced fact on security is that DoS by MITM can not be prevented. Masataka Ohta From owner-multi6@ops.ietf.org Thu Nov 13 04:11: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 EAA17738 for ; Thu, 13 Nov 2003 04:11:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKDSm-0007aW-Hx for multi6-data@psg.com; Thu, 13 Nov 2003 09:08:28 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKDSi-0007aA-Oh for multi6@ops.ietf.org; Thu, 13 Nov 2003 09:08:24 +0000 Received: from descartes.info.ucl.ac.be (descartes [130.104.229.82]) by info.ucl.ac.be (8.12.10/8.12.8) with ESMTP id hAD98LZS005184; Thu, 13 Nov 2003 10:08:21 +0100 (MET) Subject: RE: Summary of work areas From: Cedric de Launois To: multi6@ops.ietf.org Cc: Kurt Erik Lindqvist , Tony Li , Christian Huitema In-Reply-To: References: Content-Type: text/plain Message-Id: <1068714617.31341.56.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 13 Nov 2003 10:10:17 +0100 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm currently working on a document that classify solutions to the numerous high-level problems related to multiadressed multihomed IPv6 end-sites. I mention actual propositions (HIP, NOID, SCTP...) only as examples that illustrate a particular way to solve a problem. I divided the problems into five categories : - Destination Locator Retrieval and Selection - Source Locator Selection - Failure Detection - Preservation of Security - Traffic Engineering The complete table of content is copy/paste'd below. The document is not finished yet. I hope it will help fixing the ideas. -- Cedric Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Destination Locator Retrieval and Selection . . . . . . . . 4 3.1 Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1 From the Domain Name System . . . . . . . . . . . . . . . . 4 3.1.2 From a Dedicated Service . . . . . . . . . . . . . . . . . . 4 3.1.3 Using Transport-Level Protocol . . . . . . . . . . . . . . . 4 3.2 Stack Levels for the Destination Locator Selection . . . . . 5 3.2.1 Application-Level . . . . . . . . . . . . . . . . . . . . . 5 3.2.2 Transport-Level . . . . . . . . . . . . . . . . . . . . . . 5 3.2.3 Between IP and Transport Levels . . . . . . . . . . . . . . 5 3.2.4 IP-Level . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Destination Locator Selection Mechanisms . . . . . . . . . . 6 3.3.1 Experimentation-Based Selection . . . . . . . . . . . . . . 6 3.3.2 Using Routing Protocols . . . . . . . . . . . . . . . . . . 6 4. Source Locator Selection . . . . . . . . . . . . . . . . . . 6 4.1 Stack Levels for the Source Locator Selection . . . . . . . 6 4.1.1 Application-Level . . . . . . . . . . . . . . . . . . . . . 7 4.1.2 Transport-Level . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3 Between IP and Transport Levels . . . . . . . . . . . . . . 7 4.1.4 IP-Level . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 Source Locator Selection Mechanisms . . . . . . . . . . . . 7 4.2.1 Using Routing Protocols . . . . . . . . . . . . . . . . . . 7 4.2.2 Automatic Selection by IP Infrastructure . . . . . . . . . . 8 4.2.3 Infrastructure-Driven Selection . . . . . . . . . . . . . . 8 5. Failure Detection . . . . . . . . . . . . . . . . . . . . . 8 5.1 End-to-End Keepalive . . . . . . . . . . . . . . . . . . . . 8 5.2 Passive Detection . . . . . . . . . . . . . . . . . . . . . 9 5.3 Using Routing Protocols . . . . . . . . . . . . . . . . . . 9 6. Preservation of Established Communication Sessions . . . . . 10 6.1 Application-Level . . . . . . . . . . . . . . . . . . . . . 10 6.2 Session-Level . . . . . . . . . . . . . . . . . . . . . . . 10 6.3 Transport-Level . . . . . . . . . . . . . . . . . . . . . . 10 6.4 Between IP and Transport Levels . . . . . . . . . . . . . . 10 6.5 IP Level . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Preservation of Security . . . . . . . . . . . . . . . . . . 11 8. Ingress Filtering Issue . . . . . . . . . . . . . . . . . . 11 8.1 Relaxing the Source Address Check . . . . . . . . . . . . . 11 8.2 Source Address Based Routing . . . . . . . . . . . . . . . . 12 8.3 Ensuring Right Source Address Selection by the Host . . . . 12 8.4 Packet Rewriting at Exit Router . . . . . . . . . . . . . . 13 9. Traffic Engineering . . . . . . . . . . . . . . . . . . . . 13 9.1 Outbound Traffic Engineering . . . . . . . . . . . . . . . . 13 9.1.1 Infrastructure-Driven Traffic Engineering . . . . . . . . . 14 9.1.2 Host-Driven Traffic Engineering . . . . . . . . . . . . . . 15 9.2 Inbound Traffic Engineering . . . . . . . . . . . . . . . . 15 Le jeu 13/11/2003 a 05:05, Christian Huitema a ecrit : > My own list of task includes: > > - description of an incremental roadmap that makes "business sense" > - solving the egress filtering issue (including when addresses cannot be > rewritten) > - selection of a first pair of address/locator to "establish contact", > either from application to TCP (as in the DT2 proposal or in the NOID > proposal) or from identifier to locator (in the SIM proposal) > - learning the set of addresses/locators associated to the > "distinguished address/locator" (common to DT2 proposal and NOID -- the > DNS is only one of many possibilities) > - decision algorithm for actually triggering the use of a different set > of addresses/locators for an ongoing TCP connection (we should consider > the trade-off between routing events, mobility events, and transport > events such as retransmit on timer) > - threat model & possible mitigations of the various attacks > > -- Christian Huitema > > > > -----Original Message----- > > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org] On > > Behalf Of Kurt Erik Lindqvist > > Sent: Wednesday, November 12, 2003 7:46 PM > > To: Tony Li > > Cc: multi6@ops.ietf.org > > Subject: Re: Summary of work areas > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > Oh, and I think the bootstrap/start-up face that Margaret and others > > brought up is something that should be on the list. > > > > - - kurtis - > > > > On onsdag, nov 12, 2003, at 21:02 Europe/Stockholm, Tony Li wrote: > > > > > > > > Hi, > > > > > > To help Elliot out, I'd like for us to start thinking > > > about our top level work items. As top level items, > > > they should, IMHO, be as independent as possible (tho > > > not wholly independent). They should not be nested and > > > they should not be about the details. > > > > > > Here's a strawman: > > > > > > > > > Threat analysis > > > Locator storage & distribution > > > Mappings between locators, identifiers, and FQDNs > > > Security solutions > > > Exit addressing > > > > > > Additions, modifications? > > > > > > Tony > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGP 8.0.2 > > > > iQA/AwUBP7L+YKarNKXTPFCVEQICiACdFjR3qVo8No4pMrzHdLqJhZ628TUAoLpV > > CMtZwn3Q2m8V3ibnTY+sIHdn > > =J+q6 > > -----END PGP SIGNATURE----- > > From owner-multi6@ops.ietf.org Thu Nov 13 08:44: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 IAA26192 for ; Thu, 13 Nov 2003 08:44:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKHgz-0006aD-Hx for multi6-data@psg.com; Thu, 13 Nov 2003 13:39:25 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKHgw-0006Zp-Lw for multi6@ops.ietf.org; Thu, 13 Nov 2003 13:39:22 +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 hADDcf46003639; Thu, 13 Nov 2003 14:38:42 +0100 (CET) Date: Thu, 13 Nov 2003 14:36:55 +0100 Subject: Re: noid and applications (generic requirements from applications) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Erik Nordmark , Multi6 Mailing List To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <053B2AB4-1587-11D8-A1D0-000A95CD987A@muada.com> Message-Id: <727E5CBD-15DE-11D8-882E-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On torsdag, nov 13, 2003, at 04:11 Europe/Stockholm, Iljitsch van Beijnum wrote: > On 12-nov-03, at 20:45, Erik Nordmark wrote: > >> The only thing to consider is when AID(A) isn't working as a locator >> when >> C tries to contact it. > >> There are two choices: >> C can detect that the locator doesn't work and do a reverse+forward >> DNS >> lookup to get the whole locator set (Ls(A)). >> or >> The referal can include Ls(A) instead of just the AID(A); this >> requires >> modifying existing IPv6 appication protocols which do referal. > > I think it would be a good idea to look at a referral API. Such an API > would allow a host to ask the system to create a neat little package > containing all the pertinent locator and identifier information, then > it can transmit this package to a correspondent and the correspondent > can then unwrap it and use the content to do whatever it needed the > referral for. The advantage of such a system is that it could allow > applications that need referral to be completely independent of lower > layer technologies, such as the multihoming solution we're going to > implement, and the differences between IPv4 and IPv6. The downside > would be that this referral package could get significantly larger > than a simple address. Although I am tempted to say that a multi6 API with ULP hints, referral package, etc is a good idea - I am not sure I think that is where we should be right now. This will mean that applications will have to be rewritten in order to make full use of the mulihoming solution. Maybe this is another topic for Elliot's draft? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7OI/qarNKXTPFCVEQJ8cQCeKBfMUtYSEFwanFY2sZj9RxpaGE0AoNtY 0VKIyNdVBv35PxbckPlLBvUX =ChFb -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 13 09:19: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 JAA27822 for ; Thu, 13 Nov 2003 09:19:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIIW-000B6U-38 for multi6-data@psg.com; Thu, 13 Nov 2003 14:18:12 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIIR-000B5s-FW for multi6@ops.ietf.org; Thu, 13 Nov 2003 14:18:07 +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 hADEHe46003680; Thu, 13 Nov 2003 15:17:41 +0100 (CET) Date: Thu, 13 Nov 2003 15:17:35 +0100 Subject: Re: Summary of work areas Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <20DCF78B-15E4-11D8-8943-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony, > I'm proposing that we divide-and-conquer on these issues. We send > folks off to document the solution space for each of these, document > the pros and cons, and then try to achieve subgroup consensus for > each of these major decisions. > > I want to stress that this is a PROPOSAL. If you wanna do something > else, I'm game. All that I'm proposing is that we avoid proposal > bashing and instead take a normal engineering subsystem approach > to making decisions. Hierarchy is a fine goal for tackling scalability > in our decision making processes as well. > > I was under the impression that Elliot was going to document these > areas. If I'm confused, please push my reset. What I think I'd like to see is Elliot's draft written up with the operational issues that are not in RFC3582, and I'd like to see Erik's threat analysis completed (or merged with other proposals - as long as we get to a single proposal). At some point we also need to document the trade-offs that each of the issues in Elliot's draft imply. I am not sure that we should do that in Elliot's draft though, as we then are already assuming properties of the solution. But maybe we are that far ahead, I am certainly open for discussion. As for dividing the problem into subsystems, I think that is a good model. That is also what I think Randy said in the session yesterday. However, my understanding from the session yesterday was that Elliot's draft together with 3582 would serve as this list of subsystems. So I guess you are right in your last paragraph. And I am sure that Elliot will appreciate comments and text to help him, as I am sure that Erik will on the threats draft. Me and Randy yesterday also dragged Patrik and a few other applications people in here so that we can make sure to meet their needs. Keith Moor yesterday said he didn't feel that any of the current proposals meets the needs of applications. If that is the case we need to get that documented and better understood. That is not a target of Elliot's draft as I understood it. My take is that if the "applications requirement list" is too long and to diverse from where we are heading, we might need to document that as well. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7OSg6arNKXTPFCVEQJtoACg1UE3XlkUDG+jjxYJgInxL5l0lSgAoKVL aOBzv92c+ahYrP0FzE9u1FWL =uZ+e -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 13 09:20: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 JAA27861 for ; Thu, 13 Nov 2003 09:20:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIKd-000BKY-Od for multi6-data@psg.com; Thu, 13 Nov 2003 14:20:23 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIKX-000BJR-HM for multi6@ops.ietf.org; Thu, 13 Nov 2003 14:20:17 +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 hADEIe46003683; Thu, 13 Nov 2003 15:18:40 +0100 (CET) Date: Thu, 13 Nov 2003 15:18:37 +0100 Subject: Re: noid and applications (generic requirements from applications) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Erik Nordmark" , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <46085A95-15E4-11D8-8943-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On torsdag, nov 13, 2003, at 04:44 Europe/Stockholm, Tony Li wrote: > | The referal can include Ls(A) instead of just the AID(A); > | this requires > | modifying existing IPv6 appication protocols which do referal. > > > Of course, if we're going to open an implementation, we might want > to make the point of referral the FQDN, not the locator(s). > That is probably an important point as the Ls(A) could have changed, right? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7OSv6arNKXTPFCVEQIfMwCgr37sDjnNRD9GXWdL8xuOtAZ0gtwAoLBd Pkvkxz+Hc5+4/aa3ztwDRYzS =jG8i -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 13 09:21: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 JAA27918 for ; Thu, 13 Nov 2003 09:21:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKILi-000BSd-Hf for multi6-data@psg.com; Thu, 13 Nov 2003 14:21:30 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKILf-000BSF-QZ for multi6@ops.ietf.org; Thu, 13 Nov 2003 14:21:27 +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 hADEKp46003686; Thu, 13 Nov 2003 15:20:52 +0100 (CET) Date: Thu, 13 Nov 2003 15:20:48 +0100 Subject: Re: security requirement for multi6 Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , Multi6 Mailing List To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <3FB3083D.8040006@necom830.hpcl.titech.ac.jp> Message-Id: <94107A82-15E4-11D8-8943-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On torsdag, nov 13, 2003, at 05:27 Europe/Stockholm, Masataka Ohta wrote: > Kurt Erik Lindqvist wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> On torsdag, nov 13, 2003, at 00:33 Europe/Stockholm, Iljitsch van >> Beijnum wrote: > Kurt; > >>> Still, I think this new kind of denial of service is bad enough that >>> we shouldn't allow this to happen, even though other denial of >>> service attacks are also possible today. Hopefully we'll be able to >>> do something about that in the future. >> Just because there are DoS possibilities that we do not yet know >> about, does not mean that we should not fix the ones that we do know >> about, and also know how to fix. > > What is your point? > > The current situation is that there are DoS possibilities that we > (I, at least) already know about. In the id/loc separation case? That are not in Eriks draft? Then this is the time to list them. If you know how to work around them, even better. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7OTQqarNKXTPFCVEQLgUgCffbd72B3JHBDc9XysM+N7nNTH1IMAoOqD eB0AP4PXK1C2O1m117Zx3CgS =g3dD -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 13 09:27: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 JAA28072 for ; Thu, 13 Nov 2003 09:27:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIR6-000C4w-OF for multi6-data@psg.com; Thu, 13 Nov 2003 14:27:04 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIR3-000C4N-33 for multi6@ops.ietf.org; Thu, 13 Nov 2003 14:27:01 +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 hADEQs5u008543; Thu, 13 Nov 2003 07:26:55 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADEQoQ08664; Thu, 13 Nov 2003 15:26:51 +0100 (MET) Date: Thu, 13 Nov 2003 15:25:50 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on nordmark-multi-threats To: Pekka Savola Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka, Thanks for your comments. > One thing the doc could maybe be slightly clearer on is which "security > problems" the different attacks rely on (e.g., off-link TCP ACK spoofing, > TCP seq number synchronization (could be very challenging if tryly random > seq/ack numbers are used, etc.) We can try to add this. > A couple of observations and minor nits below, nothing major. > > Similarly, if DNS can be compromised, and a change can be made to an > advertised resource record to advertise a different IP address for a > hostname, effectively taking over that hostname. > > ==> does this imply DNS threats, in addition to just hacking thezone? I don't know what "hacking the zone" means. A DNS lookup, without DNSsec, can be spoofed if the attacker can spoof the source address, match a (16 bit, probably predictable) number in the query, and guess the domain name that was in the query. > Any system that is along the path from the source to the destination > host can be compromised and used to redirect traffic. Systems may be > added to the best path to accomplish this. Further, even systems > that are on multi-access links that do not provide security can also > be used to redirect traffic off of the normal path. For example, ARP > and ND spoofing can be used to attract all traffic for the legitimate > next hop across an Ethernet. > > ==> these apply to DNS the paths and links to the DNS server as well, of > course. Yes, until DNSsec gets deployed. > > An attribute of this type of attack is that A will simply think that > B is faulty since its flow and congestion control mechanisms don't > seem to be working. Detecting that the stream of ACK packets is > generated from X and not from A might be challenging, since the rate > of ACK packets might be relatively low. This type of attack might > not be common today because it requires that X remain on the path in > order to sustain the DoS attack, but the addition of multihoming > redirection mechanisms might potentially remove that constraint. > > ==> it is not readily apparent why X would need to remain on the path to > continue this, but I didn't think this through. Maybe need spelling out? Should spell that out. Its ability to move off the path is constrained by whatever amount of ingress filtering is used. > fully editorial > --------------- Thanks - taken care of. > multihoming solution would fail our "no worse than what we have now" > litmus test. However, given that ingress filtering deployment is far > > ==> "litmus test" ? Originally paper used to test the pH of a solution. Used a lot more generally; google it for examples of broad usage. Erik From owner-multi6@ops.ietf.org Thu Nov 13 09:52:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29304 for ; Thu, 13 Nov 2003 09:52:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIoE-000Ez6-Lg for multi6-data@psg.com; Thu, 13 Nov 2003 14:50:58 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIoA-000EyP-DH for multi6@ops.ietf.org; Thu, 13 Nov 2003 14:50:54 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hADEolPh029149; Thu, 13 Nov 2003 07:50:47 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADEoiQ15427; Thu, 13 Nov 2003 15:50:44 +0100 (MET) Date: Thu, 13 Nov 2003 15:49:47 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: noid and applications (generic requirements from applications) To: Tony Li Cc: Erik Nordmark , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Of course, if we're going to open an implementation, we might want > to make the point of referral the FQDN, not the locator(s). Yes. Especially with noid, where the multihomed node needs to have a FQDN, this makes a lot of sense. Erik From owner-multi6@ops.ietf.org Thu Nov 13 09:57: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 JAA29599 for ; Thu, 13 Nov 2003 09:57:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIty-000Fwi-AZ for multi6-data@psg.com; Thu, 13 Nov 2003 14:56:54 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKItp-000FvZ-Pt for multi6@ops.ietf.org; Thu, 13 Nov 2003 14:56:45 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hADEuhxA019173; Thu, 13 Nov 2003 06:56:44 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADEufQ15982; Thu, 13 Nov 2003 15:56:41 +0100 (MET) Date: Thu, 13 Nov 2003 15:55:43 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Summary of work areas To: Tony Li Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Threat analysis > Locator storage & distribution > Mappings between locators, identifiers, and FQDNs > Security solutions > Exit addressing > > Additions, modifications? As marcelo suggested, adding an item to the list for locator selection (based on routing feedback, ULP feedback, etc) would make sense to me. I think this is largely independent of the other work areas, even though the mechanisms to get feedback from the routing system might be different depending on other aspects of the total space. Erik From owner-multi6@ops.ietf.org Thu Nov 13 09:59: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 JAA29668 for ; Thu, 13 Nov 2003 09:59:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKIvp-000GDS-Ku for multi6-data@psg.com; Thu, 13 Nov 2003 14:58:49 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKIvn-000GD6-Tf for multi6@ops.ietf.org; Thu, 13 Nov 2003 14:58:47 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hADEwiPh002611; Thu, 13 Nov 2003 07:58:45 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADEwfQ16387; Thu, 13 Nov 2003 15:58:41 +0100 (MET) Date: Thu, 13 Nov 2003 15:57:41 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Some Comments on ID/Loc Separation Proposals To: Margaret.Wasserman@nokia.com Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > The use of the term "Identifier" or "ID" sweeps an important > issue under the rug in some cases: Is this a host ID or an > interface ID? The current IP (v4 and v6) architecture uses > interface IDs. IPv4 implementations are generally constrained > to one ID per interface, while IPv6 supports multiple IDs per > interface. ID selection is linked to outbound interface > selection -- it is still unclear to me what implications this > has for ID or Locator selection in ID/Loc separation protocols. An interface ID makes no sense to me. The concept of a stack name, where there can be one or more "stacks" on a given host, provides the right granularity to me. Each "stack" can presumbly have one or more network interfaces. Erik From owner-multi6@ops.ietf.org Thu Nov 13 10:19: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 KAA02269 for ; Thu, 13 Nov 2003 10:19:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJF7-000JJG-KN for multi6-data@psg.com; Thu, 13 Nov 2003 15:18:45 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKJF2-000JIe-LO for multi6@ops.ietf.org; Thu, 13 Nov 2003 15:18:40 +0000 Received: (qmail 69625 invoked from network); 13 Nov 2003 15:26:22 -0000 Received: from dyn051-172.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.51.172) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 15:26:22 -0000 Message-ID: <3FB3A126.20708@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 00:20:06 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: security requirement for multi6 References: <94107A82-15E4-11D8-8943-000A9598A184@kurtis.pp.se> In-Reply-To: <94107A82-15E4-11D8-8943-000A9598A184@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; >>>>Still, I think this new kind of denial of service is bad enough that >>>>we shouldn't allow this to happen, even though other denial of >>>>service attacks are also possible today. Hopefully we'll be able to >>>>do something about that in the future. >>> >>>Just because there are DoS possibilities that we do not yet know >>>about, does not mean that we should not fix the ones that we do know >>>about, and also know how to fix. >> >>What is your point? >> >>The current situation is that there are DoS possibilities that we >>(I, at least) already know about. > > > In the id/loc separation case? No. > That are not in Eriks draft? No. > Then Then? Masataka Ohta From owner-multi6@ops.ietf.org Thu Nov 13 10:20: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 KAA02320 for ; Thu, 13 Nov 2003 10:20:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJFg-000JMh-0S for multi6-data@psg.com; Thu, 13 Nov 2003 15:19:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJFK-000JKE-28 for multi6@ops.ietf.org; Thu, 13 Nov 2003 15:18:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADFIsY05744; Thu, 13 Nov 2003 17:18:55 +0200 Date: Thu, 13 Nov 2003 17:18:54 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: multi6@ops.ietf.org Subject: Re: comments on nordmark-multi-threats In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, Thanks for the response. Just one comment below. On Thu, 13 Nov 2003, Erik Nordmark wrote: > > A couple of observations and minor nits below, nothing major. > > > > Similarly, if DNS can be compromised, and a change can be made to an > > advertised resource record to advertise a different IP address for a > > hostname, effectively taking over that hostname. > > > > ==> does this imply DNS threats, in addition to just hacking thezone? > > I don't know what "hacking the zone" means. > A DNS lookup, without DNSsec, can be spoofed if the > attacker can spoof the source address, match a (16 bit, probably predictable) > number in the query, and guess the domain name that was in the query. "If DNS is compromised" was not unambiguous whether you referred to all the threats to the DNS system, rather than just somehow modifying what's advertised in the DNS to begin with (e.g., by compromising the DDNS updates). The question seems obvious, but it may be useful to list a few examples of DNS threats to spell this out. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Nov 13 10:23: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 KAA02538 for ; Thu, 13 Nov 2003 10:23:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJJ1-000Jrc-2w for multi6-data@psg.com; Thu, 13 Nov 2003 15:22:47 +0000 Received: from [206.197.161.140] (helo=uillean.fuaim.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJIw-000Jr5-EM for multi6@ops.ietf.org; Thu, 13 Nov 2003 15:22:42 +0000 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id hADFMfV09266; Thu, 13 Nov 2003 07:22:41 -0800 Received: from innovationslab.net (dyn134-131.ietf58.ietf.org [130.129.134.131]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hADFQatX019453 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 13 Nov 2003 07:26:41 -0800 Message-ID: <3FB3A174.4000800@innovationslab.net> Date: Thu, 13 Nov 2003 10:21:24 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Margaret.Wasserman@nokia.com, multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>The use of the term "Identifier" or "ID" sweeps an important >>issue under the rug in some cases: Is this a host ID or an >>interface ID? The current IP (v4 and v6) architecture uses >>interface IDs. IPv4 implementations are generally constrained >>to one ID per interface, while IPv6 supports multiple IDs per >>interface. ID selection is linked to outbound interface >>selection -- it is still unclear to me what implications this >>has for ID or Locator selection in ID/Loc separation protocols. > > > An interface ID makes no sense to me. > > The concept of a stack name, where there can be one or more "stacks" > on a given host, provides the right granularity to me. > Each "stack" can presumbly have one or more network interfaces. I agree with Erik that an "interface ID" doesn't make sense. The question I have is a stack ID high enough? I have been mulling over the issue of how a security association should work here. Is the SA between stacks? between apps? between users? There may be cases where each of the above approach is useful. Regards, Brian From owner-multi6@ops.ietf.org Thu Nov 13 10:24: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 KAA02577 for ; Thu, 13 Nov 2003 10:24:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJIt-000Jqu-Ux for multi6-data@psg.com; Thu, 13 Nov 2003 15:22:39 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJIp-000Jq6-SR for multi6@ops.ietf.org; Thu, 13 Nov 2003 15:22:35 +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 hADFMXUP015554 for ; Thu, 13 Nov 2003 07:22:34 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADFMVQ19098 for ; Thu, 13 Nov 2003 16:22:32 +0100 (MET) Date: Thu, 13 Nov 2003 16:21:34 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Mobility observation To: multi6@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Here is a food for throught how mobility can fit in with multihoming. Assume that a multihoming solution allows the host to send its list of locators to the peer. In that case it is possible to provide hints about different characteristics of the locators. Some might be long-term stable (what is a home address in MIPv6) but might not be optimal for performance (due to the home agent tunneling packets to the current location of the mobile node). Others (care of addresses) might perform better but stop working when the mobile node works. Being able to provide such distinctions to the peer allows the peer's destination locator selection to use different strategies e.g. when packets to a locator no longer appear to make it to the mobile host. Which such an approach one could continue to use the MIPv6 MN-HA protocol for updating the home agent (this is independent of the MN-CN aspects), and use the multihoming mechanism to update correspondents with the set of locators. A side effect of this is that a mobile node can provide multiple care-of-locators to the correspondents to allow failover. Erik From owner-multi6@ops.ietf.org Thu Nov 13 10:29: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 KAA02854 for ; Thu, 13 Nov 2003 10:29:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJOd-000Kw0-76 for multi6-data@psg.com; Thu, 13 Nov 2003 15:28:35 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJOT-000Kun-Kf for multi6@ops.ietf.org; Thu, 13 Nov 2003 15:28:25 +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 hADFRn46003787; Thu, 13 Nov 2003 16:27:50 +0100 (CET) Date: Thu, 13 Nov 2003 16:27:41 +0100 Subject: Re: security requirement for multi6 Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , Multi6 Mailing List To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <3FB3A126.20708@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> Still, I think this new kind of denial of service is bad enough >>>>> that we shouldn't allow this to happen, even though other denial >>>>> of service attacks are also possible today. Hopefully we'll be >>>>> able to do something about that in the future. >>>> >>>> Just because there are DoS possibilities that we do not yet know >>>> about, does not mean that we should not fix the ones that we do >>>> know about, and also know how to fix. >>> >>> What is your point? >>> >>> The current situation is that there are DoS possibilities that we >>> (I, at least) already know about. >> In the id/loc separation case? > > No. > >> That are not in Eriks draft? > > No. > >> Then > > Then? Then please post to the list. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA+AwUBP7Oi8qarNKXTPFCVEQIQKQCgxWvB0b1kQrrsqzJrx7RTNJ5PGXEAmK86 uZw4Gjj7lwDReFrygF84sxM= =lKvs -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 13 10:59: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 KAA04596 for ; Thu, 13 Nov 2003 10:59:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJrb-0000D4-VM for multi6-data@psg.com; Thu, 13 Nov 2003 15:58:31 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJrZ-0000Cl-3y for multi6@ops.ietf.org; Thu, 13 Nov 2003 15:58:29 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hADFwOPh003437; Thu, 13 Nov 2003 08:58:25 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADFwLQ27553; Thu, 13 Nov 2003 16:58:22 +0100 (MET) Date: Thu, 13 Nov 2003 16:57:25 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on nordmark-multi-threats To: Pekka Savola Cc: Erik Nordmark , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > "If DNS is compromised" was not unambiguous whether you referred to all > the threats to the DNS system, rather than just somehow modifying what's > advertised in the DNS to begin with (e.g., by compromising the DDNS > updates). The question seems obvious, but it may be useful to list a few > examples of DNS threats to spell this out. I'll add a reference to draft-ietf-dnsext-dns-threats-04.txt which contains the threats. Erik From owner-multi6@ops.ietf.org Thu Nov 13 11:03: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 LAA04849 for ; Thu, 13 Nov 2003 11:03:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJvy-00014m-10 for multi6-data@psg.com; Thu, 13 Nov 2003 16:03:02 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJvu-00014O-Rk for multi6@ops.ietf.org; Thu, 13 Nov 2003 16:02:59 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id D5FFE1C; Thu, 13 Nov 2003 18:16:04 +0200 (EET) Message-ID: <3FB3AB31.4090603@nomadiclab.com> Date: Thu, 13 Nov 2003 10:02:57 -0600 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret.Wasserman@nokia.com Cc: multi6@ops.ietf.org, HIPsec Subject: HIP referrals (was Re: Some Comments on ID/Loc Separation Proposals) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret.Wasserman@nokia.com wrote: > I have been analyzing a few of the proposal for ID/Loc separation > (HIP, NOID and MAST) and I have some comments (attached). ... > > HIP Feedback > > Very well-developed proposal for end-to-end ID/Loc separation. > No ID->Locator mapping mechanism, so no support for referrals. > > Specific Feedback: > > - The lack of any ID->Locator mapping mechanism is a > blocking problem for using HIP (as currently defined) > with anything but simple end-to-end applications. The earlier versions of the HIP draft contained a mechanism where a HIT would not be a 128 bit hash of the public key but consist of a 64-bit, hierarchically assigned prefix and a 64-bit hash. However, I removed this from the later versions of drafts for the following reasons: - the proposed mechanism was tied to DNS, and we decided to move all DNS specific issues into a separate draft - we wanted to keep HIP as simple as possible, and having different types of HITs seemed unnecessary, especially when the mechanism was optioinal - ID->Locator mapping is not needed for simple end-to-end applications, and the majority of current applications do not need referrals According to the current thinking, there are at least three different options on how to support referrals in HIP: 1. Re-introduce some structure to the HITs, and use a hierarchical lookup service (e.g. reverse DNS). 2. Introduce a flat lookup service, e.g., based on DHTs. This looks like a researchy issue, which is likely to need more research before ready for engineering. 3. Introduce a "social contract" to HIP where each HIP host acts as a temporary rendezvous point for all hosts that it has connections with. While 3) is not a generic ID->locator mapping solution, it looks like quite interesting anyway. In particular, it seems to be able to solve the common referral case where A has connections with both B and C, and what to give B's ID to C so that B and C can start to communicate directly. Here is a more specific example on how this might work: 1. A opens a HIP association AB with B. 2. A opens a HIP association AC with C. At this point A knows the locator sets for both B and C, but B and C know only the locator set of A. 3. A sends B's ID to C. 4. C tries to open a connection to B. At this point C has B's id, but it does not have B's locator set. However, it has a HIP association with A, and therefore it may try to use A as a rendezvous server for B. [There are a number of open problems in the description above, I know. But for the moment I'd like to focus only on the idea, hoping that the nasty details can be solved later.] 4. C constructs an I1 packet and sents it to A, hoping that A knows where B is and will forward the packet to B. 5. A receives the I1, and according to the "social contract" it passes the packet to B, whose locators it knows. 6. B receives the I1, and replies directly back to C, thereby initiating the actual negotiation. I don't think that it would be useful to define such an referral mechanism quite yet, but it would certainly be interesting to explore its limitations and implications (given the assumption that it can be made to work in the first place). --Pekka Nikander From owner-multi6@ops.ietf.org Thu Nov 13 11:04: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 LAA04920 for ; Thu, 13 Nov 2003 11:04:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKJx2-0001Iy-Jq for multi6-data@psg.com; Thu, 13 Nov 2003 16:04:08 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKJx0-0001Id-Ol for multi6@ops.ietf.org; Thu, 13 Nov 2003 16:04:06 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hADG45A24998 for ; Thu, 13 Nov 2003 18:04:05 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 18:04:03 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 08:04:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Some Comments on ID/Loc Separation Proposals Date: Thu, 13 Nov 2003 11:04:01 -0500 Message-ID: Thread-Topic: Some Comments on ID/Loc Separation Proposals Thread-Index: AcOp9qYuiY4A0IAvQu2medK8GiYAJAAB+FsA From: To: Cc: X-OriginalArrivalTime: 13 Nov 2003 16:04:02.0493 (UTC) FILETIME=[C1843ED0:01C3A9FF] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > An interface ID makes no sense to me. >=20 > The concept of a stack name, where there can be one or more "stacks" > on a given host, provides the right granularity to me. > Each "stack" can presumbly have one or more network interfaces. I'm not suggesting that the AID in NOID should become an interface ID. Current discussion focuses on the use of an IP address as a node identifier and as a locator. And, I agree that it serves these=20 two purposes. =20 An IP address can be used, for example, to allow ULPs to indicate=20 which physical interface to use for outbound packets by explictly=20 choosing a source address. This can be useful for multicast traffic=20 and specialized ULPs such as routing protocols.=20 The interface ID aspect of IP addresses can also be used to communicate between ULPs and LLPs (lower layer protocols). The ULPs may make a specific source address selection to specify a virtual interface that will be used to send outbound packets. This can allow some traffic to be sent through tunnels, or for per-application selection between multiple paths that may have different properties (cost, latency, bandwidth, etc.). The use of IP addresses as interface identifiers may or may not have any implications for NOID, as it seems that NOID will allow ULP access to the real local IP addresses (??) -- the document doesn't specifically say this, but I'm assuming that is how SCTP would run over NOID, for example. This is a larger potential issue=20 for other proposals, such as HIP. Margaret =20 From owner-multi6@ops.ietf.org Thu Nov 13 11:08: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 LAA05175 for ; Thu, 13 Nov 2003 11:08:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKK1P-0001yM-9E for multi6-data@psg.com; Thu, 13 Nov 2003 16:08:39 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKK1L-0001xu-IY for multi6@ops.ietf.org; Thu, 13 Nov 2003 16:08:35 +0000 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2003 08:08:37 -0800 Received: from xbe-rtp-212.cisco.com (xbe-rtp-212.cisco.com [64.102.23.41]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hADG8Vxg029565; Thu, 13 Nov 2003 11:08:31 -0500 (EST) Received: from xfe-rtp-212.cisco.com ([64.102.23.37]) by xbe-rtp-212.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Nov 2003 11:08:31 -0500 Received: from [127.0.0.1] ([64.102.23.30]) by xfe-rtp-212.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Nov 2003 11:08:30 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9E425FFC-15F3-11D8-9562-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: Tony Li , multi6@ops.ietf.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: noid and applications (generic requirements from applications) Date: Thu, 13 Nov 2003 10:08:28 -0600 To: Erik Nordmark X-Mailer: Apple Mail (2.606) X-OriginalArrivalTime: 13 Nov 2003 16:08:31.0094 (UTC) FILETIME=[619D8160:01C3AA00] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 2003-11-13, at 08.49, Erik Nordmark wrote: >> Of course, if we're going to open an implementation, we might want >> to make the point of referral the FQDN, not the locator(s). > > Yes. Especially with noid, where the multihomed node needs to have a > FQDN, > this makes a lot of sense. This is ok for an application which of course should use the FQDN, but, even when using whatever "thing" the application uses to establish the connection (which it gets via the FQDN) that should be usable without knowledge of the network topology. I guess one can formulate it as it must have features like: (A=B) and (B=C) gives (A=C) where '=' is "can communicate with" and (A->B) gives (B->A) where '->' is "can send data to" paf From owner-multi6@ops.ietf.org Thu Nov 13 11:12: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 LAA05281 for ; Thu, 13 Nov 2003 11:12:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKK4w-0002a0-B3 for multi6-data@psg.com; Thu, 13 Nov 2003 16:12:18 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKK4u-0002Zb-2Y for multi6@ops.ietf.org; Thu, 13 Nov 2003 16:12:16 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Nov 2003 08:12:15 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Nov 2003 08:12:15 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Nov 2003 08:12:17 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 Nov 2003 08:12:14 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 13 Nov 2003 08:12:02 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.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: Mobility observation Date: Thu, 13 Nov 2003 08:12:18 -0800 Message-ID: Thread-Topic: Mobility observation Thread-Index: AcOp+2KJig/jcfwXRrK/nXYAnpeqBAABNZHg From: "Christian Huitema" To: "Erik Nordmark" , X-OriginalArrivalTime: 13 Nov 2003 16:12:02.0316 (UTC) FILETIME=[DF836CC0:01C3AA00] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Which such an approach one could continue to use the MIPv6 MN-HA > protocol for updating the home agent (this is independent of > the MN-CN aspects), and use the multihoming mechanism > to update correspondents with the set of locators. > A side effect of this is that a mobile node can provide multiple > care-of-locators to the correspondents to allow failover. If I understand correctly, we would use a modification of the MN-CN node to carry a list of available "alternative addresses/locator". If a HA is available, it would simply be included in the set, with properties such as "low speed, high availability". That seems attractive. -- Christian Huitema From owner-multi6@ops.ietf.org Thu Nov 13 11:26:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05828 for ; Thu, 13 Nov 2003 11:26:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKKIR-0004jS-KF for multi6-data@psg.com; Thu, 13 Nov 2003 16:26:15 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKKIN-0004j1-Kt for multi6@ops.ietf.org; Thu, 13 Nov 2003 16:26:11 +0000 Received: from cisco.com (sjc-vpn3-741.cisco.com [10.21.66.229]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hADGQ3iN005523; Thu, 13 Nov 2003 08:26:03 -0800 (PST) Message-ID: <3FB3B09A.8050905@cisco.com> Date: Thu, 13 Nov 2003 08:26:02 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: Summary of work areas and criteria References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm working on an outline that I'll bounce off the AD and then send to the list. From owner-multi6@ops.ietf.org Thu Nov 13 11:32: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 LAA06327 for ; Thu, 13 Nov 2003 11:32:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKKOC-0005Vp-FQ for multi6-data@psg.com; Thu, 13 Nov 2003 16:32:12 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKKO9-0005Ui-W2 for multi6@ops.ietf.org; Thu, 13 Nov 2003 16:32:10 +0000 Received: (qmail 69921 invoked from network); 13 Nov 2003 16:39:53 -0000 Received: from dyn135-178.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.135.178) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 16:39:53 -0000 Message-ID: <3FB3B26C.7040109@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 01:33:48 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: security requirement for multi6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; >>>Then >> >>Then? > Then please post to the list. It was posted to the list on this thread on the same day you post your opinion, which quoted part of my post. Masataka Ohta From owner-multi6@ops.ietf.org Thu Nov 13 12:33:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09615 for ; Thu, 13 Nov 2003 12:33:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKLJu-000EjR-9I for multi6-data@psg.com; Thu, 13 Nov 2003 17:31:50 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKLJr-000Ej0-Jl for multi6@ops.ietf.org; Thu, 13 Nov 2003 17:31:47 +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 hADGDDUP012376; Thu, 13 Nov 2003 08:13:14 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hADGDBQ04820; Thu, 13 Nov 2003 17:13:11 +0100 (MET) Date: Thu, 13 Nov 2003 17:12:12 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Some Comments on ID/Loc Separation Proposals To: Margaret.Wasserman@nokia.com Cc: Erik.Nordmark@Sun.COM, multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > An IP address can be used, for example, to allow ULPs to indicate > which physical interface to use for outbound packets by explictly > choosing a source address. This can be useful for multicast traffic > and specialized ULPs such as routing protocols. I heard this asserted elsewhere yersterday but I haven't seen any IPv* stacks that do such a thing. The outbound interface is selected based on the destination IP address independently of the source address. Thus if the application specifies the source address for if2 and sends a packet to some destination where the routing table for the destination says to use if1, then the packet will go out if1 with the source of if2. Are there host stacks that do something different when there are multiple (equal?) routes that match the destination? > The use of IP addresses as interface identifiers may or may not > have any implications for NOID, as it seems that NOID will allow > ULP access to the real local IP addresses (??) -- the document > doesn't specifically say this, but I'm assuming that is how SCTP > would run over NOID, for example. This is a larger potential issue > for other proposals, such as HIP. In NOID there is a choice (don't know the tradeoffs) whether the application gets all locators (i.e. all potential AIDs for the peer) from the getaddrinfo() API it uses, or whether getaddrinfo() would pick one AID to return to the app. If the app gets all of them *and* if source addresses imply interface selection in the stack, then the application would have control over the interface that is used. Erik From owner-multi6@ops.ietf.org Thu Nov 13 14:51:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15245 for ; Thu, 13 Nov 2003 14:51:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKNU3-0006bK-DE for multi6-data@psg.com; Thu, 13 Nov 2003 19:50:27 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKNU2-0006b4-69 for multi6@ops.ietf.org; Thu, 13 Nov 2003 19:50:26 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKNTy-0002Zj-6S for multi6@ops.ietf.org; Thu, 13 Nov 2003 13:50:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Randy Bush Date: Thu, 13 Nov 2003 13:49:16 -0600 To: multi6@ops.ietf.org Subject: brian steps up X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit once again, brian carpenter, hero of the revolution, steps up to a hard task. he has agreed to co-chair the multi6 wg, working with kurtis lindqvist. thanks a million, brian. randy From owner-multi6@ops.ietf.org Thu Nov 13 15:30: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 PAA18703 for ; Thu, 13 Nov 2003 15:30:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKO5F-000Azd-Qn for multi6-data@psg.com; Thu, 13 Nov 2003 20:28:53 +0000 Received: from [195.212.14.170] (helo=mail-gw1.hursley.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKO5D-000Az5-5s for multi6@ops.ietf.org; Thu, 13 Nov 2003 20:28:51 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AKO5C-0000pn-00 for multi6@ops.ietf.org; Thu, 13 Nov 2003 20:28:50 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AKO5C-0000pj-00 for multi6@ops.ietf.org; Thu, 13 Nov 2003 20:28:50 +0000 Received: from zurich.ibm.com ([9.145.151.149]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id hADKSmv63162 for ; Thu, 13 Nov 2003 20:28:49 GMT Message-ID: <3FB3E950.C2BDC54D@zurich.ibm.com> Date: Thu, 13 Nov 2003 21:28:00 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: <3FB3A174.4000800@innovationslab.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit below... Brian Haberman wrote: > > Erik Nordmark wrote: > > >>The use of the term "Identifier" or "ID" sweeps an important > >>issue under the rug in some cases: Is this a host ID or an > >>interface ID? The current IP (v4 and v6) architecture uses > >>interface IDs. IPv4 implementations are generally constrained > >>to one ID per interface, while IPv6 supports multiple IDs per > >>interface. ID selection is linked to outbound interface > >>selection -- it is still unclear to me what implications this > >>has for ID or Locator selection in ID/Loc separation protocols. > > > > > > An interface ID makes no sense to me. > > > > The concept of a stack name, where there can be one or more "stacks" > > on a given host, provides the right granularity to me. > > Each "stack" can presumbly have one or more network interfaces. > > I agree with Erik that an "interface ID" doesn't make sense. The > question I have is a stack ID high enough? I have been mulling > over the issue of how a security association should work here. Is > the SA between stacks? between apps? between users? > > There may be cases where each of the above approach is useful. Indeed. And they are not mutually exclusive. However, does multi6 need to consider any SA higher than the network or transport level? Brian From owner-multi6@ops.ietf.org Thu Nov 13 15:35: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 PAA19062 for ; Thu, 13 Nov 2003 15:35:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKOB6-000Beg-AA for multi6-data@psg.com; Thu, 13 Nov 2003 20:34:56 +0000 Received: from [195.212.14.170] (helo=mail-gw1.hursley.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKOB2-000Be5-Tz for multi6@ops.ietf.org; Thu, 13 Nov 2003 20:34:53 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AKOB1-0002g5-00; Thu, 13 Nov 2003 20:34:51 +0000 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 1AKOB1-0002fz-00; Thu, 13 Nov 2003 20:34:51 +0000 Received: from zurich.ibm.com ([9.145.151.149]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with ESMTP id hADKYmv26352; Thu, 13 Nov 2003 20:34:49 GMT Message-ID: <3FB3EAC2.517505F4@zurich.ibm.com> Date: Thu, 13 Nov 2003 21:34:10 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Cedric de Launois CC: multi6@ops.ietf.org, Kurt Erik Lindqvist , Tony Li , Christian Huitema Subject: Re: Summary of work areas References: <1068714617.31341.56.camel@descartes> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Cedric, That sounds like very useful work, but can you figure out how to avoid duplication of effort with Eliot's promised draft? Brian Cedric de Launois wrote: > > I'm currently working on a document that classify solutions to the > numerous high-level problems related to multiadressed multihomed IPv6 > end-sites. I mention actual propositions (HIP, NOID, SCTP...) only > as examples that illustrate a particular way to solve a problem. > > I divided the problems into five categories : > - Destination Locator Retrieval and Selection > - Source Locator Selection > - Failure Detection > - Preservation of Security > - Traffic Engineering > > The complete table of content is copy/paste'd below. > > The document is not finished yet. I hope it will help fixing the ideas. > > -- Cedric > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 3. Destination Locator Retrieval and Selection . . . . . . . . 4 > 3.1 Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3.1.1 From the Domain Name System . . . . . . . . . . . . . . . . 4 > 3.1.2 From a Dedicated Service . . . . . . . . . . . . . . . . . . 4 > 3.1.3 Using Transport-Level Protocol . . . . . . . . . . . . . . . 4 > 3.2 Stack Levels for the Destination Locator Selection . . . . . 5 > 3.2.1 Application-Level . . . . . . . . . . . . . . . . . . . . . 5 > 3.2.2 Transport-Level . . . . . . . . . . . . . . . . . . . . . . 5 > 3.2.3 Between IP and Transport Levels . . . . . . . . . . . . . . 5 > 3.2.4 IP-Level . . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 3.3 Destination Locator Selection Mechanisms . . . . . . . . . . 6 > 3.3.1 Experimentation-Based Selection . . . . . . . . . . . . . . 6 > 3.3.2 Using Routing Protocols . . . . . . . . . . . . . . . . . . 6 > > 4. Source Locator Selection . . . . . . . . . . . . . . . . . . 6 > 4.1 Stack Levels for the Source Locator Selection . . . . . . . 6 > 4.1.1 Application-Level . . . . . . . . . . . . . . . . . . . . . 7 > 4.1.2 Transport-Level . . . . . . . . . . . . . . . . . . . . . . 7 > 4.1.3 Between IP and Transport Levels . . . . . . . . . . . . . . 7 > 4.1.4 IP-Level . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 4.2 Source Locator Selection Mechanisms . . . . . . . . . . . . 7 > 4.2.1 Using Routing Protocols . . . . . . . . . . . . . . . . . . 7 > 4.2.2 Automatic Selection by IP Infrastructure . . . . . . . . . . 8 > 4.2.3 Infrastructure-Driven Selection . . . . . . . . . . . . . . 8 > > 5. Failure Detection . . . . . . . . . . . . . . . . . . . . . 8 > 5.1 End-to-End Keepalive . . . . . . . . . . . . . . . . . . . . 8 > 5.2 Passive Detection . . . . . . . . . . . . . . . . . . . . . 9 > 5.3 Using Routing Protocols . . . . . . . . . . . . . . . . . . 9 > > 6. Preservation of Established Communication Sessions . . . . . 10 > 6.1 Application-Level . . . . . . . . . . . . . . . . . . . . . 10 > 6.2 Session-Level . . . . . . . . . . . . . . . . . . . . . . . 10 > 6.3 Transport-Level . . . . . . . . . . . . . . . . . . . . . . 10 > 6.4 Between IP and Transport Levels . . . . . . . . . . . . . . 10 > 6.5 IP Level . . . . . . . . . . . . . . . . . . . . . . . . . . 11 > > 7. Preservation of Security . . . . . . . . . . . . . . . . . . 11 > > 8. Ingress Filtering Issue . . . . . . . . . . . . . . . . . . 11 > 8.1 Relaxing the Source Address Check . . . . . . . . . . . . . 11 > 8.2 Source Address Based Routing . . . . . . . . . . . . . . . . 12 > 8.3 Ensuring Right Source Address Selection by the Host . . . . 12 > 8.4 Packet Rewriting at Exit Router . . . . . . . . . . . . . . 13 > > 9. Traffic Engineering . . . . . . . . . . . . . . . . . . . . 13 > 9.1 Outbound Traffic Engineering . . . . . . . . . . . . . . . . 13 > 9.1.1 Infrastructure-Driven Traffic Engineering . . . . . . . . . 14 > 9.1.2 Host-Driven Traffic Engineering . . . . . . . . . . . . . . 15 > 9.2 Inbound Traffic Engineering . . . . . . . . . . . . . . . . 15 > > Le jeu 13/11/2003 a 05:05, Christian Huitema a ecrit : > > My own list of task includes: > > > > - description of an incremental roadmap that makes "business sense" > > - solving the egress filtering issue (including when addresses cannot be > > rewritten) > > - selection of a first pair of address/locator to "establish contact", > > either from application to TCP (as in the DT2 proposal or in the NOID > > proposal) or from identifier to locator (in the SIM proposal) > > - learning the set of addresses/locators associated to the > > "distinguished address/locator" (common to DT2 proposal and NOID -- the > > DNS is only one of many possibilities) > > - decision algorithm for actually triggering the use of a different set > > of addresses/locators for an ongoing TCP connection (we should consider > > the trade-off between routing events, mobility events, and transport > > events such as retransmit on timer) > > - threat model & possible mitigations of the various attacks > > > > -- Christian Huitema > > > > > > > -----Original Message----- > > > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org] On > > > Behalf Of Kurt Erik Lindqvist > > > Sent: Wednesday, November 12, 2003 7:46 PM > > > To: Tony Li > > > Cc: multi6@ops.ietf.org > > > Subject: Re: Summary of work areas > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > > > > Oh, and I think the bootstrap/start-up face that Margaret and others > > > brought up is something that should be on the list. > > > > > > - - kurtis - > > > > > > On onsdag, nov 12, 2003, at 21:02 Europe/Stockholm, Tony Li wrote: > > > > > > > > > > > Hi, > > > > > > > > To help Elliot out, I'd like for us to start thinking > > > > about our top level work items. As top level items, > > > > they should, IMHO, be as independent as possible (tho > > > > not wholly independent). They should not be nested and > > > > they should not be about the details. > > > > > > > > Here's a strawman: > > > > > > > > > > > > Threat analysis > > > > Locator storage & distribution > > > > Mappings between locators, identifiers, and FQDNs > > > > Security solutions > > > > Exit addressing > > > > > > > > Additions, modifications? > > > > > > > > Tony > > > > From owner-multi6@ops.ietf.org Thu Nov 13 15:44: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 PAA19416 for ; Thu, 13 Nov 2003 15:44:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKOKA-000CmZ-0K for multi6-data@psg.com; Thu, 13 Nov 2003 20:44:18 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKOK7-000CmE-4c for multi6@ops.ietf.org; Thu, 13 Nov 2003 20:44:15 +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 hADKhc46004043; Thu, 13 Nov 2003 21:43:38 +0100 (CET) Date: Thu, 13 Nov 2003 21:43:33 +0100 Subject: Re: security requirement for multi6 Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , Multi6 Mailing List To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <3FB3B26C.7040109@necom830.hpcl.titech.ac.jp> Message-Id: <0C42FFFA-161A-11D8-8943-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> This is not really leading us anywhere... >>>> Then >>> >>> Then? > >> Then please post to the list. > > It was posted to the list on this thread on the same day you post > your opinion, which quoted part of my post. Uhm, I replied to a mail from Iljitsch, that had replied to your statement : >I should state an elementary fact again. > >DoS is so easy. > >That is, that you happen to find a way of DoS does not mean other >forms of DoS is not possible. I then went on to say that although DOS attacks are a fact of life, that does not mean that when designing future solutions, and we discover new possible DOS attacks, and we at the same time knows how to fix them - that we should ignore that. You then said in a reply to my message that >What is your point? > >The current situation is that there are DoS possibilities that we >(I, at least) already know about. And my question was : If you know of DOS possibilities against id/loc split models such as NOID or SIM or others, that are not described in draft-nordmark-multi6-threats-00.txt, then please mail a description of those to the multi6 list. If you also have suggestions or know how to prevent against those attacks, include that. If you can't describe any new threats I think we can kill this thread. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7Ps+KarNKXTPFCVEQJ/6wCgnLFqMdHv7ijQ87DFoWVN/7ntnw8AoJzY 7dEr2wqxkXEZ9LczDOf39I0m =A+Rp -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 13 15:47: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 PAA19639 for ; Thu, 13 Nov 2003 15:47:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKONO-000D8h-KF for multi6-data@psg.com; Thu, 13 Nov 2003 20:47:38 +0000 Received: from [198.6.255.248] (helo=tower.partan.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKONK-000D83-H2 for multi6@ops.ietf.org; Thu, 13 Nov 2003 20:47:34 +0000 Received: from tower.partan.com (localhost.partan.com [127.0.0.1]) by tower.partan.com (8.12.8p2/8.12.8) with ESMTP id hADKlXgq020898 for ; Thu, 13 Nov 2003 15:47:33 -0500 (EST) (envelope-from asp@tower.partan.com) Received: (from asp@localhost) by tower.partan.com (8.12.8p2/8.12.8/Submit) id hADKlXFY020895 for multi6@ops.ietf.org; Thu, 13 Nov 2003 15:47:33 -0500 (EST) (envelope-from asp) Date: Thu, 13 Nov 2003 15:47:33 -0500 From: Andrew Partan To: multi6@ops.ietf.org Subject: how many locators? Message-ID: <20031113204733.GA20637@partan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk How many locators should hosts have - or - how big is the global routing table - or - where do you get your locators from? As the number of locators per host goes up, the complexity of choosing a pair of locations to use for a onnection goes up even faster (probably as n**2). So we probably want to limit the number of locators per host to a smallish number. Now hosts end up getting their locators from their upstreams (and their upstreams' upstream?). The question is how far up you go. The further up you go, the more local paths out you have (probably on the order of n**2), so the more locators per host you have. If you go to the upstream's upstream's upstream, then you are approaching approx the Tier-1 core, so the size of the global routing table is approx the size of the Tier-1 core -- but at the cost of having lots of locators per host. If you go just one hop to the upstream to get the locator, then you have just a few locators per host (basically the number of transit connections per site), but you have a much larger global routing table - approx the number of ISPs in the world. Is this a reasonable size with reasonable growth factors? --asp From owner-multi6@ops.ietf.org Thu Nov 13 15:50: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 PAA19796 for ; Thu, 13 Nov 2003 15:50:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKOPZ-000DWj-37 for multi6-data@psg.com; Thu, 13 Nov 2003 20:49:53 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKOPU-000DW9-JV for multi6@ops.ietf.org; Thu, 13 Nov 2003 20:49:48 +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 hADMrROt034456; Thu, 13 Nov 2003 14:53:27 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hADKmVYB021828; Thu, 13 Nov 2003 12:48:31 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: noid and applications (generic requirements from applications) Date: Thu, 13 Nov 2003 12:48:30 -0800 Message-ID: Thread-Topic: noid and applications (generic requirements from applications) Thread-Index: AcOqAGylPS2QAlMdT2S+f521F3UVXQAJscXw From: "Tony Li" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Erik Nordmark" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Patrik, That is going to be exceedingly difficult. As long as we are using IP addresses in applications and we are hiding the actual reachability of the address from the application, we are guaranteed to be allowing an application to pass along an unreachable address. Note that this is a result of the layering violation of passing around an IP address in the application. Asking us to warp the world to support architectural mistakes strikes me as suboptimal. Regards, Tony | -----Original Message----- | From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com]=20 | Sent: Thursday, November 13, 2003 8:08 AM | To: Erik Nordmark | Cc: Tony Li; multi6@ops.ietf.org | Subject: Re: noid and applications (generic requirements=20 | from applications) | =20 | =20 | On 2003-11-13, at 08.49, Erik Nordmark wrote: | =20 | >> Of course, if we're going to open an implementation, we might want | >> to make the point of referral the FQDN, not the locator(s). | > | > Yes. Especially with noid, where the multihomed node needs=20 | to have a=20 | > FQDN, | > this makes a lot of sense. | =20 | This is ok for an application which of course should use the=20 | FQDN, but,=20 | even when using whatever "thing" the application uses to=20 | establish the=20 | connection (which it gets via the FQDN) that should be=20 | usable without=20 | knowledge of the network topology. I guess one can formulate=20 | it as it=20 | must have features like: | =20 | (A=3DB) and (B=3DC) gives (A=3DC) where '=3D' is "can communicate = with" | =20 | and | =20 | (A->B) gives (B->A) where '->' is "can send data to" | =20 | paf | =20 | =20 From owner-multi6@ops.ietf.org Thu Nov 13 16:07:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20747 for ; Thu, 13 Nov 2003 16:07:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKOf1-000GDX-GK for multi6-data@psg.com; Thu, 13 Nov 2003 21:05:51 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKOew-000GCg-4z for multi6@ops.ietf.org; Thu, 13 Nov 2003 21:05:46 +0000 Received: (qmail 71161 invoked from network); 13 Nov 2003 21:13:32 -0000 Received: from dyn129-43.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.129.43) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 21:13:32 -0000 Message-ID: <3FB3F28D.7090706@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 06:07:25 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: security requirement for multi6 References: <0C42FFFA-161A-11D8-8943-000A9598A184@kurtis.pp.se> In-Reply-To: <0C42FFFA-161A-11D8-8943-000A9598A184@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; > If you can't describe any new threats I think we can kill this thread. No, we can't. This thread is whether threats claimed to be new are really new or not. You miss the point. I showed that some are not new. Iljitsch showed a new case, which was expected to be a new threat. I modified the case using current TCP to show that the threat is not new. Note that our security requirement is not more security but not-less security. Masataka Ohta From owner-multi6@ops.ietf.org Thu Nov 13 16:11: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 QAA20993 for ; Thu, 13 Nov 2003 16:11:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKOke-000GfJ-0H for multi6-data@psg.com; Thu, 13 Nov 2003 21:11:40 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKOkW-000Gf4-PT for multi6@ops.ietf.org; Thu, 13 Nov 2003 21:11:32 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 092EF43137; Thu, 13 Nov 2003 22:11:32 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp02.uc3m.es (Postfix) with ESMTP id 35BFF9A07A; Thu, 13 Nov 2003 22:11:29 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Kurt Erik Lindqvist , Iljitsch van Beijnum Subject: Re: noid and applications (generic requirements from applications) Date: Thu, 13 Nov 2003 22:11:19 +0100 User-Agent: KMail/1.5.4 Cc: Erik Nordmark , Multi6 Mailing List References: <727E5CBD-15DE-11D8-882E-000A9598A184@kurtis.pp.se> In-Reply-To: <727E5CBD-15DE-11D8-882E-000A9598A184@kurtis.pp.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311132211.20946.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 13 November 2003 14:36, Kurt Erik Lindqvist wrote: > On torsdag, nov 13, 2003, at 04:11 Europe/Stockholm, Iljitsch van > > Beijnum wrote: > > On 12-nov-03, at 20:45, Erik Nordmark wrote: > >> The only thing to consider is when AID(A) isn't working as a locator > >> when > >> C tries to contact it. > >> > >> There are two choices: > >> C can detect that the locator doesn't work and do a reverse+forward > >> DNS > >> lookup to get the whole locator set (Ls(A)). > >> or > >> The referal can include Ls(A) instead of just the AID(A); this > >> requires > >> modifying existing IPv6 appication protocols which do referal. > > > > I think it would be a good idea to look at a referral API. Such an API > > would allow a host to ask the system to create a neat little package > > containing all the pertinent locator and identifier information, then > > it can transmit this package to a correspondent and the correspondent > > can then unwrap it and use the content to do whatever it needed the > > referral for. The advantage of such a system is that it could allow > > applications that need referral to be completely independent of lower > > layer technologies, such as the multihoming solution we're going to > > implement, and the differences between IPv4 and IPv6. The downside > > would be that this referral package could get significantly larger > > than a simple address. > > Although I am tempted to say that a multi6 API with ULP hints, referral > package, etc is a good idea - I am not sure I think that is where we > should be right now. This will mean that applications will have to be > rewritten in order to make full use of the mulihoming solution. Maybe > this is another topic for Elliot's draft? > > - kurtis - The Ilijtshc's comment raise the question whether multihoming should be solved at the IP layer. I'm sure that applications can find out a (better) multihoming solution. -- ****** JFRH ****** Real computer scientists admire ADA for its overwhelming aesthetic value but they find it difficult to actually program in it, as it is much too large to implement. Most computer scientists don't notice this because they are still arguing over what else to add to ADA. From owner-multi6@ops.ietf.org Thu Nov 13 16:22: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 QAA21293 for ; Thu, 13 Nov 2003 16:22:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKOuQ-000HV7-OS for multi6-data@psg.com; Thu, 13 Nov 2003 21:21:46 +0000 Received: from [206.197.161.140] (helo=uillean.fuaim.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKOuO-000HUu-6s for multi6@ops.ietf.org; Thu, 13 Nov 2003 21:21:44 +0000 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id hADLLhV12144 for ; Thu, 13 Nov 2003 13:21:43 -0800 Received: from innovationslab.net (dyn134-131.ietf58.ietf.org [130.129.134.131]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hADLPatX020885 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 13 Nov 2003 13:25:44 -0800 Message-ID: <3FB3F59B.8080700@innovationslab.net> Date: Thu, 13 Nov 2003 16:20:27 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: <3FB3A174.4000800@innovationslab.net> <3FB3E950.C2BDC54D@zurich.ibm.com> In-Reply-To: <3FB3E950.C2BDC54D@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > below... > > Brian Haberman wrote: > >>Erik Nordmark wrote: >> >> >>>>The use of the term "Identifier" or "ID" sweeps an important >>>>issue under the rug in some cases: Is this a host ID or an >>>>interface ID? The current IP (v4 and v6) architecture uses >>>>interface IDs. IPv4 implementations are generally constrained >>>>to one ID per interface, while IPv6 supports multiple IDs per >>>>interface. ID selection is linked to outbound interface >>>>selection -- it is still unclear to me what implications this >>>>has for ID or Locator selection in ID/Loc separation protocols. >>> >>> >>>An interface ID makes no sense to me. >>> >>>The concept of a stack name, where there can be one or more "stacks" >>>on a given host, provides the right granularity to me. >>>Each "stack" can presumbly have one or more network interfaces. >> >>I agree with Erik that an "interface ID" doesn't make sense. The >>question I have is a stack ID high enough? I have been mulling >>over the issue of how a security association should work here. Is >>the SA between stacks? between apps? between users? >> >>There may be cases where each of the above approach is useful. > > > Indeed. And they are not mutually exclusive. However, does multi6 > need to consider any SA higher than the network or transport level? For the purpose of multi6, I agree with Erik that a "stack ID" is sufficient. Regards, Brian From owner-multi6@ops.ietf.org Thu Nov 13 16:29: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 QAA21566 for ; Thu, 13 Nov 2003 16:29:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKP1M-000I97-IP for multi6-data@psg.com; Thu, 13 Nov 2003 21:28:56 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKP1I-000I8v-G6 for multi6@ops.ietf.org; Thu, 13 Nov 2003 21:28:52 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B2BBD2FE; Thu, 13 Nov 2003 22:28:51 +0100 (CET) Received: from cimborrio (cimborrio.it.uc3m.es [163.117.139.95]) by smtp03.uc3m.es (Postfix) with ESMTP id 9CA672FC; Thu, 13 Nov 2003 22:28:51 +0100 (CET) From: Juan Rodriguez Hervella Organization: UC3M To: Erik Nordmark , Margaret.Wasserman@nokia.com Subject: Re: Some Comments on ID/Loc Separation Proposals Date: Thu, 13 Nov 2003 22:28:42 +0100 User-Agent: KMail/1.5.4 Cc: Erik.Nordmark@Sun.COM, multi6@ops.ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311132228.43501.jrh@it.uc3m.es> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday 13 November 2003 17:12, Erik Nordmark wrote: > > An IP address can be used, for example, to allow ULPs to indicate > > which physical interface to use for outbound packets by explictly > > choosing a source address. This can be useful for multicast traffic > > and specialized ULPs such as routing protocols. > > I heard this asserted elsewhere yersterday but I haven't seen any IPv* > stacks that do such a thing. > The outbound interface is selected based on the destination IP address > independently of the source address. > Thus if the application specifies the source address for if2 and sends > a packet to some destination where the routing table for the destination > says to use if1, then the packet will go out if1 with the source of if2. Hello, Quoted from RFC 1122 ("Strong End System" model): ---beginning of quotation: There are two key requirement issues related to multihoming: (A) A host MAY silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received. (B) A host MAY restrict itself to sending (non-source- routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams. o Strong ES Model The Strong ES (End System, i.e., host) model emphasizes the host/gateway (ES/IS) distinction, and would therefore substitute MUST for MAY in issues (A) and (B) above. It tends to model a multihomed host as a set of logical hosts within the same physical host. With respect to (A), proponents of the Strong ES model note that automatic Internet routing mechanisms could not route a datagram to a physical interface that did not correspond to the destination address. Under the Strong ES model, the route computation for an outgoing datagram is the mapping: route(src IP addr, dest IP addr, TOS) -> gateway ----end of quotation In short, Erik, under the "strong ES" model assuption, your example would _not_work. Ciao ! -- ****** JFRH ****** SAGITTARIUS (Nov 22 - Dec 21) You are optimistic and enthusiastic. You have a reckless tendency to rely on luck since you lack talent. The majority of Sagittarians are drunks or dope fiends or both. People laugh at you a great deal. From owner-multi6@ops.ietf.org Thu Nov 13 17:05: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 RAA23155 for ; Thu, 13 Nov 2003 17:05:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKPaf-000MHB-PB for multi6-data@psg.com; Thu, 13 Nov 2003 22:05:25 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKPaE-000MAK-QM for multi6@ops.ietf.org; Thu, 13 Nov 2003 22:04:58 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hADM4vi2014160; Thu, 13 Nov 2003 22:04:57 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hADM4tBE221000; Thu, 13 Nov 2003 23:04:55 +0100 Received: from zurich.ibm.com ([9.145.244.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA60394; Thu, 13 Nov 2003 23:04:54 +0100 Message-ID: <3FB3FFDF.D15B73E7@zurich.ibm.com> Date: Thu, 13 Nov 2003 23:04:15 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Andrew Partan CC: multi6@ops.ietf.org Subject: Re: how many locators? References: <20031113204733.GA20637@partan.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andrew Partan wrote: ... > If you go just one hop to the upstream to get the locator, then you > have just a few locators per host (basically the number of transit > connections per site), but you have a much larger global routing > table - approx the number of ISPs in the world. This is the model I have always assumed for IPv6. > Is this a reasonable size with reasonable growth factors? This is what I have assumed. If these assumptions are false, I think it affects more than just multi6. Brian From owner-multi6@ops.ietf.org Thu Nov 13 17:18: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 RAA24220 for ; Thu, 13 Nov 2003 17:18:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKPn6-000NbF-DM for multi6-data@psg.com; Thu, 13 Nov 2003 22:18:16 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKPn1-000Naj-AU for multi6@ops.ietf.org; Thu, 13 Nov 2003 22:18:11 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hADMI6pT027204; Thu, 13 Nov 2003 22:18:06 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hADMI6BE143980; Thu, 13 Nov 2003 23:18:06 +0100 Received: from zurich.ibm.com ([9.145.244.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA35520; Thu, 13 Nov 2003 23:18:04 +0100 Message-ID: <3FB402F5.E6CBD392@zurich.ibm.com> Date: Thu, 13 Nov 2003 23:17:25 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Juan Rodriguez Hervella CC: Multi6 Mailing List Subject: Re: noid and applications (generic requirements from applications) References: <727E5CBD-15DE-11D8-882E-000A9598A184@kurtis.pp.se> <200311132211.20946.jrh@it.uc3m.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juan Rodriguez Hervella wrote: > > On Thursday 13 November 2003 14:36, Kurt Erik Lindqvist wrote: > > On torsdag, nov 13, 2003, at 04:11 Europe/Stockholm, Iljitsch van > > > > Beijnum wrote: > > > On 12-nov-03, at 20:45, Erik Nordmark wrote: > > >> The only thing to consider is when AID(A) isn't working as a locator > > >> when > > >> C tries to contact it. > > >> > > >> There are two choices: > > >> C can detect that the locator doesn't work and do a reverse+forward > > >> DNS > > >> lookup to get the whole locator set (Ls(A)). > > >> or > > >> The referal can include Ls(A) instead of just the AID(A); this > > >> requires > > >> modifying existing IPv6 appication protocols which do referal. > > > > > > I think it would be a good idea to look at a referral API. Such an API > > > would allow a host to ask the system to create a neat little package > > > containing all the pertinent locator and identifier information, then > > > it can transmit this package to a correspondent and the correspondent > > > can then unwrap it and use the content to do whatever it needed the > > > referral for. The advantage of such a system is that it could allow > > > applications that need referral to be completely independent of lower > > > layer technologies, such as the multihoming solution we're going to > > > implement, and the differences between IPv4 and IPv6. The downside > > > would be that this referral package could get significantly larger > > > than a simple address. > > > > Although I am tempted to say that a multi6 API with ULP hints, referral > > package, etc is a good idea - I am not sure I think that is where we > > should be right now. This will mean that applications will have to be > > rewritten in order to make full use of the mulihoming solution. Maybe > > this is another topic for Elliot's draft? > > > > - kurtis - > > The Ilijtshc's comment raise the question whether multihoming should be > solved at the IP layer. I'm sure that applications can find out a (better) > multihoming solution. There are in fact many applications that succesfully survive connectivity changes, but this WG is chartered to work on *site* multihoming for IPv6 and that seems to imply layer 3 or layer 4 solutions. Brian From owner-multi6@ops.ietf.org Thu Nov 13 17:22: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 RAA24456 for ; Thu, 13 Nov 2003 17:22:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKPrP-000O8G-Q5 for multi6-data@psg.com; Thu, 13 Nov 2003 22:22:43 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKPrN-000O7w-3p for multi6@ops.ietf.org; Thu, 13 Nov 2003 22:22:41 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hADMM8i2092278; Thu, 13 Nov 2003 22:22:08 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hADMM7w2256166; Thu, 13 Nov 2003 23:22:08 +0100 Received: from zurich.ibm.com ([9.145.244.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA33898; Thu, 13 Nov 2003 23:22:05 +0100 Message-ID: <3FB403E4.5D5E84BE@zurich.ibm.com> Date: Thu, 13 Nov 2003 23:21:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Masataka Ohta CC: Multi6 Mailing List Subject: Re: security requirement for multi6 References: <0C42FFFA-161A-11D8-8943-000A9598A184@kurtis.pp.se> <3FB3F28D.7090706@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka, Whether a threat is new or old really doesn't matter. Our objective is to have a complete threat analysis that we can use to evaluate the security of proposed solutions. As Kurt says, if you have additional threats that should be added to Erik's threat analysis draft, please send text. Brian Masataka Ohta wrote: > > Kurt; > > > If you can't describe any new threats I think we can kill this thread. > > No, we can't. > > This thread is whether threats claimed to be new are really new > or not. > > You miss the point. > > I showed that some are not new. > > Iljitsch showed a new case, which was expected to be a new > threat. > > I modified the case using current TCP to show that the threat > is not new. > > Note that our security requirement is not more security but > not-less security. > > Masataka Ohta From owner-multi6@ops.ietf.org Thu Nov 13 17:26: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 RAA24654 for ; Thu, 13 Nov 2003 17:26:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKPua-000OXC-TD for multi6-data@psg.com; Thu, 13 Nov 2003 22:26:00 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKPuV-000OWD-MT for multi6@ops.ietf.org; Thu, 13 Nov 2003 22:25:55 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hADMPbed061812; Thu, 13 Nov 2003 23:25:38 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20031113204733.GA20637@partan.com> References: <20031113204733.GA20637@partan.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58222342-1628-11D8-8CC8-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: how many locators? Date: Thu, 13 Nov 2003 16:25:54 -0600 To: Andrew Partan X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 13-nov-03, at 14:47, Andrew Partan wrote: > How many locators should hosts have - or - how big is the global > routing table - or - where do you get your locators from? > As the number of locators per host goes up, the complexity of > choosing a pair of locations to use for a onnection goes up even > faster (probably as n**2). Actually at some point the complexity goes down again. If we take getting an address from each ISP to its extreme at some point hosts will have addresses for each aspect of our existence. So at some point two people at opposite ends of an ocean are each going to have an address from the provider of the intercontinental cable. The regular "longest match first" rule in the address selection mechanism will then select those addresses for both ends. Then we simple add a preference to each address and it's going to be the best possible address, too. But in reality the average number of addresses for multihomers would be very close to 2, exactly because having many addresses would stress the selection mechanisms (that we have to come up with) too much. From owner-multi6@ops.ietf.org Thu Nov 13 17:29: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 RAA24738 for ; Thu, 13 Nov 2003 17:29:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKPxT-000P20-Kx for multi6-data@psg.com; Thu, 13 Nov 2003 22:28:59 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKPxL-000P1A-Jy for multi6@ops.ietf.org; Thu, 13 Nov 2003 22:28:51 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hADMP3CW073322; Thu, 13 Nov 2003 22:25:03 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hADMRVBE268672; Thu, 13 Nov 2003 23:27:31 +0100 Received: from zurich.ibm.com ([9.145.244.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA35338; Thu, 13 Nov 2003 23:27:15 +0100 Message-ID: <3FB4051C.283FFF14@zurich.ibm.com> Date: Thu, 13 Nov 2003 23:26:36 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Tony Li CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , multi6@ops.ietf.org Subject: Re: noid and applications (generic requirements from applications) References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Tony, Doesn't this objection also apply to passing an FQDN around, since FQDNs can also be unreachable, due to 2-faced DNS and the like? In other words, referral is a very deep problem in the non-transparent network that we sometimes still describe as "the Internet." I suspect this is a problem that multi6 is unable to solve; we should simply not make it worse. Brian Tony Li wrote: > = > Patrik, > = > That is going to be exceedingly difficult. As long as we > are using IP addresses in applications and we are hiding > the actual reachability of the address from the application, > we are guaranteed to be allowing an application to pass along > an unreachable address. > = > Note that this is a result of the layering violation of > passing around an IP address in the application. Asking us > to warp the world to support architectural mistakes strikes > me as suboptimal. > = > Regards, > Tony > = > | -----Original Message----- > | From: Patrik F=E4ltstr=F6m [mailto:paf@cisco.com] > | Sent: Thursday, November 13, 2003 8:08 AM > | To: Erik Nordmark > | Cc: Tony Li; multi6@ops.ietf.org > | Subject: Re: noid and applications (generic requirements > | from applications) > | > | > | On 2003-11-13, at 08.49, Erik Nordmark wrote: > | > | >> Of course, if we're going to open an implementation, we might wan= t > | >> to make the point of referral the FQDN, not the locator(s). > | > > | > Yes. Especially with noid, where the multihomed node needs > | to have a > | > FQDN, > | > this makes a lot of sense. > | > | This is ok for an application which of course should use the > | FQDN, but, > | even when using whatever "thing" the application uses to > | establish the > | connection (which it gets via the FQDN) that should be > | usable without > | knowledge of the network topology. I guess one can formulate > | it as it > | must have features like: > | > | (A=3DB) and (B=3DC) gives (A=3DC) where '=3D' is "can communicate = with" > | > | and > | > | (A->B) gives (B->A) where '->' is "can send data to" > | > | paf From owner-multi6@ops.ietf.org Thu Nov 13 17:42:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25530 for ; Thu, 13 Nov 2003 17:42:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKQ9x-0000aU-R3 for multi6-data@psg.com; Thu, 13 Nov 2003 22:41:53 +0000 Received: from [130.129.132.189] (helo=kurtis-lindqvists-computer.local) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKQ9v-0000aD-O3 for multi6@ops.ietf.org; Thu, 13 Nov 2003 22:41:51 +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 hADMfC46004097; Thu, 13 Nov 2003 23:41:12 +0100 (CET) Date: Thu, 13 Nov 2003 23:40:46 +0100 Subject: Re: noid and applications (generic requirements from applications) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , Erik Nordmark , Multi6 Mailing List To: Juan Rodriguez Hervella From: Kurt Erik Lindqvist In-Reply-To: <200311132211.20946.jrh@it.uc3m.es> Message-Id: <6C47D5E8-162A-11D8-8943-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On torsdag, nov 13, 2003, at 22:11 Europe/Stockholm, Juan Rodriguez Hervella wrote: > The Ilijtshc's comment raise the question whether multihoming should be > solved at the IP layer. I'm sure that applications can find out a > (better) > multihoming solution. > I don't agree with that line of thought. One does not imply the other. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7QIcaarNKXTPFCVEQL79ACg7bKIxoiCYvIs5eCY0Kg0+7qLDc0AnjBF Pg9unSv45bXL+04qSx6AJ8a7 =BI0j -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 13 17:43: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 RAA25700 for ; Thu, 13 Nov 2003 17:43:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKQBg-0000j4-Lv for multi6-data@psg.com; Thu, 13 Nov 2003 22:43:40 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKQBd-0000im-6v for multi6@ops.ietf.org; Thu, 13 Nov 2003 22:43:37 +0000 Received: (qmail 71492 invoked from network); 13 Nov 2003 22:51:25 -0000 Received: from dyn129-43.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.129.43) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 22:51:25 -0000 Message-ID: <3FB4097F.3010708@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 07:45:19 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Mailing List Subject: Re: security requirement for multi6 References: <0C42FFFA-161A-11D8-8943-000A9598A184@kurtis.pp.se> <3FB3F28D.7090706@necom830.hpcl.titech.ac.jp> <3FB403E4.5D5E84BE@zurich.ibm.com> In-Reply-To: <3FB403E4.5D5E84BE@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > Whether a threat is new or old really doesn't matter. > > Our objective is to have a complete threat analysis that we can use > to evaluate the security of proposed solutions. If you use "complete" that way, the threat list MUST be proposal specific. For example, if I propose a protocol which clones TCP and name it MOCP, there will be a new threat of MOCP SYN attack, in addition to TCP SYN attack. This is not a productive way to do things, though. Erik is trying to be more productive stating in the abstract that: The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. Just as SYN attack is inherent to not TCP but having state on the initial paket of a 3-way handshake, redirection by MITM is inherent to not M6 problem but MITM. Masataka Ohta From owner-multi6@ops.ietf.org Thu Nov 13 18:02: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 SAA26297 for ; Thu, 13 Nov 2003 18:02:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKQT6-00039K-E0 for multi6-data@psg.com; Thu, 13 Nov 2003 23:01:40 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKQT4-000398-FD for multi6@ops.ietf.org; Thu, 13 Nov 2003 23:01:38 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hADN1Ked062281; Fri, 14 Nov 2003 00:01:20 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FB4051C.283FFF14@zurich.ibm.com> References: <3FB4051C.283FFF14@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <472A099E-162B-11D8-8CC8-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: noid and applications (generic requirements from applications) Date: Thu, 13 Nov 2003 16:46:54 -0600 To: Brian E Carpenter X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 13-nov-03, at 16:26, Brian E Carpenter wrote: > Doesn't this objection also apply to passing an FQDN around, > since FQDNs can also be unreachable, due to 2-faced DNS > and the like? What would be the logic of making something unreachable using twofaced DNS? I thought the point was to make sure that different people connect to different hosts when they try to connect to an FQDN. The situation where one side of the DNS produces something useful while the other doesn't is either unintended, which is the risk you run by abusing technology in this way, or is intended in which case there isn't a problem. From owner-multi6@ops.ietf.org Thu Nov 13 18:07:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27011 for ; Thu, 13 Nov 2003 18:07:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKQXr-0003sh-Rf for multi6-data@psg.com; Thu, 13 Nov 2003 23:06:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKQXo-0003qp-1c for multi6@ops.ietf.org; Thu, 13 Nov 2003 23:06:32 +0000 Received: (qmail 71587 invoked from network); 13 Nov 2003 23:14:19 -0000 Received: from dyn129-43.ietf58.ietf.org (HELO necom830.hpcl.titech.ac.jp) (130.129.129.43) by necom830.hpcl.titech.ac.jp with SMTP; 13 Nov 2003 23:14:19 -0000 Message-ID: <3FB40EDC.2090508@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 08:08:12 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Andrew Partan CC: multi6@ops.ietf.org Subject: Re: how many locators? References: <20031113204733.GA20637@partan.com> In-Reply-To: <20031113204733.GA20637@partan.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andrew Partan; First, thank you for initiating a real engineering discussion, with quantatative analysis possible. > How many locators should hosts have At Vienna, I said 9 (=3*3) is a proper upper limit. > - or - how big is the global > routing table 1K~8K. > - or - where do you get your locators from? Anyway, though DNS is suggested. > As the number of locators per host goes up, the complexity of > choosing a pair of locations to use for a onnection goes up even > faster (probably as n**2). No. It is n. We have code of our protocol to do so. Moreover, global routing table small enough to be held on hosts can optimize the order of try that n can, in most cases, 1 or 2. > So we probably want to limit the number of locators per host to a > smallish number. Still yes, though 16 or 20 may be tolerated. > Now hosts end up getting their locators from their upstreams (and > their upstreams' upstream?). The question is how far up you go. Two levels of ISP is reasonable. But, note that lower level ISPs can peer with a lot more than 3 other ISPs. A site may directly negotiate with upper level ISPs to have 9 upper links. Depending on a policy to assign TLAs, big companies may get its own TLA and be multihomed with IPv4 style. But, it should cost a lot. > If you go to the upstream's upstream's upstream, then you are > approaching approx the Tier-1 core, so the size of the global routing > table is approx the size of the Tier-1 core -- but at the cost of > having lots of locators per host. The cost should be paid by those wanting to have lots of locators or their peer. > If you go just one hop to the upstream to get the locator, then you > have just a few locators per host (basically the number of transit > connections per site), but you have a much larger global routing > table - approx the number of ISPs in the world. > > Is this a reasonable size with reasonable growth factors? Currently, ISPs are assigned address blocks, primarily if they are multihomed to other ISPs, which is inevitable with multihoming issues unsolved. As the number and density of ISP grows, more and more ISPs qualify to have its own address blocks. Note that, with dark fiber, cost of local peering is almost zero. Suppose that an ISP, in average, serves 1K people mostly singly homed and world population is 5G, there will be 5M ISPs. Do you think it small enough? Masataka Ohta From owner-multi6@ops.ietf.org Thu Nov 13 18:11: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 SAA27757 for ; Thu, 13 Nov 2003 18:11:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKQc7-0004Rw-E8 for multi6-data@psg.com; Thu, 13 Nov 2003 23:10:59 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKQc4-0004Qv-69 for multi6@ops.ietf.org; Thu, 13 Nov 2003 23:10:56 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADNAsw15286 for ; Fri, 14 Nov 2003 01:10:55 +0200 Date: Fri, 14 Nov 2003 01:10:54 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: delayed multihoming/mobility set-up Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, Me and Dave Crocker sat down and thought about multihoming and mobility a bit. Among other things, we came up with one notion which may not have been explicitly mentioned, but may be relevant: Is it necessary to ensure connection survivability prior to the connection establishment? Or, is it necessary to ensure connection survivability in parallel with the connection establishment? Or even, is it OK to just ensure connection survivability only for "long-lived" sessions (e.g., those which have lasted for longer than 5 minutes), using some definition. The last one would be obviously useful with low-mobility rate, or site multihoming when the connection survivability method you're using would require extra packets or extra delay to set up -- and you'd want to avoid that when it's not necessary. Note that in low-mobility or site multihoming scenarios you don't expect the the multihoming to be required *immediately*; the risk increases in proportion to the time. Would an "intentional race-condition" be acceptable in most cases? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Nov 13 18:12:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27936 for ; Thu, 13 Nov 2003 18:12:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKQdF-0004Xv-MF for multi6-data@psg.com; Thu, 13 Nov 2003 23:12:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKQdD-0004Xa-DL for multi6@ops.ietf.org; Thu, 13 Nov 2003 23:12:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hADNC6a15306 for ; Fri, 14 Nov 2003 01:12:06 +0200 Date: Fri, 14 Nov 2003 01:12:06 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: piggybacking on data in delayed mobility/multihoming setup Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, The corollary from the previous observation of "delayed mobility/multihoming setup" became apparent soon afterwards: Maybe the mobility/multihoming setup, when initiated afterwards, could be piggybacked on the data packets? Obviously, this could result in zero new packets, only minimal amount of overhead for a couple of packets only. The mobility/multihoming -related data could be put e.g. in a new destination option, which could be included e.g.: - after the connection has been up for more than X minutes/seconds, - after the packet size is lower than MTU-MOBOPT_SIZE (i.e., piggyback it only when there is "extra" free space in the packets) - etc. Of course, there could be problems with a model like this with connectionless protocols, especially if there are no acknowledgements. But maybe then connection survability is not a huge problem in any case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Nov 13 18:15: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 SAA28297 for ; Thu, 13 Nov 2003 18:15:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKQgU-0004yr-92 for multi6-data@psg.com; Thu, 13 Nov 2003 23:15:30 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKQgQ-0004yT-GS for multi6@ops.ietf.org; Thu, 13 Nov 2003 23:15:26 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hADNEkXP092982; Thu, 13 Nov 2003 23:14:46 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hADNEjw2259778; Fri, 14 Nov 2003 00:14:45 +0100 Received: from zurich.ibm.com ([9.145.244.71]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id AAA60344; Fri, 14 Nov 2003 00:14:42 +0100 Message-ID: <3FB4103B.16F8E922@zurich.ibm.com> Date: Fri, 14 Nov 2003 00:14:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Juan Rodriguez Hervella CC: Erik Nordmark , Margaret.Wasserman@nokia.com, multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: <200311132228.43501.jrh@it.uc3m.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'd observe that 1122 is fundamentally an IPv4 document. We should not take it as applying exactly to IPv6, where the notion of an interface is somewhat different. Brian Juan Rodriguez Hervella wrote: > > On Thursday 13 November 2003 17:12, Erik Nordmark wrote: > > > An IP address can be used, for example, to allow ULPs to indicate > > > which physical interface to use for outbound packets by explictly > > > choosing a source address. This can be useful for multicast traffic > > > and specialized ULPs such as routing protocols. > > > > I heard this asserted elsewhere yersterday but I haven't seen any IPv* > > stacks that do such a thing. > > The outbound interface is selected based on the destination IP address > > independently of the source address. > > Thus if the application specifies the source address for if2 and sends > > a packet to some destination where the routing table for the destination > > says to use if1, then the packet will go out if1 with the source of if2. > > Hello, > > Quoted from RFC 1122 ("Strong End System" model): > > ---beginning of quotation: > > There are two key requirement issues related to multihoming: > > (A) A host MAY silently discard an incoming datagram whose > destination address does not correspond to the physical > interface through which it is received. > > (B) A host MAY restrict itself to sending (non-source- > routed) IP datagrams only through the physical > interface that corresponds to the IP source address of > the datagrams. > > o Strong ES Model > > The Strong ES (End System, i.e., host) model > emphasizes the host/gateway (ES/IS) distinction, > and would therefore substitute MUST for MAY in > issues (A) and (B) above. It tends to model a > multihomed host as a set of logical hosts within > the same physical host. > > With respect to (A), proponents of the Strong ES > model note that automatic Internet routing > mechanisms could not route a datagram to a > physical interface that did not correspond to the > destination address. > > Under the Strong ES model, the route computation > for an outgoing datagram is the mapping: > > route(src IP addr, dest IP addr, TOS) > -> gateway > > ----end of quotation > > In short, Erik, under the "strong ES" model assuption, > your example would _not_work. > > Ciao ! > > -- > ****** > JFRH > ****** From owner-multi6@ops.ietf.org Thu Nov 13 18:26: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 SAA28983 for ; Thu, 13 Nov 2003 18:26:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKQqo-0006Lm-HB for multi6-data@psg.com; Thu, 13 Nov 2003 23:26:10 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKQqk-0006LD-II for multi6@ops.ietf.org; Thu, 13 Nov 2003 23:26:06 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hADNPked062558; Fri, 14 Nov 2003 00:25:49 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: how many locators? Date: Thu, 13 Nov 2003 17:26:03 -0600 To: "Christian Huitema" X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 13-nov-03, at 16:42, Christian Huitema wrote: >> But in reality the average number of addresses for multihomers would >> be very close to 2, exactly because having many addresses would >> stress the selection mechanisms (that we have to come up with) too >> much. > We should not make such assumptions. I have already seen hosts > configuring many global addresses. You are right of course. We shouldn't assume this, and it was in no way my intention to say the number of addresses _should_ be just two. It's just that the address selection problem is complex and having very many addresses really doesn't help. Removing known low quality addresses is the easiest way to optimize this. > You have also to consider things like > privacy extensions and temporary addresses -- addresses which, by the > way, should never be placed in a database... Yes. However, for the purposes of what we're trying to do we can usually aggregate different addresses with the same prefix and treat them as one address for optimization purposes. From owner-multi6@ops.ietf.org Thu Nov 13 20:25: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 UAA03405 for ; Thu, 13 Nov 2003 20:25:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKSh4-000Jiy-8U for multi6-data@psg.com; Fri, 14 Nov 2003 01:24:14 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKSh1-000Jil-7j for multi6@ops.ietf.org; Fri, 14 Nov 2003 01:24:11 +0000 Received: from dyn129-225.ietf58.ietf.org (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAE1UVf28902; Thu, 13 Nov 2003 17:30:31 -0800 Date: Thu, 13 Nov 2003 17:21:45 -0600 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <477501015.20031113172145@brandenburg.com> To: Margaret.Wasserman@nokia.com CC: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret, Wnc> The use of the term "Identifier" or "ID" sweeps an important MWnc> issue under the rug in some cases: Is this a host ID or an MWnc> interface ID? or a 'stack id' or an 'endpoint id'? and what do these mean, precisely. so, yes, we need to be precise and consistent in defining the term. (Our -analysis- paper has an increasing list of terminology, with a goal of capturing consensus definitions. Feedback is eagerly sought.) MWnc> - Initial end-to-end connection set-up. MWnc> - Referrals. MWnc> - What happens when two nodes try to establish connections MWnc> to each other "simultaneously" MWnc> - How does the mechanism avoid connection hijacking? These are really good points. For example, I had frankly been avoiding trying to handle referrals, but any solution needs to attend to this requirement explicitly. MWnc> MAST Feedback: MWnc> Uses a control protocol between the two end-nodes to MWnc> exchange address information. The current proposal is MWnc> two sparsely defined to allow a full analysis of its MWnc> properties. And, of course, that is intentional. The intent is to distinguish between basic approach, versus the essential details of a specification that permits real implementation. MWnc> In particular the document does not describe MWnc> when MAST control messages would be sent, and how the MWnc> nodes would know when to send them. Right. Absolutely required -- eventually -- but not the rocket science of designing an address pool maintenance mechanism. MWnc> - How do the end-points know when they need to MWnc> send SET operations to update the locators MWnc> being used on the ends of this connection? ignoring the heartbeat function that is suggested, why would not the obvious "when something changes" rule suffice? MWnc> - The draft suggests using IPsec to secure the MWnc> control connection, but IPsec doesn't support MWnc> changing end-point addresses. As one or another of the other wedge proposals suggests, IPSec would run above the Mast address pool mechanism. Hence, IPSec would only see one "address". MWnc> - The PROBE message sounds (to me) similar to MWnc> the old proposal to use pings to detect dead MWnc> gateways. What can we learn from the problems MWnc> with that model that apply here? I, too, would greatly like to hear feedback on this construct. I've seen a couple of comments that raised no concerns about it, but none that offered assurance it would work ok. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Nov 13 21:42: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 VAA07108 for ; Thu, 13 Nov 2003 21:42:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKTtj-0002n4-NU for multi6-data@psg.com; Fri, 14 Nov 2003 02:41:23 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKTtf-0002mA-9k for multi6@ops.ietf.org; Fri, 14 Nov 2003 02:41:19 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAE2fGpT081160 for ; Fri, 14 Nov 2003 02:41:16 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAE2fGw2270046 for ; Fri, 14 Nov 2003 03:41:16 +0100 Received: from zurich.ibm.com ([9.145.140.250]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id DAA60358 for ; Fri, 14 Nov 2003 03:41:13 +0100 Message-ID: <3FB44094.504A7737@zurich.ibm.com> Date: Fri, 14 Nov 2003 03:40:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: how many locators? References: <20031113204733.GA20637@partan.com> <3FB40EDC.2090508@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta wrote: > > Suppose that an ISP, in average, serves 1K people mostly singly > homed and world population is 5G, there will be 5M ISPs. I think 1K subscribers is a very low average. Even 10k seems low to me. So I think 500k ISPs is more likely than 5M. Brian From owner-multi6@ops.ietf.org Thu Nov 13 21:50: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 VAA07275 for ; Thu, 13 Nov 2003 21:50:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKU2H-0003zJ-5m for multi6-data@psg.com; Fri, 14 Nov 2003 02:50:13 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKU2C-0003xp-8s for multi6@ops.ietf.org; Fri, 14 Nov 2003 02:50:08 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAE2o0XP106750; Fri, 14 Nov 2003 02:50:01 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAE2o0BE265778; Fri, 14 Nov 2003 03:50:00 +0100 Received: from zurich.ibm.com ([9.145.140.250]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id DAA44196; Fri, 14 Nov 2003 03:49:58 +0100 Message-ID: <3FB442AF.9BB3BCC6@zurich.ibm.com> Date: Fri, 14 Nov 2003 03:49:19 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Mailing List Subject: Re: noid and applications (generic requirements from applications) References: <3FB4051C.283FFF14@zurich.ibm.com> <472A099E-162B-11D8-8CC8-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On 13-nov-03, at 16:26, Brian E Carpenter wrote: > > > Doesn't this objection also apply to passing an FQDN around, > > since FQDNs can also be unreachable, due to 2-faced DNS > > and the like? > > What would be the logic of making something unreachable using twofaced > DNS? I thought the point was to make sure that different people connect > to different hosts when they try to connect to an FQDN. The situation > where one side of the DNS produces something useful while the other > doesn't is either unintended, which is the risk you run by abusing > technology in this way, or is intended in which case there isn't a > problem. I don't mean there would be any logic. My point is that just as you can make a mess by referring unrouteable addresses, you can make a mess by referring inaccessible FQDNs. If server.example.com sends a referral for internal-only.example.com to client.example.org, it is no different from sending a referral to FEC0::27. Neither referral makes sense, but both might happen if server.example.com doesn't know any better. Brian From owner-multi6@ops.ietf.org Fri Nov 14 06:18: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 GAA06410 for ; Fri, 14 Nov 2003 06:18:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKbua-00040R-EU for multi6-data@psg.com; Fri, 14 Nov 2003 11:14:48 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKbuX-000406-JU for multi6@ops.ietf.org; Fri, 14 Nov 2003 11:14:45 +0000 Received: (qmail 73662 invoked from network); 14 Nov 2003 11:22:41 -0000 Received: from business.mysantanarow.com (HELO necom830.hpcl.titech.ac.jp) (65.122.201.5) by necom830.hpcl.titech.ac.jp with SMTP; 14 Nov 2003 11:22:41 -0000 Message-ID: <3FB4B98B.7080801@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 20:16:27 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Pekka Savola CC: multi6@ops.ietf.org Subject: Re: delayed multihoming/mobility set-up References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola; > Me and Dave Crocker sat down and thought about multihoming and mobility a > bit. Among other things, we came up with one notion which may not have been > explicitly mentioned, but may be relevant: > Is it necessary to ensure connection survivability prior to the connection > establishment? Survivability of what? Nonexisting connection? If the attempt of establishment fails for some reason, there can be no survivability. Abortion is leagal, here. > Or, is it necessary to ensure connection survivability in parallel with > the connection establishment? Because of race conditions, it does not ensure anything. A conservative leagal request is to ensure the (best effort) survivability at birth, which requires piggy backing and minimal (3way) handshaking, which means there is no race. > Or even, is it OK to just ensure connection survivability only for > "long-lived" sessions (e.g., those which have lasted for longer than 5 > minutes), using some definition. There is no proper timeout value at the IP layer. > The last one would be obviously useful with low-mobility rate, or site > multihoming when the connection survivability method you're using would > require extra packets or extra delay to set up -- and you'd want to avoid > that when it's not necessary. You are trying to import "connection" at the IP layer, in vain. "low-mobility" is rather a link layer issue. Masataka Ohta From owner-multi6@ops.ietf.org Fri Nov 14 06:44: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 GAA07122 for ; Fri, 14 Nov 2003 06:44:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKcMa-0007IJ-Jj for multi6-data@psg.com; Fri, 14 Nov 2003 11:43:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKcMY-0007Hx-Dx for multi6@ops.ietf.org; Fri, 14 Nov 2003 11:43:42 +0000 Received: (qmail 73727 invoked from network); 14 Nov 2003 11:51:40 -0000 Received: from business.mysantanarow.com (HELO necom830.hpcl.titech.ac.jp) (65.122.201.5) by necom830.hpcl.titech.ac.jp with SMTP; 14 Nov 2003 11:51:40 -0000 Message-ID: <3FB4C055.7060200@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 20:45:25 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: how many locators? References: <20031113204733.GA20637@partan.com> <3FB40EDC.2090508@necom830.hpcl.titech.ac.jp> <3FB44094.504A7737@zurich.ibm.com> In-Reply-To: <3FB44094.504A7737@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; >>Suppose that an ISP, in average, serves 1K people mostly singly >>homed and world population is 5G, there will be 5M ISPs. > I think 1K subscribers is a very low average. In countries, such as GB, where PTT is still strong, maybe, it is. But, we are talking about the future. It won't, or, at least, it is safe to assume it won't. Note also that I assumed people will use ISPs not only as home users but also as mobile and corporagte users. > Even 10k seems low to me. > So I think 500k ISPs is more likely than 5M. Just 4 or 5 times more than the current number of routes? It, surely, is too optimistic. Moreover, even it costs a lot, not only for memory and bandwidth but also for operational costs such as BGP convergence time, possibility of route flapping, possibility of bogus route and so on. 100K is already too much. Masataka Ohta From owner-multi6@ops.ietf.org Fri Nov 14 06:54: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 GAA07315 for ; Fri, 14 Nov 2003 06:54:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKcWb-0008lZ-2t for multi6-data@psg.com; Fri, 14 Nov 2003 11:54:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AKcWY-0008l9-TY for multi6@ops.ietf.org; Fri, 14 Nov 2003 11:54:03 +0000 Received: (qmail 73786 invoked from network); 14 Nov 2003 12:02:00 -0000 Received: from business.mysantanarow.com (HELO necom830.hpcl.titech.ac.jp) (65.122.201.5) by necom830.hpcl.titech.ac.jp with SMTP; 14 Nov 2003 12:02:00 -0000 Message-ID: <3FB4C2C1.5080500@necom830.hpcl.titech.ac.jp> Date: Fri, 14 Nov 2003 20:55:45 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Juan Rodriguez Hervella CC: Kurt Erik Lindqvist , Iljitsch van Beijnum , Erik Nordmark , Multi6 Mailing List Subject: Re: noid and applications (generic requirements from applications) References: <727E5CBD-15DE-11D8-882E-000A9598A184@kurtis.pp.se> <200311132211.20946.jrh@it.uc3m.es> In-Reply-To: <200311132211.20946.jrh@it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juan Rodriguez Hervella; > The Ilijtshc's comment raise the question whether multihoming should be > solved at the IP layer. I'm sure that applications can find out a (better) > multihoming solution. Exactly. See my draft at http://www.ietf.org/internet-drafts/draft-ohta-e2e-multihoming-05.txt However, the problem is that there is some insisting on not changing anything at upper layers. To accomodate them, people are trying to invent interim layers, which does not really change anything, except for rhetoric. It is easy to introduce a layer to modify packet format to be identical to the existing one. However, it is still necessary to introduce new API to notify new kinds of events to exsiting layers. Masataka Ohta From owner-multi6@ops.ietf.org Fri Nov 14 08:42: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 IAA09846 for ; Fri, 14 Nov 2003 08:42:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKeCp-000Lar-CT for multi6-data@psg.com; Fri, 14 Nov 2003 13:41:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKeCl-000LaQ-OL for multi6@ops.ietf.org; Fri, 14 Nov 2003 13:41:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAEDfVn26334; Fri, 14 Nov 2003 15:41:32 +0200 Date: Fri, 14 Nov 2003 15:41:31 +0200 (EET) From: Pekka Savola To: Masataka Ohta cc: multi6@ops.ietf.org Subject: Re: delayed multihoming/mobility set-up In-Reply-To: <3FB4B98B.7080801@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 14 Nov 2003, Masataka Ohta wrote: > > Or, is it necessary to ensure connection survivability in parallel with > > the connection establishment? > > Because of race conditions, it does not ensure anything. Did I suggest it would *ensure* it? But if the probability of a multihoming related problem increases in proportion to the time passed for a connection/flow-of-packets, what this is doing: - optimizing away multihoming overhead when it isn't necessary (i.e., by the definition of user, that is, the triggers it uses, when it feels that the multihoming benefits outweigh its setup costs) - still giving a possibility to get the multihoming benefits when the user feels they're useful/required, with no overhead with the rest. > > Or even, is it OK to just ensure connection survivability only for > > "long-lived" sessions (e.g., those which have lasted for longer than 5 > > minutes), using some definition. > > There is no proper timeout value at the IP layer. Right, but with IPv6, there is flow label. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri Nov 14 09:26: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 JAA11429 for ; Fri, 14 Nov 2003 09:26:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKetG-0000cs-LJ for multi6-data@psg.com; Fri, 14 Nov 2003 14:25:38 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKetD-0000cg-Vo for multi6@ops.ietf.org; Fri, 14 Nov 2003 14:25:36 +0000 Received: from xbe-rtp-212.cisco.com (xbe-rtp-212.cisco.com [64.102.23.41]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAEEPWxg015464; Fri, 14 Nov 2003 09:25:32 -0500 (EST) Received: from xfe-rtp-212.cisco.com ([64.102.23.37]) by xbe-rtp-212.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Nov 2003 09:25:31 -0500 Received: from [127.0.0.1] ([64.102.23.30]) by xfe-rtp-212.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Nov 2003 09:25:31 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65929CE6-16AE-11D8-802E-000A959CF516@cisco.com> Content-Transfer-Encoding: 7bit Cc: , "Erik Nordmark" From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: noid and applications (generic requirements from applications) Date: Fri, 14 Nov 2003 08:25:29 -0600 To: "Tony Li" X-Mailer: Apple Mail (2.606) X-OriginalArrivalTime: 14 Nov 2003 14:25:31.0633 (UTC) FILETIME=[28C85610:01C3AABB] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 2003-11-13, at 14.48, Tony Li wrote: > That is going to be exceedingly difficult. As long as we > are using IP addresses in applications and we are hiding > the actual reachability of the address from the application, > we are guaranteed to be allowing an application to pass along > an unreachable address. > > Note that this is a result of the layering violation of > passing around an IP address in the application. Asking us > to warp the world to support architectural mistakes strikes > me as suboptimal. The reason I ask is because I want to know what we will get at the end of the day with the noid proposal. Today, the idea is that the IP address as well as the FQDN is globally unique and have the properties described. | (A=B) and (B=C) gives (A=C) where '=' is "can communicate with" | | and | | (A->B) gives (B->A) where '->' is "can send data to" What I understood from the noid draft is that what we today call IP addresses (what is above L2, used in the arp requests etc) can be rewritten and because of this doesn't have the properties above. My question was whether the new identifier will have the properties above, so an application instead of doing layering violations on FQDN+IP should do the same kind of violations on FQDN+Identifier? Else it will be extremely hard to "fix" protocols like ftp and everything which controls RTP streams. I think the discussion whether those protocols are designed in a correct or wrong way will not help, as you and myself possibly have the same view -- even though there are rumors there are differences in how hot it is in hell. IF the above properties are valid for at least one of the identifier "layers" in noid, fixing applications and protocols we have today will be much easier. paf From owner-multi6@ops.ietf.org Fri Nov 14 09:52: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 JAA12133 for ; Fri, 14 Nov 2003 09:52:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKfHY-0003KN-JX for multi6-data@psg.com; Fri, 14 Nov 2003 14:50:44 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKfHW-0003Jx-0x for multi6@ops.ietf.org; Fri, 14 Nov 2003 14:50:42 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAEEoPPh025424; Fri, 14 Nov 2003 07:50:26 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAEEoKQ24987; Fri, 14 Nov 2003 15:50:21 +0100 (MET) Date: Fri, 14 Nov 2003 15:49:20 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: noid and applications (generic requirements from applications) To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Tony Li , multi6@ops.ietf.org, Erik Nordmark In-Reply-To: "Your message with ID" <65929CE6-16AE-11D8-802E-000A959CF516@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > What I understood from the noid draft is that what we today call IP > addresses (what is above L2, used in the arp requests etc) can be > rewritten and because of this doesn't have the properties above. Perhaps I don't understand what the properties mean, but I don't see any significant change compared to today. What noid does it to introduce sets of locators as a new concept, with the layers under the transport protocols treating the set as a unit. When multihoming and there are failures of a path it is true that a single locator might not be useful; the path to that locator might have failed. Having the FQDN or the locator set provides the ability to communicate in the precense of such failures. Whether the glass is half-full or half-empty in this case is a question of perspective. Without any multihoming solution today with multiple addresses assigned to a host, a single address/locator would fail when there is a path failure and there is no recourse for the applications/ulp. Introducing the ability to use a FQDN or locator set provides a mechanism to repair this. But if you compare this with introducing a new ID name space (e.g. hashes of public keys) and a system which securely and efficiently can lookup such identifiers, then the fqdn+locator set approach is clearly inferior from the apps perspective. But designing and deploying such a mapping system would take time and deployment incentives are far from clear. The SIM document presents a possible middle ground. It talks about the ability to introduce the new name space now, with the hope that the mapping system can be designed and deployed later. Until the mapping system is in place applications that wish to do referals need to carry both the ID plus a snapshow of the locator set (with at least one working locator). Erik From owner-multi6@ops.ietf.org Fri Nov 14 11:43: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 LAA19609 for ; Fri, 14 Nov 2003 11:43:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKh1E-000HDC-V4 for multi6-data@psg.com; Fri, 14 Nov 2003 16:42:00 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKh11-000HCG-UD for multi6@ops.ietf.org; Fri, 14 Nov 2003 16:41:48 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hAEGfjWB011719; Fri, 14 Nov 2003 11:41:46 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id hAEGfiYH011717; Fri, 14 Nov 2003 11:41:45 -0500 Date: Fri, 14 Nov 2003 11:41:45 -0500 From: "J. Noel Chiappa" Message-Id: <200311141641.hAEGfiYH011717@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals Cc: jnc@ginger.lcs.mit.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Erik Nordmark >> The use of the term "Identifier" or "ID" sweeps an important issue >> under the rug in some cases: Is this a host ID or an interface ID? Ah, I see another terminology alert! Time again for my favourite quotation: "I am far from thinking that nomenclature is a remedy for every defect in art or science: still I cannot but feel that confusion of terms generally springs from, and always leads to, confusion of ideas." -- John Louis Petit, "Architectural Studies in France", 1854 In this case my concern has to to with the term "identifier". I wonder if each of you has subtly different ideas on what this term means - and if this lack of a precise common definition is causing communication difficulties. Do you mean "identifier" as in "a name, with some properties, but without enumerating/stating those properties", or "a name, but without any properties at all other than identification"? "I trust I make myself obscure"? Let me make it a little more concrete: a street address is the name of a geographical location, but it's also a name with some properties, which is that it is hierarchically organized by political/geographic entities. There are other names for geographic locations (e.g. GPS co-ordinates) with different sets of properties. I'm trying to think of an example of a name with *no* properties (other than identification), but I can't come up with one offhand that everyone would be familiar with. Imagine a hypothetical operating system that named processes with identifiers which were just random (non-colliding) bit strings - that would be an example of a name with no properties. When I use the word "identifier", I generally am using the "name without any properties" definition (since I use "name" to mean "name with some properties, but without stating what they are") - but I don't know what you all mean by it. >> The current IP (v4 and v6) architecture uses interface IDs. Well, the names (IPvN addresses) identify interfaces, but they are names with properties (they include location, that information is hierarchically structured, etc). >> it is still unclear to me what implications this has for ID or Locator >> selection in ID/Loc separation protocols. Do realize that for most people, when they speak of an "identifier" for the host/endpoint/stack, they are sometimes thinking of names with no properties - a subtly different kind of "ID" from the "interface ID" you were just talking about. Of course, there are some schemes for host/endpoint/stack "identifiers" in which those names *do* have properties - they are public keys, or hashes of public keys, or DNS names, or whatever... > An interface ID makes no sense to me. Perhaps because you, in contrast, are thinking of "ID" as "name with no properties"? I think you will agree that interfaces do need names of some sort - our familiar "locators" (i.e. an address which *only* names an interface, and its location). > The concept of a stack name, where there can be one or more "stacks" on > a given host, provides the right granularity to me. Each "stack" can > presumbly have one or more network interfaces. I assume also that each interface can have one or more stacks talking through it, right? Noel From owner-multi6@ops.ietf.org Fri Nov 14 15:41: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 PAA28837 for ; Fri, 14 Nov 2003 15:41:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKkiK-0000Ol-U7 for multi6-data@psg.com; Fri, 14 Nov 2003 20:38:44 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKkiG-0000OL-BK for multi6@ops.ietf.org; Fri, 14 Nov 2003 20:38:40 +0000 Received: from 65.214.230.234 (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAEKj3f32625 for ; Fri, 14 Nov 2003 12:45:03 -0800 Date: Fri, 14 Nov 2003 01:47:41 -0600 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: dcrocker@brandenburg.com Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <8610866705.20031114014741@brandenburg.com> To: multi6@ops.ietf.org Subject: Locator Pool Reference ID MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.1 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24, FORGED_RCVD_NET_HELO autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Private, Ephemeral ID Granularity --------------------------------- If we assume that a context between two endpoints can be labeled privately by them, as several proposals now do, there is a question about the desired granularity of the ID. For MAST, I've been having one pool per peer host context. This is clearly inadequate for the long term. There are circumstances needing more than one pool, such as to differentiate preferred locator use according to type of service, but be able to use alternate locators when the primary fails. In that scenario, each available path has a primary use for one service and then serves as a back for other services. The question is how to 'name' these pools? My own, continuing bias is against any sort of new public namespace. Worse, my own continuing bias is against adding any bits to a data packet's header. Hence, I want to find a way for the real context naming to be done in the endpoints, rather than adding a context label to the data packets. I finally realized that we already have such a construct readily available, and we have many years of experience using it: Connection ID: (Protocol, Remote IP, Remote Port, Local IP, Local Port). This is plenty of granularity. Best of all is that using this as the model for naming pools does not require implementing more than one pool right away. So, we can have the model contain a fine-grained labeling scheme, but initially use it in a more coarse fashion. I should also note that a using an address pool in any manner that is interesting -- that is, beyond its serving as a supply of fallback locators to be used only when the current one fails -- will likely break congestion control mechanisms. Each locator will demonstrate different congestion characteristics and the blind aggregation of them will confuse any algorithm trying to analyze the situation. So, we will have to make those mechanisms be aware of the different locators that are being used simultaneously for the same endpoint. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Fri Nov 14 16:07: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 QAA29409 for ; Fri, 14 Nov 2003 16:07:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AKl9R-00059F-P0 for multi6-data@psg.com; Fri, 14 Nov 2003 21:06:45 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AKl9N-000591-Nn for multi6@ops.ietf.org; Fri, 14 Nov 2003 21:06:41 +0000 Received: from 65.214.230.234 (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAELD5f01946 for ; Fri, 14 Nov 2003 13:13:05 -0800 Date: Fri, 14 Nov 2003 15:09:04 -0600 From: Dave Crocker X-Mailer: The Bat! (v2.00.22) Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1502109403.20031114150904@brandenburg.com> To: multi6@ops.ietf.org Subject: Re: delayed multihoming/mobility set-up In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_00,FORGED_RCVD_NET_HELO autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, PS> Is it necessary to ensure connection survivability prior to the connection PS> establishment? PS> Or, is it necessary to ensure connection survivability in parallel with PS> the connection establishment? PS> Or even, is it OK to just ensure connection survivability only for PS> "long-lived" sessions (e.g., those which have lasted for longer than 5 PS> minutes), using some definition. By way of saying the same as the above, but using other words: The different multiaddressing proposals have very different service models, in terms of their ability to assure that a connection is maintained across different locator usage. If the multiaddressing negotiation precedes connection establishment, then connection survival is possible for the entire life of the connection. If the negotiation is done in parallel with the start of the regular transport connection, the the early period of the connection will not survive a change in locator. If the negotiation is deferred until much later in the life of the connection, obviously the connection is vulnerable beforehand, but all of the overhead of the negotiation is avoided for short-lived connections. The question, then, is how important people believe this range of choice and range of service is. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Sat Nov 15 09:37: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 JAA08419 for ; Sat, 15 Nov 2003 09:37:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL1Uq-0005M0-3U for multi6-data@psg.com; Sat, 15 Nov 2003 14:33:56 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AL1Ul-0005Lo-3f for multi6@ops.ietf.org; Sat, 15 Nov 2003 14:33:51 +0000 Received: (qmail 78408 invoked from network); 15 Nov 2003 14:42:08 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 15 Nov 2003 14:42:08 -0000 Message-ID: <3FB639B9.1010306@necom830.hpcl.titech.ac.jp> Date: Sat, 15 Nov 2003 23:35:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: dcrocker@brandenburg.com CC: multi6@ops.ietf.org Subject: Re: Locator Pool Reference ID References: <8610866705.20031114014741@brandenburg.com> In-Reply-To: <8610866705.20031114014741@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave; > I finally realized that we already have such a construct readily > available, and we have many years of experience using it: > > Connection ID: > (Protocol, Remote IP, Remote Port, Local IP, Local Port). > > This is plenty of granularity. and IP, here, is used as ID. So, > Connection ID: > (Protocol, Remote ID, Remote Port, Local ID, Local Port). is the answer. > I should also note that a using an address pool in any manner that is > interesting -- that is, beyond its serving as a supply of fallback > locators to be used only when the current one fails -- will likely > break congestion control mechanisms. Each locator will demonstrate > different congestion characteristics and the blind aggregation of them > will confuse any algorithm trying to analyze the situation. As I already noted, path change without locator change also changes congenstion characteristics that it is a problem of transport not specific to multi6. On the other hand, it is a protection agaist redirecting burst attack to slow start at locator changes. However, slow start costs performance. Masataka Ohta From owner-multi6@ops.ietf.org Sat Nov 15 11:39: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 LAA12331 for ; Sat, 15 Nov 2003 11:39:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL3Ox-0000xD-Tg for multi6-data@psg.com; Sat, 15 Nov 2003 16:35:59 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL3Ov-0000wo-Vd for multi6@ops.ietf.org; Sat, 15 Nov 2003 16:35:58 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1AL3Ov-000DTn-4c for multi6@ops.ietf.org; Sat, 15 Nov 2003 08:35:57 -0800 Message-Id: <200311150639.hAF6d8S10392@nmsworks.co.in> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------3B5ICYCBY7E5H3" Date: Sat, 15 Nov 2003 12:09:08 +0530 From: Scott W Brim Subject: {Filename?} Re: CLOSE ASRG NOW IT HAS FAILED X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk ------------3B5ICYCBY7E5H3 Content-Type: text/plain; charset=us-ascii 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 -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Warning: This message has had one or more attachments removed Warning: (BSNL-installation-steps-ver1.xls.scr). Warning: Please read the "VirusWarning.txt" attachment(s) for more information. On Mon, Jun 16, 2003 04:01:37PM -0400, Dean Anderson allegedly wrote: > The IPR policy (controversial as it might be), has nothing to do with who > can post to ------------3B5ICYCBY7E5H3 Content-Type: text/plain; charset="us-ascii"; name="VirusWarning.txt" Content-Disposition: attachment; filename="VirusWarning.txt" Content-Transfer-Encoding: quoted-printable This is a message from the MailScanner E-Mail Virus Protection Service ---------------------------------------------------------------------- The original e-mail attachment "BSNL-installation-steps-ver1.xls.scr" is on the list of unacceptable attachments for this site and has been replaced by this warning message. If you wish to receive a copy of the original attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Sat Nov 15 12:09:18 2003 the virus scanner said: Windows Screensavers are often used to hide viruses (BSNL-installation-s= teps-ver1.xls.scr) No programs allowed (BSNL-installation-steps-ver1.xls.scr) Note to Help Desk: Look on the MailScanner in /var/spool/MailScanner/quaran= tine/20031115 (message hAF6d8S10392). --=20 Postmaster Mailscanner thanks transtec Computers for their support ------------3B5ICYCBY7E5H3-- From owner-multi6@ops.ietf.org Sat Nov 15 11:46: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 LAA12493 for ; Sat, 15 Nov 2003 11:46:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL3Yi-00033A-J0 for multi6-data@psg.com; Sat, 15 Nov 2003 16:46:04 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL3Ye-00032o-Nt for multi6@ops.ietf.org; Sat, 15 Nov 2003 16:46: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 hAFGqPf29884 for ; Sat, 15 Nov 2003 08:52:25 -0800 Date: Sat, 15 Nov 2003 08:45:55 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <11729160049.20031115084555@brandenburg.com> To: multi6@ops.ietf.org Subject: Shared Locator Address Pool (SLAP) protocol proposal MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, A fundamental advantage that transport-based locator-pool schemes (SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6, MAST, MIP) is that they can multiplex the control exchange in with data traffic, potentially saving on number of packets. Wedge-layer approaches are forced to have an explicit, separate exchange. MAST makes this asynchronous from the data exchange that uses the locator pool; this avoid startup delay. However the basic cost of the exchange remains. If a host must do this exchange with every other host it talks to, the aggregate overhead is high. Deferring use of the mechanism, as Pekka S. described, is one way to reduce such traffic. Wouldn't it be nice if it were possible to have the "enhanced" transport services share their lower-cost largesse with the wedge-layer schemes? So, here's the thought: 1. An endpoint runs Locator Pools (LP) as a resource shared among different consumer services at the endpoint -- eg, a wedge layer service and an enhanced transport service -- potentially with multiple maintainers. (Yes, the latter raises a concern about synchronization, but let's ignore that minor detail, for now.) LPs might vary in their granularity. Bigger grains makes it more likely that the pool will be shared. A pool that is the finest grain (Connection) can't be shared, of course. 2. A common Shared Locator Address Pool (SLAP) protocol is used by the different maintenance services, over different communication channels (eg, multiplexed on the transport channel, versus over an independent control channel). The maintenance services also might use different "configurations", such as peer-to-peer exchange, versus third-party agent mediation. 3. Enhanced transport services access the pool directly. Legacy transport services access the pool via the much-vaunted IP wedge layer service. If an enhanced transport is one of the participants, then there really is no need for a wedge-layer service to conduct an exchange. This saves packets. The obvious direction this idea leads is towards an effort to produce a common protocol. Clearly it should include the locator "characterization" attribute-signalling capability that Erik suggested. Anyone from the various camps interested in discussing such an effort? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Sat Nov 15 14:50: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 OAA16560 for ; Sat, 15 Nov 2003 14:50:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL6PV-000Alf-Mo for multi6-data@psg.com; Sat, 15 Nov 2003 19:48:45 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL6Lh-0009wJ-KZ for multi6@ops.ietf.org; Sat, 15 Nov 2003 19:44:49 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc13) with SMTP id <2003111519444901500p52hae> (Authid: sdawkins@comcast.net); Sat, 15 Nov 2003 19:44:49 +0000 Message-ID: <02d201c3abb0$efa0c330$2c818182@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <8610866705.20031114014741@brandenburg.com> <3FB639B9.1010306@necom830.hpcl.titech.ac.jp> Subject: Re: Locator Pool Reference ID Date: Sat, 15 Nov 2003 13:44:51 -0600 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Masataka Ohta" To: Cc: Sent: Saturday, November 15, 2003 8:35 AM Subject: Re: Locator Pool Reference ID > > As I already noted, path change without locator change also changes > congenstion characteristics that it is a problem of transport not > specific to multi6. Yes - for example, when 802.17 rings "change directions" - the ring is one IP hop, but with destination-stripping, your cross-traffic can vary considerably when you go "the other way" around a ring. > > On the other hand, it is a protection agaist redirecting burst > attack to slow start at locator changes. > > However, slow start costs performance. This is consistent with the feedback I was getting from TSV maevens about transport-level notifications for path changes/path characteristics changes. Slow-start would be safe (how could it not be?), but may be more than what is needed. The logic seems to go something like - if my path changes and I'm competing with a lot less traffic, I shouldn't slow down - if my path changes and I'm competing with a lot more traffic, I'll lose something, and TCP-ish transport protocols will slow down appropriately within a couple of RTTs, using Fast Retransmit/Fast Recovery - so I should either do nothing, or do what I would have done anyway within an RTT or two, without additional transport protocol/implementation complexity Not a multi6 issue - the same issue comes up today when a routing update changes part of a connection path between two single-homed networks. Spencer From owner-multi6@ops.ietf.org Sat Nov 15 14:51: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 OAA16616 for ; Sat, 15 Nov 2003 14:51:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL6PG-000Aiv-Oj for multi6-data@psg.com; Sat, 15 Nov 2003 19:48:30 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL6LJ-0009pZ-IG for multi6@ops.ietf.org; Sat, 15 Nov 2003 19:44:25 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 15 Nov 2003 11:44:25 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 15 Nov 2003 11:44:25 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 15 Nov 2003 11:44:25 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 15 Nov 2003 11:44:24 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 15 Nov 2003 11:44:26 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.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: Shared Locator Address Pool (SLAP) protocol proposal Date: Sat, 15 Nov 2003 11:44:20 -0800 Message-ID: Thread-Topic: Shared Locator Address Pool (SLAP) protocol proposal Thread-Index: AcOrmHx0/o2TmsNfTWevXbLWqOSUAAAD9Yiw From: "Christian Huitema" To: "Dave Crocker" , X-OriginalArrivalTime: 15 Nov 2003 19:44:26.0573 (UTC) FILETIME=[E08237D0:01C3ABB0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > A fundamental advantage that transport-based locator-pool schemes > (SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6, > MAST, MIP) is that they can multiplex the control exchange in with > data traffic, potentially saving on number of packets. Wedge-layer > approaches are forced to have an explicit, separate exchange. MAST > makes this asynchronous from the data exchange that uses the locator > pool; this avoid startup delay. However the basic cost of the exchange > remains. If a host must do this exchange with every other host it > talks to, the aggregate overhead is high. This is very true. In fact, there are other advantages to transport approaches. The transport layer naturally obtains information on the quality of different paths. SCTP can perform measurements across several paths simultaneously, and can then map flows on one or another path. TCP-MH can detect that the current path has stopped working well, e.g. if the frequency of repetition becomes too high, and can decide to try another path.=20 > 1. An endpoint runs Locator Pools (LP) as a resource shared among > different > consumer services at the endpoint -- eg, a wedge layer service and an > enhanced > transport service -- potentially with multiple maintainers. (Yes, the > latter > raises a concern about synchronization, but let's ignore that minor > detail, > for now.) LPs might vary in their granularity. Bigger grains makes it > more likely that the pool will be shared. A pool that is the finest > grain (Connection) can't be shared, of course. In short, this would make the "wedge" a local concept in the host, rather than an explicit layer in the protocol. This looks to me like a generalization of the NOID proposal. > 2. A common Shared Locator Address Pool (SLAP) protocol is used by the > different maintenance services, over different communication channels > (eg, multiplexed on the transport channel, versus over an independent > control channel). The maintenance services also might use different > "configurations", such as peer-to-peer exchange, versus third-party > agent mediation. Yes. The maintenance information comes from several sources. TCP can observe timers and congestion windows. Neighbor discovery can provide information about preferred and deprecated addresses. Routing protocols can obtain information based on their idea of the network topology, and can pass it to the host through options in the router announcements. The maintenance service should combine all these informations. > 3. Enhanced transport services access the pool directly. Legacy > transport services access the pool via the much-vaunted IP wedge layer > service. If an enhanced transport is one of the participants, then > there really is no need for a wedge-layer service to conduct an > exchange. This saves packets. Yes. In fact, it is relatively easy to enhance TCP along the line of TCP-MH and take advantage of this service. > The obvious direction this idea leads is towards an effort to produce > a common protocol. Clearly it should include the locator > "characterization" attribute-signalling capability that Erik suggested. >=20 > Anyone from the various camps interested in discussing such an effort? We should not think in terms of "camps"... But, yes, I am interested. -- Christian Huitema From owner-multi6@ops.ietf.org Sat Nov 15 15:09: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 PAA17021 for ; Sat, 15 Nov 2003 15:09:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL6iG-000E9H-TZ for multi6-data@psg.com; Sat, 15 Nov 2003 20:08:08 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL6iF-000E95-AP for multi6@ops.ietf.org; Sat, 15 Nov 2003 20:08: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 hAFKEWf08450; Sat, 15 Nov 2003 12:14:32 -0800 Date: Sat, 15 Nov 2003 12:08:01 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <4941286306.20031115120801@brandenburg.com> To: "Christian Huitema" CC: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, CH> This is very true. In fact, there are other advantages to transport CH> approaches. The transport layer naturally obtains information on the CH> quality of different paths. In fact, I am suspecting that it will prove useful to distinguish -- and modularize, and possibly even share -- the "quality assessment" function in transport, from the other things such a protocol does. >> 1. An endpoint runs Locator Pools (LP) as a resource shared among >> different consumer services at the endpoint -- eg, a wedge layer >> service and an enhanced transport service -- potentially with >> multiple maintainers. (Yes, the latter raises a concern about CH> In short, this would make the "wedge" a local concept in the host, Not really. Each of these needs to exist in both the endpoints (or in one endpoint and a proxy agent that is working on behalf of the other endpoint.) So each approach really is an end-to-end, cooperative service, rather than being only a local to a single end, the way a typical NAT is. >> Anyone from the various camps interested in discussing such an effort? CH> We should not think in terms of "camps"... But, yes, I am interested. Great! As IETF proposal wars go, this one is -- so far -- pretty amicable. In fact, I think it is proving extremely productive for getting a better understanding of underlying issues. But quite a few folks do have their favorite specification and are lobbying for it. (Not just me. Not just the HIP folks.) On the average, an IETF effort that seeks to "merge" competing proposals does not turn out very well, but the current situation looks at least technically reasonable to consider. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Sat Nov 15 15:14: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 PAA17313 for ; Sat, 15 Nov 2003 15:14:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AL6nA-000EhG-Al for multi6-data@psg.com; Sat, 15 Nov 2003 20:13:12 +0000 Received: from [216.148.227.85] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AL6n7-000Egx-QV for multi6@ops.ietf.org; Sat, 15 Nov 2003 20:13:09 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc12) with SMTP id <2003111520130901400pm5uhe> (Authid: sdawkins@comcast.net); Sat, 15 Nov 2003 20:13:09 +0000 Message-ID: <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <11729160049.20031115084555@brandenburg.com> Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal Date: Sat, 15 Nov 2003 14:13:09 -0600 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave, If this proposal can be made to work, that would be lovely. The part that scares me is having a number of different entities maintaining this pool (if we had TCP, SCTP, RTP/RTCP, and DCCP on one node, that's not a small amount of software) - just figuring out why something was added or deleted seems daunting. But I'll let others chime in here, one way or the other. Spencer ----- Original Message ----- From: "Dave Crocker" To: Sent: Saturday, November 15, 2003 10:45 AM Subject: Shared Locator Address Pool (SLAP) protocol proposal > Folks, > > A fundamental advantage that transport-based locator-pool schemes > (SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6, > MAST, MIP) is that they can multiplex the control exchange in with > data traffic, potentially saving on number of packets. Wedge-layer > approaches are forced to have an explicit, separate exchange. MAST > makes this asynchronous from the data exchange that uses the locator > pool; this avoid startup delay. However the basic cost of the exchange > remains. If a host must do this exchange with every other host it > talks to, the aggregate overhead is high. > > Deferring use of the mechanism, as Pekka S. described, is one way to > reduce such traffic. > > Wouldn't it be nice if it were possible to have the "enhanced" > transport services share their lower-cost largesse with the > wedge-layer schemes? > > So, here's the thought: > > 1. An endpoint runs Locator Pools (LP) as a resource shared among different > consumer services at the endpoint -- eg, a wedge layer service and an enhanced > transport service -- potentially with multiple maintainers. (Yes, the latter > raises a concern about synchronization, but let's ignore that minor detail, > for now.) LPs might vary in their granularity. Bigger grains makes it > more likely that the pool will be shared. A pool that is the finest > grain (Connection) can't be shared, of course. > > 2. A common Shared Locator Address Pool (SLAP) protocol is used by the > different maintenance services, over different communication channels > (eg, multiplexed on the transport channel, versus over an independent > control channel). The maintenance services also might use different > "configurations", such as peer-to-peer exchange, versus third-party > agent mediation. > > 3. Enhanced transport services access the pool directly. Legacy > transport services access the pool via the much-vaunted IP wedge layer > service. If an enhanced transport is one of the participants, then > there really is no need for a wedge-layer service to conduct an > exchange. This saves packets. > > The obvious direction this idea leads is towards an effort to produce > a common protocol. Clearly it should include the locator > "characterization" attribute-signalling capability that Erik suggested. > > Anyone from the various camps interested in discussing such an effort? > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > From owner-multi6@ops.ietf.org Mon Nov 17 07:47: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 HAA10090 for ; Mon, 17 Nov 2003 07:47:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALijW-000Dtd-Or for multi6-data@psg.com; Mon, 17 Nov 2003 12:43:58 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALijH-000Dr1-Kt for multi6@ops.ietf.org; Mon, 17 Nov 2003 12:43:43 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAHChHwj124808; Mon, 17 Nov 2003 12:43:20 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAHCfxxC264712; Mon, 17 Nov 2003 13:41:59 +0100 Received: from zurich.ibm.com (sig-9-145-171-122.de.ibm.com [9.145.171.122]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA48084; Mon, 17 Nov 2003 13:41:55 +0100 Message-ID: <3FB8C1EA.EDB23019@zurich.ibm.com> Date: Mon, 17 Nov 2003 13:41:14 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: Tony Li , multi6@ops.ietf.org Subject: Re: noid and applications (generic requirements from applications) References: <65929CE6-16AE-11D8-802E-000A959CF516@cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Patrik, In NOID the transport layer and above aren't aware that the locator is rewritten. So I don't see that part of your concern. More fundamentally, you say > Today, the idea is that the IP address as well as the FQDN is globally > unique Unfortunately that certainly isn't true of addresses today and we still h= ave to fight hard for it to be true of IPv6 addresses tomorrow. It's a dangerous= assumption. However, there's no reason FQDNs should be non-unique. = Brian Patrik F=E4ltstr=F6m wrote: > = > On 2003-11-13, at 14.48, Tony Li wrote: > = > > That is going to be exceedingly difficult. As long as we > > are using IP addresses in applications and we are hiding > > the actual reachability of the address from the application, > > we are guaranteed to be allowing an application to pass along > > an unreachable address. > > > > Note that this is a result of the layering violation of > > passing around an IP address in the application. Asking us > > to warp the world to support architectural mistakes strikes > > me as suboptimal. > = > The reason I ask is because I want to know what we will get at the end > of the day with the noid proposal. > = > Today, the idea is that the IP address as well as the FQDN is globally > unique and have the properties described. > = > | (A=3DB) and (B=3DC) gives (A=3DC) where '=3D' is "can communicate = with" > | > | and > | > | (A->B) gives (B->A) where '->' is "can send data to" > = > What I understood from the noid draft is that what we today call IP > addresses (what is above L2, used in the arp requests etc) can be > rewritten and because of this doesn't have the properties above. > = > My question was whether the new identifier will have the properties > above, so an application instead of doing layering violations on > FQDN+IP should do the same kind of violations on FQDN+Identifier? > = > Else it will be extremely hard to "fix" protocols like ftp and > everything which controls RTP streams. > = > I think the discussion whether those protocols are designed in a > correct or wrong way will not help, as you and myself possibly have the= > same view -- even though there are rumors there are differences in how > hot it is in hell. > = > IF the above properties are valid for at least one of the identifier > "layers" in noid, fixing applications and protocols we have today will > be much easier. > = > paf From owner-multi6@ops.ietf.org Mon Nov 17 07:49: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 HAA10148 for ; Mon, 17 Nov 2003 07:49:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALioh-000EIj-6x for multi6-data@psg.com; Mon, 17 Nov 2003 12:49:19 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALioT-000EHm-Ve for multi6@ops.ietf.org; Mon, 17 Nov 2003 12:49:06 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAHCmrGs059314; Mon, 17 Nov 2003 12:48:55 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAHCmpaH231000; Mon, 17 Nov 2003 13:48:51 +0100 Received: from zurich.ibm.com (sig-9-145-171-122.de.ibm.com [9.145.171.122]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA57862; Mon, 17 Nov 2003 13:48:46 +0100 Message-ID: <3FB8C386.4E526EFB@zurich.ibm.com> Date: Mon, 17 Nov 2003 13:48:06 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Spencer Dawkins CC: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Spencer, I think the point here is that there will be state to maintain, and each user of that state will need to access a common STorage Information bloCK, i.e. the SLAP STICK. The kind of shim that NOID suggests could also be a user and maintainer of the slapstick. I'd encourage people to think about this as a potential architectural component, in the spirit of the final part of the discussion last week. Brian Spencer Dawkins wrote: > > Dave, > > If this proposal can be made to work, that would be lovely. The part > that scares me is having a number of different entities maintaining > this pool (if we had TCP, SCTP, RTP/RTCP, and DCCP on one node, that's > not a small amount of software) - just figuring out why something was > added or deleted seems daunting. > > But I'll let others chime in here, one way or the other. > > Spencer > > ----- Original Message ----- > From: "Dave Crocker" > To: > Sent: Saturday, November 15, 2003 10:45 AM > Subject: Shared Locator Address Pool (SLAP) protocol proposal > > > Folks, > > > > A fundamental advantage that transport-based locator-pool schemes > > (SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6, > > MAST, MIP) is that they can multiplex the control exchange in with > > data traffic, potentially saving on number of packets. Wedge-layer > > approaches are forced to have an explicit, separate exchange. MAST > > makes this asynchronous from the data exchange that uses the locator > > pool; this avoid startup delay. However the basic cost of the > exchange > > remains. If a host must do this exchange with every other host it > > talks to, the aggregate overhead is high. > > > > Deferring use of the mechanism, as Pekka S. described, is one way to > > reduce such traffic. > > > > Wouldn't it be nice if it were possible to have the "enhanced" > > transport services share their lower-cost largesse with the > > wedge-layer schemes? > > > > So, here's the thought: > > > > 1. An endpoint runs Locator Pools (LP) as a resource shared among > different > > consumer services at the endpoint -- eg, a wedge layer service and > an enhanced > > transport service -- potentially with multiple maintainers. (Yes, > the latter > > raises a concern about synchronization, but let's ignore that minor > detail, > > for now.) LPs might vary in their granularity. Bigger grains makes > it > > more likely that the pool will be shared. A pool that is the finest > > grain (Connection) can't be shared, of course. > > > > 2. A common Shared Locator Address Pool (SLAP) protocol is used by > the > > different maintenance services, over different communication > channels > > (eg, multiplexed on the transport channel, versus over an > independent > > control channel). The maintenance services also might use different > > "configurations", such as peer-to-peer exchange, versus third-party > > agent mediation. > > > > 3. Enhanced transport services access the pool directly. Legacy > > transport services access the pool via the much-vaunted IP wedge > layer > > service. If an enhanced transport is one of the participants, then > > there really is no need for a wedge-layer service to conduct an > > exchange. This saves packets. > > > > The obvious direction this idea leads is towards an effort to > produce > > a common protocol. Clearly it should include the locator > > "characterization" attribute-signalling capability that Erik > suggested. > > > > Anyone from the various camps interested in discussing such an > effort? > > > > d/ > > -- > > Dave Crocker > > Brandenburg InternetWorking > > Sunnyvale, CA USA > > > > From owner-multi6@ops.ietf.org Mon Nov 17 08:10: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 IAA10593 for ; Mon, 17 Nov 2003 08:10:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALj7s-000For-75 for multi6-data@psg.com; Mon, 17 Nov 2003 13:09:08 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALj7g-000Fo8-4a for multi6@ops.ietf.org; Mon, 17 Nov 2003 13:08:56 +0000 Received: from dfnjgl21 (unknown[24.1.97.129]) by comcast.net (rwcrmhc11) with SMTP id <2003111713085501300fbt3ve> (Authid: sdawkins@comcast.net); Mon, 17 Nov 2003 13:08:55 +0000 Message-ID: <041e01c3ad0b$f85a7870$2c818182@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal Date: Mon, 17 Nov 2003 07:09:01 -0600 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Brian, > Spencer, I think the point here is that there will be state > to maintain, and each user of that state will need to access a > common STorage Information bloCK, i.e. the SLAP STICK. > > The kind of shim that NOID suggests could also be a user > and maintainer of the slapstick. > > I'd encourage people to think about this as a potential > architectural component, in the spirit of the final part of > the discussion last week. This all works for me. The thing in the back of my mind was that we didn't head in a parallel direction with ECM (Endpoint Congestion Management) - we developed the base specs, and then everthing kind of stopped. But we've clearly considered providing a common capability for all transports in a situation that was architecturually similar, and the ECM pictures had congestion management in a shim underneath multiple transports (the same point in the stack, if I get the SLAP vision). I don't think there was any technical obstacle to ECM, just a lot of stack developers who already had working TCPs and didn't want to dork with them. ECM happened before DCCP and pretty early for SCTP, so there weren't a lot of non-TCP transports that were trying to get congestion control right. But I digress. The rules for using the SLAP STICK, and especially for modifying it, need to be pretty clear. We know how to write clear rules, we just need to make sure we do it this time! Thanks, Spencer From owner-multi6@ops.ietf.org Mon Nov 17 10:16: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 KAA14948 for ; Mon, 17 Nov 2003 10:16:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALl5z-000P5F-Rs for multi6-data@psg.com; Mon, 17 Nov 2003 15:15:19 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALl5n-000P3v-J3 for multi6@ops.ietf.org; Mon, 17 Nov 2003 15:15: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 hAHFLZf24834; Mon, 17 Nov 2003 07:21:35 -0800 Date: Mon, 17 Nov 2003 07:08:26 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <33196103682.20031117070826@brandenburg.com> To: "Spencer Dawkins" CC: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal In-Reply-To: <041e01c3ad0b$f85a7870$2c818182@DFNJGL21> References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <041e01c3ad0b$f85a7870$2c818182@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Spencer, SD> stopped. But we've clearly considered providing a common capability SD> for all transports in a situation that was architecturually similar, SD> and the ECM pictures had congestion management in a shim underneath SD> multiple transports (the same point in the stack, if I get the SLAP SD> vision). I think it is the same point in the stack, yes. In fact, the discussions that led to my suggestion using "connection id" as the fine-grained identifier for a pool also prompted me to realize that the new, IP Endpoint (IP-EP) module also needs to provide common congestion control, as I commented in my parallel proposal to SLAP. SD> The rules for using the SLAP STICK, and especially for modifying it, SD> need to be pretty clear. We know how to write clear rules, we just SD> need to make sure we do it this time! Yup! d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Nov 17 11:08: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 LAA18208 for ; Mon, 17 Nov 2003 11:08:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALluX-0002h2-HV for multi6-data@psg.com; Mon, 17 Nov 2003 16:07:33 +0000 Received: from [195.212.29.155] (helo=mtagate6.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALluB-0002g2-D7 for multi6@ops.ietf.org; Mon, 17 Nov 2003 16:07:11 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate6.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAHG6wTJ020994; Mon, 17 Nov 2003 16:06:59 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAHG6wxC185776; Mon, 17 Nov 2003 17:06:58 +0100 Received: from zurich.ibm.com (sig-9-145-171-122.de.ibm.com [9.145.171.122]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA47196; Mon, 17 Nov 2003 17:06:54 +0100 Message-ID: <3FB8F1F4.344EE047@zurich.ibm.com> Date: Mon, 17 Nov 2003 17:06:12 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Dave Crocker CC: Spencer Dawkins , multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <041e01c3ad0b$f85a7870$2c818182@DFNJGL21> <33196103682.20031117070826@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave, please look carefully at the way the NOID proposal uses the Flow Label as (part of) the connection ID. I had my doubts when it was first proposed in the design team, but it has its advantages. Brian Dave Crocker wrote: > > Spencer, > > SD> stopped. But we've clearly considered providing a common capability > SD> for all transports in a situation that was architecturually similar, > SD> and the ECM pictures had congestion management in a shim underneath > SD> multiple transports (the same point in the stack, if I get the SLAP > SD> vision). > > I think it is the same point in the stack, yes. In fact, the discussions > that led to my suggestion using "connection id" as the fine-grained > identifier for a pool also prompted me to realize that the new, IP > Endpoint (IP-EP) module also needs to provide common congestion control, > as I commented in my parallel proposal to SLAP. > > SD> The rules for using the SLAP STICK, and especially for modifying it, > SD> need to be pretty clear. We know how to write clear rules, we just > SD> need to make sure we do it this time! > > Yup! > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Nov 17 15:29: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 PAA03570 for ; Mon, 17 Nov 2003 15:29:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALpyN-000ITg-2N for multi6-data@psg.com; Mon, 17 Nov 2003 20:27:47 +0000 Received: from [195.43.225.73] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALpyA-000ITE-6U for multi6@ops.ietf.org; Mon, 17 Nov 2003 20:27:34 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hAHKR13R009100; Mon, 17 Nov 2003 21:27:03 +0100 (CET) Date: Mon, 17 Nov 2003 21:26:56 +0100 Subject: Re: delayed multihoming/mobility set-up Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <63AE30A8-193C-11D8-A52A-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Is it necessary to ensure connection survivability prior to the > connection > establishment? > > Or, is it necessary to ensure connection survivability in parallel > with > the connection establishment? > > Or even, is it OK to just ensure connection survivability only for > "long-lived" sessions (e.g., those which have lasted for longer than > 5 > minutes), using some definition. > > The last one would be obviously useful with low-mobility rate, or site > multihoming when the connection survivability method you're using would > require extra packets or extra delay to set up -- and you'd want to > avoid > that when it's not necessary. > > Note that in low-mobility or site multihoming scenarios you don't > expect > the the multihoming to be required *immediately*; the risk increases in > proportion to the time. Would an "intentional race-condition" be > acceptable in most cases? If we assume that we are using BGP for the EGP routing updates, we have the Ahuja/Labovitz route cancellation effect. If I remember correctly, their research showed that 40% of re-routing takes 2-4 minutes (I am taking this out of my head). This would IMHO give the reference of how long a "rehoming event" could take. Anything lower than that is a bonus :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7kvE6arNKXTPFCVEQInpgCg7dPlgYdWWDlQKJzfp09qsERQY4kAoPy5 8mZSHcprwOtx0OEYAxQPHyZz =wZ5F -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Nov 17 15:35: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 PAA03727 for ; Mon, 17 Nov 2003 15:35:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALq5H-000Iq5-L2 for multi6-data@psg.com; Mon, 17 Nov 2003 20:34:55 +0000 Received: from [195.43.225.73] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALq54-000Ipa-In for multi6@ops.ietf.org; Mon, 17 Nov 2003 20:34:42 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hAHKY63R009105; Mon, 17 Nov 2003 21:34:11 +0100 (CET) Date: Mon, 17 Nov 2003 21:34:02 +0100 Subject: Re: noid and applications (generic requirements from applications) Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Iljitsch van Beijnum , Multi6 Mailing List To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3FB442AF.9BB3BCC6@zurich.ibm.com> Message-Id: <619F52B2-193D-11D8-A52A-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On fredag, nov 14, 2003, at 03:49 Europe/Stockholm, Brian E Carpenter wrote: >> On 13-nov-03, at 16:26, Brian E Carpenter wrote: >> >>> Doesn't this objection also apply to passing an FQDN around, >>> since FQDNs can also be unreachable, due to 2-faced DNS >>> and the like? >> >> What would be the logic of making something unreachable using twofaced >> DNS? I thought the point was to make sure that different people >> connect >> to different hosts when they try to connect to an FQDN. The situation >> where one side of the DNS produces something useful while the other >> doesn't is either unintended, which is the risk you run by abusing >> technology in this way, or is intended in which case there isn't a >> problem. > > I don't mean there would be any logic. My point is that just as > you can make a mess by referring unrouteable addresses, you can make > a mess by referring inaccessible FQDNs. > > If server.example.com sends a referral for internal-only.example.com > to client.example.org, it is no different from sending a referral to > FEC0::27. Neither referral makes sense, but both might happen if > server.example.com doesn't know any better. Although I agree with Brian, this is a real case problem. Very much the same that was discussed with site-locals (but let's not go there right now). However, I am not sure this is an issues that we need to solve. As Iljitsch says, if people have a broken set-up, things will break. But I think this should be documented. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7kwvaarNKXTPFCVEQKttACgnxNFDmAxmTCKepTe+SlWjd+pHf4AoKF2 sIXJP+an1iLlqCJn+tSMhHdA =x00I -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Nov 17 15:44: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 PAA04002 for ; Mon, 17 Nov 2003 15:44:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALqDf-000JRh-Pw for multi6-data@psg.com; Mon, 17 Nov 2003 20:43:35 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALqDS-000JQo-Vs for multi6@ops.ietf.org; Mon, 17 Nov 2003 20:43:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAHKhDp04682; Mon, 17 Nov 2003 22:43:13 +0200 Date: Mon, 17 Nov 2003 22:43:13 +0200 (EET) From: Pekka Savola To: Kurt Erik Lindqvist cc: multi6@ops.ietf.org Subject: Re: delayed multihoming/mobility set-up In-Reply-To: <63AE30A8-193C-11D8-A52A-000A9598A184@kurtis.pp.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Kurt Erik Lindqvist wrote: [...] > If we assume that we are using BGP for the EGP routing updates, we have > the Ahuja/Labovitz route cancellation effect. If I remember correctly, > their research showed that 40% of re-routing takes 2-4 minutes (I am > taking this out of my head). This would IMHO give the reference of how > long a "rehoming event" could take. Anything lower than that is a bonus > :-) Uhh, could you clarify how this relates to this subject? I think I see a few ways to tie these together, but I'm not sure what your point is.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Nov 17 16:00: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 QAA04530 for ; Mon, 17 Nov 2003 16:00:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALqTD-000KZZ-Jm for multi6-data@psg.com; Mon, 17 Nov 2003 20:59:39 +0000 Received: from [195.43.225.73] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALqSt-000KYq-4c for multi6@ops.ietf.org; Mon, 17 Nov 2003 20:59:19 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hAHKwk3R009114; Mon, 17 Nov 2003 21:58:48 +0100 (CET) Date: Mon, 17 Nov 2003 21:58:38 +0100 Subject: Re: delayed multihoming/mobility set-up Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > [...] >> If we assume that we are using BGP for the EGP routing updates, we >> have >> the Ahuja/Labovitz route cancellation effect. If I remember correctly, >> their research showed that 40% of re-routing takes 2-4 minutes (I am >> taking this out of my head). This would IMHO give the reference of how >> long a "rehoming event" could take. Anything lower than that is a >> bonus >> :-) > > Uhh, could you clarify how this relates to this subject? I think I > see a > few ways to tie these together, but I'm not sure what your point is.. ( I was a bit fast there, to much mail to read and catch up with) Well the point I was after was your discussion on when a connected session should expect connection survivability. In todays IPv4/IPv6 internet, a connection passing over a EGP boundary (and I guess in worst case even inside ASes) will have to take the route cancellation in effect. This means that you will always have to worry about this. So the last you said was : > Note that in low-mobility or site multihoming scenarios you don't > expect > the the multihoming to be required *immediately*; the risk increases in > proportion to the time. And I was pointing out that you can't expect it to be immediate in the case above. Does this make any more sense? :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP7k2hKarNKXTPFCVEQIDrwCg/VOKG/o1ImSpCBovIdWlceEKziEAoJib 8JQ1GjmAfSB1OmqSU+1XPyrK =eX/p -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Nov 17 16:36: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 QAA06809 for ; Mon, 17 Nov 2003 16:36:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALr19-000Mif-9X for multi6-data@psg.com; Mon, 17 Nov 2003 21:34:43 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALr0w-000MhS-Cs for multi6@ops.ietf.org; Mon, 17 Nov 2003 21:34:30 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAHLetf19435; Mon, 17 Nov 2003 13:40:56 -0800 Date: Mon, 17 Nov 2003 13:34:21 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <31219258677.20031117133421@brandenburg.com> To: Brian E Carpenter CC: Spencer Dawkins , multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal In-Reply-To: <3FB8F1F4.344EE047@zurich.ibm.com> References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <041e01c3ad0b$f85a7870$2c818182@DFNJGL21> <33196103682.20031117070826@brandenburg.com> <3FB8F1F4.344EE047@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, BEC> Dave, please look carefully at the way the NOID proposal uses BEC> the Flow Label as (part of) the connection ID. I had my doubts when BEC> it was first proposed in the design team, but it has its advantages. If I have suggested anything that contradicts NOID, concerning SLAP, then I don't know what it is. Please clarify. (For the total topic of multiaddressing, I want to find mechanisms that do not put special or extra information into the packet header, at least so it will work with IPv4, but I don't think that the SLAP proposal affects this issue, one way or the other.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Nov 17 18:14: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 SAA12833 for ; Mon, 17 Nov 2003 18:14:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALsYU-0002t6-TT for multi6-data@psg.com; Mon, 17 Nov 2003 23:13:14 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ALsYH-0002rK-LY for multi6@ops.ietf.org; Mon, 17 Nov 2003 23:13:01 +0000 Received: (qmail 87667 invoked from network); 17 Nov 2003 23:22:01 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 17 Nov 2003 23:22:01 -0000 Message-ID: <3FB9566A.4090000@necom830.hpcl.titech.ac.jp> Date: Tue, 18 Nov 2003 08:14:50 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Pekka Savola , multi6@ops.ietf.org Subject: Re: delayed multihoming/mobility set-up References: <63AE30A8-193C-11D8-A52A-000A9598A184@kurtis.pp.se> In-Reply-To: <63AE30A8-193C-11D8-A52A-000A9598A184@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; > If we assume that we are using BGP for the EGP routing updates, we have > the Ahuja/Labovitz route cancellation effect. If I remember correctly, > their research showed that 40% of re-routing takes 2-4 minutes (I am > taking this out of my head). That is a reason why global routing table should be shrinked. > This would IMHO give the reference of how > long a "rehoming event" could take. Anything lower than that is a bonus > :-) It is not the reference for M6 as the proper timing is application dependent. It, instead, is the reference for BGP++. Masataka Ohta From owner-multi6@ops.ietf.org Mon Nov 17 20:34: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 UAA17485 for ; Mon, 17 Nov 2003 20:34:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALujk-000Aqw-3E for multi6-data@psg.com; Tue, 18 Nov 2003 01:33:00 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALujY-000AqP-AE for multi6@ops.ietf.org; Tue, 18 Nov 2003 01:32:48 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAI1dGf04051 for ; Mon, 17 Nov 2003 17:39:16 -0800 Date: Mon, 17 Nov 2003 17:32:36 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <150233553041.20031117173236@brandenburg.com> To: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal In-Reply-To: <33196103682.20031117070826@brandenburg.com> References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <041e01c3ad0b$f85a7870$2c818182@DFNJGL21> <33196103682.20031117070826@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Further thought: SD>> stopped. But we've clearly considered providing a common capability SD>> for all transports in a situation that was architecturually similar, SD>> and the ECM pictures had congestion management in a shim underneath SD>> multiple transports (the same point in the stack, if I get the SLAP SD>> vision). DC> I think it is the same point in the stack, yes. In fact, the discussions DC> that led to my suggestion using "connection id" as the fine-grained DC> identifier for a pool also prompted me to realize that the new, IP DC> Endpoint (IP-EP) module also needs to provide common congestion control, DC> as I commented in my parallel proposal to SLAP. With a multiaddressing pool mechanism, the transport may not see the locator information, instead seeing only an identifier. However, differential congestion control is needed at the locator level. So I think the long-term effect of creating pools needs to be to bring congestion control into the core of the pool mechanism. Think of this as taking the bottom end of transport and the top end (sort of) of IP and making them overlap. Mumble. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Nov 17 21:29: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 VAA18938 for ; Mon, 17 Nov 2003 21:29:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALvaP-000DmA-KS for multi6-data@psg.com; Tue, 18 Nov 2003 02:27:25 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALvaD-000Dlm-6T for multi6@ops.ietf.org; Tue, 18 Nov 2003 02:27:13 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2003 03:24:42 +0100 Received: from XBE-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAI2QwJW026044; Tue, 18 Nov 2003 03:26:59 +0100 (MET) Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Nov 2003 03:22:48 +0100 Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Nov 2003 03:27:08 +0100 In-Reply-To: <3FB8C1EA.EDB23019@zurich.ibm.com> References: <65929CE6-16AE-11D8-802E-000A959CF516@cisco.com> <3FB8C1EA.EDB23019@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Tony Li , multi6@ops.ietf.org From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: noid and applications (generic requirements from applications) Date: Tue, 18 Nov 2003 03:27:07 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.606) X-OriginalArrivalTime: 18 Nov 2003 02:27:08.0487 (UTC) FILETIME=[76F53570:01C3AD7B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On 2003-11-17, at 13.41, Brian E Carpenter wrote: > In NOID the transport layer and above aren't aware that the locator > is rewritten. So I don't see that part of your concern. Good. I just wanted someone else to say so, because when I read the=20 noid draft that was not clear to me. > More fundamentally, you say > >> Today, the idea is that the IP address as well as the FQDN is = globally >> unique > > Unfortunately that certainly isn't true of addresses today and we=20 > still have to > fight hard for it to be true of IPv6 addresses tomorrow. It's a=20 > dangerous > assumption. However, there's no reason FQDNs should be non-unique. Let me rephrase myself. In the real world, this is of course not true, BUT, protocols we have=20 (FTP, SIP etc) believe it is true. If the noid identifier is "more globally unique" than IPv4 addresses,=20 then I can see not objection from apps people but very strong support=20 for noid. paf > Brian > > Patrik F=E4ltstr=F6m wrote: >> >> On 2003-11-13, at 14.48, Tony Li wrote: >> >>> That is going to be exceedingly difficult. As long as we >>> are using IP addresses in applications and we are hiding >>> the actual reachability of the address from the application, >>> we are guaranteed to be allowing an application to pass along >>> an unreachable address. >>> >>> Note that this is a result of the layering violation of >>> passing around an IP address in the application. Asking us >>> to warp the world to support architectural mistakes strikes >>> me as suboptimal. >> >> The reason I ask is because I want to know what we will get at the = end >> of the day with the noid proposal. >> >> Today, the idea is that the IP address as well as the FQDN is = globally >> unique and have the properties described. >> >> | (A=3DB) and (B=3DC) gives (A=3DC) where '=3D' is "can = communicate with" >> | >> | and >> | >> | (A->B) gives (B->A) where '->' is "can send data to" >> >> What I understood from the noid draft is that what we today call IP >> addresses (what is above L2, used in the arp requests etc) can be >> rewritten and because of this doesn't have the properties above. >> >> My question was whether the new identifier will have the properties >> above, so an application instead of doing layering violations on >> FQDN+IP should do the same kind of violations on FQDN+Identifier? >> >> Else it will be extremely hard to "fix" protocols like ftp and >> everything which controls RTP streams. >> >> I think the discussion whether those protocols are designed in a >> correct or wrong way will not help, as you and myself possibly have=20= >> the >> same view -- even though there are rumors there are differences in = how >> hot it is in hell. >> >> IF the above properties are valid for at least one of the identifier >> "layers" in noid, fixing applications and protocols we have today = will >> be much easier. >> >> paf > From owner-multi6@ops.ietf.org Tue Nov 18 00:47: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 AAA23706 for ; Tue, 18 Nov 2003 00:47:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ALyfN-000MD1-Bh for multi6-data@psg.com; Tue, 18 Nov 2003 05:44:45 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ALyf3-000MBz-Bb for multi6@ops.ietf.org; Tue, 18 Nov 2003 05:44:25 +0000 Received: from jurassic.eng.sun.com ([129.146.87.31]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id hAI5iM5u001403; Mon, 17 Nov 2003 22:44:23 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with SMTP id hAI5iM7m337850; Mon, 17 Nov 2003 21:44:22 -0800 (PST) Date: Mon, 17 Nov 2003 21:43:15 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Some Comments on ID/Loc Separation Proposals To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200311141641.hAEGfiYH011717@ginger.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Do realize that for most people, when they speak of an "identifier" for the > host/endpoint/stack, they are sometimes thinking of names with no properties > - a subtly different kind of "ID" from the "interface ID" you were just > talking about. > > Of course, there are some schemes for host/endpoint/stack "identifiers" in > which those names *do* have properties - they are public keys, or hashes of > public keys, or DNS names, or whatever... I guess the issues isn't whether the frobnits has a property or not, because even your example of a random process id has the properties that they are random and uniques, but whether this property is important; being used for some particular purpose. I think this is shades of grey; a random frobnits can be used as a good hash key somewhere, which is a much *lighter* usage that the random bits also being a hash of a public key. > > An interface ID makes no sense to me. > > Perhaps because you, in contrast, are thinking of "ID" as "name with no > properties"? I think you will agree that interfaces do need names of some > sort - our familiar "locators" (i.e. an address which *only* names an > interface, and its location). Actually I was thinking more of "makes no sense"= isn't useful in the context of id/loc split. If one wants to separate out identifiers from locators for the purposes of allowing "rehoming" presumably one would want to rehome between different interfaces and not just between different locators assigned to the same interface. > > The concept of a stack name, where there can be one or more "stacks" on > > a given host, provides the right granularity to me. Each "stack" can > > presumbly have one or more network interfaces. > > I assume also that each interface can have one or more stacks talking through > it, right? Right. Erik From owner-multi6@ops.ietf.org Tue Nov 18 13:18: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 NAA05259 for ; Tue, 18 Nov 2003 13:18:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMAP8-000J3O-0z for multi6-data@psg.com; Tue, 18 Nov 2003 18:16:46 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AMAOu-000J2C-I8 for multi6@ops.ietf.org; Tue, 18 Nov 2003 18:16:32 +0000 Received: (qmail 90944 invoked from network); 18 Nov 2003 18:25:47 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 18 Nov 2003 18:25:47 -0000 Message-ID: <3FBA626F.5090408@necom830.hpcl.titech.ac.jp> Date: Wed, 19 Nov 2003 03:18:23 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Dave Crocker CC: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal References: <11729160049.20031115084555@brandenburg.com> In-Reply-To: <11729160049.20031115084555@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave; > A fundamental advantage that transport-based locator-pool schemes > (SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6, > MAST, MIP) is that they can multiplex the control exchange in with > data traffic, potentially saving on number of packets. Wedge-layer > approaches are forced to have an explicit, separate exchange. And, that is a possible new security threat of DoS amplifying. > 1. An endpoint runs Locator Pools (LP) as a resource shared among different > consumer services at the endpoint The Internet today already have DNS cache, which even enabls sharing beyond an endpoint. > The obvious direction this idea leads is towards an effort to produce > a common protocol. Clearly it should include the locator > "characterization" attribute-signalling capability that Erik suggested. Some characterristic of a locator is already stored in an endpoint as routing table entry or cache. Some (such as PMTU) is better treated by the transport layer. Masataka Ohta From owner-multi6@ops.ietf.org Tue Nov 18 15:22: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 PAA12946 for ; Tue, 18 Nov 2003 15:22:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMCLx-00023s-04 for multi6-data@psg.com; Tue, 18 Nov 2003 20:21:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMCLj-00023C-HR for multi6@ops.ietf.org; Tue, 18 Nov 2003 20:21:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id hAIKLLC27814; Tue, 18 Nov 2003 22:21:21 +0200 Date: Tue, 18 Nov 2003 22:21:21 +0200 (EET) From: Pekka Savola To: Kurt Erik Lindqvist cc: multi6@ops.ietf.org Subject: Re: delayed multihoming/mobility set-up In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Nov 2003, Kurt Erik Lindqvist wrote: > > Uhh, could you clarify how this relates to this subject? I think > > I see a few ways to tie these together, but I'm not sure what your > > point is.. > > ( I was a bit fast there, to much mail to read and catch up with) > > Well the point I was after was your discussion on when a connected > session should expect connection survivability. In todays IPv4/IPv6 > internet, a connection passing over a EGP boundary (and I guess in > worst case even inside ASes) will have to take the route > cancellation in effect. This means that you will always have to > worry about this. So the last you said was : > > > Note that in low-mobility or site multihoming scenarios you don't > > expect the the multihoming to be required *immediately*; the risk > > increases in proportion to the time. > > And I was pointing out that you can't expect it to be immediate in the > case above. No, this does not make sense. I'm trying to guess what point you're making. I can see two possibilities which neither clearly falls inside your text: 1) "if a route goes down, how long does it take to be able switch to the other connection if the protocols supported transport survivability" 2) "if a route goes down, and comes back up, how long does it take until it's fully usable everywhere?" Both of these are interesting, but not directly related to the question I raised, AFAICS. Could you try to elaborate a bit more? The proposal was all about stable configuration. Instead of setting up connection survability immediately when setting up the connection, it would only be done for connections that pass certain criteria check (e.g. last more than T minutes). That way, if there is a failure inside 0 ... T minutes from the startup of the connection, the connection in question will fail. If not, it'll just switch to the another connection transparently, with the possible problems switching connections may have. This is just about optimizing away the connection survability for "statistically" short-lived sessions unless you really care about that feature. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Nov 18 17:06: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 RAA20776 for ; Tue, 18 Nov 2003 17:06:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMDxt-00085t-Ti for multi6-data@psg.com; Tue, 18 Nov 2003 22:04:53 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMDxg-00085I-F8 for multi6@ops.ietf.org; Tue, 18 Nov 2003 22:04:40 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAIM4d620675 for ; Wed, 19 Nov 2003 00:04:39 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 00:04:38 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 18 Nov 2003 14:04:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Some Comments on ID/Loc Separation Proposals Date: Tue, 18 Nov 2003 17:04:34 -0500 Message-ID: Thread-Topic: Some Comments on ID/Loc Separation Proposals Thread-Index: AcOqTgWGlNe4KVqqSweCJbPVUTykoADz8C1g From: To: Cc: X-OriginalArrivalTime: 18 Nov 2003 22:04:35.0575 (UTC) FILETIME=[F3E75870:01C3AE1F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Wnc> The use of the term "Identifier" or "ID" sweeps an important > MWnc> issue under the rug in some cases: Is this a host ID or an > MWnc> interface ID? >=20 > or a 'stack id' or an 'endpoint id'? and what do these mean, > precisely. Exactly, Noel Chiappa referred to a host/endpoint/stack ID as though a host, an endpoint and a stack are all the same thing. But are they really the same thing? Is there even a 1:1:1 correlation between these things? > MWnc> - Initial end-to-end connection set-up. > MWnc> - Referrals. > MWnc> - What happens when two nodes try to establish connections > MWnc> to each other "simultaneously" > MWnc> - How does the mechanism avoid connection hijacking? >=20 > These are really good points. For example, I had frankly been > avoiding trying to handle referrals, but any solution needs to attend > to this requirement explicitly. Yes. And, there are enough commonly deployed application that use referrals that I think that we should consider it an operational requirement that a multi-homing mechanism includes support for referrals. > MWnc> MAST Feedback: >=20 > MWnc> Uses a control protocol between the two end-nodes to=20 > MWnc> exchange address information. The current proposal is > MWnc> two sparsely defined to allow a full analysis of its > MWnc> properties. >=20 > And, of course, that is intentional. The intent is to distinguish > between basic approach, versus the essential details of a > specification that permits real implementation. I understood that this was intentional, and I didn't mean to be insulting in any way. It's just that the proposal is not yet=20 detailed enough to allow the type of operational/functional analysis that I was trying to perform. > MWnc> - How do the end-points know when they need to > MWnc> send SET operations to update the locators=20 > MWnc> being used on the ends of this connection? >=20 > ignoring the heartbeat function that is suggested, why would not the > obvious "when something changes" rule suffice? How would an end-node detect when "something changes", such as=20 connectivity through a particular ISP? The routing system may know about this change (through routing protocols, for instance), but I don't know how the end-node IP stack would notice -- unless it receives some sort of "advice" from ULPs when communications are failing to progress? Or snoops routing messages? > MWnc> - The draft suggests using IPsec to secure the > MWnc> control connection, but IPsec doesn't support > MWnc> changing end-point addresses. >=20 > As one or another of the other wedge proposals suggests, IPSec would > run above the Mast address pool mechanism. Hence, IPSec would only > see one "address". So, the MAST control connection would also run over MAST, using the MAST IDs? If so, how is the initial connection set-up accomplished? Is there a bootstrapping issue here? > MWnc> - The PROBE message sounds (to me) similar to=20 > MWnc> the old proposal to use pings to detect dead > MWnc> gateways. What can we learn from the problems > MWnc> with that model that apply here? >=20 > I, too, would greatly like to hear feedback on this construct. I've > seen a couple of comments that raised no concerns about it, but none > that offered assurance it would work ok. One of the problems with active connectivity detection is bandwidth use. Perhaps this could be alleviated by suppressing MAST messages when ULPs are progressing -- similar to how Neighbor Solicitations are suppressed in IPv6 ND? =20 Margaret =20 From owner-multi6@ops.ietf.org Tue Nov 18 18:28: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 SAA25282 for ; Tue, 18 Nov 2003 18:28:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMFFG-000D3Q-Se for multi6-data@psg.com; Tue, 18 Nov 2003 23:26:54 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMFF2-000D2O-Vo for multi6@ops.ietf.org; Tue, 18 Nov 2003 23:26:40 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 18 Nov 2003 15:26:42 -0800 Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Nov 2003 15:26:40 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Nov 2003 15:26:11 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Nov 2003 15:26:34 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 Nov 2003 15:26:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.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: Some Comments on ID/Loc Separation Proposals Date: Tue, 18 Nov 2003 15:26:40 -0800 Message-ID: Thread-Topic: Some Comments on ID/Loc Separation Proposals Thread-Index: AcOqTgWGlNe4KVqqSweCJbPVUTykoADz8C1gAANDi3A= From: "Christian Huitema" To: , Cc: X-OriginalArrivalTime: 18 Nov 2003 23:26:37.0658 (UTC) FILETIME=[69B19BA0:01C3AE2B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > Wnc> The use of the term "Identifier" or "ID" sweeps an important > > MWnc> issue under the rug in some cases: Is this a host ID or an > > MWnc> interface ID? > > > > or a 'stack id' or an 'endpoint id'? and what do these mean, > > precisely. >=20 > Exactly, Noel Chiappa referred to a host/endpoint/stack ID as though > a host, an endpoint and a stack are all the same thing. But are they > really the same thing? Is there even a 1:1:1 correlation between > these things? There are many cases in which topology does matter. The classic example is VPN: you don't necessarily want a connection initiated over a VPN channel to migrate to another interface. Another classic example is compartmented organization, with a secret network and an open network, where you don't want a secret process to use the open network.=20 There are also classic cases of interfaces with different monetary characteristics, e.g. flat fee versus pay by volume. You don't want applications assuming a flat fee to accidentally migrate to a pay by volume interface.=20 -- Christian Huitema From owner-multi6@ops.ietf.org Tue Nov 18 20:06: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 UAA29277 for ; Tue, 18 Nov 2003 20:06:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMGm5-000Ihg-NI for multi6-data@psg.com; Wed, 19 Nov 2003 01:04:53 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMGlt-000IhI-S2 for multi6@ops.ietf.org; Wed, 19 Nov 2003 01:04:41 +0000 Received: from cisco.com (dhcp-171-71-119-91.cisco.com [171.71.119.91]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAJ14djq027870; Tue, 18 Nov 2003 17:04:39 -0800 (PST) Message-ID: <3FBAC1A6.5060908@cisco.com> Date: Tue, 18 Nov 2003 17:04:38 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Margaret.Wasserman@nokia.com, dcrocker@brandenburg.com, multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > There are many cases in which topology does matter. The classic example > is VPN: you don't necessarily want a connection initiated over a VPN > channel to migrate to another interface. Another classic example is > compartmented organization, with a secret network and an open network, > where you don't want a secret process to use the open network. Yes, I would agree that topology does matter. However, I think your example may be overstated. In fact I *would* like my VPN to migrate from one interface to another when I change addresses (outside-outside). I would also like to know when I don't need it because I'm "inside" some network. To me that's a matter of secured signaling to the next layer. > There are also classic cases of interfaces with different monetary > characteristics, e.g. flat fee versus pay by volume. You don't want > applications assuming a flat fee to accidentally migrate to a pay by > volume interface. Righto. And that's a matter of filtering at the TCP/UDP or even the application layer. Microsoft is in a very good position to ask and answer the question, "Who is calling me?" It's a bit more difficult if you're a router, but then IPSEC makes that a pain, anyway. Eliot From owner-multi6@ops.ietf.org Tue Nov 18 23:27: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 XAA05454 for ; Tue, 18 Nov 2003 23:27:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMJv2-0002rW-Rt for multi6-data@psg.com; Wed, 19 Nov 2003 04:26:20 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMJup-0002qY-Q5 for multi6@ops.ietf.org; Wed, 19 Nov 2003 04:26:07 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hAJ4Q6WB020276; Tue, 18 Nov 2003 23:26:06 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id hAJ4Q5OK020273; Tue, 18 Nov 2003 23:26:05 -0500 Date: Tue, 18 Nov 2003 23:26:05 -0500 From: "J. Noel Chiappa" Message-Id: <200311190426.hAJ4Q5OK020273@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Some Comments on ID/Loc Separation Proposals Cc: jnc@ginger.lcs.mit.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: >>> The use of the term "Identifier" or "ID" sweeps an important issue >>> under the rug in some cases: Is this a host ID or an interface ID? >> or a 'stack id' or an 'endpoint id'? and what do these mean, >> precisely. > Noel .. referred to a host/endpoint/stack ID as though a host, an > endpoint and a stack are all the same thing. But are they really the > same thing? Is there even a 1:1:1 correlation between these things? I was being a little loose there, for which I apologize. Let me expand a bit on that "host/endpoint/stack" thing. "stack" is a term that gained increased prominence in the NSRG, which used it to name some new "thing" that they might name. I don't think there was rough consensus there on what a "stack" might be; I don't even think there was RC on whether it was below the transport layer, or what - I'd have to look at my notes from the NSRG meeting to see (if anyone cares). "endpoint" is a term I have been using for a long time now (defined in this note - http://users.exis.net/~jnc/tech/endpoints.txt) to name a class of entities I thought we should explicitly add to the architecture; they are the things that do end-end communications like TCP (fate-sharing regions, in other words). I'm not sure if there is a significant difference between "stack" and "endpoint", but that might depend on who you talked to, and what the term "stack" meant to them. "host" I assume means a physical computer. I just threw that one in in case people were confused by the stack/endpoint terminology. Most people have a pretty good handle on what a "host" is. In a simple model, the kind we mostly have now (modulo things like the IBM web server farm), a host is an endpoint. If we included endpoints as first-class objects, presumably you could do things like have multiple endpoints in a particular host, and probably allow them to move from host to host. But that's all just architectural sketches. Noel From owner-multi6@ops.ietf.org Wed Nov 19 00:09: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 AAA06722 for ; Wed, 19 Nov 2003 00:09:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMKZQ-00051E-Ae for multi6-data@psg.com; Wed, 19 Nov 2003 05:08:04 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMKZD-00050U-02 for multi6@ops.ietf.org; Wed, 19 Nov 2003 05:07:51 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hAJ57nWB020463; Wed, 19 Nov 2003 00:07:49 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id hAJ57mYp020462; Wed, 19 Nov 2003 00:07:48 -0500 Date: Wed, 19 Nov 2003 00:07:48 -0500 From: "J. Noel Chiappa" Message-Id: <200311190507.hAJ57mYp020462@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals Cc: jnc@ginger.lcs.mit.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Erik Nordmark >> > Do realize that for most people, when they speak of an "identifier" >> for the host/endpoint/stack, they are sometimes thinking of names with >> no properties - a subtly different kind of "ID" from the "interface >> ID" you were just talking about. >> Of course, there are some schemes for host/endpoint/stack >> "identifiers" in which those names *do* have properties - they are >> public keys, or hashes of public keys, or DNS names, or whatever... > I guess the issues isn't whether the frobnits has a property or not, > because even your example of a random process id has the properties > that they are random and uniques OK, so I guess I used a non-optimal term when I called them "properties". Perhaps I should have called them "functionalities", or something, to emphasize that they are things about the name that allow you to perform some non-trivial operation with them - e.g. if it's a public key, you can authenticate or secure things with it. But I think the chief point I wanted to make is to get everyone to realize that the term "identifier" was not precisely defined. So, when one person mentions a " identifier", without specifying exactly what set of properties/functionalities that " identifier" has, someone else can't really understand what the first person meant. I will suggest again that we take "identifier" to mean "name with basically no properties/functionalities" (other than identfying the thing which it names). To allow me to be precise hereo, I'll use the term "NF-identifier" when I want this meaning. > but whether this property is important; being used for some particular > purpose. I think this is shades of grey; a random frobnits can be used > as a good hash key somewhere, which is a much *lighter* usage that the > random bits also being a hash of a public key. This is a fairly fine hair to split! Yes, if a particular type of name has some set of properties/functionalities, some class of users of that name might decide to only use a subset of those properties/functionalities. However, the uses clearly can't be a superset - so the full set of properties/functionalities of a name is important, because it sets hard bounds on what one can possibly (ever) do with it. >>> An interface ID makes no sense to me. >> Perhaps because you, in contrast, are thinking of "ID" as "name with >> no properties"? I think you will agree that interfaces do need names >> of some sort - our familiar "locators" (i.e. an address which *only* >> names an interface, and its location). > Actually I was thinking more of "makes no sense"= isn't useful in the > context of id/loc split. I think we're having a mis-communication here! Let me try this again. Depending on exactly how one defines the term "identifier", a "locator" might indeed be an "interface identifier". I.e. if one defines "identifier" to be "any kind of label", then a "locator" is clearly a member of the class "identifiers". On the other hand, for someone who uses the term "identifier" to mean an NF-identifier, a locator is clearly not an "interface identifier". That's all I meant. As to whether an "interface identifier" of the second sort is useful, well, I don't know for sure. I think it would depend in part on the routing architecture, and whether it had a use for names for interfaces which were not connectivity-dependent. I've seen routing architecture that did have a use for such names, particularly in networks of highly mobile objects. > If one wants to separate out identifiers from locators for the purposes > of allowing "rehoming" presumably one would want to rehome between > different interfaces and not just between different locators assigned > to the same interface. First, I assuming that when you say "identifier" above, you mean some sort of name (not necessarily an NF-identifier) for a stack/endpoint. If so, then I am in agreement with you - that would one want to allow an stack/endpoint to be bound to different interfaces, both over time (mobility) and at the same time (multi-homing). The reason it doesn't matter what kind of name you're using for the stack/endpoint is that the important architectural concept is that you're associating a "stack/endpoint" with an "interface" - and you're also specifying what kinds of associations (whether one-one, one-many, or many-one) are allowed, as well as allowing the associations to change over time, etc The issue of what particular names you're using for these two classes of things comes later. So the particular kind of name we use for the stack/endpoint is immaterial to these points in the previous paragraphs - it could be an NF-identifier, it could be a public key, whatever. (It also doesn't matter what kind of name we use for the interfaces, but so far I don't think anyone has seriously proposed anything except a locator.) Sorry for going on a bit of length about this, but my sense is that some of the back-and-forth here is caused by use of terms for which not everyone has the same precise definition. There's also some lack of precision in thinking separately about the things, and the names for them (as in the previous paragraphs). Noel From owner-multi6@ops.ietf.org Wed Nov 19 01:34: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 BAA08624 for ; Wed, 19 Nov 2003 01:34:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMLtS-0009EM-7x for multi6-data@psg.com; Wed, 19 Nov 2003 06:32:50 +0000 Received: from [18.26.0.82] (helo=ginger.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMLtG-0009E5-9l for multi6@ops.ietf.org; Wed, 19 Nov 2003 06:32:38 +0000 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id hAJ6WaWB020901; Wed, 19 Nov 2003 01:32:37 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id hAJ6WaDX020900; Wed, 19 Nov 2003 01:32:36 -0500 Date: Wed, 19 Nov 2003 01:32:36 -0500 From: "J. Noel Chiappa" Message-Id: <200311190632.hAJ6WaDX020900@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals Cc: jnc@ginger.lcs.mit.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Erik Nordmark >>> An interface ID makes no sense to me. >> Perhaps because you, in contrast, are thinking of "ID" as "name with >> no properties"? I think you will agree that interfaces do need names >> of some sort - our familiar "locators" (i.e. an address which *only* >> names an interface, and its location). > Actually I was thinking more of "makes no sense"= isn't useful in the > context of id/loc split. Actually, now that I think about it some more, perhaps you had a completely different meaning in mind here. Did you in fact mean to say that "I don't see any need to provide any kind of name for interfaces, either one with topological significance, or any other kind"? (The "name with topological significance for an interface" is what I've been calling a "locator".) In other words, when you talk about "id/loc split", are you thinking that we'll have two different kinds of names for endpoints/stacks - "ids" which are not related to any particular locations, and some sort of "location" name which is? Noel From owner-multi6@ops.ietf.org Wed Nov 19 02:16: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 CAA22915 for ; Wed, 19 Nov 2003 02:16:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMMZ3-000BP2-VS for multi6-data@psg.com; Wed, 19 Nov 2003 07:15:49 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMMYr-000BOH-ME for multi6@ops.ietf.org; Wed, 19 Nov 2003 07:15:37 +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 hAJ9KVOt012088; Wed, 19 Nov 2003 01:20:32 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hAJ7FPYB017123; Tue, 18 Nov 2003 23:15:25 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Some Comments on ID/Loc Separation Proposals Date: Tue, 18 Nov 2003 23:15:24 -0800 Message-ID: Thread-Topic: Some Comments on ID/Loc Separation Proposals Thread-Index: AcOuaGgah2sJYpx1QIqjofeVioXwvwAA1Mtg From: "Tony Li" To: "J. Noel Chiappa" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Noel, From my perspective, we've been quite consistent with using locator for the topological naming for an interface, while an identifier is the name for a host. Yes, I realize that we haven't taken this quite as far as you (or I) would like. However, if you consider that we have managed to get consensus on this much separation, I'd say that we've come a long way, baby. Tony | -----Original Message----- | From: J. Noel Chiappa [mailto:jnc@ginger.lcs.mit.edu]=20 | Sent: Tuesday, November 18, 2003 10:33 PM | To: multi6@ops.ietf.org | Cc: jnc@ginger.lcs.mit.edu | Subject: Re: Some Comments on ID/Loc Separation Proposals | =20 | =20 | > From: Erik Nordmark =20 | =20 | >>> An interface ID makes no sense to me. | =20 | >> Perhaps because you, in contrast, are thinking of=20 | "ID" as "name with | >> no properties"? I think you will agree that=20 | interfaces do need names | >> of some sort - our familiar "locators" (i.e. an=20 | address which *only* | >> names an interface, and its location). | =20 | > Actually I was thinking more of "makes no sense"=3D=20 | isn't useful in the | > context of id/loc split. | =20 | Actually, now that I think about it some more, perhaps you=20 | had a completely | different meaning in mind here. | =20 | Did you in fact mean to say that "I don't see any need to=20 | provide any kind of | name for interfaces, either one with topological=20 | significance, or any other | kind"? | =20 | (The "name with topological significance for an interface"=20 | is what I've been | calling a "locator".) | =20 | =20 | In other words, when you talk about "id/loc split", are you=20 | thinking that | we'll have two different kinds of names for endpoints/stacks=20 | - "ids" which | are not related to any particular locations, and some sort=20 | of "location" name | which is? | =20 | Noel | =20 | =20 From owner-multi6@ops.ietf.org Wed Nov 19 05:07: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 FAA10743 for ; Wed, 19 Nov 2003 05:07:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMPEC-000M4T-OO for multi6-data@psg.com; Wed, 19 Nov 2003 10:06:28 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMPDx-000M3r-LF for multi6@ops.ietf.org; Wed, 19 Nov 2003 10:06:13 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAJA5rGs107368; Wed, 19 Nov 2003 10:05:55 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAJA2ugU240210; Wed, 19 Nov 2003 11:02:56 +0100 Received: from zurich.ibm.com (dhcp222-92.zurich.ibm.com [9.4.222.92]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA56290; Wed, 19 Nov 2003 11:02:55 +0100 Message-ID: <3FBB2704.9E72705@zurich.ibm.com> Date: Wed, 19 Nov 2003 09:17:08 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Dave Crocker CC: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <041e01c3ad0b$f85a7870$2c818182@DFNJGL21> <33196103682.20031117070826@brandenburg.com> <3FB8F1F4.344EE047@zurich.ibm.com> <31219258677.20031117133421@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave, Dave Crocker wrote: > > Brian, > > BEC> Dave, please look carefully at the way the NOID proposal uses > BEC> the Flow Label as (part of) the connection ID. I had my doubts when > BEC> it was first proposed in the design team, but it has its advantages. > > If I have suggested anything that contradicts NOID, concerning SLAP, > then I don't know what it is. Please clarify. NOID includes the flow label in the n-tuple that identifies a flow (for lack of a better word). This isn't different from what you suggest at 10,000 meter level, but it affects some details, including the granularity at which multihoming occurs - in fact the granularity becomes identically the scope of a {srce, dest, flow label} 3tuple, rather than the scope of a {srce, dest, port, port, protocol} 5tuple. And it has the advantage of using fields that are outside all IPSEC headers. As far as I can tell, NOID is fully compatible with the flow label spec (draft-ietf-ipv6-flow-label-08.txt). > > (For the total topic of multiaddressing, I want to find mechanisms that > do not put special or extra information into the packet header, at > least so it will work with IPv4, but I don't think that the SLAP > proposal affects this issue, one way or the other.) This is the IPv6 multihoming WG... Brian From owner-multi6@ops.ietf.org Wed Nov 19 05:50: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 FAA12065 for ; Wed, 19 Nov 2003 05:50:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMPuF-000PAG-4y for multi6-data@psg.com; Wed, 19 Nov 2003 10:49:55 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMPtz-000P9J-EL for multi6@ops.ietf.org; Wed, 19 Nov 2003 10:49:39 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAJARvM2112304 for ; Wed, 19 Nov 2003 10:49:36 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAJA2wgU283746 for ; Wed, 19 Nov 2003 11:02:59 +0100 Received: from zurich.ibm.com (dhcp222-92.zurich.ibm.com [9.4.222.92]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA41216 for ; Wed, 19 Nov 2003 11:02:57 +0100 Message-ID: <3FBB29F7.3023A4D2@zurich.ibm.com> Date: Wed, 19 Nov 2003 09:29:43 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we're going to have to face a couple of realities in order to make progress. 1. Despite years of discussion, we've never managed to establish a shared understanding of identifier issues. The NSRG was the most recent serious attempt, and despite a measure of consensus it didn't really succeed. 2. These things we call "addresses" have frustratingly ambiguous properties. We have to deal with these realities pragmatically - we simply will not have mathematical precision about the meaning and properties of "addresses," but reality forces us to use them anyway. Conceptually, upper layer protocols have been taught to think of addresses as a perfect blend of locator and identifier, and the lower layers know well that they are only locators. Multi6's job is to reconcile these two views as part of our solution. Brian co-chair hat mainly on Erik Nordmark wrote: > > > Do realize that for most people, when they speak of an "identifier" for the > > host/endpoint/stack, they are sometimes thinking of names with no properties > > - a subtly different kind of "ID" from the "interface ID" you were just > > talking about. > > > > Of course, there are some schemes for host/endpoint/stack "identifiers" in > > which those names *do* have properties - they are public keys, or hashes of > > public keys, or DNS names, or whatever... > > I guess the issues isn't whether the frobnits has a property or not, > because even your example of a random process id has the properties that they > are random and uniques, but whether this property is important; being > used for some particular purpose. > I think this is shades of grey; a random frobnits can be used as a good > hash key somewhere, which is a much *lighter* usage that the random bits > also being a hash of a public key. > > > > An interface ID makes no sense to me. > > > > Perhaps because you, in contrast, are thinking of "ID" as "name with no > > properties"? I think you will agree that interfaces do need names of some > > sort - our familiar "locators" (i.e. an address which *only* names an > > interface, and its location). > > Actually I was thinking more of "makes no sense"= isn't useful in the context > of id/loc split. > If one wants to separate out identifiers from locators for the purposes > of allowing "rehoming" presumably one would want to rehome between different > interfaces and not just between different locators assigned to the same > interface. > > > > The concept of a stack name, where there can be one or more "stacks" on > > > a given host, provides the right granularity to me. Each "stack" can > > > presumbly have one or more network interfaces. > > > > I assume also that each interface can have one or more stacks talking through > > it, right? > > Right. > > Erik From owner-multi6@ops.ietf.org Wed Nov 19 06:28: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 GAA12903 for ; Wed, 19 Nov 2003 06:28:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMQUJ-0001c3-Rh for multi6-data@psg.com; Wed, 19 Nov 2003 11:27:11 +0000 Received: from [206.197.161.140] (helo=uillean.fuaim.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMQU5-0001b1-B6 for multi6@ops.ietf.org; Wed, 19 Nov 2003 11:26:57 +0000 Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id hAJBQuV32011 for ; Wed, 19 Nov 2003 03:26:56 -0800 Received: from innovationslab.net (md-wmnsmd-cuda2-c6a-a-4.chvlva.adelphia.net [68.65.120.4]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id hAJBVKtX020032 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 19 Nov 2003 03:31:23 -0800 Message-ID: <3FBB537C.8040308@innovationslab.net> Date: Wed, 19 Nov 2003 06:26:52 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: <200311190632.hAJ6WaDX020900@ginger.lcs.mit.edu> In-Reply-To: <200311190632.hAJ6WaDX020900@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit J. Noel Chiappa wrote: > > From: Erik Nordmark > > >>> An interface ID makes no sense to me. > > >> Perhaps because you, in contrast, are thinking of "ID" as "name with > >> no properties"? I think you will agree that interfaces do need names > >> of some sort - our familiar "locators" (i.e. an address which *only* > >> names an interface, and its location). > > > Actually I was thinking more of "makes no sense"= isn't useful in the > > context of id/loc split. > > Actually, now that I think about it some more, perhaps you had a completely > different meaning in mind here. > > Did you in fact mean to say that "I don't see any need to provide any kind of > name for interfaces, either one with topological significance, or any other > kind"? > > (The "name with topological significance for an interface" is what I've been > calling a "locator".) > > > In other words, when you talk about "id/loc split", are you thinking that > we'll have two different kinds of names for endpoints/stacks - "ids" which > are not related to any particular locations, and some sort of "location" name > which is? I can't speak for Erik, but that is exactly how I interpreted this comment. Conceptually, I picture the model mentioned by Erik as ID="Who I am" and Loc="Where I am". For example, ID="Brian Henderson" and Loc="12 Maple Lane". Regards, Brian From owner-multi6@ops.ietf.org Wed Nov 19 06:58: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 GAA13633 for ; Wed, 19 Nov 2003 06:58:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMQxC-0003So-Np for multi6-data@psg.com; Wed, 19 Nov 2003 11:57:02 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMQx0-0003Rr-4l for multi6@ops.ietf.org; Wed, 19 Nov 2003 11:56:50 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 80EA71C for ; Wed, 19 Nov 2003 14:09:55 +0200 (EET) Message-ID: <3FBB5A85.3020102@nomadiclab.com> Date: Wed, 19 Nov 2003 12:56:53 +0100 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> In-Reply-To: <3FB8C386.4E526EFB@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Spencer, I think the point here is that there will be state > to maintain, and each user of that state will need to access a > common STorage Information bloCK, i.e. the SLAP STICK. > > The kind of shim that NOID suggests could also be a user > and maintainer of the slapstick. > > I'd encourage people to think about this as a potential > architectural component, in the spirit of the final part of > the discussion last week. Personally, I like the SLAP STICK idea very much. To me, it is pretty clear that the interface between multi-addressed layer 3.5 and transport has some serious issues, as discussed e.g. by Spencer. Perhaps SLAP, maybe combined with ECM, could do something to them. However, I am also worried about potential DoS and other security issues. To me, it looks like a bad idea of allowing all of the upper layer protocols to add or remove addresses from SLAP. Updating (soft) address state is probably fine, but both adding and deleting addresses is potentially dangerous. Hence, maybe we should consider a new protocol to maintain the SLAP state, and instead of having upper layer address update mechanism (eg. SCTP addip), route the upper layer APIs to the new protocol. --Pekka Nikander From owner-multi6@ops.ietf.org Wed Nov 19 08:56: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 IAA16647 for ; Wed, 19 Nov 2003 08:56:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMSnB-000BNi-AW for multi6-data@psg.com; Wed, 19 Nov 2003 13:54:49 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMSmt-000BMg-Ms for multi6@ops.ietf.org; Wed, 19 Nov 2003 13:54:31 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAJDsCHf020004; Wed, 19 Nov 2003 13:54:15 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAJDqA59170558; Wed, 19 Nov 2003 14:52:10 +0100 Received: from zurich.ibm.com (dhcp222-92.zurich.ibm.com [9.4.222.92]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA62778; Wed, 19 Nov 2003 14:52:09 +0100 Message-ID: <3FBB7560.EFBB01AB@zurich.ibm.com> Date: Wed, 19 Nov 2003 14:51:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: delayed multihoming/mobility set-up References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit What we should probably be clear about is that multi6 is not aiming to support instant QOS restoration. In other words we are not aiming to be qualified for emergency services and not even for fast signalling (which is what SCTP is aimed at). Brian Pekka Savola wrote: > > On Mon, 17 Nov 2003, Kurt Erik Lindqvist wrote: > > > Uhh, could you clarify how this relates to this subject? I think > > > I see a few ways to tie these together, but I'm not sure what your > > > point is.. > > > > ( I was a bit fast there, to much mail to read and catch up with) > > > > Well the point I was after was your discussion on when a connected > > session should expect connection survivability. In todays IPv4/IPv6 > > internet, a connection passing over a EGP boundary (and I guess in > > worst case even inside ASes) will have to take the route > > cancellation in effect. This means that you will always have to > > worry about this. So the last you said was : > > > > > Note that in low-mobility or site multihoming scenarios you don't > > > expect the the multihoming to be required *immediately*; the risk > > > increases in proportion to the time. > > > > And I was pointing out that you can't expect it to be immediate in the > > case above. > > No, this does not make sense. > > I'm trying to guess what point you're making. I can see two > possibilities which neither clearly falls inside your text: > > 1) "if a route goes down, how long does it take to be able switch to > the other connection if the protocols supported transport > survivability" > > 2) "if a route goes down, and comes back up, how long does it take > until it's fully usable everywhere?" > > Both of these are interesting, but not directly related to the > question I raised, AFAICS. > > Could you try to elaborate a bit more? > > The proposal was all about stable configuration. Instead of setting > up connection survability immediately when setting up the connection, > it would only be done for connections that pass certain criteria check > (e.g. last more than T minutes). That way, if there is a failure > inside 0 ... T minutes from the startup of the connection, the > connection in question will fail. If not, it'll just switch to the > another connection transparently, with the possible problems switching > connections may have. This is just about optimizing away the > connection survability for "statistically" short-lived sessions unless > you really care about that feature. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Wed Nov 19 11:42: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 LAA25478 for ; Wed, 19 Nov 2003 11:42:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMVO2-000M7y-FP for multi6-data@psg.com; Wed, 19 Nov 2003 16:41:02 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMVNo-000M6j-Sl for multi6@ops.ietf.org; Wed, 19 Nov 2003 16:40:48 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAJGlAf19436; Wed, 19 Nov 2003 08:47:10 -0800 Date: Wed, 19 Nov 2003 08:30:35 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <16878086402.20031119083035@brandenburg.com> To: Pekka Nikander CC: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal In-Reply-To: <3FBB5A85.3020102@nomadiclab.com> References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <3FBB5A85.3020102@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, PN> However, I am also worried about potential DoS and other PN> security issues. To me, it looks like a bad idea of allowing PN> all of the upper layer protocols to add or remove addresses PN> from SLAP. Updating (soft) address state is probably fine, PN> but both adding and deleting addresses is potentially dangerous. Please elaborate on your concerns. My assumption is that the apps each has at least the requisite, basic "authentication of exchange continuity" that routing-based IP validation provides. So all I can guess is that the danger you fear is the general one of having too many participants (applications and transport add/delete mechanisms) and that any one of them can do a lot of damage. That's why I think it would be great to try to standardize a single control protocol, but permit it to be used over a variety of mechanisms (layer 3.5, transport, and even apps.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Wed Nov 19 12:51: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 MAA29563 for ; Wed, 19 Nov 2003 12:51:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMWTc-0000ZF-70 for multi6-data@psg.com; Wed, 19 Nov 2003 17:50:52 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMWTK-0000Xd-5a for multi6@ops.ietf.org; Wed, 19 Nov 2003 17:50:34 +0000 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 32E1E1C; Wed, 19 Nov 2003 20:03:39 +0200 (EET) Message-ID: <3FBBAD6C.5040106@nomadiclab.com> Date: Wed, 19 Nov 2003 18:50:36 +0100 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Crocker Cc: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <3FBB5A85.3020102@nomadiclab.com> <16878086402.20031119083035@brandenburg.com> In-Reply-To: <16878086402.20031119083035@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave, > PN> However, I am also worried about potential DoS and other > PN> security issues. To me, it looks like a bad idea of allowing > PN> all of the upper layer protocols to add or remove addresses > PN> from SLAP. Updating (soft) address state is probably fine, > PN> but both adding and deleting addresses is potentially dangerous. > > Please elaborate on your concerns. It's mostly gut feeling right now. I have to do some analysis before I can say much more, and I don't have that time right now. Maybe reading Erik's threat draft would give some insight? > My assumption is that the apps each has at least the requisite, basic > "authentication of exchange continuity" that routing-based IP validation > provides. Well, while that may suffice as a baseline, it may still have some issues. Like what if some applications have better security properties than others? In that case you could use an application with weaker security to confuse the SLAP state in order to launch an attack against a more secure application. > So all I can guess is that the danger you fear is the general one of > having too many participants (applications and transport add/delete > mechanisms) and that any one of them can do a lot of damage. More or less yes. But there are probably details, and they need to be worked out. > That's why > I think it would be great to try to standardize a single control > protocol, but permit it to be used over a variety of mechanisms (layer > 3.5, transport, and even apps.) I agree that it would be great to standardize a single control protocol. However, I am not so sure whether it would be great to permit it to be carried over a variety of mechanisms. One particular problem with security is that it is not composable, in general. That is, if you have a perfectly secure mechanism A, and another perfectly secure mechanism B, putting them together into A + B (where + is some sort of a composition operator) may result in a system that is not secure any more. (I am not saying that it is not composable in this particular case. I am merely saying that we don't know before we've done some analysis.) --Pekka Nikander From owner-multi6@ops.ietf.org Wed Nov 19 15:29: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 PAA10015 for ; Wed, 19 Nov 2003 15:29:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMYtK-000B4k-9m for multi6-data@psg.com; Wed, 19 Nov 2003 20:25:34 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMYsy-000B2v-Ab for multi6@ops.ietf.org; Wed, 19 Nov 2003 20:25:12 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09502; Wed, 19 Nov 2003 15:24:57 -0500 (EST) Message-Id: <200311192024.PAA09502@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: multi6@ops.ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-nordmark-multi6-cb64-00.txt Date: Wed, 19 Nov 2003 15:24:57 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multihoming using 64-bit Crypto-based IDs Author(s) : E. Nordmark Filename : draft-nordmark-multi6-cb64-00.txt Pages : 33 Date : 2003-11-19 This document outlines a potential solution to IPv6 multihoming in order to stimulate discussion. This proposal is a middle ground between the NOID and CB128 proposals. This proposed solution relies on verification the crypto-based identifier properties (using public-key crypto during uncommon operations), while allowing locator rewriting by (border) routers, with no per-packet overhead. The solution does have something which could be viewed as a 'stack name' type of identifier, but this isn't exposed to upper layer protocols. Instead it ensures that all upper layer protocols can operate unmodified in a multihomed setting while still seeing a stable IPv6 address, even though the address internally consists of 64-bits worth of subnet locator plus 64-bits of crypto-based identifier. This solution (and this draft) is remarkably similar to draft- nordmark-multi6-noid-00.txt; only issues related to prevention of redirection attacks differ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nordmark-multi6-cb64-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nordmark-multi6-cb64-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nordmark-multi6-cb64-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-11-19144325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nordmark-multi6-cb64-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nordmark-multi6-cb64-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-19144325.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Wed Nov 19 22:10: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 WAA00905 for ; Wed, 19 Nov 2003 22:10:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMfBA-0005y2-92 for multi6-data@psg.com; Thu, 20 Nov 2003 03:08:24 +0000 Received: from [216.148.227.85] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMfAx-0005xk-Cg for multi6@ops.ietf.org; Thu, 20 Nov 2003 03:08:11 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc12) with SMTP id <2003112003081001400ekd9fe> (Authid: sdawkins@comcast.net); Thu, 20 Nov 2003 03:08:11 +0000 Message-ID: <07d901c3af13$87ac20b0$2c818182@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <3FBB5A85.3020102@nomadiclab.com> <16878086402.20031119083035@brandenburg.com> <3FBBAD6C.5040106@nomadiclab.com> Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal Date: Wed, 19 Nov 2003 21:08:07 -0600 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Pekka and Dave, I didn't mean to bring up a subject quite this dark. My concern was about errors in one transport or one application hosing the multi6 capability for everyone, and about how difficult it might be to debug this (visualize kernel debugging in many implementations). Pekka's gut feeling about one transport or one application being manipulated into hosing the multi6 capability for everyone is the next step, when one thinks about it (thanks for thinking about it). Put another way, I was talking about software engineering, not about protocol design. Pekka brought the concept back into protocol design territory. If we're saying that, in the absence of secure discovery mechanisms, anybody can respond to ARP requests and steal traffic, that's true, but maybe a little easier for the average snifferholic to debug than what Pekka and I are noodling about - a blown pointer would be sufficient to cause the effect I'm talking about. Spencer ----- Original Message ----- From: "Pekka Nikander" To: "Dave Crocker" Cc: Sent: Wednesday, November 19, 2003 11:50 AM Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal > Dave, > > > PN> However, I am also worried about potential DoS and other > > PN> security issues. To me, it looks like a bad idea of allowing > > PN> all of the upper layer protocols to add or remove addresses > > PN> from SLAP. Updating (soft) address state is probably fine, > > PN> but both adding and deleting addresses is potentially dangerous. > > > > Please elaborate on your concerns. > > It's mostly gut feeling right now. I have to do some analysis > before I can say much more, and I don't have that time right now. > Maybe reading Erik's threat draft would give some insight? > > > My assumption is that the apps each has at least the requisite, basic > > "authentication of exchange continuity" that routing-based IP validation > > provides. > > Well, while that may suffice as a baseline, it may still have > some issues. Like what if some applications have better security > properties than others? In that case you could use an application > with weaker security to confuse the SLAP state in order to launch > an attack against a more secure application. > > > So all I can guess is that the danger you fear is the general one of > > having too many participants (applications and transport add/delete > > mechanisms) and that any one of them can do a lot of damage. > > More or less yes. But there are probably details, and they > need to be worked out. > > > That's why > > I think it would be great to try to standardize a single control > > protocol, but permit it to be used over a variety of mechanisms (layer > > 3.5, transport, and even apps.) > > I agree that it would be great to standardize a single control > protocol. However, I am not so sure whether it would be great > to permit it to be carried over a variety of mechanisms. > > One particular problem with security is that it is not composable, > in general. That is, if you have a perfectly secure mechanism A, > and another perfectly secure mechanism B, putting them together > into A + B (where + is some sort of a composition operator) may > result in a system that is not secure any more. (I am not saying > that it is not composable in this particular case. I am merely > saying that we don't know before we've done some analysis.) > > --Pekka Nikander > > > From owner-multi6@ops.ietf.org Wed Nov 19 22:45: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 WAA02042 for ; Wed, 19 Nov 2003 22:45:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMfjE-0007V0-Ct for multi6-data@psg.com; Thu, 20 Nov 2003 03:43:36 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AMfij-0007UJ-Qo for multi6@ops.ietf.org; Thu, 20 Nov 2003 03:43:06 +0000 Received: (qmail 97642 invoked from network); 20 Nov 2003 03:52:45 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 20 Nov 2003 03:52:45 -0000 Message-ID: <3FBC38B9.1040404@necom830.hpcl.titech.ac.jp> Date: Thu, 20 Nov 2003 12:44:57 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: <3FBB29F7.3023A4D2@zurich.ibm.com> In-Reply-To: <3FBB29F7.3023A4D2@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > We have to deal with these realities pragmatically - we simply will not > have mathematical precision about the meaning and properties of "addresses," > but reality forces us to use them anyway. According to the end to end principle of the Internet, what's important on the Internet is end systems. So, addresses, IDs and locators address, identify and locate end systems and they occur at the Internetworking layer. > Conceptually, upper layer protocols have been taught to think of addresses > as a perfect blend of locator and identifier, and the lower layers know well > that they are only locators. Multi6's job is to reconcile these two views > as part of our solution. By definition of "layering", layers other than the Internetworking layer may use anything (including something used by the Internetworking layer) for identifiers. On the other hand, "locator" locates something only at the Internetworking layer though other layers may use the "locator" for other purposes. > Brian > co-chair hat mainly on Just rely on not chairmanship but the end to end principle. Masataka Ohta From owner-multi6@ops.ietf.org Thu Nov 20 08:05: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 IAA02747 for ; Thu, 20 Nov 2003 08:05:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMoTB-00073g-9p for multi6-data@psg.com; Thu, 20 Nov 2003 13:03:37 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMoSx-00072b-VP for multi6@ops.ietf.org; Thu, 20 Nov 2003 13:03:24 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAKD36Hf037062; Thu, 20 Nov 2003 13:03:09 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAKD0qLE060218; Thu, 20 Nov 2003 14:00:53 +0100 Received: from zurich.ibm.com (dyn-9-13-127-147.ge.ch.ibm.com [9.13.127.147]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA70506; Thu, 20 Nov 2003 14:00:49 +0100 Message-ID: <3FBCBAD8.356DE59D@zurich.ibm.com> Date: Thu, 20 Nov 2003 14:00:08 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Spencer Dawkins CC: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <3FBB5A85.3020102@nomadiclab.com> <16878086402.20031119083035@brandenburg.com> <3FBBAD6C.5040106@nomadiclab.com> <07d901c3af13$87ac20b0$2c818182@DFNJGL21> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Our guideline here is that the multi6 solution must not introduce any new security vulnerabilities that we don't have today. And Pekka is certainly correct - anytime you add shared state, you need to protect it against bad people. But we can't assume that any key material is available to multihoming participants, unless we also define how they acquire it, since multihoming participants likely have no pre-existing relationship. Brian Spencer Dawkins wrote: > > Hi, Pekka and Dave, > > I didn't mean to bring up a subject quite this dark. My concern was > about errors in one transport or one application hosing the multi6 > capability for everyone, and about how difficult it might be to debug > this (visualize kernel debugging in many implementations). Pekka's gut > feeling about one transport or one application being manipulated into > hosing the multi6 capability for everyone is the next step, when one > thinks about it (thanks for thinking about it). > > Put another way, I was talking about software engineering, not about > protocol design. Pekka brought the concept back into protocol design > territory. > > If we're saying that, in the absence of secure discovery mechanisms, > anybody can respond to ARP requests and steal traffic, that's true, > but maybe a little easier for the average snifferholic to debug than > what Pekka and I are noodling about - a blown pointer would be > sufficient to cause the effect I'm talking about. > > Spencer > > ----- Original Message ----- > From: "Pekka Nikander" > To: "Dave Crocker" > Cc: > Sent: Wednesday, November 19, 2003 11:50 AM > Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal > > > Dave, > > > > > PN> However, I am also worried about potential DoS and other > > > PN> security issues. To me, it looks like a bad idea of allowing > > > PN> all of the upper layer protocols to add or remove addresses > > > PN> from SLAP. Updating (soft) address state is probably fine, > > > PN> but both adding and deleting addresses is potentially > dangerous. > > > > > > Please elaborate on your concerns. > > > > It's mostly gut feeling right now. I have to do some analysis > > before I can say much more, and I don't have that time right now. > > Maybe reading Erik's threat draft would give some insight? > > > > > My assumption is that the apps each has at least the requisite, > basic > > > "authentication of exchange continuity" that routing-based IP > validation > > > provides. > > > > Well, while that may suffice as a baseline, it may still have > > some issues. Like what if some applications have better security > > properties than others? In that case you could use an application > > with weaker security to confuse the SLAP state in order to launch > > an attack against a more secure application. > > > > > So all I can guess is that the danger you fear is the general one > of > > > having too many participants (applications and transport > add/delete > > > mechanisms) and that any one of them can do a lot of damage. > > > > More or less yes. But there are probably details, and they > > need to be worked out. > > > > > That's why > > > I think it would be great to try to standardize a single control > > > protocol, but permit it to be used over a variety of mechanisms > (layer > > > 3.5, transport, and even apps.) > > > > I agree that it would be great to standardize a single control > > protocol. However, I am not so sure whether it would be great > > to permit it to be carried over a variety of mechanisms. > > > > One particular problem with security is that it is not composable, > > in general. That is, if you have a perfectly secure mechanism A, > > and another perfectly secure mechanism B, putting them together > > into A + B (where + is some sort of a composition operator) may > > result in a system that is not secure any more. (I am not saying > > that it is not composable in this particular case. I am merely > > saying that we don't know before we've done some analysis.) > > > > --Pekka Nikander From owner-multi6@ops.ietf.org Thu Nov 20 08:46:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03892 for ; Thu, 20 Nov 2003 08:46:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMp6w-000993-RN for multi6-data@psg.com; Thu, 20 Nov 2003 13:44:42 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMp6k-00098U-4m for multi6@ops.ietf.org; Thu, 20 Nov 2003 13:44:30 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc11) with SMTP id <2003112013442901300mq7qse> (Authid: sdawkins@comcast.net); Thu, 20 Nov 2003 13:44:29 +0000 Message-ID: <099601c3af6c$6c4a4000$2c818182@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <3FBB5A85.3020102@nomadiclab.com> <16878086402.20031119083035@brandenburg.com> <3FBBAD6C.5040106@nomadiclab.com> <07d901c3af13$87ac20b0$2c818182@DFNJGL21> <3FBCBAD8.356DE59D@zurich.ibm.com> Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal Date: Thu, 20 Nov 2003 07:44:29 -0600 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Maybe I'm the only one that's still catching up, but I think this makes three categories of worries, - protecting different users of multi6 on a single node from each other's implementation bugs (not our problem, but anything we do to keep from making it worse helps), - protecting different users of multi6 on a single node from each other's exploitation vulnerabilities (not quite the same as previous, but close, because we're talking about "implementation bug amplifiers"), - protecting all the users of multi6 on a single node from attackers on other nodes (clearly our problem). Is this close? - so there's probably a category of worry about protecting groups of multi6 participants from attack, too... Spencer ----- Original Message ----- From: "Brian E Carpenter" To: "Spencer Dawkins" Cc: Sent: Thursday, November 20, 2003 7:00 AM Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal > Our guideline here is that the multi6 solution must not introduce any new > security vulnerabilities that we don't have today. And Pekka is certainly > correct - anytime you add shared state, you need to protect it against bad > people. But we can't assume that any key material is available to multihoming > participants, unless we also define how they acquire it, since multihoming > participants likely have no pre-existing relationship. > > Brian > > Spencer Dawkins wrote: > > > > Hi, Pekka and Dave, > > > > I didn't mean to bring up a subject quite this dark. My concern was > > about errors in one transport or one application hosing the multi6 > > capability for everyone, and about how difficult it might be to debug > > this (visualize kernel debugging in many implementations). Pekka's gut > > feeling about one transport or one application being manipulated into > > hosing the multi6 capability for everyone is the next step, when one > > thinks about it (thanks for thinking about it). > > > > Put another way, I was talking about software engineering, not about > > protocol design. Pekka brought the concept back into protocol design > > territory. > > > > If we're saying that, in the absence of secure discovery mechanisms, > > anybody can respond to ARP requests and steal traffic, that's true, > > but maybe a little easier for the average snifferholic to debug than > > what Pekka and I are noodling about - a blown pointer would be > > sufficient to cause the effect I'm talking about. > > > > Spencer > > > > ----- Original Message ----- > > From: "Pekka Nikander" > > To: "Dave Crocker" > > Cc: > > Sent: Wednesday, November 19, 2003 11:50 AM > > Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal > > > > > Dave, > > > > > > > PN> However, I am also worried about potential DoS and other > > > > PN> security issues. To me, it looks like a bad idea of allowing > > > > PN> all of the upper layer protocols to add or remove addresses > > > > PN> from SLAP. Updating (soft) address state is probably fine, > > > > PN> but both adding and deleting addresses is potentially > > dangerous. > > > > > > > > Please elaborate on your concerns. > > > > > > It's mostly gut feeling right now. I have to do some analysis > > > before I can say much more, and I don't have that time right now. > > > Maybe reading Erik's threat draft would give some insight? > > > > > > > My assumption is that the apps each has at least the requisite, > > basic > > > > "authentication of exchange continuity" that routing-based IP > > validation > > > > provides. > > > > > > Well, while that may suffice as a baseline, it may still have > > > some issues. Like what if some applications have better security > > > properties than others? In that case you could use an application > > > with weaker security to confuse the SLAP state in order to launch > > > an attack against a more secure application. > > > > > > > So all I can guess is that the danger you fear is the general one > > of > > > > having too many participants (applications and transport > > add/delete > > > > mechanisms) and that any one of them can do a lot of damage. > > > > > > More or less yes. But there are probably details, and they > > > need to be worked out. > > > > > > > That's why > > > > I think it would be great to try to standardize a single control > > > > protocol, but permit it to be used over a variety of mechanisms > > (layer > > > > 3.5, transport, and even apps.) > > > > > > I agree that it would be great to standardize a single control > > > protocol. However, I am not so sure whether it would be great > > > to permit it to be carried over a variety of mechanisms. > > > > > > One particular problem with security is that it is not composable, > > > in general. That is, if you have a perfectly secure mechanism A, > > > and another perfectly secure mechanism B, putting them together > > > into A + B (where + is some sort of a composition operator) may > > > result in a system that is not secure any more. (I am not saying > > > that it is not composable in this particular case. I am merely > > > saying that we don't know before we've done some analysis.) > > > > > > --Pekka Nikander > From owner-multi6@ops.ietf.org Thu Nov 20 10:32: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 KAA09426 for ; Thu, 20 Nov 2003 10:32:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMqln-000FDJ-VC for multi6-data@psg.com; Thu, 20 Nov 2003 15:30:59 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMqlb-000FCm-7x for multi6@ops.ietf.org; Thu, 20 Nov 2003 15:30: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 hAKFbIf13697; Thu, 20 Nov 2003 07:37:18 -0800 Date: Thu, 20 Nov 2003 07:30:35 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <3852771321.20031120073035@brandenburg.com> To: "Spencer Dawkins" CC: multi6@ops.ietf.org Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal In-Reply-To: <099601c3af6c$6c4a4000$2c818182@DFNJGL21> References: <11729160049.20031115084555@brandenburg.com> <02ef01c3abb4$e4ffd3e0$2c818182@DFNJGL21> <3FB8C386.4E526EFB@zurich.ibm.com> <3FBB5A85.3020102@nomadiclab.com> <16878086402.20031119083035@brandenburg.com> <3FBBAD6C.5040106@nomadiclab.com> <07d901c3af13$87ac20b0$2c818182@DFNJGL21> <3FBCBAD8.356DE59D@zurich.ibm.com> <099601c3af6c$6c4a4000$2c818182@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Spencer, SD> - protecting different users of multi6 on a single node from each ... SD> - protecting different users of multi6 on a single node from each ... SD> - protecting all the users of multi6 on a single node from attackers The fact that SLAP involves multiple instances of the control protocol does not necessarily mean that the instances are under the control of different users. Of course, a user can take over the kernel of a machine, but there is nothing we can do about that problem. So, the normal scenario is that the control protocol instantiations are running in the operating system. Different users might be the cause of having multiple instantiations, just like they might be the cause of multiple TCP connections. But that does not mean the users have special priviledges over each other. Note that the pool of TCP connections is "shared" state, of exactly the type that we have with SLAP. Do we view that shared, TCP pool as a security risk? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Nov 20 11:06: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 LAA10832 for ; Thu, 20 Nov 2003 11:06:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMrIQ-000HCb-CZ for multi6-data@psg.com; Thu, 20 Nov 2003 16:04:42 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMrID-000HBk-RR for multi6@ops.ietf.org; Thu, 20 Nov 2003 16:04:29 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAKG4PPh003373; Thu, 20 Nov 2003 09:04:26 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hAKG4MQ04553; Thu, 20 Nov 2003 17:04:22 +0100 (MET) Date: Thu, 20 Nov 2003 08:03:05 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Some Comments on ID/Loc Separation Proposals To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200311190507.hAJ57mYp020462@ginger.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I will suggest again that we take "identifier" to mean "name with basically > no properties/functionalities" (other than identfying the thing which it > names). To allow me to be precise hereo, I'll use the term "NF-identifier" > when I want this meaning. Two points The folks in this WG seems to have gravitated to using the term "identifier" to mean the name of a host (or stack). I sometimes use the term "IP identifier" to make it clear where in the stack it is relevant. I don't know if it makes sense to use some other term at this point in time; we do need to know what we mean and write it down. I don't know if there is any utility to NF-identifiers. All uses of identifiers I can think of at least need some way to verify to whom the identifier has been assigned. That might be because I'm thinking about what you call names of objects and not pure identifiers. Thus knowing where an NF-identifier would be useful would help clarify things in my head. Erik From owner-multi6@ops.ietf.org Thu Nov 20 12:30: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 MAA14697 for ; Thu, 20 Nov 2003 12:30:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AMsbx-000MY1-CH for multi6-data@psg.com; Thu, 20 Nov 2003 17:28:57 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AMsba-000MWA-HZ for multi6@ops.ietf.org; Thu, 20 Nov 2003 17:28:34 +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 hAKJXOOt034997; Thu, 20 Nov 2003 11:33:24 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hAKHSHYB014876; Thu, 20 Nov 2003 09:28:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Some Comments on ID/Loc Separation Proposals Date: Thu, 20 Nov 2003 09:28:17 -0800 Message-ID: Thread-Topic: Some Comments on ID/Loc Separation Proposals Thread-Index: AcOvgZPVpDIQhqOhScawIUYBCBY16wACZp9w From: "Tony Li" To: "Erik Nordmark" , "J. Noel Chiappa" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Erik, Several folks have asked us how NOID would work with respect to "hosts" that appear to be a single entity yet are=20 implemented using load-balancers and multiple actual servers. In this case, what does an "identifier" bind to? =20 Noel is trying to make a semantic distinction between an identifier that might be bound to one particular server in the group and a different identifier that would be bound to the entire "entity" of a balancer and servers supporting a particular address. While I think that this is an interesting and useful distinction, I also think that we have bigger fish to fry at the moment. Tony | -----Original Message----- | From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]=20 | Sent: Thursday, November 20, 2003 8:03 AM | To: J. Noel Chiappa | Cc: multi6@ops.ietf.org | Subject: Re: Some Comments on ID/Loc Separation Proposals | =20 | =20 | > I will suggest again that we take "identifier" to mean=20 | "name with basically | > no properties/functionalities" (other than identfying the=20 | thing which it | > names). To allow me to be precise hereo, I'll use the term=20 | "NF-identifier" | > when I want this meaning. | =20 | Two points | =20 | The folks in this WG seems to have gravitated to using | the term "identifier" to mean the name of a host (or stack). | I sometimes use the term "IP identifier" to make it clear=20 | where in the | stack it is relevant. | I don't know if it makes sense to use some other term at=20 | this point in time; | we do need to know what we mean and write it down. | =20 | I don't know if there is any utility to NF-identifiers. | All uses of identifiers I can think of at least need some way to | verify to whom the identifier has been assigned. That might=20 | be because I'm | thinking about what you call names of objects and not pure=20 | identifiers. | Thus knowing where an NF-identifier would be useful would=20 | help clarify | things in my head. | =20 | Erik | =20 | =20 | =20 From owner-multi6@ops.ietf.org Fri Nov 21 13:26: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 NAA25504 for ; Fri, 21 Nov 2003 13:26:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANFxW-000PkC-6B for multi6-data@psg.com; Fri, 21 Nov 2003 18:24:46 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANFxC-000PjX-9L for multi6@ops.ietf.org; Fri, 21 Nov 2003 18:24:26 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hALIOCPh014447; Fri, 21 Nov 2003 11:24:13 -0700 (MST) Received: from par (par.Eng.Sun.COM [129.146.89.82]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hALIOAQ15446; Fri, 21 Nov 2003 19:24:10 +0100 (MET) Date: Fri, 21 Nov 2003 10:23:54 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Some Comments on ID/Loc Separation Proposals To: Tony Li Cc: Erik Nordmark , "J. Noel Chiappa" , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Several folks have asked us how NOID would work with respect > to "hosts" that appear to be a single entity yet are > implemented using load-balancers and multiple actual servers. > > In this case, what does an "identifier" bind to? If the load balancing is transparent - with one IP address for the service - then the identifier would bind to the load balancer and the LB effectively has a private interface with actual servers. Thus that case is out of scope. If the load balancing is visble to the clients as multiple different IP addresses then there is an pen issue and an opportunity that is pointed out in the NOID draft. In this case with NOID you can have multiple identifers=FQDNs www.example.com for the service wwwN.example.com for each of the N servers Since we propose adding a new "M6 capable" RR in the DNS we have the option of making that new RR help distinguish between case of multiple locators assigned to the same host/stack and multiple locators assigned to different hosts/stacks providing the service. An example (probably not be best approach) of how this could be done is to have the M6 RR contain the FQDNs for the host (the set of wwwN above) and a lookup of the www1 etc would return the locators for that host. Thus each host would have a unique FQDN, which would be part of the "cost" of using NOID together with this form of load balancing. Other schemes might be able to use other approaches. For instance, in CB64 all the locators for all the nodes could be in the AAAA RRset for www.example.com and the client can see whether there is one or multiple hosts by comparing the 64-bit hash of the public key; those AAAA RRs with the same hash are locators for the same host. Hence the M6 layer can limit rehoming to be between locators assigned to the same host. Thus I think multihoming is an opportunity to make the destinction between services and host names in the DNS more clear for multihomed sites. Erik From owner-multi6@ops.ietf.org Sat Nov 22 14:34: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 OAA19173 for ; Sat, 22 Nov 2003 14:34:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ANdS7-000Jum-Ay for multi6-data@psg.com; Sat, 22 Nov 2003 19:29:55 +0000 Received: from [160.36.56.50] (helo=klutz.cs.utk.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ANdRv-000JuC-2T for multi6@ops.ietf.org; Sat, 22 Nov 2003 19:29:43 +0000 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8C60FAFE32; Sat, 22 Nov 2003 14:29:42 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17812-14; Sat, 22 Nov 2003 14:29:41 -0500 (EST) Received: from cs.utk.edu (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 82763AFC91; Sat, 22 Nov 2003 14:29:37 -0500 (EST) Date: Sat, 22 Nov 2003 14:30:14 -0500 Subject: Re: Some Comments on ID/Loc Separation Proposals Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Keith Moore , "Erik Nordmark" , "J. Noel Chiappa" , To: "Tony Li" From: Keith Moore In-Reply-To: Message-Id: <4B93209E-1D22-11D8-89BF-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps there are bigger fish to fry, but it's absolutely necessary to make that distinction before we can make significant progress in separating IDs from LOCs. You need both kinds of identifiers. I informally think of them as "initial identifiers" vs. "connection endpoint identifiers", the former being an identifier associated with the (perhaps virtual) host that you initially attempt to contact; the latter being an identifier associated with the particular host that maintains the state necessary to continue conversations in progress. Such state may be at the kernel or the application level. > Several folks have asked us how NOID would work with respect > to "hosts" that appear to be a single entity yet are > implemented using load-balancers and multiple actual servers. > > In this case, what does an "identifier" bind to? > > Noel is trying to make a semantic distinction between an > identifier that might be bound to one particular server in > the group and a different identifier that would be bound to > the entire "entity" of a balancer and servers supporting > a particular address. > > While I think that this is an interesting and useful distinction, > I also think that we have bigger fish to fry at the moment. From owner-multi6@ops.ietf.org Mon Nov 24 05:40: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 FAA03127 for ; Mon, 24 Nov 2003 05:40:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOE6V-0000xP-0F for multi6-data@psg.com; Mon, 24 Nov 2003 10:38:03 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOE6H-0000wc-6X for multi6@ops.ietf.org; Mon, 24 Nov 2003 10:37:49 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hAOAbiBs048666 for ; Mon, 24 Nov 2003 10:37:45 GMT Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hAOAYv33208662 for ; Mon, 24 Nov 2003 11:34:57 +0100 Received: from zurich.ibm.com (dhcp21-96.zurich.ibm.com [9.4.21.96]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA68090 for ; Mon, 24 Nov 2003 11:34:56 +0100 Message-ID: <3FC1BCA3.F0FFC270@zurich.ibm.com> Date: Mon, 24 Nov 2003 09:09:07 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: <4B93209E-1D22-11D8-89BF-000393DB5366@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There is an abstract distinction between 1) identifiers used for rendez-vous 2) identifiers used for binding and 3) identifiers used to maintain a session after binding. Historically we thought of FQDNs being in 1:1 correspondence with IP addresses, except that we normally used the FQDN for rendez-vous, and the IP address for binding and session maintenance. Load balancing, anycast, and virtualization seem to have split apart the three functions. Rendez-vous and binding have already occurred before multihoming enters the picture. I think multi6 only needs to consider the session maintenance ID and I ask people not to get distracted by the rendez-vous ID or the binding ID in this discussion. (In TCP, the session maintenance ID is the IP address, and in SCTP it's the default primary transport IP address, in fact.) Brian Keith Moore wrote: > > Perhaps there are bigger fish to fry, but it's absolutely necessary to > make that distinction before we can make significant progress in > separating IDs from LOCs. You need both kinds of identifiers. I > informally think of them as "initial identifiers" vs. "connection > endpoint identifiers", the former being an identifier associated with > the (perhaps virtual) host that you initially attempt to contact; the > latter being an identifier associated with the particular host that > maintains the state necessary to continue conversations in progress. > Such state may be at the kernel or the application level. > > > Several folks have asked us how NOID would work with respect > > to "hosts" that appear to be a single entity yet are > > implemented using load-balancers and multiple actual servers. > > > > In this case, what does an "identifier" bind to? > > > > Noel is trying to make a semantic distinction between an > > identifier that might be bound to one particular server in > > the group and a different identifier that would be bound to > > the entire "entity" of a balancer and servers supporting > > a particular address. > > > > While I think that this is an interesting and useful distinction, > > I also think that we have bigger fish to fry at the moment. From owner-multi6@ops.ietf.org Mon Nov 24 15:46: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 PAA28740 for ; Mon, 24 Nov 2003 15:46:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AONZA-000CSl-MN for multi6-data@psg.com; Mon, 24 Nov 2003 20:44:16 +0000 Received: from [195.43.225.73] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AONYw-000CRv-A8 for multi6@ops.ietf.org; Mon, 24 Nov 2003 20:44:02 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id hAOKhrL4003604; Mon, 24 Nov 2003 21:43:56 +0100 (CET) Date: Mon, 24 Nov 2003 21:43:49 +0100 Subject: Re: delayed multihoming/mobility set-up Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Pekka Savola From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >>> Uhh, could you clarify how this relates to this subject? I think >>> I see a few ways to tie these together, but I'm not sure what your >>> point is.. >> >> ( I was a bit fast there, to much mail to read and catch up with) >> >> Well the point I was after was your discussion on when a connected >> session should expect connection survivability. In todays IPv4/IPv6 >> internet, a connection passing over a EGP boundary (and I guess in >> worst case even inside ASes) will have to take the route >> cancellation in effect. This means that you will always have to >> worry about this. So the last you said was : >> >>> Note that in low-mobility or site multihoming scenarios you don't >>> expect the the multihoming to be required *immediately*; the risk >>> increases in proportion to the time. >> >> And I was pointing out that you can't expect it to be immediate in the >> case above. > > No, this does not make sense. > > I'm trying to guess what point you're making. I can see two > possibilities which neither clearly falls inside your text: > > 1) "if a route goes down, how long does it take to be able switch to > the other connection if the protocols supported transport > survivability" > > 2) "if a route goes down, and comes back up, how long does it take > until it's fully usable everywhere?" I was aiming for statement #2 here. > Both of these are interesting, but not directly related to the > question I raised, AFAICS. Maybe I didn't understand your original question correct then. > The proposal was all about stable configuration. Instead of setting > up connection survability immediately when setting up the connection, > it would only be done for connections that pass certain criteria check > (e.g. last more than T minutes). That way, if there is a failure > inside 0 ... T minutes from the startup of the connection, the > connection in question will fail. If not, it'll just switch to the > another connection transparently, with the possible problems switching > connections may have. This is just about optimizing away the > connection survability for "statistically" short-lived sessions unless > you really care about that feature. My point was that in order to determine what a useful "timeout" value would be, it has to be longer than the risk of cancellation - depending on where in the network you are and what type of sessions we are talking about. If T is to low, once you think you have a stable route, it might get cancelled. Is this important for end-nodes? Not necessarily. If the nodes gets a locator assigned to it - it might. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP8JtiKarNKXTPFCVEQJ8CACghSJau2h4/9MCG7ooLHpHIrhJiOgAni4p R8L4SATpaBZ968aIp3KFmbuI =KCPj -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Nov 24 16:12:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00396 for ; Mon, 24 Nov 2003 16:12:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AONzm-000EHS-Td for multi6-data@psg.com; Mon, 24 Nov 2003 21:11:46 +0000 Received: from [195.43.225.73] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AONza-000EGm-Bw for multi6@ops.ietf.org; Mon, 24 Nov 2003 21:11:34 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id hAOLBOL4003619; Mon, 24 Nov 2003 22:11:27 +0100 (CET) Date: Mon, 24 Nov 2003 22:11:19 +0100 Subject: Re: delayed multihoming/mobility set-up Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Pekka Savola , multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3FBB7560.EFBB01AB@zurich.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What I think we need to do at some point in the future though, is to define what we _can_ do. Agreed, that is far way and not what we should focus on now. - - kurtis - On onsdag, nov 19, 2003, at 14:51 Europe/Stockholm, Brian E Carpenter wrote: > What we should probably be clear about is that multi6 > is not aiming to support instant QOS restoration. In other words > we are not aiming to be qualified for emergency services and not > even for fast signalling (which is what SCTP is aimed at). > > Brian > > Pekka Savola wrote: >> >> On Mon, 17 Nov 2003, Kurt Erik Lindqvist wrote: >>>> Uhh, could you clarify how this relates to this subject? I think >>>> I see a few ways to tie these together, but I'm not sure what your >>>> point is.. >>> >>> ( I was a bit fast there, to much mail to read and catch up with) >>> >>> Well the point I was after was your discussion on when a connected >>> session should expect connection survivability. In todays IPv4/IPv6 >>> internet, a connection passing over a EGP boundary (and I guess in >>> worst case even inside ASes) will have to take the route >>> cancellation in effect. This means that you will always have to >>> worry about this. So the last you said was : >>> >>>> Note that in low-mobility or site multihoming scenarios you don't >>>> expect the the multihoming to be required *immediately*; the risk >>>> increases in proportion to the time. >>> >>> And I was pointing out that you can't expect it to be immediate in >>> the >>> case above. >> >> No, this does not make sense. >> >> I'm trying to guess what point you're making. I can see two >> possibilities which neither clearly falls inside your text: >> >> 1) "if a route goes down, how long does it take to be able switch to >> the other connection if the protocols supported transport >> survivability" >> >> 2) "if a route goes down, and comes back up, how long does it take >> until it's fully usable everywhere?" >> >> Both of these are interesting, but not directly related to the >> question I raised, AFAICS. >> >> Could you try to elaborate a bit more? >> >> The proposal was all about stable configuration. Instead of setting >> up connection survability immediately when setting up the connection, >> it would only be done for connections that pass certain criteria check >> (e.g. last more than T minutes). That way, if there is a failure >> inside 0 ... T minutes from the startup of the connection, the >> connection in question will fail. If not, it'll just switch to the >> another connection transparently, with the possible problems switching >> connections may have. This is just about optimizing away the >> connection survability for "statistically" short-lived sessions unless >> you really care about that feature. >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP8Jz+6arNKXTPFCVEQLCwACgjCRXBA1hW324bus3rCKoWxu1RfQAoLl0 2E8/VISCy9Bg23+wEiqj11Q8 =7b1B -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Nov 25 01:17: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 BAA22371 for ; Tue, 25 Nov 2003 01:17:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOWTk-000HlB-KG for multi6-data@psg.com; Tue, 25 Nov 2003 06:15:16 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOWTO-000HjX-3Y for multi6@ops.ietf.org; Tue, 25 Nov 2003 06:14:54 +0000 Received: from gih505.telstra.net (rsdhcp13.telstra.net [203.50.0.207]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id hAP6EMRc091544; Tue, 25 Nov 2003 17:14:29 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20031125171242.01ea2fd0@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Nov 2003 17:13:48 +1100 To: Kurt Erik Lindqvist , Brian E Carpenter From: Geoff Huston Subject: ascii-formatted version of the multi6 minutes from IETF58 - please send me corrections Cc: multi6@ops.ietf.org In-Reply-To: References: <3FBB7560.EFBB01AB@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Multi6 Working Group -------------------- Session 1 Tuesday 11 November Agenda: * Agenda Bashing and Administrivia * Design Team 2 Update - Marcelo Bagnulo / David Kessens * Dave Crocker - draft-crocker-mast-analysis-01.txt - draft-crocker-mast-proposal-01.txt * Arifumi Matsumoto * Masataka Ohta - draft-ohta-multihomed-isps-00.txt * Kenji Ohira - draft-ohira-assign-select-e2e-multihome-02.txt - some research results about implementation of SABR Session 2 Wednesday 12 November Agenda: * Erik Nordmark - draft-nordmark-multi6-noid-01.txt - draft-nordmark-multi6-sim-01.txt - draft-nordmark-multi6-threats-00.txt Agenda Bashing and Administrivia ================================ Scribe: Geoff Huston WG Chair announcement: Sean Doran has stepped down as co-chair of the Working Group. Brian Carpenter is co-chair for the working group for this week. Shortened agenda for Tuesday to allow a break to attend the IPv6 WG meeting RFC3582 (Goals for IPv6 Site-Multihoming Architectures) to measure proposals has been published. Each presenter has been asked to measure their proposal against the parameters described in this document Decisions / Outcomes ==================== 1. The WG should evolve the threat work (as documented in nordmark-multi6-threats) with solution development. 2. Chairs to set a date for the submission of ideas regarding approaches to multi-homing - mid-January appears to be the preferred deadline. 3. Take the topic of evaluation criteria for WG to use to the mailing list. 4. Eliot Lear to prepare a draft on criteria for analysis of MH proposals. 5. Jim Bound to draft a proposal using SCTP + NOID with TCP emulation layered above SCTP. 6. Pekka Nikkander to prepare a HIP based MH draft 7. WG to consider how to converge ('marry') these proposals into a WG proposal from this set of individual proposals using an approach of functionality analysis of the proposals. Presentations ============= Design Team 2 Update -------------------- Presentation - Design Goals outlined, with a reduced set of requirements as described in draft-huitema-multi6-experiment-00. The approach described as incremental with minimal changes to external hosts. - testbed described - Normal Operation - source address based routing, load sharing and policing - fault Tolerance - 2 cases: outage in link between mh sites and direct ISP - RFC3178. Outage in other elements is reference to RFC3484 from externally-initiated comms. Internal initiated communications retry with a difference source address - summary - a lot of features that only require some additional configurations. Internal hosts require modifications for internally- initiated communications. External hosts require changes to preserve comms in external-initiated communications - The capability against RFC3582 presented Clarification questions: How is the ingress filtering from the ISPs circumvented? Source address-based routing in the site's boundary routers - packets will be forwarded from one exit router to another based on source address. How would this work if the routers were not on the same subnet? The model assumes a subnet in this presentation, and the remote case may require additional internal routing capabilities Design Team 1 Update -------------------- Presentation - extensive update provided in Vienna - this one is more succinct. Erik Nordmark will cover the substantive issues in the subsequent WG sessions - the essential element is the use of explicit identifier / location identifier split using a shim layer to map between the two identity spaces. - the design team is considering a number of aspects: threats, - threats to be addressed in next session - issues similar to mobility in v6, but mobility approaches can't be directly mapped due to multi-homing differences - NOID - no identifier beyond FQDN. FQDN is not to be loaded into packets, and upper layer protocols chose a locator and the shim layer allows the upper layer to continue to use this locator even in the event of home changes. - CB128 - the shim layer performs a reverse -> forward -> reverse DNS lookup - another approach uses a 128 bit crypto-id, similar in some form to the HIP approach, but with different mechanisms. - locators can't be found from IDs in this case - CB64 - alternate approach with 64 bit hashes - cryptoid - similar to cb64 with internal structure within the identity space. Locator and ID bits can appear on the wire. Analysis -------- Dave Crocker - framework for the approach is a similarity in multi-homing and mobility. The stated difference is one of the time base for the multiple addresses in play. - lengthy considerations sections - infrastructure approach uses an agent that works on behalf of one end of the communications - shim or wedge is a full function layer that sites only in the end- points, not in the transit operation. Mast is one of these. HIP is another, and there are some other 4 or 5 noted. The end-to-end communications is without intermediaries. The shim layer is a rendezvous-styled operation - transport layer approaches - comparisons of these approaches include the match against the goals document, and it is claimed that there are more considerations here. MAST ---- Dave Crocker - goal of maintaining locator pools. The application's awareness of the locator pool is mute. Claimed to make renumbering easier - terminology listed. multi-addressing is claimed to be relationship across multiple packets that pass across the infrastructure. - identifier to locator mapping is one aspect. locator selection is an open research topic, if there is more that one locator. - architecture knowledge of multiple locators goes to endpoint modules within the host, but no further. The endpoint module will map from an eid string to a locator. Each host loads its locator as an 'open question'. NAT traversal is described by a mirror query to the remote end to locate the own external locator. DNS and presence is included as a means of getting a current locator using a presence- style service. - operator - locator discovery and locator selection. The discovery operation is 'normal' DNS for fixed. DNS + dynamic mechanism to retrieve current locator. Locator interruption can be undertaken by MAST peer-to-peer - locator pool maintained through MAST mechanism - security only equal to IP. The recognition of 2 packets belonging to the same sequence have a number of choices. For global persistency global DNS is proposed. A NONE is proposed to be sufficient for mobility - table of comparison presented. TCP Multi-Home Option --------------------- Arifumi Matsumoto - DT2 - host-centric model, source-address based routing within mh site. Improved TCP is necessary and claimed to be simple. SCTP is not TCP as there is no interoperability between SCTP and TCP endpoints in a single session. This approach is TCP MH Options - TCP - add MH option only. claimed to allow rapid recovery from transmission failure. after RTO timeouts the pool of source addresses is used to use a new path - protocol exchange illustrated. SYN packet contains MH option that includes the intention to use different source addresses. - bit format for MH options presented. - path switch triggered on TCP timeout or ICMP error - path discarded under certain conditions - security considerations: redirection attack - claimed to be easily prevented in this approach. Session hijack protected by strict MH- Serial number management, backing out when incorrect serial received. - not the consensus of the DT2 team. - table of comparison presented Clarification questions: * What to do with UDP? UDP need not be considered within this context. * Why are TCP enhancements is showing up here first? This should be targeted at transport area! (Chair) This would be referred over if we proceed in this way * Redirection attack is possible on guessing the 16 bit number. Protection is based on not being able to guess this 16 bit number, correct? yes, although there are other protections here to reset the TCP session Global Routing Table Size ------------------------- Masataka Ohta - the goal in multi6 is to make the global routing table small - how small at the lower limit? - small routing table is claimed to be a desirable goal - mh is multiple links with separated sites for boundary routers - full route sets are necessary on the 'site backbone' - a full routing table on hosts allow a host to carry unreachable locators and metrics for each locator - source locators must be 'proper' - let hosts select the source locator, routing protocol to carry source locator to be used for each destination - policy control is 'not so global' - the global routing table size should be larger than the number of Tier 1 ISPS. An upper limit should be imposed by memory and bandwidth of a host. Presentation makes some assumptions to calculate this figure, and postulates that the global routing table should be upper limit bounded at 8,000 entries in the global routing table. - table of comparisons Source-Based Routing -------------------- Kenji Ohira - characterizes some solutions as above IP and below TCP, others are TCP augmentation /alteration - target is small stub networks, not ISP multi-homing - method proposed of hierarchical addressing and source-based routing - updates from original draft listed - table of comparison provided Lin6 ---- Masahiro Ishiyama - location in dependant networking - implementations - uses globally unique id in low 64 bits and network prefix in upper 64 bits - locator resolution uses a new agent - a mapping agent - to perform this resolution - assume that the ID is statically assigned - now working on a dynamic assignment mechanism with a crypto base with the mapping agent Multi6 Threats -------------- Erik Nordmark Why? - adding this additional level of indirection to the architecture opens up security vulnerabilities - can be used to divert traffic and potential denial of service to a 3rd party - similar to mobile ipv6, but not identical Today's assumptions - how good security - no better, but not making it any worse - option to use the DNS and trust what comes back - applications that trust the source IP addr of received packets without any verification of information - these are vulnerable to various forms of attack - the existence of reverse+forward DNS resolutions was noted - using security mechanisms and their notions of identity - opportunistic security without access control Redirection threats today - compromise the routing protocol - compromise the DNS - ND/ARP spoofing - attack a node on the path - mh solution should not make things any worse Flooding attacks today - send packets to target - self-flood or flood path to self (e.g. ACK spoofing) - reflection attack where A can direct B to send to C, with out without amplification - we don't need to fix these problems, but should avoid making them worse New attack vectors - redirect existing flow to a new locator - predictive attack (if A will talk to B, C claims to be A before A communicates with B) - replay attack - black hole by broadcasting a broken id/locator binding 3rd party DOS attacks - redirection to flood a 3rd party - possibly a check that the endpoint is reachable at the location prior to data flow as a mitigation Accepting Packets - With ingress filtering at all locations its hard to inject a spoofing packets - mh potentially allows any source, compromising ingress filtering Multiple Multi6 Approaches -------------------------- Erik Nordmark - A number of solution proposals with inherent trade-offs - NOID, SIM and CB64 as a shim between ULP and IP, below fragmentation, AH, ESP and destination options, and above IP 'routing' - Application / ULP uses an ID that is stable for a session or longer. This IS is termed the 'AID' - mh uses different locators over time - rewriting of source locators to detect changes - Uses DNS without changes NOID - no identifier in any packets. The FQDN is the node identifier, and a set of locators are used on the wire. - The ULP uses a single locator during a communications - different connections use different locators to allow load-sharing - shim layer can use different locators on the wire - receiver needs to rewrite locator according to current context NOID - DNS - uses reverse + forward to prevent redirection attacks - this provides the FQDN and a working reversed - without this you cam communicate with a mh NOID remote point but cannot be mh yourself - needs R6 RR into the DNS - no packet overhead for data packets - uses flow id plus next header values - conceptually this is similar to an extension header to operate at the shim layer - new ICMPv6 packets for the handshake - NOIDS walk through in presentation SIM concepts - 128 bit identifier, a hash of a public key, akin to HIP, created autonomously - Upper Layer Protocol uses these identifiers - shim layer needs a context tag, and is seeded from the DNS - AAAA records plus new SIM ID RR type to collect identifier - In order to prevent redirection, the public key crypto scheme is used, as per CGA in SEND WG. Not needed until locators change. - Also uses an explicit extension header - new packets for handshake - protocol exchange walk through CB64 - middle ground between NOID and SIM - IP addresses with 64bit hash of a public key - previously discussed in SEND and MobileV6 High Level choices: - Is it beneficial to introduce a new IP space as in SIM/HIP - Or use multiple addresses - DNS for verification issues? vs public key crypto? or no verification? - Use of local locators? Clarification questions: * Do you assume symmetric routing in these models? No. * Do you assume DNSSEC in these models? No - but use of DNSSEC would improve the security of the use of DNS * For SIM you claim no PKI is required, but a new DNS RR is returned - Is this a public key record? No keys are stored in the DNS in this approach. Its a derivative rather than the actual key. The trust in NDS in no change * The threats work said "don't make things worse". Those protocols are being secured right now. To what version of these protocols are you referring to - secured or unsecured? If introduced today, we don't want to make things worse than today, or in the future. General Discussion ================== 1. Cutoff date for Proposals? Kurt Lindquist (chair): The issue is for how much longer do we keep on seeing the same presentations. The cutoff for proposals to be submitted as drafts for WG consideration is proposed by the chairs to be year end. Brian Carpenter (chair): Call for comment on this proposed rule Keith Moore: Serious reservations for this call. Nothing is serious enough in the proposals to be a 'real' solution. IN the past a late proposal has been a drastic improvement with eager WG adoption. Its premature to reduce the number of proposals. Jim Bound: Process point: I've read the specs - I don't need to hear this. Matsataka Ohta: This is fine for my proposal, but no good for others as it promotes a step-by-step approach. The NOID approach does not address interaction with mobility, for example. Brian Carpenter: The proposals so far are not ready for evaluation, but I'm not willing to accept more - they are two different points. I don't know any way to make things happen without deadlines. If no deadline then we will never complete the proposal stage. Erik Nordmark: The thing you want to avoid is new proposals that are similar to previous proposals in all but name. But different ways of doing things should not be cut off. Maybe look at diffs to current proposals rather than complete proposals Eliot Lear: 31 Dec is very close. If so then why not make the proposal cut today? Brian Carpenter: we are aware of one draft that did not make it. Eliot Lear: Could you please include HIP is this set of proposals for WG consideration? Keith Moore: The scheduling concern is fine for understood problems. But if the problem is not understood, then setting deadlines for proposals is not a solution path Christian Huitema: What concerns me is the focus on proposals. So far there are complete architecture presentations, and no modular approach has been presented so far. Maybe modularity of the solution process would help. Some things are constant/generic - eg ingress filtering, security. None of the solutions seen so far provide for incremental deployment - none have a business model that drives incremental deployment. Brian Carpenter: This concept of a cutoff date for proposal is not being accepted by the WG. Instead could we set a target date for ideas to get ideas out so we avoid a situation where everything arrives at a face-to-face meeting. Reasonable? WG: silence and nods Decision: Chairs to set a date for the submission of ideas regarding approaches to multi-homing 2. Evaluation Criteria Randy Bush: we need to consider what e2e connection setup, referrals (passive ftp), both ends attempt simul connect. NOID appears to be incompatible with local addressing or two-faced DNS - I'm not sure that this is a bad thing Kurt Lindquist: Remind the WG on desired properties of a solution (see slide) How to pick a proposal? RFC 3582 is one tool to do so Brian Carpenter: Some of these questions raised are missing in that RFC - the WG may want use a longer list of criteria Kurt Lindquist: At some point we still need to pick a solution - we'll take this to the mailing list to discuss these in depth - more merit may be an outcome of combining aspects of these proposals Decision: Take the topic of evaluation criteria for WG to use to the mailing list. 3. General Discussion of Proposals Erik Nordmark: thinking about how referrals work is very important - each approach is different. Technical differentiator. In NOID, The extra 8 bytes uses the flow id on the proposal. If you believe that the rewriting of the ID by the receiver is good, then some help in the header to flag this permission would be good. Brian Carpenter: If we go down the path of this solution we should discuss the version number at some stage Erik Nordmark: 2 faced DNS and local addresses. NOID says you get the id info from the DNS. Added words suggesting what happens when you get inconsistent answers from the DNS? Maybe you need a mechanisms to exchange the info you received. Or maybe sprinkling in some other security technique into this may be useful. This has not been explored in any detail. Matsataka Ohta: I like my own security requirement drafts. I have objections to his draft. redirection attack. The other concern is that the security analysis is complete. Brian Carpenter: please distinguish between threat analysis and solution Tony Li: Our proposal ensure incremental deployment by allowing each host to advertise its capabilities. Ilijsch van Beijnum: There are proposals where you need to store info in the DNS that are not there today. Proposals to allow systems to interact before interaction. Both at the same time is not ok. Keith Moore: Use of DNS - likely that DNS is part of any successful proposal. DNS names are service names as well as host names. not just host names. Rebinding to the DNS IP addr is a dubious assumption. In practice DNS is not universally consistent. Assuming that DNS is a good mechanism for addressing updates and changes is not a good assumption. Brian Carpenter: use of reverse DNS tree? Keith Moore: That would be unwise. Jim Bound: Did not understand the use of compression in the flow-id. The SCTP protocol combined with NOID may well be the answer. I'd IKE to propose a submission to the WG on SCTP + NOID. Brian Carpenter: As SCTP is not TCP this would imply that there would be no TCP in your approach Jim Bound: I had in mind SCTP simulating / emulating TCP Brian Carpenter: It would be nice if we had a draft on this. Brian Carpenter: Erik is correct - the only case where things look strange is where the flow-id is exported in a coarse-grained style. Multiple TCP sessions using the same flow-id will cause all TCP sessions to suffer the same mh fate Christian Huitema: incremental deployment. In all the proposals you have to assume a world in which IPv6 is already deployed. The m6 proposal is an add on to a deployed network. You need an immediate benefit to yourself without requiring other sites to also upgrade. i.e. one-armed mechanisms that require no change to the other end. e.g. advertise >1 addresses in the DNS and let the other end choose. Want to see a way to solve egress filtering to an other end that cannot do the rewrite trick. Tony Li: egress filtering is orthogonal to the rest of the issues here. They can be applied to all the proposals see so far Dave Crocker: Rarely, I agree with Keith Moore. Need to distinguish between names as a name space and names as a query mechanism. MAs also has incremental adoption, but Huitema defined incremental adoption in a way that MAST is not. We don't have a common shared sense for criteria and terminology. Incremental deployment capability in not on criteria list. Other considerations emerging, and there is more. Theory is any single proposal may be attack on these criteria. We need to get clear what is important and what is not to allow proponents to respond carefully. Kurt Lindquist: The RFC lacks criteria - the WG's evaluation list appears to be bigger than that listed in the RFC.. Brian Carpenter: This is an OPS working group - these are close to operational questions. Crocker: I hear what you said but don't understand it. Ellwyn Davis: Wondering is we are transferring the problem from the data to the control plane. Bootstrapping is a real issue here. It need to be thought through. Matsataka Ohta: I propose that all proposals should address issues already contained in additional to the RFC careful analysis of interaction with DNS. For example in NOID DNS appears, but nothing is mention of DNS as a connectionless protocol using UDP. Section about connectionless UDP is very strange. ok? Keith Moore: coming up with more criteria in a solution - this is good. But if you acknowledge that you are going to compromise in selecting than you will need a lot of help in doing the compromising. The discussion flows around renumbering, mobility, etc, and there is a good chance of conflicting with other efforts Matsataka Ohta: General feeling about design parameters; global routing table size, number of prefixes. Can I have discussion? Brian Carpenter: If we did not care about the number of prefixes we would not have this discussion Randy Bush: (channeling Margaret Wasserman) Isn't there a multi6 draft about requirements? Shouldn't this draft be tuned with this discussion? What are the technical details of these proposals? The HIP BOF did a good effort of comparisons Brian Carpenter: I feel a need for a document for a new set of considerations, need a volunteer for a draft Sean McCleary: What is the expected number of per-host addresses in each proposal and what would push this number upward. Concerned that it may rise to several dozen - I am concerned if it gets to that high point Tony Li: All the proposals are 1 locator per immediate ISP. Not 1 locator per inbound path Eliot Lear: does it matter how many identifier there are? [Several]: no! Margaret Wasserman: I heard Randy channel me. The issues I have are referral (as per passive ftp) and simultaneous TCP connect attempts from each end. Questions about NOID from this perspective. In NOID when if A -> B and B -> A starts up at the same time, state on A with flow ID requires 2 DNS lookups on B and the B -> A connect attempt will be rejected in the meantime. Is this bad? Erik Nordmark: this was an exercise left to the reader. The document has not thought through this scenario in detail. The document talks about state loss and re-establishment efforts. There is a risk of ending up with 2 different contexts. It sounds like the same issue, but not sure. Margaret Wasserman: Have a problem when we completely separate the locators as an ID. How do we know this has occurred. Do we always do the 2 DNS lookups on a referral, or is there state. Erik Nordmark: 2 reasons why this would not work. a) renumbering (long time scale) b) short term (routing). a) deal with it - don't keep these things around forever. Use the FQDN to consult the DNS. A locator without the FQDN is pretty useless. And the DNS reverse should fail in such a case. Referrals and failure simultaneous - you can pass across the id. One approach is the other end to do the 2 DNS thing to retrieve the full set of locators, or the other end could send off the full locator pool Margaret Wasserman: does with work with 2-faced DNS? Erik Nordmark: DNS inconsistencies in responses require you to come to the minimum intersection of the two sets. I've been thinking of a weaker mechanism with some sort of security and some sort of local or global scope. Brian Carpenter: reverse tree reliance? Christian Huitema: This is not a good idea. A cyclic dependency is not what you want. Today's reverse is populated with poor data to a level of around 50%. Not a good idea to rely on this data. Brian Carpenter: multi-homed DNS server? Randy Bush: MH is a lot of hoops. They will get reverse DNS right if its part of the necessary steps. The cyclic dependency is a substantive point. Keith Moore: The rev-DNS tree is an anachronism. There are many forms of relationships in the reverse -> forward, and its not generally an inverse of the forward lookup functions Dave Crocker: domain names are many things. Any global consistent name space requires a query service. Use a new one or a new one? Randy Bush: put it in BGP! Erik Nordmark: Careful not to create recursion here - need to be careful to use a lookup for locators not identifiers. DNS has its own way of doing that by listing the IP addresses of the name servers. You don't need to use this solution to lookup DNS name servers. I don't understand what the operational issues are. Its an identifier, not a locator. The DNS should check, because things will, just, fall apart. one more thing... mumble.... Matsataka Ohta: I don't want to change current operational practice. When its necessary use DNS reverse, but not mandate it. I actually proposed a way to use TCP options to pass locators which means DNS is not necessary. Christian Huitema: The DNS is used to acquire a set of locators if you have a locator, and so conceptually you could ask a server, the other is to ask your peer. If you ask you peer to get an answer that is not dependant on a server Erik Nordmark: the server is used as a verification to avoid certain forms of DOS attacks. Christian Huitema: I hear you. The attack you describe was an attribute with mobile ipv6 - you do a 2 way handshake with the locator to verify before use, and this defends against he attack. Erik Nordmark: You could this with an exchange - its something to go explore further Randy Bush: what I think I heard from ohta-san the reverse is just increasing your confidence. The cert exchange is just increasing your confidence. But what's going to be different here? Pekka Nikkander: We wanted to discuss the reverse DNS thing. A identifier / locator split will break things. A fix that relies on reverse DNS would be a little bit awkward. Bruce Campbell: The DNS is distributed, but not reliable. Using DNS to load a mh session is not always reliable. This is an instance of middlebox attack Perry Metgzer: True the DNS is not perfectly reliable, nor is IP. Things work without the DNS already, such as nutella. Its unfortunate that we are producing this hairy ball of interdependencies, but it may be the only way. Steve Bellovin: ALIAS BOF about hints - hints are good for optimizations, but they are not reliable directives. As long as it still works if you can't get to the DNS this is better. Iljitsch van Beijnum: We've looking into the DNS for locators or exchange. Another is to just go ahead with TCP and back off into another address on failure, and only on failure. i.e. backoff into this form of exchange Christian Huitema: Privacy, and where to engage this mechanism. Many of the slides think of IP security as a layer above the exchange of locators, yet I can see why want to have a peer discussion but not want intermediaries to know of this. If we do an exchange to move traffic to other locators I'd like to do this with privacy. On the one hand you want to keep the IPSEC session going but protect the information about locators. Dave Crocker: layering shown usage, not control channel Keith Moore: Opposed to Perry's comment. Applications that do not depend on the DNS exist - many of them. The generalization is incorrect, and applications are a broad spectrum, not two types generically. Brian Carpenter: No consensus about the use of reverse DNS in these approaches so far. Margaret Wasserman: Use identifier or id rather weakly here. IP addresses are used within hosts as well as externally Erik Nordmark: Christian Huitema suggested control channel privacy - this is a trade- off. I don't know if confidentiality for the control channel is necessarily the right thing to do. Perry Metzger: This may not add up to better security overall. Architecturally - You need to name state. It can't be IP addresses. DNS labels are a fixed point and work as a named state. Christian Huitema: the point is that we shall not impose a position on the trade- off on privacy. It should be clear that the solution should not _mandate_ that you drop confidentiality. I should have control of what I choose to disclose and this should be compatible with the solution. Erik Nordmark: I understand the mobility concern about disclosure of location. This may be different between disclosure of mh state per se. After all any connection discloses the current connection state in any case. Brian Carpenter: In a paranoid location you may deliberately move the location to take this to a non-disclosed locator. Margaret Wasserman: Why frag over NOID? Erik Nordmark: Not NOID, thats SIM. Margaret Wasserman: why should it be above? Nordmark: The reason you have this flexible system you have the potential risk that different frags do down different paths. If reassembly is done BEFORE source rewrite reassembly is not possible. Brian Carpenter: Bound said - SCTP-based draft on the table. Anyone willing to get a HIP-based draft on the table? Pekka Nikkander: This is an initial draft on this. I'm willing to work on a draft on this as a more specific effort. Brian Carpenter: Need a draft summarizing the criteria we've discussed here. Eliot Lear: I volunteer to write this up Brian Carpenter: Each proposal should self-assess against criteria, as proposed to WG assessment. Brian Carpenter: 31 Dec did not get WG approval, but a rush of proposal 2 weeks prior to next IETF is also tough. 'sometime in January" is a strongly preferred option. Brian Carpenter: Need to think about how to converge ('marry') proposals into a WG proposal from a set of individual proposals. Tony Li: A competition among proposals is a barrier to consensus and rational choice. We should be working in problems and look at salient features, solutions to each of those problems. They may not be in dependant, but thats fine. 'your' vs 'mine' is destructive to working together. Erik Nordmark: What are the pieces: filtering and the right exist. Hints from elements need more work. It may not be a fine cut, but it has promise. Brian Carpenter: maybe we can see similar components in each of the solutions Kurt Lindquist: the security analysis looks common Matsataka Ohta: We need proposals of complete architectures. Brian Carpenter: we are not quite ready to do that yet. Dave Crocker: Working over IPv4 as well could be considered Brian Carpenter: Next Steps: Eliot Lear to prepare a draft on criteria analysis, Jim Bound a SCTP document,Pekka Nikkander to prepare a HIP-based document, i-d publication of design team document, complete gathering of ideas, prepare evaluation criteria as applied to proposals, and then undertake functionality analysis with a view to convergence of WG efforts. WG session adjourned. From owner-multi6@ops.ietf.org Tue Nov 25 01:31:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22656 for ; Tue, 25 Nov 2003 01:31:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOWi3-000IL9-IT for multi6-data@psg.com; Tue, 25 Nov 2003 06:30:03 +0000 Received: from [195.43.225.73] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOWhh-000IKG-MF for multi6@ops.ietf.org; Tue, 25 Nov 2003 06:29:41 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id hAP6TaL4003816; Tue, 25 Nov 2003 07:29:39 +0100 (CET) Date: Tue, 25 Nov 2003 07:29:30 +0100 Subject: Re: ascii-formatted version of the multi6 minutes from IETF58 - please send me corrections Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Brian E Carpenter , multi6@ops.ietf.org To: Geoff Huston From: Kurt Erik Lindqvist In-Reply-To: <5.1.0.14.2.20031125171242.01ea2fd0@kahuna.telstra.net> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks! - - kurtis - On tisdag, nov 25, 2003, at 07:13 Europe/Stockholm, Geoff Huston wrote: > Multi6 Working Group > -------------------- > > Session 1 > Tuesday 11 November > > > Agenda: > * Agenda Bashing and Administrivia > > * Design Team 2 Update > - Marcelo Bagnulo / David Kessens > > > * Dave Crocker > - draft-crocker-mast-analysis-01.txt > - draft-crocker-mast-proposal-01.txt > > > * Arifumi Matsumoto > > > * Masataka Ohta > - draft-ohta-multihomed-isps-00.txt > > > * Kenji Ohira > - draft-ohira-assign-select-e2e-multihome-02.txt > - some research results about implementation of SABR > > > Session 2 > Wednesday 12 November > > Agenda: > > * Erik Nordmark > - draft-nordmark-multi6-noid-01.txt > - draft-nordmark-multi6-sim-01.txt > - draft-nordmark-multi6-threats-00.txt > > > Agenda Bashing and Administrivia > ================================ > > Scribe: Geoff Huston > > WG Chair announcement: Sean Doran has stepped down as co-chair of the > Working Group. Brian Carpenter is co-chair for the working group for > this week. > > Shortened agenda for Tuesday to allow a break to attend the IPv6 WG > meeting > > RFC3582 (Goals for IPv6 Site-Multihoming Architectures) to measure > proposals has been published. Each presenter has been asked to > measure their proposal against the parameters described in this > document > > > Decisions / Outcomes > ==================== > > 1. The WG should evolve the threat work (as documented in > nordmark-multi6-threats) with solution development. > > 2. Chairs to set a date for the submission of ideas regarding > approaches to multi-homing - mid-January appears to be the > preferred deadline. > > 3. Take the topic of evaluation criteria for WG to use to the > mailing list. > > 4. Eliot Lear to prepare a draft on criteria for analysis of MH > proposals. > > 5. Jim Bound to draft a proposal using SCTP + NOID with TCP emulation > layered above SCTP. > > 6. Pekka Nikkander to prepare a HIP based MH draft > > 7. WG to consider how to converge ('marry') these proposals into a WG > proposal from this set of individual proposals using an approach > of > functionality analysis of the proposals. > > > Presentations > ============= > > Design Team 2 Update > -------------------- > > Presentation > - Design Goals outlined, with a reduced set of requirements as > described in draft-huitema-multi6-experiment-00. The approach > described as incremental with minimal changes to external hosts. > - testbed described > - Normal Operation - source address based routing, load sharing and > policing > - fault Tolerance - 2 cases: outage in link between mh sites and > direct ISP - RFC3178. Outage in other elements is reference to > RFC3484 from externally-initiated comms. Internal initiated > communications retry with a difference source address > - summary - a lot of features that only require some additional > configurations. Internal hosts require modifications for > internally- initiated communications. External hosts require > changes to preserve comms in external-initiated communications > - The capability against RFC3582 presented > > Clarification questions: > > How is the ingress filtering from the ISPs circumvented? > Source address-based routing in the site's boundary routers - > packets will be forwarded from one exit router to another based > on source address. > > How would this work if the routers were not on the same subnet? > The model assumes a subnet in this presentation, and the remote > case may require additional internal routing capabilities > > Design Team 1 Update > -------------------- > > Presentation > - extensive update provided in Vienna - this one is more succinct. > Erik Nordmark will cover the substantive issues in the subsequent > WG sessions > - the essential element is the use of explicit identifier / location > identifier split using a shim layer to map between the two > identity > spaces. > - the design team is considering a number of aspects: threats, > - threats to be addressed in next session > - issues similar to mobility in v6, but mobility approaches can't be > directly mapped due to multi-homing differences > - NOID > - no identifier beyond FQDN. FQDN is not to be loaded into > packets, > and upper layer protocols chose a locator and the shim layer > allows the upper layer to continue to use this locator even in > the event of home changes. > - CB128 > - the shim layer performs a reverse -> forward -> reverse DNS > lookup > - another approach uses a 128 bit crypto-id, similar in some form > to the HIP approach, but with different mechanisms. > - locators can't be found from IDs in this case > - CB64 > - alternate approach with 64 bit hashes > - cryptoid > - similar to cb64 with internal structure within the identity > space. Locator and ID bits can appear on the wire. > > Analysis > -------- > > Dave Crocker > - framework for the approach is a similarity in multi-homing and > mobility. The stated difference is one of the time base for the > multiple addresses in play. > - lengthy considerations sections > - infrastructure approach uses an agent that works on behalf of one > end of the communications > - shim or wedge is a full function layer that sites only in the end- > points, not in the transit operation. Mast is one of these. HIP is > another, and there are some other 4 or 5 noted. The end-to-end > communications is without intermediaries. The shim layer is a > rendezvous-styled operation > - transport layer approaches > - comparisons of these approaches include the match against the > goals > document, and it is claimed that there are more considerations > here. > > MAST > ---- > > Dave Crocker > - goal of maintaining locator pools. The application's awareness of > the locator pool is mute. Claimed to make renumbering easier > - terminology listed. multi-addressing is claimed to be relationship > across multiple packets that pass across the infrastructure. > - identifier to locator mapping is one aspect. locator selection is > an > open research topic, if there is more that one locator. > - architecture knowledge of multiple locators goes to endpoint > modules > within the host, but no further. The endpoint module will map from > an eid string to a locator. Each host loads its locator as an 'open > question'. NAT traversal is described by a mirror query to the > remote end to locate the own external locator. DNS and presence is > included as a means of getting a current locator using a presence- > style service. > - operator - locator discovery and locator selection. The discovery > operation is 'normal' DNS for fixed. DNS + dynamic mechanism to > retrieve current locator. Locator interruption can be undertaken by > MAST peer-to-peer > - locator pool maintained through MAST mechanism > - security only equal to IP. The recognition of 2 packets belonging > to > the same sequence have a number of choices. For global persistency > global DNS is proposed. A NONE is proposed to be sufficient for > mobility > - table of comparison presented. > > > > TCP Multi-Home Option > --------------------- > > Arifumi Matsumoto > - DT2 - host-centric model, source-address based routing within mh > site. Improved TCP is necessary and claimed to be simple. SCTP is > not TCP as there is no interoperability between SCTP and TCP > endpoints in a single session. This approach is TCP MH Options > - TCP - add MH option only. claimed to allow rapid recovery from > transmission failure. after RTO timeouts the pool of source > addresses is used to use a new path > - protocol exchange illustrated. SYN packet contains MH option that > includes the intention to use different source addresses. > - bit format for MH options presented. > - path switch triggered on TCP timeout or ICMP error > - path discarded under certain conditions > - security considerations: redirection attack - claimed to be easily > prevented in this approach. Session hijack protected by strict MH- > Serial number management, backing out when incorrect serial > received. > - not the consensus of the DT2 team. > - table of comparison presented > > Clarification questions: > > * What to do with UDP? > UDP need not be considered within this context. > > * Why are TCP enhancements is showing up here first? This should be > targeted > at transport area! > (Chair) This would be referred over if we proceed in this way > > * Redirection attack is possible on guessing the 16 bit number. > Protection is based on not being able to guess this 16 bit number, > correct? > yes, although there are other protections here to reset the TCP > session > > Global Routing Table Size > ------------------------- > > Masataka Ohta > - the goal in multi6 is to make the global routing table small > - how small at the lower limit? > - small routing table is claimed to be a desirable goal > - mh is multiple links with separated sites for boundary routers > - full route sets are necessary on the 'site backbone' > - a full routing table on hosts allow a host to carry unreachable > locators and metrics for each locator > - source locators must be 'proper' > - let hosts select the source locator, routing protocol to carry > source locator to be used for each destination > - policy control is 'not so global' > - the global routing table size should be larger than the number of > Tier 1 ISPS. An upper limit should be imposed by memory and > bandwidth of a host. Presentation makes some assumptions to > calculate this figure, and postulates that the global routing table > should be upper limit bounded at 8,000 entries in the global > routing > table. > - table of comparisons > > > Source-Based Routing > -------------------- > > Kenji Ohira > - characterizes some solutions as above IP and below TCP, others are > TCP augmentation /alteration > - target is small stub networks, not ISP multi-homing > - method proposed of hierarchical addressing and source-based routing > - updates from original draft listed > - table of comparison provided > > > Lin6 > ---- > > Masahiro Ishiyama > - location in dependant networking > - implementations > - uses globally unique id in low 64 bits and network prefix in upper > 64 > bits > - locator resolution uses a new agent - a mapping agent - to perform > this resolution > - assume that the ID is statically assigned - now working on a > dynamic > assignment mechanism with a crypto base with the mapping agent > > > Multi6 Threats > -------------- > > Erik Nordmark > > Why? > - adding this additional level of indirection to the architecture > opens up security vulnerabilities > - can be used to divert traffic and potential denial of service to a > 3rd party > - similar to mobile ipv6, but not identical > > Today's assumptions > - how good security - no better, but not making it any worse > - option to use the DNS and trust what comes back > - applications that trust the source IP addr of received packets > without any verification of information - these are vulnerable to > various forms of attack > - the existence of reverse+forward DNS resolutions was noted > - using security mechanisms and their notions of identity > - opportunistic security without access control > > Redirection threats today > - compromise the routing protocol > - compromise the DNS > - ND/ARP spoofing > - attack a node on the path > - mh solution should not make things any worse > > Flooding attacks today > - send packets to target > - self-flood or flood path to self (e.g. ACK spoofing) > - reflection attack where A can direct B to send to C, with out > without amplification > - we don't need to fix these problems, but should avoid making them > worse > > New attack vectors > - redirect existing flow to a new locator > - predictive attack (if A will talk to B, C claims to be A before A > communicates with B) > - replay attack > - black hole by broadcasting a broken id/locator binding > > 3rd party DOS attacks > - redirection to flood a 3rd party > - possibly a check that the endpoint is reachable at the location > prior to data flow as a mitigation > > Accepting Packets > - With ingress filtering at all locations its hard to inject a > spoofing packets > - mh potentially allows any source, compromising ingress filtering > > > Multiple Multi6 Approaches > -------------------------- > > Erik Nordmark > - A number of solution proposals with inherent trade-offs > - NOID, SIM and CB64 as a shim between ULP and IP, below > fragmentation, AH, ESP and destination options, and above IP > 'routing' > - Application / ULP uses an ID that is stable for a session or > longer. This IS is termed the 'AID' > - mh uses different locators over time > - rewriting of source locators to detect changes > - Uses DNS without changes > > NOID > - no identifier in any packets. The FQDN is the node identifier, > and > a set of locators are used on the wire. > - The ULP uses a single locator during a communications > - different connections use different locators to allow > load-sharing > - shim layer can use different locators on the wire > - receiver needs to rewrite locator according to current context > > NOID - DNS > - uses reverse + forward to prevent redirection attacks > - this provides the FQDN and a working reversed > - without this you cam communicate with a mh NOID remote point but > cannot be mh yourself > - needs R6 RR into the DNS > - no packet overhead for data packets > - uses flow id plus next header values > - conceptually this is similar to an extension header to operate at > the shim layer > - new ICMPv6 packets for the handshake > - NOIDS walk through in presentation > > SIM concepts > - 128 bit identifier, a hash of a public key, akin to HIP, created > autonomously > - Upper Layer Protocol uses these identifiers > - shim layer needs a context tag, and is seeded from the DNS > - AAAA records plus new SIM ID RR type to collect identifier > - In order to prevent redirection, the public key crypto scheme is > used, as per CGA in SEND WG. Not needed until locators change. > - Also uses an explicit extension header > - new packets for handshake > - protocol exchange walk through > > CB64 > - middle ground between NOID and SIM - IP addresses with 64bit hash > of a public key > - previously discussed in SEND and MobileV6 > > High Level choices: > - Is it beneficial to introduce a new IP space as in SIM/HIP > - Or use multiple addresses > - DNS for verification issues? vs public key crypto? or no > verification? > - Use of local locators? > > Clarification questions: > > * Do you assume symmetric routing in these models? > No. > > * Do you assume DNSSEC in these models? > No - but use of DNSSEC would improve the security of the use of > DNS > > * For SIM you claim no PKI is required, but a new DNS RR is > returned - > Is this a public key record? > No keys are stored in the DNS in this approach. Its a derivative > rather than the actual key. The trust in NDS in no change > > * The threats work said "don't make things worse". Those protocols > are being secured right now. To what version of these protocols > are > you referring to - secured or unsecured? > If introduced today, we don't want to make things worse than > today, or in the future. > > General Discussion > ================== > > > 1. Cutoff date for Proposals? > > Kurt Lindquist (chair): The issue is for how much longer do we keep > on > seeing the same presentations. The cutoff for proposals to be > submitted as drafts for WG consideration is proposed by the chairs > to be year end. > > Brian Carpenter (chair): Call for comment on this proposed rule > > Keith Moore: Serious reservations for this call. Nothing is serious > enough in the proposals to be a 'real' solution. IN the past a late > proposal has been a drastic improvement with eager WG adoption. Its > premature to reduce the number of proposals. > > Jim Bound: Process point: I've read the specs - I don't need to hear > this. > > Matsataka Ohta: This is fine for my proposal, but no good for others > as it promotes a step-by-step approach. The NOID approach does not > address interaction with mobility, for example. > > Brian Carpenter: The proposals so far are not ready for evaluation, > but I'm not willing to accept more - they are two different points. > I don't know any way to make things happen without deadlines. If no > deadline then we will never complete the proposal stage. > > Erik Nordmark: The thing you want to avoid is new proposals that are > similar to previous proposals in all but name. But different ways > of > doing things should not be cut off. Maybe look at diffs to current > proposals rather than complete proposals > > Eliot Lear: 31 Dec is very close. If so then why not make the > proposal > cut today? > > Brian Carpenter: we are aware of one draft that did not make it. > > Eliot Lear: Could you please include HIP is this set of proposals for > WG consideration? > > Keith Moore: The scheduling concern is fine for understood problems. > But if the problem is not understood, then setting deadlines for > proposals is not a solution path > > Christian Huitema: What concerns me is the focus on proposals. So far > there are complete architecture presentations, and no modular > approach has been presented so far. Maybe modularity of the > solution > process would help. Some things are constant/generic - eg ingress > filtering, security. None of the solutions seen so far provide for > incremental deployment - none have a business model that drives > incremental deployment. > > Brian Carpenter: This concept of a cutoff date for proposal is not > being accepted by the WG. Instead could we set a target date for > ideas to get ideas out so we avoid a situation where everything > arrives at a face-to-face meeting. Reasonable? > > WG: silence and nods > > Decision: Chairs to set a date for the submission of ideas regarding > approaches to multi-homing > > 2. Evaluation Criteria > > Randy Bush: we need to consider what e2e connection setup, referrals > (passive ftp), both ends attempt simul connect. NOID appears to be > incompatible with local addressing or two-faced DNS - I'm not sure > that this is a bad thing > > Kurt Lindquist: Remind the WG on desired properties of a solution > (see > slide) How to pick a proposal? RFC 3582 is one tool to do so > > Brian Carpenter: Some of these questions raised are missing in that > RFC - the WG may want use a longer list of criteria > > Kurt Lindquist: At some point we still need to pick a solution - > we'll > take this to the mailing list to discuss these in depth - more > merit > may be an outcome of combining aspects of these proposals > > Decision: Take the topic of evaluation criteria for WG to use to the > mailing list. > > > > 3. General Discussion of Proposals > > > Erik Nordmark: thinking about how referrals work is very important - > each approach is different. Technical differentiator. In NOID, The > extra 8 bytes uses the flow id on the proposal. If you believe that > the rewriting of the ID by the receiver is good, then some help in > the header to flag this permission would be good. > > Brian Carpenter: If we go down the path of this solution we should > discuss the version number at some stage > > Erik Nordmark: 2 faced DNS and local addresses. NOID says you get the > id info from the DNS. Added words suggesting what happens when you > get inconsistent answers from the DNS? Maybe you need a mechanisms > to exchange the info you received. Or maybe sprinkling in some > other security technique into this may be useful. This has not been > explored in any detail. > > Matsataka Ohta: I like my own security requirement drafts. I have > objections to his draft. redirection attack. The other concern is > that the security analysis is complete. > > Brian Carpenter: please distinguish between threat analysis and > solution > > Tony Li: Our proposal ensure incremental deployment by allowing each > host to advertise its capabilities. > > Ilijsch van Beijnum: There are proposals where you need to store info > in the DNS that are not there today. Proposals to allow systems to > interact before interaction. Both at the same time is not ok. > > Keith Moore: Use of DNS - likely that DNS is part of any successful > proposal. DNS names are service names as well as host names. not > just host names. Rebinding to the DNS IP addr is a dubious > assumption. In practice DNS is not universally consistent. Assuming > that DNS is a good mechanism for addressing updates and changes is > not a good assumption. > > Brian Carpenter: use of reverse DNS tree? > > Keith Moore: That would be unwise. > > Jim Bound: Did not understand the use of compression in the flow-id. > The SCTP protocol combined with NOID may well be the answer. I'd > IKE > to propose a submission to the WG on SCTP + NOID. > > Brian Carpenter: As SCTP is not TCP this would imply that there would > be no TCP in your approach > > Jim Bound: I had in mind SCTP simulating / emulating TCP > > Brian Carpenter: It would be nice if we had a draft on this. > > Brian Carpenter: Erik is correct - the only case where things look > strange is where the flow-id is exported in a coarse-grained style. > Multiple TCP sessions using the same flow-id will cause all TCP > sessions to suffer the same mh fate > > Christian Huitema: incremental deployment. In all the proposals you > have to assume a world in which IPv6 is already deployed. The m6 > proposal is an add on to a deployed network. You need an immediate > benefit to yourself without requiring other sites to also upgrade. > i.e. one-armed mechanisms that require no change to the other end. > e.g. advertise >1 addresses in the DNS and let the other end > choose. > Want to see a way to solve egress filtering to an other end that > cannot do the rewrite trick. > > Tony Li: egress filtering is orthogonal to the rest of the issues > here. They can be applied to all the proposals see so far > > Dave Crocker: Rarely, I agree with Keith Moore. Need to distinguish > between names as a name space and names as a query mechanism. > MAs also has incremental adoption, but Huitema defined incremental > adoption in a way that MAST is not. We don't have a common shared > sense for criteria and terminology. Incremental deployment > capability in not on criteria list. Other considerations emerging, > and there is more. Theory is any single proposal may be attack on > these criteria. We need to get clear what is important and what is > not to allow proponents to respond carefully. > > Kurt Lindquist: The RFC lacks criteria - the WG's evaluation list > appears to be bigger than that listed in the RFC.. > > Brian Carpenter: This is an OPS working group - these are close to > operational questions. > > Crocker: I hear what you said but don't understand it. > > Ellwyn Davis: Wondering is we are transferring the problem from the > data to the control plane. Bootstrapping is a real issue here. It > need to be thought through. > > Matsataka Ohta: I propose that all proposals should address issues > already contained in additional to the RFC careful analysis of > interaction with DNS. For example in NOID DNS appears, but nothing > is mention of DNS as a connectionless protocol using UDP. Section > about connectionless UDP is very strange. ok? > > Keith Moore: coming up with more criteria in a solution - this is > good. But if you acknowledge that you are going to compromise in > selecting than you will need a lot of help in doing the > compromising. > The discussion flows around renumbering, mobility, etc, and there > is > a good chance of conflicting with other efforts > > Matsataka Ohta: General feeling about design parameters; global > routing table size, number of prefixes. Can I have discussion? > > Brian Carpenter: If we did not care about the number of prefixes we > would not have this discussion > > Randy Bush: (channeling Margaret Wasserman) Isn't there a multi6 > draft about requirements? Shouldn't this draft be tuned with this > discussion? What are the technical details of these proposals? The > HIP BOF did a good effort of comparisons > > Brian Carpenter: I feel a need for a document for a new set of > considerations, need a volunteer for a draft > > Sean McCleary: What is the expected number of per-host addresses in > each proposal and what would push this number upward. Concerned > that > it may rise to several dozen - I am concerned if it gets to that > high point > > Tony Li: All the proposals are 1 locator per immediate ISP. Not 1 > locator per inbound path > > Eliot Lear: does it matter how many identifier there are? > > [Several]: no! > > Margaret Wasserman: I heard Randy channel me. The issues I have are > referral (as per passive ftp) and simultaneous TCP connect attempts > from each end. Questions about NOID from this perspective. In NOID > when if A -> B and B -> A starts up at the same time, state on A > with flow ID requires 2 DNS lookups on B and the B -> A connect > attempt will be rejected in the meantime. Is this bad? > > Erik Nordmark: this was an exercise left to the reader. The document > has not thought through this scenario in detail. The document talks > about state loss and re-establishment efforts. There is a risk of > ending up with 2 different contexts. It sounds like the same issue, > but not sure. > > Margaret Wasserman: Have a problem when we completely separate the > locators as an ID. How do we know this has occurred. Do we always > do > the 2 DNS lookups on a referral, or is there state. > > Erik Nordmark: 2 reasons why this would not work. a) renumbering > (long > time scale) b) short term (routing). a) deal with it - don't keep > these things around forever. Use the FQDN to consult the DNS. A > locator without the FQDN is pretty useless. And the DNS reverse > should fail in such a case. Referrals and failure simultaneous - > you can pass across the id. One approach is the other end to do the > 2 DNS thing to retrieve the full set of locators, or the other end > could send off the full locator pool > > Margaret Wasserman: does with work with 2-faced DNS? > > Erik Nordmark: DNS inconsistencies in responses require you to come > to > the minimum intersection of the two sets. I've been thinking of a > weaker mechanism with some sort of security and some sort of local > or global scope. > > Brian Carpenter: reverse tree reliance? > > Christian Huitema: This is not a good idea. A cyclic dependency is > not > what you want. Today's reverse is populated with poor data to a > level of around 50%. Not a good idea to rely on this data. > > Brian Carpenter: multi-homed DNS server? > > Randy Bush: MH is a lot of hoops. They will get reverse DNS right if > its part of the necessary steps. The cyclic dependency is a > substantive point. > > Keith Moore: The rev-DNS tree is an anachronism. There are many forms > of relationships in the reverse -> forward, and its not generally > an > inverse of the forward lookup functions > > Dave Crocker: domain names are many things. Any global consistent > name > space requires a query service. Use a new one or a new one? > > Randy Bush: put it in BGP! > > Erik Nordmark: Careful not to create recursion here - need to be > careful to use a lookup for locators not identifiers. DNS has its > own way of doing that by listing the IP addresses of the name > servers. You don't need to use this solution to lookup DNS name > servers. I don't understand what the operational issues are. Its an > identifier, not a locator. The DNS should check, because things > will, just, fall apart. one more thing... mumble.... > > Matsataka Ohta: I don't want to change current operational practice. > When its necessary use DNS reverse, but not mandate it. I actually > proposed a way to use TCP options to pass locators which means DNS > is > not necessary. > > Christian Huitema: The DNS is used to acquire a set of locators if > you > have a locator, and so conceptually you could ask a server, the > other is to ask your peer. If you ask you peer to get an answer > that > is not dependant on a server > > Erik Nordmark: the server is used as a verification to avoid certain > forms of DOS attacks. > > Christian Huitema: I hear you. The attack you describe was an > attribute > with mobile ipv6 - you do a 2 way handshake with the locator to > verify before use, and this defends against he attack. > > Erik Nordmark: You could this with an exchange - its something to go > explore further > > Randy Bush: what I think I heard from ohta-san the reverse is just > increasing your confidence. The cert exchange is just increasing > your > confidence. But what's going to be different here? > > Pekka Nikkander: We wanted to discuss the reverse DNS thing. A > identifier / locator split will break things. A fix that relies on > reverse DNS would be a little bit awkward. > > Bruce Campbell: The DNS is distributed, but not reliable. Using DNS > to > load a mh session is not always reliable. This is an instance of > middlebox attack > > Perry Metgzer: True the DNS is not perfectly reliable, nor is IP. > Things work without the DNS already, such as nutella. Its > unfortunate that we are producing this hairy ball of > interdependencies, but it may be the only way. > > Steve Bellovin: ALIAS BOF about hints - hints are good for > optimizations, but they are not reliable directives. As long as it > still works if you can't get to the DNS this is better. > > Iljitsch van Beijnum: We've looking into the DNS for locators or > exchange. Another is to just go ahead with TCP and back off into > another address on failure, and only on failure. i.e. backoff into > this form of exchange > > Christian Huitema: Privacy, and where to engage this mechanism. Many > of the slides think of IP security as a layer above the exchange of > locators, yet I can see why want to have a peer discussion but not > want intermediaries to know of this. If we do an exchange to move > traffic to other locators I'd like to do this with privacy. On the > one hand you want to keep the IPSEC session going but protect the > information about locators. > > Dave Crocker: layering shown usage, not control channel > > Keith Moore: Opposed to Perry's comment. Applications that do not > depend on the DNS exist - many of them. The generalization is > incorrect, and applications are a broad spectrum, not two types > generically. > > Brian Carpenter: No consensus about the use of reverse DNS in these > approaches so far. > > Margaret Wasserman: Use identifier or id rather weakly here. IP > addresses are used within hosts as well as externally > > Erik Nordmark: Christian Huitema suggested control channel privacy - > this is a trade- off. I don't know if confidentiality for the > control channel is necessarily the right thing to do. > > Perry Metzger: This may not add up to better security overall. > Architecturally - You need to name state. It can't be IP addresses. > DNS labels are a fixed point and work as a named state. > > Christian Huitema: the point is that we shall not impose a position > on > the trade- off on privacy. It should be clear that the solution > should not _mandate_ that you drop confidentiality. I should have > control of what I choose to disclose and this should be compatible > with the solution. > > Erik Nordmark: I understand the mobility concern about disclosure of > location. This may be different between disclosure of mh state per > se. After all any connection discloses the current connection state > in any case. > > Brian Carpenter: In a paranoid location you may deliberately move the > location to take this to a non-disclosed locator. > > Margaret Wasserman: Why frag over NOID? > > Erik Nordmark: Not NOID, thats SIM. > > Margaret Wasserman: why should it be above? > > Nordmark: The reason you have this flexible system you have the > potential risk that different frags do down different paths. If > reassembly is done BEFORE source rewrite reassembly is not > possible. > > Brian Carpenter: Bound said - SCTP-based draft on the table. Anyone > willing to get a HIP-based draft on the table? > > Pekka Nikkander: This is an initial draft on this. I'm willing to > work > on a draft on this as a more specific effort. > > Brian Carpenter: Need a draft summarizing the criteria we've > discussed here. > > Eliot Lear: I volunteer to write this up > > Brian Carpenter: Each proposal should self-assess against criteria, > as > proposed to WG assessment. > > Brian Carpenter: 31 Dec did not get WG approval, but a rush of > proposal 2 weeks prior to next IETF is also tough. 'sometime in > January" is a strongly preferred option. > > Brian Carpenter: Need to think about how to converge ('marry') > proposals into a WG proposal from a set of individual proposals. > > Tony Li: A competition among proposals is a barrier to consensus and > rational choice. We should be working in problems and look at > salient features, solutions to each of those problems. They may not > be in dependant, but thats fine. 'your' vs 'mine' is destructive to > working together. > > Erik Nordmark: What are the pieces: filtering and the right exist. > Hints from elements need more work. It may not be a fine cut, but > it > has promise. > > Brian Carpenter: maybe we can see similar components in each of the > solutions > > Kurt Lindquist: the security analysis looks common > > Matsataka Ohta: We need proposals of complete architectures. > > Brian Carpenter: we are not quite ready to do that yet. > > Dave Crocker: Working over IPv4 as well could be considered > > Brian Carpenter: Next Steps: Eliot Lear to prepare a draft on > criteria > analysis, Jim Bound a SCTP document,Pekka Nikkander to prepare a > HIP-based document, i-d publication of design team document, > complete gathering of ideas, prepare evaluation criteria as applied > to proposals, and then undertake functionality analysis with a view > to convergence of WG efforts. > > > WG session adjourned. > > > > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP8L2z6arNKXTPFCVEQLTqgCgjnT8ODtnexc6FY8vDUFaV58WX0wAoJ9H X1DVGhQZUAcNM6+i5bb1rXoA =OqzA -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Nov 25 01:36: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 BAA22777 for ; Tue, 25 Nov 2003 01:36:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOWnM-000Iay-Uc for multi6-data@psg.com; Tue, 25 Nov 2003 06:35:32 +0000 Received: from [195.43.225.73] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOWnA-000IaJ-SE for multi6@ops.ietf.org; Tue, 25 Nov 2003 06:35:21 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.9/8.10.2) with ESMTP id hAP6ZHL4003819 for ; Tue, 25 Nov 2003 07:35:19 +0100 (CET) Date: Tue, 25 Nov 2003 07:35:13 +0100 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=fixed Subject: presentations in Minneapolis From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <86662D66-1F11-11D8-AB7F-000A9598A184@kurtis.pp.se> X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am missing quite a few of the presentations made in Minneapolis. If you haven't already sent them to me, please do. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP8L4I6arNKXTPFCVEQJn6ACfeVG4kVRTWTLJ3EBaAIujKL5/vNMAn0qK LViBtIJRYkDS8LRZA2R3o0Jn =grdy -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Nov 25 05:12: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 FAA10854 for ; Tue, 25 Nov 2003 05:12:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOa9i-0003of-8R for multi6-data@psg.com; Tue, 25 Nov 2003 10:10:50 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOa9V-0003o2-T2 for multi6@ops.ietf.org; Tue, 25 Nov 2003 10:10:38 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hAPAA8ed047339; Tue, 25 Nov 2003 11:10:08 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FB9566A.4090000@necom830.hpcl.titech.ac.jp> References: <63AE30A8-193C-11D8-A52A-000A9598A184@kurtis.pp.se> <3FB9566A.4090000@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <954CD888-1F2F-11D8-AC6B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: delayed multihoming/mobility set-up Date: Tue, 25 Nov 2003 11:10:23 +0100 To: Masataka Ohta X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 18-nov-03, at 0:14, Masataka Ohta wrote: >> If we assume that we are using BGP for the EGP routing updates, we >> have the Ahuja/Labovitz route cancellation effect. If I remember >> correctly, their research showed that 40% of re-routing takes 2-4 >> minutes (I am taking this out of my head). > That is a reason why global routing table should be shrinked. I'm afraid these two issues aren't really related. The reason that BGP rerouting can take so long is that the RFC mandates a 90 second hold time, but Cisco and presumably others use an even longer default hold time of 180 seconds. Operators are often reluctant to change the default. Once the BGP session goes down there is of course the issue of updating all the related routes, which can also take some time depending on the number of routes that ran over the neighbor. But this is usually a matter of seconds (think a one digit number). > It, instead, is the reference for BGP++. We already have BGP4+, but now we need BGP++? From owner-multi6@ops.ietf.org Tue Nov 25 05:33: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 FAA11489 for ; Tue, 25 Nov 2003 05:33:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOaVI-00053s-M4 for multi6-data@psg.com; Tue, 25 Nov 2003 10:33:08 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOaV4-00052w-7X for multi6@ops.ietf.org; Tue, 25 Nov 2003 10:32:54 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hAPAWOed047569; Tue, 25 Nov 2003 11:32:24 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Some Comments on ID/Loc Separation Proposals Date: Tue, 25 Nov 2003 11:32:44 +0100 To: X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 18-nov-03, at 23:04, wrote: >> Wnc> The use of the term "Identifier" or "ID" sweeps an important >> MWnc> issue under the rug in some cases: Is this a host ID or an >> MWnc> interface ID? >> or a 'stack id' or an 'endpoint id'? and what do these mean, >> precisely. > Exactly, Noel Chiappa referred to a host/endpoint/stack ID as though > a host, an endpoint and a stack are all the same thing. But are they > really the same thing? Is there even a 1:1:1 correlation between > these things? Is the nature of that which is identified an important attribute of the identifier? I don't believe it is. But if I would have to make a choice, I'd go for a host identifier, or stack identifier in NSRG terminology. (But I prefer the term "host identifier".) >> For example, I had frankly been >> avoiding trying to handle referrals, but any solution needs to attend >> to this requirement explicitly. > Yes. And, there are enough commonly deployed application that use > referrals that I think that we should consider it an operational > requirement that a multi-homing mechanism includes support for > referrals. As referrals are pretty much broken in today's internet anyway, I don't see why we would have to burden multihoming mechanisms with meeting the fairly arbitrary expectations of applications doing referrals. A much better approach would be to spin off this issue and solve it independently of what happens with multihoming. >> MWnc> - The PROBE message sounds (to me) similar to >> MWnc> the old proposal to use pings to detect dead >> MWnc> gateways. What can we learn from the problems >> MWnc> with that model that apply here? >> I, too, would greatly like to hear feedback on this construct. I've >> seen a couple of comments that raised no concerns about it, but none >> that offered assurance it would work ok. > One of the problems with active connectivity detection is bandwidth > use. Yes, this is something we need to avoid. > Perhaps this could be alleviated by suppressing MAST messages > when ULPs are progressing Supress them too when the upper layers are idle. This can lead to a slight delay when the communication resumes if something went dead in the mean time, but that's certainly preferable to wasting bandwidth when nothing is going on. For wedge solutions I'm thinking along the way of monitoring ULP interactions and only send and explicit keepalive (request) when there is no traffic from the other side when the failover logic expects there to be. For a transport solution this would be unecessary as transport protocols know exactly when something should be coming back or not, so the only reason to do keepalives would be to see which paths are available when the primary one looks dead. From owner-multi6@ops.ietf.org Tue Nov 25 06:45: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 GAA13856 for ; Tue, 25 Nov 2003 06:45:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AObbQ-0008pb-2Q for multi6-data@psg.com; Tue, 25 Nov 2003 11:43:32 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AObb4-0008oF-4W for multi6@ops.ietf.org; Tue, 25 Nov 2003 11:43:10 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hAPBgfed048333; Tue, 25 Nov 2003 12:42:41 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <867F9A58-1F3C-11D8-AC6B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: delayed multihoming/mobility set-up Date: Tue, 25 Nov 2003 12:43:02 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 14-nov-03, at 0:10, Pekka Savola wrote: > Is it necessary to ensure connection survivability prior to the > connection > establishment? > Or, is it necessary to ensure connection survivability in parallel > with > the connection establishment? > Or even, is it OK to just ensure connection survivability only for > "long-lived" sessions (e.g., those which have lasted for longer than > 5 > minutes), using some definition. Ideally, it should be possible to take an identifier, connect to it and the connection establishes as long as there is a single working source/destination locator pair. However, if we want to build this, we need an identfier->locator (and probably also locator->identifier) mapping infrastructure. At present, nobody seems too thrilled about either using the DNS for this or building something from scratch. This approach also has the downside that it's all or nothing: both sides must implement it and the mapping infrastructure must be in place before it can work. The alternative is making improvements to what we have now. One thing that needs to be solved regardless of what else happens is the whole source address/exit ISP selection and ingress filtering problem. Another problem that we can solve on just one end (which makes it infinitely easier to do) is establishing a connection in the presence of unreachable destination addresses. This is hardly rocket science, as very old versions of telnet and FTP already cycle through all IP addresses associated with a FQDN until they find a live one. Many IPv6 applications do this quite well today (ie, not requiring a very long TCP connect timeout before trying another address). And on systems that provide a connectbyname() function call this entire problem can be solved in the OS rather than in individual applications. The only thing that we can't possibly solve without involving both ends is connection survivability. Now obviously we can go back to our ideal solution as listed above, or we can add some stuff to existing protocols that makes it possible to repair reachability problems in a backward compatible manner. The huge advantage here is that there is no need to determine the type of connection that can be set up beforehand: just connect and see what happens. The next step is setting up the multihoming mechanisms. Rather than exchanging addresses in-band, I think we should limit ourselves to just announcing an authentication token. This can easily be done with minimal overhead in a destination option in one of the first packets. Then the session (including non-TCP "sessions") can proceed as they would normally in the absense of multihoming mechanisms. Only when the connection gets stuck because of a a reachability problem (and the session would normally time out), the multihoming stuff kicks in. If the session was set up using the DNS, the initiator or client knows the locator addresses for the other side so it is able to find a working source/destination locator set. If additional locators aren't available, then it is still possible to repair most failures by sticking to the destination locator but jumping to a new source locator. Obviously, there would have to be some serious negotiating as the other side doesn't know the packets with the new source addresses belong to the existing session. This is where the authentication token comes in, in order to prove that the "new" correspondent is the same as the previously known one. To answer your initial question whether it is necessary to protect not yet established sessions using multihoming mechanisms: in the above universe this wouldn't be required as the application or OS on the initiating side knows how to connect to a correspondent with unreachable locators without employing end-to-end multihoming mechanisms. But it's probably useful to provide this functionality anyway if possible to accommodate applications that don't do this themselves or use system calls that allow the OS to do it. One additional caveat if we go this route: since the additional locators aren't available until there is a reachability problem, smart upper layer protocols don't get to do their thing. I think this can be solved by adding additional mechanisms that ty in to the core session survivability mechanisms by allowing the ULP to request adding new locators to the mix. The multihoming layer then negotiates with the other side and then reports back to the ULP whether it can use the requested locators. After that, the ULP can bypass the rewriting that would normally be done by the mh layer and use its own magic. Note that the way this is done today in SCTP where the ULP negotiates the additional addresses itself is probably insecure. From owner-multi6@ops.ietf.org Tue Nov 25 10:55: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 KAA24416 for ; Tue, 25 Nov 2003 10:55:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOfVS-000Naj-Js for multi6-data@psg.com; Tue, 25 Nov 2003 15:53:38 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOfVG-000NZP-BQ for multi6@ops.ietf.org; Tue, 25 Nov 2003 15:53:26 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAPFvmf21798; Tue, 25 Nov 2003 07:57:48 -0800 Date: Tue, 25 Nov 2003 07:51:05 -0800 From: Dave Crocker Reply-To: dcrocker@brandenburg.com Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <102251632608.20031125075105@brandenburg.com> To: Iljitsch van Beijnum CC: Multi6 Mailing List Subject: Re: delayed multihoming/mobility set-up In-Reply-To: <954CD888-1F2F-11D8-AC6B-000A95CD987A@muada.com> References: <63AE30A8-193C-11D8-A52A-000A9598A184@kurtis.pp.se> <3FB9566A.4090000@necom830.hpcl.titech.ac.jp> <954CD888-1F2F-11D8-AC6B-000A95CD987A@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, IvB> The reason that BGP IvB> rerouting can take so long is that the RFC mandates a 90 second hold IvB> time, The reason that BGP has a long hold is because short times lead to route flapping. This is an inherent property of doing route calculations. A scheme that is too quick to change will be constantly changing. Hence the assessment of a particular route always needs to be pretty slow to change the assessment. That is why I think the way to achieve quick response is with a model of parallel paths. When one goes out, the other is already in use. (Of course, this introduces the costs of out-of-order packets.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Tue Nov 25 11:42: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 LAA26167 for ; Tue, 25 Nov 2003 11:42:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOgFU-0000H8-5F for multi6-data@psg.com; Tue, 25 Nov 2003 16:41:12 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOgFH-0000GZ-BN for multi6@ops.ietf.org; Tue, 25 Nov 2003 16:40:59 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hAPGdHed051631; Tue, 25 Nov 2003 17:39:17 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <102251632608.20031125075105@brandenburg.com> References: <63AE30A8-193C-11D8-A52A-000A9598A184@kurtis.pp.se> <3FB9566A.4090000@necom830.hpcl.titech.ac.jp> <954CD888-1F2F-11D8-AC6B-000A95CD987A@muada.com> <102251632608.20031125075105@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: delayed multihoming/mobility set-up Date: Tue, 25 Nov 2003 17:39:38 +0100 To: dcrocker@brandenburg.com X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 25-nov-03, at 16:51, Dave Crocker wrote: > IvB> The reason that BGP > IvB> rerouting can take so long is that the RFC mandates a 90 second > hold > IvB> time, > The reason that BGP has a long hold is because short times lead to > route > flapping. Hm, it shouldn't have to. And BGP has route flap dampening. > This is an inherent property of doing route calculations. A scheme > that > is too quick to change will be constantly changing. Hence the > assessment of a particular route always needs to be pretty slow to > change the assessment. I disagree. The right thing to do would be to popagate bad news fast, and good news slower. This limits the amount of flapping almost as well as delaying both good and bad news, while still allowing fast rerouting when failures happen. Regardless, there is no reasonable scenario where a keepalive comes in after 179 seconds. Three minutes is just too long. In my book I recommend 15 seconds but this is probably a bit too agressive: unfortunately there seem to be some BGP implementations that fail to generate keepalives frequently when they're busy, so setting the keepalive to 15 seconds leads to frequent flaps. But 30 seconds should be ok most of the time, maybe 60 seconds for the conservative crowd. > That is why I think the way to achieve quick response is with a model > of > parallel paths. When one goes out, the other is already in use. (Of > course, this introduces the costs of out-of-order packets.) I'm not sure if this is worth the trouble for just failover. Remember that by using twice the paths you're also vulnerable to twice the outages. But we probably want this for load balancing anyway. From owner-multi6@ops.ietf.org Tue Nov 25 13:30: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 NAA00807 for ; Tue, 25 Nov 2003 13:30:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOhwa-0006bi-PC for multi6-data@psg.com; Tue, 25 Nov 2003 18:29:48 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOhwO-0006ao-Vr for multi6@ops.ietf.org; Tue, 25 Nov 2003 18:29:37 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPITZA13859 for ; Tue, 25 Nov 2003 20:29:35 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 20:29:23 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 12:28:58 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Some Comments on ID/Loc Separation Proposals X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 25 Nov 2003 13:28:57 -0500 Message-ID: Thread-Topic: Some Comments on ID/Loc Separation Proposals Thread-Index: AcOuaGgah2sJYpx1QIqjofeVioXwvwAA1MtgAUU1lCA= From: To: , , X-OriginalArrivalTime: 25 Nov 2003 18:28:58.0550 (UTC) FILETIME=[FDBA3D60:01C3B381] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > From my perspective, we've been quite consistent with > using locator for the topological naming for an interface, while > an identifier is the name for a host. Ahhh... This pretty much answers my question (I think :-)). In your taxonomy, the "ID" portion serves as a host/endpoint=20 identifier and the "Locator" portion allows you to topologically=20 locate a particular interface on the network, right? If I understand correctly, the 8+8/GSE world uses a different=20 breakdown between ID and Locator... The upper 8 bytes are only a topological locator for a particular link (which may have many attached interfaces), and the lower order 8 bytes=20 are used to identify a particular interface on that link. I consider this to be a fairly important architectural=20 distinction, as the two models offer different levels of=20 abstraction to ULPs. Margaret From owner-multi6@ops.ietf.org Tue Nov 25 15:41:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08635 for ; Tue, 25 Nov 2003 15:41:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOjxi-000G6q-Jo for multi6-data@psg.com; Tue, 25 Nov 2003 20:39:06 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOjxW-000G5p-E8 for multi6@ops.ietf.org; Tue, 25 Nov 2003 20:38:54 +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 hAPMhoOt011611; Tue, 25 Nov 2003 14:43:50 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hAPKcgYB005291; Tue, 25 Nov 2003 12:38:42 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Some Comments on ID/Loc Separation Proposals Date: Tue, 25 Nov 2003 12:38:41 -0800 Message-ID: Thread-Topic: Some Comments on ID/Loc Separation Proposals Thread-Index: AcOuaGgah2sJYpx1QIqjofeVioXwvwAA1MtgAUU1lCAABMQFUA== From: "Tony Li" To: , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | > From my perspective, we've been quite consistent with | > using locator for the topological naming for an interface, while | > an identifier is the name for a host. | =20 | Ahhh... This pretty much answers my question (I think :-)). | =20 | In your taxonomy, the "ID" portion serves as a host/endpoint=20 | identifier and the "Locator" portion allows you to topologically=20 | locate a particular interface on the network, right? Correct. More specifically, we have not introduced any terminology with respect to an 'endpoint'. =20 | If I understand correctly, the 8+8/GSE world uses a different=20 | breakdown between ID and Locator... The upper 8 bytes | are only a topological locator for a particular link (which | may have many attached interfaces), and the lower order 8 bytes=20 | are used to identify a particular interface on that link. | =20 | I consider this to be a fairly important architectural=20 | distinction, as the two models offer different levels of=20 | abstraction to ULPs. Granted, however, from the macro point of view, this seems somewhat less critical. Our goal has been to "break as little as possible" and towards that end, we have naturally gravitated towards interface abstractions. This is not a religious requirement -- rather it's driven more by the pragmatics of finding a solution that will gain widespread acceptance without some very painful educational processes. Tony From owner-multi6@ops.ietf.org Tue Nov 25 16:28: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 QAA11586 for ; Tue, 25 Nov 2003 16:28:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AOkht-000Ie4-9d for multi6-data@psg.com; Tue, 25 Nov 2003 21:26:49 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AOkhg-000IdG-TO for multi6@ops.ietf.org; Tue, 25 Nov 2003 21:26:37 +0000 Received: from gih505.telstra.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id hAPLPgRc050475; Wed, 26 Nov 2003 08:25:47 +1100 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20031126075020.00bdca20@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Nov 2003 07:55:47 +1100 To: Iljitsch van Beijnum , Masataka Ohta From: Geoff Huston Subject: Re: delayed multihoming/mobility set-up Cc: Multi6 Mailing List In-Reply-To: <954CD888-1F2F-11D8-AC6B-000A95CD987A@muada.com> References: <3FB9566A.4090000@necom830.hpcl.titech.ac.jp> <63AE30A8-193C-11D8-A52A-000A9598A184@kurtis.pp.se> <3FB9566A.4090000@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > >I'm afraid these two issues aren't really related. The reason that BGP >rerouting can take so long is that the RFC mandates a 90 second hold time, >but Cisco and presumably others use an even longer default hold time of >180 seconds. Operators are often reluctant to change the default. > >Once the BGP session goes down there is of course the issue of updating >all the related routes, which can also take some time depending on the >number of routes that ran over the neighbor. But this is usually a matter >of seconds (think a one digit number). > >>It, instead, is the reference for BGP++. > >We already have BGP4+, but now we need BGP++? Iljtsch is of course right - its also useful to bear in mind that _any_ distance vector algorithm takes time to propagate, and any distance vector algorithm that needs to also synch itself with interior routing systems will take more time. The trade-offs here is speed vs stability. BGP is biased towards stability as that is the best path we know for scaleability. I'm not sure that BGPn for any n>4 will break out of this need to strike a balance between these two attributes. That being said, all this strikes me as wandering off into the weeds for this topic! :-) Geoff From owner-multi6@ops.ietf.org Sat Nov 29 19:47: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 TAA03440 for ; Sat, 29 Nov 2003 19:47:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQFi4-0005CF-GE for multi6-data@psg.com; Sun, 30 Nov 2003 00:45:12 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQFhr-0005AL-Ep for multi6@ops.ietf.org; Sun, 30 Nov 2003 00:44:59 +0000 Received: from adsl-67-121-106-210.dsl.irvnca.pacbell.net (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hAU0pgf05555 for ; Sat, 29 Nov 2003 16:51:42 -0800 Date: Thu, 27 Nov 2003 15:39:22 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <5420088946.20031127153922@brandenburg.com> To: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, draft-crocker-mast-analysis (which will be draft-crocker-multiaddr-analysis in its next version) has a section for defining some terms. The section has been prompted by exactly the kind of vagueness that the current thread is also trying to fix. My primary interest is in having precise definitions that we all find useful and use consistently. Some of the current versions of definitions in the draft are: Endpoint refers to "the fundamental entity of and end-end communication" [EID]. It is an end-system that participates in an association. Endpoints are distinguished from intermediate, infrastructure nodes and from hosts. Identifier refers to a unique label for an endpoint. The label is used simply for distinguishing one endpoint from another. Because a locator is usually globally unique, it might be able to serve as an identifier. However this use will often suffer administrative and referential limitations as a global identifier for mobile endpoints. This is exemplified by the current problems experienced with the dual role of IP Addresses. Suggestions for improving the text are eagerly sought. As with others, I do not think it is useful to have ID refer to an interface. Stack, endpoint or process all seem more helpful. Speaking of 'stack', what definition text would folks like. The NSRG paper introduces the construct nicely, but I'm not sure the text there is what we should live with. For that matter, what is the difference between endpoint and stack? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Sun Nov 30 06:39: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 GAA28708 for ; Sun, 30 Nov 2003 06:39:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQPrS-0003Ah-16 for multi6-data@psg.com; Sun, 30 Nov 2003 11:35:34 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQPrC-00039d-Ap for multi6@ops.ietf.org; Sun, 30 Nov 2003 11:35:18 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hAUBZeDP001002; Sun, 30 Nov 2003 12:35:42 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <5420088946.20031127153922@brandenburg.com> References: <5420088946.20031127153922@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <421EA354-2329-11D8-AA85-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Some Comments on ID/Loc Separation Proposals Date: Sun, 30 Nov 2003 12:35:11 +0100 To: Dave Crocker X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28-nov-03, at 0:39, Dave Crocker wrote: > My primary interest is in having precise definitions that we all find > useful and use consistently. Some of the current versions of > definitions in the draft are: > Endpoint > refers to "the fundamental entity of and end-end > communication" [EID]. It is an end-system that participates > in an association. Endpoints are distinguished from > intermediate, infrastructure nodes and from hosts. An endpoint is an end-system but not a host: I think this isn't all that clear. Personally, I prefer to talk about hosts, as this is a well-known concept. The fact that there is some ambiguity because hosts can be clustered and virtualized also isn't a huge surprise to most people, and can be spelled out for good measure. If you want to stick to "endpoints" you should say whether an endpoint is host that may or may not be virtual, a transport protocol or a process. This has pretty serious consequences for the number of identifiers that is necessary and some other stuff as well. For instance, certain types of communication may be handled by more than a single processes. When identifiers are tied to processes this makes referral very complex. > Identifier > refers to a unique label for an endpoint. Hm, maybe this is just my English but to me it is unclear whether you mean the identifier <-> endpoint relationship is 1-to-1, 1-to-n or n-to-1, only that it isn't n-to-m. I think "an identifier identifies a specific endpoint" is enough. > The label is used > simply for distinguishing one endpoint from another. > Because a locator is usually globally unique, it might be > able to serve as an identifier. However this use will often > suffer administrative and referential limitations as a > global identifier for mobile endpoints. This is exemplified > by the current problems experienced with the dual role of > IP Addresses. This is too much text and largely not relevant for defining "identifier". The only additional remark that's necessary is that an identifier is independent of an endpoint's attachment to the network ("location"). > As with others, I do not think it is useful to have ID refer to an > interface. Stack, endpoint or process all seem more helpful. Absolutely. While multi6 is about site multihoming and not host multihoming, it would be a mistake only allow jumping locators when those locators are tied to the same interface. "Endpoint" is usable, but "stack" isn't a very good word as it will probably confuse people who haven't followed what has happened in the NSRG and identifying processes is too granular and dynamic, IMO. From owner-multi6@ops.ietf.org Sun Nov 30 12:45: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 MAA06151 for ; Sun, 30 Nov 2003 12:45:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQVb2-000INj-Sc for multi6-data@psg.com; Sun, 30 Nov 2003 17:43:00 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQVaq-000IMr-Kw for multi6@ops.ietf.org; Sun, 30 Nov 2003 17:42:48 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 30 Nov 2003 09:45:08 +0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAUHgjAt026241; Sun, 30 Nov 2003 09:42:45 -0800 (PST) Received: from cisco.com (sjc-vpn2-19.cisco.com [10.21.112.19]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA00126; Sun, 30 Nov 2003 09:42:44 -0800 (PST) Message-ID: <3FCA2C14.9020900@cisco.com> Date: Sun, 30 Nov 2003 09:42:44 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031121 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Dave Crocker , multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: <5420088946.20031127153922@brandenburg.com> <421EA354-2329-11D8-AA85-000A95CD987A@muada.com> In-Reply-To: <421EA354-2329-11D8-AA85-000A95CD987A@muada.com> X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > Personally, I prefer to talk about hosts, as this is a well-known > concept. The fact that there is some ambiguity because hosts can be > clustered and virtualized also isn't a huge surprise to most people, and > can be spelled out for good measure. Once so spelt out, an end point would would have been defined in all but word, so why not define it? Personally I believe the term "host" has become ambiguous, and so itself is worthy of a good clarification, if not definition. Eliot From owner-multi6@ops.ietf.org Sun Nov 30 18:30: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 SAA17303 for ; Sun, 30 Nov 2003 18:30:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQazL-0007IY-Iq for multi6-data@psg.com; Sun, 30 Nov 2003 23:28:27 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AQaz8-0007I1-Kb for multi6@ops.ietf.org; Sun, 30 Nov 2003 23:28:14 +0000 Received: (qmail 24854 invoked from network); 30 Nov 2003 23:26:45 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 30 Nov 2003 23:26:45 -0000 Message-ID: <3FCA7D8F.3000405@necom830.hpcl.titech.ac.jp> Date: Mon, 01 Dec 2003 08:30:23 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Dave Crocker , multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: <5420088946.20031127153922@brandenburg.com> <421EA354-2329-11D8-AA85-000A95CD987A@muada.com> In-Reply-To: <421EA354-2329-11D8-AA85-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> My primary interest is in having precise definitions that we all find >> useful and use consistently. Some of the current versions of >> definitions in the draft are: > > >> Endpoint > > >> refers to "the fundamental entity of and end-end >> communication" [EID]. It is an end-system that participates >> in an association. Endpoints are distinguished from >> intermediate, infrastructure nodes and from hosts. > > > An endpoint is an end-system but not a host: I think this isn't all that > clear. Why do you say "endpoint" only to confuse everything? An entity at the Internetworking layer is the end system, which is identified by an identifier at the Internetworking layer. Just say "end systems". In addition, layering allows various mapping of entities at different layers, such as one to one, one to many, many to one, many to many, none to many and so on that there is no point on considering identifiers at other layers here. For example, an application layer identifier of a mail address may have no entity in the Internet, if the recipient is behind NAT or UUCP gateway. Even a mail gateway, which is, though not a mail recipient, an entity of the Internet, has many to many mapping to mail domain through MX that there is no point using identifiers at the Internetworking layer to identify an mail address. > Personally, I prefer to talk about hosts, as this is a well-known > concept. The fact that there is some ambiguity because hosts can be > clustered and virtualized also isn't a huge surprise to most people, and > can be spelled out for good measure. "virtualize" means "as if it is real. "virtualized host" means "muptiple entities behaving as if it is a single host". So, for the purpose of network protocol, treat it as a plain host. All the rest is internal implementation details within a host. There is no room of confusion. Masataka Ohta From owner-multi6@ops.ietf.org Sun Nov 30 19:16: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 TAA18199 for ; Sun, 30 Nov 2003 19:16:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQbiC-0009fB-DF for multi6-data@psg.com; Mon, 01 Dec 2003 00:14:48 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQbhz-0009ed-8u for multi6@ops.ietf.org; Mon, 01 Dec 2003 00:14:35 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hB10EsDP008976; Mon, 1 Dec 2003 01:14:55 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FCA7D8F.3000405@necom830.hpcl.titech.ac.jp> References: <5420088946.20031127153922@brandenburg.com> <421EA354-2329-11D8-AA85-000A95CD987A@muada.com> <3FCA7D8F.3000405@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <51AEDA39-2393-11D8-AA85-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Some Comments on ID/Loc Separation Proposals Date: Mon, 1 Dec 2003 01:14:24 +0100 To: Masataka Ohta X-Mailer: Apple Mail (2.606) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 1-dec-03, at 0:30, Masataka Ohta wrote: >> Personally, I prefer to talk about hosts, as this is a well-known >> concept. The fact that there is some ambiguity because hosts can be >> clustered and virtualized also isn't a huge surprise to most people, >> and can be spelled out for good measure. > "virtualize" means "as if it is real. > "virtualized host" means "muptiple entities behaving as if it is a > single host". > So, for the purpose of network protocol, treat it as a plain host. Right. > All the rest is internal implementation details within a host. Yes. This is more or less my point. > There is no room of confusion. There is always room for two things: desert and confusion. ;-)