From netlmm-bounces@ietf.org Tue Sep 04 06:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISW6a-0004am-Ti; Tue, 04 Sep 2007 06:58:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISW6Z-0004WV-7M for netlmm@ietf.org; Tue, 04 Sep 2007 06:57:59 -0400 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISW6X-0005MM-W9 for netlmm@ietf.org; Tue, 04 Sep 2007 06:57:59 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1089494rvb for ; Tue, 04 Sep 2007 03:57:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; b=LtY79eVjU2YXH0nouAfcpMFycFEVMjU+GT8JzcboVTWUlC/bQBHWWfsO1F6xftIF+bTX1QJVUCw/mPiDccLAgluEbDjJqELv7oky4vbYOueWsE5qGewPHK2aVELqf/Ipz1MQ/F1qNDwgxeXziiG8SO+D6xlZiAIiNL2+qI9CH04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=Gx8Axv6oH83uGuicNBYQ1KHu1+fpbuD0aTyhpJCnutmEJKUBOpc6hrOe6E9OVRU1JPKR/TRH1hFrAir0qdp6ya3zK6PB00z5a1nTt+qdRMzLUdTvZSl/GgPlzPSHEPbuMiO4dvTpSV3r1LIEHa/8eBIQ72o2VVvXw0iOQ+polOk= Received: by 10.141.76.21 with SMTP id d21mr943039rvl.1188903476602; Tue, 04 Sep 2007 03:57:56 -0700 (PDT) Received: by 10.141.185.9 with HTTP; Tue, 4 Sep 2007 03:57:56 -0700 (PDT) Message-ID: Date: Tue, 4 Sep 2007 19:57:56 +0900 From: "Jong-Hyouk Lee" To: abeille@netlab.nec.de Subject: [netlmm] RO establishment time in draft-abeille-netlmm-proxymip6ro-00. MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1046222147==" Errors-To: netlmm-bounces@ietf.org --===============1046222147== Content-Type: multipart/alternative; boundary="----=_Part_4849_3264457.1188903476613" ------=_Part_4849_3264457.1188903476613 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear colleague. In draft-abeille-netlmm-proxymip6ro-00, the route optimization (RO) procedure is defined and some scenarios are well described. However, there are ambiguous things, the actual RO establishment time and the actions in LMA after sending RO Report Ack. Well, for simplicity, take Fig. 2 in the document. When the packets of MN1 are sent directly via the RO path between MAG1 and MAG2? After receiving RO Setup Ack at MAG1? Also, after receiving RO Report at LMA1, it sends RO Report Ack. After that, what is the next actions at LMA? Please, make clear. Cheers. -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://www.hurryon.org ------=_Part_4849_3264457.1188903476613 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear colleague.
 
In draft-abeille-netlmm-proxymip6ro-00, the route optimization (RO) procedure is defined and some scenarios are well described. However, there are ambiguous things, the actual RO establishment time and the actions in LMA after sending RO Report Ack.
 
Well, for simplicity, take Fig. 2 in the document. When the packets of MN1 are sent directly via the RO path between MAG1 and MAG2? After receiving RO Setup Ack at MAG1? Also, after receiving RO Report at LMA1, it sends RO Report Ack. After that, what is the next actions at LMA?
 
Please, make clear.
 
Cheers.

--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
------=_Part_4849_3264457.1188903476613-- --===============1046222147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============1046222147==-- From netlmm-bounces@ietf.org Tue Sep 04 08:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXC2-0000q7-6A; Tue, 04 Sep 2007 08:07:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXC0-0000q2-O5 for netlmm@ietf.org; Tue, 04 Sep 2007 08:07:40 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISXBz-0007TO-5w for netlmm@ietf.org; Tue, 04 Sep 2007 08:07:40 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A4744212C63; Tue, 4 Sep 2007 15:07:37 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6697D212C59; Tue, 4 Sep 2007 15:07:37 +0300 (EEST) Message-ID: <46DD4A89.2080200@nomadiclab.com> Date: Tue, 04 Sep 2007 15:07:37 +0300 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA887@zrc2hxm2.corp.nortel.com> <001801c78e09$d207e0d0$0586500a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA43711400B717@zrc2hxm2.corp.nortel.com> <05f601c7e6d1$5cf85380$8142150a@amer.cisco.com> <46D2EA4A.7080204@gmail.com> <012401c7e974$88e97d70$d4f6200a@amer.cisco.com> <46D433D4.2080907@gmail.com> <013e01c7e993$36b563b0$d4f6200a@amer.cisco.com> <46D5658B.90408@gmail.com> <023e01c7ea3b$ebe3e6a0$d4f6200a@amer.cisco.com> <46D5709E.8060309@nsn.com> <46D57291.1060700@gmail.com> In-Reply-To: <46D57291.1060700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Kilian Weniger' , netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alexandru Petrescu wrote: > -use of NTP timestamp format is incompatible with ISO C 200X. > -use of NTP protocol for syncing is incompatible with IEEE 802.16 > requiring TIME instead of NTP. > -use of timestamps to avoid sequencing issues upon handovers is new > software development (if starting from MIP6 and going to PMIP6), > whereas the problem could be solved with seqno tools from MIP6. > -use of NTP timestamps obviously has problems of solving the sequencing > problem in year 2036. Alex, you have actually brought up two issues: (1) Should we use time stamps at all? And if yes: (2) Should we require NTP for clock synchronization? Our consensus addressed issue (1), and my personal believe is that we should stick to it. Use of time stamps will be the default for reordering protection. But alternatives will be possible as future P-MIPv6 extensions. (Of course, such extensions will have to consider interoperability between P-MIPv6 domains to allow roaming.) Therefore, in-line with what Kilian suggested, /support/ (i.e., implementation) of time stamps should be a "MUST", whereas /use/ of time stamps should be a "MUST unless an alternative mechanism for reordering prevention is in place." Regarding issue (2), I think your point is valid that the P-MIPv6 spec should not require NTP, but leave it up to the operator how to synchronize clocks. But the text that Sri suggested already provides such flexibility. The only dependency on NTP currently is with the time stamp format for P-MIPv6 messages, which will get fixed by adopting the format from SEND as suggested by Julien. Given that issue #160 in our tracker equals the above issue (1), and given that we reached consensus on that, I will close it down now. Of course, I will reopen it if that consensus gets challenged. - Christian _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 04 08:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXHS-0007oj-Jr; Tue, 04 Sep 2007 08:13:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXHR-0007ng-TN for netlmm@ietf.org; Tue, 04 Sep 2007 08:13:17 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISXHR-0007Bi-Bx for netlmm@ietf.org; Tue, 04 Sep 2007 08:13:17 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5DF9B212C63 for ; Tue, 4 Sep 2007 15:13:15 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E0D23212C59 for ; Tue, 4 Sep 2007 15:13:14 +0300 (EEST) Resent-From: Christian Vogt Resent-To: NetLMM Mailing List Resent-Date: Tue, 4 Sep 2007 15:13:14 +0300 Resent-Message-Id: <46DD4BDA.4040804@nomadiclab.com> Resent-User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13 Mnenhy/0.7.5.0 Received: from murder ([unix socket]) (authenticated user=chvogt bits=0) by p130.piuha.net (Cyrus v2.2.13) with LMTPA; Tue, 04 Sep 2007 15:12:40 +0300 X-Sieve: CMU Sieve 2.2 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on p130.piuha.net X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=ham version=3.2.3 X-Original-To: christian.vogt@piuha.net Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 36E7E19867F for ; Tue, 4 Sep 2007 15:12:34 +0300 (EEST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by p130.piuha.net (Postfix) with ESMTP id 0651319866A for ; Tue, 4 Sep 2007 15:12:34 +0300 (EEST) Received: by n2.nomadiclab.com (Postfix) id F3B1B212C59; Tue, 4 Sep 2007 15:12:33 +0300 (EEST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B7EAC212C63 for ; Tue, 4 Sep 2007 15:12:33 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 80054212C59 for ; Tue, 4 Sep 2007 15:12:33 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 3F5FABDC43 for ; Tue, 4 Sep 2007 15:12:33 +0300 (EEST) Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by outside.nomadiclab.com (Postfix) with ESMTP id 0861EBDC42 for ; Tue, 4 Sep 2007 15:12:32 +0300 (EEST) Received: from localhost ([127.0.0.1]:40161 helo=merlot.tools.ietf.org ident=www-data) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1ISXGh-0002QK-8r; Tue, 04 Sep 2007 14:12:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ascii" Content-Transfer-Encoding: 7bit From: "NetLMM" X-Trac-Version: 0.10.4 X-Mailer: Trac 0.10.4, by Edgewall Software X-Trac-Project: NetLMM Date: Tue, 04 Sep 2007 12:12:31 -0000 X-URL: http://tools.ietf.org/wg/netlmm/ Subject: Re: [NetLMM] #160: Timestamps vs. Sequence Numbers X-Trac-Ticket-URL: http://www3.tools.ietf.org/wg/netlmm/trac/ticket/160#comment:2 Message-ID: <080.0345727f5ea6b049aa2002291dee3195@tools.ietf.org> References: <071.c25d6fff1e95cb8a0385625692db88cb@tools.ietf.org> X-Trac-Ticket-ID: 160 In-Reply-To: <071.c25d6fff1e95cb8a0385625692db88cb@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: christian.vogt@nomadiclab.com, sgundave@cisco.com, amuhanna@nortel.com X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false To: undisclosed-recipients:; X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: trac@tools.ietf.org List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netlmm-bounces@ietf.org Errors-To: netlmm-bounces@ietf.org Resent-Date: Tue, 04 Sep 2007 08:13:18 -0400 #160: Timestamps vs. Sequence Numbers -----------------------------------------+---------------------------------- Reporter: christian.vogt@ericsson.com | Owner: christian.vogt@nomadiclab.com Type: technical | Status: closed Priority: normal | Milestone: PMIPv6 base specification Component: draft-ietf-netlmm-proxymip6 | Resolution: fixed Keywords: | -----------------------------------------+---------------------------------- Changes (by christian.vogt@nomadiclab.com): * status: assigned => closed * resolution: => fixed Comment: The working group consensus was to use time stamps as a default. Future P-MIPv6 extensions may define alternative mechanisms for reordering prevention. Sri Gundavelli proposed text for a new section 5.5, "Timestamp Option for Message Ordering", on the mailing list on August 25, 2007. With some modifications that were agreed upon on the mailing list, this solves this issue for now. -- Ticket URL: NetLMM _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 04 09:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISY7h-0003Sv-IF; Tue, 04 Sep 2007 09:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISY7f-0003S2-OM for netlmm@ietf.org; Tue, 04 Sep 2007 09:07:15 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISY7e-0000d5-Fj for netlmm@ietf.org; Tue, 04 Sep 2007 09:07:15 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1188911233!7582809!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 595 invoked from network); 4 Sep 2007 13:07:13 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-11.tower-153.messagelabs.com with SMTP; 4 Sep 2007 13:07:13 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l84D7CR6020294; Tue, 4 Sep 2007 06:07:12 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l84D7BjU024607; Tue, 4 Sep 2007 08:07:11 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l84D771N024555; Tue, 4 Sep 2007 08:07:08 -0500 (CDT) Message-ID: <46DD587A.4070504@gmail.com> Date: Tue, 04 Sep 2007 15:07:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Vogt Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA887@zrc2hxm2.corp.nortel.com> <001801c78e09$d207e0d0$0586500a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA43711400B717@zrc2hxm2.corp.nortel.com> <05f601c7e6d1$5cf85380$8142150a@amer.cisco.com> <46D2EA4A.7080204@gmail.com> <012401c7e974$88e97d70$d4f6200a@amer.cisco.com> <46D433D4.2080907@gmail.com> <013e01c7e993$36b563b0$d4f6200a@amer.cisco.com> <46D5658B.90408@gmail.com> <023e01c7ea3b$ebe3e6a0$d4f6200a@amer.cisco.com> <46D5709E.8060309@nsn.com> <46D57291.1060700@gmail.com> <46DD4A89.2080200@nomadiclab.com> In-Reply-To: <46DD4A89.2080200@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000772-0, 03/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Julien Laganier , 'Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Christian Vogt wrote: > Alexandru Petrescu wrote: >> -use of NTP timestamp format is incompatible with ISO C 200X. -use >> of NTP protocol for syncing is incompatible with IEEE 802.16 >> requiring TIME instead of NTP. -use of timestamps to avoid >> sequencing issues upon handovers is new software development (if >> starting from MIP6 and going to PMIP6), whereas the problem could >> be solved with seqno tools from MIP6. -use of NTP timestamps >> obviously has problems of solving the sequencing problem in year >> 2036. > > Alex, > > you have actually brought up two issues: (1) Should we use time > stamps at all? And if yes: (2) Should we require NTP for clock > synchronization? Right Christian, it's different issues. I'd say (1) should we use timestamps or seqnos? (2) should we require the NTP's way of encoding timestamps or should we use ISO C200X way of encoding? and (3) should we require the use of NTP to sync clocks or should we require the use of GPS to sync clocks, or the use of TIME protocol? > Our consensus addressed issue (1), and my personal believe is that we > should stick to it. Use of time stamps will be the default for > reordering protection. Ok, I see I can not convince you. Why did I raise all this; When trying to implement a system relying on timestamps as opposed to relying on seqnos: my personal experience is that the latter is much easier to make reliable. > But alternatives will be possible as future P-MIPv6 extensions. (Of > course, such extensions will have to consider interoperability > between P-MIPv6 domains to allow roaming.) I think even the base timestamp logic as written today (reliance on NTP) has to consider interoperability between P-MIPv6 domains to allow roaming. If a PMIPv6 synchs its clocks and another doesn't then obviously is a risk of out-of-order P-BUs when roaming. Also, there's a difference between keeping synchronous time locally, within a system, and keeping a synchronous time to universal time. Many systems just do the former. Also, implementation-wise, issues about bad and incompatible time keep come up regularly. It is not long ago that a known software manufacturer accepted that its way of representing and using timezones between two different applications was wrong, with very important impact on business (people's calendars got messed). > Therefore, in-line with what Kilian suggested, /support/ (i.e., > implementation) of time stamps should be a "MUST", whereas /use/ of > time stamps should be a "MUST unless an alternative mechanism for > reordering prevention is in place." I agree, I think the alternative is already in place, based on MIP6 seqnos. It's surprising P-MIPv6 needs seqnos whereas MIP6 doesn't. > Regarding issue (2), I think your point is valid that the P-MIPv6 > spec should not require NTP, but leave it up to the operator how to > synchronize clocks. But the text that Sri suggested already provides > such flexibility. The only dependency on NTP currently is with the > time stamp format for P-MIPv6 messages, which will get fixed by > adopting the format from SEND as suggested by Julien. I agree, I think SeND format (48/16bit seconds since 1970) is better than NTP format (32/32bit seconds since 1900) at least because more compatible with some Unices and because delays the roll-over flag day to much later than 2036. But I think the roll-over issue is still there. IMHO SeND could get rid of the timestamp as well. At minimal, IMHO we could write in the doc the roll-over P-MIPv6 year, by the Gregorian calendar (anyone cares to compute the year?) when P-MIPv6 will have issues and how it should seamlessly be dealt with it without disrupting service to MN. > Given that issue #160 in our tracker equals the above issue (1), and > given that we reached consensus on that, I will close it down now. > Of course, I will reopen it if that consensus gets challenged. Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 04 11:27:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaJp-000186-Us; Tue, 04 Sep 2007 11:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaJp-00017z-9e for netlmm@ietf.org; Tue, 04 Sep 2007 11:27:57 -0400 Received: from fk-out-0910.google.com ([209.85.128.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISaJn-0004X8-T6 for netlmm@ietf.org; Tue, 04 Sep 2007 11:27:57 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1675787fkz for ; Tue, 04 Sep 2007 08:27:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-disposition:message-id:content-type:content-transfer-encoding:sender; b=tpANa2xdyV+KLnyUsRqDnp/LPEk7ZKSmvnV0YebdVakPKaVL6z2AoNNIfiiMsaUWOkZMfe+neW+wN/DSPmR0fc3D3tuHawh+yBCVKD73nnnfSXw8R2pderB+fyyD/aX1N8EQElbmKQDwa6d0gzGo/+PiAA61SJ5xvMuwSFyFQtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-disposition:message-id:content-type:content-transfer-encoding:sender; b=d7vVllmDFL7t1Wnv8GhIyEAxJ/y0uyQ7ugrWlA0VZGqHuK4LsOFngMF8L+4HpbSd2iVuQdIxaxMGaWTZbXZhgS3txJsMUQm7agMkJafhzkmRL0qf4NZ/TELQDwlaaEkG40FUdQ6uUZSX2GvrL0FoAvXb+QVj5Y3FFR5cuJ+9zo0= Received: by 10.82.100.1 with SMTP id x1mr13942658bub.1188919674685; Tue, 04 Sep 2007 08:27:54 -0700 (PDT) Received: from ?192.168.1.28? ( [212.119.9.178]) by mx.google.com with ESMTPS id e23sm8102894ugd.2007.09.04.08.27.52 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2007 08:27:53 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic Date: Tue, 4 Sep 2007 17:27:49 +0200 User-Agent: KMail/1.9.6 References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <46DD4A89.2080200@nomadiclab.com> <46DD587A.4070504@gmail.com> In-Reply-To: <46DD587A.4070504@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200709041727.50014.julien.IETF@laposte.net> Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Christian Vogt , 'Kilian Weniger' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Tuesday 04 September 2007, Alexandru Petrescu wrote: > I agree, I think SeND format (48/16bit seconds since =A01970) is better > than NTP format (32/32bit seconds since 1900) at least because more > compatible with some Unices and because delays the roll-over flag day > to much later than 2036. =A0But I think the roll-over issue is still > there. IMHO SeND could get rid =A0of the timestamp as well. > > At minimal, IMHO we could write in the doc the roll-over P-MIPv6 > year, by the Gregorian calendar (anyone cares to compute the year?) > when P-MIPv6 will have issues and how it should seamlessly be dealt > with it without disrupting service to MN. Alex, as I wrote earlier with 48bits seconds we are safe for nearly 9=20 millions years. =2D-julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 04 12:14:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISb2n-0003PN-Bq; Tue, 04 Sep 2007 12:14:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISb2l-0003PH-Qg for netlmm@ietf.org; Tue, 04 Sep 2007 12:14:23 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISb2l-0005Y3-Ax for netlmm@ietf.org; Tue, 04 Sep 2007 12:14:23 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1188922461!2605463!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 16662 invoked from network); 4 Sep 2007 16:14:21 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-128.messagelabs.com with SMTP; 4 Sep 2007 16:14:21 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l84GEGLr003206; Tue, 4 Sep 2007 09:14:21 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l84GEFk6008655; Tue, 4 Sep 2007 11:14:16 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l84GECXa008625; Tue, 4 Sep 2007 11:14:13 -0500 (CDT) Message-ID: <46DD8453.1050005@gmail.com> Date: Tue, 04 Sep 2007 18:14:11 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <46DD4A89.2080200@nomadiclab.com> <46DD587A.4070504@gmail.com> <200709041727.50014.julien.IETF@laposte.net> In-Reply-To: <200709041727.50014.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000772-0, 03/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Christian Vogt , 'Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > On Tuesday 04 September 2007, Alexandru Petrescu wrote: >> I agree, I think SeND format (48/16bit seconds since 1970) is >> better than NTP format (32/32bit seconds since 1900) at least >> because more compatible with some Unices and because delays the >> roll-over flag day to much later than 2036. But I think the >> roll-over issue is still there. IMHO SeND could get rid of the >> timestamp as well. >> >> At minimal, IMHO we could write in the doc the roll-over P-MIPv6 >> year, by the Gregorian calendar (anyone cares to compute the year?) >> when P-MIPv6 will have issues and how it should seamlessly be >> dealt with it without disrupting service to MN. > > Alex, as I wrote earlier with 48bits seconds we are safe for nearly 9 > millions years. Thanks, this is good to know (and sorry I have just seen now your previous message). We should then write down what happens at year 9million+1picosecond: (1) how is the LMA making sure it survives the overflowing P-BU without believing it's a very old P-BU; and (2) without disrupting service to MN. Don't you think so? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 04 23:10:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISlHp-0001kG-1h; Tue, 04 Sep 2007 23:10:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISlHl-0001cm-Re; Tue, 04 Sep 2007 23:10:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISlHk-0004hn-NH; Tue, 04 Sep 2007 23:10:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id AA1433289A; Wed, 5 Sep 2007 03:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ISlHG-0004K7-JW; Tue, 04 Sep 2007 23:10:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Sep 2007 23:10:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: netlmm@ietf.org Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-02.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF. Title : Proxy Mobile IPv6 Author(s) : S. Gundavelli, et al. Filename : draft-ietf-netlmm-proxymip6-02.txt Pages : 54 Date : 2007-09-04 This specification describes a network-based mobility management protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 Protocol [RFC-3775]. This protocol enables mobility support to a host within a domain and without requiring its participation in any mobility related signaling. The design principle in the case of network-based mobility management protocol relies on the network being in control of the mobility management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-netlmm-proxymip6-02.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-ietf-netlmm-proxymip6-02.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: <2007-09-04230812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netlmm-proxymip6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netlmm-proxymip6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-04230812.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --NextPart-- From netlmm-bounces@ietf.org Wed Sep 05 01:29:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISnRm-0000aW-79; Wed, 05 Sep 2007 01:29:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISnRk-0000TP-Ve for netlmm@ietf.org; Wed, 05 Sep 2007 01:29:00 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISnRj-0007U2-Co for netlmm@ietf.org; Wed, 05 Sep 2007 01:29:00 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1295774rvb for ; Tue, 04 Sep 2007 22:28:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Wd6UafkwcYA8nmX2csR0m5M/aMk//dJrtEokv+EEwZFdlnCTJewDNv957aps6ve8nm8gsxTtls+UiDqu9zJzWSNjEKjNVOrpNj7Ro3UOvsXraC2banRnYt7C1s8ycwfCqBY1h1+B0yldi0WpbDWJI4/lHlFjeDwrp0lWQlzZyfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=s7p6cjWJ1SxGEqx4rrZ+oCt+WEN0KOkPA3gcRAdcQRRYP4eQGQlKwahsDt8iNHieCbh1L7+XrXFwyG8T5x7pnI9jKxObZKRfSfbmuEcYj7dSvIqzy9MAnSQPf4z3gsQ1t/v6sKbFjfhb1EJHteW/YC1m4B5/KhYM9IQDSrl8tJk= Received: by 10.141.88.3 with SMTP id q3mr2661053rvl.1188970137767; Tue, 04 Sep 2007 22:28:57 -0700 (PDT) Received: by 10.141.185.9 with HTTP; Tue, 4 Sep 2007 22:28:57 -0700 (PDT) Message-ID: Date: Wed, 5 Sep 2007 14:28:57 +0900 From: "Jong-Hyouk Lee" To: sgundave@cisco.com Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-02.txt In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1609296446==" Errors-To: netlmm-bounces@ietf.org --===============1609296446== Content-Type: multipart/alternative; boundary="----=_Part_8007_27777527.1188970137306" ------=_Part_8007_27777527.1188970137306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear colleague. Now, I skip over the submitted document. There is an editing mistake. Take the end part of page 11 in the document. "After obtaining the address configuration, if the mobile node changes ... " Cheers. On 9/5/07, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Network-based Localized Mobility > Management Working Group of the IETF. > > > Title : Proxy Mobile IPv6 > Author(s) : S. Gundavelli, et al. > Filename : draft-ietf-netlmm-proxymip6-02.txt > Pages : 54 > Date : 2007-09-04 > > This specification describes a network-based mobility management > protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 > Protocol [RFC-3775]. This protocol enables mobility support to a > host within a domain and without requiring its participation in any > mobility related signaling. The design principle in the case of > network-based mobility management protocol relies on the network > being in control of the mobility management. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-ietf-netlmm-proxymip6-02.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-ietf-netlmm-proxymip6-02.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. > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > > -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://www.hurryon.org ------=_Part_8007_27777527.1188970137306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear colleague.
 
Now, I skip over the submitted document. There is an editing mistake. Take the end part of page 11 in the document.
 
"After obtaining the address configuration, if the mobile node changes ... "
 
Cheers.

 
On 9/5/07, Internet-Drafts@ietf.org <Internet-Drafts@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF.


       Title           : Proxy Mobile IPv6
       Author(s)       : S. Gundavelli, et al.
       Filename        : draft-ietf-netlmm-proxymip6-02.txt
       Pages           : 54
       Date            : 2007-09-04

This specification describes a network-based mobility management
protocol.  It is called Proxy Mobile IPv6 and is based on Mobile IPv6
Protocol [RFC-3775].  This protocol enables mobility support to a
host within a domain and without requiring its participation in any
mobility related signaling.  The design principle in the case of
network-based mobility management protocol relies on the network
being in control of the mobility management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-02.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-ietf-netlmm-proxymip6-02.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-ietf-netlmm-proxymip6-02.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.


_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm




--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org ------=_Part_8007_27777527.1188970137306-- --===============1609296446== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============1609296446==-- From netlmm-bounces@ietf.org Wed Sep 05 01:48:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISnk5-0001Qe-1x; Wed, 05 Sep 2007 01:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISnk3-0001QZ-TA for netlmm@ietf.org; Wed, 05 Sep 2007 01:47:55 -0400 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISnk2-00087G-Au for netlmm@ietf.org; Wed, 05 Sep 2007 01:47:55 -0400 Received: by rv-out-0910.google.com with SMTP id l15so1299057rvb for ; Tue, 04 Sep 2007 22:47:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; b=t2jHvMRZAdTiAGwDB8W5B/K7t7abKzlH5NTM5O03t4k20Cds9x/UIrew9pwO9g+M9sue7QGh/V9GAoIIoNypEaERQqcJ0Isbn5IVZ0D0Q6vBXTbULOygPbzC4lA32m7XPc9mIR3w9qdgvXR5X8J1Osn11egXij8pB7P2IT5+DmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=f0znWaQ5ODujCSDEKBbRxaH+Z1x73LuxZFG0JEU/zrLn74O5t3+eqv5HCrT2/IupkVzrph1BRZBzih3sEX0CkOIlNL+5nTtAMacoIRlS7z4ssGfI8YH0WNAoxEkZFgzGGDdIM9S+IRRyNsG/ym3HnwubkdXqjkxQILCwakfHiCc= Received: by 10.140.251.1 with SMTP id y1mr739845rvh.1188971273168; Tue, 04 Sep 2007 22:47:53 -0700 (PDT) Received: by 10.141.185.9 with HTTP; Tue, 4 Sep 2007 22:47:53 -0700 (PDT) Message-ID: Date: Wed, 5 Sep 2007 14:47:53 +0900 From: "Jong-Hyouk Lee" To: vijay.devarapalli@azairenet.com Subject: [netlmm] appropriate actions on draft-devarapalli-netlmm-pmipv6-heartbeat-00. MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1233134017==" Errors-To: netlmm-bounces@ietf.org --===============1233134017== Content-Type: multipart/alternative; boundary="----=_Part_8071_16311955.1188971273156" ------=_Part_8071_16311955.1188971273156 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear V. Devarapalli. In draft-devarapalli-netlmm-pmipv6-heartbeat-00, you mentioned that the appropriate actions, for instance, releasing resources, would be invoked or processed after the communication failure detection between the LMA and the MAG. If so, there needs to be a context switching or transfer protocol for such cases. Do you know any candidate protocol for this? Or shall we develop new one? Cheers. -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://www.hurryon.org ------=_Part_8071_16311955.1188971273156 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear V. Devarapalli.
 
In draft-devarapalli-netlmm-pmipv6-heartbeat-00, you mentioned that the appropriate actions, for instance, releasing resources, would be invoked or processed after the communication failure detection between the LMA and the MAG. If so, there needs to be a context switching or transfer protocol for such cases.
 
Do you know any candidate protocol for this? Or shall we develop new one?
 
Cheers. 

--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
------=_Part_8071_16311955.1188971273156-- --===============1233134017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============1233134017==-- From netlmm-bounces@ietf.org Wed Sep 05 05:21:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISr4X-0004xg-23; Wed, 05 Sep 2007 05:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISr4V-0004xY-5v for netlmm@ietf.org; Wed, 05 Sep 2007 05:21:15 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISr4T-0005K2-Pt for netlmm@ietf.org; Wed, 05 Sep 2007 05:21:15 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1188984072!7105654!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22409 invoked from network); 5 Sep 2007 09:21:12 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-153.messagelabs.com with SMTP; 5 Sep 2007 09:21:12 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l859L34u025954; Wed, 5 Sep 2007 02:21:08 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l859L3IM023628; Wed, 5 Sep 2007 04:21:03 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l859KxFj023579; Wed, 5 Sep 2007 04:21:00 -0500 (CDT) Message-ID: <46DE74FB.4000902@gmail.com> Date: Wed, 05 Sep 2007 11:20:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Vogt Subject: Re: time kept by 4 different systems (was: [netlmm] Issue: Timestamp vs Sequence Number based logic) References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA887@zrc2hxm2.corp.nortel.com> <001801c78e09$d207e0d0$0586500a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA43711400B717@zrc2hxm2.corp.nortel.com> <05f601c7e6d1$5cf85380$8142150a@amer.cisco.com> <46D2EA4A.7080204@gmail.com> <012401c7e974$88e97d70$d4f6200a@amer.cisco.com> <46D433D4.2080907@gmail.com> <013e01c7e993$36b563b0$d4f6200a@amer.cisco.com> <46D5658B.90408@gmail.com> <023e01c7ea3b$ebe3e6a0$d4f6200a@amer.cisco.com> <46D5709E.8060309@nsn.com> <46D57291.1060700@gmail.com> <46DD4A89.2080200@nomadiclab.com> In-Reply-To: <46DD4A89.2080200@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000772-3, 04/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 'Kilian Weniger' , netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Christian Vogt wrote: [...] > Given that issue #160 in our tracker equals the above issue (1), and > given that we reached consensus on that, I will close it down now. > Of course, I will reopen it if that consensus gets challenged. Hi Christian, first thank you for taking care thoroughly of this issue. I wanted to send another note about precision of time synchronization. I have just compared time kept by four different deployed systems: a Windows PC with NTP, a GSM handset, a GPS device without EGNOS, and a wristwatch on the German DCF77 long wave time signal. My observation is that the four systems display 4 different times, with as much as 1second difference between each two systems. How this relates to our P-MIPv6 issue of relying on time synchronization? Two: C.V.: > Use of time stamps will be the default for reordering protection. But > alternatives will be possible as future P-MIPv6 extensions. (Of > course, such extensions will have to consider interoperability > between P-MIPv6 domains to allow roaming.) The current P-MIPv6 relying on entities being time synchronized may have an issue of interoperability between P-MIPv6 domains (eg one domain keeps time with NTP and the other with DCF77). It is not only the future extensions that potentially have this issue. The other issue is that _if_ P-MIPv6 protocol relies on time synchronization then it should recommend that all entities within the P-MIPv6 domain (all LMAs and MAGs) keep the time by using the same unique method (examples of time keeping methods are NTP, TIME, GSM time synchronization, GPS and DCF77 - feel free to suggest another). Currently the document states: > o All the mobility entities in a Proxy Mobile IPv6 domain, > exchanging signaling messages using Timestamp option must have > adequately synchronized time-of-day clocks. These nodes SHOULD > synchronize their clocks to a common time source using Network > Time Protocol [RFC-1305]. I think the recommendation should be that MAGs and LMAs SHOULD keep time synchronized by a unique method. We surely don't want MAG to use GPS synchronization and LMA to use NTP synchronization. What do you think? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 05 08:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IStfc-00052Y-CT; Wed, 05 Sep 2007 08:07:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IStfa-00052D-Mv for netlmm@ietf.org; Wed, 05 Sep 2007 08:07:42 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IStfa-00039Q-6o for netlmm@ietf.org; Wed, 05 Sep 2007 08:07:42 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 41263212D39; Wed, 5 Sep 2007 15:07:40 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DFC2E212D1E; Wed, 5 Sep 2007 15:07:39 +0300 (EEST) Message-ID: <46DE9C0B.50701@nomadiclab.com> Date: Wed, 05 Sep 2007 15:07:39 +0300 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA887@zrc2hxm2.corp.nortel.com> <001801c78e09$d207e0d0$0586500a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA43711400B717@zrc2hxm2.corp.nortel.com> <05f601c7e6d1$5cf85380$8142150a@amer.cisco.com> <46D2EA4A.7080204@gmail.com> <012401c7e974$88e97d70$d4f6200a@amer.cisco.com> <46D433D4.2080907@gmail.com> <013e01c7e993$36b563b0$d4f6200a@amer.cisco.com> <46D5658B.90408@gmail.com> <023e01c7ea3b$ebe3e6a0$d4f6200a@amer.cisco.com> <46D5709E.8060309@nsn.com> <46D57291.1060700@gmail.com> <46DD4A89.2080200@nomadiclab.com> <46DD587A.4070504@gmail.com> In-Reply-To: <46DD587A.4070504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'Kilian Weniger' , netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > When trying to implement a system relying on timestamps as opposed to > relying on seqnos: my personal experience is that the latter is much > easier to make reliable. Alex, the reason why the WG considered timestamps superior to sequence numbers was that was the lack of a mechanism to synchronize sequence numbers across MAGs. OTOH, sufficiently precise timestamps would allow reordering prevention because there will always be a link layer handover and some link-local signaling between critical P-BU messages, and this will likely take much longer than the maximum error in clock synchronization. This is why we probably must accept some implementation and deployment challenges related to timestamps and clock synchronization. But, in another email, you described what P-MIPv6 domain operators should keep in mind for clock synchronization. I'd suggest that you write these recommendations down for inclusion in the P-MIPv6 spec. What do you and the other folks think about this? Best, - Christian _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 05 09:06:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuag-0002P7-V5; Wed, 05 Sep 2007 09:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuaf-0002OD-Gz for netlmm@ietf.org; Wed, 05 Sep 2007 09:06:41 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISuae-0002sb-8B for netlmm@ietf.org; Wed, 05 Sep 2007 09:06:41 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1188997598!5357780!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10267 invoked from network); 5 Sep 2007 13:06:38 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 5 Sep 2007 13:06:38 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l85D6c3C019119; Wed, 5 Sep 2007 06:06:38 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l85D6buc018695; Wed, 5 Sep 2007 08:06:37 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l85D6YBx018671; Wed, 5 Sep 2007 08:06:35 -0500 (CDT) Message-ID: <46DEA9D9.506@gmail.com> Date: Wed, 05 Sep 2007 15:06:33 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Vogt Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA887@zrc2hxm2.corp.nortel.com> <001801c78e09$d207e0d0$0586500a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA43711400B717@zrc2hxm2.corp.nortel.com> <05f601c7e6d1$5cf85380$8142150a@amer.cisco.com> <46D2EA4A.7080204@gmail.com> <012401c7e974$88e97d70$d4f6200a@amer.cisco.com> <46D433D4.2080907@gmail.com> <013e01c7e993$36b563b0$d4f6200a@amer.cisco.com> <46D5658B.90408@gmail.com> <023e01c7ea3b$ebe3e6a0$d4f6200a@amer.cisco.com> <46D5709E.8060309@nsn.com> <46D57291.1060700@gmail.com> <46DD4A89.2080200@nomadiclab.com> <46DD587A.4070504@gmail.com> <46DE9C0B.50701@nomadiclab.com> In-Reply-To: <46DE9C0B.50701@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000772-3, 04/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 'Kilian Weniger' , netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Christian Vogt wrote: >> When trying to implement a system relying on timestamps as opposed to >> relying on seqnos: my personal experience is that the latter is much >> easier to make reliable. > > Alex, > > the reason why the WG considered timestamps superior to sequence numbers was > that was the lack of a mechanism to synchronize sequence numbers across MAGs. In previous discussions there seemed to be some interest in making the seqno mechanism of 3775 to work for P-MIPv6 as well. I think it's not difficult to link the seqno to a MN address, at MAG. If there is interest I can contribute discussion to this. > OTOH, sufficiently precise timestamps would allow reordering prevention because > there will always be a link layer handover and some link-local signaling between > critical P-BU messages, and this will likely take much longer than the maximum > error in clock synchronization. I'm not sure what example you have in mind... but if we consider some average wifi link-layer handovers to be around 500ms this is clearly below the 1s I've noticed as error between time keeping of different systems. Most performant wifi handovers I've seen are around 5ms. What do you consider as link-layer handover time? What technology? > This is why we probably must accept some implementation and deployment > challenges related to timestamps and clock synchronization. I think this is artificial. I don't think we have a clear idea about what the P-MIPv6 handover time is. > But, in another email, you described what P-MIPv6 domain operators should keep > in mind for clock synchronization. I'd suggest that you write these > recommendations down for inclusion in the P-MIPv6 spec. What do you and the > other folks think about this? If other people agree then yes, I can write recommendations about time synchronization... (ideally I'd like to contribute to a mechanism for MAG to use seqnos linked to the MN address, instead; and not recommending time synchronization at all.) Alex > > Best, > - Christian > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 05 09:29:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuwt-0003dk-5P; Wed, 05 Sep 2007 09:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuws-0003df-1I for netlmm@ietf.org; Wed, 05 Sep 2007 09:29:38 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISuwq-0003Vh-Fx for netlmm@ietf.org; Wed, 05 Sep 2007 09:29:38 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9BD13212D37; Wed, 5 Sep 2007 16:29:34 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5FCDC212D1E; Wed, 5 Sep 2007 16:29:34 +0300 (EEST) Message-ID: <46DEAF3E.1000007@nomadiclab.com> Date: Wed, 05 Sep 2007 16:29:34 +0300 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA887@zrc2hxm2.corp.nortel.com> <001801c78e09$d207e0d0$0586500a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA43711400B717@zrc2hxm2.corp.nortel.com> <05f601c7e6d1$5cf85380$8142150a@amer.cisco.com> <46D2EA4A.7080204@gmail.com> <012401c7e974$88e97d70$d4f6200a@amer.cisco.com> <46D433D4.2080907@gmail.com> <013e01c7e993$36b563b0$d4f6200a@amer.cisco.com> <46D5658B.90408@gmail.com> <023e01c7ea3b$ebe3e6a0$d4f6200a@amer.cisco.com> <46D5709E.8060309@nsn.com> <46D57291.1060700@gmail.com> <46DD4A89.2080200@nomadiclab.com> <46DD587A.4070504@gmail.com> <46DE9C0B.50701@nomadiclab.com> <46DEA9D9.506@gmail.com> In-Reply-To: <46DEA9D9.506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'Kilian Weniger' , netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > I'm not sure what example you have in mind... but if we consider some average > wifi link-layer handovers to be around 500ms this is clearly below the 1s > I've noticed as error between time keeping of different systems. Most > performant wifi handovers I've seen are around 5ms. Alex, I fully agree with you that we should not focus on link layer handover delays that are prevalent today, but that we should support much lower ones. But at least within a single P-MIPv6 domain, it should well be possible to reduce synchronization errors to below 1 ms because the round-trip times are then sufficiently small. As I had mentioned in an earlier email, roaming across P-MIPv6 domains requires global clock synchronization, where errors might be higher. This requires additional thought on how to synchronize clocks. - Christian _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 05 09:41:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISv7s-0004Uj-DJ; Wed, 05 Sep 2007 09:41:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISv7q-0004Ud-CK for netlmm@ietf.org; Wed, 05 Sep 2007 09:40:58 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISv7p-0003pD-7I for netlmm@ietf.org; Wed, 05 Sep 2007 09:40:58 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1188999656!23642476!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 9890 invoked from network); 5 Sep 2007 13:40:56 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-11.tower-119.messagelabs.com with SMTP; 5 Sep 2007 13:40:56 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l85DetuV022447; Wed, 5 Sep 2007 06:40:55 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l85Des79025417; Wed, 5 Sep 2007 08:40:54 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l85DeodF025248; Wed, 5 Sep 2007 08:40:51 -0500 (CDT) Message-ID: <46DEB1D7.2060703@gmail.com> Date: Wed, 05 Sep 2007 15:40:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Christian Vogt Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437113FBA887@zrc2hxm2.corp.nortel.com> <001801c78e09$d207e0d0$0586500a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA43711400B717@zrc2hxm2.corp.nortel.com> <05f601c7e6d1$5cf85380$8142150a@amer.cisco.com> <46D2EA4A.7080204@gmail.com> <012401c7e974$88e97d70$d4f6200a@amer.cisco.com> <46D433D4.2080907@gmail.com> <013e01c7e993$36b563b0$d4f6200a@amer.cisco.com> <46D5658B.90408@gmail.com> <023e01c7ea3b$ebe3e6a0$d4f6200a@amer.cisco.com> <46D5709E.8060309@nsn.com> <46D57291.1060700@gmail.com> <46DD4A89.2080200@nomadiclab.com> <46DD587A.4070504@gmail.com> <46DE9C0B.50701@nomadiclab.com> <46DEA9D9.506@gmail.com> <46DEAF3E.1000007@nomadiclab.com> In-Reply-To: <46DEAF3E.1000007@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000772-3, 04/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'Kilian Weniger' , netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Christian Vogt wrote: >> I'm not sure what example you have in mind... but if we consider some average >> wifi link-layer handovers to be around 500ms this is clearly below the 1s >> I've noticed as error between time keeping of different systems. Most >> performant wifi handovers I've seen are around 5ms. > > Alex, > > I fully agree with you that we should not focus on link layer handover delays > that are prevalent today, but that we should support much lower ones. > > But at least within a single P-MIPv6 domain, it should well be possible to > reduce synchronization errors to below 1 ms because the round-trip times are > then sufficiently small. I agree, provided every MAG and the LMA within that domain use the same time synchronization mechanism. I think, not sure, that when you say '1ms' you already assume that they use NTP, because NTP is known to claim that '1ms' accuracy. > As I had mentioned in an earlier email, roaming across P-MIPv6 domains requires > global clock synchronization, where errors might be higher. This requires > additional thought on how to synchronize clocks. I agree. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 05 16:14:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1Gz-0003HD-W3; Wed, 05 Sep 2007 16:14:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1Gy-0003H7-MR for netlmm@ietf.org; Wed, 05 Sep 2007 16:14:48 -0400 Received: from mout.perfora.net ([74.208.4.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT1Gy-0000vu-8f for netlmm@ietf.org; Wed, 05 Sep 2007 16:14:48 -0400 Received: from [88.234.104.169] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IT1Gc488j-0008Oy; Wed, 05 Sep 2007 16:14:36 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" , "'Christian Vogt'" Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic Date: Wed, 5 Sep 2007 23:14:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46DEB1D7.2060703@gmail.com> Thread-Index: AcfvwmWQSv2KqyX8Sya+9FJbZX65EAANg6Ig Message-Id: <0MKp8S-1IT1Gc488j-0008Oy@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+KfIN+I98cgs2pLsfk7wZ4Pl1gLrGqSpJWGMq 4DrexqywRor6O3vKKSaKQAjGQ302uJlT6Wm9vDiGxL36cSVtSP pRTaWTCTUyDMP0IRWFmUQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Kilian Weniger' , netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hello, > Christian Vogt wrote: > >> I'm not sure what example you have in mind... but if we consider some > average > >> wifi link-layer handovers to be around 500ms this is clearly below the > 1s > >> I've noticed as error between time keeping of different systems. Most > >> performant wifi handovers I've seen are around 5ms. > > > > Alex, > > > > I fully agree with you that we should not focus on link layer handover > delays > > that are prevalent today, but that we should support much lower ones. > > > > But at least within a single P-MIPv6 domain, it should well be possible > to > > reduce synchronization errors to below 1 ms because the round-trip times > are > > then sufficiently small. There seems to be an assumption here with respect to the distance between the MAG and LMA. Considering how PMIP6 will be deployed with various architectures (e.g., WiMAX), I don't think we can make this assumption. > I agree, provided every MAG and the LMA within that domain use the same > time synchronization mechanism. > > I think, not sure, that when you say '1ms' you already assume that they > use NTP, because NTP is known to claim that '1ms' accuracy. > > > As I had mentioned in an earlier email, roaming across P-MIPv6 domains > requires > > global clock synchronization, where errors might be higher. This > requires > > additional thought on how to synchronize clocks. Are we talking about synchronizing the clocks among all MAGs and LMAs that are interacting with each other? Each MAG and LMA may belong to a different operator, located at a different corner of the Internet. Can NTP practically deal with this? Just asking... Alper _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 05 16:32:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1YU-0001Tw-3u; Wed, 05 Sep 2007 16:32:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT1YT-0001Tr-La for netlmm@ietf.org; Wed, 05 Sep 2007 16:32:53 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IT1YS-000202-VM for netlmm@ietf.org; Wed, 05 Sep 2007 16:32:53 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Sep 2007 13:32:52 -0700 X-IronPort-AV: i="4.20,211,1186383600"; d="scan'208"; a="520828542:sNHT67741614" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l85KWqId017120; Wed, 5 Sep 2007 13:32:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l85KWpxN020569; Wed, 5 Sep 2007 20:32:51 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 13:32:47 -0700 Received: from sgundavewxp ([128.107.163.44]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 13:32:46 -0700 From: "Sri Gundavelli" To: "'Alper Yegin'" , "'Alexandru Petrescu'" , "'Christian Vogt'" References: <46DEB1D7.2060703@gmail.com> <0MKp8S-1IT1Gc488j-0008Oy@mrelay.perfora.net> Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic Date: Wed, 5 Sep 2007 13:32:46 -0700 Message-ID: <00ee01c7effb$eafe42b0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <0MKp8S-1IT1Gc488j-0008Oy@mrelay.perfora.net> Thread-Index: AcfvwmWQSv2KqyX8Sya+9FJbZX65EAANg6IgAABwbiA= X-OriginalArrivalTime: 05 Sep 2007 20:32:46.0617 (UTC) FILETIME=[EB425090:01C7EFFB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3602; t=1189024372; x=1189888372; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Timestamp=20vs=20Sequence=20Num ber=20based=20logic |Sender:=20; bh=xm7HgEAEyQNkmDbrQRCK1yLoeFDmGiI2/f/DK5poUDk=; b=gS+5gH+lArkw/IzEvhkxcmELdQ8I64Una1NRlD2cx66/KRmHFkE2qRJytKOiF0dUoHlMZzAn WEADhhPB7y4FZb6VJSMwwB5fX1d293AuWGscu/dRLYopEbQaUgb7fmps; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: 'Kilian Weniger' , netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Wednesday, September 05, 2007 1:14 PM > To: 'Alexandru Petrescu'; 'Christian Vogt' > Cc: 'Kilian Weniger'; netlmm@ietf.org; 'Julien Laganier' > Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic > > Hello, > > > Christian Vogt wrote: > > >> I'm not sure what example you have in mind... but if we > consider some > > average > > >> wifi link-layer handovers to be around 500ms this is > clearly below the > > 1s > > >> I've noticed as error between time keeping of different > systems. Most > > >> performant wifi handovers I've seen are around 5ms. > > > > > > Alex, > > > > > > I fully agree with you that we should not focus on link > layer handover > > delays > > > that are prevalent today, but that we should support much > lower ones. > > > > > > But at least within a single P-MIPv6 domain, it should > well be possible > > to > > > reduce synchronization errors to below 1 ms because the > round-trip times > > are > > > then sufficiently small. > > There seems to be an assumption here with respect to the > distance between > the MAG and LMA. Considering how PMIP6 will be deployed with various > architectures (e.g., WiMAX), I don't think we can make this > assumption. > > > > I agree, provided every MAG and the LMA within that domain > use the same > > time synchronization mechanism. > > > > I think, not sure, that when you say '1ms' you already > assume that they > > use NTP, because NTP is known to claim that '1ms' accuracy. > > > > > As I had mentioned in an earlier email, roaming across > P-MIPv6 domains > > requires > > > global clock synchronization, where errors might be higher. This > > requires > > > additional thought on how to synchronize clocks. > > Are we talking about synchronizing the clocks among all MAGs > and LMAs that > are interacting with each other? Each MAG and LMA may belong > to a different > operator, located at a different corner of the Internet. Can > NTP practically > deal with this? Just asking... > It is important to highlight the fact that we need this entire synchronization logic to avoid one scenario, where the LMA ends up processing a PBU that was sent by pMAG and the LMA received that much later due to network out of order deliverly. In my mind, this is a special case. Now the solutions: The spec supports both Sequence Number based and Timestamp based approaches. If a given architecture has some kind of interface between MAG to MAG for context transfers, which I assume it is true for WiMAX as well, then the sequence number based scheme will just fine. Now, for completeness, in the absence of a context transfer protocol, the base spec supports a Timestamp based approach. It expects the LMA's and MAG's to sync to a common clock source. If a deployment does not enable NTP kind of protocols and if the LMA receives a packet with PBU from a MAG with a invalid timestamp, the LMA can return its own timestamp and the MAG can use the same in the requests to avoid this special race condition. So, it should not be a concern that the LMA and MAG are in different domains and syncing is an issue. Also, MIP4 uses timestamp based logic and there are deployments based on that. Regards Sri > > Alper > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 02:20:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITAik-0004YY-R3; Thu, 06 Sep 2007 02:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITAig-0004YE-MP; Thu, 06 Sep 2007 02:20:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITAig-0004ZS-7t; Thu, 06 Sep 2007 02:20:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2609F26E65; Thu, 6 Sep 2007 06:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ITAig-0002uA-1l; Thu, 06 Sep 2007 02:20:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 06 Sep 2007 02:20:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: netlmm@ietf.org Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF. Title : Proxy Mobile IPv6 Author(s) : S. Gundavelli, et al. Filename : draft-ietf-netlmm-proxymip6-03.txt Pages : 55 Date : 2007-09-06 This specification describes a network-based mobility management protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 [RFC-3775]. This protocol enables mobility support to a host without requiring its participation in any mobility related signaling. The design principle in the case of network-based mobility management protocol relies on the network being in control of the mobility management. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-netlmm-proxymip6-03.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-ietf-netlmm-proxymip6-03.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: <2007-09-06021915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netlmm-proxymip6-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netlmm-proxymip6-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-06021915.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --NextPart-- From netlmm-bounces@ietf.org Thu Sep 06 02:34:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITAwK-0007Hj-Jv; Thu, 06 Sep 2007 02:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITAwJ-0007Ha-Mq for netlmm@ietf.org; Thu, 06 Sep 2007 02:34:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITAwI-000580-Dc for netlmm@ietf.org; Thu, 06 Sep 2007 02:34:07 -0400 X-IronPort-AV: E=Sophos;i="4.20,214,1186383600"; d="scan'208";a="174622166" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 05 Sep 2007 23:34:05 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l866Y5mP021460 for ; Wed, 5 Sep 2007 23:34:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l866Y57P012201 for ; Thu, 6 Sep 2007 06:34:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 23:34:05 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 23:34:05 -0700 From: "Sri Gundavelli" To: References: Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt Date: Wed, 5 Sep 2007 23:34:04 -0700 Message-ID: <013f01c7f04f$ebbd1ab0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfwTglzGxi+UdpsQHGbbtafLERnrAAAWvZQ X-OriginalArrivalTime: 06 Sep 2007 06:34:05.0519 (UTC) FILETIME=[EBF5DDF0:01C7F04F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3274; t=1189060445; x=1189924445; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-proxymip6 -03.txt=20 |Sender:=20; bh=Obfc7sXZBNSo6zOmm0XTLWjnWGXFQr/exZKCj7JYXdM=; b=FHkZ4giBSGkPSd5KpdfeV5/OFe7L1To37ZjHPoHeN5bTqUz7bao0pm3nfwI7TmhbS0+mJSi7 Lgp2efrF3dvFoKNFLjCivSHq6COX8Szy4rt/xjaeztgGg90uThJiWUMLyARrcJgUn0f2yoCnRr YtFGyOrCNXqQiVSp1cQmwCZks=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org This is the latest version of the PMIP6 draft. Please review and let us know any comments you have. Any nits, technical issues, editorial ..please let us know and we will fix them right away. We want to go last call, asap. Please review and comment. Regards Sri > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, September 05, 2007 11:20 PM > To: i-d-announce@ietf.org > Cc: netlmm@ietf.org > Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Network-based Localized > Mobility Management Working Group of the IETF. > > > Title : Proxy Mobile IPv6 > Author(s) : S. Gundavelli, et al. > Filename : draft-ietf-netlmm-proxymip6-03.txt > Pages : 55 > Date : 2007-09-06 > > This specification describes a network-based mobility management > protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 > [RFC-3775]. This protocol enables mobility support to a host without > requiring its participation in any mobility related signaling. The > design principle in the case of network-based mobility management > protocol relies on the network being in control of the mobility > management. The mobility entities in the network are responsible for > tracking the movements of the host and initiating the required > mobility signaling on its behalf. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-ietf-netlmm-proxymip6-03.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-ietf-netlmm-proxymip6-03.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. > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 04:17:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITCYa-0005ll-AF; Thu, 06 Sep 2007 04:17:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITCYZ-0005lg-3b for netlmm@ietf.org; Thu, 06 Sep 2007 04:17:43 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITCYY-000218-Oy for netlmm@ietf.org; Thu, 06 Sep 2007 04:17:43 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 97645212C63; Thu, 6 Sep 2007 11:17:40 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 541DD212C59; Thu, 6 Sep 2007 11:17:40 +0300 (EEST) Message-ID: <46DFB7A4.9010209@nomadiclab.com> Date: Thu, 06 Sep 2007 11:17:40 +0300 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13) Gecko/20070824 Thunderbird/1.5.0.13 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: NetLMM Mailing List Subject: [netlmm] Remaining Open Issues X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, thanks for revising the P-MIPv6 specification. There are a few open issues left in our tracker [1]. In order to help folks form an opinion on whether those issues can be considered resolved now, may I ask you to send a brief statement, per open issue, on how the issue got addressed by the revised specification? I believe this would be helpful for everyone. Thank you, - Christian [1] http://www3.tools.ietf.org/wg/netlmm/trac/report/1/ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 05:01:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITDEb-0008I7-9R; Thu, 06 Sep 2007 05:01:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITDEa-0008I2-GX for netlmm@ietf.org; Thu, 06 Sep 2007 05:01:08 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITDEa-00031G-0Z for netlmm@ietf.org; Thu, 06 Sep 2007 05:01:08 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1189069266!6885851!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29121 invoked from network); 6 Sep 2007 09:01:06 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 6 Sep 2007 09:01:06 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l869157k000054 for ; Thu, 6 Sep 2007 02:01:05 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l86915fn018112 for ; Thu, 6 Sep 2007 04:01:05 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l86914E6017925 for ; Thu, 6 Sep 2007 04:01:04 -0500 (CDT) Message-ID: <46DFC1C7.9060103@gmail.com> Date: Thu, 06 Sep 2007 11:00:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: netlmm Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-0, 05/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [netlmm] timestamp vs seqno redux X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I've recently became aware that much nonsense discussion is happening around the timestamp vs seqno. People keep saying that seqno method is a possible alternative to timestamp but at the same time they mandate in the document the timestamp method. This is complete nonsense. I don't want the timestamp method to be mandatory. Anybody else wants the timestamp method to be a mandatory method? Anybody else wants the timestamp method to be an alternative method? Alex PS: mandatory excerpts: "This document _requires_ the use of Timestamp Option" "An implementation MUST support Timestamp option." ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 05:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITDOH-0001SN-Hb; Thu, 06 Sep 2007 05:11:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITDOG-0001S7-4C for netlmm@ietf.org; Thu, 06 Sep 2007 05:11:08 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITDOF-0003Cy-G9 for netlmm@ietf.org; Thu, 06 Sep 2007 05:11:08 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id EAC332800035C; Thu, 6 Sep 2007 11:11:10 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKK9Fya4RHwa; Thu, 6 Sep 2007 11:11:10 +0200 (CEST) Received: by smtp0.netlab.nec.de (Postfix, from userid 1001) id D7C4A280037E2; Thu, 6 Sep 2007 11:11:10 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on atlas1.office X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7 Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3A7E02800035C; Thu, 6 Sep 2007 11:10:55 +0200 (CEST) Received: from [127.0.0.1] ([10.1.1.152]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Sep 2007 11:10:50 +0200 Message-ID: <46DFC41B.6010503@netlab.nec.de> Date: Thu, 06 Sep 2007 11:10:51 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jong-Hyouk Lee Subject: Re: [netlmm] RO establishment time in draft-abeille-netlmm-proxymip6ro-00. References: In-Reply-To: X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Sep 2007 09:10:51.0003 (UTC) FILETIME=[D210D4B0:01C7F065] X-Sanitizer: This message has been sanitized! X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: abeille@netlab.nec.de, netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Jong-Hyouk, thanks for your comments. Please see below for my reply. Jong-Hyouk Lee wrote: > Dear colleague. > > In draft-abeille-netlmm-proxymip6ro-00, the route optimization (RO) > procedure is defined and some scenarios are well described. However, > there are ambiguous things, the actual RO establishment time and the actions > in LMA after sending RO Report Ack. > > Well, for simplicity, take Fig. 2 in the document. When the packets of MN1 > are sent directly via the RO path between MAG1 and MAG2? After receiving RO > Setup Ack at MAG1? MAG1 does not receive RO Setup Ack, but the RO Setup message. MAG2 initiates the RO Setup procedure after the RO Init has been received. At that time, MAG2 can have all the information to establish as well as to activate RO states and start forwarding traffic. However, we think it might be beneficial to wait for feedback about a result from MAG1 before activating states. After MAG1 receives the RO Setup message, it creates and activates RO states. This results in forwarding packets from MN1-->MN2 through the route optimized path. After MAG2 received the RO Setup Ack, it activates the states in case the result for RO setup in MAG1 was successful. Optionally, we described the Early State Activation (ESA) policy in Appendix B, which allows MAG2 (referring to Figure 2) activating RO states already after RO Init has been received, without waiting for MAG1's feedback. In case the ESA policy is applied, MAG2 forwards packets towards MAG1 through the route optimized path immediately. A further issue with this is that MAG1 must support terminating the tunnel from MAG2 and forward the packet to MN1 without having a state yet (as there might be a race condition between the RO Setup message and the first data packet being tunneled from MAG2-->Mag1). Hence, this mechanism is possible, but implies some drawbacks. That's why it's only optional. > Also, after receiving RO Report at LMA1, it sends RO > Report Ack. After that, what is the next actions at LMA? > The LMA knows about the result of route optimization setup between MAG1 and MAG2. As in this case the one and only LMA1 is the RO controller, it waits until states need to be updated, such as in case of a handover of one or even both MNs. Hope this clarified you questions a bit. Best regards, marco > Please, make clear. > > Cheers. > > > ------------------------------------------------------------------------ > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 14:18:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITLvk-0004Ps-Pf; Thu, 06 Sep 2007 14:18:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITLvj-0004Pi-3a for netlmm@ietf.org; Thu, 06 Sep 2007 14:18:15 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITLvi-0002GQ-5Q for netlmm@ietf.org; Thu, 06 Sep 2007 14:18:14 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l86IIBY0012227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Sep 2007 11:18:12 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l86IIAQ7024916; Thu, 6 Sep 2007 11:18:10 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Sep 2007 11:18:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Remaining Open Issues Date: Thu, 6 Sep 2007 11:18:08 -0700 Message-ID: In-Reply-To: <46DFB7A4.9010209@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Remaining Open Issues Thread-Index: AcfwXuWiMF/LpBr3SvmCu4GXspP7vgAUvFgA References: <46DFB7A4.9010209@nomadiclab.com> From: "Narayanan, Vidya" To: "Christian Vogt" , "Sri Gundavelli" X-OriginalArrivalTime: 06 Sep 2007 18:18:08.0087 (UTC) FILETIME=[467E3670:01C7F0B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: NetLMM Mailing List X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Thanks for raising this, Christian.=20 Authors, thanks for the revised draft. It would be very helpful for reviewers to see a change log and the resolution to the open issues that were addressed by this draft. Please post that to the mailing list. =20 Thanks, Vidya > -----Original Message----- > From: Christian Vogt [mailto:christian.vogt@nomadiclab.com]=20 > Sent: Thursday, September 06, 2007 1:18 AM > To: Sri Gundavelli > Cc: NetLMM Mailing List > Subject: [netlmm] Remaining Open Issues >=20 > Sri, >=20 > thanks for revising the P-MIPv6 specification. There are a=20 > few open issues left in our tracker [1]. In order to help=20 > folks form an opinion on whether those issues can be=20 > considered resolved now, may I ask you to send a brief=20 > statement, per open issue, on how the issue got addressed by=20 > the revised specification? >=20 > I believe this would be helpful for everyone. >=20 > Thank you, > - Christian >=20 > [1] http://www3.tools.ietf.org/wg/netlmm/trac/report/1/ >=20 >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 15:58:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNUS-0001nq-A7; Thu, 06 Sep 2007 15:58:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNUR-0001cj-93 for netlmm@ietf.org; Thu, 06 Sep 2007 15:58:11 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITNUQ-0004pO-Lg for netlmm@ietf.org; Thu, 06 Sep 2007 15:58:11 -0400 X-IronPort-AV: E=Sophos;i="4.20,216,1186383600"; d="scan'208";a="174722244" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 06 Sep 2007 12:58:10 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l86JwA8w018556; Thu, 6 Sep 2007 12:58:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l86Jw4D7014776; Thu, 6 Sep 2007 19:58:09 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 12:58:07 -0700 Received: from sgundavewxp ([128.107.163.55]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 12:58:07 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" , "'netlmm'" References: <46DFC1C7.9060103@gmail.com> Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 6 Sep 2007 12:58:06 -0700 Message-ID: <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46DFC1C7.9060103@gmail.com> Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pw X-OriginalArrivalTime: 06 Sep 2007 19:58:07.0020 (UTC) FILETIME=[3E22BEC0:01C7F0C0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3246; t=1189108690; x=1189972690; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20timestamp=20vs=20seqno=20redux |Sender:=20; bh=IseN/9nbM6+XbDkKNtmgFn6YBdNIoQCoHXKOi/kJjLc=; b=Pcw4tJ6wo/ii2AUlE1qXsSXq1wJiBe2haroSGO3uhIPOXVmYE4jkczs4fPB1au/Cgt3bqz59 BttzR+Qv038UekRWxx7W1GIfzk7ciPJbOVJGKX1zKKqv6cNdrOtzrTdY; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Please comment on this issue raised by Alex about mandating Timestamp option. Alex is right, when we discussed this issue, the conclusion was to use Timestamp based approach, but we did not discuss if that was supposed to be mandatory to implement. Now, w.r.t the issue, what are we mandating ? - The ability for the LMA to generate a Timestamp and return the timestamp option. The timestamp in relation to a specific reference point. IMO, this is one system call on most OS's and a delta addition if the timestamp generated is elapsed time past some other reference point. We are talking about 5 to 8 lines of code. I will be happy to publish this code for all standard OS's. - We are NOT mandating the nodes in the domain to sync up to a clock source. How does it impact, if some deployment wants to use Seq Number approach ? - No impact. The option need to be supported. Implies those 10 lines of extra code. Why this should be mandatory ? Base draft does not support Context Transfers. Given that the draft will be incomplete, if we dont mandate the support. By mandating the support, the LMA can always return its timestamp and the MAG can use that timestamp and register. This need to be done just once whenever the LMA/MAG clocks are out of sync and just for one registration. One extra round trip for the 1st registration between LMA/MAG pair. But, if the LMA falls back to the seq number based approach and if there are no context transfers, there is always an extra round trip for each MN registration (at handoff). So, I prefer the mandatory approach, its more efficient. But, as I had it in the initial suggested text, I'm ok not mandating this and defining an error code "Timestamp option not supported". Please comment. I want to close this issue. Implementation MUST support Timestamp option: [Yes/No] Thanks Sri > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, September 06, 2007 2:01 AM > To: netlmm > Subject: [netlmm] timestamp vs seqno redux > > I've recently became aware that much nonsense discussion is happening > around the timestamp vs seqno. People keep saying that seqno > method is > a possible alternative to timestamp but at the same time they mandate > in the document the timestamp method. This is complete nonsense. > > I don't want the timestamp method to be mandatory. > > Anybody else wants the timestamp method to be a mandatory method? > > Anybody else wants the timestamp method to be an alternative method? > > Alex > PS: mandatory excerpts: > "This document _requires_ the use of Timestamp Option" > "An implementation MUST support Timestamp option." > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 15:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNUU-0001ws-Hu; Thu, 06 Sep 2007 15:58:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNUS-0001mg-2Y for netlmm@ietf.org; Thu, 06 Sep 2007 15:58:12 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITNUR-0004pS-Jn for netlmm@ietf.org; Thu, 06 Sep 2007 15:58:11 -0400 X-IronPort-AV: E=Sophos;i="4.20,216,1186383600"; d="scan'208";a="213455594" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Sep 2007 12:58:10 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l86JwA3c003746; Thu, 6 Sep 2007 12:58:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l86Jw4D9014776; Thu, 6 Sep 2007 19:58:10 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 12:58:07 -0700 Received: from sgundavewxp ([128.107.163.55]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 12:58:06 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" , "'Christian Vogt'" References: <46DFB7A4.9010209@nomadiclab.com> Subject: RE: [netlmm] Remaining Open Issues Date: Thu, 6 Sep 2007 12:58:06 -0700 Message-ID: <01db01c7f0c0$3e106f40$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfwXuWiMF/LpBr3SvmCu4GXspP7vgAUvFgAAAOTpTA= X-OriginalArrivalTime: 06 Sep 2007 19:58:06.0895 (UTC) FILETIME=[3E0FABF0:01C7F0C0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1622; t=1189108690; x=1189972690; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Remaining=20Open=20Issues |Sender:=20; bh=8pC2ARHihqL5y5dnh3Oi5t1x46MGEWO8sFKr1GJZV5A=; b=1m3vsUjzVBg+MZ3j9G8TmrKby0zUvJe7hkLBPP7LpVuwU0tiUziQ3fTa2U6rwa19gtlnbX12 arrrypkzCX6uNQmzZ8Nkes+4QWy+xcPU1wQVkYqViNxqp3R1Mp//H+JH; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 'NetLMM Mailing List' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Christian/Vidya, Sure we will publish the log, on how we addressed each of the issues. Thanks Sri > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Thursday, September 06, 2007 11:18 AM > To: Christian Vogt; Sri Gundavelli > Cc: NetLMM Mailing List > Subject: RE: [netlmm] Remaining Open Issues > > Thanks for raising this, Christian. > > Authors, thanks for the revised draft. It would be very helpful for > reviewers to see a change log and the resolution to the open > issues that > were addressed by this draft. Please post that to the > mailing list. > > Thanks, > Vidya > > > -----Original Message----- > > From: Christian Vogt [mailto:christian.vogt@nomadiclab.com] > > Sent: Thursday, September 06, 2007 1:18 AM > > To: Sri Gundavelli > > Cc: NetLMM Mailing List > > Subject: [netlmm] Remaining Open Issues > > > > Sri, > > > > thanks for revising the P-MIPv6 specification. There are a > > few open issues left in our tracker [1]. In order to help > > folks form an opinion on whether those issues can be > > considered resolved now, may I ask you to send a brief > > statement, per open issue, on how the issue got addressed by > > the revised specification? > > > > I believe this would be helpful for everyone. > > > > Thank you, > > - Christian > > > > [1] http://www3.tools.ietf.org/wg/netlmm/trac/report/1/ > > > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 16:07:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNd9-0004YH-UJ; Thu, 06 Sep 2007 16:07:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITNd8-0004Y9-QT for netlmm@ietf.org; Thu, 06 Sep 2007 16:07:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITNd7-00014B-IU for netlmm@ietf.org; Thu, 06 Sep 2007 16:07:10 -0400 X-IronPort-AV: E=Sophos;i="4.20,216,1186383600"; d="scan'208";a="174724866" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 06 Sep 2007 13:07:09 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l86K79oG018846; Thu, 6 Sep 2007 13:07:09 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l86K78D1023149; Thu, 6 Sep 2007 20:07:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 13:07:08 -0700 Received: from sgundavewxp ([128.107.163.55]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 13:07:08 -0700 From: "Sri Gundavelli" To: "'Alper Yegin'" , References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> Subject: RE: [netlmm] Issue: Auth Option support Date: Thu, 6 Sep 2007 13:07:08 -0700 Message-ID: <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> Thread-Index: AcfYwQ6voKS1c0EASayvJIq8ADkrlQADOAAgBfytoKA= X-OriginalArrivalTime: 06 Sep 2007 20:07:08.0472 (UTC) FILETIME=[80DDC380:01C7F0C1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2855; t=1189109229; x=1189973229; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Auth=20Option=20support |Sender:=20; bh=m5Ki6RP/jZbd1rDnyE7BJCMN1S0/3mXEWSUSGKQ/rwU=; b=M9+MOX+Z4maSYFGoDiWE4uBG9YIDtyG2SunKP4YZo4rV6g/HmHwWIk1b4obcbGhJlS22LFqi TtrTkdTe4cPAKpuc14JSnk9zAgnYrn3wFPuONdaE7Wukkg4/ibnDPW8h; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I want some comments on this issue raised by Alper. Also, if I interpret Sec 5.1 [3775], the IPSec is being mandated, only the use of IPsec ESP is optional. -------- 5.1. Binding Updates to Home Agents The mobile node and the home agent MUST use an IPsec security association to protect the integrity and authenticity of the Binding Updates and Acknowledgements. Both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [6] header in transport mode and MUST use a non-NULL payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection. Note that Authentication Header (AH) [5] is also possible but for brevity not discussed in this specification. ------- I'm confused, should the draft say "Both LMA and MAG MUST implement IPsec" and "all the signaling messages SHOULD be protected using IPSec". Will this ok, when reviewed by the security folks ? or mandate IPsec for this specification and let other draft relax this in the presence of an alternative approach ? Please comment. Sri > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Tuesday, August 07, 2007 1:41 AM > To: 'Sri Gundavelli'; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Auth Option support > > > The issue was related to the use of MUST clause in specifying > > the IPSec requirement for Proxy Mobile IPv6 protocol. Alper > > was suggesting that we relax that requirement and potentially > > leave a room for Auth Option support in future. > > Actually, I didn't mean it specifically for Auth Option. It > can be anything. > Given that the security is handled by a separate protocol, > why lock it down > to "IPsec", when some other protocol (Auth Option being one > example) cannot > be used. > > > But, as most people agreed and as supported by Jari, this can > > My understanding was the opposite, especially about Jari's statement. > > > always be changed in future when the support for new security > > mechanisms such as Auth Option are defined for Proxy Mobile IPv6 > > and that specific document can always modify this requirement. > > So, no changes will be made to the document on this issue. > > What if Auth Option is good enough as written? > What if a document in another SDO defines the alternative security > mechanism? > > For the type of interop we are seeking in IETF, "MUST > implement" is good > enough. "MUST use" is not necessary. > > Alper > > > > > > > > > > > Regards > > Sri > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 17:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITOyI-0003Oj-Pg; Thu, 06 Sep 2007 17:33:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITOyG-0003IB-3m for netlmm@ietf.org; Thu, 06 Sep 2007 17:33:04 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITOyE-0004Nw-O9 for netlmm@ietf.org; Thu, 06 Sep 2007 17:33:04 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1ITOxf1WA2-0007Wz; Thu, 06 Sep 2007 17:32:38 -0400 From: "Alper Yegin" To: "'Sri Gundavelli'" , "'Alexandru Petrescu'" , "'Christian Vogt'" Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic Date: Fri, 7 Sep 2007 00:32:20 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfvwmWQSv2KqyX8Sya+9FJbZX65EAANg6IgAABwbiAANMrM8A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <00ee01c7effb$eafe42b0$d4f6200a@amer.cisco.com> Message-Id: <0MKpCa-1ITOxf1WA2-0007Wz@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19OmkRCxk7qz07M4q0ErZssE6s1gGQz4FLBgeN th5StQhgUlwrU4nNrckDOumdCw+RN/MU1VhL27AiyRHUtceHoB QuctqzBW5Tpkxd7zGgw9g== X-Spam-Score: -0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: 'Kilian Weniger' , netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Thanks Sri, that makes sense to me. Alper > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Wednesday, September 05, 2007 11:33 PM > To: 'Alper Yegin'; 'Alexandru Petrescu'; 'Christian Vogt' > Cc: 'Kilian Weniger'; netlmm@ietf.org; 'Julien Laganier' > Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic > > Hi Alper, > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Wednesday, September 05, 2007 1:14 PM > > To: 'Alexandru Petrescu'; 'Christian Vogt' > > Cc: 'Kilian Weniger'; netlmm@ietf.org; 'Julien Laganier' > > Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic > > > > Hello, > > > > > Christian Vogt wrote: > > > >> I'm not sure what example you have in mind... but if we > > consider some > > > average > > > >> wifi link-layer handovers to be around 500ms this is > > clearly below the > > > 1s > > > >> I've noticed as error between time keeping of different > > systems. Most > > > >> performant wifi handovers I've seen are around 5ms. > > > > > > > > Alex, > > > > > > > > I fully agree with you that we should not focus on link > > layer handover > > > delays > > > > that are prevalent today, but that we should support much > > lower ones. > > > > > > > > But at least within a single P-MIPv6 domain, it should > > well be possible > > > to > > > > reduce synchronization errors to below 1 ms because the > > round-trip times > > > are > > > > then sufficiently small. > > > > There seems to be an assumption here with respect to the > > distance between > > the MAG and LMA. Considering how PMIP6 will be deployed with various > > architectures (e.g., WiMAX), I don't think we can make this > > assumption. > > > > > > > I agree, provided every MAG and the LMA within that domain > > use the same > > > time synchronization mechanism. > > > > > > I think, not sure, that when you say '1ms' you already > > assume that they > > > use NTP, because NTP is known to claim that '1ms' accuracy. > > > > > > > As I had mentioned in an earlier email, roaming across > > P-MIPv6 domains > > > requires > > > > global clock synchronization, where errors might be higher. This > > > requires > > > > additional thought on how to synchronize clocks. > > > > Are we talking about synchronizing the clocks among all MAGs > > and LMAs that > > are interacting with each other? Each MAG and LMA may belong > > to a different > > operator, located at a different corner of the Internet. Can > > NTP practically > > deal with this? Just asking... > > > > It is important to highlight the fact that we need this entire > synchronization logic to avoid one scenario, where the LMA > ends up processing a PBU that was sent by pMAG and the LMA > received that much later due to network out of order deliverly. > In my mind, this is a special case. Now the solutions: > > The spec supports both Sequence Number based and Timestamp based > approaches. If a given architecture has some kind of interface > between MAG to MAG for context transfers, which I assume it is > true for WiMAX as well, then the sequence number based scheme will > just fine. > > Now, for completeness, in the absence of a context transfer > protocol, the base spec supports a Timestamp based approach. It > expects the LMA's and MAG's to sync to a common clock source. If > a deployment does not enable NTP kind of protocols and if the > LMA receives a packet with PBU from a MAG with a invalid timestamp, > the LMA can return its own timestamp and the MAG can use the same > in the requests to avoid this special race condition. So, it should > not be a concern that the LMA and MAG are in different domains and > syncing is an issue. Also, MIP4 uses timestamp based logic and > there are deployments based on that. > > Regards > Sri > > > > > > > > > > > > > > > > > Alper > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 17:59:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPOB-0005SN-Cl; Thu, 06 Sep 2007 17:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPOA-0005SI-Ms for netlmm@ietf.org; Thu, 06 Sep 2007 17:59:50 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ITPO9-00053z-Hh for netlmm@ietf.org; Thu, 06 Sep 2007 17:59:50 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1189115988!19027982!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 11486 invoked from network); 6 Sep 2007 21:59:48 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-2.tower-119.messagelabs.com with SMTP; 6 Sep 2007 21:59:48 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l86LxmYp027863; Thu, 6 Sep 2007 14:59:48 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l86LxlrM015068; Thu, 6 Sep 2007 16:59:47 -0500 (CDT) Received: from [127.0.0.1] ([10.129.42.196]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l86Lxi6S015052; Thu, 6 Sep 2007 16:59:45 -0500 (CDT) Message-ID: <46E0784F.2090904@gmail.com> Date: Thu, 06 Sep 2007 23:59:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [netlmm] timestamp vs seqno redux References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> In-Reply-To: <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri Gundavelli wrote: > Please comment on this issue raised by Alex about mandating Timestamp > option. Alex is right, when we discussed this issue, the conclusion > was to use Timestamp based approach, but we did not discuss if that > was supposed to be mandatory to implement. > > Now, w.r.t the issue, what are we mandating ? > > - The ability for the LMA to generate a Timestamp and return the > timestamp option. The timestamp in relation to a specific reference > point. IMO, this is one system call on most OS's and a delta addition > if the timestamp generated is elapsed time past some other reference > point. We are talking about 5 to 8 lines of code. I will be happy to > publish this code for all standard OS's. I agree it's not much code to call an API to obtain current time. What is more is to encode the message format of that time into the Mobile IPv6 implementation. > - We are NOT mandating the nodes in the domain to sync up to a clock > source. Thanks, that is good. > How does it impact, if some deployment wants to use Seq Number > approach ? > > - No impact. The option need to be supported. Implies those 10 lines > of extra code. > > > Why this should be mandatory ? > > Base draft does not support Context Transfers. Ok. > Given that the draft will be incomplete, if we dont mandate the > support. I don't think it will be incomplete. The spec can very easily say that in order for the P-BUs to be correctly ordered at the HA then the HA should provide the correct seqno to the MAG, as part of the 'profile' related to MN, or as part of some other assumed and non-specified mechanism. When MAG sends a P-BU to MAG it will just send the seqno it received in the unspecified mechanism, and increment it plus one. Or maybe as part of an enhanced DHCP procedure, or AAA, or link-layer authentication procedure. The LMA is supposed to provide MN's home prefix already to the MAG, thus it can provide the right seqno to it as well. > By mandating the support, the LMA can always return its timestamp and > the MAG can use that timestamp and register. This need to be done > just once whenever the LMA/MAG clocks are out of sync and just for > one registration. One extra round trip for the 1st registration > between LMA/MAG pair. But this can be achieved with the seqnos as well, not necessarily to send the timestamp. > But, if the LMA falls back to the seq number based approach and if > there are no context transfers, there is always an extra round trip > for each MN registration (at handoff). No, not always an extra round trip necessary. (For our audience: in private I've discussed with Ahmad and Sri at least three possible ways to sync these seqnos and two of them assumed extra round trips.) I think that if the right seqno is provided by LMA to MAG as part of that 'profile' then MAG can simply increment it and send the proper seqno to LMA. This involves no additional roundtrip. > So, I prefer the mandatory approach, its more efficient. But, as I > had it in the initial suggested text, I'm ok not mandating this and > defining an error code "Timestamp option not supported". I'm happy you already agreed not to mandate timestamp, thanks for that. For error "Timestamp option not supported" then one would have to define "seqno option not supported" too, right? > Please comment. I want to close this issue. > > > Implementation MUST support Timestamp option: [Yes/No] No, it's not necessary to say that implementation MUST support timestamp option. An alternative is just an alternative. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 18:05:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPTa-0002tw-CE; Thu, 06 Sep 2007 18:05:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPTY-0002rP-VY for netlmm@ietf.org; Thu, 06 Sep 2007 18:05:25 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITPTY-0000rK-88 for netlmm@ietf.org; Thu, 06 Sep 2007 18:05:24 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1189116322!3746654!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25613 invoked from network); 6 Sep 2007 22:05:22 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-153.messagelabs.com with SMTP; 6 Sep 2007 22:05:22 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l86M5MJt000857; Thu, 6 Sep 2007 15:05:22 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l86M5LLV027960; Thu, 6 Sep 2007 17:05:22 -0500 (CDT) Received: from [127.0.0.1] ([10.129.42.196]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l86M5Jef027895; Thu, 6 Sep 2007 17:05:20 -0500 (CDT) Message-ID: <46E0799E.10207@gmail.com> Date: Fri, 07 Sep 2007 00:05:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [netlmm] Issue: Auth Option support References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> In-Reply-To: <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, IMHO, I have several comments on the authopt original support, and I've already posted on the mip6 list, not much follow up yet. authopt draft is currently incompletely specified (eg what happens to Binding Error authentication?). Basically, I would like to not see authopt being a mandatory authentication mechanism for P-MIPv6. At least not yet - it should evolve more. I would personally say that IPsec support for LMA and MAG is understood ok for the moment and could be suggested as a default for the P-MIPv6 spec. (I perfectly understand the deployments need and use AAA, and AAA is performant and should be integrated with MIP6 and P-MIP6 - but it's not yet clear how). IMHO, Alex Sri Gundavelli wrote: > I want some comments on this issue raised by Alper. > > > Also, if I interpret Sec 5.1 [3775], the IPSec is being > mandated, only the use of IPsec ESP is optional. > > -------- > 5.1. Binding Updates to Home Agents > > The mobile node and the home agent MUST use an IPsec security > association to protect the integrity and authenticity of the Binding > Updates and Acknowledgements. Both the mobile nodes and the home > agents MUST support and SHOULD use the Encapsulating Security Payload > (ESP) [6] header in transport mode and MUST use a non-NULL payload > authentication algorithm to provide data origin authentication, > connectionless integrity and optional anti-replay protection. Note > that Authentication Header (AH) [5] is also possible but for brevity > not discussed in this specification. > ------- > > > I'm confused, should the draft say > > "Both LMA and MAG MUST implement IPsec" and > "all the signaling messages SHOULD be protected using IPSec". > > Will this ok, when reviewed by the security folks ? > > or mandate IPsec for this specification and let other draft > relax this in the presence of an alternative approach ? > > Please comment. > > > Sri > > > > > > > > > > >> -----Original Message----- >> From: Alper Yegin [mailto:alper.yegin@yegin.org] >> Sent: Tuesday, August 07, 2007 1:41 AM >> To: 'Sri Gundavelli'; netlmm@ietf.org >> Subject: RE: [netlmm] Issue: Auth Option support >> >>> The issue was related to the use of MUST clause in specifying >>> the IPSec requirement for Proxy Mobile IPv6 protocol. Alper >>> was suggesting that we relax that requirement and potentially >>> leave a room for Auth Option support in future. >> Actually, I didn't mean it specifically for Auth Option. It >> can be anything. >> Given that the security is handled by a separate protocol, >> why lock it down >> to "IPsec", when some other protocol (Auth Option being one >> example) cannot >> be used. >> >>> But, as most people agreed and as supported by Jari, this can >> My understanding was the opposite, especially about Jari's statement. >> >>> always be changed in future when the support for new security >>> mechanisms such as Auth Option are defined for Proxy Mobile IPv6 >>> and that specific document can always modify this requirement. >>> So, no changes will be made to the document on this issue. >> What if Auth Option is good enough as written? >> What if a document in another SDO defines the alternative security >> mechanism? >> >> For the type of interop we are seeking in IETF, "MUST >> implement" is good >> enough. "MUST use" is not necessary. >> >> Alper >> >> >> >> >> >>> >>> Regards >>> Sri >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 06 18:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPzS-00031V-M6; Thu, 06 Sep 2007 18:38:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITPzR-00030s-QV for netlmm@ietf.org; Thu, 06 Sep 2007 18:38:21 -0400 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITPzR-0002Fs-3b for netlmm@ietf.org; Thu, 06 Sep 2007 18:38:21 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1ITPzK2Wsh-0008S4; Thu, 06 Sep 2007 18:38:19 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" , "'Sri Gundavelli'" Subject: RE: [netlmm] Issue: Auth Option support Date: Fri, 7 Sep 2007 01:38:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfw0gYhSyWULcrwRxu6tOJj3HIQ1wAA7ZDg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46E0799E.10207@gmail.com> Message-Id: <0MKp8S-1ITPzK2Wsh-0008S4@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/yRSHAF9GwEGIjHSamIaBm8Oemogb7Rel3UUK cL/dOyfnO4nJLcCyNd5YK8BNs17o6sXDpUAWPwrWHRPdSgYt1q ZirgMwgCCGNn66V3Jka6w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, Sri, - The highlight of my suggestion is not to mandate auth option, but to simply relax the current language that states "must use IPsec". - Auth option is an example of another security mechanism that we shall not prevent from being used. - "default" does not mean much. We shall speak in terms of "must/should/may implement", and "must/should/may use." - Leaving that to other specs, and the "must use IPsec" language in RFC 3775 despite RFC4285 do not make sense to me. My recommendation is to state "should implement IPsec, may use IPsec" in the PMIP6 spec. Alper > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, September 07, 2007 1:05 AM > To: Sri Gundavelli > Cc: 'Alper Yegin'; netlmm@ietf.org > Subject: Re: [netlmm] Issue: Auth Option support > > Sri, IMHO, I have several comments on the authopt original support, and > I've already posted on the mip6 list, not much follow up yet. authopt > draft is currently incompletely specified (eg what happens to Binding > Error authentication?). > > Basically, I would like to not see authopt being a mandatory > authentication mechanism for P-MIPv6. At least not yet - it should > evolve more. > > I would personally say that IPsec support for LMA and MAG is understood > ok for the moment and could be suggested as a default for the P-MIPv6 > spec. > > (I perfectly understand the deployments need and use AAA, and AAA is > performant and should be integrated with MIP6 and P-MIP6 - but it's not > yet clear how). > > IMHO, > > Alex > > Sri Gundavelli wrote: > > I want some comments on this issue raised by Alper. > > > > > > Also, if I interpret Sec 5.1 [3775], the IPSec is being > > mandated, only the use of IPsec ESP is optional. > > > > -------- > > 5.1. Binding Updates to Home Agents > > > > The mobile node and the home agent MUST use an IPsec security > > association to protect the integrity and authenticity of the Binding > > Updates and Acknowledgements. Both the mobile nodes and the home > > agents MUST support and SHOULD use the Encapsulating Security Payload > > (ESP) [6] header in transport mode and MUST use a non-NULL payload > > authentication algorithm to provide data origin authentication, > > connectionless integrity and optional anti-replay protection. Note > > that Authentication Header (AH) [5] is also possible but for brevity > > not discussed in this specification. > > ------- > > > > > > I'm confused, should the draft say > > > > "Both LMA and MAG MUST implement IPsec" and > > "all the signaling messages SHOULD be protected using IPSec". > > > > Will this ok, when reviewed by the security folks ? > > > > or mandate IPsec for this specification and let other draft > > relax this in the presence of an alternative approach ? > > > > Please comment. > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >> Sent: Tuesday, August 07, 2007 1:41 AM > >> To: 'Sri Gundavelli'; netlmm@ietf.org > >> Subject: RE: [netlmm] Issue: Auth Option support > >> > >>> The issue was related to the use of MUST clause in specifying > >>> the IPSec requirement for Proxy Mobile IPv6 protocol. Alper > >>> was suggesting that we relax that requirement and potentially > >>> leave a room for Auth Option support in future. > >> Actually, I didn't mean it specifically for Auth Option. It > >> can be anything. > >> Given that the security is handled by a separate protocol, > >> why lock it down > >> to "IPsec", when some other protocol (Auth Option being one > >> example) cannot > >> be used. > >> > >>> But, as most people agreed and as supported by Jari, this can > >> My understanding was the opposite, especially about Jari's statement. > >> > >>> always be changed in future when the support for new security > >>> mechanisms such as Auth Option are defined for Proxy Mobile IPv6 > >>> and that specific document can always modify this requirement. > >>> So, no changes will be made to the document on this issue. > >> What if Auth Option is good enough as written? > >> What if a document in another SDO defines the alternative security > >> mechanism? > >> > >> For the type of interop we are seeking in IETF, "MUST > >> implement" is good > >> enough. "MUST use" is not necessary. > >> > >> Alper > >> > >> > >> > >> > >> > >>> > >>> Regards > >>> Sri > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 05:03:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITZkB-0003dd-RR; Fri, 07 Sep 2007 05:03:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITZkA-0003dY-EQ for netlmm@ietf.org; Fri, 07 Sep 2007 05:03:14 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ITZk9-0003H0-4q for netlmm@ietf.org; Fri, 07 Sep 2007 05:03:14 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1189155791!5445014!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26155 invoked from network); 7 Sep 2007 09:03:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 7 Sep 2007 09:03:11 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l87939aK000999; Fri, 7 Sep 2007 02:03:11 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l87939gr001537; Fri, 7 Sep 2007 04:03:09 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l87937s0001459; Fri, 7 Sep 2007 04:03:07 -0500 (CDT) Message-ID: <46E113C5.8080908@gmail.com> Date: Fri, 07 Sep 2007 11:03:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] Issue: Auth Option support References: <0MKp8S-1ITPzK2Wsh-0008S4@mrelay.perfora.net> In-Reply-To: <0MKp8S-1ITPzK2Wsh-0008S4@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Hi Alex, Sri, > > - The highlight of my suggestion is not to mandate auth option, but > to simply relax the current language that states "must use IPsec". > > - Auth option is an example of another security mechanism that we > shall not prevent from being used. Auth option is now little appropriate for recommendation to implementation of a MIP6 stack. As I said already, authopt is silent about other MIP6 messages than BU/BAck. And one surely doesn't want BU/BAck auth'ed with authopt and BErr with IPsec. It will probably evolve more than its current state. When would you like to discuss technically authopt document? BEfore we recommend it in PMIP or after? > - "default" does not mean much. We shall speak in terms of > "must/should/may implement", and "must/should/may use." I agree, it's more understandable. > - Leaving that to other specs, and the "must use IPsec" language in > RFC 3775 despite RFC4285 do not make sense to me. Sorry, it does make a lot of sense to me. 3775 is stds track. Authopt is informational. The new authopt-bis draft is apparently intended as informational as well, correct me if I'm wrong. It's normal for a stds track document to recommend another stds track document and be silent about the informationals. > My recommendation is to state "should implement IPsec, may use IPsec" > in the PMIP6 spec. Should and should is ok with me by now (not should and may). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 05:04:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITZl2-00041h-IH; Fri, 07 Sep 2007 05:04:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITZl0-0003zu-PI for netlmm@ietf.org; Fri, 07 Sep 2007 05:04:06 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITZkz-0007X0-9P for netlmm@ietf.org; Fri, 07 Sep 2007 05:04:06 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8793Se5013492; Fri, 7 Sep 2007 11:03:28 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 7 Sep 2007 11:04:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 11:03:49 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A5013999EA@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABfNwGA= References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" X-OriginalArrivalTime: 07 Sep 2007 09:04:01.0392 (UTC) FILETIME=[0854E700:01C7F12E] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, I haven't had time to catch up yet with the new draft, so I apologize if = any of my comments below has already been addresed Sri> ... what are we mandating? The ability for the LMA to generate a = Timestamp and return the timestamp option ... I'm trying to understand the motivation for this mandate I understand the need in the LMA to identify the sequence of BUs in = order to avoid race conditions when more than one MAG can send a BU for = the same user The minimum requirement from LMA point of view is that the ID carried in = the BU represents a free-running counter that increases monotonically It follows that the requirement for the MAGs is to synchronize the = values used in the BU-ID Let me stress that these "minimum requirements" are only for = synchronization between MAGs, i.e. not including LMA Timestamps is a valid solution for filling in the ID when there's time = synchronization (with sufficient accuracy) between MAGs Let me stress that the precondition for using timestamps should only be = synchronization between MAGs, i.e. not including LMA By including LMA in the equation, it seems that we're trying to correct = deviations in the time synchronization of MAGs via PMIP That is, the LMA becomes some kind of synch Master. Honestly, I don't = think it is right to extend PMIP scope in such way Let me cite your answers to Alper (from another email): Sri> ... It is important to highlight the fact that we need this entire = synchronization logic to avoid one scenario, where the LMA ends up = processing a PBU that was sent by pMAG and the LMA received that much = later due to network out of order deliverly ... [FDJ] This problem statement seems wrong. Unordered delivery because of = nw congestion does not make any difference What matters is the relationship between the ID sent by the pMAG and the = one sent by the nMAG The only requirement that we can make is that pMAG and nMAG must = synchronize this ID There's no way the LMA can't tell in which order these 2 BUus were sent = if the IDs are not-synchronized Sri> ... If a deployment does not enable NTP kind of protocols and if = the LMA receives a packet with PBU from a MAG with a invalid timestamp, = the LMA can return its own timestamp and the MAG can use the same in the = requests to avoid this special race condition ... [FDJ] If the deployment does not enable NTP, all PBUs will have a wrong = ID. Or do you expect the MAG to synch to the same timebase as the LMA = when the LMA returns the timestamp option? Furthermore, I fail to understand the solution you propose: how can the = LMA declare that the ID (timestamp) is invalid? Use case: - pMAG send BU at 10 AM - nMAG sends BU at 11 AM - LMA receives BU from nMAG at 11:15 AM. Will it return timestamp to = nMAG, so that the BU can be resent? - LMA receives BU from pMAG at 11:30 AM. Will it retun timestamp to = pMAG, so that BU can be resent? Or maybe the proposal is that LMA will = decide that pMAG BU was sent earlier than nMAG BU and therefore discard = it. The latter makes sense but it means that the LMA has to assume that = pMAG and nMAG are in synch. And then we're back to the minimum = requirement In summary, in my opinion: 1- The LMA MAY be able to generate timestamps (but should not be = required to) 2- The LMA MAY know that the source used for the ID is a timestamp = (but should not be required to) 3- If the LMA is not timestamp aware, the MAG MAY use timestamps (but = should not be required to) 4- If the LMA is timestamp aware, the MAG MAY use timestamps (but = should not be required to) If any of the 4 statements would reduce the usability of PMIP in any = way, I would appreciate to have a more clear problem statement Thus: Implementation MUST support Timestamp option: No And I would even push it further: if the previous 4 statements can be = agreed to, then the logical conclusion is that timestamps can be left = out of the specification (at most an informative note would do) A couple of collateral comments: - I understand that CT (Context Transfer) is already acknowledged as = a valid alternative solution For some reason, CT is left out of scope. Fine for me, but I don't = think it's a fair consequence to mandate timestamps The fact that "context transfer is out of scope" doesn't equate to = "there is no context transfer" Is it the working assumption that a solution without CT is simpler = than a solution with CT? This would be a wrong assumption If we have to choose between specifying timestamps or specifying CT, = then I prefer the latter. It's clear that it will require more work but = it will be more useful - If a nMAG sends a BU for a given user without synchronization with = pMAG it may be useful to have the option to indicate it to the LMA In other words, I propose a flag "OOS ID" (Out of Synch ID) sent by = the MAG, so that the LMA can reset the sequencing algorithm for a given = MN - I have read in other emails that timestamps are already a proven = concept in MIP4 I fail to understand how this argument makes a difference, since the = original problem statement is that the MIP client (the one generating = BUs) in case of PMIP (i.e. the MAG) may change during the lifetime of a = MIP session. The problem addressed in MIP4 is a different one (replay = protection). It's off-topic, but I find this area of MIP4 overspecified = when compared to approaches in other protocols (e.g. IEEE 802.16). A = monotonically increasing counter is sufficient for replay protection Regards federico -----Message d'origine----- De : Sri Gundavelli [mailto:sgundave@cisco.com]=20 Envoy=E9 : jeudi 6 septembre 2007 21:58 =C0 : 'Alexandru Petrescu'; 'netlmm' Objet : RE: [netlmm] timestamp vs seqno redux Please comment on this issue raised by Alex about mandating Timestamp = option. Alex is right, when we discussed this issue, the conclusion was = to use Timestamp based approach, but we did not discuss if that was = supposed to be mandatory to implement. Now, w.r.t the issue, what are we mandating ? - The ability for the LMA to generate a Timestamp and return the timestamp option. The timestamp in relation to a specific reference point. IMO, this is one system call on most OS's and a delta addition if the timestamp generated is elapsed time past some other reference point. We are talking about 5 to 8 lines of code. I will be happy to publish this code for all standard OS's. - We are NOT mandating the nodes in the domain to sync up to a clock source.=20 How does it impact, if some deployment wants to use Seq Number approach = ? - No impact. The option need to be supported. Implies those 10 lines of extra code. Why this should be mandatory ? Base draft does not support Context Transfers. Given that the draft will = be incomplete, if we dont mandate the support. By mandating the support, = the LMA can always return its timestamp and the MAG can use that = timestamp and register. This need to be done just once whenever the = LMA/MAG clocks are out of sync and just for one registration. One extra = round trip for the 1st registration between LMA/MAG pair. But, if the LMA falls back to the seq number based approach and if there = are no context transfers, there is always an extra round trip for each = MN registration (at handoff).=20 So, I prefer the mandatory approach, its more efficient. But, as I had = it in the initial suggested text, I'm ok not mandating this and defining = an error code "Timestamp option not supported".=20 Please comment. I want to close this issue.=20 Implementation MUST support Timestamp option: [Yes/No] Thanks Sri =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, September 06, 2007 2:01 AM > To: netlmm > Subject: [netlmm] timestamp vs seqno redux >=20 > I've recently became aware that much nonsense discussion is happening=20 > around the timestamp vs seqno. People keep saying that seqno method=20 > is a possible alternative to timestamp but at the same time they=20 > mandate in the document the timestamp method. This is complete=20 > nonsense. >=20 > I don't want the timestamp method to be mandatory. >=20 > Anybody else wants the timestamp method to be a mandatory method? >=20 > Anybody else wants the timestamp method to be an alternative method? >=20 > Alex > PS: mandatory excerpts: > "This document _requires_ the use of Timestamp Option" > "An implementation MUST support Timestamp option." >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 05:11:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITZrm-0001tK-NJ; Fri, 07 Sep 2007 05:11:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITZrl-0001tF-9t for netlmm@ietf.org; Fri, 07 Sep 2007 05:11:05 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITZrj-0003Ny-QM for netlmm@ietf.org; Fri, 07 Sep 2007 05:11:05 -0400 Received: from rly30f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly30f.srv.mailcontrol.com (MailControl) with ESMTP id l879AqR5017615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Sep 2007 10:10:59 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly30f.srv.mailcontrol.com (MailControl) id l8799q4J015305 for netlmm@ietf.org; Fri, 7 Sep 2007 10:09:52 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly30f-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8799aDm015035; Fri, 07 Sep 2007 10:09:52 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 4750_324657c4_5d21_11dc_999d_0030482aac25; Fri, 07 Sep 2007 11:03:27 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007090711093188-478453 ; Fri, 7 Sep 2007 11:09:31 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.105,BAYES_00: -1.665,TOTAL_SCORE: -1.560 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 7 Sep 2007 11:10:15 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] timestamp vs seqno redux In-Reply-To: <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsA= References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> Date: Fri, 7 Sep 2007 11:09:01 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.70.1.140 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri,=20 > - We are NOT mandating the nodes in the domain to sync up to > a clock source.=20 Hmm, so far I assumed that the proposal is to mandate the MAGs to sync up to an external clock source such as NTP server. > Base draft does not support Context Transfers. Given that the draft > will be incomplete, if we dont mandate the support. By mandating > the support, the LMA can always return its timestamp and the MAG > can use that timestamp and register. This need to be done just > once whenever the LMA/MAG clocks are out of sync and just for one > registration. One extra round trip for the 1st registration between > LMA/MAG pair. So the proposal is to allow the use of the timestamp option in the absence of any external time synchronization like NTP and to mandate a mechanism to synchronize clocks between MAGs and LMA (and hence between all MAGs) using the timestamp option in PBU/PBA only (i.e., without utilizing NTP or an external clock source)? Is my understanding correct? If so, can you please give some more details how the LMA can detect that the clocks are out of sync? Is it based on a certain difference of timestamp in the received PBU and the current LMA's time?=20 And how to differentiate the out of sync case from the out-of-order delivery case (i.e., a PBU is delayed and overtaken by another PBU from another MAG)? For instance, if the LMA receives a PBU with timestamp equal to "current time of LMA - X" and X > threshold, how does the LMA know whether the=20 1. the MAG clock is synchronized, but the PBU got delayed by X or 2. the PBU is not delayed, but the MAG's clock is out of sync by X? Ideally, in case 1 the LMA should just ignore the PBU, in case 2 it should accept it and sync clocks. If the idea is to always reject a PBU with X > threshold and include a current timestamp in the PBA, then I guess the same could be done with sequence numbers instead of timestamps, right? BR, Kilian Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 08:17:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITcmH-0007N6-QO; Fri, 07 Sep 2007 08:17:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITcmG-0007Mx-9m for netlmm@ietf.org; Fri, 07 Sep 2007 08:17:36 -0400 Received: from hu-out-0506.google.com ([72.14.214.239]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITcmF-0003Ri-OU for netlmm@ietf.org; Fri, 07 Sep 2007 08:17:36 -0400 Received: by hu-out-0506.google.com with SMTP id 31so132182huc for ; Fri, 07 Sep 2007 05:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=0kxE+NLzPk3RfGVFggXGSAYBcQz8yw0oD59DwHlnuok=; b=DRrzQ+mdRgA6RWp8q+qQowWfSu95Jt7+Q3KeaqPpO6wd7yRuGFV6u/padqEBGsuLOyT5TD24z2ZyCwsZkYpEXCQsLtOYW1W69qvbAgSHcOSzeKbA5kA3AZhKq4JLc7+w0gSJwvuQ7s6pm5Rd8ckCwZ1lzWfZNSVzFtxr90nFGEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=glVxGo3GEEtnQfcL+2qUSVstf8Z8AhjdqKNuMbMMyw8smdNltnZ8ejadfwibP88T2o68f+5vdKIRxIFiY5vPR3ECG3Xi6LWogbaqR1QPzlmjGBrbmIRJ7h/bXSGmrYZm+Vud8UYyzpGDVQMY7Wb4zBg6i2u5pA4e8X1cWd30Gw4= Received: by 10.67.26.7 with SMTP id d7mr1278986ugj.1189167454413; Fri, 07 Sep 2007 05:17:34 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id h7sm3272679nfh.2007.09.07.05.17.31 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2007 05:17:32 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic Date: Fri, 7 Sep 2007 14:17:27 +0200 User-Agent: KMail/1.9.6 References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <200709041727.50014.julien.IETF@laposte.net> <46DD8453.1050005@gmail.com> In-Reply-To: <46DD8453.1050005@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709071417.28184.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Christian Vogt , 'Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Tuesday 04 September 2007, Alexandru Petrescu wrote: > Julien Laganier wrote: > > On Tuesday 04 September 2007, Alexandru Petrescu wrote: > >> I agree, I think SeND format (48/16bit seconds since 1970) is > >> better than NTP format (32/32bit seconds since 1900) at least > >> because more compatible with some Unices and because delays the > >> roll-over flag day to much later than 2036. But I think the > >> roll-over issue is still there. IMHO SeND could get rid of the > >> timestamp as well. > >> > >> At minimal, IMHO we could write in the doc the roll-over P-MIPv6 > >> year, by the Gregorian calendar (anyone cares to compute the > >> year?) when P-MIPv6 will have issues and how it should seamlessly > >> be dealt with it without disrupting service to MN. > > > > Alex, as I wrote earlier with 48bits seconds we are safe for nearly > > 9 millions years. > > Thanks, this is good to know (and sorry I have just seen now your > previous message). > > We should then write down what happens at year 9million+1picosecond: > (1) how is the LMA making sure it survives the overflowing P-BU > without believing it's a very old P-BU; and (2) without disrupting > service to MN. > > Don't you think so? Maybe I'm wrong, but I somehow feel a timestamp wrap around is not a problem when it is going to happen 9 millions years from now; that gives us ample time (9 million years I guess) to specify an extended timestamp option that works after 9 million years and takes precedence over the current timestamp option. Further, when the wrap around occurs we'll probably not be using IPv6 anymore... If that is really a concern to you, would you be fine with a 128 bits timestamp, that would work until the end of the universe and time? --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 08:19:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITco8-0002B6-LE; Fri, 07 Sep 2007 08:19:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITco7-00024g-M8 for netlmm@ietf.org; Fri, 07 Sep 2007 08:19:31 -0400 Received: from hu-out-0506.google.com ([72.14.214.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITco6-0007Uv-Dn for netlmm@ietf.org; Fri, 07 Sep 2007 08:19:31 -0400 Received: by hu-out-0506.google.com with SMTP id 31so132346huc for ; Fri, 07 Sep 2007 05:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=CoAMMYHqYhM6kBEaOPF6bA6sumUPLFYP2trrHPv1ZrE=; b=WpW4es8otCFMhF/fq48Hhli9ilzlVMhCE+jP85XwWzRhJsyU32DQj0kQkT6sMWy5tC9YZ+hIg4i7tNzRmtmTnApGj0DBtsIgyvadJTDT6qSno+RwbezuxOxxV2S+zuP0EYHYfxXVKZiJzsBLCKNvCPEQZ2AHQ2Sh9yi8nuqAqQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=e7jmevRMB8ZIYq5t8VkaeURlNadCqJ+vAVVXlJfkbG6gmr/GM9CzziMCHvPyq83HF3Z0+hBQ2jjZ0kmbDIsya4nZnLVDR6WJVSFMJ3JKVpGY2TSKSVUKal36SJEIAS/s5K3RfmohT9CS+e/s7wh/jSw9yvRjvuHKIZLGYpdK9uk= Received: by 10.86.82.16 with SMTP id f16mr1380080fgb.1189167569079; Fri, 07 Sep 2007 05:19:29 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 7sm3222736nfv.2007.09.07.05.19.27 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2007 05:19:27 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 14:19:23 +0200 User-Agent: KMail/1.9.6 References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> In-Reply-To: <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709071419.24046.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Thursday 06 September 2007, Sri Gundavelli wrote: > Implementation MUST support Timestamp option: [Yes/No] YES. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 08:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITcxq-0003T7-AC; Fri, 07 Sep 2007 08:29:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITcxo-0003T2-Is for netlmm@ietf.org; Fri, 07 Sep 2007 08:29:32 -0400 Received: from hu-out-0506.google.com ([72.14.214.239]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITcxn-0003hL-Cb for netlmm@ietf.org; Fri, 07 Sep 2007 08:29:32 -0400 Received: by hu-out-0506.google.com with SMTP id 31so133082huc for ; Fri, 07 Sep 2007 05:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Ont4xDK9jG451A+IiRsNDAiYIr4Q0fCquLnO7Io+CgU=; b=PYvCpGVSmaKwqw1+mYV1L/t15FE5nkOXIZT7RW5FQw8c/NbTAbhEbCIPPqQfPBorkiT8yHLTy8+zdFLPnwy33EsBt7b9KisapZzNbZDJ6xb28+rGWpMdKxc3JFCqE8FkIJ17oP5mMhvfdeHBFNH2CjYCC65ryUDXUmHE6vYbf0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=rP3vAMx5SIRv2kOdlaBK73v+nz4NV1nSKSkmUMbI4bKSFLfHJDc7/LrYNSCWjohAke5DRHvSmplRWCEH6ee53QT3RkP/3y2heYlZVwFwr0JfIZzs/z12XmOtMXUU/YVtcCdL/zAbEHqyxDWp+vR8X5EC/CFDaFvfmOUvVlwdw0o= Received: by 10.86.23.17 with SMTP id 17mr1391810fgw.1189168169942; Fri, 07 Sep 2007 05:29:29 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 2sm3212942nfv.2007.09.07.05.29.25 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2007 05:29:27 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] Issue: Auth Option support Date: Fri, 7 Sep 2007 14:29:19 +0200 User-Agent: KMail/1.9.6 References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> In-Reply-To: <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709071429.19318.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, On Thursday 06 September 2007, Sri Gundavelli wrote: > I'm confused, should the draft say > > "Both LMA and MAG MUST implement IPsec" and > "all the signaling messages SHOULD be protected using IPSec". > > Will this ok, when reviewed by the security folks ? > > or mandate IPsec for this specification and let other draft > relax this in the presence of an alternative approach ? > > Please comment. Somehow, "MUST implement" and "SHOULD use" together seems a bit tautologic. To me "SHOULD use" is sufficient since it covers both of the two possibles cases: - deployment follows the SHOULD recommendation, it uses IPsec to protect PMIPv6, in which case it supports it, since it's using it :), or - deployment ignores the SHOULD recommendation, does not uses IPSec, in which case it is useless to implement it since it's not used... I'd prefer having "MUST protect integrity of signalling messages, and SHOULD use IPsec ESP to protect integrity of those messages". We might also add "MAY use IPsec AH". --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 08:43:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdBJ-0008NT-79; Fri, 07 Sep 2007 08:43:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdBI-0008LS-H0 for netlmm@ietf.org; Fri, 07 Sep 2007 08:43:28 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITdBH-00043y-Te for netlmm@ietf.org; Fri, 07 Sep 2007 08:43:28 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1189169006!3788843!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 14280 invoked from network); 7 Sep 2007 12:43:26 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-153.messagelabs.com with SMTP; 7 Sep 2007 12:43:26 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l87ChQeX012631; Fri, 7 Sep 2007 05:43:26 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l87ChPdg004621; Fri, 7 Sep 2007 07:43:25 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l87ChLU8004542; Fri, 7 Sep 2007 07:43:22 -0500 (CDT) Message-ID: <46E14764.2060604@gmail.com> Date: Fri, 07 Sep 2007 14:43:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <200709041727.50014.julien.IETF@laposte.net> <46DD8453.1050005@gmail.com> <200709071417.28184.julien.IETF@laposte.net> In-Reply-To: <200709071417.28184.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Christian Vogt , 'Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > On Tuesday 04 September 2007, Alexandru Petrescu wrote: >> Julien Laganier wrote: >>> On Tuesday 04 September 2007, Alexandru Petrescu wrote: >>>> I agree, I think SeND format (48/16bit seconds since 1970) is >>>> better than NTP format (32/32bit seconds since 1900) at least >>>> because more compatible with some Unices and because delays >>>> the roll-over flag day to much later than 2036. But I think >>>> the roll-over issue is still there. IMHO SeND could get rid of >>>> the timestamp as well. >>>> >>>> At minimal, IMHO we could write in the doc the roll-over >>>> P-MIPv6 year, by the Gregorian calendar (anyone cares to >>>> compute the year?) when P-MIPv6 will have issues and how it >>>> should seamlessly be dealt with it without disrupting service >>>> to MN. >>> Alex, as I wrote earlier with 48bits seconds we are safe for >>> nearly 9 millions years. >> Thanks, this is good to know (and sorry I have just seen now your >> previous message). >> >> We should then write down what happens at year >> 9million+1picosecond: (1) how is the LMA making sure it survives >> the overflowing P-BU without believing it's a very old P-BU; and >> (2) without disrupting service to MN. >> >> Don't you think so? > > Maybe I'm wrong, but I somehow feel a timestamp wrap around is not a > problem when it is going to happen 9 millions years from now; that > gives us ample time (9 million years I guess) to specify an extended > timestamp option that works after 9 million years and takes > precedence over the current timestamp option. Further, when the wrap > around occurs we'll probably not be using IPv6 anymore... > > If that is really a concern to you, would you be fine with a 128 bits > timestamp, that would work until the end of the universe and time? Julien, thank you for asking. After discussing face-to-face with colleagues around this issue, I've been also told that in 9million years we have enough time to conquer the galaxies and/or disappear, etc, etc. I would like to say that you are right. It's just that when trying to specify the usage of time the things are very complex to specify and to implement too. Think for example that if we use timestamps that expire in 9million years (or 128bit at the end of universe) then the common use of time within that timestamp is going to be very localized. Ie much of the bits in these timestamps don't change at all, they're the same for a long time. This means, grosso modo, that we use 64bit to waste bandwidth. Alex >> a 128 bits timestamp, that would work until the end of the universe >> and time PS:128bits survives the time itself? ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 08:52:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdJk-0001uc-ML; Fri, 07 Sep 2007 08:52:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdJj-0001qn-Nv for netlmm@ietf.org; Fri, 07 Sep 2007 08:52:11 -0400 Received: from hu-out-0506.google.com ([72.14.214.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITdJi-0008Er-Gf for netlmm@ietf.org; Fri, 07 Sep 2007 08:52:11 -0400 Received: by hu-out-0506.google.com with SMTP id 31so135533huc for ; Fri, 07 Sep 2007 05:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Tt4PDdynkN4+2qYP+iLrPeKCQyY0Q/tASD0Hfnvgf5k=; b=mtOJ4KR3gUmJTSaNwkWvGtjh+VntbfR31NEaJ3jOwPcZ6ku+c9YsPDxk9XM7oQFKVkQXIub1GOO587CGbZ11SMIipFk18/9JDhIYWdM5pHPQQ9N4u+TvKguH9T+F6lBhBUsPlDtEwiW48KhSLW2ISMRMHN4Qk45xjRX5OY1iyF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=VBDl+fBMS2sP4hgM8uYCCZc3ewnWl+6u2/c0aQl0cYiM4V5W2hIDvMGMTPKkgbPFVaohyN2jU3cYpdu/ehRypll9okYHbx+guKUGAdaSNckMSwcVyAXgvWpv2SgPOxFX6z3ocs3HIiOES34Oj3lKZlqJwCG0d5wCfHQnVe2DKGU= Received: by 10.86.91.9 with SMTP id o9mr1432560fgb.1189169529207; Fri, 07 Sep 2007 05:52:09 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 7sm3376901nfv.2007.09.07.05.52.05 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2007 05:52:07 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic Date: Fri, 7 Sep 2007 14:51:58 +0200 User-Agent: KMail/1.9.6 References: <025301c78705$f548be80$d3f6200a@amer.cisco.com> <200709071417.28184.julien.IETF@laposte.net> <46E14764.2060604@gmail.com> In-Reply-To: <46E14764.2060604@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709071451.59026.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Christian Vogt , 'Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Friday 07 September 2007, Alexandru Petrescu wrote: > >> a 128 bits timestamp, that would work until the end of the > >> universe and time > > PS:128bits survives the time itself? Time is either a dimension of the universe, or an intellectual construction of human beings. In both case, if the universe is gone the time too :) --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 08:52:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdKI-0002Ws-2Y; Fri, 07 Sep 2007 08:52:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdKH-0002Wj-Av for netlmm@ietf.org; Fri, 07 Sep 2007 08:52:45 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITdKG-0004GT-Uk for netlmm@ietf.org; Fri, 07 Sep 2007 08:52:45 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1189169564!25819797!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23636 invoked from network); 7 Sep 2007 12:52:44 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 7 Sep 2007 12:52:44 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l87Cqi4E020372; Fri, 7 Sep 2007 05:52:44 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l87CqhHD005149; Fri, 7 Sep 2007 07:52:43 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l87CqfIR005066; Fri, 7 Sep 2007 07:52:42 -0500 (CDT) Message-ID: <46E14994.9060302@gmail.com> Date: Fri, 07 Sep 2007 14:52:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Issue: Auth Option support References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> <200709071429.19318.julien.IETF@laposte.net> In-Reply-To: <200709071429.19318.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > Hi Sri, > > On Thursday 06 September 2007, Sri Gundavelli wrote: >> I'm confused, should the draft say >> >> "Both LMA and MAG MUST implement IPsec" and >> "all the signaling messages SHOULD be protected using IPSec". >> >> Will this ok, when reviewed by the security folks ? >> >> or mandate IPsec for this specification and let other draft >> relax this in the presence of an alternative approach ? >> >> Please comment. > > Somehow, "MUST implement" and "SHOULD use" together seems a bit > tautologic. > > To me "SHOULD use" is sufficient since it covers both of the two > possibles cases: > > - deployment follows the SHOULD recommendation, it uses IPsec to protect > PMIPv6, in which case it supports it, since it's using it :), or > > - deployment ignores the SHOULD recommendation, does not uses IPSec, in > which case it is useless to implement it since it's not used... > > I'd prefer having "MUST protect integrity of signalling messages, and > SHOULD use IPsec ESP to protect integrity of those messages". We might > also add "MAY use IPsec AH". I'm not sure what you mean... Do you mean to use ESP to offer authentication (integrity protection)? I'd suggest to make AH a should, for this purpose, not ESP. Or do you mean to use ESP to offer confidentiality (encrypted packets)? In this case, ESP is the only possibility to do confindentiality, because authopt doesn't; so not sure why needing to debate the use of ESP for confidentiality, it is pretty clear. Also, when you say to protect integrity of signalling messages, which of those do you assume? authopt only does bu/back, it doesn't do other mip6 signalling. So I think you only assume integrity of bu/back, right? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 09:16:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdgm-0001GZ-LA; Fri, 07 Sep 2007 09:16:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdgl-0001G7-HF for netlmm@ietf.org; Fri, 07 Sep 2007 09:15:59 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITdgk-0000Hm-7E for netlmm@ietf.org; Fri, 07 Sep 2007 09:15:59 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1030519uge for ; Fri, 07 Sep 2007 06:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=P9Uu57Wda1eoKrrU9LGNY5StaMp9DLhnykEU3mwfjxw=; b=YRX33lTytuqkAHyrEqDkdmTU4bkNmYtOQ1RQiuKXRHWzqZzhxkS9Q2xoGLHzd0kB88OC1Sivjuw8lABQ/CiehxzAxf9CczFqJaZaNgWzP4f6/rlwdIegXslujpET/xnQjZuDB7n48ESC5iKzBmLzw4+PqgSPaLFRzTB5vKgin90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=FSui56GuJ4bUkJfx8K2frzyoHH/EV7AEelTJtOgeCkenGV21ugfq01PjN/XFbNHfWKfp8U+ktWTltrHe0JE8QGN5NpTCeY63MFFfYgfFe4nTmCLYgBBtsBKiKtcaJAbrPuW74dOGIvsxmkNO8J/PCsJYgRBOxEvwojc1JOSqOWA= Received: by 10.66.244.20 with SMTP id r20mr1326396ugh.1189170957060; Fri, 07 Sep 2007 06:15:57 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 7sm3478681nfv.2007.09.07.06.15.54 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2007 06:15:55 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Subject: Re: [netlmm] Issue: Auth Option support Date: Fri, 7 Sep 2007 15:15:51 +0200 User-Agent: KMail/1.9.6 References: <200709071429.19318.julien.IETF@laposte.net> <46E14994.9060302@gmail.com> In-Reply-To: <46E14994.9060302@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709071515.51933.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Friday 07 September 2007, Alexandru Petrescu wrote: > Julien Laganier wrote: > > Hi Sri, > > > > On Thursday 06 September 2007, Sri Gundavelli wrote: > >> I'm confused, should the draft say > >> > >> "Both LMA and MAG MUST implement IPsec" and > >> "all the signaling messages SHOULD be protected using IPSec". > >> > >> Will this ok, when reviewed by the security folks ? > >> > >> or mandate IPsec for this specification and let other draft > >> relax this in the presence of an alternative approach ? > >> > >> Please comment. > > > > Somehow, "MUST implement" and "SHOULD use" together seems a bit > > tautologic. > > > > To me "SHOULD use" is sufficient since it covers both of the two > > possibles cases: > > > > - deployment follows the SHOULD recommendation, it uses IPsec to > > protect PMIPv6, in which case it supports it, since it's using it > > :), or > > > > - deployment ignores the SHOULD recommendation, does not uses > > IPSec, in which case it is useless to implement it since it's not > > used... > > > > I'd prefer having "MUST protect integrity of signalling messages, > > and SHOULD use IPsec ESP to protect integrity of those messages". > > We might also add "MAY use IPsec AH". > > I'm not sure what you mean... > > Do you mean to use ESP to offer authentication (integrity > protection)? I'd suggest to make AH a should, for this purpose, not > ESP. For an IPsec implementation ESP is MUST and AH is a MAY, therefore I meant exactly what I said: ESP for integrity protection. For the reference, this is an excerpt from Section 3.2 of RFC4301: IPsec implementations MUST support ESP and MAY support AH. (Support for AH has been downgraded to MAY because experience has shown that there are very few contexts in which ESP cannot provide the requisite security services. Note that ESP can be used to provide only integrity, without confidentiality, making it comparable to AH in most contexts.) > Or do you mean to use ESP to offer confidentiality (encrypted > packets)? No I don't mean that. I don't see confidentiality protection as a requirement for PMIPv6 security. > In this case, ESP is the only possibility to do > confindentiality, because authopt doesn't; so not sure why needing to > debate the use of ESP for confidentiality, it is pretty clear. > > Also, when you say to protect integrity of signalling messages, which > of those do you assume? authopt only does bu/back, it doesn't do > other mip6 signalling. So I think you only assume integrity of > bu/back, right? I mean protection of PMIPv6 messages, i.e. defined/used by the PMIPv6 specification. Seems that's limited to pBU/pBAck, right? --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 09:22:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdmw-0002Ox-3Z; Fri, 07 Sep 2007 09:22:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdmu-0002Ol-5W for netlmm@ietf.org; Fri, 07 Sep 2007 09:22:20 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITdmt-0004qv-EZ for netlmm@ietf.org; Fri, 07 Sep 2007 09:22:20 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l87DGFo20947; Fri, 7 Sep 2007 13:16:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 08:18:25 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E0784F.2090904@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acfw0UeptuRIstosTB2A7ozl3xKzrQAfuJpg References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" , "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, Please see comments inline. >=20 > Sri Gundavelli wrote: > > Please comment on this issue raised by Alex about mandating=20 > Timestamp =20 > > option. Alex is right, when we discussed this issue, the=20 > conclusion =20 > > was to use Timestamp based approach, but we did not discuss=20 > if that =20 > > was supposed to be mandatory to implement. > >=20 > > Now, w.r.t the issue, what are we mandating ? > >=20 > > - The ability for the LMA to generate a Timestamp and return the=20 > > timestamp option. The timestamp in relation to a specific reference=20 > > point. IMO, this is one system call on most OS's and a=20 > delta addition =20 > > if the timestamp generated is elapsed time past some other=20 > reference =20 > > point. We are talking about 5 to 8 lines of code. I will be=20 > happy to =20 > > publish this code for all standard OS's. >=20 > I agree it's not much code to call an API to obtain current=20 > time. What is more is to encode the message format of that=20 > time into the Mobile > IPv6 implementation. >=20 > > - We are NOT mandating the nodes in the domain to sync up=20 > to a clock =20 > > source. >=20 > Thanks, that is good. >=20 > > How does it impact, if some deployment wants to use Seq Number=20 > > approach ? > >=20 > > - No impact. The option need to be supported. Implies=20 > those 10 lines =20 > > of extra code. > >=20 > >=20 > > Why this should be mandatory ? > >=20 > > Base draft does not support Context Transfers. >=20 > Ok. >=20 > > Given that the draft will be incomplete, if we dont mandate the=20 > > support. >=20 > I don't think it will be incomplete. >=20 > The spec can very easily say that in order for the P-BUs to=20 > be correctly ordered at the HA then the HA should provide the=20 > correct seqno to the MAG, as part of the 'profile' related to=20 > MN, or as part of some other assumed and non-specified=20 > mechanism. When MAG sends a P-BU to MAG it will just send=20 > the seqno it received in the unspecified mechanism, and=20 > increment it plus one. >=20 > Or maybe as part of an enhanced DHCP procedure, or AAA, or=20 > link-layer authentication procedure. >=20 > The LMA is supposed to provide MN's home prefix already to=20 > the MAG, thus it can provide the right seqno to it as well. >=20 > > By mandating the support, the LMA can always return its=20 > timestamp and =20 > > the MAG can use that timestamp and register. This need to=20 > be done just=20 > > once whenever the LMA/MAG clocks are out of sync and just for one=20 > > registration. One extra round trip for the 1st registration between=20 > > LMA/MAG pair. >=20 > But this can be achieved with the seqnos as well, not=20 > necessarily to send the timestamp. >=20 > > But, if the LMA falls back to the seq number based approach and if=20 > > there are no context transfers, there is always an extra round trip=20 > > for each MN registration (at handoff). >=20 > No, not always an extra round trip necessary. (For our=20 > audience: in private I've discussed with Ahmad and Sri at=20 > least three possible ways to sync these seqnos and two of=20 > them assumed extra round trips.) {Ahmad] Alex, the fact that we did not continue the offline discussion is because you preferred to bring this to the mailing list which is absolutely fine with me. It does not mean that I agreed with any of your proposals.=20 You keep saying that the SQN can be provided by the LMA via a profile. I want you to be specific here, tell me how that would work. In details. My understudying that profile comes from a policy server or whatever. The SQN is a per-MN dynamically always changing. In your response please consider how the LMA will always update the profile with the last SQN. Thanks. >=20 > I think that if the right seqno is provided by LMA to MAG as=20 > part of that 'profile' then MAG can simply increment it and=20 > send the proper seqno to LMA. This involves no additional roundtrip. [Ahmad] I disagree, The only feasible and meaningful way to provide the SQN without extra outstanding effort is Context Transfer and the draft acknowledged that. Please see the above comment. >=20 > > So, I prefer the mandatory approach, its more efficient.=20 > But, as I had=20 > > it in the initial suggested text, I'm ok not mandating this and=20 > > defining an error code "Timestamp option not supported". >=20 > I'm happy you already agreed not to mandate timestamp, thanks=20 > for that. >=20 > For error "Timestamp option not supported" then one would=20 > have to define "seqno option not supported" too, right? [Ahmad] Not right. PMIPv6 is based on RFC3775 and we agreed long time ago, LMA supports SQN either way. It is part of the Mobility header. Right? How the LMA would survive all of this without supporting SQN, unless you are proposing deprecating it? >=20 > > Please comment. I want to close this issue. > >=20 > >=20 > > Implementation MUST support Timestamp option: [Yes/No] >=20 > No, it's not necessary to say that implementation MUST=20 > support timestamp option. [Ahmad] Ok, I guess you meant to say, that it is not necessary for implementation to support the use of timestamp for P-BU/P-BA ordering. In all conditions, implementation MUST support the timestamp option but not necessarily the use of it. Because, in order to reject timestamp option, implementation MUST understand the option itself. Right? >=20 > An alternative is just an alternative. >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 09:28:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdt6-000514-18; Fri, 07 Sep 2007 09:28:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdt4-00050z-P1 for netlmm@ietf.org; Fri, 07 Sep 2007 09:28:42 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITdt3-0000Wy-GD for netlmm@ietf.org; Fri, 07 Sep 2007 09:28:42 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l87DOrw23389; Fri, 7 Sep 2007 13:24:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 08:24:51 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371169906D2@zrc2hxm2.corp.nortel.com> In-Reply-To: <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwACUqQtA= References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> From: "Ahmad Muhanna" To: "Sri Gundavelli" , "Alexandru Petrescu" , "netlmm" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, Please see comments inline. Regards, Ahmad =20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Thursday, September 06, 2007 2:58 PM > To: 'Alexandru Petrescu'; 'netlmm' > Subject: RE: [netlmm] timestamp vs seqno redux >=20 >=20 > Please comment on this issue raised by Alex about mandating=20 > Timestamp option. Alex is right, when we discussed this=20 > issue, the conclusion was to use Timestamp based approach,=20 > but we did not discuss if that was supposed to be mandatory=20 > to implement. >=20 > Now, w.r.t the issue, what are we mandating ? >=20 > - The ability for the LMA to generate a Timestamp and return > the timestamp option. The timestamp in relation to a specific > reference point. IMO, this is one system call on most OS's and > a delta addition if the timestamp generated is elapsed time past > some other reference point. We are talking about 5 to 8 lines > of code. I will be happy to publish this code for all standard > OS's. >=20 > - We are NOT mandating the nodes in the domain to sync up to > a clock source.=20 >=20 >=20 > How does it impact, if some deployment wants to use Seq=20 > Number approach ? >=20 > - No impact. The option need to be supported. Implies those 10 > lines of extra code. >=20 >=20 > Why this should be mandatory ? >=20 > Base draft does not support Context Transfers. Given that the=20 > draft will be incomplete, if we dont mandate the support. By=20 > mandating the support, the LMA can always return its=20 > timestamp and the MAG can use that timestamp and register.=20 > This need to be done just once whenever the LMA/MAG clocks=20 > are out of sync and just for one registration. One extra=20 > round trip for the 1st registration between LMA/MAG pair. [Ahmad] I agree. >=20 > But, if the LMA falls back to the seq number based approach=20 > and if there are no context transfers, there is always an=20 > extra round trip for each MN registration (at handoff). [Ahmad] TRUE.=20 Unless there is a mechanism to communicate the last SQN the pMAG used for the MN to the nMAG, it is almost always requires 2 round trips..=20 >=20 > So, I prefer the mandatory approach, its more efficient. But,=20 > as I had it in the initial suggested text, I'm ok not=20 > mandating this and defining an error code "Timestamp option=20 > not supported".=20 [Ahmad] As my initial suggestion was, I believe this is the best approach. I support that. >=20 >=20 > Please comment. I want to close this issue.=20 >=20 >=20 > Implementation MUST support Timestamp option: [Yes/No] [Ahmad] Let me rephrase this question, as I mentioned in my response to Alex earlier. Implementation Must support timestamp option however, the mechanism to use timestamp for ordering P-BU/P-BA is optional. In that case, I support this approach. As I said earlier, in order for the MAG to send "timestamp mechanism NOT supported", it needs to understand the timestamp option. >=20 >=20 > Thanks > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Sent: Thursday, September 06, 2007 2:01 AM > > To: netlmm > > Subject: [netlmm] timestamp vs seqno redux > >=20 > > I've recently became aware that much nonsense discussion is=20 > happening=20 > > around the timestamp vs seqno. People keep saying that=20 > seqno method=20 > > is a possible alternative to timestamp but at the same time they=20 > > mandate in the document the timestamp method. This is complete=20 > > nonsense. > >=20 > > I don't want the timestamp method to be mandatory. > >=20 > > Anybody else wants the timestamp method to be a mandatory method? > >=20 > > Anybody else wants the timestamp method to be an alternative method? > >=20 > > Alex > > PS: mandatory excerpts: > > "This document _requires_ the use of Timestamp Option" > > "An implementation MUST support Timestamp option." > >=20 > >=20 > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email=20 > Security System. > > For more information please visit http://www.messagelabs.com/email=20 > >=20 > ______________________________________________________________________ > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 09:28:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdtL-0005kK-9n; Fri, 07 Sep 2007 09:28:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdtK-0005kE-DR for netlmm@ietf.org; Fri, 07 Sep 2007 09:28:58 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITdtJ-0004y4-U1 for netlmm@ietf.org; Fri, 07 Sep 2007 09:28:58 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1189171736!32693858!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 24215 invoked from network); 7 Sep 2007 13:28:56 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-13.tower-119.messagelabs.com with SMTP; 7 Sep 2007 13:28:56 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l87DSpZa027340; Fri, 7 Sep 2007 06:28:56 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l87DSpDr023114; Fri, 7 Sep 2007 08:28:51 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l87DSm46023006; Fri, 7 Sep 2007 08:28:49 -0500 (CDT) Message-ID: <46E1520B.3010102@gmail.com> Date: Fri, 07 Sep 2007 15:28:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Issue: Auth Option support References: <200709071429.19318.julien.IETF@laposte.net> <46E14994.9060302@gmail.com> <200709071515.51933.julien.IETF@laposte.net> In-Reply-To: <200709071515.51933.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > On Friday 07 September 2007, Alexandru Petrescu wrote: >> Julien Laganier wrote: >>> Hi Sri, >>> >>> On Thursday 06 September 2007, Sri Gundavelli wrote: >>>> I'm confused, should the draft say >>>> >>>> "Both LMA and MAG MUST implement IPsec" and >>>> "all the signaling messages SHOULD be protected using IPSec". >>>> >>>> Will this ok, when reviewed by the security folks ? >>>> >>>> or mandate IPsec for this specification and let other draft >>>> relax this in the presence of an alternative approach ? >>>> >>>> Please comment. >>> Somehow, "MUST implement" and "SHOULD use" together seems a bit >>> tautologic. >>> >>> To me "SHOULD use" is sufficient since it covers both of the two >>> possibles cases: >>> >>> - deployment follows the SHOULD recommendation, it uses IPsec to >>> protect PMIPv6, in which case it supports it, since it's using it >>> :), or >>> >>> - deployment ignores the SHOULD recommendation, does not uses >>> IPSec, in which case it is useless to implement it since it's not >>> used... >>> >>> I'd prefer having "MUST protect integrity of signalling messages, >>> and SHOULD use IPsec ESP to protect integrity of those messages". >>> We might also add "MAY use IPsec AH". >> I'm not sure what you mean... >> >> Do you mean to use ESP to offer authentication (integrity >> protection)? I'd suggest to make AH a should, for this purpose, not >> ESP. > > For an IPsec implementation ESP is MUST and AH is a MAY, therefore I > meant exactly what I said: ESP for integrity protection. For the > reference, this is an excerpt from Section 3.2 of RFC4301: > > IPsec implementations MUST support ESP and MAY > support AH. (Support for AH has been downgraded to MAY because > experience has shown that there are very few contexts in which ESP > cannot provide the requisite security services. Note that ESP can be > used to provide only integrity, without confidentiality, making it > comparable to AH in most contexts.) Ok, I was not aware of that paragraph. I was thinking AH protection was enough but it seems it is not necessary, and that ESP is necessary. >> Or do you mean to use ESP to offer confidentiality (encrypted >> packets)? > > No I don't mean that. I don't see confidentiality protection as a > requirement for PMIPv6 security. Err... >> In this case, ESP is the only possibility to do >> confindentiality, because authopt doesn't; so not sure why needing to >> debate the use of ESP for confidentiality, it is pretty clear. >> >> Also, when you say to protect integrity of signalling messages, which >> of those do you assume? authopt only does bu/back, it doesn't do >> other mip6 signalling. So I think you only assume integrity of >> bu/back, right? > > I mean protection of PMIPv6 messages, i.e. defined/used by the PMIPv6 > specification. Seems that's limited to pBU/pBAck, right? Right... that's what the PMIPv6 spec says. It is strange we struggle with timestamp/seqno issues whose main goal is to make it more reliable and at the same time we ignore Binding Error, Binding Refresh Request. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 09:34:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdyM-00025z-Qv; Fri, 07 Sep 2007 09:34:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITdyL-00025u-HY for netlmm@ietf.org; Fri, 07 Sep 2007 09:34:09 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ITdyK-0000eI-9c for netlmm@ietf.org; Fri, 07 Sep 2007 09:34:09 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1189172047!4661238!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 32008 invoked from network); 7 Sep 2007 13:34:07 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-153.messagelabs.com with SMTP; 7 Sep 2007 13:34:07 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l87DY2QQ023056; Fri, 7 Sep 2007 06:34:06 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l87DY1H8013047; Fri, 7 Sep 2007 08:34:01 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l87DXw3v012957; Fri, 7 Sep 2007 08:33:59 -0500 (CDT) Message-ID: <46E15341.4060102@gmail.com> Date: Fri, 07 Sep 2007 15:33:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: [...] >>> But, if the LMA falls back to the seq number based approach and >>> if there are no context transfers, there is always an extra round >>> trip for each MN registration (at handoff). >> No, not always an extra round trip necessary. (For our audience: >> in private I've discussed with Ahmad and Sri at least three >> possible ways to sync these seqnos and two of them assumed extra >> round trips.) > > {Ahmad] Alex, the fact that we did not continue the offline > discussion is because you preferred to bring this to the mailing list > which is absolutely fine with me. It does not mean that I agreed > with any of your proposals. Right, I know, you didn't agree, and I didn't imply you agreed. I agree with you on this. > You keep saying that the SQN can be provided by the LMA via a > profile. I want you to be specific here, tell me how that would work. > In details. > > My understudying that profile comes from a policy server or whatever. > The SQN is a per-MN dynamically always changing. In your response > please consider how the LMA will always update the profile with the > last SQN. Ahmad, when first the 'profile' is delivered by the 'policy server' or whatever to the MAG then the LMA inserts the current seqno in that profile. It is not necessary to insert every time, just the first time the MN authenticates. This is the same time when the home prefix (the one that has to be put in the RA) is delivered in that same profile. Don't you think this can work? Why not? Why can the LMA send to MAG the home network prefix of the MN but not its current seqno? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 09:45:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITe96-0005Ta-OQ; Fri, 07 Sep 2007 09:45:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITe95-0005TV-RI for netlmm@ietf.org; Fri, 07 Sep 2007 09:45:15 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITe95-0005Oi-8n for netlmm@ietf.org; Fri, 07 Sep 2007 09:45:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l87Dj7w27068; Fri, 7 Sep 2007 13:45:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 08:45:04 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116990762@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E15341.4060102@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfxU8hMfiYEhSJVTC+8JH7+3vNmEgAAJLeQ References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> <46E15341.4060102@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, Please find comments inline. Regards, Ahmad =20 > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > [...] > >>> But, if the LMA falls back to the seq number based=20 > approach and if=20 > >>> there are no context transfers, there is always an extra=20 > round trip=20 > >>> for each MN registration (at handoff). > >> No, not always an extra round trip necessary. (For our audience:=20 > >> in private I've discussed with Ahmad and Sri at least=20 > three possible=20 > >> ways to sync these seqnos and two of them assumed extra=20 > round trips.) > >=20 > > {Ahmad] Alex, the fact that we did not continue the offline=20 > discussion=20 > > is because you preferred to bring this to the mailing list =20 > which is=20 > > absolutely fine with me. It does not mean that I agreed with any of=20 > > your proposals. >=20 > Right, I know, you didn't agree, and I didn't imply you=20 > agreed. I agree with you on this. >=20 > > You keep saying that the SQN can be provided by the LMA via=20 > a profile.=20 > > I want you to be specific here, tell me how that would work. > > In details. > >=20 > > My understudying that profile comes from a policy server or=20 > whatever. > > The SQN is a per-MN dynamically always changing. In your response=20 > > please consider how the LMA will always update the profile with the=20 > > last SQN. >=20 > Ahmad, when first the 'profile' is delivered by the 'policy=20 > server' or whatever to the MAG then the LMA inserts the=20 > current seqno in that profile. =20 {Ahmad] I do not understand this sentence, can you elaborate. I understand the portion of how the policy server may deliver the profile to the MAG. Now, how the LMA then will insert the current SQN in that profile which already in the hand of the MAG.? Am I missing something? > It is not necessary to insert=20 > every time, just the first time the MN authenticates. =20 [Ahmad] What does this mean Alex. Are you assuming that there is no re-registration possibility here? > This=20 > is the same time when the home prefix (the one that has to=20 > be put in the RA) is delivered in that same profile. [Ahmad] I am truly confused here. May be if you give a call flow or a step by step mechanism, I would be able to understand what you mean. >=20 > Don't you think this can work? Why not? {Ahmad] It is not clear to me what is the proposal yet to give a verdict here. > Why can the LMA=20 > send to MAG the home network prefix of the MN but not its=20 > current seqno? [Ahmad] This I understand, but the current RFC3775 mechanism is BROKEN and needs to be fixed.=20 We need to have a new option "Last Successful SQN" it currently does not exist. >=20 > Alex >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 10:18:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITefb-00043O-0Q; Fri, 07 Sep 2007 10:18:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITefZ-00043I-7M for netlmm@ietf.org; Fri, 07 Sep 2007 10:18:49 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITefY-0006Ef-JD for netlmm@ietf.org; Fri, 07 Sep 2007 10:18:49 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1189174727!5216974!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23773 invoked from network); 7 Sep 2007 14:18:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 7 Sep 2007 14:18:47 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l87EIkMa014760; Fri, 7 Sep 2007 07:18:46 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l87EIkn8026288; Fri, 7 Sep 2007 09:18:46 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l87EIiWe026199; Fri, 7 Sep 2007 09:18:44 -0500 (CDT) Message-ID: <46E15DBE.2090502@gmail.com> Date: Fri, 07 Sep 2007 16:18:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: [...] >>> My understudying that profile comes from a policy server or >> whatever. >>> The SQN is a per-MN dynamically always changing. In your response >>> please consider how the LMA will always update the profile with >>> the last SQN. >> Ahmad, when first the 'profile' is delivered by the 'policy server' >> or whatever to the MAG then the LMA inserts the current seqno in >> that profile. > > {Ahmad] I do not understand this sentence, can you elaborate. I > understand the portion of how the policy server may deliver the > profile to the MAG. (btw this is the part that _I_ don't understand can you please elaborate: how does the 'policy server' deliver the profile to MAG?). > Now, how the LMA then will insert the current SQN in that profile > which already in the hand of the MAG.? Am I missing something? In the same way that it sends the home prefix to the MAG. >> It is not necessary to insert every time, just the first time the >> MN authenticates. > > [Ahmad] What does this mean Alex. Are you assuming that there is no > re-registration possibility here? Once a seqno is sent to the MAG then MAG knows from where to send its increments. And yes, there is re-registration possible. Each time a MAG obtains a home prefix to send in RS to the MN it also obtains the current seqno that LMA keeps with respect to that MN. Both the home prefix and the seqno are managed on a per-MN basis. >> This is the same time when the home prefix (the one that has to be >> put in the RA) is delivered in that same profile. > > [Ahmad] I am truly confused here. May be if you give a call flow or a > step by step mechanism, I would be able to understand what you mean. HEre is topology and message exchange diagram, is this more clear? ---- ----- ----- | MN |----| MAG |----------| LMA | ---- ----- ----- | --------------- |'Policy Server'| --------------- MN MAG LMA 'Policy Server' | L2 trig | | | |-------->| 'Profile|Req' | | |----------o-------->| | | 'Profile|Ack' | | |<---------o---------|(Home Prefix and seqno) | | P-BU | | | |--------->| |(inc'ed seqno) | | P-BAck | | | RA |<---------| | |<------- | | | | | | | >> Don't you think this can work? Why not? > > {Ahmad] It is not clear to me what is the proposal yet to give a > verdict here. Please let me know how can I clarify more. >> Why can the LMA send to MAG the home network prefix of the MN but >> not its current seqno? > > [Ahmad] This I understand, but the current RFC3775 mechanism is > BROKEN and needs to be fixed. We need to have a new option "Last > Successful SQN" it currently does not exist. (Errr... so MIP6-3775 has an issue with the way it deals with sequence numbers, right? The issue is listed here: http://www.mip4.org/issues/tracker/mip6/issue101 In there you propose a solution: communicate the last valid seqno by HA to MN. Do you want to discuss that issue in MIP6 WG? It doesn't warrant the introduction of timestamps in P-MIPv6 IMHO.) Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 10:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITf0W-0000wi-1h; Fri, 07 Sep 2007 10:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITf0U-0000nj-F7 for netlmm@ietf.org; Fri, 07 Sep 2007 10:40:26 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITf0T-0002DF-6G for netlmm@ietf.org; Fri, 07 Sep 2007 10:40:26 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l87EeHw20555; Fri, 7 Sep 2007 14:40:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 09:40:15 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116990966@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E15DBE.2090502@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfxWgX8Sjar8cjZToiOWiou8hj8XgAAKhvw References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> <46E15DBE.2090502@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Cc: Sri Gundavelli; netlmm > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > [...] > >>> My understudying that profile comes from a policy server or > >> whatever. > >>> The SQN is a per-MN dynamically always changing. In your=20 > response =20 > >>> please consider how the LMA will always update the=20 > profile with the=20 > >>> last SQN. > >> Ahmad, when first the 'profile' is delivered by the 'policy server' > >> or whatever to the MAG then the LMA inserts the current seqno in=20 > >> that profile. > >=20 > > {Ahmad] I do not understand this sentence, can you elaborate. I=20 > > understand the portion of how the policy server may deliver the=20 > > profile to the MAG. >=20 > (btw this is the part that _I_ don't understand can you please > elaborate: how does the 'policy server' deliver the profile=20 > to MAG?). [Ahmad] There are more than one way for that delivery right. Offline Via AAA for example. Please see more below. >=20 > > Now, how the LMA then will insert the current SQN in that profile=20 > > which already in the hand of the MAG.? Am I missing something? >=20 > In the same way that it sends the home prefix to the MAG. [Ahmad] Ok, let us continue. >=20 > >> It is not necessary to insert every time, just the first=20 > time the MN=20 > >> authenticates. > >=20 > > [Ahmad] What does this mean Alex. Are you assuming that there is no=20 > > re-registration possibility here? >=20 > Once a seqno is sent to the MAG then MAG knows from where to=20 > send its increments. And yes, there is re-registration possible. >=20 > Each time a MAG obtains a home prefix to send in RS to the MN=20 > it also obtains the current seqno that LMA keeps with respect=20 > to that MN. >=20 > Both the home prefix and the seqno are managed on a per-MN basis. [Ahmad] You have the following assumptions here: 1. The delivery of the MN/User profile always goes through the LMA.=20 2. MAG always know what LMA the MN is attached to. I am not sure how this would happen without context transfer or during access authentication. 3. LMA is able to update the policy reply back to the MAG and inserts the last SQN used in the user profile or, 3.1. LMA always updates the policy server of the latest successful SQN for that user. Are those valid assumptions here or you have a problem with any? >=20 > >> This is the same time when the home prefix (the one that=20 > has to be =20 > >> put in the RA) is delivered in that same profile. > >=20 > > [Ahmad] I am truly confused here. May be if you give a call=20 > flow or a =20 > > step by step mechanism, I would be able to understand what you mean. >=20 > HEre is topology and message exchange diagram, is this more clear? >=20 >=20 > ---- ----- ----- > | MN |----| MAG |----------| LMA | > ---- ----- ----- > | > --------------- > |'Policy Server'| > --------------- >=20 >=20 > MN MAG LMA 'Policy Server' > | L2 trig | | | > |-------->| 'Profile|Req' | > | |----------o-------->| > | | 'Profile|Ack' | > | |<---------o---------|(Home Prefix and seqno) > | | P-BU | | > | |--------->| |(inc'ed seqno) > | | P-BAck | | > | RA |<---------| | > |<------- | | | > | | | | >=20 > >> Don't you think this can work? Why not? > >=20 > > {Ahmad] It is not clear to me what is the proposal yet to give a=20 > > verdict here. >=20 > Please let me know how can I clarify more. [Ahmad] Please see the assumptions listed above and let me know if you agree/disagree with any of them in order to comment further. >=20 > >> Why can the LMA send to MAG the home network prefix of the=20 > MN but not=20 > >> its current seqno? > >=20 > > [Ahmad] This I understand, but the current RFC3775=20 > mechanism is BROKEN=20 > > and needs to be fixed. We need to have a new option "Last=20 > Successful=20 > > SQN" it currently does not exist. >=20 > (Errr... so MIP6-3775 has an issue with the way it deals with sequence > numbers, right? The issue is listed here: > http://www.mip4.org/issues/tracker/mip6/issue101 >=20 > In there you propose a solution: communicate the last valid=20 > seqno by HA > to MN. >=20 > Do you want to discuss that issue in MIP6 WG? It doesn't=20 > warrant the > introduction of timestamps in P-MIPv6 IMHO.) [Ahmad] If we need to discuss this issue it must be on MIPv6 mailing list.=20 Second, I am not saying that the reason behind introducing timestamp. I never said that SQN can not be made to work. As a matter of fact that what the spec reflects. However, there are more than one way to make SQN works and that is beyond the scope of PMIPv6 base protocol spec. That's all here. However, I still believe that RFC3775 issue needs to be fixed. But that is a different animal. >=20 > Alex >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 10:54:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfES-0006J7-Ks; Fri, 07 Sep 2007 10:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfES-0006J2-6i for netlmm@ietf.org; Fri, 07 Sep 2007 10:54:52 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITfEQ-0002YL-VQ for netlmm@ietf.org; Fri, 07 Sep 2007 10:54:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l87Eskw23613; Fri, 7 Sep 2007 14:54:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 09:54:43 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371169909F3@zrc2hxm2.corp.nortel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAC2rfcA== References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" , "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Please see comments inline. Regards, Ahmad =20 > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Sri,=20 >=20 > > - We are NOT mandating the nodes in the domain to sync up=20 > to a clock=20 > > source. >=20 > Hmm, so far I assumed that the proposal is to mandate the=20 > MAGs to sync up to an external clock source such as NTP server. [Ahmad] May be the spec can specify if timestamp mechanism is used, then MAGs needs to sync up to an external clock source, e.g. NTP server. That should not be a problem, I think. >=20 > > Base draft does not support Context Transfers. Given that the draft=20 > > will be incomplete, if we dont mandate the support. By=20 > mandating the=20 > > support, the LMA can always return its timestamp and the=20 > MAG can use=20 > > that timestamp and register. This need to be done just once=20 > whenever=20 > > the LMA/MAG clocks are out of sync and just for one=20 > registration. One=20 > > extra round trip for the 1st registration between LMA/MAG pair. >=20 > So the proposal is to allow the use of the timestamp option=20 > in the absence of any external time synchronization like NTP=20 > and to mandate a mechanism to synchronize clocks between MAGs=20 > and LMA (and hence between all MAGs) using the timestamp=20 > option in PBU/PBA only (i.e., without utilizing NTP or an=20 > external clock source)? Is my understanding correct? [Ahmad] That is NOT my understanding here. The mandate is for the use of timestamp mechanism in ordering P-BU/P-BA. In case timestamp is used, the best approach is to have the MAGs synchronizes their timestamp via an external server, e.g. NTP. >=20 > If so, can you please give some more details how the LMA can=20 > detect that the clocks are out of sync? Is it based on a=20 > certain difference of timestamp in the received PBU and the=20 > current LMA's time?=20 [Ahmad] That is possible. Why not? >=20 > And how to differentiate the out of sync case from the=20 > out-of-order delivery case (i.e., a PBU is delayed and=20 > overtaken by another PBU from another MAG)? For instance, if=20 > the LMA receives a PBU with timestamp equal to "current time=20 > of LMA - X" and X > threshold, how does the LMA know whether=20 > the 1. the MAG clock is synchronized, but the PBU got delayed=20 > by X or 2. the PBU is not delayed, but the MAG's clock is out=20 > of sync by X? > Ideally, in case 1 the LMA should just ignore the PBU, in=20 > case 2 it should accept it and sync clocks. >=20 > If the idea is to always reject a PBU with X > threshold and=20 > include a current timestamp in the PBA, then I guess the same=20 > could be done with sequence numbers instead of timestamps, right? [Ahmad] No. They are not the same here. The possibility of the timestamp to go out of synch over the threshold every handoff registration does not exit. The MAG needs to track a global time delta per a peer LMA. MAG can update the global option every time a P-BA with code 135 arrives. On the other hand, in the absence of a mechanism to communicate the SQN, every handoff registration warrants a 2 round trip. Right? >=20 > BR, >=20 > Kilian >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 10:55:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfFK-0007ZI-0a; Fri, 07 Sep 2007 10:55:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfFI-0007ZC-R2 for netlmm@ietf.org; Fri, 07 Sep 2007 10:55:44 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ITfFH-0002Ze-Fg for netlmm@ietf.org; Fri, 07 Sep 2007 10:55:44 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1189176942!7440446!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 26748 invoked from network); 7 Sep 2007 14:55:42 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-4.tower-153.messagelabs.com with SMTP; 7 Sep 2007 14:55:42 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l87EtgeY012114; Fri, 7 Sep 2007 07:55:42 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l87EtfcC002333; Fri, 7 Sep 2007 09:55:41 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l87EtcxF002267; Fri, 7 Sep 2007 09:55:39 -0500 (CDT) Message-ID: <46E16664.1030708@gmail.com> Date: Fri, 07 Sep 2007 16:55:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> <46E15DBE.2090502@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990966@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116990966@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: >> Cc: Sri Gundavelli; netlmm >> Subject: Re: [netlmm] timestamp vs seqno redux >> >> Ahmad Muhanna wrote: >> [...] >>>>> My understudying that profile comes from a policy server or >>>> whatever. >>>>> The SQN is a per-MN dynamically always changing. In your >> response >>>>> please consider how the LMA will always update the >> profile with the >>>>> last SQN. >>>> Ahmad, when first the 'profile' is delivered by the 'policy server' >>>> or whatever to the MAG then the LMA inserts the current seqno in >>>> that profile. >>> {Ahmad] I do not understand this sentence, can you elaborate. I >>> understand the portion of how the policy server may deliver the >>> profile to the MAG. >> (btw this is the part that _I_ don't understand can you please >> elaborate: how does the 'policy server' deliver the profile >> to MAG?). > > [Ahmad] > There are more than one way for that delivery right. Offline Via AAA for > example. Please see more below. > >>> Now, how the LMA then will insert the current SQN in that profile >>> which already in the hand of the MAG.? Am I missing something? >> In the same way that it sends the home prefix to the MAG. > > [Ahmad] > Ok, let us continue. >>>> It is not necessary to insert every time, just the first >> time the MN >>>> authenticates. >>> [Ahmad] What does this mean Alex. Are you assuming that there is no >>> re-registration possibility here? >> Once a seqno is sent to the MAG then MAG knows from where to >> send its increments. And yes, there is re-registration possible. >> >> Each time a MAG obtains a home prefix to send in RS to the MN >> it also obtains the current seqno that LMA keeps with respect >> to that MN. >> >> Both the home prefix and the seqno are managed on a per-MN basis. > > [Ahmad] > You have the following assumptions here: > > 1. The delivery of the MN/User profile always goes through the LMA. I'm talking about the home network prefix of the MN. That will always go through LMA, because LMA is in charge, topologically correct, of that prefix. You can't have any other entity to send the home prefix of MN to MN without letting LMA know about that. > 2. MAG always know what LMA the MN is attached to. I am not sure how > this would happen without context transfer or during access > authentication. I don't know either. How do you assume the current P-MIPv6 MAG to send the P-BU to what LMA? > 3. LMA is able to update the policy reply back to the MAG and inserts > the last SQN used in the user profile or, Right, I assumed that. > 3.1. LMA always updates the policy server of the latest successful SQN > for that user. I didn't assume that. The LMA maintains that seqno and it doesn't communicate it to anybody else but to MAG. If you want to have the 'policy server' to maintain the home network prefix of each MN then this server has to work in synch with the HA somehow. Because a 'policy server' can not be in charge of any prefix. > Are those valid assumptions here or you have a problem with any? I think I don't have any problem with any. > > >>>> This is the same time when the home prefix (the one that >> has to be >>>> put in the RA) is delivered in that same profile. >>> [Ahmad] I am truly confused here. May be if you give a call >> flow or a >>> step by step mechanism, I would be able to understand what you mean. >> HEre is topology and message exchange diagram, is this more clear? >> >> >> ---- ----- ----- >> | MN |----| MAG |----------| LMA | >> ---- ----- ----- >> | >> --------------- >> |'Policy Server'| >> --------------- >> >> >> MN MAG LMA 'Policy Server' >> | L2 trig | | | >> |-------->| 'Profile|Req' | >> | |----------o-------->| >> | | 'Profile|Ack' | >> | |<---------o---------|(Home Prefix and seqno) >> | | P-BU | | >> | |--------->| |(inc'ed seqno) >> | | P-BAck | | >> | RA |<---------| | >> |<------- | | | >> | | | | >> >>>> Don't you think this can work? Why not? >>> {Ahmad] It is not clear to me what is the proposal yet to give a >>> verdict here. >> Please let me know how can I clarify more. > > [Ahmad] > Please see the assumptions listed above and let me know if you > agree/disagree with any of them in order to comment further. >>>> Why can the LMA send to MAG the home network prefix of the >> MN but not >>>> its current seqno? >>> [Ahmad] This I understand, but the current RFC3775 >> mechanism is BROKEN >>> and needs to be fixed. We need to have a new option "Last >> Successful >>> SQN" it currently does not exist. >> (Errr... so MIP6-3775 has an issue with the way it deals with sequence >> numbers, right? The issue is listed here: >> http://www.mip4.org/issues/tracker/mip6/issue101 >> >> In there you propose a solution: communicate the last valid >> seqno by HA >> to MN. >> >> Do you want to discuss that issue in MIP6 WG? It doesn't >> warrant the >> introduction of timestamps in P-MIPv6 IMHO.) > > [Ahmad] > If we need to discuss this issue it must be on MIPv6 mailing list. > Second, I am not saying that the reason behind introducing timestamp. I > never said that SQN can not be made to work. As a matter of fact that > what the spec reflects. However, there are more than one way to make SQN > works and that is beyond the scope of PMIPv6 base protocol spec. > > That's all here. However, I still believe that RFC3775 issue needs to be > fixed. But that is a different animal. Ok, so let's discuss the 3775isssue of seqnos in MIP6. And discuss here how seqnos can work ok with P-MIPv6. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 11:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITflm-000600-Mm; Fri, 07 Sep 2007 11:29:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITflk-0005o3-MC for netlmm@ietf.org; Fri, 07 Sep 2007 11:29:16 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITflj-0003N3-E1 for netlmm@ietf.org; Fri, 07 Sep 2007 11:29:16 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l87FTBw14813; Fri, 7 Sep 2007 15:29:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 10:28:51 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116990B40@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E16664.1030708@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfxXy35QxSzWKQ+QLu2fqTSLxFCeAAAEZtQ References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> <46E15DBE.2090502@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990966@zrc2hxm2.corp.nortel.com> <46E16664.1030708@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > >=20 > > [Ahmad] > > You have the following assumptions here: > >=20 > > 1. The delivery of the MN/User profile always goes through the LMA.=20 >=20 > I'm talking about the home network prefix of the MN. That=20 > will always go through LMA, because LMA is in charge,=20 > topologically correct, of that prefix. You can't have any=20 > other entity to send the home prefix of MN to MN without=20 > letting LMA know about that. [Ahmad] Alex, I understand that LMA in charge of the maintenance of its network topology, whatever, you would like to call it. Including the HNP. Okay. Let us focus here on the HNP first and SQN becomes redundant. Now, It seems we have different opinions on how the HNP is communicated back to the MAG. somehow you believe that the HNP will always be communicated back to the MAG via LMA. I have a problem with this assumption, as follows: My understanding is that there are two options that have been discussed: 1. MAG receive the HNP before establishing P-MIP session, i.e. before sending P-BU/P-BA. 1.1. In this mechanism it does not make any sense for this mechanism to be done through the LMA. 1.2. MAG request the profile from the Policy server which maintains the HNP of the user. I do not think this a huge issue here and it can be done, is that the best option, that is a different discussion. 1.3. Policy server delivers the user profile (Assuming that the LMA and Policy server are in sync) In other words, yes, LMA supports the HNP configured in the policy server and it is available. 1.4. When the MAG receives the user profile from the policy server, MAG finds the following information:=20 1.4.1. User NAI=20 1.4.2. LMA IP address 1.4.3. IP address Configuration Optionally: 1.4.4. HNP (this was made optional because there is another mechanism which I will list in a second) 1.5. After the MAG receives the user profile, MAG sends a P-BU to the LMA and include the HNP. ** Optionally MAG may start advertising the HNP to the MN via RA or wait after successful P-BA arrives ** 1.6. LMA send a successful P-BA only if the HNP is correct and all other stuff. 1.7. MAG receives P-BA and user is registered. In this scenario, tell me where the LMA can update the user profile by the last successful SQN. It is only possible if the LMA always goes back to the Policy Server and update the policy server with the last successful SQN per-MN. I guess that probably a killing! 2. MAG receive the HNP in the P-BA after inserting an All-ZERO in the HNP/HoA option in the P-BU: This mechanism is exactly the same as per option 1 until (1.3) for this one let us say 2.3. 2.4. MAG will receive the profile BUT there is no HNP. 2.5. After the MAG receives the user profile, MAG sends a P-BU to the LMA and include an all-ZEROS in the HNP option. 2.6. LMA send a successful P-BA with a valid HNP/HoA IP address if all other validations are correct. 2.7. MAG receives P-BA and ONLY then advertise the HNP to the MN. NOW: In this scenario, tell me where the LMA can update the user profile by the last successful per-MN SQN.=20 >=20 > > 2. MAG always know what LMA the MN is attached to. I am not=20 > sure how=20 > > this would happen without context transfer or during access=20 > > authentication. >=20 > I don't know either. How do you assume the current P-MIPv6=20 > MAG to send the P-BU to what LMA? [Ahmad] Please see above. It is only arrives after the MAG already consulted the policy server. >=20 > > 3. LMA is able to update the policy reply back to the MAG=20 > and inserts=20 > > the last SQN used in the user profile or, >=20 > Right, I assumed that. >=20 > > 3.1. LMA always updates the policy server of the latest=20 > successful SQN=20 > > for that user. >=20 > I didn't assume that. [Ahmad] Please check above and tell me how your proposal would work without this assumption. >=20 > The LMA maintains that seqno and it doesn't communicate it to=20 > anybody else but to MAG. How? In P-BA, it is too late and that is what is called 2 round trips. Right? >=20 > If you want to have the 'policy server' to maintain the home=20 > network prefix of each MN then this server has to work in=20 > synch with the HA somehow. [Ahmad] That is not my option but that is one of the options that is already documented in the spec. I assume that is also a valid assumption. >=20 > Because a 'policy server' can not be in charge of any prefix. [Ahmad] I am not sure why, but that is irrelevant here. >=20 > > Are those valid assumptions here or you have a problem with any? >=20 > I think I don't have any problem with any. [Ahmad] Actually you had a problem with one which is part of 3.1. Please see comments above. > >=20 > >=20 > >>>> This is the same time when the home prefix (the one that > >> has to be > >>>> put in the RA) is delivered in that same profile. > >>> [Ahmad] I am truly confused here. May be if you give a call > >> flow or a > >>> step by step mechanism, I would be able to understand=20 > what you mean. > >> HEre is topology and message exchange diagram, is this more clear? > >> > >> > >> ---- ----- ----- > >> | MN |----| MAG |----------| LMA | > >> ---- ----- ----- > >> | > >> --------------- > >> |'Policy Server'| > >> --------------- > >> > >> > >> MN MAG LMA 'Policy Server' > >> | L2 trig | | | > >> |-------->| 'Profile|Req' | > >> | |----------o-------->| > >> | | 'Profile|Ack' | > >> | |<---------o---------|(Home Prefix and seqno) > >> | | P-BU | | > >> | |--------->| |(inc'ed seqno) > >> | | P-BAck | | > >> | RA |<---------| | > >> |<------- | | | > >> | | | | > >> > >>>> Don't you think this can work? Why not? > >>> {Ahmad] It is not clear to me what is the proposal yet to give a=20 > >>> verdict here. > >> Please let me know how can I clarify more. > >=20 > > [Ahmad] > > Please see the assumptions listed above and let me know if you=20 > > agree/disagree with any of them in order to comment further. > >>>> Why can the LMA send to MAG the home network prefix of the > >> MN but not > >>>> its current seqno? > >>> [Ahmad] This I understand, but the current RFC3775 > >> mechanism is BROKEN > >>> and needs to be fixed. We need to have a new option "Last > >> Successful > >>> SQN" it currently does not exist. > >> (Errr... so MIP6-3775 has an issue with the way it deals=20 > with sequence > >> numbers, right? The issue is listed here: > >> http://www.mip4.org/issues/tracker/mip6/issue101 > >> > >> In there you propose a solution: communicate the last=20 > valid seqno=20 > >> by HA > >> to MN. > >> > >> Do you want to discuss that issue in MIP6 WG? It=20 > doesn't warrant=20 > >> the > >> introduction of timestamps in P-MIPv6 IMHO.) > >=20 > > [Ahmad] > > If we need to discuss this issue it must be on MIPv6 mailing list.=20 > > Second, I am not saying that the reason behind introducing=20 > timestamp.=20 > > I never said that SQN can not be made to work. As a matter of fact=20 > > that what the spec reflects. However, there are more than=20 > one way to=20 > > make SQN works and that is beyond the scope of PMIPv6 base=20 > protocol spec. > >=20 > > That's all here. However, I still believe that RFC3775=20 > issue needs to=20 > > be fixed. But that is a different animal. >=20 > Ok, so let's discuss the 3775isssue of seqnos in MIP6. [Ahmad] Agreed. >=20 > And discuss here how seqnos can work ok with P-MIPv6. [Ahmad] Agreed. >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 11:55:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgB1-0005s5-4y; Fri, 07 Sep 2007 11:55:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgAz-0005s0-OP for netlmm@ietf.org; Fri, 07 Sep 2007 11:55:21 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITgAy-0000CH-M1 for netlmm@ietf.org; Fri, 07 Sep 2007 11:55:21 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1189180519!26081464!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 24473 invoked from network); 7 Sep 2007 15:55:19 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-12.tower-119.messagelabs.com with SMTP; 7 Sep 2007 15:55:19 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l87FtJWe021237; Fri, 7 Sep 2007 08:55:19 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l87FtI8i018848; Fri, 7 Sep 2007 10:55:18 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l87FtFgg018741; Fri, 7 Sep 2007 10:55:16 -0500 (CDT) Message-ID: <46E1745D.5010402@gmail.com> Date: Fri, 07 Sep 2007 17:55:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> <46E15DBE.2090502@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990966@zrc2hxm2.corp.nortel.com> <46E16664.1030708@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990B40@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116990B40@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: >>> [Ahmad] You have the following assumptions here: >>> >>> 1. The delivery of the MN/User profile always goes through the >>> LMA. >> I'm talking about the home network prefix of the MN. That will >> always go through LMA, because LMA is in charge, topologically >> correct, of that prefix. You can't have any other entity to send >> the home prefix of MN to MN without letting LMA know about that. > > [Ahmad] Alex, > > I understand that LMA in charge of the maintenance of its network > topology, whatever, you would like to call it. Including the HNP. > Okay. > > Let us focus here on the HNP first and SQN becomes redundant. Now, It > seems we have different opinions on how the HNP is communicated back > to the MAG. > > somehow you believe that the HNP will always be communicated back to > the MAG via LMA. I have a problem with this assumption, as follows: > > My understanding is that there are two options that have been > discussed: > > 1. MAG receive the HNP before establishing P-MIP session, i.e. before > sending P-BU/P-BA. Right... that's what I've assumed. > 1.1. In this mechanism it does not make any sense for this mechanism > to be done through the LMA. 1.2. MAG request the profile from the > Policy server which maintains the HNP of the user. I do not think > this a huge issue here and it can be done, is that the best option, > that is a different discussion. How? Which protocol? > 1.3. Policy server delivers the user profile (Assuming that the LMA > and Policy server are in sync) In other words, yes, LMA supports the > HNP configured in the policy server and it is available. 1.4. When > the MAG receives the user profile from the policy server, MAG finds > the following information: 1.4.1. User NAI 1.4.2. LMA IP address > 1.4.3. IP address Configuration How does the 'policy server' know the IP address configuration of MN? It's the LMA who communicated it to 'policy server', right? > Optionally: 1.4.4. HNP (this was made optional because there is > another mechanism which I will list in a second) > > 1.5. After the MAG receives the user profile, MAG sends a P-BU to the > LMA and include the HNP. > > ** Optionally MAG may start advertising the HNP to the MN via RA or > wait after successful P-BA arrives ** 1.6. LMA send a successful P-BA > only if the HNP is correct and all other stuff. 1.7. MAG receives > P-BA and user is registered. > > In this scenario, tell me where the LMA can update the user profile > by the last successful SQN. In step 1.4.3: how does the 'policy server' know the 'IP address configuration' to send to MAG? The only way it could know it is to learn it from LMA. At that learning point the LMA sends the last successful seqno as well. > It is only possible if the LMA always goes back to the Policy Server > and update the policy server with the last successful SQN per-MN. I > guess that probably a killing! We can have the 'policy server' to always request the LMA before sending IP address information to MAG. This happens only at first MN attaching to MAG. If you talk about overkill, I think the whole reliance on a 'policy server' is overkill. > 2. MAG receive the HNP in the P-BA after inserting an All-ZERO in the > HNP/HoA option in the P-BU: This mechanism is exactly the same as > per option 1 until (1.3) for this one let us say 2.3. Right... in this case, in addition to HNP All-ZERO, the MAG will put a seqno equal All-ZERO and the LMA will reply back the current seqno. > 2.4. MAG will receive the profile BUT there is no HNP. 2.5. After the > MAG receives the user profile, MAG sends a P-BU to the LMA and > include an all-ZEROS in the HNP option. 2.6. LMA send a successful > P-BA with a valid HNP/HoA IP address if all other validations are > correct. 2.7. MAG receives P-BA and ONLY then advertise the HNP to > the MN. > > NOW: In this scenario, tell me where the LMA can update the user > profile by the last successful per-MN SQN. In this last scenario 2, you don't have a 'policy server', so only the LMA is involved. The 'policy profiler machine' will not update the user profile. Could you please picture a message exchange with what you think the first steps are and then I'll paste into these first steps where the seqno fits. >> The LMA maintains that seqno and it doesn't communicate it to >> anybody else but to MAG. > > How? In P-BA, it is too late and that is what is called 2 round > trips. Right? Well, if you put 00 instead of a home address in the P-BU then you can put a 00 in the place of the seqno as well. There will only be one pbu/pback initially. The LMA will just not increment its seqno when it receives a seqno 00. The LMA can not receive two P-BUs with seqno 00 from two different MAGs. BEcause MAG can not be attached to two MAGs simultaneously. Alex >> If you want to have the 'policy server' to maintain the home >> network prefix of each MN then this server has to work in synch >> with the HA somehow. > [Ahmad] That is not my option but that is one of the options that is > already documented in the spec. I assume that is also a valid > assumption. > >> Because a 'policy server' can not be in charge of any prefix. > > [Ahmad] I am not sure why, but that is irrelevant here. > >>> Are those valid assumptions here or you have a problem with any? >> I think I don't have any problem with any. > > [Ahmad] Actually you had a problem with one which is part of 3.1. > Please see comments above. > >>> >>>>>> This is the same time when the home prefix (the one that >>>> has to be >>>>>> put in the RA) is delivered in that same profile. >>>>> [Ahmad] I am truly confused here. May be if you give a call >>>> flow or a >>>>> step by step mechanism, I would be able to understand >> what you mean. >>>> HEre is topology and message exchange diagram, is this more >>>> clear? >>>> >>>> >>>> ---- ----- ----- | MN |----| MAG |----------| >>>> LMA | ---- ----- ----- | --------------- >>>> |'Policy Server'| --------------- >>>> >>>> >>>> MN MAG LMA 'Policy Server' | L2 trig | >>>> | | |-------->| 'Profile|Req' | | >>>> |----------o-------->| | | 'Profile|Ack' | | >>>> |<---------o---------|(Home Prefix and seqno) | | >>>> P-BU | | | |--------->| |(inc'ed >>>> seqno) | | P-BAck | | | RA |<---------| >>>> | |<------- | | | | | | >>>> | >>>> >>>>>> Don't you think this can work? Why not? >>>>> {Ahmad] It is not clear to me what is the proposal yet to >>>>> give a verdict here. >>>> Please let me know how can I clarify more. >>> [Ahmad] Please see the assumptions listed above and let me know >>> if you agree/disagree with any of them in order to comment >>> further. >>>>>> Why can the LMA send to MAG the home network prefix of the >>>> MN but not >>>>>> its current seqno? >>>>> [Ahmad] This I understand, but the current RFC3775 >>>> mechanism is BROKEN >>>>> and needs to be fixed. We need to have a new option "Last >>>> Successful >>>>> SQN" it currently does not exist. >>>> (Errr... so MIP6-3775 has an issue with the way it deals >> with sequence >>>> numbers, right? The issue is listed here: >>>> http://www.mip4.org/issues/tracker/mip6/issue101 >>>> >>>> In there you propose a solution: communicate the last >> valid seqno >>>> by HA to MN. >>>> >>>> Do you want to discuss that issue in MIP6 WG? It >> doesn't warrant >>>> the introduction of timestamps in P-MIPv6 IMHO.) >>> [Ahmad] If we need to discuss this issue it must be on MIPv6 >>> mailing list. Second, I am not saying that the reason behind >>> introducing >> timestamp. >>> I never said that SQN can not be made to work. As a matter of >>> fact that what the spec reflects. However, there are more than >> one way to >>> make SQN works and that is beyond the scope of PMIPv6 base >> protocol spec. >>> That's all here. However, I still believe that RFC3775 >> issue needs to >>> be fixed. But that is a different animal. >> Ok, so let's discuss the 3775isssue of seqnos in MIP6. > > [Ahmad] Agreed. >> And discuss here how seqnos can work ok with P-MIPv6. > [Ahmad] Agreed. > >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 12:30:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgiq-0005M3-Pf; Fri, 07 Sep 2007 12:30:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgip-0005Hd-Ay for netlmm@ietf.org; Fri, 07 Sep 2007 12:30:19 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITgio-0001Lj-Gp for netlmm@ietf.org; Fri, 07 Sep 2007 12:30:19 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l87GUE400080; Fri, 7 Sep 2007 16:30:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 11:30:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116990D8B@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E1745D.5010402@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfxZ4G42us3BzQrQQq0dsBMPKSuuwAAM5Bw References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> <46E15DBE.2090502@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990966@zrc2hxm2.corp.nortel.com> <46E16664.1030708@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990B40@zrc2hxm2.corp.nortel.com> <46E1745D.5010402@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, Please see comments inline. Regards, Ahmad >=20 > Ahmad Muhanna wrote: > >>> [Ahmad] You have the following assumptions here: > >>>=20 > >>> 1. The delivery of the MN/User profile always goes=20 > through the LMA. > >> I'm talking about the home network prefix of the MN. That will=20 > >> always go through LMA, because LMA is in charge, topologically=20 > >> correct, of that prefix. You can't have any other entity=20 > to send the=20 > >> home prefix of MN to MN without letting LMA know about that. > >=20 > > [Ahmad] Alex, > >=20 > > I understand that LMA in charge of the maintenance of its network=20 > > topology, whatever, you would like to call it. Including the HNP. > > Okay. > >=20 > > Let us focus here on the HNP first and SQN becomes=20 > redundant. Now, It=20 > > seems we have different opinions on how the HNP is=20 > communicated back=20 > > to the MAG. > >=20 > > somehow you believe that the HNP will always be=20 > communicated back to=20 > > the MAG via LMA. I have a problem with this assumption, as follows: > >=20 > > My understanding is that there are two options that have been > > discussed: > >=20 > > 1. MAG receive the HNP before establishing P-MIP session,=20 > i.e. before =20 > > sending P-BU/P-BA. >=20 > Right... that's what I've assumed. [Ahmad] But how that can be done through the LMA before exchanging P-BU/P-BA? >=20 > > 1.1. In this mechanism it does not make any sense for this=20 > mechanism=20 > > to be done through the LMA. 1.2. MAG request the profile from the=20 > > Policy server which maintains the HNP of the user. I do not=20 > think this=20 > > a huge issue here and it can be done, is that the best=20 > option, that is=20 > > a different discussion. >=20 > How? Which protocol? >=20 > > 1.3. Policy server delivers the user profile (Assuming that the LMA=20 > > and Policy server are in sync) In other words, yes, LMA=20 > supports the=20 > > HNP configured in the policy server and it is available.=20 > 1.4. When the=20 > > MAG receives the user profile from the policy server, MAG finds the=20 > > following information: 1.4.1. User NAI 1.4.2. LMA IP=20 > address 1.4.3. IP=20 > > address Configuration >=20 > How does the 'policy server' know the IP address configuration of MN? > It's the LMA who communicated it to 'policy server', right? [Ahmad] Alex,=20 we are not talking about the MN IP address, it is the whole HNP.=20 Regardless. Now, how the Policy server know which HNP is out-of-scope of this discussion and the PMIPv6 spec. >=20 > > Optionally: 1.4.4. HNP (this was made optional because there is=20 > > another mechanism which I will list in a second) > >=20 > > 1.5. After the MAG receives the user profile, MAG sends a=20 > P-BU to the =20 > > LMA and include the HNP. > >=20 > > ** Optionally MAG may start advertising the HNP to the MN=20 > via RA or=20 > > wait after successful P-BA arrives ** 1.6. LMA send a=20 > successful P-BA=20 > > only if the HNP is correct and all other stuff. 1.7. MAG=20 > receives P-BA=20 > > and user is registered. > >=20 > > In this scenario, tell me where the LMA can update the user=20 > profile by=20 > > the last successful SQN. >=20 > In step 1.4.3: how does the 'policy server' know the 'IP=20 > address configuration' to send to MAG? The only way it could=20 > know it is to learn it from LMA. At that learning point the=20 > LMA sends the last successful seqno as well. {Ahmad] Step 1.4.3. Is not a step in the call flow, I am just listing what are the things saved in the user profile! How to get these information into the user profile can be achieved via many other ways and out-of-scope here and irrelevant. If you think that is done dynamically by the LMA while establishing a PMIP session for the user, I can tell you that is NOT correct. IMO. >=20 >=20 > > It is only possible if the LMA always goes back to the=20 > Policy Server=20 > > and update the policy server with the last successful SQN per-MN. I=20 > > guess that probably a killing! >=20 > We can have the 'policy server' to always request the LMA=20 > before sending IP address information to MAG. This happens=20 > only at first MN attaching to MAG. {Ahmad] No problem, you can suggest whatever you want, however, that is out-of-scope of the PMIP spec. IMO, it is not the best option! >=20 > If you talk about overkill, I think the whole reliance on a=20 > 'policy server' is overkill. [Ahmad] May be. However, to dynamically update the policy server with the latest SQN in order to solve your issue here is not an overkill, it is a little more:-) >=20 > > 2. MAG receive the HNP in the P-BA after inserting an=20 > All-ZERO in the =20 > > HNP/HoA option in the P-BU: This mechanism is exactly the=20 > same as per=20 > > option 1 until (1.3) for this one let us say 2.3. >=20 > Right... in this case, in addition to HNP All-ZERO, the MAG=20 > will put a seqno equal All-ZERO and the LMA will reply back=20 > the current seqno. [Ahmad] Good suggestion, Do you expect the LMA to send a successful P-BA or a P-BA with code 135? 1. If you expect LMA to send 135 and the latest SQN, that is 2 round trip! 2. If you expects the LMA to accept the P-BU and sends a successful P-BA with latest SQN, that is a horrible thing. The least to say. 3. Also, you are creating a problem in matching the P-BA with the outstanding P-BU for nothing. >=20 > > 2.4. MAG will receive the profile BUT there is no HNP. 2.5.=20 > After the=20 > > MAG receives the user profile, MAG sends a P-BU to the LMA=20 > and include=20 > > an all-ZEROS in the HNP option. 2.6. LMA send a successful=20 > P-BA with a=20 > > valid HNP/HoA IP address if all other validations are correct. 2.7.=20 > > MAG receives P-BA and ONLY then advertise the HNP to the MN. > >=20 > > NOW: In this scenario, tell me where the LMA can update the user=20 > > profile by the last successful per-MN SQN. >=20 > In this last scenario 2, you don't have a 'policy server', so=20 > only the LMA is involved. The 'policy profiler machine' will=20 > not update the user profile. [Ahmad] Alex, Please go back and read it one more time. >=20 > Could you please picture a message exchange with what you=20 > think the first steps are and then I'll paste into these=20 > first steps where the seqno fits. >=20 [Ahmad] Sincerely, I do not have the time to do it and I apologize for not being able to deliver on your request. > >> The LMA maintains that seqno and it doesn't communicate it=20 > to anybody=20 > >> else but to MAG. > >=20 > > How? In P-BA, it is too late and that is what is called 2=20 > round trips.=20 > > Right? >=20 > Well, if you put 00 instead of a home address in the P-BU=20 > then you can put a 00 in the place of the seqno as well. =20 > There will only be one pbu/pback initially. The LMA will=20 > just not increment its seqno when it receives a seqno 00. >=20 > The LMA can not receive two P-BUs with seqno 00 from two=20 > different MAGs.=20 > BEcause MAG can not be attached to two MAGs simultaneously. [Ahmad] Please see comments above. >=20 > Alex >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 12:48:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITh0F-0006Ep-C1; Fri, 07 Sep 2007 12:48:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITh0D-0006Ei-W5 for netlmm@ietf.org; Fri, 07 Sep 2007 12:48:18 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITh0D-0001pJ-CR for netlmm@ietf.org; Fri, 07 Sep 2007 12:48:17 -0400 X-IronPort-AV: E=Sophos;i="4.20,221,1186383600"; d="scan'208";a="521610670" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 07 Sep 2007 09:47:52 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l87Glpfp014827; Fri, 7 Sep 2007 09:47:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l87Gll7T014825; Fri, 7 Sep 2007 16:47:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 09:47:48 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 09:47:48 -0700 From: "Sri Gundavelli" To: "'Kilian Weniger'" References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 09:47:47 -0700 Message-ID: <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewA== X-OriginalArrivalTime: 07 Sep 2007 16:47:48.0269 (UTC) FILETIME=[D2715DD0:01C7F16E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3188; t=1189183672; x=1190047672; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20timestamp=20vs=20seqno=20redux |Sender:=20; bh=xekLJ1Q0aIt+n8AddYzoo0S8nwBBjCxjpJYMzQ0DDQ4=; b=S+WvZH6ubzEGSCjED+HpsE57KO6D8OpTK+AnMi40gGi+iXco0/6QwEJ8G6/0RCeAgOSJseRc sb9natrMDXPbYm2iZq3HRxJefGhfIBGBa9T+GCdC09lPgyOByz3RFzxzj326xPT2gAiUfYZNAJ zc3RqOCJkkb2ps2WSCy8gnXNU=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: Friday, September 07, 2007 2:09 AM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux > > Hi Sri, > > > - We are NOT mandating the nodes in the domain to sync up to > > a clock source. > > Hmm, so far I assumed that the proposal is to mandate the MAGs to sync > up to an external clock source such as NTP server. > For the timestamp option to work, we RECOMMEND the use of NTP for synchronizing the clocks in the domain. However, we do not want to mandate on a specific mechanism. > > Base draft does not support Context Transfers. Given that the draft > > will be incomplete, if we dont mandate the support. By mandating > > the support, the LMA can always return its timestamp and the MAG > > can use that timestamp and register. This need to be done just > > once whenever the LMA/MAG clocks are out of sync and just for one > > registration. One extra round trip for the 1st registration between > > LMA/MAG pair. > > So the proposal is to allow the use of the timestamp option in the > absence of any external time synchronization like NTP and to mandate a > mechanism to synchronize clocks between MAGs and LMA (and > hence between > all MAGs) using the timestamp option in PBU/PBA only (i.e., without > utilizing NTP or an external clock source)? Is my > understanding correct? > No. For this to work, we require the clocks to be in sync. How its achieved, it could be based on NTP or some other protocols. But, why should we mandate this. > If so, can you please give some more details how the LMA can > detect that > the clocks are out of sync? Is it based on a certain difference of > timestamp in the received PBU and the current LMA's time? > > And how to differentiate the out of sync case from the out-of-order > delivery case (i.e., a PBU is delayed and overtaken by > another PBU from > another MAG)? For instance, if the LMA receives a PBU with timestamp > equal to "current time of LMA - X" and X > threshold, how does the LMA > know whether the > 1. the MAG clock is synchronized, but the PBU got delayed by X or > 2. the PBU is not delayed, but the MAG's clock is out of sync by X? > Ideally, in case 1 the LMA should just ignore the PBU, in case 2 it > should accept it and sync clocks. > > If the idea is to always reject a PBU with X > threshold and include a > current timestamp in the PBA, then I guess the same could be done with > sequence numbers instead of timestamps, right? > For what ever reasons if the LMA and MAG clocks are out of sync, the LMA can return its timestamp and the MAG can always apply that delta in all the registration it sends. This is done just once, when ever the clocks are off. But, with seq number scheme, this needs to be done for each MN registration. Its as per the 3775 per MN seq number. Sri > BR, > > Kilian > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 13:01:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IThDT-00012P-Ih; Fri, 07 Sep 2007 13:01:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IThDR-00012J-Tw for netlmm@ietf.org; Fri, 07 Sep 2007 13:01:57 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IThDQ-00068S-Dr for netlmm@ietf.org; Fri, 07 Sep 2007 13:01:57 -0400 X-IronPort-AV: E=Sophos;i="4.20,221,1186383600"; d="scan'208";a="521615898" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Sep 2007 10:01:56 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l87H1tU3007057; Fri, 7 Sep 2007 10:01:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l87H1Zxh009817; Fri, 7 Sep 2007 17:01:55 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 10:01:51 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 10:01:50 -0700 From: "Sri Gundavelli" To: "'DE JUAN HUARTE FEDERICO'" References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A5013999EA@FRVELSMBS12.ad2.ad.alcatel.com> Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 10:01:50 -0700 Message-ID: <010701c7f170$c8863be0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A5013999EA@FRVELSMBS12.ad2.ad.alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABfNwGAAE6an0A== X-OriginalArrivalTime: 07 Sep 2007 17:01:50.0665 (UTC) FILETIME=[C88CCB90:01C7F170] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12155; t=1189184515; x=1190048515; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20timestamp=20vs=20seqno=20redux |Sender:=20; bh=SOgDBL5Pb9iJ8dVlnJ5InXIIX10hSx5t6Ul5zC35WHo=; b=WgEzFKnvCtjk5mCmEAGLOYKIuje/q9Txjjm9g8OoaiA58riRV3r9jjm9vS7U3U4Y603pfo6r drNuLAgjrLw/e3PLN26t1CqXIpKWAaLLL0Zyf+nhrPMpWcYA7Jy8wG7G; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, =20 Please see inline .. > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Friday, September 07, 2007 2:04 AM > To: Sri Gundavelli > Cc: netlmm > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Sri, >=20 > I haven't had time to catch up yet with the new draft, so I=20 > apologize if any of my comments below has already been addresed >=20 > Sri> ... what are we mandating? The ability for the LMA to=20 > generate a Timestamp and return the timestamp option ... > I'm trying to understand the motivation for this mandate >=20 > I understand the need in the LMA to identify the sequence of=20 > BUs in order to avoid race conditions when more than one MAG=20 > can send a BU for the same user > The minimum requirement from LMA point of view is that the ID=20 > carried in the BU represents a free-running counter that=20 > increases monotonically > It follows that the requirement for the MAGs is to=20 > synchronize the values used in the BU-ID > Let me stress that these "minimum requirements" are only for=20 > synchronization between MAGs, i.e. not including LMA >=20 > Timestamps is a valid solution for filling in the ID when=20 > there's time synchronization (with sufficient accuracy) between MAGs > Let me stress that the precondition for using timestamps=20 > should only be synchronization between MAGs, i.e. not including LMA > By including LMA in the equation, it seems that we're trying=20 > to correct deviations in the time synchronization of MAGs via PMIP > That is, the LMA becomes some kind of synch Master. Honestly,=20 > I don't think it is right to extend PMIP scope in such way >=20 No, that is not true. We are not trying to sync clocks using PMIP. Allowing LMA to return its own timestamp, essentially establishes one node in that domain to dictate some order, in the absence of NTP snchronization. In a network with multiple nodes, we need a global scale such as a timestamp. We either depend on NTP to synchronize all the clocks in the node or let LMA always returns its timestamp, so as for the MAG to use that timestamp (delta) in the subsequent requests. Otherwise, every MAG in the network may be sending different timestamps and the LMA would not know, which one to accept. > Let me cite your answers to Alper (from another email): > Sri> ... It is important to highlight the fact that we need=20 > this entire synchronization logic to avoid one scenario,=20 > where the LMA ends up processing a PBU that was sent by pMAG=20 > and the LMA received that much later due to network out of=20 > order deliverly ... > [FDJ] This problem statement seems wrong. Unordered delivery=20 > because of nw congestion does not make any difference > What matters is the relationship between the ID sent by the=20 > pMAG and the one sent by the nMAG > The only requirement that we can make is that pMAG and nMAG=20 > must synchronize this ID > There's no way the LMA can't tell in which order these 2 BUus=20 > were sent if the IDs are not-synchronized >=20 It does. The race condition would not be an issue, if LMA=20 receives packets in the order in which they were generated by different MAG's. The LMA may potentially delete a valid=20 current binding, because it received a stale binding from the prev MAG.=20 If pMAG and nMAG can synchronize the id's, the whole issue is mute. That is the alternative approach to timestamp based scheme that the draft supports. MAG can certainly send the seq number of the MN that it obtained as part of handoff using CT. No need for timestamps there. > Sri> ... If a deployment does not enable NTP kind of=20 > protocols and if the LMA receives a packet with PBU from a=20 > MAG with a invalid timestamp, the LMA can return its own=20 > timestamp and the MAG can use the same in the requests to=20 > avoid this special race condition ... > [FDJ] If the deployment does not enable NTP, all PBUs will=20 > have a wrong ID. Or do you expect the MAG to synch to the=20 > same timebase as the LMA when the LMA returns the timestamp option? > Furthermore, I fail to understand the solution you propose:=20 > how can the LMA declare that the ID (timestamp) is invalid? > Use case: > - pMAG send BU at 10 AM > - nMAG sends BU at 11 AM > - LMA receives BU from nMAG at 11:15 AM. Will it return=20 > timestamp to nMAG, so that the BU can be resent? The LMA returns its timestamp if it detects that the clocks are out of sync.=20 > - LMA receives BU from pMAG at 11:30 AM. Will it retun=20 > timestamp to pMAG, so that BU can be resent? Or maybe the=20 > proposal is that LMA will decide that pMAG BU was sent=20 > earlier than nMAG BU and therefore discard it. Yes. The LMA will discard it. You should read the Timestamp section. The latter=20 > makes sense but it means that the LMA has to assume that pMAG=20 > and nMAG are in synch. And then we're back to the minimum requirement >=20 > In summary, in my opinion: > 1- The LMA MAY be able to generate timestamps (but should=20 > not be required to) > 2- The LMA MAY know that the source used for the ID is a=20 > timestamp (but should not be required to) > 3- If the LMA is not timestamp aware, the MAG MAY use=20 > timestamps (but should not be required to) > 4- If the LMA is timestamp aware, the MAG MAY use=20 > timestamps (but should not be required to) > If any of the 4 statements would reduce the usability of PMIP=20 > in any way, I would appreciate to have a more clear problem statement > Thus: Implementation MUST support Timestamp option: No Ok. > And I would even push it further: if the previous 4=20 > statements can be agreed to, then the logical conclusion is=20 > that timestamps can be left out of the specification (at most=20 > an informative note would do) >=20 > A couple of collateral comments: > - I understand that CT (Context Transfer) is already=20 > acknowledged as a valid alternative solution > For some reason, CT is left out of scope. Fine for me, but=20 > I don't think it's a fair consequence to mandate timestamps > The fact that "context transfer is out of scope" doesn't=20 > equate to "there is no context transfer" But, the base draft has to be complete. We should allow deployments to happen just based on this spec. If we dont support Timestamp and if there is no CT, how will registrations happen ? The LMA will always reject the first request for each MN.=20 > Is it the working assumption that a solution without CT is=20 > simpler than a solution with CT? This would be a wrong assumption > If we have to choose between specifying timestamps or=20 > specifying CT, then I prefer the latter. It's clear that it=20 > will require more work but it will be more useful >=20 > - If a nMAG sends a BU for a given user without=20 > synchronization with pMAG it may be useful to have the option=20 > to indicate it to the LMA > In other words, I propose a flag "OOS ID" (Out of Synch=20 > ID) sent by the MAG, so that the LMA can reset the sequencing=20 > algorithm for a given MN >=20 > - I have read in other emails that timestamps are already=20 > a proven concept in MIP4 > I fail to understand how this argument makes a difference,=20 > since the original problem statement is that the MIP client=20 > (the one generating BUs) in case of PMIP (i.e. the MAG) may=20 > change during the lifetime of a MIP session. The problem=20 > addressed in MIP4 is a different one (replay protection).=20 > It's off-topic, but I find this area of MIP4 overspecified=20 > when compared to approaches in other protocols (e.g. IEEE=20 > 802.16). A monotonically increasing counter is sufficient for=20 > replay protection >=20 Agree, the purpose is different. But, replay protection has a relation to time window. Timestamp provides the validity for the same message. Its the same thing here, just that the window is small. Sri > Regards >=20 > federico >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Envoy=E9 : jeudi 6 septembre 2007 21:58 > =C0 : 'Alexandru Petrescu'; 'netlmm' > Objet : RE: [netlmm] timestamp vs seqno redux >=20 >=20 > Please comment on this issue raised by Alex about mandating=20 > Timestamp option. Alex is right, when we discussed this=20 > issue, the conclusion was to use Timestamp based approach,=20 > but we did not discuss if that was supposed to be mandatory=20 > to implement. >=20 > Now, w.r.t the issue, what are we mandating ? >=20 > - The ability for the LMA to generate a Timestamp and return > the timestamp option. The timestamp in relation to a specific > reference point. IMO, this is one system call on most OS's and > a delta addition if the timestamp generated is elapsed time past > some other reference point. We are talking about 5 to 8 lines > of code. I will be happy to publish this code for all standard > OS's. >=20 > - We are NOT mandating the nodes in the domain to sync up to > a clock source.=20 >=20 >=20 > How does it impact, if some deployment wants to use Seq=20 > Number approach ? >=20 > - No impact. The option need to be supported. Implies those 10 > lines of extra code. >=20 >=20 > Why this should be mandatory ? >=20 > Base draft does not support Context Transfers. Given that the=20 > draft will be incomplete, if we dont mandate the support. By=20 > mandating the support, the LMA can always return its=20 > timestamp and the MAG can use that timestamp and register.=20 > This need to be done just once whenever the LMA/MAG clocks=20 > are out of sync and just for one registration. One extra=20 > round trip for the 1st registration between LMA/MAG pair. >=20 > But, if the LMA falls back to the seq number based approach=20 > and if there are no context transfers, there is always an=20 > extra round trip for each MN registration (at handoff).=20 >=20 > So, I prefer the mandatory approach, its more efficient. But,=20 > as I had it in the initial suggested text, I'm ok not=20 > mandating this and defining an error code "Timestamp option=20 > not supported".=20 >=20 >=20 > Please comment. I want to close this issue.=20 >=20 >=20 > Implementation MUST support Timestamp option: [Yes/No] >=20 >=20 > Thanks > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Sent: Thursday, September 06, 2007 2:01 AM > > To: netlmm > > Subject: [netlmm] timestamp vs seqno redux > >=20 > > I've recently became aware that much nonsense discussion is=20 > happening=20 > > around the timestamp vs seqno. People keep saying that=20 > seqno method=20 > > is a possible alternative to timestamp but at the same time they=20 > > mandate in the document the timestamp method. This is complete=20 > > nonsense. > >=20 > > I don't want the timestamp method to be mandatory. > >=20 > > Anybody else wants the timestamp method to be a mandatory method? > >=20 > > Anybody else wants the timestamp method to be an alternative method? > >=20 > > Alex > > PS: mandatory excerpts: > > "This document _requires_ the use of Timestamp Option" > > "An implementation MUST support Timestamp option." > >=20 > >=20 > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email=20 > Security System. > > For more information please visit http://www.messagelabs.com/email=20 > >=20 > ______________________________________________________________________ > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 13:10:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IThLX-00026O-Iy; Fri, 07 Sep 2007 13:10:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IThLW-00026I-FO for netlmm@ietf.org; Fri, 07 Sep 2007 13:10:18 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IThLW-0002P8-1H for netlmm@ietf.org; Fri, 07 Sep 2007 13:10:18 -0400 X-IronPort-AV: E=Sophos;i="4.20,221,1186383600"; d="scan'208";a="214054691" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 07 Sep 2007 10:10:17 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l87HAHhO021562; Fri, 7 Sep 2007 10:10:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l87HACxJ018774; Fri, 7 Sep 2007 17:10:13 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 10:10:12 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 10:10:12 -0700 From: "Sri Gundavelli" To: "'Julien Laganier'" , References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> <200709071429.19318.julien.IETF@laposte.net> Subject: RE: [netlmm] Issue: Auth Option support Date: Fri, 7 Sep 2007 10:10:12 -0700 Message-ID: <010801c7f171$f3997f30$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200709071429.19318.julien.IETF@laposte.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQ X-OriginalArrivalTime: 07 Sep 2007 17:10:12.0521 (UTC) FILETIME=[F3ADF190:01C7F171] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1829; t=1189185017; x=1190049017; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Auth=20Option=20support |Sender:=20; bh=akkPfBNQUlSpiWysBHkeTV56QSM6+ueDqUnWthfIj7Y=; b=EA9dzWdgmcX3/16E5qhvBxQ1bsHbt562imlpAMnySOl1MXz62LLQE6pfAD/Ts4BaLQIdbxUa PjqzfSQa4oC9is/W2ZeIKSbR3nZpd7VrwaeMkCPmxUPU+8erZ4PbDPwA; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien, > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On > Behalf Of Julien Laganier > Sent: Friday, September 07, 2007 5:29 AM > To: netlmm@ietf.org > Cc: Sri Gundavelli; 'Alper Yegin' > Subject: Re: [netlmm] Issue: Auth Option support > > Hi Sri, > > On Thursday 06 September 2007, Sri Gundavelli wrote: > > I'm confused, should the draft say > > > > "Both LMA and MAG MUST implement IPsec" and > > "all the signaling messages SHOULD be protected using IPSec". > > > > Will this ok, when reviewed by the security folks ? > > > > or mandate IPsec for this specification and let other draft > > relax this in the presence of an alternative approach ? > > > > Please comment. > > Somehow, "MUST implement" and "SHOULD use" together seems a bit > tautologic. > > To me "SHOULD use" is sufficient since it covers both of the two > possibles cases: > > - deployment follows the SHOULD recommendation, it uses IPsec > to protect > PMIPv6, in which case it supports it, since it's using it :), or > > - deployment ignores the SHOULD recommendation, does not uses > IPSec, in > which case it is useless to implement it since it's not used... > > I'd prefer having "MUST protect integrity of signalling messages, and > SHOULD use IPsec ESP to protect integrity of those messages". > We might > also add "MAY use IPsec AH". > I agree. I'm not against allowing other approaches. I'm only concerned, if we can leave the draft saying, "MUST protect integrity of signalling messages", with out specifying IPsec or some other approach. If that will pass the security review. We may have to state that IPsec MUST be used or some other approach, say Auth-Option MUST be used. Not sure, if we can leave this blank. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 14:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITidl-0000O8-4D; Fri, 07 Sep 2007 14:33:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITidk-0000JC-08 for netlmm@ietf.org; Fri, 07 Sep 2007 14:33:12 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ITidi-00008Y-KR for netlmm@ietf.org; Fri, 07 Sep 2007 14:33:11 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1189189989!5549009!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8357 invoked from network); 7 Sep 2007 18:33:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 7 Sep 2007 18:33:09 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l87IX9Pj022331; Fri, 7 Sep 2007 11:33:09 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l87IX88Y002959; Fri, 7 Sep 2007 13:33:08 -0500 (CDT) Received: from [127.0.0.1] ([10.129.43.186]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l87IX6G0002912; Fri, 7 Sep 2007 13:33:07 -0500 (CDT) Message-ID: <46E19961.6020407@gmail.com> Date: Fri, 07 Sep 2007 20:33:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> <46E15DBE.2090502@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990966@zrc2hxm2.corp.nortel.com> <46E16664.1030708@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990B40@zrc2hxm2.corp.nortel.com> <46E1745D.5010402@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990D8B@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116990D8B@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000773-1, 06/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad, both you and me have exposed our reasons. I think both of us make some assumptions in order for our preferred method to work (seqno vs timestamp). But as you can see, me and you are not the only one expressing opinions on this topic. I would call for Chair judgment. Alex Ahmad Muhanna wrote: > Hi Alex, > Please see comments inline. > > Regards, > Ahmad > >> Ahmad Muhanna wrote: >>>>> [Ahmad] You have the following assumptions here: >>>>> >>>>> 1. The delivery of the MN/User profile always goes >> through the LMA. >>>> I'm talking about the home network prefix of the MN. That will >>>> always go through LMA, because LMA is in charge, topologically >>>> correct, of that prefix. You can't have any other entity >> to send the >>>> home prefix of MN to MN without letting LMA know about that. >>> [Ahmad] Alex, >>> >>> I understand that LMA in charge of the maintenance of its network >>> topology, whatever, you would like to call it. Including the HNP. >>> Okay. >>> >>> Let us focus here on the HNP first and SQN becomes >> redundant. Now, It >>> seems we have different opinions on how the HNP is >> communicated back >>> to the MAG. >>> >>> somehow you believe that the HNP will always be >> communicated back to >>> the MAG via LMA. I have a problem with this assumption, as follows: >>> >>> My understanding is that there are two options that have been >>> discussed: >>> >>> 1. MAG receive the HNP before establishing P-MIP session, >> i.e. before >>> sending P-BU/P-BA. >> Right... that's what I've assumed. > > [Ahmad] > But how that can be done through the LMA before exchanging P-BU/P-BA? > >>> 1.1. In this mechanism it does not make any sense for this >> mechanism >>> to be done through the LMA. 1.2. MAG request the profile from the >>> Policy server which maintains the HNP of the user. I do not >> think this >>> a huge issue here and it can be done, is that the best >> option, that is >>> a different discussion. >> How? Which protocol? >> >>> 1.3. Policy server delivers the user profile (Assuming that the LMA >>> and Policy server are in sync) In other words, yes, LMA >> supports the >>> HNP configured in the policy server and it is available. >> 1.4. When the >>> MAG receives the user profile from the policy server, MAG finds the >>> following information: 1.4.1. User NAI 1.4.2. LMA IP >> address 1.4.3. IP >>> address Configuration >> How does the 'policy server' know the IP address configuration of MN? >> It's the LMA who communicated it to 'policy server', right? > > [Ahmad] > Alex, > we are not talking about the MN IP address, it is the whole HNP. > Regardless. Now, how the Policy server know which HNP is out-of-scope of > this discussion and the PMIPv6 spec. > > >>> Optionally: 1.4.4. HNP (this was made optional because there is >>> another mechanism which I will list in a second) >>> >>> 1.5. After the MAG receives the user profile, MAG sends a >> P-BU to the >>> LMA and include the HNP. >>> >>> ** Optionally MAG may start advertising the HNP to the MN >> via RA or >>> wait after successful P-BA arrives ** 1.6. LMA send a >> successful P-BA >>> only if the HNP is correct and all other stuff. 1.7. MAG >> receives P-BA >>> and user is registered. >>> >>> In this scenario, tell me where the LMA can update the user >> profile by >>> the last successful SQN. >> In step 1.4.3: how does the 'policy server' know the 'IP >> address configuration' to send to MAG? The only way it could >> know it is to learn it from LMA. At that learning point the >> LMA sends the last successful seqno as well. > > {Ahmad] > Step 1.4.3. Is not a step in the call flow, I am just listing what are > the things saved in the user profile! > How to get these information into the user profile can be achieved via > many other ways and out-of-scope here and irrelevant. If you think that > is done dynamically by the LMA while establishing a PMIP session for the > user, I can tell you that is NOT correct. IMO. > >> >>> It is only possible if the LMA always goes back to the >> Policy Server >>> and update the policy server with the last successful SQN per-MN. I >>> guess that probably a killing! >> We can have the 'policy server' to always request the LMA >> before sending IP address information to MAG. This happens >> only at first MN attaching to MAG. > > {Ahmad] > No problem, you can suggest whatever you want, however, that is > out-of-scope of the PMIP spec. IMO, it is not the best option! > >> If you talk about overkill, I think the whole reliance on a >> 'policy server' is overkill. > > [Ahmad] > May be. However, to dynamically update the policy server with the latest > SQN in order to solve your issue here is not an overkill, it is a little > more:-) > >>> 2. MAG receive the HNP in the P-BA after inserting an >> All-ZERO in the >>> HNP/HoA option in the P-BU: This mechanism is exactly the >> same as per >>> option 1 until (1.3) for this one let us say 2.3. >> Right... in this case, in addition to HNP All-ZERO, the MAG >> will put a seqno equal All-ZERO and the LMA will reply back >> the current seqno. > > [Ahmad] > Good suggestion, Do you expect the LMA to send a successful P-BA or a > P-BA with code 135? > 1. If you expect LMA to send 135 and the latest SQN, that is 2 round > trip! > 2. If you expects the LMA to accept the P-BU and sends a successful P-BA > with latest SQN, that is a horrible thing. The least to say. > 3. Also, you are creating a problem in matching the P-BA with the > outstanding P-BU for nothing. > >>> 2.4. MAG will receive the profile BUT there is no HNP. 2.5. >> After the >>> MAG receives the user profile, MAG sends a P-BU to the LMA >> and include >>> an all-ZEROS in the HNP option. 2.6. LMA send a successful >> P-BA with a >>> valid HNP/HoA IP address if all other validations are correct. 2.7. >>> MAG receives P-BA and ONLY then advertise the HNP to the MN. >>> >>> NOW: In this scenario, tell me where the LMA can update the user >>> profile by the last successful per-MN SQN. >> In this last scenario 2, you don't have a 'policy server', so >> only the LMA is involved. The 'policy profiler machine' will >> not update the user profile. > > [Ahmad] > Alex, Please go back and read it one more time. > >> Could you please picture a message exchange with what you >> think the first steps are and then I'll paste into these >> first steps where the seqno fits. >> > > [Ahmad] > Sincerely, I do not have the time to do it and I apologize for not being > able to deliver on your request. > >>>> The LMA maintains that seqno and it doesn't communicate it >> to anybody >>>> else but to MAG. >>> How? In P-BA, it is too late and that is what is called 2 >> round trips. >>> Right? >> Well, if you put 00 instead of a home address in the P-BU >> then you can put a 00 in the place of the seqno as well. >> There will only be one pbu/pback initially. The LMA will >> just not increment its seqno when it receives a seqno 00. >> >> The LMA can not receive two P-BUs with seqno 00 from two >> different MAGs. >> BEcause MAG can not be attached to two MAGs simultaneously. > > [Ahmad] > Please see comments above. >> Alex >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 15:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITjTn-0005CF-0O; Fri, 07 Sep 2007 15:26:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITjTl-0005Bf-TQ for netlmm@ietf.org; Fri, 07 Sep 2007 15:26:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITjTk-0001bp-FM for netlmm@ietf.org; Fri, 07 Sep 2007 15:26:57 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l87JQs6L011214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Sep 2007 12:26:55 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l87JQrYI008579; Fri, 7 Sep 2007 12:26:54 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Sep 2007 12:26:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Auth Option support Date: Fri, 7 Sep 2007 12:26:54 -0700 Message-ID: In-Reply-To: <010801c7f171$f3997f30$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Auth Option support Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQAATTUOA= References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net><01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com><200709071429.19318.julien.IETF@laposte.net> <010801c7f171$f3997f30$d4f6200a@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" , "Julien Laganier" , X-OriginalArrivalTime: 07 Sep 2007 19:26:53.0806 (UTC) FILETIME=[0C06B8E0:01C7F185] X-Spam-Score: -4.0 (----) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org All, On this topic, I believe we must have a mandatory to implement mechanism specified for standards track publication. We can leave the use at "RECOMMENDED" or "SHOULD", but, we need a "MUST" on what the LMA and MAG need to implement. =20 I had run this by the security directorate at the Chicago meeting and my understanding is that as long as we have "MUST implement IPsec" and "SHOULD use IPsec", it would be fine. =20 In other words, the SHOULD vs. MUST that we want to place on using IPsec can be discussed, but, the "MUST" on implementation is non-negotiable. =20 This is inline with my understanding on what we need to state for a complete specification. Given that channel security of signaling messages is mandatory, unless we have at least one common denominator that the MAG and LMA implementors will implement, we cannot ensure interoperability. If they support multiple common mechanisms and chose to use something other than IPsec, that's fine - hence, the "SHOULD" on usage.=20 Hope that helps.=20 Thanks, Vidya > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Friday, September 07, 2007 10:10 AM > To: 'Julien Laganier'; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Auth Option support >=20 > Hi Julien, >=20 > =20 >=20 > > -----Original Message----- > > From: julien laganier [mailto:julien.laganier@gmail.com] On=20 > Behalf Of=20 > > Julien Laganier > > Sent: Friday, September 07, 2007 5:29 AM > > To: netlmm@ietf.org > > Cc: Sri Gundavelli; 'Alper Yegin' > > Subject: Re: [netlmm] Issue: Auth Option support > >=20 > > Hi Sri, > >=20 > > On Thursday 06 September 2007, Sri Gundavelli wrote: > > > I'm confused, should the draft say > > > > > > "Both LMA and MAG MUST implement IPsec" and "all the signaling=20 > > > messages SHOULD be protected using IPSec". > > > > > > Will this ok, when reviewed by the security folks ? > > > > > > or mandate IPsec for this specification and let other draft relax=20 > > > this in the presence of an alternative approach ? > > > > > > Please comment. > >=20 > > Somehow, "MUST implement" and "SHOULD use" together seems a bit=20 > > tautologic. > >=20 > > To me "SHOULD use" is sufficient since it covers both of the two=20 > > possibles cases: > >=20 > > - deployment follows the SHOULD recommendation, it uses IPsec to=20 > > protect PMIPv6, in which case it supports it, since it's=20 > using it :),=20 > > or > >=20 > > - deployment ignores the SHOULD recommendation, does not=20 > uses IPSec,=20 > > in which case it is useless to implement it since it's not used... > >=20 > > I'd prefer having "MUST protect integrity of signalling=20 > messages, and=20 > > SHOULD use IPsec ESP to protect integrity of those messages". > > We might > > also add "MAY use IPsec AH". > >=20 >=20 >=20 > I agree. I'm not against allowing other approaches. I'm only=20 > concerned, if we can leave the draft saying, "MUST protect=20 > integrity of signalling messages", with out specifying IPsec=20 > or some other approach. If that will pass the security=20 > review. We may have to state that IPsec MUST be used or some=20 > other approach, say Auth-Option MUST be used. Not sure, if we=20 > can leave this blank. >=20 > Sri >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 16:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkON-00026A-IZ; Fri, 07 Sep 2007 16:25:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkOM-00021W-8R for netlmm@ietf.org; Fri, 07 Sep 2007 16:25:26 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITkOL-0007Qo-8e for netlmm@ietf.org; Fri, 07 Sep 2007 16:25:26 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l87KPL322648; Fri, 7 Sep 2007 20:25:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Fri, 7 Sep 2007 15:25:19 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371169E844F@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E19961.6020407@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfxfY5I9DFbzH85T3e40hr3YwVkYQADFx7Q References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <46E0784F.2090904@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169906A0@zrc2hxm2.corp.nortel.com> <46E15DBE.2090502@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990966@zrc2hxm2.corp.nortel.com> <46E16664.1030708@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990B40@zrc2hxm2.corp.nortel.com> <46E1745D.5010402@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116990D8B@zrc2hxm2.corp.nortel.com> <46E19961.6020407@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, I am not sure what is the best approach for moving forward.=20 But that should not be a problem. Cheers. Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Friday, September 07, 2007 1:33 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Sri Gundavelli; netlmm > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad, both you and me have exposed our reasons. >=20 > I think both of us make some assumptions in order for our=20 > preferred method to work (seqno vs timestamp). >=20 > But as you can see, me and you are not the only one=20 > expressing opinions on this topic. >=20 > I would call for Chair judgment. >=20 > Alex >=20 > Ahmad Muhanna wrote: > > Hi Alex, > > Please see comments inline. > >=20 > > Regards, > > Ahmad > >=20 > >> Ahmad Muhanna wrote: > >>>>> [Ahmad] You have the following assumptions here: > >>>>> > >>>>> 1. The delivery of the MN/User profile always goes > >> through the LMA. > >>>> I'm talking about the home network prefix of the MN. That will=20 > >>>> always go through LMA, because LMA is in charge, topologically=20 > >>>> correct, of that prefix. You can't have any other entity > >> to send the > >>>> home prefix of MN to MN without letting LMA know about that. > >>> [Ahmad] Alex, > >>> > >>> I understand that LMA in charge of the maintenance of its network=20 > >>> topology, whatever, you would like to call it. Including the HNP. > >>> Okay. > >>> > >>> Let us focus here on the HNP first and SQN becomes > >> redundant. Now, It > >>> seems we have different opinions on how the HNP is > >> communicated back > >>> to the MAG. > >>> > >>> somehow you believe that the HNP will always be > >> communicated back to > >>> the MAG via LMA. I have a problem with this assumption,=20 > as follows: > >>> > >>> My understanding is that there are two options that have been > >>> discussed: > >>> > >>> 1. MAG receive the HNP before establishing P-MIP session, > >> i.e. before > >>> sending P-BU/P-BA. > >> Right... that's what I've assumed. > >=20 > > [Ahmad] > > But how that can be done through the LMA before exchanging=20 > P-BU/P-BA? > >=20 > >>> 1.1. In this mechanism it does not make any sense for this > >> mechanism > >>> to be done through the LMA. 1.2. MAG request the profile from the=20 > >>> Policy server which maintains the HNP of the user. I do not > >> think this > >>> a huge issue here and it can be done, is that the best > >> option, that is > >>> a different discussion. > >> How? Which protocol? > >> > >>> 1.3. Policy server delivers the user profile (Assuming=20 > that the LMA=20 > >>> and Policy server are in sync) In other words, yes, LMA > >> supports the > >>> HNP configured in the policy server and it is available.=20 > >> 1.4. When the > >>> MAG receives the user profile from the policy server, MAG=20 > finds the=20 > >>> following information: 1.4.1. User NAI 1.4.2. LMA IP > >> address 1.4.3. IP > >>> address Configuration > >> How does the 'policy server' know the IP address=20 > configuration of MN? > >> It's the LMA who communicated it to 'policy server', right? > >=20 > > [Ahmad] > > Alex, > > we are not talking about the MN IP address, it is the whole HNP.=20 > > Regardless. Now, how the Policy server know which HNP is=20 > out-of-scope=20 > > of this discussion and the PMIPv6 spec. > >=20 > >=20 > >>> Optionally: 1.4.4. HNP (this was made optional because there is=20 > >>> another mechanism which I will list in a second) > >>> > >>> 1.5. After the MAG receives the user profile, MAG sends a > >> P-BU to the > >>> LMA and include the HNP. > >>> > >>> ** Optionally MAG may start advertising the HNP to the MN > >> via RA or > >>> wait after successful P-BA arrives ** 1.6. LMA send a > >> successful P-BA > >>> only if the HNP is correct and all other stuff. 1.7. MAG > >> receives P-BA > >>> and user is registered. > >>> > >>> In this scenario, tell me where the LMA can update the user > >> profile by > >>> the last successful SQN. > >> In step 1.4.3: how does the 'policy server' know the 'IP address=20 > >> configuration' to send to MAG? The only way it could know=20 > it is to=20 > >> learn it from LMA. At that learning point the LMA sends the last=20 > >> successful seqno as well. > >=20 > > {Ahmad] > > Step 1.4.3. Is not a step in the call flow, I am just=20 > listing what are=20 > > the things saved in the user profile! > > How to get these information into the user profile can be=20 > achieved via=20 > > many other ways and out-of-scope here and irrelevant. If you think=20 > > that is done dynamically by the LMA while establishing a=20 > PMIP session=20 > > for the user, I can tell you that is NOT correct. IMO. > >=20 > >> > >>> It is only possible if the LMA always goes back to the > >> Policy Server > >>> and update the policy server with the last successful SQN=20 > per-MN. I=20 > >>> guess that probably a killing! > >> We can have the 'policy server' to always request the LMA before=20 > >> sending IP address information to MAG. This happens only=20 > at first MN=20 > >> attaching to MAG. > >=20 > > {Ahmad] > > No problem, you can suggest whatever you want, however, that is=20 > > out-of-scope of the PMIP spec. IMO, it is not the best option! > >=20 > >> If you talk about overkill, I think the whole reliance on=20 > a 'policy=20 > >> server' is overkill. > >=20 > > [Ahmad] > > May be. However, to dynamically update the policy server with the=20 > > latest SQN in order to solve your issue here is not an=20 > overkill, it is=20 > > a little > > more:-) > >=20 > >>> 2. MAG receive the HNP in the P-BA after inserting an > >> All-ZERO in the > >>> HNP/HoA option in the P-BU: This mechanism is exactly the > >> same as per > >>> option 1 until (1.3) for this one let us say 2.3. > >> Right... in this case, in addition to HNP All-ZERO, the=20 > MAG will put=20 > >> a seqno equal All-ZERO and the LMA will reply back the=20 > current seqno. > >=20 > > [Ahmad] > > Good suggestion, Do you expect the LMA to send a successful=20 > P-BA or a=20 > > P-BA with code 135? > > 1. If you expect LMA to send 135 and the latest SQN, that=20 > is 2 round=20 > > trip! > > 2. If you expects the LMA to accept the P-BU and sends a successful=20 > > P-BA with latest SQN, that is a horrible thing. The least to say. > > 3. Also, you are creating a problem in matching the P-BA with the=20 > > outstanding P-BU for nothing. > >=20 > >>> 2.4. MAG will receive the profile BUT there is no HNP. 2.5.=20 > >> After the > >>> MAG receives the user profile, MAG sends a P-BU to the LMA > >> and include > >>> an all-ZEROS in the HNP option. 2.6. LMA send a successful > >> P-BA with a > >>> valid HNP/HoA IP address if all other validations are=20 > correct. 2.7.=20 > >>> MAG receives P-BA and ONLY then advertise the HNP to the MN. > >>> > >>> NOW: In this scenario, tell me where the LMA can update the user=20 > >>> profile by the last successful per-MN SQN. > >> In this last scenario 2, you don't have a 'policy server', so only=20 > >> the LMA is involved. The 'policy profiler machine' will=20 > not update=20 > >> the user profile. > >=20 > > [Ahmad] > > Alex, Please go back and read it one more time. > >=20 > >> Could you please picture a message exchange with what you=20 > think the=20 > >> first steps are and then I'll paste into these first steps=20 > where the=20 > >> seqno fits. > >> > >=20 > > [Ahmad] > > Sincerely, I do not have the time to do it and I apologize for not=20 > > being able to deliver on your request. > >=20 > >>>> The LMA maintains that seqno and it doesn't communicate it > >> to anybody > >>>> else but to MAG. > >>> How? In P-BA, it is too late and that is what is called 2 > >> round trips.=20 > >>> Right? > >> Well, if you put 00 instead of a home address in the P-BU then you=20 > >> can put a 00 in the place of the seqno as well. > >> There will only be one pbu/pback initially. The LMA will just not=20 > >> increment its seqno when it receives a seqno 00. > >> > >> The LMA can not receive two P-BUs with seqno 00 from two different=20 > >> MAGs. > >> BEcause MAG can not be attached to two MAGs simultaneously. > >=20 > > [Ahmad] > > Please see comments above. > >> Alex > >> > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 17:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkw1-0008Ik-UZ; Fri, 07 Sep 2007 17:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkw0-0008IY-IA for netlmm@ietf.org; Fri, 07 Sep 2007 17:00:12 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITkvz-0003sE-9Q for netlmm@ietf.org; Fri, 07 Sep 2007 17:00:12 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l87L09fT020677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Sep 2007 14:00:10 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l87L094w008540 for ; Fri, 7 Sep 2007 14:00:09 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Sep 2007 14:00:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Sep 2007 14:00:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom 2007-8: Nominations Close on Sep 10, 2007 Thread-Index: AcfxidFVDASPfLgTS225XTfZ34uYywAB5ygQ From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 07 Sep 2007 21:00:09.0063 (UTC) FILETIME=[130F2F70:01C7F192] X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [netlmm] FW: Nomcom 2007-8: Nominations Close on Sep 10, 2007 X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org FYI > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Friday, September 07, 2007 12:53 PM > To: ietf-announce@ietf.org; wgchairs@ietf.org; IESG IESG; IAB IAB > Subject: Nomcom 2007-8: Nominations Close on Sep 10, 2007 >=20 > WGchairs, IESG and IAB members >=20 > Please forward this request to the lists you manage and=20 > request feedback and nominations. >=20 > All, >=20 > Here is the link to nominate:=20 > https://tools.ietf.org/group/nomcom/07/nominate >=20 > You may also send nominations or comments via email to=20 > nomcom07@ietf.org or ldondeti@qualcomm.com. >=20 > We have received very few nominations (1, 2, 2, 2, 3, 4, 8,=20 > 8, 19) and even fewer accepted (1-2 people in each area, IAB=20 > acceptances is 4 at last count). >=20 > I request the community to provide feedback on the incumbents=20 > (send email or send notes via the web page). >=20 > 1) If you think that the incumbent is doing a good job > a) provide feedback AND > b) nominate similar people just in case there is strong=20 > negative feedback on the incumbent >=20 > 2) If you think the incumbent can do somethings better > a) provide feedback AND > b) nominate someone who you think might do better >=20 > Candidates, if time commitment is the only issue, please=20 > indicate that to the nomcom and accept the nominations. >=20 > thanks, > Lakshminath >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 17:12:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITl7P-0004b5-V3; Fri, 07 Sep 2007 17:11:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITl7O-0004b0-EX for netlmm@ietf.org; Fri, 07 Sep 2007 17:11:58 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITl7N-00049d-1z for netlmm@ietf.org; Fri, 07 Sep 2007 17:11:58 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l87LB7S1028687; Sat, 8 Sep 2007 00:11:46 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Sep 2007 00:11:09 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 16:11:04 -0500 Received: from 10.241.58.198 ([10.241.58.198]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Sep 2007 21:11:04 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 07 Sep 2007 16:11:33 -0500 Subject: Re: [netlmm] Issue: Auth Option support From: Basavaraj Patil To: Sri Gundavelli , "'Julien Laganier'" , Message-ID: Thread-Topic: [netlmm] Issue: Auth Option support Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQAAi0xVI= In-Reply-To: <010801c7f171$f3997f30$d4f6200a@amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Sep 2007 21:11:04.0771 (UTC) FILETIME=[99E44930:01C7F193] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, I do believe we need to specify a default security mechanism for the MAG/LMA signaling messages. And for this purpose, IPsec is a good choice. So IMO it is required that we state "Proxy MIP6 signaling messages between the MAG and LMA MUST be secured by the use of an IPsec SA between the two entities". I think this does not limit the ability to adopt alternative security solutions in the future. -Raj On 9/7/07 12:10 PM, "ext Sri Gundavelli" wrote: > Hi Julien, > > > >> -----Original Message----- >> From: julien laganier [mailto:julien.laganier@gmail.com] On >> Behalf Of Julien Laganier >> Sent: Friday, September 07, 2007 5:29 AM >> To: netlmm@ietf.org >> Cc: Sri Gundavelli; 'Alper Yegin' >> Subject: Re: [netlmm] Issue: Auth Option support >> >> Hi Sri, >> >> On Thursday 06 September 2007, Sri Gundavelli wrote: >>> I'm confused, should the draft say >>> >>> "Both LMA and MAG MUST implement IPsec" and >>> "all the signaling messages SHOULD be protected using IPSec". >>> >>> Will this ok, when reviewed by the security folks ? >>> >>> or mandate IPsec for this specification and let other draft >>> relax this in the presence of an alternative approach ? >>> >>> Please comment. >> >> Somehow, "MUST implement" and "SHOULD use" together seems a bit >> tautologic. >> >> To me "SHOULD use" is sufficient since it covers both of the two >> possibles cases: >> >> - deployment follows the SHOULD recommendation, it uses IPsec >> to protect >> PMIPv6, in which case it supports it, since it's using it :), or >> >> - deployment ignores the SHOULD recommendation, does not uses >> IPSec, in >> which case it is useless to implement it since it's not used... >> >> I'd prefer having "MUST protect integrity of signalling messages, and >> SHOULD use IPsec ESP to protect integrity of those messages". >> We might >> also add "MAY use IPsec AH". >> > > > I agree. I'm not against allowing other approaches. I'm only concerned, > if we can leave the draft saying, "MUST protect integrity of signalling > messages", with out specifying IPsec or some other approach. If that > will pass the security review. We may have to state that IPsec MUST be > used or some other approach, say Auth-Option MUST be used. Not sure, if > we can leave this blank. > > Sri > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 17:42:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlb0-0006Ea-E1; Fri, 07 Sep 2007 17:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlay-0006Az-UT for netlmm@ietf.org; Fri, 07 Sep 2007 17:42:32 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITlax-00054H-Mm for netlmm@ietf.org; Fri, 07 Sep 2007 17:42:32 -0400 X-IronPort-AV: E=Sophos;i="4.20,222,1186383600"; d="scan'208";a="521724618" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Sep 2007 14:42:31 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l87LgVHD011460; Fri, 7 Sep 2007 14:42:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l87LgQ7R016280; Fri, 7 Sep 2007 21:42:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 14:42:26 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 14:42:26 -0700 From: "Sri Gundavelli" To: "'Basavaraj Patil'" , "'Julien Laganier'" , References: <010801c7f171$f3997f30$d4f6200a@amer.cisco.com> Subject: RE: [netlmm] Issue: Auth Option support Date: Fri, 7 Sep 2007 14:42:25 -0700 Message-ID: <015101c7f197$fb0457b0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQAAi0xVIAAPT7EA== X-OriginalArrivalTime: 07 Sep 2007 21:42:26.0123 (UTC) FILETIME=[FB43D1B0:01C7F197] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3189; t=1189201351; x=1190065351; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Auth=20Option=20support |Sender:=20; bh=iYVpF5t1EeavYFy1KNGuFkXmF+CeENA7QtK+t4qOWK0=; b=uZcBGZaqGlfinJYHPGsRD+8H7ezqZ79d2uEpu3H1JuLC9sbCIG9toH57r16qp6l2SKu5+3Ab 61JW9X77BZkUJvAhbawaYDH/IPFnvLHuIIb7gVJbpJ4RvmuiBnm4Ob4/; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Raj, This is my view as well. Now, this will conflict with "MUST implement and SHOULD use of IPsec". To be consistent, it has to be "MUST implement and MUST use". Then Alper wont like this... Sri > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Friday, September 07, 2007 2:12 PM > To: Sri Gundavelli; 'Julien Laganier'; netlmm@ietf.org > Subject: Re: [netlmm] Issue: Auth Option support > > > Hi Sri, > > I do believe we need to specify a default security mechanism > for the MAG/LMA > signaling messages. And for this purpose, IPsec is a good choice. > So IMO it is required that we state "Proxy MIP6 signaling > messages between > the MAG and LMA MUST be secured by the use of an IPsec SA > between the two > entities". > > I think this does not limit the ability to adopt alternative security > solutions in the future. > > -Raj > > > On 9/7/07 12:10 PM, "ext Sri Gundavelli" wrote: > > > Hi Julien, > > > > > > > >> -----Original Message----- > >> From: julien laganier [mailto:julien.laganier@gmail.com] On > >> Behalf Of Julien Laganier > >> Sent: Friday, September 07, 2007 5:29 AM > >> To: netlmm@ietf.org > >> Cc: Sri Gundavelli; 'Alper Yegin' > >> Subject: Re: [netlmm] Issue: Auth Option support > >> > >> Hi Sri, > >> > >> On Thursday 06 September 2007, Sri Gundavelli wrote: > >>> I'm confused, should the draft say > >>> > >>> "Both LMA and MAG MUST implement IPsec" and > >>> "all the signaling messages SHOULD be protected using IPSec". > >>> > >>> Will this ok, when reviewed by the security folks ? > >>> > >>> or mandate IPsec for this specification and let other draft > >>> relax this in the presence of an alternative approach ? > >>> > >>> Please comment. > >> > >> Somehow, "MUST implement" and "SHOULD use" together seems a bit > >> tautologic. > >> > >> To me "SHOULD use" is sufficient since it covers both of the two > >> possibles cases: > >> > >> - deployment follows the SHOULD recommendation, it uses IPsec > >> to protect > >> PMIPv6, in which case it supports it, since it's using it :), or > >> > >> - deployment ignores the SHOULD recommendation, does not uses > >> IPSec, in > >> which case it is useless to implement it since it's not used... > >> > >> I'd prefer having "MUST protect integrity of signalling > messages, and > >> SHOULD use IPsec ESP to protect integrity of those messages". > >> We might > >> also add "MAY use IPsec AH". > >> > > > > > > I agree. I'm not against allowing other approaches. I'm > only concerned, > > if we can leave the draft saying, "MUST protect integrity > of signalling > > messages", with out specifying IPsec or some other approach. If that > > will pass the security review. We may have to state that > IPsec MUST be > > used or some other approach, say Auth-Option MUST be used. > Not sure, if > > we can leave this blank. > > > > Sri > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 17:55:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlnS-0002Hp-FU; Fri, 07 Sep 2007 17:55:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlnR-0002GW-8p for netlmm@ietf.org; Fri, 07 Sep 2007 17:55:25 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITlnQ-0001Vu-0y for netlmm@ietf.org; Fri, 07 Sep 2007 17:55:25 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l87LtBCa003929; Sat, 8 Sep 2007 00:55:20 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Sep 2007 00:55:15 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 16:55:12 -0500 Received: from 10.241.58.198 ([10.241.58.198]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Sep 2007 21:55:12 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 07 Sep 2007 16:55:41 -0500 Subject: Re: [netlmm] Issue: Auth Option support From: Basavaraj Patil To: Sri Gundavelli , "'Julien Laganier'" , Message-ID: Thread-Topic: [netlmm] Issue: Auth Option support Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQAAi0xVIAAPT7EAAAlZrf In-Reply-To: <015101c7f197$fb0457b0$d4f6200a@amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Sep 2007 21:55:12.0613 (UTC) FILETIME=[C420E950:01C7F199] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org To ensure there is interoperability between multiple implementations, there needs to be a default security mechanism and that would be IPsec. What specific method is used in a certain deployment is not mandated by the spec. So I think we can just leave it as a MUST for IPsec as the default security solution without saying MUST use. -Raj On 9/7/07 4:42 PM, "ext Sri Gundavelli" wrote: > Raj, > > This is my view as well. Now, this will conflict with > "MUST implement and SHOULD use of IPsec". To be consistent, > it has to be "MUST implement and MUST use". Then Alper wont > like this... > > > Sri > > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Friday, September 07, 2007 2:12 PM >> To: Sri Gundavelli; 'Julien Laganier'; netlmm@ietf.org >> Subject: Re: [netlmm] Issue: Auth Option support >> >> >> Hi Sri, >> >> I do believe we need to specify a default security mechanism >> for the MAG/LMA >> signaling messages. And for this purpose, IPsec is a good choice. >> So IMO it is required that we state "Proxy MIP6 signaling >> messages between >> the MAG and LMA MUST be secured by the use of an IPsec SA >> between the two >> entities". >> >> I think this does not limit the ability to adopt alternative security >> solutions in the future. >> >> -Raj >> >> >> On 9/7/07 12:10 PM, "ext Sri Gundavelli" wrote: >> >>> Hi Julien, >>> >>> >>> >>>> -----Original Message----- >>>> From: julien laganier [mailto:julien.laganier@gmail.com] On >>>> Behalf Of Julien Laganier >>>> Sent: Friday, September 07, 2007 5:29 AM >>>> To: netlmm@ietf.org >>>> Cc: Sri Gundavelli; 'Alper Yegin' >>>> Subject: Re: [netlmm] Issue: Auth Option support >>>> >>>> Hi Sri, >>>> >>>> On Thursday 06 September 2007, Sri Gundavelli wrote: >>>>> I'm confused, should the draft say >>>>> >>>>> "Both LMA and MAG MUST implement IPsec" and >>>>> "all the signaling messages SHOULD be protected using IPSec". >>>>> >>>>> Will this ok, when reviewed by the security folks ? >>>>> >>>>> or mandate IPsec for this specification and let other draft >>>>> relax this in the presence of an alternative approach ? >>>>> >>>>> Please comment. >>>> >>>> Somehow, "MUST implement" and "SHOULD use" together seems a bit >>>> tautologic. >>>> >>>> To me "SHOULD use" is sufficient since it covers both of the two >>>> possibles cases: >>>> >>>> - deployment follows the SHOULD recommendation, it uses IPsec >>>> to protect >>>> PMIPv6, in which case it supports it, since it's using it :), or >>>> >>>> - deployment ignores the SHOULD recommendation, does not uses >>>> IPSec, in >>>> which case it is useless to implement it since it's not used... >>>> >>>> I'd prefer having "MUST protect integrity of signalling >> messages, and >>>> SHOULD use IPsec ESP to protect integrity of those messages". >>>> We might >>>> also add "MAY use IPsec AH". >>>> >>> >>> >>> I agree. I'm not against allowing other approaches. I'm >> only concerned, >>> if we can leave the draft saying, "MUST protect integrity >> of signalling >>> messages", with out specifying IPsec or some other approach. If that >>> will pass the security review. We may have to state that >> IPsec MUST be >>> used or some other approach, say Auth-Option MUST be used. >> Not sure, if >>> we can leave this blank. >>> >>> Sri >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 18:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlu2-0001wl-6e; Fri, 07 Sep 2007 18:02:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlu1-0001wd-Bt for netlmm@ietf.org; Fri, 07 Sep 2007 18:02:13 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITlu0-0001i6-NX for netlmm@ietf.org; Fri, 07 Sep 2007 18:02:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 218A798027 for ; Fri, 7 Sep 2007 18:02:09 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27425-03 for ; Fri, 7 Sep 2007 18:02:07 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 7 Sep 2007 18:02:07 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 18:02:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Auth Option support Date: Fri, 7 Sep 2007 18:01:32 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA53C@exchtewks2.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Auth Option support Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQAAi0xVIAAPT7EAAAlZrfAAAtWLA= From: "Chowdhury, Kuntal" To: "Basavaraj Patil" , "Sri Gundavelli" , "Julien Laganier" , X-OriginalArrivalTime: 07 Sep 2007 22:02:47.0398 (UTC) FILETIME=[D3339860:01C7F19A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I agree. MUST implement is fine. MUST use is too much, IMO. -Kuntal > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Friday, September 07, 2007 4:56 PM > To: Sri Gundavelli; 'Julien Laganier'; netlmm@ietf.org > Subject: Re: [netlmm] Issue: Auth Option support >=20 >=20 > To ensure there is interoperability between multiple implementations, > there > needs to be a default security mechanism and that would be IPsec. What > specific method is used in a certain deployment is not mandated by the > spec. >=20 > So I think we can just leave it as a MUST for IPsec as the default > security > solution without saying MUST use. >=20 > -Raj >=20 >=20 > On 9/7/07 4:42 PM, "ext Sri Gundavelli" wrote: >=20 > > Raj, > > > > This is my view as well. Now, this will conflict with > > "MUST implement and SHOULD use of IPsec". To be consistent, > > it has to be "MUST implement and MUST use". Then Alper wont > > like this... > > > > > > Sri > > > > > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Friday, September 07, 2007 2:12 PM > >> To: Sri Gundavelli; 'Julien Laganier'; netlmm@ietf.org > >> Subject: Re: [netlmm] Issue: Auth Option support > >> > >> > >> Hi Sri, > >> > >> I do believe we need to specify a default security mechanism > >> for the MAG/LMA > >> signaling messages. And for this purpose, IPsec is a good choice. > >> So IMO it is required that we state "Proxy MIP6 signaling > >> messages between > >> the MAG and LMA MUST be secured by the use of an IPsec SA > >> between the two > >> entities". > >> > >> I think this does not limit the ability to adopt alternative security > >> solutions in the future. > >> > >> -Raj > >> > >> > >> On 9/7/07 12:10 PM, "ext Sri Gundavelli" wrote: > >> > >>> Hi Julien, > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: julien laganier [mailto:julien.laganier@gmail.com] On > >>>> Behalf Of Julien Laganier > >>>> Sent: Friday, September 07, 2007 5:29 AM > >>>> To: netlmm@ietf.org > >>>> Cc: Sri Gundavelli; 'Alper Yegin' > >>>> Subject: Re: [netlmm] Issue: Auth Option support > >>>> > >>>> Hi Sri, > >>>> > >>>> On Thursday 06 September 2007, Sri Gundavelli wrote: > >>>>> I'm confused, should the draft say > >>>>> > >>>>> "Both LMA and MAG MUST implement IPsec" and > >>>>> "all the signaling messages SHOULD be protected using IPSec". > >>>>> > >>>>> Will this ok, when reviewed by the security folks ? > >>>>> > >>>>> or mandate IPsec for this specification and let other draft > >>>>> relax this in the presence of an alternative approach ? > >>>>> > >>>>> Please comment. > >>>> > >>>> Somehow, "MUST implement" and "SHOULD use" together seems a bit > >>>> tautologic. > >>>> > >>>> To me "SHOULD use" is sufficient since it covers both of the two > >>>> possibles cases: > >>>> > >>>> - deployment follows the SHOULD recommendation, it uses IPsec > >>>> to protect > >>>> PMIPv6, in which case it supports it, since it's using it :), or > >>>> > >>>> - deployment ignores the SHOULD recommendation, does not uses > >>>> IPSec, in > >>>> which case it is useless to implement it since it's not used... > >>>> > >>>> I'd prefer having "MUST protect integrity of signalling > >> messages, and > >>>> SHOULD use IPsec ESP to protect integrity of those messages". > >>>> We might > >>>> also add "MAY use IPsec AH". > >>>> > >>> > >>> > >>> I agree. I'm not against allowing other approaches. I'm > >> only concerned, > >>> if we can leave the draft saying, "MUST protect integrity > >> of signalling > >>> messages", with out specifying IPsec or some other approach. If that > >>> will pass the security review. We may have to state that > >> IPsec MUST be > >>> used or some other approach, say Auth-Option MUST be used. > >> Not sure, if > >>> we can leave this blank. > >>> > >>> Sri > >>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 07 19:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITn8d-0004SE-MB; Fri, 07 Sep 2007 19:21:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITn8b-0004OC-SG for netlmm@ietf.org; Fri, 07 Sep 2007 19:21:21 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITn8a-0007Xc-Mk for netlmm@ietf.org; Fri, 07 Sep 2007 19:21:21 -0400 Received: by wx-out-0506.google.com with SMTP id s8so569950wxc for ; Fri, 07 Sep 2007 16:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UQmdL9GcPjanU0dPiq2+2sSYOViHiKeADiWB2QIYm+g=; b=uOXewtNr3YAR8u6DsX/ndSB40w59/gUaTYs7KmjIXrbK6+DQMT13/RVsVMjExtTaRdaIuC8aPVVE2f1RNMdaNRGMJDKwfL+ieSvZVBycQldd9fmJdqpttm0/JF9PUA9MDV1S343/jXICnFDmTuGxOxg1xnwHrlkZ7q35qeJ+U4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RyE+6yclOwINnFA2m+RdU83JoKekgL/7WlnbgxEHiGSdmDAomqqj+6oBCPXzXGX2HEBYkuWjtxMKLiVwRojwfks17qiXYtNf3p7GYbuiAmAD7yO0oX/OsnX65Iow9jEyqJBIPNZMfPUNOJjorTGxmX2OyLNTs2jEcbYTaWBhafg= Received: by 10.90.95.11 with SMTP id s11mr4827816agb.1189207280249; Fri, 07 Sep 2007 16:21:20 -0700 (PDT) Received: by 10.90.99.4 with HTTP; Fri, 7 Sep 2007 16:21:20 -0700 (PDT) Message-ID: <4c174b660709071621s399377e5n9e4347c6f9191fd8@mail.gmail.com> Date: Fri, 7 Sep 2007 16:21:20 -0700 From: "Shyam H" To: netlmm@ietf.org Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt In-Reply-To: <013f01c7f04f$ebbd1ab0$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <013f01c7f04f$ebbd1ab0$d4f6200a@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Dear Sri Thank you for updating the Proxy-MIP6 draft. We reviewed and discussed the draft in detail and these are our comments. First, the draft is written nicely, organized very well; enjoyed reading it; we thank the authors for the good work. We did not like the timestamp format change; it was not needed, we have to make changes to our code.; but fine. In MAG signaling, you should add the RS and RA flow related points; You should add a small section with couple of lines on what the MAG does when RA arrives; this is missing; it is there in the seq diagram. Lot of new error checking rules; but good; very detailed You should specify when the HA should consider the timestamp from MAG as as outof sync. Suggest some time window like 1 second; define a protocol variable. Or, make NTP use a must. Not an issue for us; we have RO. On PBU and PBA retransmissions or timeouts, please say it is as per rfc3775; or define new protocol constants PBA cannot have the type-II routing header, can it ? there is no home address ; you should mention this; to avoid interop problems. Hope this review helps. Thank you again for completing this document; good job. - Shyam > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, September 05, 2007 11:20 PM > > To: i-d-announce@ietf.org > > Cc: netlmm@ietf.org > > Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Network-based Localized > > Mobility Management Working Group of the IETF. > > > > > > Title : Proxy Mobile IPv6 > > Author(s) : S. Gundavelli, et al. > > Filename : draft-ietf-netlmm-proxymip6-03.txt > > Pages : 55 > > Date : 2007-09-06 > > > > This specification describes a network-based mobility management > > protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 > > [RFC-3775]. This protocol enables mobility support to a host without > > requiring its participation in any mobility related signaling. The > > design principle in the case of network-based mobility management > > protocol relies on the network being in control of the mobility > > management. The mobility entities in the network are responsible for > > tracking the movements of the host and initiating the required > > mobility signaling on its behalf. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-03.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > 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-ietf-netlmm-proxymip6-03.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-ietf-netlmm-proxymip6-03.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. > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sun Sep 09 22:48:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUZJ1-000615-SL; Sun, 09 Sep 2007 22:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUZJ1-0005xw-24 for netlmm@ietf.org; Sun, 09 Sep 2007 22:47:19 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUZIz-0006Bj-Hk for netlmm@ietf.org; Sun, 09 Sep 2007 22:47:19 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 19:47:16 -0700 Message-ID: <46E4B02C.5010101@azairenet.com> Date: Sun, 09 Sep 2007 19:47:08 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli , 'Alper Yegin' Subject: Re: [netlmm] Issue: Auth Option support References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> In-Reply-To: <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2007 02:47:16.0561 (UTC) FILETIME=[E60AAC10:01C7F354] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, I agree with "SHOULD" for using IPsec and "MUST" for supporting IPsec on the MAG and the LMA. If thats the consensus, we need to modify a few sentences in the draft. In section 4, replace > The signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access gateway and the > local mobility anchor MUST be protected using IPsec [RFC-4301] and > using the established security association between them. The > security association of the specific mobile node for which the > signaling message is initiated is not required for protecting these > messages. with The signaling messages, Proxy Binding Update and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor MUST be protected using security associations established between them. The security association of the specific mobile node for which the signaling message is initiated is not required for protecting these messages. We need the MUST above since we have to say that the proxy BU and proxy BAck must be protected, irrespective of whether IPsec or some other mechanism is used. Add one sentence that says The mobile access gateway and the local mobility anchor MUST implement IPsec for protecting the Proxy Mobile IPv6 signaling messages [RFC-4301]. The paragraph that comes after already uses "SHOULD" for using ESP. > IPsec ESP [RFC-4303] in transport mode with mandatory integrity > protection SHOULD be used for protecting the signaling messages. > Confidentiality protection of these messages is not required. Hope that is sufficient. Vijay Sri Gundavelli wrote: > I want some comments on this issue raised by Alper. > > > Also, if I interpret Sec 5.1 [3775], the IPSec is being > mandated, only the use of IPsec ESP is optional. > > -------- > 5.1. Binding Updates to Home Agents > > The mobile node and the home agent MUST use an IPsec security > association to protect the integrity and authenticity of the Binding > Updates and Acknowledgements. Both the mobile nodes and the home > agents MUST support and SHOULD use the Encapsulating Security Payload > (ESP) [6] header in transport mode and MUST use a non-NULL payload > authentication algorithm to provide data origin authentication, > connectionless integrity and optional anti-replay protection. Note > that Authentication Header (AH) [5] is also possible but for brevity > not discussed in this specification. > ------- > > > I'm confused, should the draft say > > "Both LMA and MAG MUST implement IPsec" and > "all the signaling messages SHOULD be protected using IPSec". > > Will this ok, when reviewed by the security folks ? > > or mandate IPsec for this specification and let other draft > relax this in the presence of an alternative approach ? > > Please comment. > > > Sri > > > > > > > > > > >> -----Original Message----- >> From: Alper Yegin [mailto:alper.yegin@yegin.org] >> Sent: Tuesday, August 07, 2007 1:41 AM >> To: 'Sri Gundavelli'; netlmm@ietf.org >> Subject: RE: [netlmm] Issue: Auth Option support >> >>> The issue was related to the use of MUST clause in specifying >>> the IPSec requirement for Proxy Mobile IPv6 protocol. Alper >>> was suggesting that we relax that requirement and potentially >>> leave a room for Auth Option support in future. >> Actually, I didn't mean it specifically for Auth Option. It >> can be anything. >> Given that the security is handled by a separate protocol, >> why lock it down >> to "IPsec", when some other protocol (Auth Option being one >> example) cannot >> be used. >> >>> But, as most people agreed and as supported by Jari, this can >> My understanding was the opposite, especially about Jari's statement. >> >>> always be changed in future when the support for new security >>> mechanisms such as Auth Option are defined for Proxy Mobile IPv6 >>> and that specific document can always modify this requirement. >>> So, no changes will be made to the document on this issue. >> What if Auth Option is good enough as written? >> What if a document in another SDO defines the alternative security >> mechanism? >> >> For the type of interop we are seeking in IETF, "MUST >> implement" is good >> enough. "MUST use" is not necessary. >> >> Alper >> >> >> >> >> >>> >>> Regards >>> Sri >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sun Sep 09 23:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUZhp-0002pq-6F; Sun, 09 Sep 2007 23:12:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUZhn-0002md-R9 for netlmm@ietf.org; Sun, 09 Sep 2007 23:12:55 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUZhm-0006j6-DI for netlmm@ietf.org; Sun, 09 Sep 2007 23:12:55 -0400 X-IronPort-AV: E=Sophos;i="4.20,228,1186383600"; d="scan'208";a="214977465" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Sep 2007 20:12:53 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8A3CrPK008499; Sun, 9 Sep 2007 20:12:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8A3CjF0010520; Mon, 10 Sep 2007 03:12:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 20:12:49 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 20:12:48 -0700 From: "Sri Gundavelli" To: "'Shyam H'" , References: <013f01c7f04f$ebbd1ab0$d4f6200a@amer.cisco.com> <4c174b660709071621s399377e5n9e4347c6f9191fd8@mail.gmail.com> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt Date: Sun, 9 Sep 2007 20:12:48 -0700 Message-ID: <005e01c7f358$7767a020$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfxpdIXFnAM2QyGQVC7fQT6cGgB0QBsgFAA In-Reply-To: <4c174b660709071621s399377e5n9e4347c6f9191fd8@mail.gmail.com> X-OriginalArrivalTime: 10 Sep 2007 03:12:49.0018 (UTC) FILETIME=[77750DA0:01C7F358] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5536; t=1189393973; x=1190257973; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-proxymip6 -03.txt |Sender:=20; bh=I3mTzyCgVWT8dYlavm1+xGa626GHwpA2C7koxbuoLHc=; b=GFDIBUVnQUy16/PLhLDFdL2VMAYKxna6qchK7VHdWosAbSj5wn7JsaOVJNiOyKjvhcr7mgMl OD2XhhfEhTLHOWjKt0rdQT3BH9W/JcE7WVIv1q2e/bWWm4D39uLs79Lp; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Shyam, Please see inline ... > -----Original Message----- > From: Shyam H [mailto:shyam.hemad@gmail.com] > Sent: Friday, September 07, 2007 4:21 PM > To: netlmm@ietf.org > Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt > > Dear Sri > > > Thank you for updating the Proxy-MIP6 draft. We reviewed and discussed > the draft in detail and these are our comments. > > First, the draft is written nicely, organized very well; enjoyed > reading it; we thank the authors for the good work. > > > We did not like the timestamp format change; it was not needed, we > have to make changes to our code.; but fine. > > In MAG signaling, you should add the RS and RA flow related points; > You should add a small section with couple of lines on what the MAG > does when RA arrives; this is missing; it is there in the seq diagram. > Ok. > Lot of new error checking rules; but good; very detailed > > You should specify when the HA should consider the timestamp from MAG > as as outof sync. Suggest some time window like 1 second; define a > protocol variable. Or, make NTP use a must. Not an issue for us; we > have RO. > Ok. > On PBU and PBA retransmissions or timeouts, please say it is as per > rfc3775; or define new protocol constants > This is a good point. I've worked on the text for this and other points you raised, you will see it in the next rev. > PBA cannot have the type-II routing header, can it ? there is no home > address ; you should mention this; to avoid interop problems. > Format of the PBA is given. Its not there in it. But, if it needs to be explicitly mentioned, will do that. > > Hope this review helps. Thank you again for completing this > document; good job. > Thanks for the comments. Sri > > - Shyam > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: Wednesday, September 05, 2007 11:20 PM > > > To: i-d-announce@ietf.org > > > Cc: netlmm@ietf.org > > > Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > This draft is a work item of the Network-based Localized > > > Mobility Management Working Group of the IETF. > > > > > > > > > Title : Proxy Mobile IPv6 > > > Author(s) : S. Gundavelli, et al. > > > Filename : draft-ietf-netlmm-proxymip6-03.txt > > > Pages : 55 > > > Date : 2007-09-06 > > > > > > This specification describes a network-based mobility management > > > protocol. It is called Proxy Mobile IPv6 and is based on > Mobile IPv6 > > > [RFC-3775]. This protocol enables mobility support to a > host without > > > requiring its participation in any mobility related > signaling. The > > > design principle in the case of network-based mobility management > > > protocol relies on the network being in control of the mobility > > > management. The mobility entities in the network are > responsible for > > > tracking the movements of the host and initiating the required > > > mobility signaling on its behalf. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-03.txt > > > > > > To remove yourself from the I-D Announcement list, send a > message to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > > the body of > > > the message. > > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > 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-ietf-netlmm-proxymip6-03.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-ietf-netlmm-proxymip6-03.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. > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sun Sep 09 23:14:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUZiR-0004q5-Hc; Sun, 09 Sep 2007 23:13:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUZiP-0004Z9-IH for netlmm@ietf.org; Sun, 09 Sep 2007 23:13:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUZiO-0006jo-4G for netlmm@ietf.org; Sun, 09 Sep 2007 23:13:33 -0400 X-IronPort-AV: E=Sophos;i="4.20,228,1186383600"; d="scan'208";a="175168631" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 09 Sep 2007 20:13:31 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8A3DV9a006292; Sun, 9 Sep 2007 20:13:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8A3DUEw010840; Mon, 10 Sep 2007 03:13:30 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 20:13:30 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 20:13:30 -0700 From: "Sri Gundavelli" To: "'Vijay Devarapalli'" , "'Alper Yegin'" References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> <46E4B02C.5010101@azairenet.com> Subject: RE: [netlmm] Issue: Auth Option support Date: Sun, 9 Sep 2007 20:13:29 -0700 Message-ID: <005f01c7f358$8ff1f960$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfzVOlI/0yZah5ISJ2hahCBVDo86AAA5BOw In-Reply-To: <46E4B02C.5010101@azairenet.com> X-OriginalArrivalTime: 10 Sep 2007 03:13:30.0164 (UTC) FILETIME=[8FFB6F40:01C7F358] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5523; t=1189394011; x=1190258011; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Auth=20Option=20support |Sender:=20; bh=cdgqa/yRuFxooj9FtS5hDzQn2YCr1v17fEzLeesuKCo=; b=EtUj+3hfh8A+Jw2R1UQPNzE4tbaDTpPhXP98lqyArjZOkSnTew2PxZXFKhaFe4YAmNOx14p4 g47+N9cIrUBCiHIpUmV8gTVrMVMguGVznlHajtMttTR+RzMFUgSxQ1vs; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay/Raj, I agree. Will make these changes. Sri > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > Sent: Sunday, September 09, 2007 7:47 PM > To: Sri Gundavelli; 'Alper Yegin' > Cc: netlmm@ietf.org > Subject: Re: [netlmm] Issue: Auth Option support > > Sri, > > I agree with "SHOULD" for using IPsec and "MUST" for > supporting IPsec on > the MAG and the LMA. > > If thats the consensus, we need to modify a few sentences in > the draft. > > In section 4, replace > > > The signaling messages, Proxy Binding Update and Proxy Binding > > Acknowledgement, exchanged between the mobile access > gateway and the > > local mobility anchor MUST be protected using IPsec > [RFC-4301] and > > using the established security association between them. The > > security association of the specific mobile node for which the > > signaling message is initiated is not required for > protecting these > > messages. > > with > > The signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access > gateway and the > local mobility anchor MUST be protected using security > associations > established between them. The security association of the specific > mobile node for which the signaling message is initiated is not > required for protecting these messages. > > We need the MUST above since we have to say that the proxy BU > and proxy > BAck must be protected, irrespective of whether IPsec or some other > mechanism is used. > > Add one sentence that says > > The mobile access gateway and the local mobility anchor MUST > implement IPsec for protecting the Proxy Mobile IPv6 signaling > messages [RFC-4301]. > > The paragraph that comes after already uses "SHOULD" for using ESP. > > > IPsec ESP [RFC-4303] in transport mode with mandatory integrity > > protection SHOULD be used for protecting the signaling messages. > > Confidentiality protection of these messages is not required. > > Hope that is sufficient. > > Vijay > > > Sri Gundavelli wrote: > > I want some comments on this issue raised by Alper. > > > > > > Also, if I interpret Sec 5.1 [3775], the IPSec is being > > mandated, only the use of IPsec ESP is optional. > > > > -------- > > 5.1. Binding Updates to Home Agents > > > > The mobile node and the home agent MUST use an IPsec security > > association to protect the integrity and authenticity of > the Binding > > Updates and Acknowledgements. Both the mobile nodes and the home > > agents MUST support and SHOULD use the Encapsulating > Security Payload > > (ESP) [6] header in transport mode and MUST use a > non-NULL payload > > authentication algorithm to provide data origin authentication, > > connectionless integrity and optional anti-replay > protection. Note > > that Authentication Header (AH) [5] is also possible but > for brevity > > not discussed in this specification. > > ------- > > > > > > I'm confused, should the draft say > > > > "Both LMA and MAG MUST implement IPsec" and > > "all the signaling messages SHOULD be protected using IPSec". > > > > Will this ok, when reviewed by the security folks ? > > > > or mandate IPsec for this specification and let other draft > > relax this in the presence of an alternative approach ? > > > > Please comment. > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > >> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >> Sent: Tuesday, August 07, 2007 1:41 AM > >> To: 'Sri Gundavelli'; netlmm@ietf.org > >> Subject: RE: [netlmm] Issue: Auth Option support > >> > >>> The issue was related to the use of MUST clause in specifying > >>> the IPSec requirement for Proxy Mobile IPv6 protocol. Alper > >>> was suggesting that we relax that requirement and potentially > >>> leave a room for Auth Option support in future. > >> Actually, I didn't mean it specifically for Auth Option. It > >> can be anything. > >> Given that the security is handled by a separate protocol, > >> why lock it down > >> to "IPsec", when some other protocol (Auth Option being one > >> example) cannot > >> be used. > >> > >>> But, as most people agreed and as supported by Jari, this can > >> My understanding was the opposite, especially about Jari's > statement. > >> > >>> always be changed in future when the support for new security > >>> mechanisms such as Auth Option are defined for Proxy Mobile IPv6 > >>> and that specific document can always modify this requirement. > >>> So, no changes will be made to the document on this issue. > >> What if Auth Option is good enough as written? > >> What if a document in another SDO defines the alternative security > >> mechanism? > >> > >> For the type of interop we are seeking in IETF, "MUST > >> implement" is good > >> enough. "MUST use" is not necessary. > >> > >> Alper > >> > >> > >> > >> > >> > >>> > >>> Regards > >>> Sri > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sun Sep 09 23:57:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUaNc-0002MU-V0; Sun, 09 Sep 2007 23:56:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUaNb-0002Gs-GL for netlmm@ietf.org; Sun, 09 Sep 2007 23:56:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUaNY-0007eZ-Va for netlmm@ietf.org; Sun, 09 Sep 2007 23:56:07 -0400 X-IronPort-AV: E=Sophos;i="4.20,229,1186383600"; d="scan'208";a="214985258" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Sep 2007 20:56:04 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8A3u4Hb002758 for ; Sun, 9 Sep 2007 20:56:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8A3tAat005366; Mon, 10 Sep 2007 03:55:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 20:55:10 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 20:55:09 -0700 From: "Sri Gundavelli" To: "'Christian Vogt'" References: <46DFB7A4.9010209@nomadiclab.com> Date: Sun, 9 Sep 2007 20:55:09 -0700 Message-ID: <006101c7f35e$61ef5a20$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfwXnExe6oZOl5aQOCii005cqOnggC/aV5A In-Reply-To: <46DFB7A4.9010209@nomadiclab.com> X-OriginalArrivalTime: 10 Sep 2007 03:55:10.0003 (UTC) FILETIME=[62009830:01C7F35E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2035; t=1189396564; x=1190260564; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20Remaining=20Open=20Issues |Sender:=20; bh=OzxpY0RkBKtpJsW3sP+Amrr9X2bs6NiqCn72bJ/BIu8=; b=kfXt59fA5ojEXOOsY3MSQcn8I9eXfuEszPnExZ40LpqqeGp10fly4wVc09MZPIiyG8xMQX+R 4ZNP02gCEw6yR+sG1HBIw1AI9NKlokN5EATQ/GUa2jc8hsYnZAft3qIn; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'NetLMM Mailing List' Subject: [netlmm] RE: Remaining Open Issues X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Change log between the -01 and 03 version of the docs. Fixes the following issues: - Removed assumptions on the acquiring MN-Id as part of Access Authentication (Vidya). - Acquiring the MN identifier and related considerations. Based on the input from Jari. - Added section on the Timestamp/seq number considerations (Issue 166) - Changed the timestamp format. (Alex) - Added lot more details on LMA processing of the PBU. - Clearly seperated the message processing rules for initial PBU's, Reregistrations and Deregistrations (Jonne) - Added lot more details on MAG sending the PBU and processing the PBA - Added message formats for the tunneled packets. - Removed duplicate text in the MN section and in other places. Fixed the editorial issues (Issue 157) - Defined the order for sending the RA's only after completing the signaling (Issue 165 & Issue 155) - Added the flow sequence in Section 3. But, will add some more text in the next rev. But, this issue can be closed (Issue 152). - Defined the link-local address option. For fixing the link-local address collision issue (Julien). Again, please review and comment on the draft. We want to go last call in a week. We will update the draft in between. Thanks Sri > -----Original Message----- > From: Christian Vogt [mailto:christian.vogt@nomadiclab.com] > Sent: Thursday, September 06, 2007 1:18 AM > To: Sri Gundavelli > Cc: NetLMM Mailing List > Subject: Remaining Open Issues > > Sri, > > thanks for revising the P-MIPv6 specification. There are a > few open issues left > in our tracker [1]. In order to help folks form an opinion > on whether those > issues can be considered resolved now, may I ask you to send > a brief statement, > per open issue, on how the issue got addressed by the revised > specification? > > I believe this would be helpful for everyone. > > Thank you, > - Christian > > [1] http://www3.tools.ietf.org/wg/netlmm/trac/report/1/ > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 04:20:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUeVA-0004Jy-LQ; Mon, 10 Sep 2007 04:20:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUeV9-0004DZ-OC for netlmm@ietf.org; Mon, 10 Sep 2007 04:20:11 -0400 Received: from mout.perfora.net ([74.208.4.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUeV8-0005QY-VO for netlmm@ietf.org; Mon, 10 Sep 2007 04:20:11 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IUeUz2OGw-0008RA; Mon, 10 Sep 2007 04:20:08 -0400 From: "Alper Yegin" To: "'Narayanan, Vidya'" , "'Sri Gundavelli'" , "'Julien Laganier'" , Subject: RE: [netlmm] Issue: Auth Option support Date: Mon, 10 Sep 2007 11:19:49 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQAATTUOAAf2sh0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Message-Id: <0MKp8S-1IUeUz2OGw-0008RA@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18i2SRSepea/MZg2nlHy/UiJw4S7CoVGk7Zkqr rm1bNwfbpRUgxj+ZETgP0JEmx3a8xDALMxWdXJ3IHbW6mWbSc2 xqwCJjqoAeaDUoWcKpb9w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org For interop "SHOULD implement and use", or even "SHOULD use" (like Julien explained) is fine. "SHOULD" means "you better know what you are doing if you don't follow", and that's exactly the case. If both ends are using some other mechanism and they know what each other supports, they should not have to worry about (and implement) the mechanism in the base spec. This is what SHOULD is for. Alper > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Friday, September 07, 2007 10:27 PM > To: Sri Gundavelli; Julien Laganier; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Auth Option support > > All, > On this topic, I believe we must have a mandatory to implement mechanism > specified for standards track publication. We can leave the use at > "RECOMMENDED" or "SHOULD", but, we need a "MUST" on what the LMA and MAG > need to implement. > > I had run this by the security directorate at the Chicago meeting and my > understanding is that as long as we have "MUST implement IPsec" and > "SHOULD use IPsec", it would be fine. > > In other words, the SHOULD vs. MUST that we want to place on using IPsec > can be discussed, but, the "MUST" on implementation is non-negotiable. > > This is inline with my understanding on what we need to state for a > complete specification. Given that channel security of signaling > messages is mandatory, unless we have at least one common denominator > that the MAG and LMA implementors will implement, we cannot ensure > interoperability. If they support multiple common mechanisms and chose > to use something other than IPsec, that's fine - hence, the "SHOULD" on > usage. > > Hope that helps. > > Thanks, > Vidya > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Friday, September 07, 2007 10:10 AM > > To: 'Julien Laganier'; netlmm@ietf.org > > Subject: RE: [netlmm] Issue: Auth Option support > > > > Hi Julien, > > > > > > > > > -----Original Message----- > > > From: julien laganier [mailto:julien.laganier@gmail.com] On > > Behalf Of > > > Julien Laganier > > > Sent: Friday, September 07, 2007 5:29 AM > > > To: netlmm@ietf.org > > > Cc: Sri Gundavelli; 'Alper Yegin' > > > Subject: Re: [netlmm] Issue: Auth Option support > > > > > > Hi Sri, > > > > > > On Thursday 06 September 2007, Sri Gundavelli wrote: > > > > I'm confused, should the draft say > > > > > > > > "Both LMA and MAG MUST implement IPsec" and "all the signaling > > > > messages SHOULD be protected using IPSec". > > > > > > > > Will this ok, when reviewed by the security folks ? > > > > > > > > or mandate IPsec for this specification and let other draft relax > > > > this in the presence of an alternative approach ? > > > > > > > > Please comment. > > > > > > Somehow, "MUST implement" and "SHOULD use" together seems a bit > > > tautologic. > > > > > > To me "SHOULD use" is sufficient since it covers both of the two > > > possibles cases: > > > > > > - deployment follows the SHOULD recommendation, it uses IPsec to > > > protect PMIPv6, in which case it supports it, since it's > > using it :), > > > or > > > > > > - deployment ignores the SHOULD recommendation, does not > > uses IPSec, > > > in which case it is useless to implement it since it's not used... > > > > > > I'd prefer having "MUST protect integrity of signalling > > messages, and > > > SHOULD use IPsec ESP to protect integrity of those messages". > > > We might > > > also add "MAY use IPsec AH". > > > > > > > > > I agree. I'm not against allowing other approaches. I'm only > > concerned, if we can leave the draft saying, "MUST protect > > integrity of signalling messages", with out specifying IPsec > > or some other approach. If that will pass the security > > review. We may have to state that IPsec MUST be used or some > > other approach, say Auth-Option MUST be used. Not sure, if we > > can leave this blank. > > > > Sri > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 05:28:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUfZ5-0001K3-AU; Mon, 10 Sep 2007 05:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUfZ4-0001Jy-Mz for netlmm@ietf.org; Mon, 10 Sep 2007 05:28:18 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUfZ3-0007Ab-Fw for netlmm@ietf.org; Mon, 10 Sep 2007 05:28:18 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1439494uge for ; Mon, 10 Sep 2007 02:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=PCBmhfvDf066lSjJzuEY4MNdWBmvIQBUxlGl2y057Y4=; b=lY5svSfSFLOodxhTSQkmVS8EhTLfd1GNTL2MBT0o70F5/XBOXfrZzvQkCZ65zT0ualrnGE7VOHL7CzHXocf9WmQcRaeZuc4S2Xo34VDRpGC+EAg5D9Vmmpzj10ZLdaNukfLx12VO/ZM2kruSfN3LSQM6YTNyZoVx68fIPgJYbBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=eXNFpl2V1ha8xBITrfM6G35XWKcrPMJ5jTKKdtecv5MW8zbeN+MnbLLQcVbpDbUUU0Ps6FK/WEiDhekYueVgswngBz1L8OdKcOdf2G+8iSnEXRk+By7qrgAWhzdlFTf2cKEnRB2uRalwoD/us97G8p/ywW2unne4wBmzfw++LUQ= Received: by 10.67.32.13 with SMTP id k13mr4517598ugj.1189416496486; Mon, 10 Sep 2007 02:28:16 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e34sm9114686ugd.2007.09.10.02.28.13 (version=SSLv3 cipher=OTHER); Mon, 10 Sep 2007 02:28:14 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] Issue: Auth Option support Date: Mon, 10 Sep 2007 11:28:08 +0200 User-Agent: KMail/1.9.6 References: <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> <46E4B02C.5010101@azairenet.com> In-Reply-To: <46E4B02C.5010101@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709101128.08546.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vijay, One comment below, On Monday 10 September 2007, Vijay Devarapalli wrote: > Sri, > > I agree with "SHOULD" for using IPsec and "MUST" for supporting IPsec > on the MAG and the LMA. > > If thats the consensus, we need to modify a few sentences in the > draft. > > In section 4, replace > > > The signaling messages, Proxy Binding Update and Proxy Binding > > Acknowledgement, exchanged between the mobile access gateway and > > the local mobility anchor MUST be protected using IPsec [RFC-4301] > > and using the established security association between them. The > > security association of the specific mobile node for which the > > signaling message is initiated is not required for protecting these > > messages. > > with > > The signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access gateway and > the local mobility anchor MUST be protected using security > associations established between them. The security association of > the specific mobile node for which the signaling message is initiated > is not required for protecting these messages. > > We need the MUST above since we have to say that the proxy BU and > proxy BAck must be protected, irrespective of whether IPsec or some > other mechanism is used. I understand you want to say that integrity and data origin authentication are MUST's. I'm thus suggesting a minor change to your text above (rest is fine with me): The Proxy Binding Update and Proxy Binding Acknowledgement signaling messages exchanged between the MAG and LMA MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. A security association with the mobile node for which the signaling message is issued is not required for protection of these messages. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 07:27:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUhPw-0002ec-KF; Mon, 10 Sep 2007 07:27:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUhPu-0002eT-Sy for netlmm@ietf.org; Mon, 10 Sep 2007 07:26:58 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUhPt-00017p-Hp for netlmm@ietf.org; Mon, 10 Sep 2007 07:26:58 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IUhPn33gN-0007S1; Mon, 10 Sep 2007 07:26:57 -0400 From: "Alper Yegin" To: Date: Mon, 10 Sep 2007 14:26:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfwTglzGxi+UdpsQHGbbtafLERnrAAAWvZQANEcb4A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <013f01c7f04f$ebbd1ab0$d4f6200a@amer.cisco.com> Message-Id: <0MKpCa-1IUhPn33gN-0007S1@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/FL8bmRlDH3WVGLIReixZq7TWuBm8PQQO8/b4 N7d3QQLypEZVQTu+s+dFzwx1YZusPShut5eiXKE6PCp7C/ufZl YP433ukXg97+Nh9UQxr6A== X-Spam-Score: -0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [netlmm] Significance of MN-Identifier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org What's the significance of MN-Identifier as carried in PBU? Is it for the sake of identifying the MN during dynamic HNP assignment in-band with PMIP? If so, given that the HNP may also be assigned during network access authentication (out-of band with PMIP, as commonly done in integrated bootstrapping scenarios), we shall not mandate that the MN-identifier identifies the real MN. Another way of using of MN-identifier is to identify the "proxy MN" (MAG) with RFC 4285. Alper _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 08:56:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUiok-0003Gg-N9; Mon, 10 Sep 2007 08:56:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUioj-0003Ga-I7 for netlmm@ietf.org; Mon, 10 Sep 2007 08:56:41 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUioi-000534-Ui for netlmm@ietf.org; Mon, 10 Sep 2007 08:56:41 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8ACuXr15555; Mon, 10 Sep 2007 12:56:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Auth Option support Date: Mon, 10 Sep 2007 07:56:31 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371169E8C2C@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Auth Option support Thread-Index: AcfxSsGFlDvDz/RAQJWYV4inKIWpywAJhYcQAATTUOAAiU6I0A== References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net><01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com><200709071429.19318.julien.IETF@laposte.net> <010801c7f171$f3997f30$d4f6200a@amer.cisco.com> From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Sri Gundavelli" , "Julien Laganier" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hope this is never too late. My understanding is that for any implementation to claim compliancy to any RFC, that implementation MUST implement all "MUST" and "SHOULD". Having said that, I am not sure why we need this distinction of "MUST implement IPsec" and "SHOULD use IPsec", that is exactly the meaning of "SHOULD use IPsec". Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Friday, September 07, 2007 2:27 PM > To: Sri Gundavelli; Julien Laganier; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Auth Option support >=20 > All, > On this topic, I believe we must have a mandatory to=20 > implement mechanism specified for standards track=20 > publication. We can leave the use at "RECOMMENDED" or=20 > "SHOULD", but, we need a "MUST" on what the LMA and MAG need=20 > to implement. =20 >=20 > I had run this by the security directorate at the Chicago=20 > meeting and my understanding is that as long as we have "MUST=20 > implement IPsec" and "SHOULD use IPsec", it would be fine. =20 >=20 > In other words, the SHOULD vs. MUST that we want to place on=20 > using IPsec can be discussed, but, the "MUST" on=20 > implementation is non-negotiable. =20 >=20 > This is inline with my understanding on what we need to state=20 > for a complete specification. Given that channel security of=20 > signaling messages is mandatory, unless we have at least one=20 > common denominator that the MAG and LMA implementors will=20 > implement, we cannot ensure interoperability. If they=20 > support multiple common mechanisms and chose to use something=20 > other than IPsec, that's fine - hence, the "SHOULD" on usage.=20 >=20 > Hope that helps.=20 >=20 > Thanks, > Vidya >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Friday, September 07, 2007 10:10 AM > > To: 'Julien Laganier'; netlmm@ietf.org > > Subject: RE: [netlmm] Issue: Auth Option support > >=20 > > Hi Julien, > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: julien laganier [mailto:julien.laganier@gmail.com] On > > Behalf Of > > > Julien Laganier > > > Sent: Friday, September 07, 2007 5:29 AM > > > To: netlmm@ietf.org > > > Cc: Sri Gundavelli; 'Alper Yegin' > > > Subject: Re: [netlmm] Issue: Auth Option support > > >=20 > > > Hi Sri, > > >=20 > > > On Thursday 06 September 2007, Sri Gundavelli wrote: > > > > I'm confused, should the draft say > > > > > > > > "Both LMA and MAG MUST implement IPsec" and "all the signaling=20 > > > > messages SHOULD be protected using IPSec". > > > > > > > > Will this ok, when reviewed by the security folks ? > > > > > > > > or mandate IPsec for this specification and let other=20 > draft relax=20 > > > > this in the presence of an alternative approach ? > > > > > > > > Please comment. > > >=20 > > > Somehow, "MUST implement" and "SHOULD use" together seems a bit=20 > > > tautologic. > > >=20 > > > To me "SHOULD use" is sufficient since it covers both of the two=20 > > > possibles cases: > > >=20 > > > - deployment follows the SHOULD recommendation, it uses IPsec to=20 > > > protect PMIPv6, in which case it supports it, since it's > > using it :), > > > or > > >=20 > > > - deployment ignores the SHOULD recommendation, does not > > uses IPSec, > > > in which case it is useless to implement it since it's not used... > > >=20 > > > I'd prefer having "MUST protect integrity of signalling > > messages, and > > > SHOULD use IPsec ESP to protect integrity of those messages". > > > We might > > > also add "MAY use IPsec AH". > > >=20 > >=20 > >=20 > > I agree. I'm not against allowing other approaches. I'm only=20 > > concerned, if we can leave the draft saying, "MUST protect=20 > integrity=20 > > of signalling messages", with out specifying IPsec or some other=20 > > approach. If that will pass the security review. We may=20 > have to state=20 > > that IPsec MUST be used or some other approach, say=20 > Auth-Option MUST=20 > > be used. Not sure, if we can leave this blank. > >=20 > > Sri > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 10:27:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkF2-0000jS-It; Mon, 10 Sep 2007 10:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkF1-0000jM-Ov for netlmm@ietf.org; Mon, 10 Sep 2007 10:27:55 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUkF0-0007Bg-GL for netlmm@ietf.org; Mon, 10 Sep 2007 10:27:55 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8AEPT102875; Mon, 10 Sep 2007 14:25:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Auth Option support Date: Mon, 10 Sep 2007 09:27:40 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E4B02C.5010101@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Auth Option support Thread-Index: AcfzVRKastzqW86cS12AQItlFqDoJwAVYavw References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> <46E4B02C.5010101@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Sri Gundavelli" , "Alper Yegin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org =20 > Subject: Re: [netlmm] Issue: Auth Option support >=20 > Sri, >=20 > I agree with "SHOULD" for using IPsec and "MUST" for=20 > supporting IPsec on the MAG and the LMA. >=20 > If thats the consensus, we need to modify a few sentences in=20 > the draft. >=20 > In section 4, replace >=20 > > The signaling messages, Proxy Binding Update and Proxy Binding > > Acknowledgement, exchanged between the mobile access=20 > gateway and the > > local mobility anchor MUST be protected using IPsec=20 > [RFC-4301] and > > using the established security association between them. The > > security association of the specific mobile node for which the > > signaling message is initiated is not required for=20 > protecting these > > messages. >=20 > with >=20 > The signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access=20 > gateway and the > local mobility anchor MUST be protected using security=20 > associations > established between them. The security association of the specific > mobile node for which the signaling message is initiated is not > required for protecting these messages. >=20 > We need the MUST above since we have to say that the proxy BU=20 > and proxy BAck must be protected, irrespective of whether=20 > IPsec or some other mechanism is used. [Ahmad] Hi Vijay, As far as I remember, the whole security concept of using a per-Node SA for PMIPv6 was based on the use of IPsec. Although, I see why you proposed the text but I still see a problem here. For example, the above text allows the use of an authentication option similar to FA-HA AE to secure the P-BU/P-BA.=20 Now, since allowing a per-Node SA to be used in PMIPv6 was based on the use of IPsec, I believe we clearly need to keep that as part of the spec text. What about the following slight modification to what you just proposed: The signaling messages, Proxy Binding Update and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor MUST be protected using a security association established between them. If IPsec is used, the security association of the specific mobile node for which the signaling message is initiated=20 is not required for protecting these messages. Thanks, Ahmad >=20 > Add one sentence that says >=20 > The mobile access gateway and the local mobility anchor MUST > implement IPsec for protecting the Proxy Mobile IPv6 signaling > messages [RFC-4301]. >=20 > The paragraph that comes after already uses "SHOULD" for using ESP. >=20 > > IPsec ESP [RFC-4303] in transport mode with mandatory integrity > > protection SHOULD be used for protecting the signaling messages. > > Confidentiality protection of these messages is not required. >=20 > Hope that is sufficient. >=20 > Vijay >=20 >=20 > Sri Gundavelli wrote: > > I want some comments on this issue raised by Alper. > >=20 > >=20 > > Also, if I interpret Sec 5.1 [3775], the IPSec is being=20 > mandated, only=20 > > the use of IPsec ESP is optional. > >=20 > > -------- > > 5.1. Binding Updates to Home Agents > >=20 > > The mobile node and the home agent MUST use an IPsec security > > association to protect the integrity and authenticity of=20 > the Binding > > Updates and Acknowledgements. Both the mobile nodes and the home > > agents MUST support and SHOULD use the Encapsulating=20 > Security Payload > > (ESP) [6] header in transport mode and MUST use a=20 > non-NULL payload > > authentication algorithm to provide data origin authentication, > > connectionless integrity and optional anti-replay=20 > protection. Note > > that Authentication Header (AH) [5] is also possible but=20 > for brevity > > not discussed in this specification. > > ------- > >=20 > >=20 > > I'm confused, should the draft say > >=20 > > "Both LMA and MAG MUST implement IPsec" and "all the signaling=20 > > messages SHOULD be protected using IPSec". > >=20 > > Will this ok, when reviewed by the security folks ? > >=20 > > or mandate IPsec for this specification and let other draft=20 > relax this=20 > > in the presence of an alternative approach ? > >=20 > > Please comment. > >=20 > >=20 > > Sri > >=20 > >=20 > >=20 > >=20 > > =20 > >=20 > >=20 > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >> Sent: Tuesday, August 07, 2007 1:41 AM > >> To: 'Sri Gundavelli'; netlmm@ietf.org > >> Subject: RE: [netlmm] Issue: Auth Option support > >> > >>> The issue was related to the use of MUST clause in specifying the=20 > >>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was=20 > >>> suggesting that we relax that requirement and potentially leave a=20 > >>> room for Auth Option support in future. > >> Actually, I didn't mean it specifically for Auth Option. It can be=20 > >> anything. > >> Given that the security is handled by a separate protocol,=20 > why lock=20 > >> it down to "IPsec", when some other protocol (Auth Option being one > >> example) cannot > >> be used. > >> > >>> But, as most people agreed and as supported by Jari, this can > >> My understanding was the opposite, especially about Jari's=20 > statement. > >> > >>> always be changed in future when the support for new security=20 > >>> mechanisms such as Auth Option are defined for Proxy=20 > Mobile IPv6 and=20 > >>> that specific document can always modify this requirement. > >>> So, no changes will be made to the document on this issue. > >> What if Auth Option is good enough as written? > >> What if a document in another SDO defines the alternative security=20 > >> mechanism? > >> > >> For the type of interop we are seeking in IETF, "MUST=20 > implement" is=20 > >> good enough. "MUST use" is not necessary. > >> > >> Alper > >> > >> > >> > >> > >> > >>> > >>> Regards > >>> Sri > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 10:36:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkNV-0004cI-0Q; Mon, 10 Sep 2007 10:36:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkNT-0004cB-Sa for netlmm@ietf.org; Mon, 10 Sep 2007 10:36:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUkNS-0007Xa-Ks for netlmm@ietf.org; Mon, 10 Sep 2007 10:36:39 -0400 X-IronPort-AV: E=Sophos;i="4.20,231,1186383600"; d="scan'208";a="215265491" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Sep 2007 07:36:38 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8AEacsm010666; Mon, 10 Sep 2007 07:36:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8AEaYb9005212; Mon, 10 Sep 2007 14:36:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 07:36:10 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 07:36:06 -0700 From: "Sri Gundavelli" To: "'Alper Yegin'" , References: <013f01c7f04f$ebbd1ab0$d4f6200a@amer.cisco.com> <0MKpCa-1IUhPn33gN-0007S1@mrelay.perfora.net> Subject: RE: [netlmm] Significance of MN-Identifier Date: Mon, 10 Sep 2007 07:36:07 -0700 Message-ID: <008301c7f3b7$ef599a20$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfwTglzGxi+UdpsQHGbbtafLERnrAAAWvZQANEcb4AACNC8MA== In-Reply-To: <0MKpCa-1IUhPn33gN-0007S1@mrelay.perfora.net> X-OriginalArrivalTime: 10 Sep 2007 14:36:10.0705 (UTC) FILETIME=[EE5DFC10:01C7F3B7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1484; t=1189434998; x=1190298998; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Significance=20of=20MN-Identifier |Sender:=20; bh=eRgxD4QayEGZjXtzINHja7Uw1wM4F0Hvqnpp+QyeuNw=; b=MwC46sFLsljqrACg7rg9a78oYd4tU01zsfEzgX3GND/v2trX3JH8JglVzSwqmUmgE1acjyjE nbcqoClk8sXhO3Uys5toN8vWia37TeATrS5Y2nf+Ax820CiGzDnRovNfgsqoQG7tTIkoYCKKRW JQmiFTroYOch7Ju7hlrsVkqh8=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, There were some comments on this from Jari. See the section on "Acquiring the MN identifier" (Sec 6.6). The MN-Identifier may not be the real identifier of the MN. But, the LMA and MAG must be able to identify a MN using this identifier and exchange it in the signaling messages. Also, but, it is not the identifier of the MAG. We are creating a BCE state and that is for a MN. The identifier of the MAG is used for authenticating and authorizing purposes. And this identifier changes at each handoff and so what is stored in the BCE is the MN identifier. Sri > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Monday, September 10, 2007 4:27 AM > To: netlmm@ietf.org > Subject: [netlmm] Significance of MN-Identifier > > What's the significance of MN-Identifier as carried in PBU? > > Is it for the sake of identifying the MN during dynamic HNP assignment > in-band with PMIP? > > If so, given that the HNP may also be assigned during network access > authentication (out-of band with PMIP, as commonly done in integrated > bootstrapping scenarios), we shall not mandate that the MN-identifier > identifies the real MN. > > Another way of using of MN-identifier is to identify the > "proxy MN" (MAG) > with RFC 4285. > > Alper > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 10:41:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkSA-00029o-Pc; Mon, 10 Sep 2007 10:41:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkS9-00026Y-IP for netlmm@ietf.org; Mon, 10 Sep 2007 10:41:29 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUkS7-0007hD-Ud for netlmm@ietf.org; Mon, 10 Sep 2007 10:41:29 -0400 Received: from rly35f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly35f.srv.mailcontrol.com (MailControl) with ESMTP id l8AEeOOG017516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Sep 2007 15:40:55 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly35f.srv.mailcontrol.com (MailControl) id l8AEeGGX016638 for netlmm@ietf.org; Mon, 10 Sep 2007 15:40:16 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly35f-eth0.srv.mailcontrol.com (envelope-sender Genadi.Velev@eu.panasonic.com) (MIMEDefang) with ESMTP id l8AEeC8x016036; Mon, 10 Sep 2007 15:40:16 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 4f08_ad06a58c_5faa_11dc_84d4_0030482aac25; Mon, 10 Sep 2007 16:32:35 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091015543496-3564 ; Mon, 10 Sep 2007 15:54:34 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.127,BAYES_00: -1.665,TOTAL_SCORE: -1.538 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Mon, 10 Sep 2007 15:55:08 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] RE: Remaining Open Issues In-Reply-To: <006101c7f35e$61ef5a20$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] RE: Remaining Open Issues Thread-Index: AcfwXnExe6oZOl5aQOCii005cqOnggC/aV5AABPjXQA= References: <46DFB7A4.9010209@nomadiclab.com> <006101c7f35e$61ef5a20$d5f6200a@amer.cisco.com> To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48A993@lan-ex-02.panasonic.de> Date: Mon, 10 Sep 2007 15:54:18 +0200 From: "Genadi Velev" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.70.1.145 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: NetLMM Mailing List X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, going through the -03 version of the document I stumbled over some editorial issues.=20 1) Page 29, 2nd paragraph says: "One of the workarounds for this issue is to set the DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that will force the mobile node to redo DAD operation every time the interface comes up, even when DNAv6 does detect a link change." The last part should be: "... to redo DAD operation every time the interface identifies a handover, even when DNAv6 does not detect a link change." 2) Several parts of the document specify that NAI option must be included in the Proxy Binding Update and Proxy Binding Acknowledgement messages. However, in section 8 "Message Formats" nothing is mentioned about NAI option. Do you plan to include a descriptive text in the next document version? 3) Sections 8.1 and 8.2 provide no description about the mobility options in both Proxy Binding Update and Proxy Binding Acknowledgement messages. I'd suggest to modify figures 11 and 12 and include some descriptive text.=20 An example for figure 11 can be as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Mobility options . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Additional text in section 8.1 is necessary to describe the meaning of "Mobility Options". For example: =20 "Variable-length field of such length that the complete Proxy Binding Update message is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The Proxy Binding Update message may include zero or more of the following options: * NAI Option (???) * Home Network Prefix Option * Link-local Address Option * Timestamp Option " A corresponding text shall be included also in section 8.2, where the list with possible mobility option should be extended with "Status Value Option". regards, Genadi > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Monday, September 10, 2007 5:55 AM > To: 'Christian Vogt' > Cc: 'NetLMM Mailing List' > Subject: [netlmm] RE: Remaining Open Issues >=20 > =20 > Change log between the -01 and 03 version of the docs. >=20 >=20 > Fixes the following issues: >=20 > - Removed assumptions on the acquiring MN-Id as part of Access > Authentication (Vidya). >=20 > - Acquiring the MN identifier and related considerations. Based on > the input from Jari. > =20 > - Added section on the Timestamp/seq number considerations (Issue 166) >=20 > - Changed the timestamp format. (Alex) >=20 > - Added lot more details on LMA processing of the PBU. >=20 > - Clearly seperated the message processing rules for initial PBU's, > Reregistrations and Deregistrations (Jonne) >=20 > - Added lot more details on MAG sending the PBU and processing the PBA >=20 > - Added message formats for the tunneled packets. >=20 > - Removed duplicate text in the MN section and in other places. Fixed > the editorial issues (Issue 157) >=20 > - Defined the order for sending the RA's only after completing the > signaling (Issue 165 & Issue 155) >=20 > - Added the flow sequence in Section 3. But, will add some more text > in the next rev. But, this issue can be closed (Issue 152). >=20 > - Defined the link-local address option. For fixing the link-local > address collision issue (Julien). >=20 > Again, please review and comment on the draft. We want to go last > call in a week. We will update the draft in between. >=20 > Thanks > Sri >=20 >=20 > > -----Original Message----- > > From: Christian Vogt [mailto:christian.vogt@nomadiclab.com]=20 > > Sent: Thursday, September 06, 2007 1:18 AM > > To: Sri Gundavelli > > Cc: NetLMM Mailing List > > Subject: Remaining Open Issues > >=20 > > Sri, > >=20 > > thanks for revising the P-MIPv6 specification. There are a=20 > > few open issues left > > in our tracker [1]. In order to help folks form an opinion=20 > > on whether those > > issues can be considered resolved now, may I ask you to send=20 > > a brief statement, > > per open issue, on how the issue got addressed by the revised=20 > > specification? > >=20 > > I believe this would be helpful for everyone. > >=20 > > Thank you, > > - Christian > >=20 > > [1] http://www3.tools.ietf.org/wg/netlmm/trac/report/1/ > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 11:00:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkkv-0003QU-57; Mon, 10 Sep 2007 11:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkkt-0003O1-Nl for netlmm@ietf.org; Mon, 10 Sep 2007 11:00:51 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUkks-0008IU-AQ for netlmm@ietf.org; Mon, 10 Sep 2007 11:00:51 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 08:00:49 -0700 Message-ID: <46E55C1A.7060900@azairenet.com> Date: Mon, 10 Sep 2007 08:00:42 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Issue: Auth Option support References: <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> <46E4B02C.5010101@azairenet.com> <200709101128.08546.julien.IETF@laposte.net> In-Reply-To: <200709101128.08546.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2007 15:00:49.0243 (UTC) FILETIME=[5FA4FAB0:01C7F3BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > Hi Vijay, > > One comment below, > > On Monday 10 September 2007, Vijay Devarapalli wrote: >> Sri, >> >> I agree with "SHOULD" for using IPsec and "MUST" for supporting IPsec >> on the MAG and the LMA. >> >> If thats the consensus, we need to modify a few sentences in the >> draft. >> >> In section 4, replace >> >>> The signaling messages, Proxy Binding Update and Proxy Binding >>> Acknowledgement, exchanged between the mobile access gateway and >>> the local mobility anchor MUST be protected using IPsec [RFC-4301] >>> and using the established security association between them. The >>> security association of the specific mobile node for which the >>> signaling message is initiated is not required for protecting these >>> messages. >> with >> >> The signaling messages, Proxy Binding Update and Proxy Binding >> Acknowledgement, exchanged between the mobile access gateway and >> the local mobility anchor MUST be protected using security >> associations established between them. The security association of >> the specific mobile node for which the signaling message is initiated >> is not required for protecting these messages. >> >> We need the MUST above since we have to say that the proxy BU and >> proxy BAck must be protected, irrespective of whether IPsec or some >> other mechanism is used. > > I understand you want to say that integrity and data origin > authentication are MUST's. I'm thus suggesting a minor change to your > text above (rest is fine with me): > > The Proxy Binding Update and Proxy Binding Acknowledgement > signaling messages exchanged between the MAG and LMA MUST be > protected using end-to-end security association(s) offering > integrity and data origin authentication. A security association > with the mobile node for which the signaling message is issued is > not required for protection of these messages. Sounds good to me. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 11:03:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkn9-0006ie-5c; Mon, 10 Sep 2007 11:03:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkn7-0006hs-5m for netlmm@ietf.org; Mon, 10 Sep 2007 11:03:09 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUkn6-00014Z-8j for netlmm@ietf.org; Mon, 10 Sep 2007 11:03:09 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 08:03:06 -0700 Message-ID: <46E55CA3.6040103@azairenet.com> Date: Mon, 10 Sep 2007 08:02:59 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] Issue: Auth Option support References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net> <01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com> <46E4B02C.5010101@azairenet.com> <6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2007 15:03:06.0912 (UTC) FILETIME=[B1B39A00:01C7F3BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad, I don't believe the security model of using just one security association between the MAG and the LMA for protecting the proxy BU and Proxy BAck changes irrespective of whether IPsec or RFC 4285 is used. So I don't agree with the suggested change. Vijay Ahmad Muhanna wrote: > >> Subject: Re: [netlmm] Issue: Auth Option support >> >> Sri, >> >> I agree with "SHOULD" for using IPsec and "MUST" for >> supporting IPsec on the MAG and the LMA. >> >> If thats the consensus, we need to modify a few sentences in >> the draft. >> >> In section 4, replace >> >>> The signaling messages, Proxy Binding Update and Proxy Binding >>> Acknowledgement, exchanged between the mobile access >> gateway and the >>> local mobility anchor MUST be protected using IPsec >> [RFC-4301] and >>> using the established security association between them. The >>> security association of the specific mobile node for which the >>> signaling message is initiated is not required for >> protecting these >>> messages. >> with >> >> The signaling messages, Proxy Binding Update and Proxy Binding >> Acknowledgement, exchanged between the mobile access >> gateway and the >> local mobility anchor MUST be protected using security >> associations >> established between them. The security association of the specific >> mobile node for which the signaling message is initiated is not >> required for protecting these messages. >> >> We need the MUST above since we have to say that the proxy BU >> and proxy BAck must be protected, irrespective of whether >> IPsec or some other mechanism is used. > > [Ahmad] > Hi Vijay, > > As far as I remember, the whole security concept of using a per-Node SA > for PMIPv6 was based on the use of IPsec. Although, I see why you > proposed the text but I still see a problem here. For example, the above > text allows the use of an authentication option similar to FA-HA AE to > secure the P-BU/P-BA. > > Now, since allowing a per-Node SA to be used in PMIPv6 was based on the > use of IPsec, I believe we clearly need to keep that as part of the spec > text. > > What about the following slight modification to what you just proposed: > > The signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access gateway and the > local mobility anchor MUST be protected using a security association > established between them. If IPsec is used, the security association > > of the specific mobile node for which the signaling message is > initiated > is not required for protecting these messages. > > Thanks, > Ahmad > >> Add one sentence that says >> >> The mobile access gateway and the local mobility anchor MUST >> implement IPsec for protecting the Proxy Mobile IPv6 signaling >> messages [RFC-4301]. >> >> The paragraph that comes after already uses "SHOULD" for using ESP. >> >>> IPsec ESP [RFC-4303] in transport mode with mandatory integrity >>> protection SHOULD be used for protecting the signaling messages. >>> Confidentiality protection of these messages is not required. >> Hope that is sufficient. >> >> Vijay >> >> >> Sri Gundavelli wrote: >>> I want some comments on this issue raised by Alper. >>> >>> >>> Also, if I interpret Sec 5.1 [3775], the IPSec is being >> mandated, only >>> the use of IPsec ESP is optional. >>> >>> -------- >>> 5.1. Binding Updates to Home Agents >>> >>> The mobile node and the home agent MUST use an IPsec security >>> association to protect the integrity and authenticity of >> the Binding >>> Updates and Acknowledgements. Both the mobile nodes and the home >>> agents MUST support and SHOULD use the Encapsulating >> Security Payload >>> (ESP) [6] header in transport mode and MUST use a >> non-NULL payload >>> authentication algorithm to provide data origin authentication, >>> connectionless integrity and optional anti-replay >> protection. Note >>> that Authentication Header (AH) [5] is also possible but >> for brevity >>> not discussed in this specification. >>> ------- >>> >>> >>> I'm confused, should the draft say >>> >>> "Both LMA and MAG MUST implement IPsec" and "all the signaling >>> messages SHOULD be protected using IPSec". >>> >>> Will this ok, when reviewed by the security folks ? >>> >>> or mandate IPsec for this specification and let other draft >> relax this >>> in the presence of an alternative approach ? >>> >>> Please comment. >>> >>> >>> Sri >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>>> Sent: Tuesday, August 07, 2007 1:41 AM >>>> To: 'Sri Gundavelli'; netlmm@ietf.org >>>> Subject: RE: [netlmm] Issue: Auth Option support >>>> >>>>> The issue was related to the use of MUST clause in specifying the >>>>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was >>>>> suggesting that we relax that requirement and potentially leave a >>>>> room for Auth Option support in future. >>>> Actually, I didn't mean it specifically for Auth Option. It can be >>>> anything. >>>> Given that the security is handled by a separate protocol, >> why lock >>>> it down to "IPsec", when some other protocol (Auth Option being one >>>> example) cannot >>>> be used. >>>> >>>>> But, as most people agreed and as supported by Jari, this can >>>> My understanding was the opposite, especially about Jari's >> statement. >>>>> always be changed in future when the support for new security >>>>> mechanisms such as Auth Option are defined for Proxy >> Mobile IPv6 and >>>>> that specific document can always modify this requirement. >>>>> So, no changes will be made to the document on this issue. >>>> What if Auth Option is good enough as written? >>>> What if a document in another SDO defines the alternative security >>>> mechanism? >>>> >>>> For the type of interop we are seeking in IETF, "MUST >> implement" is >>>> good enough. "MUST use" is not necessary. >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> >>>>> Regards >>>>> Sri >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 11:17:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUl0r-0004se-2d; Mon, 10 Sep 2007 11:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUl0q-0004sZ-6h for netlmm@ietf.org; Mon, 10 Sep 2007 11:17:20 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUl0o-0000IY-Ub for netlmm@ietf.org; Mon, 10 Sep 2007 11:17:20 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 08:17:17 -0700 Message-ID: <46E55FF6.7090008@azairenet.com> Date: Mon, 10 Sep 2007 08:17:10 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] Issue: Auth Option support References: <0MKp8S-1IUeUz2OGw-0008RA@mrelay.perfora.net> In-Reply-To: <0MKp8S-1IUeUz2OGw-0008RA@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2007 15:17:18.0005 (UTC) FILETIME=[ACFE1650:01C7F3BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, When we need to ensure interoperability, we use "MUST" and not "SHOULD". Vijay Alper Yegin wrote: > For interop "SHOULD implement and use", or even "SHOULD use" (like Julien > explained) is fine. "SHOULD" means "you better know what you are doing if > you don't follow", and that's exactly the case. > > If both ends are using some other mechanism and they know what each other > supports, they should not have to worry about (and implement) the mechanism > in the base spec. This is what SHOULD is for. > > Alper > > >> -----Original Message----- >> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >> Sent: Friday, September 07, 2007 10:27 PM >> To: Sri Gundavelli; Julien Laganier; netlmm@ietf.org >> Subject: RE: [netlmm] Issue: Auth Option support >> >> All, >> On this topic, I believe we must have a mandatory to implement mechanism >> specified for standards track publication. We can leave the use at >> "RECOMMENDED" or "SHOULD", but, we need a "MUST" on what the LMA and MAG >> need to implement. >> >> I had run this by the security directorate at the Chicago meeting and my >> understanding is that as long as we have "MUST implement IPsec" and >> "SHOULD use IPsec", it would be fine. >> >> In other words, the SHOULD vs. MUST that we want to place on using IPsec >> can be discussed, but, the "MUST" on implementation is non-negotiable. >> >> This is inline with my understanding on what we need to state for a >> complete specification. Given that channel security of signaling >> messages is mandatory, unless we have at least one common denominator >> that the MAG and LMA implementors will implement, we cannot ensure >> interoperability. If they support multiple common mechanisms and chose >> to use something other than IPsec, that's fine - hence, the "SHOULD" on >> usage. >> >> Hope that helps. >> >> Thanks, >> Vidya >> >>> -----Original Message----- >>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>> Sent: Friday, September 07, 2007 10:10 AM >>> To: 'Julien Laganier'; netlmm@ietf.org >>> Subject: RE: [netlmm] Issue: Auth Option support >>> >>> Hi Julien, >>> >>> >>> >>>> -----Original Message----- >>>> From: julien laganier [mailto:julien.laganier@gmail.com] On >>> Behalf Of >>>> Julien Laganier >>>> Sent: Friday, September 07, 2007 5:29 AM >>>> To: netlmm@ietf.org >>>> Cc: Sri Gundavelli; 'Alper Yegin' >>>> Subject: Re: [netlmm] Issue: Auth Option support >>>> >>>> Hi Sri, >>>> >>>> On Thursday 06 September 2007, Sri Gundavelli wrote: >>>>> I'm confused, should the draft say >>>>> >>>>> "Both LMA and MAG MUST implement IPsec" and "all the signaling >>>>> messages SHOULD be protected using IPSec". >>>>> >>>>> Will this ok, when reviewed by the security folks ? >>>>> >>>>> or mandate IPsec for this specification and let other draft relax >>>>> this in the presence of an alternative approach ? >>>>> >>>>> Please comment. >>>> Somehow, "MUST implement" and "SHOULD use" together seems a bit >>>> tautologic. >>>> >>>> To me "SHOULD use" is sufficient since it covers both of the two >>>> possibles cases: >>>> >>>> - deployment follows the SHOULD recommendation, it uses IPsec to >>>> protect PMIPv6, in which case it supports it, since it's >>> using it :), >>>> or >>>> >>>> - deployment ignores the SHOULD recommendation, does not >>> uses IPSec, >>>> in which case it is useless to implement it since it's not used... >>>> >>>> I'd prefer having "MUST protect integrity of signalling >>> messages, and >>>> SHOULD use IPsec ESP to protect integrity of those messages". >>>> We might >>>> also add "MAY use IPsec AH". >>>> >>> >>> I agree. I'm not against allowing other approaches. I'm only >>> concerned, if we can leave the draft saying, "MUST protect >>> integrity of signalling messages", with out specifying IPsec >>> or some other approach. If that will pass the security >>> review. We may have to state that IPsec MUST be used or some >>> other approach, say Auth-Option MUST be used. Not sure, if we >>> can leave this blank. >>> >>> Sri >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 11:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlL1-0008DZ-W6; Mon, 10 Sep 2007 11:38:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlL0-0008CC-Pp for netlmm@ietf.org; Mon, 10 Sep 2007 11:38:10 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUlKz-0002QN-OX for netlmm@ietf.org; Mon, 10 Sep 2007 11:38:10 -0400 X-IronPort-AV: E=Sophos;i="4.20,231,1186383600"; d="scan'208";a="397893319" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 10 Sep 2007 08:38:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8AFc9Xo005797; Mon, 10 Sep 2007 08:38:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8AFc8Ew003559; Mon, 10 Sep 2007 15:38:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 08:38:08 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 08:38:08 -0700 From: "Sri Gundavelli" To: "'Genadi Velev'" References: <46DFB7A4.9010209@nomadiclab.com> <006101c7f35e$61ef5a20$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A993@lan-ex-02.panasonic.de> Subject: RE: [netlmm] RE: Remaining Open Issues Date: Mon, 10 Sep 2007 08:38:07 -0700 Message-ID: <008f01c7f3c0$960663a0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfwXnExe6oZOl5aQOCii005cqOnggC/aV5AABPjXQAABPRFcA== In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48A993@lan-ex-02.panasonic.de> X-OriginalArrivalTime: 10 Sep 2007 15:38:08.0212 (UTC) FILETIME=[962C8940:01C7F3C0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6772; t=1189438689; x=1190302689; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20RE=3A=20Remaining=20Open=20Issues |Sender:=20; bh=LXfLWA2F93xYZuiEV3EO3SX0AkqQ21xkh5EGle+0e88=; b=02VuM0+/Wvuql27TlqGI+Uu6VLiIJIZO0zclC0JWGMpnAZvc44nw5zS2rKWNZIIo9EQMMCku GpSa6B5hMT6v9HJIUx2xxokW0P2i06NG0ttIwbmBorf50F6suWIXVopN; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: 'NetLMM Mailing List' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Genadi, Please see inline. > -----Original Message----- > From: Genadi Velev [mailto:Genadi.Velev@eu.panasonic.com] > Sent: Monday, September 10, 2007 6:54 AM > To: Sri Gundavelli > Cc: NetLMM Mailing List > Subject: RE: [netlmm] RE: Remaining Open Issues > > Hi Sri, > > going through the -03 version of the document I stumbled over some > editorial issues. > > 1) Page 29, 2nd paragraph says: > "One of the workarounds for this issue is to set the DNAv6 > configuration parameter, DNASameLinkDADFlag to TRUE and that will > force the mobile node to redo DAD operation every time the > interface > comes up, even when DNAv6 does detect a link change." > > The last part should be: "... to redo DAD operation every time the > interface identifies a handover, even when DNAv6 does not > detect a link > change." > Ok. We missed this. > 2) Several parts of the document specify that NAI option must be > included in the Proxy Binding Update and Proxy Binding Acknowledgement > messages. However, in section 8 "Message Formats" nothing is mentioned > about NAI option. Do you plan to include a descriptive text > in the next > document version? > Section 8.2 just identifies the PBU/PBA messages and the purpose. It does not talk about the options that go into it. There are IPv6 and IPv4 related options and all based on the signaling logic. The options that go into the message are identified in the signaling considerations. (Sections 5.3 and 6.9). It has the complete message formats. > 3) Sections 8.1 and 8.2 provide no description about the mobility > options in both Proxy Binding Update and Proxy Binding Acknowledgement > messages. I'd suggest to modify figures 11 and 12 and include some > descriptive text. > An example for figure 11 can be as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|L|K|M|R|P| Reserved | Lifetime > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > | > . Mobility options > . > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Additional text in section 8.1 is necessary to describe the meaning of > "Mobility Options". For example: > > "Variable-length field of such length that the complete Proxy Binding > Update message is an integer multiple of 8 octets long. This field > contains zero or more TLV-encoded mobility options. The Proxy Binding > Update message may include zero or more of the following options: This draft is leveraging the message/option formats from 3775. I'm not sure, if we should define any of that here. I can add an explicit statement, since, you had this doubt. > * NAI Option (???) > * Home Network Prefix Option > * Link-local Address Option > * Timestamp Option " > > A corresponding text shall be included also in section 8.2, where the > list with possible mobility option should be extended with > "Status Value > Option". > If you see 3775, the message and options are clearly mentioned seperately. In the message format sections, we are only defining the message and the option formats. In what combination they are used, that is based on the signaling logic. Thanks Sri > > regards, > Genadi > > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Monday, September 10, 2007 5:55 AM > > To: 'Christian Vogt' > > Cc: 'NetLMM Mailing List' > > Subject: [netlmm] RE: Remaining Open Issues > > > > > > Change log between the -01 and 03 version of the docs. > > > > > > Fixes the following issues: > > > > - Removed assumptions on the acquiring MN-Id as part of Access > > Authentication (Vidya). > > > > - Acquiring the MN identifier and related considerations. Based on > > the input from Jari. > > > > - Added section on the Timestamp/seq number considerations > (Issue 166) > > > > - Changed the timestamp format. (Alex) > > > > - Added lot more details on LMA processing of the PBU. > > > > - Clearly seperated the message processing rules for initial PBU's, > > Reregistrations and Deregistrations (Jonne) > > > > - Added lot more details on MAG sending the PBU and > processing the PBA > > > > - Added message formats for the tunneled packets. > > > > - Removed duplicate text in the MN section and in other > places. Fixed > > the editorial issues (Issue 157) > > > > - Defined the order for sending the RA's only after completing the > > signaling (Issue 165 & Issue 155) > > > > - Added the flow sequence in Section 3. But, will add some more text > > in the next rev. But, this issue can be closed (Issue 152). > > > > - Defined the link-local address option. For fixing the link-local > > address collision issue (Julien). > > > > Again, please review and comment on the draft. We want to go last > > call in a week. We will update the draft in between. > > > > Thanks > > Sri > > > > > > > -----Original Message----- > > > From: Christian Vogt [mailto:christian.vogt@nomadiclab.com] > > > Sent: Thursday, September 06, 2007 1:18 AM > > > To: Sri Gundavelli > > > Cc: NetLMM Mailing List > > > Subject: Remaining Open Issues > > > > > > Sri, > > > > > > thanks for revising the P-MIPv6 specification. There are a > > > few open issues left > > > in our tracker [1]. In order to help folks form an opinion > > > on whether those > > > issues can be considered resolved now, may I ask you to send > > > a brief statement, > > > per open issue, on how the issue got addressed by the revised > > > specification? > > > > > > I believe this would be helpful for everyone. > > > > > > Thank you, > > > - Christian > > > > > > [1] http://www3.tools.ietf.org/wg/netlmm/trac/report/1/ > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 13:44:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnJO-0002eS-3x; Mon, 10 Sep 2007 13:44:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnJL-0002dy-HY for netlmm@ietf.org; Mon, 10 Sep 2007 13:44:35 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUnJJ-00060S-K8 for netlmm@ietf.org; Mon, 10 Sep 2007 13:44:35 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8AHhuwV031261; Mon, 10 Sep 2007 19:43:58 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 10 Sep 2007 19:44:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] timestamp vs seqno redux Date: Mon, 10 Sep 2007 19:44:28 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A12@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <010701c7f170$c8863be0$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABfNwGAAE6an0ACRc75Q References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A5013999EA@FRVELSMBS12.ad2.ad.alcatel.com> <010701c7f170$c8863be0$d4f6200a@amer.cisco.com> From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" X-OriginalArrivalTime: 10 Sep 2007 17:44:29.0987 (UTC) FILETIME=[3D439730:01C7F3D2] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, thanks for your answer I've taken some time to process your answer and what is written in the = draft (v3) >From your email answer: Sri> ... Allowing LMA to return its own timestamp, essentially = establishes one node in that domain to dictate some order, in the = absence of NTP snchronization ... Sri> ... We either depend on NTP to synchronize all the clocks in the = node or let LMA always returns its timestamp, ... I understand now that there's a case that I had not taken into account: 1- The MAGs may be syncronized by context transfer =3D> SeqNum in BU 2- The MAGs may be synchronized by a common time reference =3D> = SeqNum (carrying a timestamp) in BU 3- The MAGs may be not-synchronized at all =3D> timestamp option Can you confirm that the timestamp option is only to cover case #3? By the way the draft is written (section 5.4), it's not clear to me if = you also expect the MAGs to use the timestamp option in case #2 = (connected to a common time reference). I think in case #2 the LMA = should not interfere with the explicit mechanism used to synchronize = clocks (e.g. NTP) In case #3, (MAGs not connected to a common time reference), I still = perceive that the draft expects the LMA to become a sort of Time = Reference Master In general, I can't see how the timestamp option can provide a = deterministic behavior and therefore I don't think that the draft should = RECOMMEND it, unless the following points are addressed: - for the timestamp option to work, the rate of BUs between a given = MAG and a given LMA should not allow for time deviations larger than the = threshold to declare a timestamp as invalid - A factor to take into account is RTDs (RoundTrip Delays) between = MAGs and LMA: if the pMAG-LMA RTD is larger than the nMAG-LMA RTD then = the pMAG "clock" will be delayed with respect to the one of the nMAG - Unclear what the effects of congestion will be: if the link between = the LMA and the pMAG is more congested than the link between the LMA and = the nMAG, the previous effect will be even worse - Something that needs to be considered in this discussion is = how/when resources will be released by the pMAG. If there's no = communication between pMAG and nMAG, there will need to be a timeout or = a revocation message from the LMA. In any case, there's a period of time = between the nMAG sending the BU and the pMAG releasing its own binding. = During this period of time the pMAG may send a BU, thereby creating a = race condition. In the extreme case, both the pMAG and the nMAG may send = the BU with the same time (virtually) - When connected to multiple LMAs (e.g. roaming), MAGs have to = maintain multiple timers (one per LMA). Doable but complex Can you please tell me if the following concerns have been raised before = and if yes how are they addressed? In my opinion, NETLMM should RECOMMEND the MAGs to be synchronized (case = #1 or case #2) and not the timestamp option (as in section 5.4) In these conditions, a non-synchronized MAG is an error case (thus = infrequent): #1) context transfer didn't take place or #2) lost = synchronization with the time reference. In order to address such error case it is enough to let the MAG indicate = it explicitly to the LMA, so that the LMA can (exceptionally) ignore the = sequencing. I don't see much added value in a solution like #3 (LMA as Time = Reference Master), but I'm not against describing it in the spec as long = as it is not REQUIRED or RECOMENDED A couple side reactions: Sri> But, the base draft has to be complete. We should allow deployments = to happen just based on this spec. If we dont support Timestamp and if = there is no CT, how will registrations happen ? The LMA will always = reject the first request for each MN.=20 MAGs need to be synchronized (CT or common time ref). The first BU of = all will need to carry a "Reset-Synch" flag Any MAG that is not synched (no CT or no connectivity to time ref) = SHOULD also assert the "Reset-Synch" flag Sri> ...replay protection has a relation to time window. Timestamp = provides the validity for the same message. Its the same thing here, = just that the window is small. We have very different opinions here, but as long as replay protection = is not an argument for the timestamp option, no need to discuss it Regards federico -----Message d'origine----- De : Sri Gundavelli [mailto:sgundave@cisco.com]=20 Envoy=E9 : vendredi 7 septembre 2007 19:02 =C0 : DE JUAN HUARTE FEDERICO Cc : 'netlmm' Objet : RE: [netlmm] timestamp vs seqno redux Hi Federico, =20 Please see inline .. > -----Original Message----- > From: DE JUAN HUARTE FEDERICO > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > Sent: Friday, September 07, 2007 2:04 AM > To: Sri Gundavelli > Cc: netlmm > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Sri, >=20 > I haven't had time to catch up yet with the new draft, so I apologize=20 > if any of my comments below has already been addresed >=20 > Sri> ... what are we mandating? The ability for the LMA to > generate a Timestamp and return the timestamp option ... > I'm trying to understand the motivation for this mandate >=20 > I understand the need in the LMA to identify the sequence of BUs in=20 > order to avoid race conditions when more than one MAG can send a BU=20 > for the same user The minimum requirement from LMA point of view is=20 > that the ID carried in the BU represents a free-running counter that=20 > increases monotonically It follows that the requirement for the MAGs=20 > is to synchronize the values used in the BU-ID Let me stress that=20 > these "minimum requirements" are only for synchronization between=20 > MAGs, i.e. not including LMA >=20 > Timestamps is a valid solution for filling in the ID when there's time = > synchronization (with sufficient accuracy) between MAGs Let me stress=20 > that the precondition for using timestamps should only be=20 > synchronization between MAGs, i.e. not including LMA By including LMA=20 > in the equation, it seems that we're trying to correct deviations in=20 > the time synchronization of MAGs via PMIP That is, the LMA becomes=20 > some kind of synch Master. Honestly, I don't think it is right to=20 > extend PMIP scope in such way >=20 No, that is not true. We are not trying to sync clocks using PMIP. = Allowing LMA to return its own timestamp, essentially establishes one = node in that domain to dictate some order, in the absence of NTP = snchronization. In a network with multiple nodes, we need a global scale = such as a timestamp. We either depend on NTP to synchronize all the = clocks in the node or let LMA always returns its timestamp, so as for = the MAG to use that timestamp (delta) in the subsequent requests. = Otherwise, every MAG in the network may be sending different timestamps = and the LMA would not know, which one to accept. > Let me cite your answers to Alper (from another email): > Sri> ... It is important to highlight the fact that we need > this entire synchronization logic to avoid one scenario, where the LMA = > ends up processing a PBU that was sent by pMAG and the LMA received=20 > that much later due to network out of order deliverly ... > [FDJ] This problem statement seems wrong. Unordered delivery because=20 > of nw congestion does not make any difference What matters is the=20 > relationship between the ID sent by the pMAG and the one sent by the=20 > nMAG The only requirement that we can make is that pMAG and nMAG must=20 > synchronize this ID There's no way the LMA can't tell in which order=20 > these 2 BUus were sent if the IDs are not-synchronized >=20 It does. The race condition would not be an issue, if LMA receives = packets in the order in which they were generated by different MAG's. = The LMA may potentially delete a valid current binding, because it = received a stale binding from the prev MAG.=20 If pMAG and nMAG can synchronize the id's, the whole issue is mute. That = is the alternative approach to timestamp based scheme that the draft = supports. MAG can certainly send the seq number of the MN that it = obtained as part of handoff using CT. No need for timestamps there. > Sri> ... If a deployment does not enable NTP kind of > protocols and if the LMA receives a packet with PBU from a MAG with a=20 > invalid timestamp, the LMA can return its own timestamp and the MAG=20 > can use the same in the requests to avoid this special race condition=20 > ... > [FDJ] If the deployment does not enable NTP, all PBUs will have a=20 > wrong ID. Or do you expect the MAG to synch to the same timebase as=20 > the LMA when the LMA returns the timestamp option? > Furthermore, I fail to understand the solution you propose:=20 > how can the LMA declare that the ID (timestamp) is invalid? > Use case: > - pMAG send BU at 10 AM > - nMAG sends BU at 11 AM > - LMA receives BU from nMAG at 11:15 AM. Will it return timestamp=20 > to nMAG, so that the BU can be resent? The LMA returns its timestamp if it detects that the clocks are out of = sync.=20 > - LMA receives BU from pMAG at 11:30 AM. Will it retun timestamp to = > pMAG, so that BU can be resent? Or maybe the proposal is that LMA will = > decide that pMAG BU was sent earlier than nMAG BU and therefore=20 > discard it. Yes. The LMA will discard it. You should read the Timestamp section. The latter=20 > makes sense but it means that the LMA has to assume that pMAG and nMAG = > are in synch. And then we're back to the minimum requirement >=20 > In summary, in my opinion: > 1- The LMA MAY be able to generate timestamps (but should not be=20 > required to) > 2- The LMA MAY know that the source used for the ID is a timestamp=20 > (but should not be required to) > 3- If the LMA is not timestamp aware, the MAG MAY use timestamps=20 > (but should not be required to) > 4- If the LMA is timestamp aware, the MAG MAY use timestamps (but=20 > should not be required to) If any of the 4 statements would reduce the = > usability of PMIP in any way, I would appreciate to have a more clear=20 > problem statement > Thus: Implementation MUST support Timestamp option: No Ok. > And I would even push it further: if the previous 4 statements can be=20 > agreed to, then the logical conclusion is that timestamps can be left=20 > out of the specification (at most an informative note would do) >=20 > A couple of collateral comments: > - I understand that CT (Context Transfer) is already acknowledged=20 > as a valid alternative solution > For some reason, CT is left out of scope. Fine for me, but I don't=20 > think it's a fair consequence to mandate timestamps > The fact that "context transfer is out of scope" doesn't equate to=20 > "there is no context transfer" But, the base draft has to be complete. We should allow deployments to = happen just based on this spec. If we dont support Timestamp and if = there is no CT, how will registrations happen ? The LMA will always = reject the first request for each MN.=20 > Is it the working assumption that a solution without CT is simpler=20 > than a solution with CT? This would be a wrong assumption > If we have to choose between specifying timestamps or specifying=20 > CT, then I prefer the latter. It's clear that it will require more=20 > work but it will be more useful >=20 > - If a nMAG sends a BU for a given user without synchronization=20 > with pMAG it may be useful to have the option to indicate it to the=20 > LMA > In other words, I propose a flag "OOS ID" (Out of Synch > ID) sent by the MAG, so that the LMA can reset the sequencing=20 > algorithm for a given MN >=20 > - I have read in other emails that timestamps are already a proven=20 > concept in MIP4 > I fail to understand how this argument makes a difference, since=20 > the original problem statement is that the MIP client (the one=20 > generating BUs) in case of PMIP (i.e. the MAG) may change during the=20 > lifetime of a MIP session. The problem addressed in MIP4 is a=20 > different one (replay protection). > It's off-topic, but I find this area of MIP4 overspecified when=20 > compared to approaches in other protocols (e.g. IEEE 802.16). A=20 > monotonically increasing counter is sufficient for replay protection >=20 Agree, the purpose is different. But, replay protection has a relation = to time window. Timestamp provides the validity for the same message. = Its the same thing here, just that the window is small. Sri > Regards >=20 > federico >=20 >=20 >=20 >=20 > -----Message d'origine----- > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 : jeudi 6=20 > septembre 2007 21:58 =C0 : 'Alexandru Petrescu'; 'netlmm' > Objet : RE: [netlmm] timestamp vs seqno redux >=20 >=20 > Please comment on this issue raised by Alex about mandating Timestamp=20 > option. Alex is right, when we discussed this issue, the conclusion=20 > was to use Timestamp based approach, but we did not discuss if that=20 > was supposed to be mandatory to implement. >=20 > Now, w.r.t the issue, what are we mandating ? >=20 > - The ability for the LMA to generate a Timestamp and return > the timestamp option. The timestamp in relation to a specific > reference point. IMO, this is one system call on most OS's and > a delta addition if the timestamp generated is elapsed time past > some other reference point. We are talking about 5 to 8 lines > of code. I will be happy to publish this code for all standard > OS's. >=20 > - We are NOT mandating the nodes in the domain to sync up to > a clock source.=20 >=20 >=20 > How does it impact, if some deployment wants to use Seq Number=20 > approach ? >=20 > - No impact. The option need to be supported. Implies those 10 > lines of extra code. >=20 >=20 > Why this should be mandatory ? >=20 > Base draft does not support Context Transfers. Given that the draft=20 > will be incomplete, if we dont mandate the support. By mandating the=20 > support, the LMA can always return its timestamp and the MAG can use=20 > that timestamp and register. > This need to be done just once whenever the LMA/MAG clocks are out of=20 > sync and just for one registration. One extra round trip for the 1st=20 > registration between LMA/MAG pair. >=20 > But, if the LMA falls back to the seq number based approach and if=20 > there are no context transfers, there is always an extra round trip=20 > for each MN registration (at handoff). >=20 > So, I prefer the mandatory approach, its more efficient. But, as I had = > it in the initial suggested text, I'm ok not mandating this and=20 > defining an error code "Timestamp option not supported". >=20 >=20 > Please comment. I want to close this issue.=20 >=20 >=20 > Implementation MUST support Timestamp option: [Yes/No] >=20 >=20 > Thanks > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Sent: Thursday, September 06, 2007 2:01 AM > > To: netlmm > > Subject: [netlmm] timestamp vs seqno redux > >=20 > > I've recently became aware that much nonsense discussion is > happening > > around the timestamp vs seqno. People keep saying that > seqno method > > is a possible alternative to timestamp but at the same time they=20 > > mandate in the document the timestamp method. This is complete=20 > > nonsense. > >=20 > > I don't want the timestamp method to be mandatory. > >=20 > > Anybody else wants the timestamp method to be a mandatory method? > >=20 > > Anybody else wants the timestamp method to be an alternative method? > >=20 > > Alex > > PS: mandatory excerpts: > > "This document _requires_ the use of Timestamp Option" > > "An implementation MUST support Timestamp option." > >=20 > >=20 > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email > Security System. > > For more information please visit http://www.messagelabs.com/email > >=20 > ______________________________________________________________________ > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 13:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnJP-0002fG-Br; Mon, 10 Sep 2007 13:44:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnJM-0002e9-CT for netlmm@ietf.org; Mon, 10 Sep 2007 13:44:37 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUnJL-00060V-35 for netlmm@ietf.org; Mon, 10 Sep 2007 13:44:36 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8AHhuwT031261; Mon, 10 Sep 2007 19:43:58 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 10 Sep 2007 19:44:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Issue: Auth Option support Date: Mon, 10 Sep 2007 19:44:28 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A13@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <46E55CA3.6040103@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Auth Option support Thread-Index: Acfzu9R6l4QFQXIEQAuS3CKNgDr0GgADN/XA References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net><01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com><46E4B02C.5010101@azairenet.com><6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com> <46E55CA3.6040103@azairenet.com> From: "DE JUAN HUARTE FEDERICO" To: "Vijay Devarapalli" , "Ahmad Muhanna" X-OriginalArrivalTime: 10 Sep 2007 17:44:29.0659 (UTC) FILETIME=[3D118AB0:01C7F3D2] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi, I am slowly catching up with NETLMM and I acknowledge that in some = aspects (e.g. security model) I'm definitely late I understand from this email that, in this group it has already been = decided to go for a per-node security model I followed the discussion about the security model in a PMIP solution in = a given forum (Wimax) some years ago, and then it was considered that a = per-node security model was was not sufficient The main argument I remember is the threat of the MAG being compromised = and indiscriminately allocating resources from the LMA This is especially worrisome when the the MAG and the LMA belong to 2 = different administrative domains Has this problem been addressed in this group? Thanks federico =20 -----Message d'origine----- De : Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 Envoy=E9 : lundi 10 septembre 2007 17:03 =C0 : Ahmad Muhanna Cc : netlmm@ietf.org Objet : Re: [netlmm] Issue: Auth Option support Ahmad, I don't believe the security model of using just one security = association between the MAG and the LMA for protecting the proxy BU and = Proxy BAck changes irrespective of whether IPsec or RFC 4285 is used. So I don't agree with the suggested change. Vijay Ahmad Muhanna wrote: > =20 >> Subject: Re: [netlmm] Issue: Auth Option support >> >> Sri, >> >> I agree with "SHOULD" for using IPsec and "MUST" for supporting IPsec = >> on the MAG and the LMA. >> >> If thats the consensus, we need to modify a few sentences in the=20 >> draft. >> >> In section 4, replace >> >>> The signaling messages, Proxy Binding Update and Proxy Binding >>> Acknowledgement, exchanged between the mobile access >> gateway and the >>> local mobility anchor MUST be protected using IPsec >> [RFC-4301] and >>> using the established security association between them. The >>> security association of the specific mobile node for which the >>> signaling message is initiated is not required for >> protecting these >>> messages. >> with >> >> The signaling messages, Proxy Binding Update and Proxy Binding >> Acknowledgement, exchanged between the mobile access gateway and=20 >> the >> local mobility anchor MUST be protected using security=20 >> associations >> established between them. The security association of the = specific >> mobile node for which the signaling message is initiated is not >> required for protecting these messages. >> >> We need the MUST above since we have to say that the proxy BU and=20 >> proxy BAck must be protected, irrespective of whether IPsec or some=20 >> other mechanism is used. >=20 > [Ahmad] > Hi Vijay, >=20 > As far as I remember, the whole security concept of using a per-Node=20 > SA for PMIPv6 was based on the use of IPsec. Although, I see why you=20 > proposed the text but I still see a problem here. For example, the=20 > above text allows the use of an authentication option similar to FA-HA = > AE to secure the P-BU/P-BA. >=20 > Now, since allowing a per-Node SA to be used in PMIPv6 was based on=20 > the use of IPsec, I believe we clearly need to keep that as part of=20 > the spec text. >=20 > What about the following slight modification to what you just = proposed: >=20 > The signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access gateway and = the > local mobility anchor MUST be protected using a security = association > established between them. If IPsec is used, the security=20 > association >=20 > of the specific mobile node for which the signaling message is=20 > initiated > is not required for protecting these messages. >=20 > Thanks, > Ahmad >=20 >> Add one sentence that says >> >> The mobile access gateway and the local mobility anchor MUST >> implement IPsec for protecting the Proxy Mobile IPv6 signaling >> messages [RFC-4301]. >> >> The paragraph that comes after already uses "SHOULD" for using ESP. >> >>> IPsec ESP [RFC-4303] in transport mode with mandatory integrity >>> protection SHOULD be used for protecting the signaling messages. >>> Confidentiality protection of these messages is not required. >> Hope that is sufficient. >> >> Vijay >> >> >> Sri Gundavelli wrote: >>> I want some comments on this issue raised by Alper. >>> >>> >>> Also, if I interpret Sec 5.1 [3775], the IPSec is being >> mandated, only >>> the use of IPsec ESP is optional. >>> >>> -------- >>> 5.1. Binding Updates to Home Agents >>> >>> The mobile node and the home agent MUST use an IPsec security >>> association to protect the integrity and authenticity of >> the Binding >>> Updates and Acknowledgements. Both the mobile nodes and the home >>> agents MUST support and SHOULD use the Encapsulating >> Security Payload >>> (ESP) [6] header in transport mode and MUST use a >> non-NULL payload >>> authentication algorithm to provide data origin authentication, >>> connectionless integrity and optional anti-replay >> protection. Note >>> that Authentication Header (AH) [5] is also possible but >> for brevity >>> not discussed in this specification. >>> ------- >>> >>> >>> I'm confused, should the draft say >>> >>> "Both LMA and MAG MUST implement IPsec" and "all the signaling=20 >>> messages SHOULD be protected using IPSec". >>> >>> Will this ok, when reviewed by the security folks ? >>> >>> or mandate IPsec for this specification and let other draft >> relax this >>> in the presence of an alternative approach ? >>> >>> Please comment. >>> >>> >>> Sri >>> >>> >>> >>> >>> =20 >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>>> Sent: Tuesday, August 07, 2007 1:41 AM >>>> To: 'Sri Gundavelli'; netlmm@ietf.org >>>> Subject: RE: [netlmm] Issue: Auth Option support >>>> >>>>> The issue was related to the use of MUST clause in specifying the=20 >>>>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was=20 >>>>> suggesting that we relax that requirement and potentially leave a=20 >>>>> room for Auth Option support in future. >>>> Actually, I didn't mean it specifically for Auth Option. It can be=20 >>>> anything. >>>> Given that the security is handled by a separate protocol, >> why lock >>>> it down to "IPsec", when some other protocol (Auth Option being one >>>> example) cannot >>>> be used. >>>> >>>>> But, as most people agreed and as supported by Jari, this can >>>> My understanding was the opposite, especially about Jari's >> statement. >>>>> always be changed in future when the support for new security=20 >>>>> mechanisms such as Auth Option are defined for Proxy >> Mobile IPv6 and >>>>> that specific document can always modify this requirement. >>>>> So, no changes will be made to the document on this issue. >>>> What if Auth Option is good enough as written? >>>> What if a document in another SDO defines the alternative security=20 >>>> mechanism? >>>> >>>> For the type of interop we are seeking in IETF, "MUST >> implement" is >>>> good enough. "MUST use" is not necessary. >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> >>>>> Regards >>>>> Sri >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 13:52:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnQn-0006WO-0O; Mon, 10 Sep 2007 13:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUnQl-0006Un-Jt for netlmm@ietf.org; Mon, 10 Sep 2007 13:52:15 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUnQj-0004nb-TJ for netlmm@ietf.org; Mon, 10 Sep 2007 13:52:15 -0400 X-IronPort-AV: E=Sophos;i="4.20,232,1186383600"; d="scan'208";a="522264318" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 Sep 2007 10:52:13 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8AHqCO5010591; Mon, 10 Sep 2007 10:52:12 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8AHq8F8006798; Mon, 10 Sep 2007 17:52:12 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 10:52:10 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 10:52:09 -0700 From: "Sri Gundavelli" To: "'DE JUAN HUARTE FEDERICO'" References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A5013999EA@FRVELSMBS12.ad2.ad.alcatel.com> <010701c7f170$c8863be0$d4f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A501399A12@FRVELSMBS12.ad2.ad.alcatel.com> Subject: RE: [netlmm] timestamp vs seqno redux Date: Mon, 10 Sep 2007 10:52:09 -0700 Message-ID: <00d701c7f3d3$4f385790$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABfNwGAAE6an0ACRc75QAAh9FoA= In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A12@FRVELSMBS12.ad2.ad.alcatel.com> X-OriginalArrivalTime: 10 Sep 2007 17:52:09.0643 (UTC) FILETIME=[4F3D87B0:01C7F3D3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18902; t=1189446732; x=1190310732; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20timestamp=20vs=20seqno=20redux |Sender:=20; bh=L5R6/f2bNyFAzAnse4D5IzEU09zjQCmttercQfT+gHg=; b=dn3hasWf3W/6W1ODV2+3ReoLwfNUbkEvRjqXCAL7yYc6tYJrcJ6Q3S2s4DwwOFX3vrmRZhg8 c4tMCMOtMwi8xWhAIqfPAXknKGErizYB0ZQg232VRxzhHyEb47KAdY1l; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2c6813ed945e40b4b5bea39da243c669 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, Two quick comments. I will respond to your other comments later. Sri > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Monday, September 10, 2007 10:44 AM > To: Sri Gundavelli > Cc: netlmm > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Sri, >=20 > thanks for your answer > I've taken some time to process your answer and what is=20 > written in the draft (v3) >=20 > From your email answer: > Sri> ... Allowing LMA to return its own timestamp,=20 > essentially establishes one node in that domain to dictate=20 > some order, in the absence of NTP snchronization ... > Sri> ... We either depend on NTP to synchronize all the=20 > clocks in the node or let LMA always returns its timestamp, ... >=20 > I understand now that there's a case that I had not taken=20 > into account: > 1- The MAGs may be syncronized by context transfer =3D> SeqNum in = BU > 2- The MAGs may be synchronized by a common time reference=20 > =3D> SeqNum (carrying a timestamp) in BU > 3- The MAGs may be not-synchronized at all =3D> timestamp option > Can you confirm that the timestamp option is only to cover case #3? > By the way the draft is written (section 5.4), it's not clear=20 > to me if you also expect the MAGs to use the timestamp option=20 > in case #2 (connected to a common time reference). I think in=20 > case #2 the LMA should not interfere with the explicit=20 > mechanism used to synchronize clocks (e.g. NTP) >=20 > In case #3, (MAGs not connected to a common time reference),=20 > I still perceive that the draft expects the LMA to become a=20 > sort of Time Reference Master > This is required. If we dont keep LMA timestamp in the loop, there will be one issue. If MN starts at MAG1 and for what ever reasons the timstamp of that MAG is bad (running 8 hours ahead) and if LMA accepts the BU without using its own time as a reference or for sanity check, any subsequent registrations from other MAG's for that MN will not go thru. As the time stamp will be older timestamp. Also, the timestamp text section was reviewed by the WG and there is consensus on this text. Unless, we failed to understand all the issues. Sri =20 > In general, I can't see how the timestamp option can provide=20 > a deterministic behavior and therefore I don't think that the=20 > draft should RECOMMEND it, unless the following points are addressed: > - for the timestamp option to work, the rate of BUs=20 > between a given MAG and a given LMA should not allow for time=20 > deviations larger than the threshold to declare a timestamp as invalid > - A factor to take into account is RTDs (RoundTrip Delays)=20 > between MAGs and LMA: if the pMAG-LMA RTD is larger than the=20 > nMAG-LMA RTD then the pMAG "clock" will be delayed with=20 > respect to the one of the nMAG > - Unclear what the effects of congestion will be: if the=20 > link between the LMA and the pMAG is more congested than the=20 > link between the LMA and the nMAG, the previous effect will=20 > be even worse > - Something that needs to be considered in this discussion=20 > is how/when resources will be released by the pMAG. If=20 > there's no communication between pMAG and nMAG, there will=20 > need to be a timeout or a revocation message from the LMA. In=20 > any case, there's a period of time between the nMAG sending=20 > the BU and the pMAG releasing its own binding. During this=20 > period of time the pMAG may send a BU, thereby creating a=20 > race condition. In the extreme case, both the pMAG and the=20 > nMAG may send the BU with the same time (virtually) > - When connected to multiple LMAs (e.g. roaming), MAGs=20 > have to maintain multiple timers (one per LMA). Doable but complex > Can you please tell me if the following concerns have been=20 > raised before and if yes how are they addressed? >=20 > In my opinion, NETLMM should RECOMMEND the MAGs to be=20 > synchronized (case #1 or case #2) and not the timestamp=20 > option (as in section 5.4) > In these conditions, a non-synchronized MAG is an error case=20 > (thus infrequent): #1) context transfer didn't take place or=20 > #2) lost synchronization with the time reference. > In order to address such error case it is enough to let the=20 > MAG indicate it explicitly to the LMA, so that the LMA can=20 > (exceptionally) ignore the sequencing. > I don't see much added value in a solution like #3 (LMA as=20 > Time Reference Master), but I'm not against describing it in=20 > the spec as long as it is not REQUIRED or RECOMENDED >=20 > A couple side reactions: > Sri> But, the base draft has to be complete. We should allow=20 > deployments to happen just based on this spec. If we dont=20 > support Timestamp and if there is no CT, how will=20 > registrations happen ? The LMA will always reject the first=20 > request for each MN.=20 > MAGs need to be synchronized (CT or common time ref). The=20 > first BU of all will need to carry a "Reset-Synch" flag > Any MAG that is not synched (no CT or no connectivity to time=20 > ref) SHOULD also assert the "Reset-Synch" flag >=20 > Sri> ...replay protection has a relation to time window.=20 > Timestamp provides the validity for the same message. Its the=20 > same thing here, just that the window is small. > We have very different opinions here, but as long as replay=20 > protection is not an argument for the timestamp option, no=20 > need to discuss it >=20 > Regards >=20 > federico >=20 > -----Message d'origine----- > De : Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Envoy=E9 : vendredi 7 septembre 2007 19:02 > =C0 : DE JUAN HUARTE FEDERICO > Cc : 'netlmm' > Objet : RE: [netlmm] timestamp vs seqno redux >=20 > Hi Federico, > =20 > Please see inline .. >=20 >=20 > > -----Original Message----- > > From: DE JUAN HUARTE FEDERICO > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > Sent: Friday, September 07, 2007 2:04 AM > > To: Sri Gundavelli > > Cc: netlmm > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > I haven't had time to catch up yet with the new draft, so I=20 > apologize=20 > > if any of my comments below has already been addresed > >=20 > > Sri> ... what are we mandating? The ability for the LMA to > > generate a Timestamp and return the timestamp option ... > > I'm trying to understand the motivation for this mandate > >=20 > > I understand the need in the LMA to identify the sequence of BUs in=20 > > order to avoid race conditions when more than one MAG can send a BU=20 > > for the same user The minimum requirement from LMA point of view is=20 > > that the ID carried in the BU represents a free-running=20 > counter that=20 > > increases monotonically It follows that the requirement for=20 > the MAGs=20 > > is to synchronize the values used in the BU-ID Let me stress that=20 > > these "minimum requirements" are only for synchronization between=20 > > MAGs, i.e. not including LMA > >=20 > > Timestamps is a valid solution for filling in the ID when=20 > there's time=20 > > synchronization (with sufficient accuracy) between MAGs Let=20 > me stress=20 > > that the precondition for using timestamps should only be=20 > > synchronization between MAGs, i.e. not including LMA By=20 > including LMA=20 > > in the equation, it seems that we're trying to correct=20 > deviations in=20 > > the time synchronization of MAGs via PMIP That is, the LMA becomes=20 > > some kind of synch Master. Honestly, I don't think it is right to=20 > > extend PMIP scope in such way > >=20 >=20 > No, that is not true. We are not trying to sync clocks using=20 > PMIP. Allowing LMA to return its own timestamp, essentially=20 > establishes one node in that domain to dictate some order, in=20 > the absence of NTP snchronization. In a network with multiple=20 > nodes, we need a global scale such as a timestamp. We either=20 > depend on NTP to synchronize all the clocks in the node or=20 > let LMA always returns its timestamp, so as for the MAG to=20 > use that timestamp (delta) in the subsequent requests.=20 > Otherwise, every MAG in the network may be sending different=20 > timestamps and the LMA would not know, which one to accept. >=20 >=20 > > Let me cite your answers to Alper (from another email): > > Sri> ... It is important to highlight the fact that we need > > this entire synchronization logic to avoid one scenario,=20 > where the LMA=20 > > ends up processing a PBU that was sent by pMAG and the LMA received=20 > > that much later due to network out of order deliverly ... > > [FDJ] This problem statement seems wrong. Unordered=20 > delivery because=20 > > of nw congestion does not make any difference What matters is the=20 > > relationship between the ID sent by the pMAG and the one=20 > sent by the=20 > > nMAG The only requirement that we can make is that pMAG and=20 > nMAG must=20 > > synchronize this ID There's no way the LMA can't tell in=20 > which order=20 > > these 2 BUus were sent if the IDs are not-synchronized > >=20 >=20 > It does. The race condition would not be an issue, if LMA=20 > receives packets in the order in which they were generated by=20 > different MAG's. The LMA may potentially delete a valid=20 > current binding, because it received a stale binding from the=20 > prev MAG.=20 >=20 > If pMAG and nMAG can synchronize the id's, the whole issue is=20 > mute. That is the alternative approach to timestamp based=20 > scheme that the draft supports. MAG can certainly send the=20 > seq number of the MN that it obtained as part of handoff=20 > using CT. No need for timestamps there. >=20 >=20 > > Sri> ... If a deployment does not enable NTP kind of > > protocols and if the LMA receives a packet with PBU from a=20 > MAG with a=20 > > invalid timestamp, the LMA can return its own timestamp and the MAG=20 > > can use the same in the requests to avoid this special race=20 > condition=20 > > ... > > [FDJ] If the deployment does not enable NTP, all PBUs will have a=20 > > wrong ID. Or do you expect the MAG to synch to the same timebase as=20 > > the LMA when the LMA returns the timestamp option? > > Furthermore, I fail to understand the solution you propose:=20 > > how can the LMA declare that the ID (timestamp) is invalid? > > Use case: > > - pMAG send BU at 10 AM > > - nMAG sends BU at 11 AM > > - LMA receives BU from nMAG at 11:15 AM. Will it return=20 > timestamp=20 > > to nMAG, so that the BU can be resent? >=20 > The LMA returns its timestamp if it detects that the clocks=20 > are out of sync.=20 >=20 >=20 > > - LMA receives BU from pMAG at 11:30 AM. Will it retun=20 > timestamp to=20 > > pMAG, so that BU can be resent? Or maybe the proposal is=20 > that LMA will=20 > > decide that pMAG BU was sent earlier than nMAG BU and therefore=20 > > discard it. >=20 >=20 > Yes. The LMA will discard it. You should read the Timestamp section. >=20 >=20 > The latter=20 > > makes sense but it means that the LMA has to assume that=20 > pMAG and nMAG=20 > > are in synch. And then we're back to the minimum requirement > >=20 > > In summary, in my opinion: > > 1- The LMA MAY be able to generate timestamps (but should not be=20 > > required to) > > 2- The LMA MAY know that the source used for the ID is a=20 > timestamp=20 > > (but should not be required to) > > 3- If the LMA is not timestamp aware, the MAG MAY use timestamps=20 > > (but should not be required to) > > 4- If the LMA is timestamp aware, the MAG MAY use=20 > timestamps (but=20 > > should not be required to) If any of the 4 statements would=20 > reduce the=20 > > usability of PMIP in any way, I would appreciate to have a=20 > more clear=20 > > problem statement >=20 > > Thus: Implementation MUST support Timestamp option: No >=20 > Ok. >=20 >=20 > > And I would even push it further: if the previous 4=20 > statements can be=20 > > agreed to, then the logical conclusion is that timestamps=20 > can be left=20 > > out of the specification (at most an informative note would do) > >=20 > > A couple of collateral comments: > > - I understand that CT (Context Transfer) is already=20 > acknowledged=20 > > as a valid alternative solution > > For some reason, CT is left out of scope. Fine for me,=20 > but I don't=20 > > think it's a fair consequence to mandate timestamps > > The fact that "context transfer is out of scope" doesn't=20 > equate to=20 > > "there is no context transfer" >=20 > But, the base draft has to be complete. We should allow=20 > deployments to happen just based on this spec. If we dont=20 > support Timestamp and if there is no CT, how will=20 > registrations happen ? The LMA will always reject the first=20 > request for each MN.=20 >=20 > > Is it the working assumption that a solution without CT=20 > is simpler=20 > > than a solution with CT? This would be a wrong assumption > > If we have to choose between specifying timestamps or specifying=20 > > CT, then I prefer the latter. It's clear that it will require more=20 > > work but it will be more useful > >=20 > > - If a nMAG sends a BU for a given user without synchronization=20 > > with pMAG it may be useful to have the option to indicate it to the=20 > > LMA > > In other words, I propose a flag "OOS ID" (Out of Synch > > ID) sent by the MAG, so that the LMA can reset the sequencing=20 > > algorithm for a given MN > >=20 > > - I have read in other emails that timestamps are=20 > already a proven=20 > > concept in MIP4 > > I fail to understand how this argument makes a difference, since=20 > > the original problem statement is that the MIP client (the one=20 > > generating BUs) in case of PMIP (i.e. the MAG) may change=20 > during the=20 > > lifetime of a MIP session. The problem addressed in MIP4 is a=20 > > different one (replay protection). > > It's off-topic, but I find this area of MIP4 overspecified when=20 > > compared to approaches in other protocols (e.g. IEEE 802.16). A=20 > > monotonically increasing counter is sufficient for replay protection > >=20 >=20 > Agree, the purpose is different. But, replay protection has a=20 > relation to time window. Timestamp provides the validity for=20 > the same message. Its the same thing here, just that the=20 > window is small. >=20 > Sri >=20 >=20 >=20 > > Regards > >=20 > > federico > >=20 > >=20 > >=20 > >=20 > > -----Message d'origine----- > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 : jeudi 6=20 > > septembre 2007 21:58 =C0 : 'Alexandru Petrescu'; 'netlmm' > > Objet : RE: [netlmm] timestamp vs seqno redux > >=20 > >=20 > > Please comment on this issue raised by Alex about mandating=20 > Timestamp=20 > > option. Alex is right, when we discussed this issue, the conclusion=20 > > was to use Timestamp based approach, but we did not discuss if that=20 > > was supposed to be mandatory to implement. > >=20 > > Now, w.r.t the issue, what are we mandating ? > >=20 > > - The ability for the LMA to generate a Timestamp and return > > the timestamp option. The timestamp in relation to a specific > > reference point. IMO, this is one system call on most OS's and > > a delta addition if the timestamp generated is elapsed time past > > some other reference point. We are talking about 5 to 8 lines > > of code. I will be happy to publish this code for all standard > > OS's. > >=20 > > - We are NOT mandating the nodes in the domain to sync up to > > a clock source.=20 > >=20 > >=20 > > How does it impact, if some deployment wants to use Seq Number=20 > > approach ? > >=20 > > - No impact. The option need to be supported. Implies those 10 > > lines of extra code. > >=20 > >=20 > > Why this should be mandatory ? > >=20 > > Base draft does not support Context Transfers. Given that the draft=20 > > will be incomplete, if we dont mandate the support. By=20 > mandating the=20 > > support, the LMA can always return its timestamp and the=20 > MAG can use=20 > > that timestamp and register. > > This need to be done just once whenever the LMA/MAG clocks=20 > are out of=20 > > sync and just for one registration. One extra round trip=20 > for the 1st=20 > > registration between LMA/MAG pair. > >=20 > > But, if the LMA falls back to the seq number based approach and if=20 > > there are no context transfers, there is always an extra round trip=20 > > for each MN registration (at handoff). > >=20 > > So, I prefer the mandatory approach, its more efficient.=20 > But, as I had=20 > > it in the initial suggested text, I'm ok not mandating this and=20 > > defining an error code "Timestamp option not supported". > >=20 > >=20 > > Please comment. I want to close this issue.=20 > >=20 > >=20 > > Implementation MUST support Timestamp option: [Yes/No] > >=20 > >=20 > > Thanks > > Sri > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > Sent: Thursday, September 06, 2007 2:01 AM > > > To: netlmm > > > Subject: [netlmm] timestamp vs seqno redux > > >=20 > > > I've recently became aware that much nonsense discussion is > > happening > > > around the timestamp vs seqno. People keep saying that > > seqno method > > > is a possible alternative to timestamp but at the same time they=20 > > > mandate in the document the timestamp method. This is complete=20 > > > nonsense. > > >=20 > > > I don't want the timestamp method to be mandatory. > > >=20 > > > Anybody else wants the timestamp method to be a mandatory method? > > >=20 > > > Anybody else wants the timestamp method to be an=20 > alternative method? > > >=20 > > > Alex > > > PS: mandatory excerpts: > > > "This document _requires_ the use of Timestamp Option" > > > "An implementation MUST support Timestamp option." > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email > > Security System. > > > For more information please visit http://www.messagelabs.com/email > > >=20 > >=20 > ______________________________________________________________________ > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 14:08:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUngP-0001Q3-GN; Mon, 10 Sep 2007 14:08:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUngN-0001Px-Kn for netlmm@ietf.org; Mon, 10 Sep 2007 14:08:23 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUngM-0006pj-NT for netlmm@ietf.org; Mon, 10 Sep 2007 14:08:23 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8AI5uA02224; Mon, 10 Sep 2007 18:05:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Issue: Auth Option support Date: Mon, 10 Sep 2007 13:08:12 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116A57C2B@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A13@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Auth Option support Thread-Index: Acfzu9R6l4QFQXIEQAuS3CKNgDr0GgADN/XAAAMPMJA= References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net><01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com><46E4B02C.5010101@azairenet.com><6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com> <46E55CA3.6040103@azairenet.com> <319D54578EAC3147BA8CC78DAB5467A501399A13@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" , "Vijay Devarapalli" X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, The issue of using a per-Node SA has been discussed long time ago and = reached consensus. This thread is not about the use of Per-Node vs. = Per-MN SA. It is about relaxing the mandate of the use IPsec to "MUST = implement" and SHOULD use" That is it. I Hope this address your concern. Regards, Ahmad =20 > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Monday, September 10, 2007 12:44 PM > To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10) > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Issue: Auth Option support >=20 > Hi, >=20 > I am slowly catching up with NETLMM and I acknowledge that in=20 > some aspects (e.g. security model) I'm definitely late >=20 > I understand from this email that, in this group it has=20 > already been decided to go for a per-node security model I=20 > followed the discussion about the security model in a PMIP=20 > solution in a given forum (Wimax) some years ago, and then it=20 > was considered that a per-node security model was was not=20 > sufficient The main argument I remember is the threat of the=20 > MAG being compromised and indiscriminately allocating=20 > resources from the LMA This is especially worrisome when the=20 > the MAG and the LMA belong to 2 different administrative=20 > domains Has this problem been addressed in this group? >=20 > Thanks >=20 > federico >=20 >=20 > =20 >=20 > -----Message d'origine----- > De : Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Envoy=E9 : lundi 10 septembre 2007 17:03 > =C0 : Ahmad Muhanna > Cc : netlmm@ietf.org > Objet : Re: [netlmm] Issue: Auth Option support >=20 > Ahmad, >=20 > I don't believe the security model of using just one security=20 > association between the MAG and the LMA for protecting the=20 > proxy BU and Proxy BAck changes irrespective of whether IPsec=20 > or RFC 4285 is used. So > I don't agree with the suggested change. >=20 > Vijay >=20 > Ahmad Muhanna wrote: > > =20 > >> Subject: Re: [netlmm] Issue: Auth Option support > >> > >> Sri, > >> > >> I agree with "SHOULD" for using IPsec and "MUST" for=20 > supporting IPsec=20 > >> on the MAG and the LMA. > >> > >> If thats the consensus, we need to modify a few sentences in the=20 > >> draft. > >> > >> In section 4, replace > >> > >>> The signaling messages, Proxy Binding Update and Proxy Binding > >>> Acknowledgement, exchanged between the mobile access > >> gateway and the > >>> local mobility anchor MUST be protected using IPsec > >> [RFC-4301] and > >>> using the established security association between them. The > >>> security association of the specific mobile node for which the > >>> signaling message is initiated is not required for > >> protecting these > >>> messages. > >> with > >> > >> The signaling messages, Proxy Binding Update and Proxy Binding > >> Acknowledgement, exchanged between the mobile access=20 > gateway and=20 > >> the > >> local mobility anchor MUST be protected using security=20 > >> associations > >> established between them. The security association of=20 > the specific > >> mobile node for which the signaling message is initiated is not > >> required for protecting these messages. > >> > >> We need the MUST above since we have to say that the proxy BU and=20 > >> proxy BAck must be protected, irrespective of whether=20 > IPsec or some=20 > >> other mechanism is used. > >=20 > > [Ahmad] > > Hi Vijay, > >=20 > > As far as I remember, the whole security concept of using a=20 > per-Node=20 > > SA for PMIPv6 was based on the use of IPsec. Although, I=20 > see why you=20 > > proposed the text but I still see a problem here. For example, the=20 > > above text allows the use of an authentication option=20 > similar to FA-HA=20 > > AE to secure the P-BU/P-BA. > >=20 > > Now, since allowing a per-Node SA to be used in PMIPv6 was based on=20 > > the use of IPsec, I believe we clearly need to keep that as part of=20 > > the spec text. > >=20 > > What about the following slight modification to what you=20 > just proposed: > >=20 > > The signaling messages, Proxy Binding Update and Proxy Binding > > Acknowledgement, exchanged between the mobile access=20 > gateway and the > > local mobility anchor MUST be protected using a=20 > security association > > established between them. If IPsec is used, the security=20 > > association > >=20 > > of the specific mobile node for which the signaling message is=20 > > initiated > > is not required for protecting these messages. > >=20 > > Thanks, > > Ahmad > >=20 > >> Add one sentence that says > >> > >> The mobile access gateway and the local mobility anchor MUST > >> implement IPsec for protecting the Proxy Mobile IPv6 signaling > >> messages [RFC-4301]. > >> > >> The paragraph that comes after already uses "SHOULD" for using ESP. > >> > >>> IPsec ESP [RFC-4303] in transport mode with mandatory integrity > >>> protection SHOULD be used for protecting the signaling=20 > messages. > >>> Confidentiality protection of these messages is not required. > >> Hope that is sufficient. > >> > >> Vijay > >> > >> > >> Sri Gundavelli wrote: > >>> I want some comments on this issue raised by Alper. > >>> > >>> > >>> Also, if I interpret Sec 5.1 [3775], the IPSec is being > >> mandated, only > >>> the use of IPsec ESP is optional. > >>> > >>> -------- > >>> 5.1. Binding Updates to Home Agents > >>> > >>> The mobile node and the home agent MUST use an IPsec security > >>> association to protect the integrity and authenticity of > >> the Binding > >>> Updates and Acknowledgements. Both the mobile nodes=20 > and the home > >>> agents MUST support and SHOULD use the Encapsulating > >> Security Payload > >>> (ESP) [6] header in transport mode and MUST use a > >> non-NULL payload > >>> authentication algorithm to provide data origin authentication, > >>> connectionless integrity and optional anti-replay > >> protection. Note > >>> that Authentication Header (AH) [5] is also possible but > >> for brevity > >>> not discussed in this specification. > >>> ------- > >>> > >>> > >>> I'm confused, should the draft say > >>> > >>> "Both LMA and MAG MUST implement IPsec" and "all the signaling=20 > >>> messages SHOULD be protected using IPSec". > >>> > >>> Will this ok, when reviewed by the security folks ? > >>> > >>> or mandate IPsec for this specification and let other draft > >> relax this > >>> in the presence of an alternative approach ? > >>> > >>> Please comment. > >>> > >>> > >>> Sri > >>> > >>> > >>> > >>> > >>> =20 > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>>> Sent: Tuesday, August 07, 2007 1:41 AM > >>>> To: 'Sri Gundavelli'; netlmm@ietf.org > >>>> Subject: RE: [netlmm] Issue: Auth Option support > >>>> > >>>>> The issue was related to the use of MUST clause in=20 > specifying the=20 > >>>>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was=20 > >>>>> suggesting that we relax that requirement and=20 > potentially leave a=20 > >>>>> room for Auth Option support in future. > >>>> Actually, I didn't mean it specifically for Auth Option.=20 > It can be=20 > >>>> anything. > >>>> Given that the security is handled by a separate protocol, > >> why lock > >>>> it down to "IPsec", when some other protocol (Auth=20 > Option being one > >>>> example) cannot > >>>> be used. > >>>> > >>>>> But, as most people agreed and as supported by Jari, this can > >>>> My understanding was the opposite, especially about Jari's > >> statement. > >>>>> always be changed in future when the support for new security=20 > >>>>> mechanisms such as Auth Option are defined for Proxy > >> Mobile IPv6 and > >>>>> that specific document can always modify this requirement. > >>>>> So, no changes will be made to the document on this issue. > >>>> What if Auth Option is good enough as written? > >>>> What if a document in another SDO defines the=20 > alternative security=20 > >>>> mechanism? > >>>> > >>>> For the type of interop we are seeking in IETF, "MUST > >> implement" is > >>>> good enough. "MUST use" is not necessary. > >>>> > >>>> Alper > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Regards > >>>>> Sri > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 14:34:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUo5X-0000bW-Ol; Mon, 10 Sep 2007 14:34:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUo5W-0000bB-7Q for netlmm@ietf.org; Mon, 10 Sep 2007 14:34:22 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUo5U-00071S-Ve for netlmm@ietf.org; Mon, 10 Sep 2007 14:34:22 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8AIYAb25335; Mon, 10 Sep 2007 18:34:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] timestamp vs seqno redux Date: Mon, 10 Sep 2007 13:33:58 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116A57CF2@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A12@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABfNwGAAE6an0ACRc75QAAnxKmA= References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A5013999EA@FRVELSMBS12.ad2.ad.alcatel.com> <010701c7f170$c8863be0$d4f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A501399A12@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" , "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, I just would like to make one comment quickly here and we can go over = other issues later. Timestamp option still needs to be used in Case No. 2 as you specified = below. Otherwise, how the whole sequencing would work? Right? Regards, Ahmad =20 > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Monday, September 10, 2007 12:44 PM > To: Sri Gundavelli > Cc: netlmm > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Sri, >=20 > thanks for your answer > I've taken some time to process your answer and what is=20 > written in the draft (v3) >=20 > >From your email answer: > Sri> ... Allowing LMA to return its own timestamp,=20 > essentially establishes one node in that domain to dictate=20 > some order, in the absence of NTP snchronization ... > Sri> ... We either depend on NTP to synchronize all the=20 > clocks in the node or let LMA always returns its timestamp, ... >=20 > I understand now that there's a case that I had not taken=20 > into account: > 1- The MAGs may be syncronized by context transfer =3D> SeqNum in = BU > 2- The MAGs may be synchronized by a common time reference=20 > =3D> SeqNum (carrying a timestamp) in BU > 3- The MAGs may be not-synchronized at all =3D> timestamp=20 > option Can you confirm that the timestamp option is only to=20 > cover case #3? [Ahmad] Timestamp option is used in case 2 and case 3. > By the way the draft is written (section 5.4), it's not clear=20 > to me if you also expect the MAGs to use the timestamp option=20 > in case #2 (connected to a common time reference). I think in=20 > case #2 the LMA should not interfere with the explicit=20 > mechanism used to synchronize clocks (e.g. NTP) >=20 > In case #3, (MAGs not connected to a common time reference),=20 > I still perceive that the draft expects the LMA to become a=20 > sort of Time Reference Master >=20 > In general, I can't see how the timestamp option can provide=20 > a deterministic behavior and therefore I don't think that the=20 > draft should RECOMMEND it, unless the following points are addressed: > - for the timestamp option to work, the rate of BUs=20 > between a given MAG and a given LMA should not allow for time=20 > deviations larger than the threshold to declare a timestamp as invalid > - A factor to take into account is RTDs (RoundTrip Delays)=20 > between MAGs and LMA: if the pMAG-LMA RTD is larger than the=20 > nMAG-LMA RTD then the pMAG "clock" will be delayed with=20 > respect to the one of the nMAG > - Unclear what the effects of congestion will be: if the=20 > link between the LMA and the pMAG is more congested than the=20 > link between the LMA and the nMAG, the previous effect will=20 > be even worse > - Something that needs to be considered in this discussion=20 > is how/when resources will be released by the pMAG. If=20 > there's no communication between pMAG and nMAG, there will=20 > need to be a timeout or a revocation message from the LMA. In=20 > any case, there's a period of time between the nMAG sending=20 > the BU and the pMAG releasing its own binding. During this=20 > period of time the pMAG may send a BU, thereby creating a=20 > race condition. In the extreme case, both the pMAG and the=20 > nMAG may send the BU with the same time (virtually) > - When connected to multiple LMAs (e.g. roaming), MAGs=20 > have to maintain multiple timers (one per LMA). Doable but=20 > complex Can you please tell me if the following concerns have=20 > been raised before and if yes how are they addressed? >=20 > In my opinion, NETLMM should RECOMMEND the MAGs to be=20 > synchronized (case #1 or case #2) and not the timestamp=20 > option (as in section 5.4) In these conditions, a=20 > non-synchronized MAG is an error case (thus infrequent): #1)=20 > context transfer didn't take place or #2) lost=20 > synchronization with the time reference. > In order to address such error case it is enough to let the=20 > MAG indicate it explicitly to the LMA, so that the LMA can=20 > (exceptionally) ignore the sequencing. > I don't see much added value in a solution like #3 (LMA as=20 > Time Reference Master), but I'm not against describing it in=20 > the spec as long as it is not REQUIRED or RECOMENDED >=20 > A couple side reactions: > Sri> But, the base draft has to be complete. We should allow=20 > deployments to happen just based on this spec. If we dont=20 > support Timestamp and if there is no CT, how will=20 > registrations happen ? The LMA will always reject the first=20 > request for each MN.=20 > MAGs need to be synchronized (CT or common time ref). The=20 > first BU of all will need to carry a "Reset-Synch" flag Any=20 > MAG that is not synched (no CT or no connectivity to time=20 > ref) SHOULD also assert the "Reset-Synch" flag >=20 > Sri> ...replay protection has a relation to time window.=20 > Timestamp provides the validity for the same message. Its the=20 > same thing here, just that the window is small. > We have very different opinions here, but as long as replay=20 > protection is not an argument for the timestamp option, no=20 > need to discuss it >=20 > Regards >=20 > federico >=20 > -----Message d'origine----- > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :=20 > vendredi 7 septembre 2007 19:02 =C0 : DE JUAN HUARTE FEDERICO=20 > Cc : 'netlmm' > Objet : RE: [netlmm] timestamp vs seqno redux >=20 > Hi Federico, > =20 > Please see inline .. >=20 >=20 > > -----Original Message----- > > From: DE JUAN HUARTE FEDERICO > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > Sent: Friday, September 07, 2007 2:04 AM > > To: Sri Gundavelli > > Cc: netlmm > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > I haven't had time to catch up yet with the new draft, so I=20 > apologize=20 > > if any of my comments below has already been addresed > >=20 > > Sri> ... what are we mandating? The ability for the LMA to > > generate a Timestamp and return the timestamp option ... > > I'm trying to understand the motivation for this mandate > >=20 > > I understand the need in the LMA to identify the sequence of BUs in=20 > > order to avoid race conditions when more than one MAG can send a BU=20 > > for the same user The minimum requirement from LMA point of view is=20 > > that the ID carried in the BU represents a free-running=20 > counter that=20 > > increases monotonically It follows that the requirement for=20 > the MAGs=20 > > is to synchronize the values used in the BU-ID Let me stress that=20 > > these "minimum requirements" are only for synchronization between=20 > > MAGs, i.e. not including LMA > >=20 > > Timestamps is a valid solution for filling in the ID when=20 > there's time=20 > > synchronization (with sufficient accuracy) between MAGs Let=20 > me stress=20 > > that the precondition for using timestamps should only be=20 > > synchronization between MAGs, i.e. not including LMA By=20 > including LMA=20 > > in the equation, it seems that we're trying to correct=20 > deviations in=20 > > the time synchronization of MAGs via PMIP That is, the LMA becomes=20 > > some kind of synch Master. Honestly, I don't think it is right to=20 > > extend PMIP scope in such way > >=20 >=20 > No, that is not true. We are not trying to sync clocks using=20 > PMIP. Allowing LMA to return its own timestamp, essentially=20 > establishes one node in that domain to dictate some order, in=20 > the absence of NTP snchronization. In a network with multiple=20 > nodes, we need a global scale such as a timestamp. We either=20 > depend on NTP to synchronize all the clocks in the node or=20 > let LMA always returns its timestamp, so as for the MAG to=20 > use that timestamp (delta) in the subsequent requests.=20 > Otherwise, every MAG in the network may be sending different=20 > timestamps and the LMA would not know, which one to accept. >=20 >=20 > > Let me cite your answers to Alper (from another email): > > Sri> ... It is important to highlight the fact that we need > > this entire synchronization logic to avoid one scenario,=20 > where the LMA=20 > > ends up processing a PBU that was sent by pMAG and the LMA received=20 > > that much later due to network out of order deliverly ... > > [FDJ] This problem statement seems wrong. Unordered=20 > delivery because=20 > > of nw congestion does not make any difference What matters is the=20 > > relationship between the ID sent by the pMAG and the one=20 > sent by the=20 > > nMAG The only requirement that we can make is that pMAG and=20 > nMAG must=20 > > synchronize this ID There's no way the LMA can't tell in=20 > which order=20 > > these 2 BUus were sent if the IDs are not-synchronized > >=20 >=20 > It does. The race condition would not be an issue, if LMA=20 > receives packets in the order in which they were generated by=20 > different MAG's. The LMA may potentially delete a valid=20 > current binding, because it received a stale binding from the=20 > prev MAG.=20 >=20 > If pMAG and nMAG can synchronize the id's, the whole issue is=20 > mute. That is the alternative approach to timestamp based=20 > scheme that the draft supports. MAG can certainly send the=20 > seq number of the MN that it obtained as part of handoff=20 > using CT. No need for timestamps there. >=20 >=20 > > Sri> ... If a deployment does not enable NTP kind of > > protocols and if the LMA receives a packet with PBU from a=20 > MAG with a=20 > > invalid timestamp, the LMA can return its own timestamp and the MAG=20 > > can use the same in the requests to avoid this special race=20 > condition=20 > > ... > > [FDJ] If the deployment does not enable NTP, all PBUs will have a=20 > > wrong ID. Or do you expect the MAG to synch to the same timebase as=20 > > the LMA when the LMA returns the timestamp option? > > Furthermore, I fail to understand the solution you propose:=20 > > how can the LMA declare that the ID (timestamp) is invalid? > > Use case: > > - pMAG send BU at 10 AM > > - nMAG sends BU at 11 AM > > - LMA receives BU from nMAG at 11:15 AM. Will it return=20 > timestamp=20 > > to nMAG, so that the BU can be resent? >=20 > The LMA returns its timestamp if it detects that the clocks=20 > are out of sync.=20 >=20 >=20 > > - LMA receives BU from pMAG at 11:30 AM. Will it retun=20 > timestamp to=20 > > pMAG, so that BU can be resent? Or maybe the proposal is=20 > that LMA will=20 > > decide that pMAG BU was sent earlier than nMAG BU and therefore=20 > > discard it. >=20 >=20 > Yes. The LMA will discard it. You should read the Timestamp section. >=20 >=20 > The latter=20 > > makes sense but it means that the LMA has to assume that=20 > pMAG and nMAG=20 > > are in synch. And then we're back to the minimum requirement > >=20 > > In summary, in my opinion: > > 1- The LMA MAY be able to generate timestamps (but should not be=20 > > required to) > > 2- The LMA MAY know that the source used for the ID is a=20 > timestamp=20 > > (but should not be required to) > > 3- If the LMA is not timestamp aware, the MAG MAY use timestamps=20 > > (but should not be required to) > > 4- If the LMA is timestamp aware, the MAG MAY use=20 > timestamps (but=20 > > should not be required to) If any of the 4 statements would=20 > reduce the=20 > > usability of PMIP in any way, I would appreciate to have a=20 > more clear=20 > > problem statement >=20 > > Thus: Implementation MUST support Timestamp option: No >=20 > Ok. >=20 >=20 > > And I would even push it further: if the previous 4=20 > statements can be=20 > > agreed to, then the logical conclusion is that timestamps=20 > can be left=20 > > out of the specification (at most an informative note would do) > >=20 > > A couple of collateral comments: > > - I understand that CT (Context Transfer) is already=20 > acknowledged=20 > > as a valid alternative solution > > For some reason, CT is left out of scope. Fine for me,=20 > but I don't=20 > > think it's a fair consequence to mandate timestamps > > The fact that "context transfer is out of scope" doesn't=20 > equate to=20 > > "there is no context transfer" >=20 > But, the base draft has to be complete. We should allow=20 > deployments to happen just based on this spec. If we dont=20 > support Timestamp and if there is no CT, how will=20 > registrations happen ? The LMA will always reject the first=20 > request for each MN.=20 >=20 > > Is it the working assumption that a solution without CT=20 > is simpler=20 > > than a solution with CT? This would be a wrong assumption > > If we have to choose between specifying timestamps or specifying=20 > > CT, then I prefer the latter. It's clear that it will require more=20 > > work but it will be more useful > >=20 > > - If a nMAG sends a BU for a given user without synchronization=20 > > with pMAG it may be useful to have the option to indicate it to the=20 > > LMA > > In other words, I propose a flag "OOS ID" (Out of Synch > > ID) sent by the MAG, so that the LMA can reset the sequencing=20 > > algorithm for a given MN > >=20 > > - I have read in other emails that timestamps are=20 > already a proven=20 > > concept in MIP4 > > I fail to understand how this argument makes a difference, since=20 > > the original problem statement is that the MIP client (the one=20 > > generating BUs) in case of PMIP (i.e. the MAG) may change=20 > during the=20 > > lifetime of a MIP session. The problem addressed in MIP4 is a=20 > > different one (replay protection). > > It's off-topic, but I find this area of MIP4 overspecified when=20 > > compared to approaches in other protocols (e.g. IEEE 802.16). A=20 > > monotonically increasing counter is sufficient for replay protection > >=20 >=20 > Agree, the purpose is different. But, replay protection has a=20 > relation to time window. Timestamp provides the validity for=20 > the same message. Its the same thing here, just that the=20 > window is small. >=20 > Sri >=20 >=20 >=20 > > Regards > >=20 > > federico > >=20 > >=20 > >=20 > >=20 > > -----Message d'origine----- > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 : jeudi 6=20 > > septembre 2007 21:58 =C0 : 'Alexandru Petrescu'; 'netlmm' > > Objet : RE: [netlmm] timestamp vs seqno redux > >=20 > >=20 > > Please comment on this issue raised by Alex about mandating=20 > Timestamp=20 > > option. Alex is right, when we discussed this issue, the conclusion=20 > > was to use Timestamp based approach, but we did not discuss if that=20 > > was supposed to be mandatory to implement. > >=20 > > Now, w.r.t the issue, what are we mandating ? > >=20 > > - The ability for the LMA to generate a Timestamp and return > > the timestamp option. The timestamp in relation to a specific > > reference point. IMO, this is one system call on most OS's and > > a delta addition if the timestamp generated is elapsed time past > > some other reference point. We are talking about 5 to 8 lines > > of code. I will be happy to publish this code for all standard > > OS's. > >=20 > > - We are NOT mandating the nodes in the domain to sync up to > > a clock source.=20 > >=20 > >=20 > > How does it impact, if some deployment wants to use Seq Number=20 > > approach ? > >=20 > > - No impact. The option need to be supported. Implies those 10 > > lines of extra code. > >=20 > >=20 > > Why this should be mandatory ? > >=20 > > Base draft does not support Context Transfers. Given that the draft=20 > > will be incomplete, if we dont mandate the support. By=20 > mandating the=20 > > support, the LMA can always return its timestamp and the=20 > MAG can use=20 > > that timestamp and register. > > This need to be done just once whenever the LMA/MAG clocks=20 > are out of=20 > > sync and just for one registration. One extra round trip=20 > for the 1st=20 > > registration between LMA/MAG pair. > >=20 > > But, if the LMA falls back to the seq number based approach and if=20 > > there are no context transfers, there is always an extra round trip=20 > > for each MN registration (at handoff). > >=20 > > So, I prefer the mandatory approach, its more efficient.=20 > But, as I had=20 > > it in the initial suggested text, I'm ok not mandating this and=20 > > defining an error code "Timestamp option not supported". > >=20 > >=20 > > Please comment. I want to close this issue.=20 > >=20 > >=20 > > Implementation MUST support Timestamp option: [Yes/No] > >=20 > >=20 > > Thanks > > Sri > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > Sent: Thursday, September 06, 2007 2:01 AM > > > To: netlmm > > > Subject: [netlmm] timestamp vs seqno redux > > >=20 > > > I've recently became aware that much nonsense discussion is > > happening > > > around the timestamp vs seqno. People keep saying that > > seqno method > > > is a possible alternative to timestamp but at the same time they=20 > > > mandate in the document the timestamp method. This is complete=20 > > > nonsense. > > >=20 > > > I don't want the timestamp method to be mandatory. > > >=20 > > > Anybody else wants the timestamp method to be a mandatory method? > > >=20 > > > Anybody else wants the timestamp method to be an=20 > alternative method? > > >=20 > > > Alex > > > PS: mandatory excerpts: > > > "This document _requires_ the use of Timestamp Option" > > > "An implementation MUST support Timestamp option." > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email > > Security System. > > > For more information please visit http://www.messagelabs.com/email > > >=20 > >=20 > ______________________________________________________________________ > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 14:40:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUoB1-0002vk-If; Mon, 10 Sep 2007 14:40:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUoB0-0002vH-Hy for netlmm@ietf.org; Mon, 10 Sep 2007 14:40:02 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUoAy-0000sp-Mb for netlmm@ietf.org; Mon, 10 Sep 2007 14:40:02 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8AIdhe26187; Mon, 10 Sep 2007 18:39:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] timestamp vs seqno redux Date: Mon, 10 Sep 2007 13:39:42 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D1B@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710F500AB8@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABfNwGAAE6an0ACRc75QAAnxKmAAAD5AsA== References: <319D54578EAC3147BA8CC78DAB5467A501399A12@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AB8@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "DE JUAN HUARTE FEDERICO" , "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b157e6e8a3799aef911c0bc37fc93a6 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, It seems that I did not read the whole case No. 2. You are proposing a new mechanism/field to use timestamp.=20 I agree with Sri, That has been discussed and agreed upon.=20 Regards, Ahmad =20 > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10)=20 > Sent: Monday, September 10, 2007 1:34 PM > To: 'DE JUAN HUARTE FEDERICO'; 'Sri Gundavelli' > Cc: 'netlmm' > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Federico, >=20 > I just would like to make one comment quickly here and we can=20 > go over other issues later. > Timestamp option still needs to be used in Case No. 2 as you=20 > specified below. Otherwise, how the whole sequencing would=20 > work? Right? >=20 >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: DE JUAN HUARTE FEDERICO > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > Sent: Monday, September 10, 2007 12:44 PM > > To: Sri Gundavelli > > Cc: netlmm > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > thanks for your answer > > I've taken some time to process your answer and what is=20 > written in the=20 > > draft (v3) > >=20 > > >From your email answer: > > Sri> ... Allowing LMA to return its own timestamp, > > essentially establishes one node in that domain to dictate=20 > some order,=20 > > in the absence of NTP snchronization ... > > Sri> ... We either depend on NTP to synchronize all the > > clocks in the node or let LMA always returns its timestamp, ... > >=20 > > I understand now that there's a case that I had not taken into=20 > > account: > > 1- The MAGs may be syncronized by context transfer =3D>=20 > SeqNum in BU > > 2- The MAGs may be synchronized by a common time reference =3D>=20 > > SeqNum (carrying a timestamp) in BU > > 3- The MAGs may be not-synchronized at all =3D> timestamp=20 > option Can=20 > > you confirm that the timestamp option is only to cover case #3? >=20 > [Ahmad] > Timestamp option is used in case 2 and case 3. >=20 > > By the way the draft is written (section 5.4), it's not=20 > clear to me if=20 > > you also expect the MAGs to use the timestamp option in case #2=20 > > (connected to a common time reference). I think in case #2 the LMA=20 > > should not interfere with the explicit mechanism used to=20 > synchronize=20 > > clocks (e.g. NTP) > >=20 > > In case #3, (MAGs not connected to a common time=20 > reference), I still=20 > > perceive that the draft expects the LMA to become a sort of Time=20 > > Reference Master > >=20 > > In general, I can't see how the timestamp option can provide a=20 > > deterministic behavior and therefore I don't think that the draft=20 > > should RECOMMEND it, unless the following points are addressed: > > - for the timestamp option to work, the rate of BUs=20 > between a given=20 > > MAG and a given LMA should not allow for time deviations=20 > larger than=20 > > the threshold to declare a timestamp as invalid > > - A factor to take into account is RTDs (RoundTrip=20 > Delays) between=20 > > MAGs and LMA: if the pMAG-LMA RTD is larger than the=20 > nMAG-LMA RTD then=20 > > the pMAG "clock" will be delayed with respect to the one of the nMAG > > - Unclear what the effects of congestion will be: if the link=20 > > between the LMA and the pMAG is more congested than the=20 > link between=20 > > the LMA and the nMAG, the previous effect will be even worse > > - Something that needs to be considered in this discussion is=20 > > how/when resources will be released by the pMAG. If there's no=20 > > communication between pMAG and nMAG, there will need to be=20 > a timeout=20 > > or a revocation message from the LMA. In any case, there's=20 > a period of=20 > > time between the nMAG sending the BU and the pMAG releasing its own=20 > > binding. During this period of time the pMAG may send a BU, thereby=20 > > creating a race condition. In the extreme case, both the=20 > pMAG and the=20 > > nMAG may send the BU with the same time (virtually) > > - When connected to multiple LMAs (e.g. roaming), MAGs have to=20 > > maintain multiple timers (one per LMA). Doable but complex Can you=20 > > please tell me if the following concerns have been raised=20 > before and=20 > > if yes how are they addressed? > >=20 > > In my opinion, NETLMM should RECOMMEND the MAGs to be synchronized=20 > > (case #1 or case #2) and not the timestamp option (as in=20 > section 5.4)=20 > > In these conditions, a non-synchronized MAG is an error case (thus=20 > > infrequent): #1) context transfer didn't take place or #2) lost=20 > > synchronization with the time reference. > > In order to address such error case it is enough to let the MAG=20 > > indicate it explicitly to the LMA, so that the LMA can > > (exceptionally) ignore the sequencing. > > I don't see much added value in a solution like #3 (LMA as Time=20 > > Reference Master), but I'm not against describing it in the spec as=20 > > long as it is not REQUIRED or RECOMENDED > >=20 > > A couple side reactions: > > Sri> But, the base draft has to be complete. We should allow > > deployments to happen just based on this spec. If we dont support=20 > > Timestamp and if there is no CT, how will registrations=20 > happen ? The=20 > > LMA will always reject the first request for each MN. > > MAGs need to be synchronized (CT or common time ref). The=20 > first BU of=20 > > all will need to carry a "Reset-Synch" flag Any MAG that is not=20 > > synched (no CT or no connectivity to time > > ref) SHOULD also assert the "Reset-Synch" flag > >=20 > > Sri> ...replay protection has a relation to time window.=20 > > Timestamp provides the validity for the same message. Its the same=20 > > thing here, just that the window is small. > > We have very different opinions here, but as long as replay=20 > protection=20 > > is not an argument for the timestamp option, no need to discuss it > >=20 > > Regards > >=20 > > federico > >=20 > > -----Message d'origine----- > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :=20 > > vendredi 7 septembre 2007 19:02 =C0 : DE JUAN HUARTE FEDERICO Cc :=20 > > 'netlmm' > > Objet : RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Federico, > > =20 > > Please see inline .. > >=20 > >=20 > > > -----Original Message----- > > > From: DE JUAN HUARTE FEDERICO > > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > > Sent: Friday, September 07, 2007 2:04 AM > > > To: Sri Gundavelli > > > Cc: netlmm > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Sri, > > >=20 > > > I haven't had time to catch up yet with the new draft, so I > > apologize > > > if any of my comments below has already been addresed > > >=20 > > > Sri> ... what are we mandating? The ability for the LMA to > > > generate a Timestamp and return the timestamp option ... > > > I'm trying to understand the motivation for this mandate > > >=20 > > > I understand the need in the LMA to identify the sequence=20 > of BUs in=20 > > > order to avoid race conditions when more than one MAG can=20 > send a BU=20 > > > for the same user The minimum requirement from LMA point=20 > of view is=20 > > > that the ID carried in the BU represents a free-running > > counter that > > > increases monotonically It follows that the requirement for > > the MAGs > > > is to synchronize the values used in the BU-ID Let me stress that=20 > > > these "minimum requirements" are only for synchronization between=20 > > > MAGs, i.e. not including LMA > > >=20 > > > Timestamps is a valid solution for filling in the ID when > > there's time > > > synchronization (with sufficient accuracy) between MAGs Let > > me stress > > > that the precondition for using timestamps should only be=20 > > > synchronization between MAGs, i.e. not including LMA By > > including LMA > > > in the equation, it seems that we're trying to correct > > deviations in > > > the time synchronization of MAGs via PMIP That is, the=20 > LMA becomes=20 > > > some kind of synch Master. Honestly, I don't think it is right to=20 > > > extend PMIP scope in such way > > >=20 > >=20 > > No, that is not true. We are not trying to sync clocks using PMIP.=20 > > Allowing LMA to return its own timestamp, essentially=20 > establishes one=20 > > node in that domain to dictate some order, in the absence of NTP=20 > > snchronization. In a network with multiple nodes, we need a global=20 > > scale such as a timestamp. We either depend on NTP to=20 > synchronize all=20 > > the clocks in the node or let LMA always returns its=20 > timestamp, so as=20 > > for the MAG to use that timestamp (delta) in the subsequent=20 > requests. > > Otherwise, every MAG in the network may be sending different=20 > > timestamps and the LMA would not know, which one to accept. > >=20 > >=20 > > > Let me cite your answers to Alper (from another email): > > > Sri> ... It is important to highlight the fact that we need > > > this entire synchronization logic to avoid one scenario, > > where the LMA > > > ends up processing a PBU that was sent by pMAG and the=20 > LMA received=20 > > > that much later due to network out of order deliverly ... > > > [FDJ] This problem statement seems wrong. Unordered > > delivery because > > > of nw congestion does not make any difference What matters is the=20 > > > relationship between the ID sent by the pMAG and the one > > sent by the > > > nMAG The only requirement that we can make is that pMAG and > > nMAG must > > > synchronize this ID There's no way the LMA can't tell in > > which order > > > these 2 BUus were sent if the IDs are not-synchronized > > >=20 > >=20 > > It does. The race condition would not be an issue, if LMA receives=20 > > packets in the order in which they were generated by=20 > different MAG's.=20 > > The LMA may potentially delete a valid current binding, because it=20 > > received a stale binding from the prev MAG. > >=20 > > If pMAG and nMAG can synchronize the id's, the whole issue is mute.=20 > > That is the alternative approach to timestamp based scheme that the=20 > > draft supports. MAG can certainly send the seq number of=20 > the MN that=20 > > it obtained as part of handoff using CT. No need for=20 > timestamps there. > >=20 > >=20 > > > Sri> ... If a deployment does not enable NTP kind of > > > protocols and if the LMA receives a packet with PBU from a=20 > > MAG with a=20 > > > invalid timestamp, the LMA can return its own timestamp=20 > and the MAG=20 > > > can use the same in the requests to avoid this special race=20 > > condition=20 > > > ... > > > [FDJ] If the deployment does not enable NTP, all PBUs will have a=20 > > > wrong ID. Or do you expect the MAG to synch to the same=20 > timebase as=20 > > > the LMA when the LMA returns the timestamp option? > > > Furthermore, I fail to understand the solution you propose:=20 > > > how can the LMA declare that the ID (timestamp) is invalid? > > > Use case: > > > - pMAG send BU at 10 AM > > > - nMAG sends BU at 11 AM > > > - LMA receives BU from nMAG at 11:15 AM. Will it return=20 > > timestamp=20 > > > to nMAG, so that the BU can be resent? > >=20 > > The LMA returns its timestamp if it detects that the clocks=20 > > are out of sync.=20 > >=20 > >=20 > > > - LMA receives BU from pMAG at 11:30 AM. Will it retun=20 > > timestamp to=20 > > > pMAG, so that BU can be resent? Or maybe the proposal is=20 > > that LMA will=20 > > > decide that pMAG BU was sent earlier than nMAG BU and therefore=20 > > > discard it. > >=20 > >=20 > > Yes. The LMA will discard it. You should read the Timestamp section. > >=20 > >=20 > > The latter=20 > > > makes sense but it means that the LMA has to assume that=20 > > pMAG and nMAG=20 > > > are in synch. And then we're back to the minimum requirement > > >=20 > > > In summary, in my opinion: > > > 1- The LMA MAY be able to generate timestamps (but=20 > should not be=20 > > > required to) > > > 2- The LMA MAY know that the source used for the ID is a=20 > > timestamp=20 > > > (but should not be required to) > > > 3- If the LMA is not timestamp aware, the MAG MAY use=20 > timestamps=20 > > > (but should not be required to) > > > 4- If the LMA is timestamp aware, the MAG MAY use=20 > > timestamps (but=20 > > > should not be required to) If any of the 4 statements would=20 > > reduce the=20 > > > usability of PMIP in any way, I would appreciate to have a=20 > > more clear=20 > > > problem statement > >=20 > > > Thus: Implementation MUST support Timestamp option: No > >=20 > > Ok. > >=20 > >=20 > > > And I would even push it further: if the previous 4=20 > > statements can be=20 > > > agreed to, then the logical conclusion is that timestamps=20 > > can be left=20 > > > out of the specification (at most an informative note would do) > > >=20 > > > A couple of collateral comments: > > > - I understand that CT (Context Transfer) is already=20 > > acknowledged=20 > > > as a valid alternative solution > > > For some reason, CT is left out of scope. Fine for me,=20 > > but I don't=20 > > > think it's a fair consequence to mandate timestamps > > > The fact that "context transfer is out of scope" doesn't=20 > > equate to=20 > > > "there is no context transfer" > >=20 > > But, the base draft has to be complete. We should allow=20 > > deployments to happen just based on this spec. If we dont=20 > > support Timestamp and if there is no CT, how will=20 > > registrations happen ? The LMA will always reject the first=20 > > request for each MN.=20 > >=20 > > > Is it the working assumption that a solution without CT=20 > > is simpler=20 > > > than a solution with CT? This would be a wrong assumption > > > If we have to choose between specifying timestamps or=20 > specifying=20 > > > CT, then I prefer the latter. It's clear that it will=20 > require more=20 > > > work but it will be more useful > > >=20 > > > - If a nMAG sends a BU for a given user without=20 > synchronization=20 > > > with pMAG it may be useful to have the option to indicate=20 > it to the=20 > > > LMA > > > In other words, I propose a flag "OOS ID" (Out of Synch > > > ID) sent by the MAG, so that the LMA can reset the sequencing=20 > > > algorithm for a given MN > > >=20 > > > - I have read in other emails that timestamps are=20 > > already a proven=20 > > > concept in MIP4 > > > I fail to understand how this argument makes a=20 > difference, since=20 > > > the original problem statement is that the MIP client (the one=20 > > > generating BUs) in case of PMIP (i.e. the MAG) may change=20 > > during the=20 > > > lifetime of a MIP session. The problem addressed in MIP4 is a=20 > > > different one (replay protection). > > > It's off-topic, but I find this area of MIP4 overspecified when=20 > > > compared to approaches in other protocols (e.g. IEEE 802.16). A=20 > > > monotonically increasing counter is sufficient for replay=20 > protection > > >=20 > >=20 > > Agree, the purpose is different. But, replay protection has a=20 > > relation to time window. Timestamp provides the validity for=20 > > the same message. Its the same thing here, just that the=20 > > window is small. > >=20 > > Sri > >=20 > >=20 > >=20 > > > Regards > > >=20 > > > federico > > >=20 > > >=20 > > >=20 > > >=20 > > > -----Message d'origine----- > > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 : jeudi 6 = > > > septembre 2007 21:58 =C0 : 'Alexandru Petrescu'; 'netlmm' > > > Objet : RE: [netlmm] timestamp vs seqno redux > > >=20 > > >=20 > > > Please comment on this issue raised by Alex about mandating=20 > > Timestamp=20 > > > option. Alex is right, when we discussed this issue, the=20 > conclusion=20 > > > was to use Timestamp based approach, but we did not=20 > discuss if that=20 > > > was supposed to be mandatory to implement. > > >=20 > > > Now, w.r.t the issue, what are we mandating ? > > >=20 > > > - The ability for the LMA to generate a Timestamp and return > > > the timestamp option. The timestamp in relation to a specific > > > reference point. IMO, this is one system call on most OS's and > > > a delta addition if the timestamp generated is elapsed time past > > > some other reference point. We are talking about 5 to 8 lines > > > of code. I will be happy to publish this code for all standard > > > OS's. > > >=20 > > > - We are NOT mandating the nodes in the domain to sync up to > > > a clock source.=20 > > >=20 > > >=20 > > > How does it impact, if some deployment wants to use Seq Number=20 > > > approach ? > > >=20 > > > - No impact. The option need to be supported. Implies those 10 > > > lines of extra code. > > >=20 > > >=20 > > > Why this should be mandatory ? > > >=20 > > > Base draft does not support Context Transfers. Given that=20 > the draft=20 > > > will be incomplete, if we dont mandate the support. By=20 > > mandating the=20 > > > support, the LMA can always return its timestamp and the=20 > > MAG can use=20 > > > that timestamp and register. > > > This need to be done just once whenever the LMA/MAG clocks=20 > > are out of=20 > > > sync and just for one registration. One extra round trip=20 > > for the 1st=20 > > > registration between LMA/MAG pair. > > >=20 > > > But, if the LMA falls back to the seq number based=20 > approach and if=20 > > > there are no context transfers, there is always an extra=20 > round trip=20 > > > for each MN registration (at handoff). > > >=20 > > > So, I prefer the mandatory approach, its more efficient.=20 > > But, as I had=20 > > > it in the initial suggested text, I'm ok not mandating this and=20 > > > defining an error code "Timestamp option not supported". > > >=20 > > >=20 > > > Please comment. I want to close this issue.=20 > > >=20 > > >=20 > > > Implementation MUST support Timestamp option: [Yes/No] > > >=20 > > >=20 > > > Thanks > > > Sri > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > > Sent: Thursday, September 06, 2007 2:01 AM > > > > To: netlmm > > > > Subject: [netlmm] timestamp vs seqno redux > > > >=20 > > > > I've recently became aware that much nonsense discussion is > > > happening > > > > around the timestamp vs seqno. People keep saying that > > > seqno method > > > > is a possible alternative to timestamp but at the same=20 > time they=20 > > > > mandate in the document the timestamp method. This is complete=20 > > > > nonsense. > > > >=20 > > > > I don't want the timestamp method to be mandatory. > > > >=20 > > > > Anybody else wants the timestamp method to be a=20 > mandatory method? > > > >=20 > > > > Anybody else wants the timestamp method to be an=20 > > alternative method? > > > >=20 > > > > Alex > > > > PS: mandatory excerpts: > > > > "This document _requires_ the use of Timestamp Option" > > > > "An implementation MUST support Timestamp option." > > > >=20 > > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > > > This email has been scanned by the MessageLabs Email > > > Security System. > > > > For more information please visit=20 > http://www.messagelabs.com/email > > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 15:33:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp0U-0007nD-3x; Mon, 10 Sep 2007 15:33:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp0T-0007my-Ce for netlmm@ietf.org; Mon, 10 Sep 2007 15:33:13 -0400 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUp0S-00038s-KO for netlmm@ietf.org; Mon, 10 Sep 2007 15:33:13 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IUp0G2MzU-0007TI; Mon, 10 Sep 2007 15:33:09 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [netlmm] Issue: Auth Option support Date: Mon, 10 Sep 2007 22:32:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfzva2V0HjGPcAAR7Gc0DPZRTrdUQAI0b/g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46E55FF6.7090008@azairenet.com> Message-Id: <0MKpCa-1IUp0G2MzU-0007TI@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1//vM+0jDvtn0D0iXLq/exitYfrj+EItyRdHJ+ Cv/GWeFla7AZpoj4PbWqjMaoMafSCO+RClNWcJ9QnM/720a5Js 2p9I3z2GhZdBRok3IPx6A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay, Where did you get that idea ("SHOULD" is not useful for achieving interoperability) from? Definitely not in RFC 2129. 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Alper > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, September 10, 2007 6:17 PM > To: Alper Yegin > Cc: 'Narayanan, Vidya'; 'Sri Gundavelli'; 'Julien Laganier'; > netlmm@ietf.org > Subject: Re: [netlmm] Issue: Auth Option support > > Alper, > > When we need to ensure interoperability, we use "MUST" and not "SHOULD". > > Vijay > > Alper Yegin wrote: > > For interop "SHOULD implement and use", or even "SHOULD use" (like > Julien > > explained) is fine. "SHOULD" means "you better know what you are doing > if > > you don't follow", and that's exactly the case. > > > > If both ends are using some other mechanism and they know what each > other > > supports, they should not have to worry about (and implement) the > mechanism > > in the base spec. This is what SHOULD is for. > > > > Alper > > > > > >> -----Original Message----- > >> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >> Sent: Friday, September 07, 2007 10:27 PM > >> To: Sri Gundavelli; Julien Laganier; netlmm@ietf.org > >> Subject: RE: [netlmm] Issue: Auth Option support > >> > >> All, > >> On this topic, I believe we must have a mandatory to implement > mechanism > >> specified for standards track publication. We can leave the use at > >> "RECOMMENDED" or "SHOULD", but, we need a "MUST" on what the LMA and > MAG > >> need to implement. > >> > >> I had run this by the security directorate at the Chicago meeting and > my > >> understanding is that as long as we have "MUST implement IPsec" and > >> "SHOULD use IPsec", it would be fine. > >> > >> In other words, the SHOULD vs. MUST that we want to place on using > IPsec > >> can be discussed, but, the "MUST" on implementation is non-negotiable. > >> > >> This is inline with my understanding on what we need to state for a > >> complete specification. Given that channel security of signaling > >> messages is mandatory, unless we have at least one common denominator > >> that the MAG and LMA implementors will implement, we cannot ensure > >> interoperability. If they support multiple common mechanisms and chose > >> to use something other than IPsec, that's fine - hence, the "SHOULD" on > >> usage. > >> > >> Hope that helps. > >> > >> Thanks, > >> Vidya > >> > >>> -----Original Message----- > >>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >>> Sent: Friday, September 07, 2007 10:10 AM > >>> To: 'Julien Laganier'; netlmm@ietf.org > >>> Subject: RE: [netlmm] Issue: Auth Option support > >>> > >>> Hi Julien, > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: julien laganier [mailto:julien.laganier@gmail.com] On > >>> Behalf Of > >>>> Julien Laganier > >>>> Sent: Friday, September 07, 2007 5:29 AM > >>>> To: netlmm@ietf.org > >>>> Cc: Sri Gundavelli; 'Alper Yegin' > >>>> Subject: Re: [netlmm] Issue: Auth Option support > >>>> > >>>> Hi Sri, > >>>> > >>>> On Thursday 06 September 2007, Sri Gundavelli wrote: > >>>>> I'm confused, should the draft say > >>>>> > >>>>> "Both LMA and MAG MUST implement IPsec" and "all the signaling > >>>>> messages SHOULD be protected using IPSec". > >>>>> > >>>>> Will this ok, when reviewed by the security folks ? > >>>>> > >>>>> or mandate IPsec for this specification and let other draft relax > >>>>> this in the presence of an alternative approach ? > >>>>> > >>>>> Please comment. > >>>> Somehow, "MUST implement" and "SHOULD use" together seems a bit > >>>> tautologic. > >>>> > >>>> To me "SHOULD use" is sufficient since it covers both of the two > >>>> possibles cases: > >>>> > >>>> - deployment follows the SHOULD recommendation, it uses IPsec to > >>>> protect PMIPv6, in which case it supports it, since it's > >>> using it :), > >>>> or > >>>> > >>>> - deployment ignores the SHOULD recommendation, does not > >>> uses IPSec, > >>>> in which case it is useless to implement it since it's not used... > >>>> > >>>> I'd prefer having "MUST protect integrity of signalling > >>> messages, and > >>>> SHOULD use IPsec ESP to protect integrity of those messages". > >>>> We might > >>>> also add "MAY use IPsec AH". > >>>> > >>> > >>> I agree. I'm not against allowing other approaches. I'm only > >>> concerned, if we can leave the draft saying, "MUST protect > >>> integrity of signalling messages", with out specifying IPsec > >>> or some other approach. If that will pass the security > >>> review. We may have to state that IPsec MUST be used or some > >>> other approach, say Auth-Option MUST be used. Not sure, if we > >>> can leave this blank. > >>> > >>> Sri > >>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 15:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp3a-0007MG-C2; Mon, 10 Sep 2007 15:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp3Y-0007FJ-FI for netlmm@ietf.org; Mon, 10 Sep 2007 15:36:24 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUp3X-0001aG-3s for netlmm@ietf.org; Mon, 10 Sep 2007 15:36:24 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IUp3D3hQh-0008SM; Mon, 10 Sep 2007 15:36:20 -0400 From: "Alper Yegin" To: "'Sri Gundavelli'" , Subject: RE: [netlmm] Significance of MN-Identifier Date: Mon, 10 Sep 2007 22:35:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfwTglzGxi+UdpsQHGbbtafLERnrAAAWvZQANEcb4AACNC8MAAKk3gw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <008301c7f3b7$ef599a20$d5f6200a@amer.cisco.com> Message-Id: <0MKp8S-1IUp3D3hQh-0008SM@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/pYBWx5ACgeZ25wyGF9cbUZ33oIKUo+r7sQiH O50GszTMN71S1dq23ESe6Aa6BwqnxtVC7/E9sIAXQnQbx1Ar5i 853q5R5y8mfVolXtVNAwA== X-Spam-Score: -0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, > There were some comments on this from Jari. See the section > on "Acquiring the MN identifier" (Sec 6.6). > > The MN-Identifier may not be the real identifier of the MN. > But, the LMA and MAG must be able to identify a MN using > this identifier and exchange it in the signaling messages. Why do they have to identify the MN? This is what I'm trying to understand. What exactly do they achieve with the identity of the MN, when the signaling is between the MAG and LMA and the state info they are dealing with is a binding between a CoA and a HNP. > Also, but, it is not the identifier of the MAG. We are > creating a BCE state and that is for a MN. The identifier > of the MAG is used for authenticating and authorizing purposes. > And this identifier changes at each handoff and so what is > stored in the BCE is the MN identifier. BCE shall have a CoA and a HNP. Again I'm trying to understand why the BCE shall have the MN identifier. Alper > > Sri > > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Monday, September 10, 2007 4:27 AM > > To: netlmm@ietf.org > > Subject: [netlmm] Significance of MN-Identifier > > > > What's the significance of MN-Identifier as carried in PBU? > > > > Is it for the sake of identifying the MN during dynamic HNP assignment > > in-band with PMIP? > > > > If so, given that the HNP may also be assigned during network access > > authentication (out-of band with PMIP, as commonly done in integrated > > bootstrapping scenarios), we shall not mandate that the MN-identifier > > identifies the real MN. > > > > Another way of using of MN-identifier is to identify the > > "proxy MN" (MAG) > > with RFC 4285. > > > > Alper > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 15:45:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpCZ-0007FV-1p; Mon, 10 Sep 2007 15:45:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpCX-0007FN-R9 for netlmm@ietf.org; Mon, 10 Sep 2007 15:45:41 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUpCX-0003TU-CN for netlmm@ietf.org; Mon, 10 Sep 2007 15:45:41 -0400 X-IronPort-AV: E=Sophos;i="4.20,232,1186383600"; d="scan'208";a="522322737" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 Sep 2007 12:45:41 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8AJjeUa024639; Mon, 10 Sep 2007 12:45:40 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8AJjeEx010394; Mon, 10 Sep 2007 19:45:40 GMT Date: Mon, 10 Sep 2007 12:45:40 -0700 (PDT) From: Sri Gundavelli To: Alper Yegin Subject: RE: [netlmm] Significance of MN-Identifier In-Reply-To: <0MKp8S-1IUp3D3hQh-0008SM@mrelay.perfora.net> Message-ID: References: <0MKp8S-1IUp3D3hQh-0008SM@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2269; t=1189453540; x=1190317540; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[netlmm]=20Significance=20of=20MN-Identifier |Sender:=20; bh=L4Kk6L74IJgLTWFiSon0ryWhYGfekqNSSfkM1kqZK9U=; b=UZERiUmd0avgDVCKWonaJwBNq1VCuJKnz/x8tPpT58bWAjAleKi64yeqZ+U467fB38GmcnGT DaB6avyu56+mX4t6JENjxhYaxSDXKzbI3pBFlUUZhu3FszSKrUeORNCb; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, On Mon, 10 Sep 2007, Alper Yegin wrote: > Hi Sri, > >> There were some comments on this from Jari. See the section >> on "Acquiring the MN identifier" (Sec 6.6). >> >> The MN-Identifier may not be the real identifier of the MN. >> But, the LMA and MAG must be able to identify a MN using >> this identifier and exchange it in the signaling messages. > > Why do they have to identify the MN? This is what I'm trying to understand. > What exactly do they achieve with the identity of the MN, when the signaling > is between the MAG and LMA and the state info they are dealing with is a > binding between a CoA and a HNP. > > >> Also, but, it is not the identifier of the MAG. We are >> creating a BCE state and that is for a MN. The identifier >> of the MAG is used for authenticating and authorizing purposes. >> And this identifier changes at each handoff and so what is >> stored in the BCE is the MN identifier. > > BCE shall have a CoA and a HNP. Again I'm trying to understand why the BCE > shall have the MN identifier. > At handoff, nMAG may not know the HNP of the mobile node. How does it communicate with the LMA about the MN, if MN-Id is not used ? That's is essential, its required in BCE and also in signaling messages. Sri > Alper > > > > > >> >> Sri >> >> >> >>> -----Original Message----- >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>> Sent: Monday, September 10, 2007 4:27 AM >>> To: netlmm@ietf.org >>> Subject: [netlmm] Significance of MN-Identifier >>> >>> What's the significance of MN-Identifier as carried in PBU? >>> >>> Is it for the sake of identifying the MN during dynamic HNP assignment >>> in-band with PMIP? >>> >>> If so, given that the HNP may also be assigned during network access >>> authentication (out-of band with PMIP, as commonly done in integrated >>> bootstrapping scenarios), we shall not mandate that the MN-identifier >>> identifies the real MN. >>> >>> Another way of using of MN-identifier is to identify the >>> "proxy MN" (MAG) >>> with RFC 4285. >>> >>> Alper >>> >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 15:55:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpLk-0000sM-1B; Mon, 10 Sep 2007 15:55:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpLj-0000sD-4O for netlmm@ietf.org; Mon, 10 Sep 2007 15:55:11 -0400 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUpLh-000212-SZ for netlmm@ietf.org; Mon, 10 Sep 2007 15:55:11 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IUpLU1Rc7-0007Sf; Mon, 10 Sep 2007 15:55:03 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" , "'Ahmad Muhanna'" Subject: RE: [netlmm] Issue: Auth Option support Date: Mon, 10 Sep 2007 22:54:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfzu7JZN1cDF6CwQy+bGXbWNTVMwAAKH4yg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46E55CA3.6040103@azairenet.com> Message-Id: <0MKpCa-1IUpLU1Rc7-0007Sf@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/lTswggmf3TM+Ux43Hc3EvZ5b1VlnSqFOg9ac Ei27/1Ikfie62LkK1AFgiWCuh5u8uue5OZ+KhILPKYdGqHIhLy sBwnILhAnbYQDWaKUHIAA== X-Spam-Score: -0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I agree. It is OK for the base spec to define one mechanism (IPsec) used with one model (per-MAG-LMA SA). But we shall not limit all deployments to those choices. Alper > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, September 10, 2007 6:03 PM > To: Ahmad Muhanna > Cc: Sri Gundavelli; Alper Yegin; netlmm@ietf.org > Subject: Re: [netlmm] Issue: Auth Option support > > Ahmad, > > I don't believe the security model of using just one security > association between the MAG and the LMA for protecting the proxy BU and > Proxy BAck changes irrespective of whether IPsec or RFC 4285 is used. So > I don't agree with the suggested change. > > Vijay > > Ahmad Muhanna wrote: > > > >> Subject: Re: [netlmm] Issue: Auth Option support > >> > >> Sri, > >> > >> I agree with "SHOULD" for using IPsec and "MUST" for > >> supporting IPsec on the MAG and the LMA. > >> > >> If thats the consensus, we need to modify a few sentences in > >> the draft. > >> > >> In section 4, replace > >> > >>> The signaling messages, Proxy Binding Update and Proxy Binding > >>> Acknowledgement, exchanged between the mobile access > >> gateway and the > >>> local mobility anchor MUST be protected using IPsec > >> [RFC-4301] and > >>> using the established security association between them. The > >>> security association of the specific mobile node for which the > >>> signaling message is initiated is not required for > >> protecting these > >>> messages. > >> with > >> > >> The signaling messages, Proxy Binding Update and Proxy Binding > >> Acknowledgement, exchanged between the mobile access > >> gateway and the > >> local mobility anchor MUST be protected using security > >> associations > >> established between them. The security association of the specific > >> mobile node for which the signaling message is initiated is not > >> required for protecting these messages. > >> > >> We need the MUST above since we have to say that the proxy BU > >> and proxy BAck must be protected, irrespective of whether > >> IPsec or some other mechanism is used. > > > > [Ahmad] > > Hi Vijay, > > > > As far as I remember, the whole security concept of using a per-Node SA > > for PMIPv6 was based on the use of IPsec. Although, I see why you > > proposed the text but I still see a problem here. For example, the above > > text allows the use of an authentication option similar to FA-HA AE to > > secure the P-BU/P-BA. > > > > Now, since allowing a per-Node SA to be used in PMIPv6 was based on the > > use of IPsec, I believe we clearly need to keep that as part of the spec > > text. > > > > What about the following slight modification to what you just proposed: > > > > The signaling messages, Proxy Binding Update and Proxy Binding > > Acknowledgement, exchanged between the mobile access gateway and the > > local mobility anchor MUST be protected using a security association > > established between them. If IPsec is used, the security association > > > > of the specific mobile node for which the signaling message is > > initiated > > is not required for protecting these messages. > > > > Thanks, > > Ahmad > > > >> Add one sentence that says > >> > >> The mobile access gateway and the local mobility anchor MUST > >> implement IPsec for protecting the Proxy Mobile IPv6 signaling > >> messages [RFC-4301]. > >> > >> The paragraph that comes after already uses "SHOULD" for using ESP. > >> > >>> IPsec ESP [RFC-4303] in transport mode with mandatory integrity > >>> protection SHOULD be used for protecting the signaling messages. > >>> Confidentiality protection of these messages is not required. > >> Hope that is sufficient. > >> > >> Vijay > >> > >> > >> Sri Gundavelli wrote: > >>> I want some comments on this issue raised by Alper. > >>> > >>> > >>> Also, if I interpret Sec 5.1 [3775], the IPSec is being > >> mandated, only > >>> the use of IPsec ESP is optional. > >>> > >>> -------- > >>> 5.1. Binding Updates to Home Agents > >>> > >>> The mobile node and the home agent MUST use an IPsec security > >>> association to protect the integrity and authenticity of > >> the Binding > >>> Updates and Acknowledgements. Both the mobile nodes and the home > >>> agents MUST support and SHOULD use the Encapsulating > >> Security Payload > >>> (ESP) [6] header in transport mode and MUST use a > >> non-NULL payload > >>> authentication algorithm to provide data origin authentication, > >>> connectionless integrity and optional anti-replay > >> protection. Note > >>> that Authentication Header (AH) [5] is also possible but > >> for brevity > >>> not discussed in this specification. > >>> ------- > >>> > >>> > >>> I'm confused, should the draft say > >>> > >>> "Both LMA and MAG MUST implement IPsec" and "all the signaling > >>> messages SHOULD be protected using IPSec". > >>> > >>> Will this ok, when reviewed by the security folks ? > >>> > >>> or mandate IPsec for this specification and let other draft > >> relax this > >>> in the presence of an alternative approach ? > >>> > >>> Please comment. > >>> > >>> > >>> Sri > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>>> Sent: Tuesday, August 07, 2007 1:41 AM > >>>> To: 'Sri Gundavelli'; netlmm@ietf.org > >>>> Subject: RE: [netlmm] Issue: Auth Option support > >>>> > >>>>> The issue was related to the use of MUST clause in specifying the > >>>>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was > >>>>> suggesting that we relax that requirement and potentially leave a > >>>>> room for Auth Option support in future. > >>>> Actually, I didn't mean it specifically for Auth Option. It can be > >>>> anything. > >>>> Given that the security is handled by a separate protocol, > >> why lock > >>>> it down to "IPsec", when some other protocol (Auth Option being one > >>>> example) cannot > >>>> be used. > >>>> > >>>>> But, as most people agreed and as supported by Jari, this can > >>>> My understanding was the opposite, especially about Jari's > >> statement. > >>>>> always be changed in future when the support for new security > >>>>> mechanisms such as Auth Option are defined for Proxy > >> Mobile IPv6 and > >>>>> that specific document can always modify this requirement. > >>>>> So, no changes will be made to the document on this issue. > >>>> What if Auth Option is good enough as written? > >>>> What if a document in another SDO defines the alternative security > >>>> mechanism? > >>>> > >>>> For the type of interop we are seeking in IETF, "MUST > >> implement" is > >>>> good enough. "MUST use" is not necessary. > >>>> > >>>> Alper > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Regards > >>>>> Sri > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 10 16:10:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpb1-0007gf-Pi; Mon, 10 Sep 2007 16:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpb0-0007ga-Po for netlmm@ietf.org; Mon, 10 Sep 2007 16:10:58 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUpaz-0002MQ-97 for netlmm@ietf.org; Mon, 10 Sep 2007 16:10:58 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 13:10:56 -0700 Message-ID: <46E5A4CE.2090008@azairenet.com> Date: Mon, 10 Sep 2007 13:10:54 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] Issue: Auth Option support References: <0MKpCa-1IUp0G2MzU-0007TI@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IUp0G2MzU-0007TI@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2007 20:10:56.0429 (UTC) FILETIME=[B2643DD0:01C7F3E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Vijay, > > Where did you get that idea ("SHOULD" is not useful for achieving > interoperability) from? Definitely not in RFC 2129. Why were you looking in 2129? :) As I said earlier when you want to ensure interoperability, you typically use a "MUST". "SHOULD" means there is a probably that it is not implemented and you don't have an interoperable implementation. Vijay > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that > the > definition is an absolute requirement of the specification. > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > > Alper > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Monday, September 10, 2007 6:17 PM >> To: Alper Yegin >> Cc: 'Narayanan, Vidya'; 'Sri Gundavelli'; 'Julien Laganier'; >> netlmm@ietf.org >> Subject: Re: [netlmm] Issue: Auth Option support >> >> Alper, >> >> When we need to ensure interoperability, we use "MUST" and not "SHOULD". >> >> Vijay >> >> Alper Yegin wrote: >>> For interop "SHOULD implement and use", or even "SHOULD use" (like >> Julien >>> explained) is fine. "SHOULD" means "you better know what you are doing >> if >>> you don't follow", and that's exactly the case. >>> >>> If both ends are using some other mechanism and they know what each >> other >>> supports, they should not have to worry about (and implement) the >> mechanism >>> in the base spec. This is what SHOULD is for. >>> >>> Alper >>> >>> >>>> -----Original Message----- >>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>>> Sent: Friday, September 07, 2007 10:27 PM >>>> To: Sri Gundavelli; Julien Laganier; netlmm@ietf.org >>>> Subject: RE: [netlmm] Issue: Auth Option support >>>> >>>> All, >>>> On this topic, I believe we must have a mandatory to implement >> mechanism >>>> specified for standards track publication. We can leave the use at >>>> "RECOMMENDED" or "SHOULD", but, we need a "MUST" on what the LMA and >> MAG >>>> need to implement. >>>> >>>> I had run this by the security directorate at the Chicago meeting and >> my >>>> understanding is that as long as we have "MUST implement IPsec" and >>>> "SHOULD use IPsec", it would be fine. >>>> >>>> In other words, the SHOULD vs. MUST that we want to place on using >> IPsec >>>> can be discussed, but, the "MUST" on implementation is non-negotiable. >>>> >>>> This is inline with my understanding on what we need to state for a >>>> complete specification. Given that channel security of signaling >>>> messages is mandatory, unless we have at least one common denominator >>>> that the MAG and LMA implementors will implement, we cannot ensure >>>> interoperability. If they support multiple common mechanisms and chose >>>> to use something other than IPsec, that's fine - hence, the "SHOULD" on >>>> usage. >>>> >>>> Hope that helps. >>>> >>>> Thanks, >>>> Vidya >>>> >>>>> -----Original Message----- >>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>>> Sent: Friday, September 07, 2007 10:10 AM >>>>> To: 'Julien Laganier'; netlmm@ietf.org >>>>> Subject: RE: [netlmm] Issue: Auth Option support >>>>> >>>>> Hi Julien, >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: julien laganier [mailto:julien.laganier@gmail.com] On >>>>> Behalf Of >>>>>> Julien Laganier >>>>>> Sent: Friday, September 07, 2007 5:29 AM >>>>>> To: netlmm@ietf.org >>>>>> Cc: Sri Gundavelli; 'Alper Yegin' >>>>>> Subject: Re: [netlmm] Issue: Auth Option support >>>>>> >>>>>> Hi Sri, >>>>>> >>>>>> On Thursday 06 September 2007, Sri Gundavelli wrote: >>>>>>> I'm confused, should the draft say >>>>>>> >>>>>>> "Both LMA and MAG MUST implement IPsec" and "all the signaling >>>>>>> messages SHOULD be protected using IPSec". >>>>>>> >>>>>>> Will this ok, when reviewed by the security folks ? >>>>>>> >>>>>>> or mandate IPsec for this specification and let other draft relax >>>>>>> this in the presence of an alternative approach ? >>>>>>> >>>>>>> Please comment. >>>>>> Somehow, "MUST implement" and "SHOULD use" together seems a bit >>>>>> tautologic. >>>>>> >>>>>> To me "SHOULD use" is sufficient since it covers both of the two >>>>>> possibles cases: >>>>>> >>>>>> - deployment follows the SHOULD recommendation, it uses IPsec to >>>>>> protect PMIPv6, in which case it supports it, since it's >>>>> using it :), >>>>>> or >>>>>> >>>>>> - deployment ignores the SHOULD recommendation, does not >>>>> uses IPSec, >>>>>> in which case it is useless to implement it since it's not used... >>>>>> >>>>>> I'd prefer having "MUST protect integrity of signalling >>>>> messages, and >>>>>> SHOULD use IPsec ESP to protect integrity of those messages". >>>>>> We might >>>>>> also add "MAY use IPsec AH". >>>>>> >>>>> I agree. I'm not against allowing other approaches. I'm only >>>>> concerned, if we can leave the draft saying, "MUST protect >>>>> integrity of signalling messages", with out specifying IPsec >>>>> or some other approach. If that will pass the security >>>>> review. We may have to state that IPsec MUST be used or some >>>>> other approach, say Auth-Option MUST be used. Not sure, if we >>>>> can leave this blank. >>>>> >>>>> Sri >>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 02:40:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzQK-0003Ee-TB; Tue, 11 Sep 2007 02:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzQH-0003EG-ID; Tue, 11 Sep 2007 02:40:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUzQG-0000i6-E0; Tue, 11 Sep 2007 02:40:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 63C1232875; Tue, 11 Sep 2007 06:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IUzPm-00086P-AK; Tue, 11 Sep 2007 02:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Sep 2007 02:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: netlmm@ietf.org Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF. Title : Proxy Mobile IPv6 Author(s) : S. Gundavelli, et al. Filename : draft-ietf-netlmm-proxymip6-04.txt Pages : 57 Date : 2007-09-11 This specification describes a network-based mobility management protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 [RFC-3775]. This protocol enables mobility support to a host without requiring its participation in any mobility related signaling. The design principle in the case of network-based mobility management protocol relies on the network being in control of the mobility management. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-netlmm-proxymip6-04.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-ietf-netlmm-proxymip6-04.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: <2007-09-11023838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netlmm-proxymip6-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netlmm-proxymip6-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-11023838.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --NextPart-- From netlmm-bounces@ietf.org Tue Sep 11 02:43:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzTW-0004vM-5W; Tue, 11 Sep 2007 02:43:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUzTV-0004v9-1j for netlmm@ietf.org; Tue, 11 Sep 2007 02:43:53 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUzTU-0002T2-FH for netlmm@ietf.org; Tue, 11 Sep 2007 02:43:52 -0400 X-IronPort-AV: E=Sophos;i="4.20,235,1186351200"; d="scan'208";a="152764494" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Sep 2007 08:43:52 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8B6hppc005360 for ; Tue, 11 Sep 2007 08:43:51 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8B6hpEN003936 for ; Tue, 11 Sep 2007 06:43:51 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 08:43:51 +0200 Received: from sgundavewxp ([10.32.246.213]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 08:43:51 +0200 From: "Sri Gundavelli" To: "'netlmm'" Subject: FW: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Mon, 10 Sep 2007 23:43:48 -0700 Message-ID: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf0Pq9T2NcAJj3HRZ+zuMUIF+h8RAAABK8A X-OriginalArrivalTime: 11 Sep 2007 06:43:51.0245 (UTC) FILETIME=[1D254FD0:01C7F43F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3514; t=1189493031; x=1190357031; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20FW=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-proxymip6 -04.txt=20 |Sender:=20; bh=tb7wwbyRjCeHmzkIDHQy7d9Fp6svwVLesN+yq2UQ4kg=; b=kFfAf7h/ty0m85/rHqpSCv93Tz98o8CpbAyof40NgdfE/FUFvoCKBcCztiKo0PGICHyVNq6G e42Ku3Yg175jyI8u8V+zCl1LUjhf8z4aACDw39wusUiYmdeXIALGcGrv; Authentication-Results: ams-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org A new revision of the Proxy Mobile IPv6 draft, based on the inpiuts received ... Change log: - Text related to allowing alternate security mechanisms for protecting PMIP6 signaling messages (WG discussion) - Retransmissions (Shyam's comments) - Seq diagram for handoff. - Fixed the idnits warnings. - References to 4283 NAI option (Genadi's comments) - Minor editorial Should close all the open issues in the issue tracker. Please comment on any issues or nits. Thanks Sri > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, September 10, 2007 11:40 PM > To: i-d-announce@ietf.org > Cc: netlmm@ietf.org > Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Network-based Localized > Mobility Management Working Group of the IETF. > > > Title : Proxy Mobile IPv6 > Author(s) : S. Gundavelli, et al. > Filename : draft-ietf-netlmm-proxymip6-04.txt > Pages : 57 > Date : 2007-09-11 > > This specification describes a network-based mobility management > protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 > [RFC-3775]. This protocol enables mobility support to a host without > requiring its participation in any mobility related signaling. The > design principle in the case of network-based mobility management > protocol relies on the network being in control of the mobility > management. The mobility entities in the network are responsible for > tracking the movements of the host and initiating the required > mobility signaling on its behalf. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-ietf-netlmm-proxymip6-04.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-ietf-netlmm-proxymip6-04.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. > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 04:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV12b-0000qJ-1n; Tue, 11 Sep 2007 04:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV12Z-0000q9-EA for netlmm@ietf.org; Tue, 11 Sep 2007 04:24:11 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV12Y-0002na-2c for netlmm@ietf.org; Tue, 11 Sep 2007 04:24:11 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IV12J3kwT-0007QD; Tue, 11 Sep 2007 04:24:04 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [netlmm] Issue: Auth Option support Date: Tue, 11 Sep 2007 11:23:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfz5rK72M0GJomDTU21kHdeHLPJggAZei3g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46E5A4CE.2090008@azairenet.com> Message-Id: <0MKpCa-1IV12J3kwT-0007QD@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18KWhZtUxILZ/3cQEFbXEH2J47QCUF9ZeW7j4V wwZqNErpsbewMWjuy7qGWpNDsU6+xT7UeDiPMAORL8CkC/PmCR JYGFfrf+oTUGgb/Vt7K7w== X-Spam-Score: -0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Alper Yegin wrote: > > Vijay, > > > > Where did you get that idea ("SHOULD" is not useful for achieving > > interoperability) from? Definitely not in RFC 2129. > > Why were you looking in 2129? :) Nevertheless I was right that SHOULD is not defined the way you described in "RFC2129" :-) Kidding aside, you are right I had a typo. It should be RFC 2119. That's where SHOULD is defined as I quoted. Alper > > As I said earlier when you want to ensure interoperability, you > typically use a "MUST". "SHOULD" means there is a probably that it is > not implemented and you don't have an interoperable implementation. > > Vijay > > > > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that > > the > > definition is an absolute requirement of the specification. > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > > there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > > > Alper > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >> Sent: Monday, September 10, 2007 6:17 PM > >> To: Alper Yegin > >> Cc: 'Narayanan, Vidya'; 'Sri Gundavelli'; 'Julien Laganier'; > >> netlmm@ietf.org > >> Subject: Re: [netlmm] Issue: Auth Option support > >> > >> Alper, > >> > >> When we need to ensure interoperability, we use "MUST" and not > "SHOULD". > >> > >> Vijay > >> > >> Alper Yegin wrote: > >>> For interop "SHOULD implement and use", or even "SHOULD use" (like > >> Julien > >>> explained) is fine. "SHOULD" means "you better know what you are doing > >> if > >>> you don't follow", and that's exactly the case. > >>> > >>> If both ends are using some other mechanism and they know what each > >> other > >>> supports, they should not have to worry about (and implement) the > >> mechanism > >>> in the base spec. This is what SHOULD is for. > >>> > >>> Alper > >>> > >>> > >>>> -----Original Message----- > >>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>>> Sent: Friday, September 07, 2007 10:27 PM > >>>> To: Sri Gundavelli; Julien Laganier; netlmm@ietf.org > >>>> Subject: RE: [netlmm] Issue: Auth Option support > >>>> > >>>> All, > >>>> On this topic, I believe we must have a mandatory to implement > >> mechanism > >>>> specified for standards track publication. We can leave the use at > >>>> "RECOMMENDED" or "SHOULD", but, we need a "MUST" on what the LMA and > >> MAG > >>>> need to implement. > >>>> > >>>> I had run this by the security directorate at the Chicago meeting and > >> my > >>>> understanding is that as long as we have "MUST implement IPsec" and > >>>> "SHOULD use IPsec", it would be fine. > >>>> > >>>> In other words, the SHOULD vs. MUST that we want to place on using > >> IPsec > >>>> can be discussed, but, the "MUST" on implementation is non- > negotiable. > >>>> > >>>> This is inline with my understanding on what we need to state for a > >>>> complete specification. Given that channel security of signaling > >>>> messages is mandatory, unless we have at least one common denominator > >>>> that the MAG and LMA implementors will implement, we cannot ensure > >>>> interoperability. If they support multiple common mechanisms and > chose > >>>> to use something other than IPsec, that's fine - hence, the "SHOULD" > on > >>>> usage. > >>>> > >>>> Hope that helps. > >>>> > >>>> Thanks, > >>>> Vidya > >>>> > >>>>> -----Original Message----- > >>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >>>>> Sent: Friday, September 07, 2007 10:10 AM > >>>>> To: 'Julien Laganier'; netlmm@ietf.org > >>>>> Subject: RE: [netlmm] Issue: Auth Option support > >>>>> > >>>>> Hi Julien, > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: julien laganier [mailto:julien.laganier@gmail.com] On > >>>>> Behalf Of > >>>>>> Julien Laganier > >>>>>> Sent: Friday, September 07, 2007 5:29 AM > >>>>>> To: netlmm@ietf.org > >>>>>> Cc: Sri Gundavelli; 'Alper Yegin' > >>>>>> Subject: Re: [netlmm] Issue: Auth Option support > >>>>>> > >>>>>> Hi Sri, > >>>>>> > >>>>>> On Thursday 06 September 2007, Sri Gundavelli wrote: > >>>>>>> I'm confused, should the draft say > >>>>>>> > >>>>>>> "Both LMA and MAG MUST implement IPsec" and "all the signaling > >>>>>>> messages SHOULD be protected using IPSec". > >>>>>>> > >>>>>>> Will this ok, when reviewed by the security folks ? > >>>>>>> > >>>>>>> or mandate IPsec for this specification and let other draft relax > >>>>>>> this in the presence of an alternative approach ? > >>>>>>> > >>>>>>> Please comment. > >>>>>> Somehow, "MUST implement" and "SHOULD use" together seems a bit > >>>>>> tautologic. > >>>>>> > >>>>>> To me "SHOULD use" is sufficient since it covers both of the two > >>>>>> possibles cases: > >>>>>> > >>>>>> - deployment follows the SHOULD recommendation, it uses IPsec to > >>>>>> protect PMIPv6, in which case it supports it, since it's > >>>>> using it :), > >>>>>> or > >>>>>> > >>>>>> - deployment ignores the SHOULD recommendation, does not > >>>>> uses IPSec, > >>>>>> in which case it is useless to implement it since it's not used... > >>>>>> > >>>>>> I'd prefer having "MUST protect integrity of signalling > >>>>> messages, and > >>>>>> SHOULD use IPsec ESP to protect integrity of those messages". > >>>>>> We might > >>>>>> also add "MAY use IPsec AH". > >>>>>> > >>>>> I agree. I'm not against allowing other approaches. I'm only > >>>>> concerned, if we can leave the draft saying, "MUST protect > >>>>> integrity of signalling messages", with out specifying IPsec > >>>>> or some other approach. If that will pass the security > >>>>> review. We may have to state that IPsec MUST be used or some > >>>>> other approach, say Auth-Option MUST be used. Not sure, if we > >>>>> can leave this blank. > >>>>> > >>>>> Sri > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>> > >>>> _______________________________________________ > >>>> netlmm mailing list > >>>> netlmm@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 04:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1O9-00060n-F3; Tue, 11 Sep 2007 04:46:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1O8-0005uH-0y for netlmm@ietf.org; Tue, 11 Sep 2007 04:46:28 -0400 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV1O7-00058b-Iz for netlmm@ietf.org; Tue, 11 Sep 2007 04:46:27 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IV1Ng2eID-0007Js; Tue, 11 Sep 2007 04:46:26 -0400 From: "Alper Yegin" To: "'Sri Gundavelli'" Subject: RE: [netlmm] Significance of MN-Identifier Date: Tue, 11 Sep 2007 11:45:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Message-Id: <0MKpCa-1IV1Ng2eID-0007Js@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+VCZUbE750WOJK7TK91NdKvNl/zn+SDhTbqwx e/6uBVG/1RNMXALI5i54L9Y9f+jzcWLqkWIsVS5JKjZfOaG/u0 xM1xpzXkvRgD+AZLe6zwA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, > At handoff, nMAG may not know the HNP of the mobile node. How does it > communicate with the LMA about the MN, if MN-Id is not used ? That's > is essential, its required in BCE and also in signaling messages. So it is just for HNP assignment as I was saying: >>> Is it for the sake of identifying the MN during dynamic HNP >>> assignment in-band with PMIP? HNP can be assigned during network access authentication. I can't imagine when this is not possible or desirable. That's why mandating presence of MN-id that identifies the MN is not necessary, imo. If people can show a reason why we must also support HNP assignment in-band with PMIP, we can say: When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that carries the MN-id MUST be included in the PBU. Alper > > Sri > > > > Alper > > > > > > > > > > > >> > >> Sri > >> > >> > >> > >>> -----Original Message----- > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>> Sent: Monday, September 10, 2007 4:27 AM > >>> To: netlmm@ietf.org > >>> Subject: [netlmm] Significance of MN-Identifier > >>> > >>> What's the significance of MN-Identifier as carried in PBU? > >>> > >>> Is it for the sake of identifying the MN during dynamic HNP assignment > >>> in-band with PMIP? > >>> > >>> If so, given that the HNP may also be assigned during network access > >>> authentication (out-of band with PMIP, as commonly done in integrated > >>> bootstrapping scenarios), we shall not mandate that the MN-identifier > >>> identifies the real MN. > >>> > >>> Another way of using of MN-identifier is to identify the > >>> "proxy MN" (MAG) > >>> with RFC 4285. > >>> > >>> Alper > >>> > >>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 04:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1YX-00010I-4C; Tue, 11 Sep 2007 04:57:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV1YV-0000su-H6 for netlmm@ietf.org; Tue, 11 Sep 2007 04:57:11 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV1YU-0005kd-PN for netlmm@ietf.org; Tue, 11 Sep 2007 04:57:11 -0400 Received: from rly22f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly22f.srv.mailcontrol.com (MailControl) with ESMTP id l8B8v3ZG026032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Sep 2007 09:57:04 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly22f.srv.mailcontrol.com (MailControl) id l8B8uXjW022858 for netlmm@ietf.org; Tue, 11 Sep 2007 09:56:34 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly22f-eth0.srv.mailcontrol.com (envelope-sender Genadi.Velev@eu.panasonic.com) (MIMEDefang) with ESMTP id l8B8uSOt022113; Tue, 11 Sep 2007 09:56:33 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 0256_106dcef4_6044_11dc_94e0_0030482aac25; Tue, 11 Sep 2007 10:50:36 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091110562127-47115 ; Tue, 11 Sep 2007 10:56:21 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.125,BAYES_00: -1.665,TOTAL_SCORE: -1.540 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Tue, 11 Sep 2007 10:56:53 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] RE: Remaining Open Issues In-Reply-To: <008f01c7f3c0$960663a0$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] RE: Remaining Open Issues Thread-Index: AcfwXnExe6oZOl5aQOCii005cqOnggC/aV5AABPjXQAABPRFcAAjezRA References: <46DFB7A4.9010209@nomadiclab.com> <006101c7f35e$61ef5a20$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A993@lan-ex-02.panasonic.de> <008f01c7f3c0$960663a0$d5f6200a@amer.cisco.com> To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48AA1C@lan-ex-02.panasonic.de> Date: Tue, 11 Sep 2007 10:56:09 +0200 From: "Genadi Velev" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.70.1.132 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: NetLMM Mailing List X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, please see my comments below=20 > > > 2) Several parts of the document specify that NAI option must be > > included in the Proxy Binding Update and Proxy Binding=20 > Acknowledgement > > messages. However, in section 8 "Message Formats" nothing=20 > is mentioned > > about NAI option. Do you plan to include a descriptive text=20 > > in the next > > document version? > >=20 >=20 > Section 8.2 just identifies the PBU/PBA messages and the purpose. > It does not talk about the options that go into it. There are IPv6 > and IPv4 related options and all based on the signaling logic. > The options that go into the message are identified in the signaling > considerations. (Sections 5.3 and 6.9). It has the complete message > formats. >=20 Ok, I missed the reference to RFC4283 regarding NAI option, which by the way was given in section 5.1. in version -03. I noticed that you captured this in version -04 and modified Sections 5.3 and 6.9. -- thanks. >=20 >=20 >=20 > > 3) Sections 8.1 and 8.2 provide no description about the mobility > > options in both Proxy Binding Update and Proxy Binding=20 > Acknowledgement > > messages. I'd suggest to modify figures 11 and 12 and include some > > descriptive text.=20 > > An example for figure 11 can be as follows: > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5=20 > 6 7 8 9 0 1 > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence #=20 > > | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |A|H|L|K|M|R|P| Reserved | Lifetime =20 > > | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | =20 > > | > > . Mobility options =20 > > . > > | =20 > > | > > =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > >=20 > > Additional text in section 8.1 is necessary to describe the=20 > meaning of > > "Mobility Options". For example: > > =20 > > "Variable-length field of such length that the complete=20 > Proxy Binding > > Update message is an integer multiple of 8 octets long. This field > > contains zero or more TLV-encoded mobility options. The=20 > Proxy Binding > > Update message may include zero or more of the following options: >=20 > This draft is leveraging the message/option formats from 3775. I'm not > sure, if we should define any of that here. I can add an explicit=20 > statement, since, you had this doubt. My point was, that in figures 11 and 12 (respectively figures 13 and 14 in version -04) the last field of the PBU/PBA format were empty. Just for the readability of the document, we can put "Mobility options" in that field. >=20 >=20 > > * NAI Option (???) > > * Home Network Prefix Option > > * Link-local Address Option > > * Timestamp Option " > >=20 > > A corresponding text shall be included also in section 8.2,=20 > where the > > list with possible mobility option should be extended with=20 > > "Status Value > > Option". > >=20 >=20 > If you see 3775, the message and options are clearly mentioned=20 > seperately. In the message format sections, we are only defining the > message and the option formats. In what combination they are=20 > used, that > is based on the signaling logic.=20 I understand that RFC3775 gives a complete description of the mobiltiy header. However since a few mobiltiy options from RFC3775 are used in PMIP, IMO it can be beneficial to list the PMIP-relevant mobiltiy options somewhere in section 8 (like a summary of what is specified previously in section 5.3. and 6.9.). Thanks, Genadi >=20 > Thanks > Sri >=20 > >=20 =20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 09:42:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV612-0008ER-6N; Tue, 11 Sep 2007 09:42:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV611-0008EJ-1B for netlmm@ietf.org; Tue, 11 Sep 2007 09:42:55 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV610-0004sF-3a for netlmm@ietf.org; Tue, 11 Sep 2007 09:42:54 -0400 Received: from rly31f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly31f.srv.mailcontrol.com (MailControl) with ESMTP id l8BDgmlk009588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Sep 2007 14:42:50 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly31f.srv.mailcontrol.com (MailControl) id l8BDfld8000887 for netlmm@ietf.org; Tue, 11 Sep 2007 14:41:47 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly31f-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8BDfdnp032452; Tue, 11 Sep 2007 14:41:47 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 0e89_e7be844e_606b_11dc_97b5_0030482aac25; Tue, 11 Sep 2007 15:35:47 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091115331975-68944 ; Tue, 11 Sep 2007 15:33:19 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.103,BAYES_00: -1.665,TOTAL_SCORE: -1.562 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Tue, 11 Sep 2007 15:33:52 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] timestamp vs seqno redux In-Reply-To: <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGw References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> Date: Tue, 11 Sep 2007 15:33:01 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.70.1.141 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, my point is that NOT mandating synchronization to an external clock source for the timestamp option implies that sending PBU msgs with timestamp option is allowed even when MAGs are not (yet) synchronized. I.e., it would be allowed that a deployment uses only the returned timestamps in PBA msgs to synchronize the MAG clocks. I think the draft should not allow this for the following reasons: 1. If a MAG's clock is out of sync (i.e., not yet synced by receiving a PBA with timestamp) AND PBUs sent by this MAG are delayed, the out of sync situation may not be detectable by the LMA and old PBUs may be accepted by the LMA.=20 Consider the following example: MN attaches to MAG1 and shortly thereafter hands over to MAG2. MAG2's clock is in sync with LMA's clock, but MAG1's clock is out of sync and is ahead of LMA's clock by 5 seconds. MAG1-LMA link is highly congested. When MN attaches to MAG1, MAG1 sends PBU1 msg to LMA. This happens 3 seconds before the MN hands over to MAG2. The PBU1 msg is delayed by 5 seconds due to the congestion and hence arrives at LMA 2 seconds after handover. Despite of the delay, PBU1 has a valid timestamp from LMA's point of view due to the wrong clock of MAG1. MAG2 sends a PBU2 msg 1 second after handover. PBU2 is not significantly delayed and arrives at LMA ~1 seconds after handover with valid timestamp. In this scenario, the LMA will wrongly accept PBU1 arriving after PBU2, since both have a valid timestamp. Consequently, the LMA forwards packets to the wrong MAG (MAG1) and will not notice the out of sync of MAG1, which also means that the LMA doesn't return a timestamp in the PBA and MAG1's clock keeps to be out of sync. 2. When packets on the link between MAG and LMA experience high (and varying) packet delays (e.g., due to congestion), the timestamp in the PBA returned by the LMA may already be outdated at the time it arrives at the MAG. So exactly in the situation where a re-ordering of PBUs is needed, the synchronization mechanism may fail. My two cents. BR, Kilian > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Freitag, 7. September 2007 18:48 > To: 'Kilian Weniger' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Kilian, >=20 > =20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > > Sent: Friday, September 07, 2007 2:09 AM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri,=20 > >=20 > > > - We are NOT mandating the nodes in the domain to sync up to > > > a clock source.=20 > >=20 > > Hmm, so far I assumed that the proposal is to mandate the=20 > MAGs to sync > > up to an external clock source such as NTP server. > >=20 >=20 > For the timestamp option to work, we RECOMMEND the use of NTP for > synchronizing the clocks in the domain. However, we do not want to > mandate on a specific mechanism.=20 >=20 >=20 > > > Base draft does not support Context Transfers. Given that=20 > the draft > > > will be incomplete, if we dont mandate the support. By mandating > > > the support, the LMA can always return its timestamp and the MAG > > > can use that timestamp and register. This need to be done just > > > once whenever the LMA/MAG clocks are out of sync and just for one > > > registration. One extra round trip for the 1st=20 > registration between > > > LMA/MAG pair. > >=20 > > So the proposal is to allow the use of the timestamp option in the > > absence of any external time synchronization like NTP and=20 > to mandate a > > mechanism to synchronize clocks between MAGs and LMA (and=20 > > hence between > > all MAGs) using the timestamp option in PBU/PBA only (i.e., without > > utilizing NTP or an external clock source)? Is my=20 > > understanding correct? > >=20 >=20 > No. For this to work, we require the clocks to be in sync. > How its achieved, it could be based on NTP or some other protocols. > But, why should we mandate this. >=20 >=20 > > If so, can you please give some more details how the LMA can=20 > > detect that > > the clocks are out of sync? Is it based on a certain difference of > > timestamp in the received PBU and the current LMA's time?=20 > >=20 > > And how to differentiate the out of sync case from the out-of-order > > delivery case (i.e., a PBU is delayed and overtaken by=20 > > another PBU from > > another MAG)? For instance, if the LMA receives a PBU with timestamp > > equal to "current time of LMA - X" and X > threshold, how=20 > does the LMA > > know whether the=20 > > 1. the MAG clock is synchronized, but the PBU got delayed by X or > > 2. the PBU is not delayed, but the MAG's clock is out of sync by X? > > Ideally, in case 1 the LMA should just ignore the PBU, in case 2 it > > should accept it and sync clocks. > >=20 > > If the idea is to always reject a PBU with X > threshold=20 > and include a > > current timestamp in the PBA, then I guess the same could=20 > be done with > > sequence numbers instead of timestamps, right? > >=20 >=20 > For what ever reasons if the LMA and MAG clocks are out of sync, the > LMA can return its timestamp and the MAG can always apply that delta > in all the registration it sends. This is done just once, when ever > the clocks are off. But, with seq number scheme, this needs to be done > for each MN registration. Its as per the 3775 per MN seq number. >=20 > Sri >=20 > > BR, > >=20 > > Kilian > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 10:03:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6Kc-00022z-2W; Tue, 11 Sep 2007 10:03:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6Ka-00022r-D5 for netlmm@ietf.org; Tue, 11 Sep 2007 10:03:08 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV6KY-0005TQ-PO for netlmm@ietf.org; Tue, 11 Sep 2007 10:03:08 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8BE2Nij012833; Tue, 11 Sep 2007 16:02:28 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 11 Sep 2007 16:02:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Sep 2007 16:02:44 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A24@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116A57C2B@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on security model Thread-Index: Acfzu9R6l4QFQXIEQAuS3CKNgDr0GgADN/XAAAMPMJAAHO22sA== References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net><01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com><46E4B02C.5010101@azairenet.com><6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com> <46E55CA3.6040103@azairenet.com> <319D54578EAC3147BA8CC78DAB5467A501399A13@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116A57C2B@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Ahmad Muhanna" X-OriginalArrivalTime: 11 Sep 2007 14:02:45.0061 (UTC) FILETIME=[6D52BF50:01C7F47C] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: netlmm@ietf.org Subject: [netlmm] Question on security model X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, you're right that I was shamelessly abusing of the thread I apologize for that: I've changed the subject this time As I said, I understand that the security model has already been = discussed and the decision has been to go with a per-node SA I would appreciate if anybody could send me a pointer to any record = capturing the discussion that led to this decision More concretely, I would like to find out: - (first and most important) how the threat of a compromised MAG is = addressed with the per-node SA model? - did the discussion take into account the fact that MAG and LMA may = be located in different administrative domains? - did the discussion take place before or after the decision to move = away from DT solution to PMIP? Thanks federico -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Envoy=E9 : lundi 10 septembre 2007 20:08 =C0 : DE JUAN HUARTE FEDERICO; Vijay Devarapalli Cc : netlmm@ietf.org Objet : RE: [netlmm] Issue: Auth Option support Hi Federico, The issue of using a per-Node SA has been discussed long time ago and = reached consensus. This thread is not about the use of Per-Node vs. = Per-MN SA. It is about relaxing the mandate of the use IPsec to "MUST = implement" and SHOULD use" That is it. I Hope this address your concern. Regards, Ahmad =20 > -----Original Message----- > From: DE JUAN HUARTE FEDERICO > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > Sent: Monday, September 10, 2007 12:44 PM > To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10) > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Issue: Auth Option support >=20 > Hi, >=20 > I am slowly catching up with NETLMM and I acknowledge that in some=20 > aspects (e.g. security model) I'm definitely late >=20 > I understand from this email that, in this group it has already been=20 > decided to go for a per-node security model I followed the discussion=20 > about the security model in a PMIP solution in a given forum (Wimax)=20 > some years ago, and then it was considered that a per-node security=20 > model was was not sufficient The main argument I remember is the=20 > threat of the MAG being compromised and indiscriminately allocating=20 > resources from the LMA This is especially worrisome when the the MAG=20 > and the LMA belong to 2 different administrative domains Has this=20 > problem been addressed in this group? >=20 > Thanks >=20 > federico >=20 >=20 > =20 >=20 > -----Message d'origine----- > De : Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Envoy=E9 : lundi 10 septembre 2007 17:03 =C0 : Ahmad Muhanna Cc :=20 > netlmm@ietf.org Objet : Re: [netlmm] Issue: Auth Option support >=20 > Ahmad, >=20 > I don't believe the security model of using just one security=20 > association between the MAG and the LMA for protecting the proxy BU=20 > and Proxy BAck changes irrespective of whether IPsec or RFC 4285 is=20 > used. So > I don't agree with the suggested change. >=20 > Vijay >=20 > Ahmad Muhanna wrote: > > =20 > >> Subject: Re: [netlmm] Issue: Auth Option support > >> > >> Sri, > >> > >> I agree with "SHOULD" for using IPsec and "MUST" for > supporting IPsec > >> on the MAG and the LMA. > >> > >> If thats the consensus, we need to modify a few sentences in the=20 > >> draft. > >> > >> In section 4, replace > >> > >>> The signaling messages, Proxy Binding Update and Proxy Binding > >>> Acknowledgement, exchanged between the mobile access > >> gateway and the > >>> local mobility anchor MUST be protected using IPsec > >> [RFC-4301] and > >>> using the established security association between them. The > >>> security association of the specific mobile node for which the > >>> signaling message is initiated is not required for > >> protecting these > >>> messages. > >> with > >> > >> The signaling messages, Proxy Binding Update and Proxy Binding > >> Acknowledgement, exchanged between the mobile access > gateway and > >> the > >> local mobility anchor MUST be protected using security=20 > >> associations > >> established between them. The security association of > the specific > >> mobile node for which the signaling message is initiated is not > >> required for protecting these messages. > >> > >> We need the MUST above since we have to say that the proxy BU and=20 > >> proxy BAck must be protected, irrespective of whether > IPsec or some > >> other mechanism is used. > >=20 > > [Ahmad] > > Hi Vijay, > >=20 > > As far as I remember, the whole security concept of using a > per-Node > > SA for PMIPv6 was based on the use of IPsec. Although, I > see why you > > proposed the text but I still see a problem here. For example, the=20 > > above text allows the use of an authentication option > similar to FA-HA > > AE to secure the P-BU/P-BA. > >=20 > > Now, since allowing a per-Node SA to be used in PMIPv6 was based on=20 > > the use of IPsec, I believe we clearly need to keep that as part of=20 > > the spec text. > >=20 > > What about the following slight modification to what you > just proposed: > >=20 > > The signaling messages, Proxy Binding Update and Proxy Binding > > Acknowledgement, exchanged between the mobile access > gateway and the > > local mobility anchor MUST be protected using a > security association > > established between them. If IPsec is used, the security=20 > > association > >=20 > > of the specific mobile node for which the signaling message is=20 > > initiated > > is not required for protecting these messages. > >=20 > > Thanks, > > Ahmad > >=20 > >> Add one sentence that says > >> > >> The mobile access gateway and the local mobility anchor MUST > >> implement IPsec for protecting the Proxy Mobile IPv6 signaling > >> messages [RFC-4301]. > >> > >> The paragraph that comes after already uses "SHOULD" for using ESP. > >> > >>> IPsec ESP [RFC-4303] in transport mode with mandatory integrity > >>> protection SHOULD be used for protecting the signaling > messages. > >>> Confidentiality protection of these messages is not required. > >> Hope that is sufficient. > >> > >> Vijay > >> > >> > >> Sri Gundavelli wrote: > >>> I want some comments on this issue raised by Alper. > >>> > >>> > >>> Also, if I interpret Sec 5.1 [3775], the IPSec is being > >> mandated, only > >>> the use of IPsec ESP is optional. > >>> > >>> -------- > >>> 5.1. Binding Updates to Home Agents > >>> > >>> The mobile node and the home agent MUST use an IPsec security > >>> association to protect the integrity and authenticity of > >> the Binding > >>> Updates and Acknowledgements. Both the mobile nodes > and the home > >>> agents MUST support and SHOULD use the Encapsulating > >> Security Payload > >>> (ESP) [6] header in transport mode and MUST use a > >> non-NULL payload > >>> authentication algorithm to provide data origin authentication, > >>> connectionless integrity and optional anti-replay > >> protection. Note > >>> that Authentication Header (AH) [5] is also possible but > >> for brevity > >>> not discussed in this specification. > >>> ------- > >>> > >>> > >>> I'm confused, should the draft say > >>> > >>> "Both LMA and MAG MUST implement IPsec" and "all the signaling=20 > >>> messages SHOULD be protected using IPSec". > >>> > >>> Will this ok, when reviewed by the security folks ? > >>> > >>> or mandate IPsec for this specification and let other draft > >> relax this > >>> in the presence of an alternative approach ? > >>> > >>> Please comment. > >>> > >>> > >>> Sri > >>> > >>> > >>> > >>> > >>> =20 > >>> > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>>> Sent: Tuesday, August 07, 2007 1:41 AM > >>>> To: 'Sri Gundavelli'; netlmm@ietf.org > >>>> Subject: RE: [netlmm] Issue: Auth Option support > >>>> > >>>>> The issue was related to the use of MUST clause in > specifying the > >>>>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was=20 > >>>>> suggesting that we relax that requirement and > potentially leave a > >>>>> room for Auth Option support in future. > >>>> Actually, I didn't mean it specifically for Auth Option.=20 > It can be > >>>> anything. > >>>> Given that the security is handled by a separate protocol, > >> why lock > >>>> it down to "IPsec", when some other protocol (Auth > Option being one > >>>> example) cannot > >>>> be used. > >>>> > >>>>> But, as most people agreed and as supported by Jari, this can > >>>> My understanding was the opposite, especially about Jari's > >> statement. > >>>>> always be changed in future when the support for new security=20 > >>>>> mechanisms such as Auth Option are defined for Proxy > >> Mobile IPv6 and > >>>>> that specific document can always modify this requirement. > >>>>> So, no changes will be made to the document on this issue. > >>>> What if Auth Option is good enough as written? > >>>> What if a document in another SDO defines the > alternative security > >>>> mechanism? > >>>> > >>>> For the type of interop we are seeking in IETF, "MUST > >> implement" is > >>>> good enough. "MUST use" is not necessary. > >>>> > >>>> Alper > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Regards > >>>>> Sri > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 10:16:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6Xw-0004vT-BM; Tue, 11 Sep 2007 10:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6Xv-0004vJ-Ia for netlmm@ietf.org; Tue, 11 Sep 2007 10:16:55 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IV6Xu-00044A-Bd for netlmm@ietf.org; Tue, 11 Sep 2007 10:16:55 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1189520212!26411391!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5106 invoked from network); 11 Sep 2007 14:16:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 11 Sep 2007 14:16:52 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8BEGqh9028034 for ; Tue, 11 Sep 2007 07:16:52 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l8BEGpEF024583 for ; Tue, 11 Sep 2007 09:16:52 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8BEGoas024557 for ; Tue, 11 Sep 2007 09:16:51 -0500 (CDT) Message-ID: <46E6A353.6020302@gmail.com> Date: Tue, 11 Sep 2007 16:16:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: netlmm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-1, 10/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [netlmm] Re: timestamps description (was: I-D Action:draft-ietf-netlmm-proxymip6-04.txt) X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, thank you for the new version of the draft. Apparently it's insisted that PMIPv6 should rely on timestamps and time synchronization. I oppose this, and I prefer the draft to not RECOMMEND, neither SHOULD, nor MAY relying on time synchronization nor timestamps. But relying on sequence numbers, with a method I've already posted. When this gets agreed in the WG I agree. Until then, I have some nits about how time use is described in the new draft-04. > For solving this problem, this specification RECOMMENDS the use of > Timestamp option [Section 8.4]. The basic principle behind the use > of timestamps in binding registration messages is that the node > generating the message inserts the current time-of-day, and the node > receiving the message checks that this timestamp is greater than all > previously accepted timestamps. (It's section 8.5 actually.) > Timestamp > > A 64-bit unsigned integer field containing a timestamp. The value > indicates the number of seconds since January 1, 1970, 00:00 UTC, > by using a fixed point format. In this format, the integer number > of seconds is contained in the first 48 bits of the field, and the > remaining 16 bits indicate the number of 1/64K fractions of a > second. I think it should better say 1/65536 fractions of a second, and not 1/64K fractions. Let me say why. 64k means 65535 when talking bits and bytes. If we talk anything else then 64k means 64000 (meters, seconds, Hertz, Joules, etc.) I think we should also say in the draft that the timestamp contains the number of seconds measured at GMT (or some other place of your choice) since Jan 1st, 1970, 00h00 UTC. Let me say why. If we don't say where this timestamp was measured then there are different timezones on Earth, and a MAG in eg New Delhi will have a different timestamp than a LMA in Hyderabad, even if they represent the same moment. Alex Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF. > > > Title : Proxy Mobile IPv6 > Author(s) : S. Gundavelli, et al. > Filename : draft-ietf-netlmm-proxymip6-04.txt > Pages : 57 > Date : 2007-09-11 > > This specification describes a network-based mobility management > protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 > [RFC-3775]. This protocol enables mobility support to a host without > requiring its participation in any mobility related signaling. The > design principle in the case of network-based mobility management > protocol relies on the network being in control of the mobility > management. The mobility entities in the network are responsible for > tracking the movements of the host and initiating the required > mobility signaling on its behalf. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-04.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-ietf-netlmm-proxymip6-04.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-ietf-netlmm-proxymip6-04.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 10:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6Xy-0004wP-JJ; Tue, 11 Sep 2007 10:16:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6Xw-0004vO-6B for netlmm@ietf.org; Tue, 11 Sep 2007 10:16:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV6Xu-000449-FN for netlmm@ietf.org; Tue, 11 Sep 2007 10:16:56 -0400 X-IronPort-AV: E=Sophos;i="4.20,238,1186351200"; d="scan'208";a="152826624" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Sep 2007 16:16:53 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8BEGrli014161; Tue, 11 Sep 2007 16:16:53 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8BEGnEP011896; Tue, 11 Sep 2007 14:16:53 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 16:16:49 +0200 Received: from sgundavewxp ([10.32.246.213]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 16:16:48 +0200 From: "Sri Gundavelli" To: "'DE JUAN HUARTE FEDERICO'" , "'Ahmad Muhanna'" References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net><01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com><46E4B02C.5010101@azairenet.com><6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com><46E55CA3.6040103@azairenet.com><319D54578EAC3147BA8CC78DAB5467A501399A13@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA437116A57C2B@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399A24@FRVELSMBS12.ad2.ad.alcatel.com> Subject: RE: [netlmm] Question on security model Date: Tue, 11 Sep 2007 07:16:45 -0700 Message-ID: <00de01c7f47e$643e0030$37a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A24@FRVELSMBS12.ad2.ad.alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acfzu9R6l4QFQXIEQAuS3CKNgDr0GgADN/XAAAMPMJAAHO22sAAM/Dgg X-OriginalArrivalTime: 11 Sep 2007 14:16:49.0024 (UTC) FILETIME=[645D4800:01C7F47E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12496; t=1189520213; x=1190384213; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Question=20on=20security=20model |Sender:=20; bh=DbdRShv9TGwL4MGs5YEmvYjbmjajk+Z9sGW5iArSepo=; b=msLZWnZ6i70j5+UeiC3bllsJzbS/fPCX3u2hzsVz+gOBPdcCdr63h5H927XMc3HyaUfzTEI3 yWTEDeBv6KovWqaD5cY5GdWBoLBaZmPDknka1PrBkRzB+VvgxeO548DV; Authentication-Results: ams-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, I dont want to reopen this thread or enter any discussions. But, let me quickly make these points. 1. The security model, Configuring a MAG with all the MN's SA's does not offer any greater security than the other security model. Even in the Per-Node security model, there could be multiple SA's between the LMA and MAG, and different SA's can be used for different flows. 2. If a MAG is compromised, so are all the MN SA's. The damage is the same. If we argue that the MAG will not be allowed to create a BCE for a MN, that it does not have SA for, the same authorization can be achieved in the other model, by requiring the LMA to authorize the MAG before it creates BCE for a given MN. There is no advantage using Per-MN security model. Its just a false = sense of security, IMHO. With respect to your other question about when the discussions took = place, when the base draft was chosen, there were proposals that pitched other security models and they were presented in the WG. The WG chose a = specific proposal that supported Per-Node security model. Sri =20 =20 > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Tuesday, September 11, 2007 7:03 AM > To: Ahmad Muhanna > Cc: netlmm@ietf.org > Subject: [netlmm] Question on security model >=20 > Hi Ahmad, >=20 > you're right that I was shamelessly abusing of the thread > I apologize for that: I've changed the subject this time >=20 > As I said, I understand that the security model has already=20 > been discussed and the decision has been to go with a per-node SA > I would appreciate if anybody could send me a pointer to any=20 > record capturing the discussion that led to this decision >=20 > More concretely, I would like to find out: > - (first and most important) how the threat of a=20 > compromised MAG is addressed with the per-node SA model? > - did the discussion take into account the fact that MAG=20 > and LMA may be located in different administrative domains? > - did the discussion take place before or after the=20 > decision to move away from DT solution to PMIP? >=20 > Thanks >=20 > federico >=20 > -----Message d'origine----- > De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Envoy=E9 : lundi 10 septembre 2007 20:08 > =C0 : DE JUAN HUARTE FEDERICO; Vijay Devarapalli > Cc : netlmm@ietf.org > Objet : RE: [netlmm] Issue: Auth Option support >=20 > Hi Federico, >=20 > The issue of using a per-Node SA has been discussed long time=20 > ago and reached consensus. This thread is not about the use=20 > of Per-Node vs. Per-MN SA. It is about relaxing the mandate=20 > of the use IPsec to "MUST implement" and SHOULD use" > That is it. >=20 > I Hope this address your concern. >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: DE JUAN HUARTE FEDERICO > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > Sent: Monday, September 10, 2007 12:44 PM > > To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10) > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Issue: Auth Option support > >=20 > > Hi, > >=20 > > I am slowly catching up with NETLMM and I acknowledge that in some=20 > > aspects (e.g. security model) I'm definitely late > >=20 > > I understand from this email that, in this group it has=20 > already been=20 > > decided to go for a per-node security model I followed the=20 > discussion=20 > > about the security model in a PMIP solution in a given=20 > forum (Wimax)=20 > > some years ago, and then it was considered that a per-node security=20 > > model was was not sufficient The main argument I remember is the=20 > > threat of the MAG being compromised and indiscriminately allocating=20 > > resources from the LMA This is especially worrisome when=20 > the the MAG=20 > > and the LMA belong to 2 different administrative domains Has this=20 > > problem been addressed in this group? > >=20 > > Thanks > >=20 > > federico > >=20 > >=20 > > =20 > >=20 > > -----Message d'origine----- > > De : Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Envoy=E9 : lundi 10 septembre 2007 17:03 =C0 : Ahmad Muhanna Cc :=20 > > netlmm@ietf.org Objet : Re: [netlmm] Issue: Auth Option support > >=20 > > Ahmad, > >=20 > > I don't believe the security model of using just one security=20 > > association between the MAG and the LMA for protecting the proxy BU=20 > > and Proxy BAck changes irrespective of whether IPsec or RFC 4285 is=20 > > used. So > > I don't agree with the suggested change. > >=20 > > Vijay > >=20 > > Ahmad Muhanna wrote: > > > =20 > > >> Subject: Re: [netlmm] Issue: Auth Option support > > >> > > >> Sri, > > >> > > >> I agree with "SHOULD" for using IPsec and "MUST" for > > supporting IPsec > > >> on the MAG and the LMA. > > >> > > >> If thats the consensus, we need to modify a few sentences in the=20 > > >> draft. > > >> > > >> In section 4, replace > > >> > > >>> The signaling messages, Proxy Binding Update and=20 > Proxy Binding > > >>> Acknowledgement, exchanged between the mobile access > > >> gateway and the > > >>> local mobility anchor MUST be protected using IPsec > > >> [RFC-4301] and > > >>> using the established security association between them. The > > >>> security association of the specific mobile node for=20 > which the > > >>> signaling message is initiated is not required for > > >> protecting these > > >>> messages. > > >> with > > >> > > >> The signaling messages, Proxy Binding Update and=20 > Proxy Binding > > >> Acknowledgement, exchanged between the mobile access > > gateway and > > >> the > > >> local mobility anchor MUST be protected using security=20 > > >> associations > > >> established between them. The security association of > > the specific > > >> mobile node for which the signaling message is=20 > initiated is not > > >> required for protecting these messages. > > >> > > >> We need the MUST above since we have to say that the=20 > proxy BU and=20 > > >> proxy BAck must be protected, irrespective of whether > > IPsec or some > > >> other mechanism is used. > > >=20 > > > [Ahmad] > > > Hi Vijay, > > >=20 > > > As far as I remember, the whole security concept of using a > > per-Node > > > SA for PMIPv6 was based on the use of IPsec. Although, I > > see why you > > > proposed the text but I still see a problem here. For=20 > example, the=20 > > > above text allows the use of an authentication option > > similar to FA-HA > > > AE to secure the P-BU/P-BA. > > >=20 > > > Now, since allowing a per-Node SA to be used in PMIPv6=20 > was based on=20 > > > the use of IPsec, I believe we clearly need to keep that=20 > as part of=20 > > > the spec text. > > >=20 > > > What about the following slight modification to what you > > just proposed: > > >=20 > > > The signaling messages, Proxy Binding Update and Proxy Binding > > > Acknowledgement, exchanged between the mobile access > > gateway and the > > > local mobility anchor MUST be protected using a > > security association > > > established between them. If IPsec is used, the security=20 > > > association > > >=20 > > > of the specific mobile node for which the signaling=20 > message is=20 > > > initiated > > > is not required for protecting these messages. > > >=20 > > > Thanks, > > > Ahmad > > >=20 > > >> Add one sentence that says > > >> > > >> The mobile access gateway and the local mobility anchor MUST > > >> implement IPsec for protecting the Proxy Mobile IPv6=20 > signaling > > >> messages [RFC-4301]. > > >> > > >> The paragraph that comes after already uses "SHOULD" for=20 > using ESP. > > >> > > >>> IPsec ESP [RFC-4303] in transport mode with=20 > mandatory integrity > > >>> protection SHOULD be used for protecting the signaling > > messages. > > >>> Confidentiality protection of these messages is not required. > > >> Hope that is sufficient. > > >> > > >> Vijay > > >> > > >> > > >> Sri Gundavelli wrote: > > >>> I want some comments on this issue raised by Alper. > > >>> > > >>> > > >>> Also, if I interpret Sec 5.1 [3775], the IPSec is being > > >> mandated, only > > >>> the use of IPsec ESP is optional. > > >>> > > >>> -------- > > >>> 5.1. Binding Updates to Home Agents > > >>> > > >>> The mobile node and the home agent MUST use an IPsec security > > >>> association to protect the integrity and authenticity of > > >> the Binding > > >>> Updates and Acknowledgements. Both the mobile nodes > > and the home > > >>> agents MUST support and SHOULD use the Encapsulating > > >> Security Payload > > >>> (ESP) [6] header in transport mode and MUST use a > > >> non-NULL payload > > >>> authentication algorithm to provide data origin=20 > authentication, > > >>> connectionless integrity and optional anti-replay > > >> protection. Note > > >>> that Authentication Header (AH) [5] is also possible but > > >> for brevity > > >>> not discussed in this specification. > > >>> ------- > > >>> > > >>> > > >>> I'm confused, should the draft say > > >>> > > >>> "Both LMA and MAG MUST implement IPsec" and "all the signaling=20 > > >>> messages SHOULD be protected using IPSec". > > >>> > > >>> Will this ok, when reviewed by the security folks ? > > >>> > > >>> or mandate IPsec for this specification and let other draft > > >> relax this > > >>> in the presence of an alternative approach ? > > >>> > > >>> Please comment. > > >>> > > >>> > > >>> Sri > > >>> > > >>> > > >>> > > >>> > > >>> =20 > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > >>>> Sent: Tuesday, August 07, 2007 1:41 AM > > >>>> To: 'Sri Gundavelli'; netlmm@ietf.org > > >>>> Subject: RE: [netlmm] Issue: Auth Option support > > >>>> > > >>>>> The issue was related to the use of MUST clause in > > specifying the > > >>>>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was=20 > > >>>>> suggesting that we relax that requirement and > > potentially leave a > > >>>>> room for Auth Option support in future. > > >>>> Actually, I didn't mean it specifically for Auth Option.=20 > > It can be > > >>>> anything. > > >>>> Given that the security is handled by a separate protocol, > > >> why lock > > >>>> it down to "IPsec", when some other protocol (Auth > > Option being one > > >>>> example) cannot > > >>>> be used. > > >>>> > > >>>>> But, as most people agreed and as supported by Jari, this can > > >>>> My understanding was the opposite, especially about Jari's > > >> statement. > > >>>>> always be changed in future when the support for new security=20 > > >>>>> mechanisms such as Auth Option are defined for Proxy > > >> Mobile IPv6 and > > >>>>> that specific document can always modify this requirement. > > >>>>> So, no changes will be made to the document on this issue. > > >>>> What if Auth Option is good enough as written? > > >>>> What if a document in another SDO defines the > > alternative security > > >>>> mechanism? > > >>>> > > >>>> For the type of interop we are seeking in IETF, "MUST > > >> implement" is > > >>>> good enough. "MUST use" is not necessary. > > >>>> > > >>>> Alper > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> Regards > > >>>>> Sri > > >>>>> > > >>>>> _______________________________________________ > > >>>>> netlmm mailing list > > >>>>> netlmm@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > > >>> _______________________________________________ > > >>> netlmm mailing list > > >>> netlmm@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > >> > > >> _______________________________________________ > > >> netlmm mailing list > > >> netlmm@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/netlmm > > >> > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 10:20:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6b5-0002eI-45; Tue, 11 Sep 2007 10:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6b3-0002e3-Ab for netlmm@ietf.org; Tue, 11 Sep 2007 10:20:09 -0400 Received: from hu-out-0506.google.com ([72.14.214.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV6b2-000484-3N for netlmm@ietf.org; Tue, 11 Sep 2007 10:20:09 -0400 Received: by hu-out-0506.google.com with SMTP id 31so592265huc for ; Tue, 11 Sep 2007 07:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=4D7Nw6pgfV0sX1qi7k9IB/er4Ohv7eeNuRD+k9xqg/U=; b=SJAFN1iVW3jm7wTpqGwNKIOzcuYKlbiOk7/mcgQd2JctnLarprrQFj6frO3mNs/+IpKbuRAdhusFUeEhl3m8CT7k0ZXgVQ279ZdyjaAThfc7/qE4/1S/ilvUnT8o2SbeoAvWBsremG1ZhF1kTaum2F+D3yHl3QU2G9OYrhUHhY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=qfaKQmm0b4ZBEKrKZocxEXnspeQgPTl7zIUjdzItBfd7VfnkldAlU9u3XHMi2WwkGAA5xlx+RC6fte6Yq69PjqlFm6hYT7iPvF8WwfQY7be1sPIxF0Qvha2wN4VjmZGSoizcplxgqB5PUo8lM/i7BjnWOUVTyAncL1H8MlFguXY= Received: by 10.67.28.4 with SMTP id f4mr737725ugj.1189520406998; Tue, 11 Sep 2007 07:20:06 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id o30sm1140850ugd.2007.09.11.07.20.04 (version=SSLv3 cipher=OTHER); Tue, 11 Sep 2007 07:20:06 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Date: Tue, 11 Sep 2007 16:20:02 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709111620.02475.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [netlmm] DNAv6/SEND and timestamp synchronization problems X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Folks, It has been discussed on the mailing list that synchronizing time across different MAGs to allow reordering of pBUs might be a problem. While thinking about the issue I got the idea to leverage on SEND to solve that issue. When the MN uses DNAv6 for movement detection along with SEND to secure ND signaling (which includes DNAv6), all ND messages sent by the MN will contain a timestamp representing the local time on the MN. Thus, all MAGs to which a given MN attached to have access to a single per-MN timestamp source. Using pBU timestamps from that source will avoid issues with time synchronization of different MAGs since timestamps are synchronized at the source. Thoughts? --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 10:27:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6iO-0001bY-1z; Tue, 11 Sep 2007 10:27:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6iM-0001Zw-UT for netlmm@ietf.org; Tue, 11 Sep 2007 10:27:42 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV6iL-0004Rd-MH for netlmm@ietf.org; Tue, 11 Sep 2007 10:27:42 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8BEPI514085; Tue, 11 Sep 2007 14:25:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Sep 2007 09:27:34 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116AAFE01@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A24@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on security model Thread-Index: Acfzu9R6l4QFQXIEQAuS3CKNgDr0GgADN/XAAAMPMJAAHO22sAANm2OQ References: <0MKp8S-1IIKcu1WNe-0005rE@mrelay.perfora.net><01e801c7f0c1$80e341c0$d4f6200a@amer.cisco.com><46E4B02C.5010101@azairenet.com><6FC4416DDE56C44DA0AEE67BC7CA4371169E8EDD@zrc2hxm2.corp.nortel.com> <46E55CA3.6040103@azairenet.com> <319D54578EAC3147BA8CC78DAB5467A501399A13@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116A57C2B@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399A24@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: netlmm@ietf.org Subject: [netlmm] RE: Question on security model X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, No problem. I agree with Sri on this point too, I do not support Re-opening this = topic again. However, I would like to emphasize one point that Sri mentioned in his = reply, if compromised MAG is a real threat, then LMA may optionally = choose to authorize the MN PMIP service at initial attach. I guess that = takes care of the threat you have in mind. Regards, Ahmad =20 > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Tuesday, September 11, 2007 9:03 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: netlmm@ietf.org > Subject: Question on security model >=20 > Hi Ahmad, >=20 > you're right that I was shamelessly abusing of the thread I=20 > apologize for that: I've changed the subject this time >=20 > As I said, I understand that the security model has already=20 > been discussed and the decision has been to go with a=20 > per-node SA I would appreciate if anybody could send me a=20 > pointer to any record capturing the discussion that led to=20 > this decision >=20 > More concretely, I would like to find out: > - (first and most important) how the threat of a=20 > compromised MAG is addressed with the per-node SA model? > - did the discussion take into account the fact that MAG=20 > and LMA may be located in different administrative domains? > - did the discussion take place before or after the=20 > decision to move away from DT solution to PMIP? >=20 > Thanks >=20 > federico >=20 > -----Message d'origine----- > De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 :=20 > lundi 10 septembre 2007 20:08 =C0 : DE JUAN HUARTE FEDERICO;=20 > Vijay Devarapalli Cc : netlmm@ietf.org Objet : RE: [netlmm]=20 > Issue: Auth Option support >=20 > Hi Federico, >=20 > The issue of using a per-Node SA has been discussed long time=20 > ago and reached consensus. This thread is not about the use=20 > of Per-Node vs. Per-MN SA. It is about relaxing the mandate=20 > of the use IPsec to "MUST implement" and SHOULD use" > That is it. >=20 > I Hope this address your concern. >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: DE JUAN HUARTE FEDERICO > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > Sent: Monday, September 10, 2007 12:44 PM > > To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10) > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Issue: Auth Option support > >=20 > > Hi, > >=20 > > I am slowly catching up with NETLMM and I acknowledge that in some=20 > > aspects (e.g. security model) I'm definitely late > >=20 > > I understand from this email that, in this group it has=20 > already been=20 > > decided to go for a per-node security model I followed the=20 > discussion=20 > > about the security model in a PMIP solution in a given=20 > forum (Wimax)=20 > > some years ago, and then it was considered that a per-node security=20 > > model was was not sufficient The main argument I remember is the=20 > > threat of the MAG being compromised and indiscriminately allocating=20 > > resources from the LMA This is especially worrisome when=20 > the the MAG=20 > > and the LMA belong to 2 different administrative domains Has this=20 > > problem been addressed in this group? > >=20 > > Thanks > >=20 > > federico > >=20 > >=20 > > =20 > >=20 > > -----Message d'origine----- > > De : Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Envoy=E9 : lundi 10 septembre 2007 17:03 =C0 : Ahmad Muhanna Cc :=20 > > netlmm@ietf.org Objet : Re: [netlmm] Issue: Auth Option support > >=20 > > Ahmad, > >=20 > > I don't believe the security model of using just one security=20 > > association between the MAG and the LMA for protecting the proxy BU=20 > > and Proxy BAck changes irrespective of whether IPsec or RFC 4285 is=20 > > used. So > > I don't agree with the suggested change. > >=20 > > Vijay > >=20 > > Ahmad Muhanna wrote: > > > =20 > > >> Subject: Re: [netlmm] Issue: Auth Option support > > >> > > >> Sri, > > >> > > >> I agree with "SHOULD" for using IPsec and "MUST" for > > supporting IPsec > > >> on the MAG and the LMA. > > >> > > >> If thats the consensus, we need to modify a few sentences in the=20 > > >> draft. > > >> > > >> In section 4, replace > > >> > > >>> The signaling messages, Proxy Binding Update and=20 > Proxy Binding > > >>> Acknowledgement, exchanged between the mobile access > > >> gateway and the > > >>> local mobility anchor MUST be protected using IPsec > > >> [RFC-4301] and > > >>> using the established security association between them. The > > >>> security association of the specific mobile node for=20 > which the > > >>> signaling message is initiated is not required for > > >> protecting these > > >>> messages. > > >> with > > >> > > >> The signaling messages, Proxy Binding Update and=20 > Proxy Binding > > >> Acknowledgement, exchanged between the mobile access > > gateway and > > >> the > > >> local mobility anchor MUST be protected using security=20 > > >> associations > > >> established between them. The security association of > > the specific > > >> mobile node for which the signaling message is=20 > initiated is not > > >> required for protecting these messages. > > >> > > >> We need the MUST above since we have to say that the=20 > proxy BU and=20 > > >> proxy BAck must be protected, irrespective of whether > > IPsec or some > > >> other mechanism is used. > > >=20 > > > [Ahmad] > > > Hi Vijay, > > >=20 > > > As far as I remember, the whole security concept of using a > > per-Node > > > SA for PMIPv6 was based on the use of IPsec. Although, I > > see why you > > > proposed the text but I still see a problem here. For=20 > example, the=20 > > > above text allows the use of an authentication option > > similar to FA-HA > > > AE to secure the P-BU/P-BA. > > >=20 > > > Now, since allowing a per-Node SA to be used in PMIPv6=20 > was based on=20 > > > the use of IPsec, I believe we clearly need to keep that=20 > as part of=20 > > > the spec text. > > >=20 > > > What about the following slight modification to what you > > just proposed: > > >=20 > > > The signaling messages, Proxy Binding Update and Proxy Binding > > > Acknowledgement, exchanged between the mobile access > > gateway and the > > > local mobility anchor MUST be protected using a > > security association > > > established between them. If IPsec is used, the security=20 > > > association > > >=20 > > > of the specific mobile node for which the signaling=20 > message is=20 > > > initiated > > > is not required for protecting these messages. > > >=20 > > > Thanks, > > > Ahmad > > >=20 > > >> Add one sentence that says > > >> > > >> The mobile access gateway and the local mobility anchor MUST > > >> implement IPsec for protecting the Proxy Mobile IPv6=20 > signaling > > >> messages [RFC-4301]. > > >> > > >> The paragraph that comes after already uses "SHOULD" for=20 > using ESP. > > >> > > >>> IPsec ESP [RFC-4303] in transport mode with=20 > mandatory integrity > > >>> protection SHOULD be used for protecting the signaling > > messages. > > >>> Confidentiality protection of these messages is not required. > > >> Hope that is sufficient. > > >> > > >> Vijay > > >> > > >> > > >> Sri Gundavelli wrote: > > >>> I want some comments on this issue raised by Alper. > > >>> > > >>> > > >>> Also, if I interpret Sec 5.1 [3775], the IPSec is being > > >> mandated, only > > >>> the use of IPsec ESP is optional. > > >>> > > >>> -------- > > >>> 5.1. Binding Updates to Home Agents > > >>> > > >>> The mobile node and the home agent MUST use an IPsec security > > >>> association to protect the integrity and authenticity of > > >> the Binding > > >>> Updates and Acknowledgements. Both the mobile nodes > > and the home > > >>> agents MUST support and SHOULD use the Encapsulating > > >> Security Payload > > >>> (ESP) [6] header in transport mode and MUST use a > > >> non-NULL payload > > >>> authentication algorithm to provide data origin=20 > authentication, > > >>> connectionless integrity and optional anti-replay > > >> protection. Note > > >>> that Authentication Header (AH) [5] is also possible but > > >> for brevity > > >>> not discussed in this specification. > > >>> ------- > > >>> > > >>> > > >>> I'm confused, should the draft say > > >>> > > >>> "Both LMA and MAG MUST implement IPsec" and "all the signaling=20 > > >>> messages SHOULD be protected using IPSec". > > >>> > > >>> Will this ok, when reviewed by the security folks ? > > >>> > > >>> or mandate IPsec for this specification and let other draft > > >> relax this > > >>> in the presence of an alternative approach ? > > >>> > > >>> Please comment. > > >>> > > >>> > > >>> Sri > > >>> > > >>> > > >>> > > >>> > > >>> =20 > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > >>>> Sent: Tuesday, August 07, 2007 1:41 AM > > >>>> To: 'Sri Gundavelli'; netlmm@ietf.org > > >>>> Subject: RE: [netlmm] Issue: Auth Option support > > >>>> > > >>>>> The issue was related to the use of MUST clause in > > specifying the > > >>>>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was=20 > > >>>>> suggesting that we relax that requirement and > > potentially leave a > > >>>>> room for Auth Option support in future. > > >>>> Actually, I didn't mean it specifically for Auth Option.=20 > > It can be > > >>>> anything. > > >>>> Given that the security is handled by a separate protocol, > > >> why lock > > >>>> it down to "IPsec", when some other protocol (Auth > > Option being one > > >>>> example) cannot > > >>>> be used. > > >>>> > > >>>>> But, as most people agreed and as supported by Jari, this can > > >>>> My understanding was the opposite, especially about Jari's > > >> statement. > > >>>>> always be changed in future when the support for new security=20 > > >>>>> mechanisms such as Auth Option are defined for Proxy > > >> Mobile IPv6 and > > >>>>> that specific document can always modify this requirement. > > >>>>> So, no changes will be made to the document on this issue. > > >>>> What if Auth Option is good enough as written? > > >>>> What if a document in another SDO defines the > > alternative security > > >>>> mechanism? > > >>>> > > >>>> For the type of interop we are seeking in IETF, "MUST > > >> implement" is > > >>>> good enough. "MUST use" is not necessary. > > >>>> > > >>>> Alper > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> Regards > > >>>>> Sri > > >>>>> > > >>>>> _______________________________________________ > > >>>>> netlmm mailing list > > >>>>> netlmm@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > > >>> _______________________________________________ > > >>> netlmm mailing list > > >>> netlmm@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > >> > > >> _______________________________________________ > > >> netlmm mailing list > > >> netlmm@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/netlmm > > >> > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 10:48:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV72S-0004dc-Iv; Tue, 11 Sep 2007 10:48:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV72R-0004dP-O7 for netlmm@ietf.org; Tue, 11 Sep 2007 10:48:27 -0400 Received: from hu-out-0506.google.com ([72.14.214.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV72P-0004yF-Pn for netlmm@ietf.org; Tue, 11 Sep 2007 10:48:27 -0400 Received: by hu-out-0506.google.com with SMTP id 31so598088huc for ; Tue, 11 Sep 2007 07:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=+05l+CYdnjVpvH4SCdDAKj8I3GLbLum+lqdrg+E9v9M=; b=sRyz9KsEyd6KyZMX8+o6iXCj+N7GKeBqBYI4m+2TU7WUYTa3rwMyjEvUSk2yoDpWx8U7sKlUW79VDn5TEEfflrKYFch9mJUPrMDmSch/Lb+lqg2D8UA1Rv1Eienc1rbJLVEUV9ft3LvFVdhZzruTJxILJzATuQzwKdurutwS6ZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=YjqLIK1G192gClCT4DG3/PauEXOdwadjLoYRM2NGc0ZbOGuaf9DVEvcdR6jklXs3ulHgzAVzqDIECdlNtLvPoDQ89Em6zUwdm8VWoWJKv/LU1mXtrFLheR6IKvZ4jlo1hlFmnN+hnIQRN9sCvL/i47Ef2KthW5zpt40EayMPoTY= Received: by 10.67.106.19 with SMTP id i19mr760806ugm.1189522104602; Tue, 11 Sep 2007 07:48:24 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id j1sm1178995ugf.2007.09.11.07.48.22 (version=SSLv3 cipher=OTHER); Tue, 11 Sep 2007 07:48:23 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] Question on security model Date: Tue, 11 Sep 2007 16:48:19 +0200 User-Agent: KMail/1.9.6 References: <319D54578EAC3147BA8CC78DAB5467A501399A24@FRVELSMBS12.ad2.ad.alcatel.com> <00de01c7f47e$643e0030$37a36b80@amer.cisco.com> In-Reply-To: <00de01c7f47e$643e0030$37a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200709111648.19896.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 'DE JUAN HUARTE FEDERICO' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Tuesday 11 September 2007, Sri Gundavelli wrote: > Hi Federico, > > I dont want to reopen this thread or enter any discussions. But, let > me quickly make these points. > > > 1. The security model, Configuring a MAG with all the MN's SA's does > not offer any greater security than the other security model. Even in > the Per-Node security model, there could be multiple SA's between the > LMA and MAG, and different SA's can be used for different flows. > > 2. If a MAG is compromised, so are all the MN SA's. The damage is the > =A0 =A0same. If we argue that the MAG will not be allowed to create a BCE > =A0 =A0for a MN, that it does not have SA for, the same authorization can > =A0 =A0be achieved in the other model, by requiring the LMA to authorize > the MAG before it creates BCE for a given MN. > > There is no advantage using Per-MN security model. Its just a false > sense of security, IMHO. Trying to be more precise here. The "Per-MN security model" reffered to is actually one in which the a=20 LMA and a given MAG have a different security association for each MN=20 attached to that MAG.=20 I think it is more precise to denote this model as "Per-MN LMA-MAG=20 Security Association" model. In this model, even though there's one security association per MN, the=20 security association is still established between the _MAG_ and LMA.=20 Thus, if the _MAG_ is compromised, the per-MN LMA-MAG SA cannot prevent=20 the MAG to issue undue signalling on behalf of a MN attached to it=20 since it has the corresponding per-MN LMA-MAG security association. On=20 the other hand, it would prevent a compromised MAG to issue undue=20 signalling on behalf of a MN which is not attached to it _if_ it has no=20 per-MN LMA-MAG SA for that MN. The draft currently specifies a "Per-MAG LMA-MAG Security Association"=20 model with no mechanisms in place to prevent a compromized MAG to issue=20 undue signalling for any MN (both attached and not attached to it). The=20 draft does however call in it security considerations section for such=20 a mechanism to be present, but as part of another, unspecified,=20 protocol: To eliminate the threats related to a compromised mobile access gateway, this specification recommends that the local mobility anchor before accepting a Proxy Binding Update message for a given mobile node, should ensure the mobile node is definitively attached to the mobile access gateway that sent the binding registration request. Thus, the "Per-MN LMA-MAG Security Association" model can be more secure=20 than the "per-MAG LMA-MAG Security Association" against MAG=20 compromission only if is guaranteed that establishment of the "Per-MN=20 LMA-MAG Security Association" cannot happen with a MAG to which the MN=20 is not attached. That might be ensured by tying this SA establishment=20 to network access control, but this would be, as for the "Per-MAG=20 LMA-MAG Security Association", a mechanism implemented as part of=20 another, unspecified, protocol. In conclusion, without another mechanism realizing what's being called=20 for in the security considerations, both security models are IMHO=20 equivalent. =2D-julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 11:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7Ss-0000wy-Ei; Tue, 11 Sep 2007 11:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7Sr-0000ws-5R for netlmm@ietf.org; Tue, 11 Sep 2007 11:15:45 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV7So-0005Wd-HX for netlmm@ietf.org; Tue, 11 Sep 2007 11:15:45 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8BFF1Ah031209; Tue, 11 Sep 2007 17:15:05 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 11 Sep 2007 17:14:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] timestamp vs seqno redux Date: Tue, 11 Sep 2007 17:14:34 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A26@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116A57D1B@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABfNwGAAE6an0ACRc75QAAnxKmAAAD5AsAAqJnwQ References: <319D54578EAC3147BA8CC78DAB5467A501399A12@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AB8@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116A57D1B@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Ahmad Muhanna" X-OriginalArrivalTime: 11 Sep 2007 15:14:35.0149 (UTC) FILETIME=[7655FBD0:01C7F486] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: ca81a19b939ce054f98c8f830c2d7742 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, I don't see why do you consider that sending the timestamp in the SeqNum = is a new mechanism IMO, it's something that can already be done with any MIP implementation The difference between sending timestamp in SeqNum or sending it in TS = option is that in the former case the LMA would not need to worry about = sending the TS option back In other words, I see a difference between: 1- Sending timestamp in SeqNum =3D> only MAGs need to be time synched 2- Sending timestamp in TS option =3D> all MAGs and LMAs should be = time synched Choosing between the 2 options is probably deployment dependent In the first case (LMA is not synched with the MAGs) what is the added = value of using the TS option instead of carrying the timestamp in = SeqNum? Ahmad> I agree with Sri, That has been discussed and agreed upon.=20 Was it agreed to use time synchronization (thus #1 falls in the = agreement) or to use the timestamp option (only #2 can be considered)? Anyway, I understood from Sri call for inputs that he was pushing the TS = option beyond what had been agreed, so I presume that there's (some) = room for closing this issue properly Regards federico PS: I'm discussing with Sri offline, so given that you have an opinion = I'll add you in CC -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Envoy=E9 : lundi 10 septembre 2007 20:40 =C0 : Ahmad Muhanna; DE JUAN HUARTE FEDERICO; Sri Gundavelli Cc : netlmm Objet : RE: [netlmm] timestamp vs seqno redux Hi Federico, It seems that I did not read the whole case No. 2. You are proposing a new mechanism/field to use timestamp.=20 I agree with Sri, That has been discussed and agreed upon.=20 Regards, Ahmad =20 > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10) > Sent: Monday, September 10, 2007 1:34 PM > To: 'DE JUAN HUARTE FEDERICO'; 'Sri Gundavelli' > Cc: 'netlmm' > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Federico, >=20 > I just would like to make one comment quickly here and we can go over=20 > other issues later. > Timestamp option still needs to be used in Case No. 2 as you specified = > below. Otherwise, how the whole sequencing would work? Right? >=20 >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: DE JUAN HUARTE FEDERICO > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > Sent: Monday, September 10, 2007 12:44 PM > > To: Sri Gundavelli > > Cc: netlmm > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > thanks for your answer > > I've taken some time to process your answer and what is=20 > written in the=20 > > draft (v3) > >=20 > > >From your email answer: > > Sri> ... Allowing LMA to return its own timestamp, > > essentially establishes one node in that domain to dictate=20 > some order,=20 > > in the absence of NTP snchronization ... > > Sri> ... We either depend on NTP to synchronize all the > > clocks in the node or let LMA always returns its timestamp, ... > >=20 > > I understand now that there's a case that I had not taken into=20 > > account: > > 1- The MAGs may be syncronized by context transfer =3D>=20 > SeqNum in BU > > 2- The MAGs may be synchronized by a common time reference =3D>=20 > > SeqNum (carrying a timestamp) in BU > > 3- The MAGs may be not-synchronized at all =3D> timestamp=20 > option Can=20 > > you confirm that the timestamp option is only to cover case #3? >=20 > [Ahmad] > Timestamp option is used in case 2 and case 3. >=20 > > By the way the draft is written (section 5.4), it's not=20 > clear to me if=20 > > you also expect the MAGs to use the timestamp option in case #2=20 > > (connected to a common time reference). I think in case #2 the LMA=20 > > should not interfere with the explicit mechanism used to=20 > synchronize=20 > > clocks (e.g. NTP) > >=20 > > In case #3, (MAGs not connected to a common time=20 > reference), I still=20 > > perceive that the draft expects the LMA to become a sort of Time=20 > > Reference Master > >=20 > > In general, I can't see how the timestamp option can provide a=20 > > deterministic behavior and therefore I don't think that the draft=20 > > should RECOMMEND it, unless the following points are addressed: > > - for the timestamp option to work, the rate of BUs=20 > between a given=20 > > MAG and a given LMA should not allow for time deviations=20 > larger than=20 > > the threshold to declare a timestamp as invalid > > - A factor to take into account is RTDs (RoundTrip=20 > Delays) between=20 > > MAGs and LMA: if the pMAG-LMA RTD is larger than the=20 > nMAG-LMA RTD then=20 > > the pMAG "clock" will be delayed with respect to the one of the nMAG > > - Unclear what the effects of congestion will be: if the link=20 > > between the LMA and the pMAG is more congested than the=20 > link between=20 > > the LMA and the nMAG, the previous effect will be even worse > > - Something that needs to be considered in this discussion is=20 > > how/when resources will be released by the pMAG. If there's no=20 > > communication between pMAG and nMAG, there will need to be=20 > a timeout=20 > > or a revocation message from the LMA. In any case, there's=20 > a period of=20 > > time between the nMAG sending the BU and the pMAG releasing its own=20 > > binding. During this period of time the pMAG may send a BU, thereby=20 > > creating a race condition. In the extreme case, both the=20 > pMAG and the=20 > > nMAG may send the BU with the same time (virtually) > > - When connected to multiple LMAs (e.g. roaming), MAGs have to=20 > > maintain multiple timers (one per LMA). Doable but complex Can you=20 > > please tell me if the following concerns have been raised=20 > before and=20 > > if yes how are they addressed? > >=20 > > In my opinion, NETLMM should RECOMMEND the MAGs to be synchronized=20 > > (case #1 or case #2) and not the timestamp option (as in=20 > section 5.4)=20 > > In these conditions, a non-synchronized MAG is an error case (thus=20 > > infrequent): #1) context transfer didn't take place or #2) lost=20 > > synchronization with the time reference. > > In order to address such error case it is enough to let the MAG=20 > > indicate it explicitly to the LMA, so that the LMA can > > (exceptionally) ignore the sequencing. > > I don't see much added value in a solution like #3 (LMA as Time=20 > > Reference Master), but I'm not against describing it in the spec as=20 > > long as it is not REQUIRED or RECOMENDED > >=20 > > A couple side reactions: > > Sri> But, the base draft has to be complete. We should allow > > deployments to happen just based on this spec. If we dont support=20 > > Timestamp and if there is no CT, how will registrations=20 > happen ? The=20 > > LMA will always reject the first request for each MN. > > MAGs need to be synchronized (CT or common time ref). The=20 > first BU of=20 > > all will need to carry a "Reset-Synch" flag Any MAG that is not=20 > > synched (no CT or no connectivity to time > > ref) SHOULD also assert the "Reset-Synch" flag > >=20 > > Sri> ...replay protection has a relation to time window.=20 > > Timestamp provides the validity for the same message. Its the same=20 > > thing here, just that the window is small. > > We have very different opinions here, but as long as replay=20 > protection=20 > > is not an argument for the timestamp option, no need to discuss it > >=20 > > Regards > >=20 > > federico > >=20 > > -----Message d'origine----- > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :=20 > > vendredi 7 septembre 2007 19:02 =C0 : DE JUAN HUARTE FEDERICO Cc :=20 > > 'netlmm' > > Objet : RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Federico, > > =20 > > Please see inline .. > >=20 > >=20 > > > -----Original Message----- > > > From: DE JUAN HUARTE FEDERICO > > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > > Sent: Friday, September 07, 2007 2:04 AM > > > To: Sri Gundavelli > > > Cc: netlmm > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Sri, > > >=20 > > > I haven't had time to catch up yet with the new draft, so I > > apologize > > > if any of my comments below has already been addresed > > >=20 > > > Sri> ... what are we mandating? The ability for the LMA to > > > generate a Timestamp and return the timestamp option ... > > > I'm trying to understand the motivation for this mandate > > >=20 > > > I understand the need in the LMA to identify the sequence=20 > of BUs in=20 > > > order to avoid race conditions when more than one MAG can=20 > send a BU=20 > > > for the same user The minimum requirement from LMA point=20 > of view is=20 > > > that the ID carried in the BU represents a free-running > > counter that > > > increases monotonically It follows that the requirement for > > the MAGs > > > is to synchronize the values used in the BU-ID Let me stress that=20 > > > these "minimum requirements" are only for synchronization between=20 > > > MAGs, i.e. not including LMA > > >=20 > > > Timestamps is a valid solution for filling in the ID when > > there's time > > > synchronization (with sufficient accuracy) between MAGs Let > > me stress > > > that the precondition for using timestamps should only be=20 > > > synchronization between MAGs, i.e. not including LMA By > > including LMA > > > in the equation, it seems that we're trying to correct > > deviations in > > > the time synchronization of MAGs via PMIP That is, the=20 > LMA becomes=20 > > > some kind of synch Master. Honestly, I don't think it is right to=20 > > > extend PMIP scope in such way > > >=20 > >=20 > > No, that is not true. We are not trying to sync clocks using PMIP.=20 > > Allowing LMA to return its own timestamp, essentially=20 > establishes one=20 > > node in that domain to dictate some order, in the absence of NTP=20 > > snchronization. In a network with multiple nodes, we need a global=20 > > scale such as a timestamp. We either depend on NTP to=20 > synchronize all=20 > > the clocks in the node or let LMA always returns its=20 > timestamp, so as=20 > > for the MAG to use that timestamp (delta) in the subsequent=20 > requests. > > Otherwise, every MAG in the network may be sending different=20 > > timestamps and the LMA would not know, which one to accept. > >=20 > >=20 > > > Let me cite your answers to Alper (from another email): > > > Sri> ... It is important to highlight the fact that we need > > > this entire synchronization logic to avoid one scenario, > > where the LMA > > > ends up processing a PBU that was sent by pMAG and the=20 > LMA received=20 > > > that much later due to network out of order deliverly ... > > > [FDJ] This problem statement seems wrong. Unordered > > delivery because > > > of nw congestion does not make any difference What matters is the=20 > > > relationship between the ID sent by the pMAG and the one > > sent by the > > > nMAG The only requirement that we can make is that pMAG and > > nMAG must > > > synchronize this ID There's no way the LMA can't tell in > > which order > > > these 2 BUus were sent if the IDs are not-synchronized > > >=20 > >=20 > > It does. The race condition would not be an issue, if LMA receives=20 > > packets in the order in which they were generated by=20 > different MAG's.=20 > > The LMA may potentially delete a valid current binding, because it=20 > > received a stale binding from the prev MAG. > >=20 > > If pMAG and nMAG can synchronize the id's, the whole issue is mute.=20 > > That is the alternative approach to timestamp based scheme that the=20 > > draft supports. MAG can certainly send the seq number of=20 > the MN that=20 > > it obtained as part of handoff using CT. No need for=20 > timestamps there. > >=20 > >=20 > > > Sri> ... If a deployment does not enable NTP kind of > > > protocols and if the LMA receives a packet with PBU from a=20 > > MAG with a=20 > > > invalid timestamp, the LMA can return its own timestamp=20 > and the MAG=20 > > > can use the same in the requests to avoid this special race=20 > > condition=20 > > > ... > > > [FDJ] If the deployment does not enable NTP, all PBUs will have a=20 > > > wrong ID. Or do you expect the MAG to synch to the same=20 > timebase as=20 > > > the LMA when the LMA returns the timestamp option? > > > Furthermore, I fail to understand the solution you propose:=20 > > > how can the LMA declare that the ID (timestamp) is invalid? > > > Use case: > > > - pMAG send BU at 10 AM > > > - nMAG sends BU at 11 AM > > > - LMA receives BU from nMAG at 11:15 AM. Will it return=20 > > timestamp=20 > > > to nMAG, so that the BU can be resent? > >=20 > > The LMA returns its timestamp if it detects that the clocks=20 > > are out of sync.=20 > >=20 > >=20 > > > - LMA receives BU from pMAG at 11:30 AM. Will it retun=20 > > timestamp to=20 > > > pMAG, so that BU can be resent? Or maybe the proposal is=20 > > that LMA will=20 > > > decide that pMAG BU was sent earlier than nMAG BU and therefore=20 > > > discard it. > >=20 > >=20 > > Yes. The LMA will discard it. You should read the Timestamp section. > >=20 > >=20 > > The latter=20 > > > makes sense but it means that the LMA has to assume that=20 > > pMAG and nMAG=20 > > > are in synch. And then we're back to the minimum requirement > > >=20 > > > In summary, in my opinion: > > > 1- The LMA MAY be able to generate timestamps (but=20 > should not be=20 > > > required to) > > > 2- The LMA MAY know that the source used for the ID is a=20 > > timestamp=20 > > > (but should not be required to) > > > 3- If the LMA is not timestamp aware, the MAG MAY use=20 > timestamps=20 > > > (but should not be required to) > > > 4- If the LMA is timestamp aware, the MAG MAY use=20 > > timestamps (but=20 > > > should not be required to) If any of the 4 statements would=20 > > reduce the=20 > > > usability of PMIP in any way, I would appreciate to have a=20 > > more clear=20 > > > problem statement > >=20 > > > Thus: Implementation MUST support Timestamp option: No > >=20 > > Ok. > >=20 > >=20 > > > And I would even push it further: if the previous 4=20 > > statements can be=20 > > > agreed to, then the logical conclusion is that timestamps=20 > > can be left=20 > > > out of the specification (at most an informative note would do) > > >=20 > > > A couple of collateral comments: > > > - I understand that CT (Context Transfer) is already=20 > > acknowledged=20 > > > as a valid alternative solution > > > For some reason, CT is left out of scope. Fine for me,=20 > > but I don't=20 > > > think it's a fair consequence to mandate timestamps > > > The fact that "context transfer is out of scope" doesn't=20 > > equate to=20 > > > "there is no context transfer" > >=20 > > But, the base draft has to be complete. We should allow=20 > > deployments to happen just based on this spec. If we dont=20 > > support Timestamp and if there is no CT, how will=20 > > registrations happen ? The LMA will always reject the first=20 > > request for each MN.=20 > >=20 > > > Is it the working assumption that a solution without CT=20 > > is simpler=20 > > > than a solution with CT? This would be a wrong assumption > > > If we have to choose between specifying timestamps or=20 > specifying=20 > > > CT, then I prefer the latter. It's clear that it will=20 > require more=20 > > > work but it will be more useful > > >=20 > > > - If a nMAG sends a BU for a given user without=20 > synchronization=20 > > > with pMAG it may be useful to have the option to indicate=20 > it to the=20 > > > LMA > > > In other words, I propose a flag "OOS ID" (Out of Synch > > > ID) sent by the MAG, so that the LMA can reset the sequencing=20 > > > algorithm for a given MN > > >=20 > > > - I have read in other emails that timestamps are=20 > > already a proven=20 > > > concept in MIP4 > > > I fail to understand how this argument makes a=20 > difference, since=20 > > > the original problem statement is that the MIP client (the one=20 > > > generating BUs) in case of PMIP (i.e. the MAG) may change=20 > > during the=20 > > > lifetime of a MIP session. The problem addressed in MIP4 is a=20 > > > different one (replay protection). > > > It's off-topic, but I find this area of MIP4 overspecified when=20 > > > compared to approaches in other protocols (e.g. IEEE 802.16). A=20 > > > monotonically increasing counter is sufficient for replay=20 > protection > > >=20 > >=20 > > Agree, the purpose is different. But, replay protection has a=20 > > relation to time window. Timestamp provides the validity for=20 > > the same message. Its the same thing here, just that the=20 > > window is small. > >=20 > > Sri > >=20 > >=20 > >=20 > > > Regards > > >=20 > > > federico > > >=20 > > >=20 > > >=20 > > >=20 > > > -----Message d'origine----- > > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 : jeudi 6 = > > > septembre 2007 21:58 =C0 : 'Alexandru Petrescu'; 'netlmm' > > > Objet : RE: [netlmm] timestamp vs seqno redux > > >=20 > > >=20 > > > Please comment on this issue raised by Alex about mandating=20 > > Timestamp=20 > > > option. Alex is right, when we discussed this issue, the=20 > conclusion=20 > > > was to use Timestamp based approach, but we did not=20 > discuss if that=20 > > > was supposed to be mandatory to implement. > > >=20 > > > Now, w.r.t the issue, what are we mandating ? > > >=20 > > > - The ability for the LMA to generate a Timestamp and return > > > the timestamp option. The timestamp in relation to a specific > > > reference point. IMO, this is one system call on most OS's and > > > a delta addition if the timestamp generated is elapsed time past > > > some other reference point. We are talking about 5 to 8 lines > > > of code. I will be happy to publish this code for all standard > > > OS's. > > >=20 > > > - We are NOT mandating the nodes in the domain to sync up to > > > a clock source.=20 > > >=20 > > >=20 > > > How does it impact, if some deployment wants to use Seq Number=20 > > > approach ? > > >=20 > > > - No impact. The option need to be supported. Implies those 10 > > > lines of extra code. > > >=20 > > >=20 > > > Why this should be mandatory ? > > >=20 > > > Base draft does not support Context Transfers. Given that=20 > the draft=20 > > > will be incomplete, if we dont mandate the support. By=20 > > mandating the=20 > > > support, the LMA can always return its timestamp and the=20 > > MAG can use=20 > > > that timestamp and register. > > > This need to be done just once whenever the LMA/MAG clocks=20 > > are out of=20 > > > sync and just for one registration. One extra round trip=20 > > for the 1st=20 > > > registration between LMA/MAG pair. > > >=20 > > > But, if the LMA falls back to the seq number based=20 > approach and if=20 > > > there are no context transfers, there is always an extra=20 > round trip=20 > > > for each MN registration (at handoff). > > >=20 > > > So, I prefer the mandatory approach, its more efficient.=20 > > But, as I had=20 > > > it in the initial suggested text, I'm ok not mandating this and=20 > > > defining an error code "Timestamp option not supported". > > >=20 > > >=20 > > > Please comment. I want to close this issue.=20 > > >=20 > > >=20 > > > Implementation MUST support Timestamp option: [Yes/No] > > >=20 > > >=20 > > > Thanks > > > Sri > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > > Sent: Thursday, September 06, 2007 2:01 AM > > > > To: netlmm > > > > Subject: [netlmm] timestamp vs seqno redux > > > >=20 > > > > I've recently became aware that much nonsense discussion is > > > happening > > > > around the timestamp vs seqno. People keep saying that > > > seqno method > > > > is a possible alternative to timestamp but at the same=20 > time they=20 > > > > mandate in the document the timestamp method. This is complete=20 > > > > nonsense. > > > >=20 > > > > I don't want the timestamp method to be mandatory. > > > >=20 > > > > Anybody else wants the timestamp method to be a=20 > mandatory method? > > > >=20 > > > > Anybody else wants the timestamp method to be an=20 > > alternative method? > > > >=20 > > > > Alex > > > > PS: mandatory excerpts: > > > > "This document _requires_ the use of Timestamp Option" > > > > "An implementation MUST support Timestamp option." > > > >=20 > > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > > > This email has been scanned by the MessageLabs Email > > > Security System. > > > > For more information please visit=20 > http://www.messagelabs.com/email > > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 11:20:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7X9-0001D7-4k; Tue, 11 Sep 2007 11:20:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV7X7-0001Cu-PQ for netlmm@ietf.org; Tue, 11 Sep 2007 11:20:10 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV7X5-0008AF-OB for netlmm@ietf.org; Tue, 11 Sep 2007 11:20:09 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8BFJxw06170; Tue, 11 Sep 2007 15:19:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] timestamp vs seqno redux Date: Tue, 11 Sep 2007 10:19:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116AB0030@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A26@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABfNwGAAE6an0ACRc75QAAnxKmAAAD5AsAAqJnwQAAFARhA= References: <319D54578EAC3147BA8CC78DAB5467A501399A12@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AB8@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116A57D1B@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399A26@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: 47f87af9e1d92eac54caf69b67f82b72 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, Please see one clarification inline. Regards, Ahmad =20 > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Ahmad, >=20 > I don't see why do you consider that sending the timestamp in=20 > the SeqNum is a new mechanism IMO, it's something that can=20 > already be done with any MIP implementation [Ahmad] Are you suggesting that the timestamp will be inserted in the already = defined SQN field of the P-BU/P-BA? I just wanted to understand this point to make sure that we are on the = same page. Thanks. >=20 > The difference between sending timestamp in SeqNum or sending=20 > it in TS option is that in the former case the LMA would not=20 > need to worry about sending the TS option back In other=20 > words, I see a difference between: > 1- Sending timestamp in SeqNum =3D> only MAGs need to be time = synched > 2- Sending timestamp in TS option =3D> all MAGs and LMAs=20 > should be time synched Choosing between the 2 options is=20 > probably deployment dependent In the first case (LMA is not=20 > synched with the MAGs) what is the added value of using the=20 > TS option instead of carrying the timestamp in SeqNum? >=20 > Ahmad> I agree with Sri, That has been discussed and agreed upon.=20 > Was it agreed to use time synchronization (thus #1 falls in=20 > the agreement) or to use the timestamp option (only #2 can be=20 > considered)? > Anyway, I understood from Sri call for inputs that he was=20 > pushing the TS option beyond what had been agreed, so I=20 > presume that there's (some) room for closing this issue properly >=20 > Regards >=20 > federico >=20 > PS: I'm discussing with Sri offline, so given that you have=20 > an opinion I'll add you in CC >=20 > -----Message d'origine----- > De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 :=20 > lundi 10 septembre 2007 20:40 =C0 : Ahmad Muhanna; DE JUAN=20 > HUARTE FEDERICO; Sri Gundavelli Cc : netlmm Objet : RE:=20 > [netlmm] timestamp vs seqno redux >=20 >=20 > Hi Federico, > It seems that I did not read the whole case No. 2. >=20 > You are proposing a new mechanism/field to use timestamp.=20 > I agree with Sri, That has been discussed and agreed upon.=20 >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Muhanna, Ahmad (RICH1:2H10) > > Sent: Monday, September 10, 2007 1:34 PM > > To: 'DE JUAN HUARTE FEDERICO'; 'Sri Gundavelli' > > Cc: 'netlmm' > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Federico, > >=20 > > I just would like to make one comment quickly here and we=20 > can go over=20 > > other issues later. > > Timestamp option still needs to be used in Case No. 2 as=20 > you specified=20 > > below. Otherwise, how the whole sequencing would work? Right? > >=20 > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: DE JUAN HUARTE FEDERICO > > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > > Sent: Monday, September 10, 2007 12:44 PM > > > To: Sri Gundavelli > > > Cc: netlmm > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Sri, > > >=20 > > > thanks for your answer > > > I've taken some time to process your answer and what is=20 > > written in the=20 > > > draft (v3) > > >=20 > > > >From your email answer: > > > Sri> ... Allowing LMA to return its own timestamp, > > > essentially establishes one node in that domain to dictate=20 > > some order,=20 > > > in the absence of NTP snchronization ... > > > Sri> ... We either depend on NTP to synchronize all the > > > clocks in the node or let LMA always returns its timestamp, ... > > >=20 > > > I understand now that there's a case that I had not taken into=20 > > > account: > > > 1- The MAGs may be syncronized by context transfer =3D>=20 > > SeqNum in BU > > > 2- The MAGs may be synchronized by a common time reference =3D> = > > > SeqNum (carrying a timestamp) in BU > > > 3- The MAGs may be not-synchronized at all =3D> timestamp=20 > > option Can=20 > > > you confirm that the timestamp option is only to cover case #3? > >=20 > > [Ahmad] > > Timestamp option is used in case 2 and case 3. > >=20 > > > By the way the draft is written (section 5.4), it's not=20 > > clear to me if=20 > > > you also expect the MAGs to use the timestamp option in case #2=20 > > > (connected to a common time reference). I think in case=20 > #2 the LMA=20 > > > should not interfere with the explicit mechanism used to=20 > > synchronize=20 > > > clocks (e.g. NTP) > > >=20 > > > In case #3, (MAGs not connected to a common time=20 > > reference), I still=20 > > > perceive that the draft expects the LMA to become a sort of Time=20 > > > Reference Master > > >=20 > > > In general, I can't see how the timestamp option can provide a=20 > > > deterministic behavior and therefore I don't think that the draft=20 > > > should RECOMMEND it, unless the following points are addressed: > > > - for the timestamp option to work, the rate of BUs=20 > > between a given=20 > > > MAG and a given LMA should not allow for time deviations=20 > > larger than=20 > > > the threshold to declare a timestamp as invalid > > > - A factor to take into account is RTDs (RoundTrip=20 > > Delays) between=20 > > > MAGs and LMA: if the pMAG-LMA RTD is larger than the=20 > > nMAG-LMA RTD then=20 > > > the pMAG "clock" will be delayed with respect to the one=20 > of the nMAG > > > - Unclear what the effects of congestion will be: if the link=20 > > > between the LMA and the pMAG is more congested than the=20 > > link between=20 > > > the LMA and the nMAG, the previous effect will be even worse > > > - Something that needs to be considered in this discussion is=20 > > > how/when resources will be released by the pMAG. If there's no=20 > > > communication between pMAG and nMAG, there will need to be=20 > > a timeout=20 > > > or a revocation message from the LMA. In any case, there's=20 > > a period of=20 > > > time between the nMAG sending the BU and the pMAG=20 > releasing its own=20 > > > binding. During this period of time the pMAG may send a=20 > BU, thereby=20 > > > creating a race condition. In the extreme case, both the=20 > > pMAG and the=20 > > > nMAG may send the BU with the same time (virtually) > > > - When connected to multiple LMAs (e.g. roaming), MAGs have to=20 > > > maintain multiple timers (one per LMA). Doable but=20 > complex Can you=20 > > > please tell me if the following concerns have been raised=20 > > before and=20 > > > if yes how are they addressed? > > >=20 > > > In my opinion, NETLMM should RECOMMEND the MAGs to be=20 > synchronized=20 > > > (case #1 or case #2) and not the timestamp option (as in=20 > > section 5.4)=20 > > > In these conditions, a non-synchronized MAG is an error=20 > case (thus=20 > > > infrequent): #1) context transfer didn't take place or #2) lost=20 > > > synchronization with the time reference. > > > In order to address such error case it is enough to let the MAG=20 > > > indicate it explicitly to the LMA, so that the LMA can > > > (exceptionally) ignore the sequencing. > > > I don't see much added value in a solution like #3 (LMA as Time=20 > > > Reference Master), but I'm not against describing it in=20 > the spec as=20 > > > long as it is not REQUIRED or RECOMENDED > > >=20 > > > A couple side reactions: > > > Sri> But, the base draft has to be complete. We should allow > > > deployments to happen just based on this spec. If we dont support=20 > > > Timestamp and if there is no CT, how will registrations=20 > > happen ? The=20 > > > LMA will always reject the first request for each MN. > > > MAGs need to be synchronized (CT or common time ref). The=20 > > first BU of=20 > > > all will need to carry a "Reset-Synch" flag Any MAG that is not=20 > > > synched (no CT or no connectivity to time > > > ref) SHOULD also assert the "Reset-Synch" flag > > >=20 > > > Sri> ...replay protection has a relation to time window.=20 > > > Timestamp provides the validity for the same message. Its=20 > the same=20 > > > thing here, just that the window is small. > > > We have very different opinions here, but as long as replay=20 > > protection=20 > > > is not an argument for the timestamp option, no need to discuss it > > >=20 > > > Regards > > >=20 > > > federico > > >=20 > > > -----Message d'origine----- > > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :=20 > > > vendredi 7 septembre 2007 19:02 =C0 : DE JUAN HUARTE FEDERICO Cc : = > > > 'netlmm' > > > Objet : RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Federico, > > > =20 > > > Please see inline .. > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: DE JUAN HUARTE FEDERICO > > > > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > > > Sent: Friday, September 07, 2007 2:04 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri, > > > >=20 > > > > I haven't had time to catch up yet with the new draft, so I > > > apologize > > > > if any of my comments below has already been addresed > > > >=20 > > > > Sri> ... what are we mandating? The ability for the LMA to > > > > generate a Timestamp and return the timestamp option ... > > > > I'm trying to understand the motivation for this mandate > > > >=20 > > > > I understand the need in the LMA to identify the sequence=20 > > of BUs in=20 > > > > order to avoid race conditions when more than one MAG can=20 > > send a BU=20 > > > > for the same user The minimum requirement from LMA point=20 > > of view is=20 > > > > that the ID carried in the BU represents a free-running > > > counter that > > > > increases monotonically It follows that the requirement for > > > the MAGs > > > > is to synchronize the values used in the BU-ID Let me=20 > stress that=20 > > > > these "minimum requirements" are only for=20 > synchronization between=20 > > > > MAGs, i.e. not including LMA > > > >=20 > > > > Timestamps is a valid solution for filling in the ID when > > > there's time > > > > synchronization (with sufficient accuracy) between MAGs Let > > > me stress > > > > that the precondition for using timestamps should only be=20 > > > > synchronization between MAGs, i.e. not including LMA By > > > including LMA > > > > in the equation, it seems that we're trying to correct > > > deviations in > > > > the time synchronization of MAGs via PMIP That is, the=20 > > LMA becomes=20 > > > > some kind of synch Master. Honestly, I don't think it=20 > is right to=20 > > > > extend PMIP scope in such way > > > >=20 > > >=20 > > > No, that is not true. We are not trying to sync clocks=20 > using PMIP.=20 > > > Allowing LMA to return its own timestamp, essentially=20 > > establishes one=20 > > > node in that domain to dictate some order, in the absence of NTP=20 > > > snchronization. In a network with multiple nodes, we need=20 > a global=20 > > > scale such as a timestamp. We either depend on NTP to=20 > > synchronize all=20 > > > the clocks in the node or let LMA always returns its=20 > > timestamp, so as=20 > > > for the MAG to use that timestamp (delta) in the subsequent=20 > > requests. > > > Otherwise, every MAG in the network may be sending different=20 > > > timestamps and the LMA would not know, which one to accept. > > >=20 > > >=20 > > > > Let me cite your answers to Alper (from another email): > > > > Sri> ... It is important to highlight the fact that we need > > > > this entire synchronization logic to avoid one scenario, > > > where the LMA > > > > ends up processing a PBU that was sent by pMAG and the=20 > > LMA received=20 > > > > that much later due to network out of order deliverly ... > > > > [FDJ] This problem statement seems wrong. Unordered > > > delivery because > > > > of nw congestion does not make any difference What=20 > matters is the=20 > > > > relationship between the ID sent by the pMAG and the one > > > sent by the > > > > nMAG The only requirement that we can make is that pMAG and > > > nMAG must > > > > synchronize this ID There's no way the LMA can't tell in > > > which order > > > > these 2 BUus were sent if the IDs are not-synchronized > > > >=20 > > >=20 > > > It does. The race condition would not be an issue, if LMA=20 > receives=20 > > > packets in the order in which they were generated by=20 > > different MAG's.=20 > > > The LMA may potentially delete a valid current binding,=20 > because it=20 > > > received a stale binding from the prev MAG. > > >=20 > > > If pMAG and nMAG can synchronize the id's, the whole=20 > issue is mute.=20 > > > That is the alternative approach to timestamp based=20 > scheme that the=20 > > > draft supports. MAG can certainly send the seq number of=20 > > the MN that=20 > > > it obtained as part of handoff using CT. No need for=20 > > timestamps there. > > >=20 > > >=20 > > > > Sri> ... If a deployment does not enable NTP kind of > > > > protocols and if the LMA receives a packet with PBU from a=20 > > > MAG with a=20 > > > > invalid timestamp, the LMA can return its own timestamp=20 > > and the MAG=20 > > > > can use the same in the requests to avoid this special race=20 > > > condition=20 > > > > ... > > > > [FDJ] If the deployment does not enable NTP, all PBUs=20 > will have a=20 > > > > wrong ID. Or do you expect the MAG to synch to the same=20 > > timebase as=20 > > > > the LMA when the LMA returns the timestamp option? > > > > Furthermore, I fail to understand the solution you propose:=20 > > > > how can the LMA declare that the ID (timestamp) is invalid? > > > > Use case: > > > > - pMAG send BU at 10 AM > > > > - nMAG sends BU at 11 AM > > > > - LMA receives BU from nMAG at 11:15 AM. Will it return=20 > > > timestamp=20 > > > > to nMAG, so that the BU can be resent? > > >=20 > > > The LMA returns its timestamp if it detects that the clocks=20 > > > are out of sync.=20 > > >=20 > > >=20 > > > > - LMA receives BU from pMAG at 11:30 AM. Will it retun=20 > > > timestamp to=20 > > > > pMAG, so that BU can be resent? Or maybe the proposal is=20 > > > that LMA will=20 > > > > decide that pMAG BU was sent earlier than nMAG BU and therefore=20 > > > > discard it. > > >=20 > > >=20 > > > Yes. The LMA will discard it. You should read the=20 > Timestamp section. > > >=20 > > >=20 > > > The latter=20 > > > > makes sense but it means that the LMA has to assume that=20 > > > pMAG and nMAG=20 > > > > are in synch. And then we're back to the minimum requirement > > > >=20 > > > > In summary, in my opinion: > > > > 1- The LMA MAY be able to generate timestamps (but=20 > > should not be=20 > > > > required to) > > > > 2- The LMA MAY know that the source used for the ID is a=20 > > > timestamp=20 > > > > (but should not be required to) > > > > 3- If the LMA is not timestamp aware, the MAG MAY use=20 > > timestamps=20 > > > > (but should not be required to) > > > > 4- If the LMA is timestamp aware, the MAG MAY use=20 > > > timestamps (but=20 > > > > should not be required to) If any of the 4 statements would=20 > > > reduce the=20 > > > > usability of PMIP in any way, I would appreciate to have a=20 > > > more clear=20 > > > > problem statement > > >=20 > > > > Thus: Implementation MUST support Timestamp option: No > > >=20 > > > Ok. > > >=20 > > >=20 > > > > And I would even push it further: if the previous 4=20 > > > statements can be=20 > > > > agreed to, then the logical conclusion is that timestamps=20 > > > can be left=20 > > > > out of the specification (at most an informative note would do) > > > >=20 > > > > A couple of collateral comments: > > > > - I understand that CT (Context Transfer) is already=20 > > > acknowledged=20 > > > > as a valid alternative solution > > > > For some reason, CT is left out of scope. Fine for me,=20 > > > but I don't=20 > > > > think it's a fair consequence to mandate timestamps > > > > The fact that "context transfer is out of scope" doesn't=20 > > > equate to=20 > > > > "there is no context transfer" > > >=20 > > > But, the base draft has to be complete. We should allow=20 > > > deployments to happen just based on this spec. If we dont=20 > > > support Timestamp and if there is no CT, how will=20 > > > registrations happen ? The LMA will always reject the first=20 > > > request for each MN.=20 > > >=20 > > > > Is it the working assumption that a solution without CT=20 > > > is simpler=20 > > > > than a solution with CT? This would be a wrong assumption > > > > If we have to choose between specifying timestamps or=20 > > specifying=20 > > > > CT, then I prefer the latter. It's clear that it will=20 > > require more=20 > > > > work but it will be more useful > > > >=20 > > > > - If a nMAG sends a BU for a given user without=20 > > synchronization=20 > > > > with pMAG it may be useful to have the option to indicate=20 > > it to the=20 > > > > LMA > > > > In other words, I propose a flag "OOS ID" (Out of Synch > > > > ID) sent by the MAG, so that the LMA can reset the sequencing=20 > > > > algorithm for a given MN > > > >=20 > > > > - I have read in other emails that timestamps are=20 > > > already a proven=20 > > > > concept in MIP4 > > > > I fail to understand how this argument makes a=20 > > difference, since=20 > > > > the original problem statement is that the MIP client (the one=20 > > > > generating BUs) in case of PMIP (i.e. the MAG) may change=20 > > > during the=20 > > > > lifetime of a MIP session. The problem addressed in MIP4 is a=20 > > > > different one (replay protection). > > > > It's off-topic, but I find this area of MIP4 overspecified when=20 > > > > compared to approaches in other protocols (e.g. IEEE 802.16). A=20 > > > > monotonically increasing counter is sufficient for replay=20 > > protection > > > >=20 > > >=20 > > > Agree, the purpose is different. But, replay protection has a=20 > > > relation to time window. Timestamp provides the validity for=20 > > > the same message. Its the same thing here, just that the=20 > > > window is small. > > >=20 > > > Sri > > >=20 > > >=20 > > >=20 > > > > Regards > > > >=20 > > > > federico > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > -----Message d'origine----- > > > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9=20 > : jeudi 6=20 > > > > septembre 2007 21:58 =C0 : 'Alexandru Petrescu'; 'netlmm' > > > > Objet : RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > >=20 > > > > Please comment on this issue raised by Alex about mandating=20 > > > Timestamp=20 > > > > option. Alex is right, when we discussed this issue, the=20 > > conclusion=20 > > > > was to use Timestamp based approach, but we did not=20 > > discuss if that=20 > > > > was supposed to be mandatory to implement. > > > >=20 > > > > Now, w.r.t the issue, what are we mandating ? > > > >=20 > > > > - The ability for the LMA to generate a Timestamp and return > > > > the timestamp option. The timestamp in relation to a specific > > > > reference point. IMO, this is one system call on most OS's and > > > > a delta addition if the timestamp generated is=20 > elapsed time past > > > > some other reference point. We are talking about 5 to 8 lines > > > > of code. I will be happy to publish this code for all standard > > > > OS's. > > > >=20 > > > > - We are NOT mandating the nodes in the domain to sync up to > > > > a clock source.=20 > > > >=20 > > > >=20 > > > > How does it impact, if some deployment wants to use Seq Number=20 > > > > approach ? > > > >=20 > > > > - No impact. The option need to be supported. Implies those 10 > > > > lines of extra code. > > > >=20 > > > >=20 > > > > Why this should be mandatory ? > > > >=20 > > > > Base draft does not support Context Transfers. Given that=20 > > the draft=20 > > > > will be incomplete, if we dont mandate the support. By=20 > > > mandating the=20 > > > > support, the LMA can always return its timestamp and the=20 > > > MAG can use=20 > > > > that timestamp and register. > > > > This need to be done just once whenever the LMA/MAG clocks=20 > > > are out of=20 > > > > sync and just for one registration. One extra round trip=20 > > > for the 1st=20 > > > > registration between LMA/MAG pair. > > > >=20 > > > > But, if the LMA falls back to the seq number based=20 > > approach and if=20 > > > > there are no context transfers, there is always an extra=20 > > round trip=20 > > > > for each MN registration (at handoff). > > > >=20 > > > > So, I prefer the mandatory approach, its more efficient.=20 > > > But, as I had=20 > > > > it in the initial suggested text, I'm ok not mandating this and=20 > > > > defining an error code "Timestamp option not supported". > > > >=20 > > > >=20 > > > > Please comment. I want to close this issue.=20 > > > >=20 > > > >=20 > > > > Implementation MUST support Timestamp option: [Yes/No] > > > >=20 > > > >=20 > > > > Thanks > > > > Sri > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > > > Sent: Thursday, September 06, 2007 2:01 AM > > > > > To: netlmm > > > > > Subject: [netlmm] timestamp vs seqno redux > > > > >=20 > > > > > I've recently became aware that much nonsense discussion is > > > > happening > > > > > around the timestamp vs seqno. People keep saying that > > > > seqno method > > > > > is a possible alternative to timestamp but at the same=20 > > time they=20 > > > > > mandate in the document the timestamp method. This=20 > is complete=20 > > > > > nonsense. > > > > >=20 > > > > > I don't want the timestamp method to be mandatory. > > > > >=20 > > > > > Anybody else wants the timestamp method to be a=20 > > mandatory method? > > > > >=20 > > > > > Anybody else wants the timestamp method to be an=20 > > > alternative method? > > > > >=20 > > > > > Alex > > > > > PS: mandatory excerpts: > > > > > "This document _requires_ the use of Timestamp Option" > > > > > "An implementation MUST support Timestamp option." > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > > > > This email has been scanned by the MessageLabs Email > > > > Security System. > > > > > For more information please visit=20 > > http://www.messagelabs.com/email > > > > >=20 > > > >=20 > > >=20 > >=20 > ______________________________________________________________________ > > > > >=20 > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 14:02:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVA3u-0007qZ-3r; Tue, 11 Sep 2007 14:02:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVA3s-0007qT-Me for netlmm@ietf.org; Tue, 11 Sep 2007 14:02:08 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVA3r-0002VT-FY for netlmm@ietf.org; Tue, 11 Sep 2007 14:02:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id E147C980A7 for ; Tue, 11 Sep 2007 14:02:03 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04979-02 for ; Tue, 11 Sep 2007 14:02:02 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 11 Sep 2007 14:02:02 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 14:02:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Significance of MN-Identifier Date: Tue, 11 Sep 2007 14:01:25 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA565@exchtewks2.starentnetworks.com> In-Reply-To: <0MKpCa-1IV1Ng2eID-0007Js@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Significance of MN-Identifier Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaA= From: "Chowdhury, Kuntal" To: "Alper Yegin" , "Sri Gundavelli" X-OriginalArrivalTime: 11 Sep 2007 18:02:43.0757 (UTC) FILETIME=[F39D65D0:01C7F49D] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, I don't know what the issue is for MN-ID in the PMIP6 signaling messages. Could you explain why we are having this debate? MN-ID is the unique identifier to identify the session state in the LMA. There are several good reasons to mandate the presence of MN-ID in the PBU/PBA. For example, it helps to identify the session state in the LMA for PMIP6 - MIP6 transition scenarios, when the LMA is collocated with a MIP6 HA. Note that during IKEv2 exchange for MIP6, the IDi field (that carries the same MN-ID) in the IKE packets help identify the ongoing (PMIP6) session related to the MN.=20 Hope this helps. -Kuntal > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Tuesday, September 11, 2007 3:46 AM > To: 'Sri Gundavelli' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Significance of MN-Identifier >=20 > Sri, >=20 > > At handoff, nMAG may not know the HNP of the mobile node. How does it > > communicate with the LMA about the MN, if MN-Id is not used ? That's > > is essential, its required in BCE and also in signaling messages. >=20 >=20 > So it is just for HNP assignment as I was saying: >=20 > >>> Is it for the sake of identifying the MN during dynamic HNP > >>> assignment in-band with PMIP? >=20 >=20 > HNP can be assigned during network access authentication. I can't imagine > when this is not possible or desirable. >=20 > That's why mandating presence of MN-id that identifies the MN is not > necessary, imo. >=20 > If people can show a reason why we must also support HNP assignment in- > band > with PMIP, we can say: >=20 > When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that > carries the MN-id MUST be included in the PBU. >=20 >=20 >=20 > Alper >=20 >=20 > > > > Sri > > > > > > > Alper > > > > > > > > > > > > > > > > > >> > > >> Sri > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > >>> Sent: Monday, September 10, 2007 4:27 AM > > >>> To: netlmm@ietf.org > > >>> Subject: [netlmm] Significance of MN-Identifier > > >>> > > >>> What's the significance of MN-Identifier as carried in PBU? > > >>> > > >>> Is it for the sake of identifying the MN during dynamic HNP > assignment > > >>> in-band with PMIP? > > >>> > > >>> If so, given that the HNP may also be assigned during network access > > >>> authentication (out-of band with PMIP, as commonly done in > integrated > > >>> bootstrapping scenarios), we shall not mandate that the MN- > identifier > > >>> identifies the real MN. > > >>> > > >>> Another way of using of MN-identifier is to identify the > > >>> "proxy MN" (MAG) > > >>> with RFC 4285. > > >>> > > >>> Alper > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> netlmm mailing list > > >>> netlmm@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 17:02:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCsB-00056Q-3j; Tue, 11 Sep 2007 17:02:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCsA-00056L-51 for netlmm@ietf.org; Tue, 11 Sep 2007 17:02:14 -0400 Received: from mout.perfora.net ([74.208.4.197]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVCs9-0001Li-GZ for netlmm@ietf.org; Tue, 11 Sep 2007 17:02:14 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IVCs60pK2-0007Uj; Tue, 11 Sep 2007 17:02:12 -0400 From: "Alper Yegin" To: Subject: RE: [netlmm] Question on security model Date: Wed, 12 Sep 2007 00:01:56 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acf0gtDWPSwhZKFsQKG6YgDS9HfwMwAMzqwQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <200709111648.19896.julien.IETF@laposte.net> Message-Id: <0MKpCa-1IVCs60pK2-0007Uj@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/hqLeLoDtKSLCZPCUYZZfFTLMQI2gmKXuhS/5 z9BsTudvTZhdjs2fRpTpOBthFOdFa39hQVdvp43LJGnkVDQaCk 2T33PT5SvEhifeGw2rOTQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org There are two types of components to security space for PMIP (so far)... Security mechanism: IPsec, Auth Option, etc... Security association: MAG-LMA, per-MN MAG-LMA All combinations are possible between the two components. While recommending support for one combination (IPsec with MAG-LMA SA) = is necessary for interop, we shall not prevent use of other combinations in = the base spec. =20 I'm fine with the current recommendation, as long as we weed out text = that unnecessarily or accidentally bars other combinations. This is better = than having to enter a beauty contest and try to pick a winner. Alper=20 > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net] > Sent: Tuesday, September 11, 2007 5:48 PM > To: netlmm@ietf.org > Cc: 'DE JUAN HUARTE FEDERICO' > Subject: Re: [netlmm] Question on security model >=20 > On Tuesday 11 September 2007, Sri Gundavelli wrote: > > Hi Federico, > > > > I dont want to reopen this thread or enter any discussions. But, let > > me quickly make these points. > > > > > > 1. The security model, Configuring a MAG with all the MN's SA's does > > not offer any greater security than the other security model. Even = in > > the Per-Node security model, there could be multiple SA's between = the > > LMA and MAG, and different SA's can be used for different flows. > > > > 2. If a MAG is compromised, so are all the MN SA's. The damage is = the > > =A0 =A0same. If we argue that the MAG will not be allowed to create = a BCE > > =A0 =A0for a MN, that it does not have SA for, the same = authorization can > > =A0 =A0be achieved in the other model, by requiring the LMA to = authorize > > the MAG before it creates BCE for a given MN. > > > > There is no advantage using Per-MN security model. Its just a false > > sense of security, IMHO. >=20 > Trying to be more precise here. >=20 > The "Per-MN security model" reffered to is actually one in which the a > LMA and a given MAG have a different security association for each MN > attached to that MAG. >=20 > I think it is more precise to denote this model as "Per-MN LMA-MAG > Security Association" model. >=20 > In this model, even though there's one security association per MN, = the > security association is still established between the _MAG_ and LMA. > Thus, if the _MAG_ is compromised, the per-MN LMA-MAG SA cannot = prevent > the MAG to issue undue signalling on behalf of a MN attached to it > since it has the corresponding per-MN LMA-MAG security association. On > the other hand, it would prevent a compromised MAG to issue undue > signalling on behalf of a MN which is not attached to it _if_ it has = no > per-MN LMA-MAG SA for that MN. >=20 > The draft currently specifies a "Per-MAG LMA-MAG Security Association" > model with no mechanisms in place to prevent a compromized MAG to = issue > undue signalling for any MN (both attached and not attached to it). = The > draft does however call in it security considerations section for such > a mechanism to be present, but as part of another, unspecified, > protocol: >=20 > To eliminate the threats related to a compromised mobile access > gateway, this specification recommends that the local mobility = anchor > before accepting a Proxy Binding Update message for a given mobile > node, should ensure the mobile node is definitively attached to the > mobile access gateway that sent the binding registration request. >=20 > Thus, the "Per-MN LMA-MAG Security Association" model can be more = secure > than the "per-MAG LMA-MAG Security Association" against MAG > compromission only if is guaranteed that establishment of the "Per-MN > LMA-MAG Security Association" cannot happen with a MAG to which the MN > is not attached. That might be ensured by tying this SA establishment > to network access control, but this would be, as for the "Per-MAG > LMA-MAG Security Association", a mechanism implemented as part of > another, unspecified, protocol. >=20 > In conclusion, without another mechanism realizing what's being called > for in the security considerations, both security models are IMHO > equivalent. >=20 > --julien >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 17:08:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCxr-0002gF-8v; Tue, 11 Sep 2007 17:08:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCxp-0002ct-Hc for netlmm@ietf.org; Tue, 11 Sep 2007 17:08:05 -0400 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVCxo-0001S2-T6 for netlmm@ietf.org; Tue, 11 Sep 2007 17:08:05 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IVCxf06NF-0007OU; Tue, 11 Sep 2007 17:08:04 -0400 From: "Alper Yegin" To: "'Chowdhury, Kuntal'" , "'Sri Gundavelli'" Subject: RE: [netlmm] Significance of MN-Identifier Date: Wed, 12 Sep 2007 00:07:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA565$0001@exchtewks2.starentnetworks.com> Message-Id: <0MKpCa-1IVCxf06NF-0007OU@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+ZhvYh+JcSPqcxQteM89ikUfqPgsIpcKqUMvr Sib+K2tXILG1Q+usHO96nq9TiW41suGnu+qFqwoUiWHYl1Z5pV EPUqhDp5JNZZAO7nQ5qfg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kuntal, > I don't know what the issue is for MN-ID in the PMIP6 signaling > messages. Could you explain why we are having this debate? Because, the current text is locking all PMIP6 deployments to one security model and not leaving any room for using anything else. And it is doing so without a good reason (unintentionally, I believe). > MN-ID is the unique identifier to identify the session state in the LMA. It is necessary only of the MN does not know its HNP. As soon as it knows the HNP (e.g., when HNP is assigned during network access authentication), we can rely on HNP to identify the session state. > There are several good reasons to mandate the presence of MN-ID in the > PBU/PBA. For example, it helps to identify the session state in the LMA > for PMIP6 - MIP6 transition scenarios, when the LMA is collocated with a > MIP6 HA. Can you elaborate on this scenario? You may have something here, but I need to understand. Alper > Note that during IKEv2 exchange for MIP6, the IDi field (that > carries the same MN-ID) in the IKE packets help identify the ongoing > (PMIP6) session related to the MN. > > Hope this helps. > > -Kuntal > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Tuesday, September 11, 2007 3:46 AM > > To: 'Sri Gundavelli' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > Sri, > > > > > At handoff, nMAG may not know the HNP of the mobile node. How does > it > > > communicate with the LMA about the MN, if MN-Id is not used ? That's > > > is essential, its required in BCE and also in signaling messages. > > > > > > So it is just for HNP assignment as I was saying: > > > > >>> Is it for the sake of identifying the MN during dynamic HNP > > >>> assignment in-band with PMIP? > > > > > > HNP can be assigned during network access authentication. I can't > imagine > > when this is not possible or desirable. > > > > That's why mandating presence of MN-id that identifies the MN is not > > necessary, imo. > > > > If people can show a reason why we must also support HNP assignment > in- > > band > > with PMIP, we can say: > > > > When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that > > carries the MN-id MUST be included in the PBU. > > > > > > > > Alper > > > > > > > > > > Sri > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > >> > > > >> Sri > > > >> > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > >>> To: netlmm@ietf.org > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > >>> > > > >>> What's the significance of MN-Identifier as carried in PBU? > > > >>> > > > >>> Is it for the sake of identifying the MN during dynamic HNP > > assignment > > > >>> in-band with PMIP? > > > >>> > > > >>> If so, given that the HNP may also be assigned during network > access > > > >>> authentication (out-of band with PMIP, as commonly done in > > integrated > > > >>> bootstrapping scenarios), we shall not mandate that the MN- > > identifier > > > >>> identifies the real MN. > > > >>> > > > >>> Another way of using of MN-identifier is to identify the > > > >>> "proxy MN" (MAG) > > > >>> with RFC 4285. > > > >>> > > > >>> Alper > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> netlmm mailing list > > > >>> netlmm@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. > Any review, retransmission, dissemination or other use of, or taking of > any action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not > the intended recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this message > and any attachments without reading or disclosing their contents. Thank > you." _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 11 18:17:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVE2k-0005DD-4u; Tue, 11 Sep 2007 18:17:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVE2b-0004zq-60 for netlmm@ietf.org; Tue, 11 Sep 2007 18:17:05 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVE2Z-0002wX-UD for netlmm@ietf.org; Tue, 11 Sep 2007 18:17:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 0E38E980B3 for ; Tue, 11 Sep 2007 18:17:00 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09954-06 for ; Tue, 11 Sep 2007 18:16:59 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 11 Sep 2007 18:16:59 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 18:17:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Significance of MN-Identifier Date: Tue, 11 Sep 2007 18:16:22 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA56C@exchtewks2.starentnetworks.com> In-Reply-To: <0MKpCa-1IVCxf06NF-0007OU@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Significance of MN-Identifier Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAACYsLQ From: "Chowdhury, Kuntal" To: "Alper Yegin" , "Sri Gundavelli" X-OriginalArrivalTime: 11 Sep 2007 22:17:40.0835 (UTC) FILETIME=[91624330:01C7F4C1] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, My comments inline... > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Tuesday, September 11, 2007 4:08 PM > To: Chowdhury, Kuntal; 'Sri Gundavelli' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Significance of MN-Identifier >=20 > Hi Kuntal, >=20 > > I don't know what the issue is for MN-ID in the PMIP6 signaling > > messages. Could you explain why we are having this debate? >=20 > Because, the current text is locking all PMIP6 deployments to one security > model and not leaving any room for using anything else. And it is doing so > without a good reason (unintentionally, I believe). >=20 [KC>] I believe, irrespective of the security model, we need the MN-ID in the PBU/PBA. > > MN-ID is the unique identifier to identify the session state in the LMA. >=20 > It is necessary only of the MN does not know its HNP. As soon as it knows > the HNP (e.g., when HNP is assigned during network access authentication), > we can rely on HNP to identify the session state. >=20 >=20 [KC>] If you are talking about re-registrations (binding refresh) the MN-ID can be omitted. However, I don't see the reason for this exception. The code and the lookup will be simpler if the MN-ID is always included.=20 > > There are several good reasons to mandate the presence of MN-ID in the > > PBU/PBA. For example, it helps to identify the session state in the LMA > > for PMIP6 - MIP6 transition scenarios, when the LMA is collocated with a > > MIP6 HA. >=20 > Can you elaborate on this scenario? You may have something here, but I > need > to understand. >=20 [KC>] Sure, please look in the MIP6-PMIP6 transitions I-D: http://www.ietf.org/internet-drafts/draft-giaretta-netlmm-mip-interactio ns-01.txt > Alper >=20 >=20 > > Note that during IKEv2 exchange for MIP6, the IDi field (that > > carries the same MN-ID) in the IKE packets help identify the ongoing > > (PMIP6) session related to the MN. > > > > Hope this helps. > > > > -Kuntal > > > > > > > -----Original Message----- > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > To: 'Sri Gundavelli' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > Sri, > > > > > > > At handoff, nMAG may not know the HNP of the mobile node. How does > > it > > > > communicate with the LMA about the MN, if MN-Id is not used ? That's > > > > is essential, its required in BCE and also in signaling messages. > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > >>> Is it for the sake of identifying the MN during dynamic HNP > > > >>> assignment in-band with PMIP? > > > > > > > > > HNP can be assigned during network access authentication. I can't > > imagine > > > when this is not possible or desirable. > > > > > > That's why mandating presence of MN-id that identifies the MN is not > > > necessary, imo. > > > > > > If people can show a reason why we must also support HNP assignment > > in- > > > band > > > with PMIP, we can say: > > > > > > When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > Alper > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > >> Sri > > > > >> > > > > >> > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > >>> To: netlmm@ietf.org > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > >>> > > > > >>> What's the significance of MN-Identifier as carried in PBU? > > > > >>> > > > > >>> Is it for the sake of identifying the MN during dynamic HNP > > > assignment > > > > >>> in-band with PMIP? > > > > >>> > > > > >>> If so, given that the HNP may also be assigned during network > > access > > > > >>> authentication (out-of band with PMIP, as commonly done in > > > integrated > > > > >>> bootstrapping scenarios), we shall not mandate that the MN- > > > identifier > > > > >>> identifies the real MN. > > > > >>> > > > > >>> Another way of using of MN-identifier is to identify the > > > > >>> "proxy MN" (MAG) > > > > >>> with RFC 4285. > > > > >>> > > > > >>> Alper > > > > >>> > > > > >>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> netlmm mailing list > > > > >>> netlmm@ietf.org > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > "This email message and any attachments are confidential information of > > Starent Networks, Corp. The information transmitted may not be used to > > create or change any contractual obligations of Starent Networks, Corp. > > Any review, retransmission, dissemination or other use of, or taking of > > any action in reliance upon this e-mail and its attachments by persons > or > > entities other than the intended recipient is prohibited. If you are not > > the intended recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of this message > > and any attachments without reading or disclosing their contents. Thank > > you." _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 00:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVJYK-0006LT-CH; Wed, 12 Sep 2007 00:10:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVJYJ-0006LO-8Y for netlmm@ietf.org; Wed, 12 Sep 2007 00:10:11 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVJYI-0000WO-Sh for netlmm@ietf.org; Wed, 12 Sep 2007 00:10:11 -0400 X-IronPort-AV: E=Sophos;i="4.20,242,1186383600"; d="scan'208";a="216460137" Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2007 21:10:10 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l8C4AANS005048; Tue, 11 Sep 2007 21:10:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8C4AAat007238; Wed, 12 Sep 2007 04:10:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 21:10:10 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 21:10:09 -0700 From: "Sri Gundavelli" To: "'Genadi Velev'" References: <46DFB7A4.9010209@nomadiclab.com> <006101c7f35e$61ef5a20$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A993@lan-ex-02.panasonic.de> <008f01c7f3c0$960663a0$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA1C@lan-ex-02.panasonic.de> Subject: RE: [netlmm] RE: Remaining Open Issues Date: Tue, 11 Sep 2007 21:10:09 -0700 Message-ID: <005201c7f4f2$cf2240e0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48AA1C@lan-ex-02.panasonic.de> Thread-Index: AcfwXnExe6oZOl5aQOCii005cqOnggC/aV5AABPjXQAABPRFcAAjezRAACjiJpA= X-OriginalArrivalTime: 12 Sep 2007 04:10:09.0808 (UTC) FILETIME=[CF277100:01C7F4F2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1259; t=1189570210; x=1190434210; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20RE=3A=20Remaining=20Open=20Issues |Sender:=20; bh=I6bRM4+zpcaEg+cZvc0lFKdTsSQD/0kQliSFofD4acc=; b=zfsxH1C/PU9kKf/6o3llwH1+R/sKc71NUuhGpzJtPWU9IssuGiAwruk08qk7n6I0qTqBiF3v ZiBqsujpqXkb9wrvQHXGvgglYvh1oVCw3maPAjmuW8T8a3piIyrh8X6r; Authentication-Results: sj-dkim-5; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'NetLMM Mailing List' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Genadi, > > > > If you see 3775, the message and options are clearly mentioned > > seperately. In the message format sections, we are only defining the > > message and the option formats. In what combination they are > > used, that > > is based on the signaling logic. > > I understand that RFC3775 gives a complete description of the mobiltiy > header. However since a few mobiltiy options from RFC3775 are used in > PMIP, IMO it can be beneficial to list the PMIP-relevant mobiltiy > options somewhere in section 8 (like a summary of what is specified > previously in section 5.3. and 6.9.). > Thinking a bit further, I agree, we can list the options that can go with it. Initial thought was that, we are only talking about the container (BU/BA) format changes in that section. The options that go in to that message and the complete message formats are in signaling considerations. I looked at how HMIP and NEMO specs, both extended the MIP6 BU/BA formats. But, since PMIP is bit different and we cant allow all the base spec options in this message, we can probably list them there (atleast for the current spec). IPv4 support doc can do the same as well. Thanks, we will make this change. Regards Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 00:34:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVJvg-0002PW-UZ; Wed, 12 Sep 2007 00:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVJvf-0002PR-Kc for netlmm@ietf.org; Wed, 12 Sep 2007 00:34:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVJve-0005x8-Cb for netlmm@ietf.org; Wed, 12 Sep 2007 00:34:19 -0400 X-IronPort-AV: E=Sophos;i="4.20,242,1186383600"; d="scan'208";a="216468899" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2007 21:34:17 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8C4YHKN025762; Tue, 11 Sep 2007 21:34:17 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8C4YHoJ023172; Wed, 12 Sep 2007 04:34:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 21:34:17 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 21:34:17 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" , References: <46E6A353.6020302@gmail.com> Subject: RE: [netlmm] Re: timestamps description (was: I-DAction:draft-ietf-netlmm-proxymip6-04.txt) Date: Tue, 11 Sep 2007 21:34:16 -0700 Message-ID: <005301c7f4f6$2da24590$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46E6A353.6020302@gmail.com> Thread-Index: Acf0fm1K+gRZvTq6REC41HFkM0ZWQgAdG6Qw X-OriginalArrivalTime: 12 Sep 2007 04:34:17.0350 (UTC) FILETIME=[2DF4D260:01C7F4F6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3005; t=1189571657; x=1190435657; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Re=3A=20timestamps=20description=20(was=3A =20I-DAction=3Adraft-ietf-netlmm-proxymip6-04.txt) |Sender:=20; bh=h/0JlEF4rYXeoof0LiEtf3qzkpps2we9IokmmhxzZxE=; b=AArXAEgw7jUGlqq19+Qx4ZsFCLIA01KEHH4/+kb8wlqgrXLY26cuK86OKeheoNKq3RwMCm1/ 074BpXFhR5WjDq/zr5E5DWXCoOhPJLo9y4yfPs8sHBXlfH8TsJwGMjxnDDbnHGt4LuYyteGfVU KmNbwo59iQLOldWYYyTk/qjo8=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, September 11, 2007 7:17 AM > To: netlmm@ietf.org > Subject: [netlmm] Re: timestamps description (was: > I-DAction:draft-ietf-netlmm-proxymip6-04.txt) > > Sri, thank you for the new version of the draft. > > Apparently it's insisted that PMIPv6 should rely on > timestamps and time > synchronization. I oppose this, and I prefer the draft to not > RECOMMEND, neither SHOULD, nor MAY relying on time > synchronization nor > timestamps. But relying on sequence numbers, with a method > I've already > posted. > > When this gets agreed in the WG I agree. > I know, you dont agree with this. Lets see how the thread closes, based on that I will reflect the consensus. > Until then, I have some nits about how time use is described > in the new > draft-04. > > > For solving this problem, this specification RECOMMENDS > the use of > > Timestamp option [Section 8.4]. The basic principle > behind the use > > of timestamps in binding registration messages is that the node > > generating the message inserts the current time-of-day, > and the node > > receiving the message checks that this timestamp is > greater than all > > previously accepted timestamps. > > (It's section 8.5 actually.) > Ok. Thanks > > Timestamp > > > > A 64-bit unsigned integer field containing a > timestamp. The value > > indicates the number of seconds since January 1, > 1970, 00:00 UTC, > > by using a fixed point format. In this format, the > integer number > > of seconds is contained in the first 48 bits of the > field, and the > > remaining 16 bits indicate the number of 1/64K fractions of a > > second. > > I think it should better say 1/65536 fractions of a second, and not > 1/64K fractions. Let me say why. 64k means 65535 when > talking bits and > bytes. If we talk anything else then 64k means 64000 > (meters, seconds, > Hertz, Joules, etc.) > > I think we should also say in the draft that the timestamp > contains the > number of seconds measured at GMT (or some other place of > your choice) > since Jan 1st, 1970, 00h00 UTC. Let me say why. If we don't > say where > this timestamp was measured then there are different > timezones on Earth, > and a MAG in eg New Delhi will have a different timestamp > than a LMA in > Hyderabad, even if they represent the same moment. > Ok. I used the description from 3971. But, this is a very good comment. This is always relative to UTC. The reference point for the delay, or the measuring point, have to at UTC. But, easily implementations can blunder. Please suggest some text. I'd love to say at Hyderabad, or if it makes you feel better, we can say its measured at Bucharest or Paris. We can probably leave GMT there. :) Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 02:14:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVLUR-0000kW-Vb; Wed, 12 Sep 2007 02:14:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVLUP-0000kR-RJ for netlmm@ietf.org; Wed, 12 Sep 2007 02:14:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVLUO-0002Fz-KU for netlmm@ietf.org; Wed, 12 Sep 2007 02:14:17 -0400 X-IronPort-AV: E=Sophos;i="4.20,242,1186383600"; d="scan'208";a="17531104" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 11 Sep 2007 23:14:15 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8C6EGQ8009431; Tue, 11 Sep 2007 23:14:16 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8C6EFat027008; Wed, 12 Sep 2007 06:14:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 23:14:15 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 23:14:10 -0700 From: "Sri Gundavelli" To: "'Kilian Weniger'" References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> Subject: RE: [netlmm] timestamp vs seqno redux Date: Tue, 11 Sep 2007 23:14:09 -0700 Message-ID: <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5A= In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 12 Sep 2007 06:14:15.0074 (UTC) FILETIME=[24E0E020:01C7F504] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9684; t=1189577656; x=1190441656; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20timestamp=20vs=20seqno=20redux |Sender:=20; bh=H+cTkrDRGiFegIx+MyzLMDiuypV0JCPDvSxBNWCqVBA=; b=XPSVoAmeQmIe588Pewz34VJRk8nEnpKTsRDoZI0WIZpPCI5NJVr/sityu0PHV/K9a5vUnSTU pjtLyxmXlRjaNTnIBR00wD5Wsz6zRtiuHwawamxJOoRfMkBFeSu72cj/; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.7 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian/Federico, > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: Tuesday, September 11, 2007 6:33 AM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux > > Hi Sri, > > my point is that NOT mandating synchronization to an external clock > source for the timestamp option implies that sending PBU msgs with > timestamp option is allowed even when MAGs are not (yet) synchronized. > I.e., it would be allowed that a deployment uses only the returned > timestamps in PBA msgs to synchronize the MAG clocks. I think > the draft > should not allow this for the following reasons: > The stated assumption for the timestamp based approach to work, is the requirement for the MAG's to have synchronized clocks. That is a requirement. Now, if a given MAG sends a PBU with an incorrect timestamp, its an error and as you and Federico pointed out, there are cases where the LMA will not be able to determine the sending order of the received packets. This is an error condition, as the requirement is not met. Now, should the draft state that the time synchronization is a requirement and additionally mandate a method of time synchronization, say by NTP ? But, the later has a system wide impact and additionally, a given architecture where this protocol is applied, can achieve the time synchronization through other non NTP means. IMO, we may not be able dictate that. Also, we want implementations to support the timestamp based scheme by default. Now, mandating the NTP usage will create some restrictions for some deployments. So, that is the reasoning behind not mandating the method of time synchronization. W.r.t this below scenario, the reason for LMA to return its timestamp, solves two purposes. 1.) Diagnostics (especially useful when the LMA and MAG are in different admin domains) 2.) The MAG can detect that its clock is not in sync and take the necessary actions. I guess, Frederico has an issue with the second part. But, if you look at the recommendation from the draft on handling this error case, MAG signaling considerations, "If the received Proxy Binding Acknowledgement message has the Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), the mobile access gateway SHOULD try to register again only after it synchronized its clock with the local mobility anchor's system clock or to a common time source that is used by all mobility entities in that domain for their clock synchronization." So, we are not really using the LMA as the time source. Now, with the given assumptions, do you see an issue if we dont say NTP is a MUST, but we say clock synch is a requirement, how they do it, draft does not say. If this requirement is not met, its an incorrect usage of the protocol and the PBU ordering will fail in that special rare reordering scenario (IMO, its not a practical issue). The second question to this discussion, is Alex's point of not mandating Timestamp option as a MUST implement. For this, as I stated before, this is few lines of code for supporting this option and if seq number scheme is in use, this need not be used at all. We need to mandate this as there is no CT in the base spec. But, this is not a big issue either way. If others agree, I'm fine not mandating this. But, I really believe, implementations can support this option, at the least cost. One last comment on the trust on LMA's clock for the sanity check, is because its an anchor point and its typically well managed, compared to MAG's, where they are scattered out. So, its reasonable to expect the clock on the LMA to be in sync, else all registrations will fail and will generate the traps. So, let me know your comments on how we can move forward. Sri > 1. If a MAG's clock is out of sync (i.e., not yet synced by > receiving a > PBA with timestamp) AND PBUs sent by this MAG are delayed, the out of > sync situation may not be detectable by the LMA and old PBUs may be > accepted by the LMA. > > Consider the following example: MN attaches to MAG1 and shortly > thereafter hands over to MAG2. MAG2's clock is in sync with > LMA's clock, > but MAG1's clock is out of sync and is ahead of LMA's clock by 5 > seconds. MAG1-LMA link is highly congested. When MN attaches to MAG1, > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before the MN hands > over to MAG2. The PBU1 msg is delayed by 5 seconds due to the > congestion > and hence arrives at LMA 2 seconds after handover. Despite of > the delay, > PBU1 has a valid timestamp from LMA's point of view due to the wrong > clock of MAG1. MAG2 sends a PBU2 msg 1 second after handover. PBU2 is > not significantly delayed and arrives at LMA ~1 seconds after handover > with valid timestamp. In this scenario, the LMA will wrongly > accept PBU1 > arriving after PBU2, since both have a valid timestamp. Consequently, > the LMA forwards packets to the wrong MAG (MAG1) and will not > notice the > out of sync of MAG1, which also means that the LMA doesn't return a > timestamp in the PBA and MAG1's clock keeps to be out of sync. > > 2. When packets on the link between MAG and LMA experience high (and > varying) packet delays (e.g., due to congestion), the timestamp in the > PBA returned by the LMA may already be outdated at the time it arrives > at the MAG. So exactly in the situation where a re-ordering of PBUs is > needed, the synchronization mechanism may fail. > > My two cents. > > BR, > > Kilian > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Freitag, 7. September 2007 18:48 > > To: 'Kilian Weniger' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > Hi Kilian, > > > > > > > > > -----Original Message----- > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > Sent: Friday, September 07, 2007 2:09 AM > > > To: Sri Gundavelli > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > Hi Sri, > > > > > > > - We are NOT mandating the nodes in the domain to sync up to > > > > a clock source. > > > > > > Hmm, so far I assumed that the proposal is to mandate the > > MAGs to sync > > > up to an external clock source such as NTP server. > > > > > > > For the timestamp option to work, we RECOMMEND the use of NTP for > > synchronizing the clocks in the domain. However, we do not want to > > mandate on a specific mechanism. > > > > > > > > Base draft does not support Context Transfers. Given that > > the draft > > > > will be incomplete, if we dont mandate the support. By mandating > > > > the support, the LMA can always return its timestamp and the MAG > > > > can use that timestamp and register. This need to be done just > > > > once whenever the LMA/MAG clocks are out of sync and > just for one > > > > registration. One extra round trip for the 1st > > registration between > > > > LMA/MAG pair. > > > > > > So the proposal is to allow the use of the timestamp option in the > > > absence of any external time synchronization like NTP and > > to mandate a > > > mechanism to synchronize clocks between MAGs and LMA (and > > > hence between > > > all MAGs) using the timestamp option in PBU/PBA only > (i.e., without > > > utilizing NTP or an external clock source)? Is my > > > understanding correct? > > > > > > > No. For this to work, we require the clocks to be in sync. > > How its achieved, it could be based on NTP or some other protocols. > > But, why should we mandate this. > > > > > > > If so, can you please give some more details how the LMA can > > > detect that > > > the clocks are out of sync? Is it based on a certain difference of > > > timestamp in the received PBU and the current LMA's time? > > > > > > And how to differentiate the out of sync case from the > out-of-order > > > delivery case (i.e., a PBU is delayed and overtaken by > > > another PBU from > > > another MAG)? For instance, if the LMA receives a PBU > with timestamp > > > equal to "current time of LMA - X" and X > threshold, how > > does the LMA > > > know whether the > > > 1. the MAG clock is synchronized, but the PBU got delayed by X or > > > 2. the PBU is not delayed, but the MAG's clock is out of > sync by X? > > > Ideally, in case 1 the LMA should just ignore the PBU, in > case 2 it > > > should accept it and sync clocks. > > > > > > If the idea is to always reject a PBU with X > threshold > > and include a > > > current timestamp in the PBA, then I guess the same could > > be done with > > > sequence numbers instead of timestamps, right? > > > > > > > For what ever reasons if the LMA and MAG clocks are out of sync, the > > LMA can return its timestamp and the MAG can always apply that delta > > in all the registration it sends. This is done just once, when ever > > the clocks are off. But, with seq number scheme, this needs > to be done > > for each MN registration. Its as per the 3775 per MN seq number. > > > > Sri > > > > > BR, > > > > > > Kilian > > > > > > > > > Panasonic R&D Center Germany GmbH > > > 63225 Langen, Hessen, Germany > > > Reg: AG Offenbach (Hessen) HRB 33974 > > > Managing Director: Thomas Micke > > > > > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 02:29:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVLie-0004BA-8H; Wed, 12 Sep 2007 02:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVLid-0004B4-Jm for netlmm@ietf.org; Wed, 12 Sep 2007 02:28:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVLic-0007Os-39 for netlmm@ietf.org; Wed, 12 Sep 2007 02:28:59 -0400 X-IronPort-AV: E=Sophos;i="4.20,242,1186383600"; d="scan'208";a="216515099" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Sep 2007 23:28:57 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8C6SvEL024228; Tue, 11 Sep 2007 23:28:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8C6SvEw013770; Wed, 12 Sep 2007 06:28:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 23:28:57 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 23:28:56 -0700 From: "Sri Gundavelli" To: "'Alper Yegin'" , "'Chowdhury, Kuntal'" References: <7CCD07160348804497EF29E9EA5560D7024DA565$0001@exchtewks2.starentnetworks.com> <0MKpCa-1IVCxf06NF-0007OU@mrelay.perfora.net> Subject: RE: [netlmm] Significance of MN-Identifier Date: Tue, 11 Sep 2007 23:28:56 -0700 Message-ID: <000101c7f506$32738970$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZg In-Reply-To: <0MKpCa-1IVCxf06NF-0007OU@mrelay.perfora.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 12 Sep 2007 06:28:56.0674 (UTC) FILETIME=[325A5C20:01C7F506] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6636; t=1189578537; x=1190442537; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Significance=20of=20MN-Identifier |Sender:=20; bh=r4jMT9u1QFx5l1X48FG9Jbak1MCAjBN4YH6Vd96eeeI=; b=xhgDNn2HgxDIvUMQJPu8PA0GZNZhDI9nf+bcc/y35+Rpm9FRo2SeBeWehzCzRqqVN+yeV8Hl fTr806q6OgsFqNhkte+M9Lqom7NVPFazDL14/T9EZFIg7VPYn3LMqBH5; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Tuesday, September 11, 2007 2:08 PM > To: 'Chowdhury, Kuntal'; 'Sri Gundavelli' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Significance of MN-Identifier > > Hi Kuntal, > > > I don't know what the issue is for MN-ID in the PMIP6 signaling > > messages. Could you explain why we are having this debate? > > Because, the current text is locking all PMIP6 deployments to > one security > model and not leaving any room for using anything else. And > it is doing so > without a good reason (unintentionally, I believe). > > > MN-ID is the unique identifier to identify the session > state in the LMA. > > It is necessary only of the MN does not know its HNP. As soon > as it knows > the HNP (e.g., when HNP is assigned during network access > authentication), > we can rely on HNP to identify the session state. > HNP is dynamically generated. Initially, a MN may not have been allocated any HNP, in that we have to send the MN identity for the LMA to apply the proper policy checks and allocate a prefix. After that point, when the mobile moves to a new MAG, the MAG on the link would likely authenticate the MN, obtain its id before it allows the MN for network access. So, most likely the new MAG would know the MN id as supposed to knowing its allocated prefix, that may be in the BCE state (unless statically configured in AAA). Generally, I can see 3775 HA, identifying a MN with its HoA and so not requiring the id in the signaling messages. But, in a proxy model in combination with dynamic prefix allocation, is it not reasonable to carry an identifier of the mobile node in the messages ? Thats the stable identifier of the mobile node. Its definetly more stable than an allocated prefix. The MAG may authenticate the mobile node on the access link and will mo t likely have some form of identifier, as supposed to it knowing the prefix that is allocated by the LMA. Id is also required for billing purposes as well and may very well be the corelation id. I do not think, we introduced this id requirement, just with one scenario in mind. Its a very natural requirement and the information is there on the MAG. Do not know, why this would be an issue for WiMAX case. Sri > > > There are several good reasons to mandate the presence of > MN-ID in the > > PBU/PBA. For example, it helps to identify the session > state in the LMA > > for PMIP6 - MIP6 transition scenarios, when the LMA is > collocated with a > > MIP6 HA. > > Can you elaborate on this scenario? You may have something > here, but I need > to understand. > > Alper > > > > Note that during IKEv2 exchange for MIP6, the IDi field (that > > carries the same MN-ID) in the IKE packets help identify the ongoing > > (PMIP6) session related to the MN. > > > > Hope this helps. > > > > -Kuntal > > > > > > > -----Original Message----- > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > To: 'Sri Gundavelli' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > Sri, > > > > > > > At handoff, nMAG may not know the HNP of the mobile > node. How does > > it > > > > communicate with the LMA about the MN, if MN-Id is not > used ? That's > > > > is essential, its required in BCE and also in signaling > messages. > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > >>> Is it for the sake of identifying the MN during dynamic HNP > > > >>> assignment in-band with PMIP? > > > > > > > > > HNP can be assigned during network access authentication. I can't > > imagine > > > when this is not possible or desirable. > > > > > > That's why mandating presence of MN-id that identifies > the MN is not > > > necessary, imo. > > > > > > If people can show a reason why we must also support HNP > assignment > > in- > > > band > > > with PMIP, we can say: > > > > > > When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > Alper > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > >> Sri > > > > >> > > > > >> > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > >>> To: netlmm@ietf.org > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > >>> > > > > >>> What's the significance of MN-Identifier as carried in PBU? > > > > >>> > > > > >>> Is it for the sake of identifying the MN during dynamic HNP > > > assignment > > > > >>> in-band with PMIP? > > > > >>> > > > > >>> If so, given that the HNP may also be assigned > during network > > access > > > > >>> authentication (out-of band with PMIP, as commonly done in > > > integrated > > > > >>> bootstrapping scenarios), we shall not mandate that the MN- > > > identifier > > > > >>> identifies the real MN. > > > > >>> > > > > >>> Another way of using of MN-identifier is to identify the > > > > >>> "proxy MN" (MAG) > > > > >>> with RFC 4285. > > > > >>> > > > > >>> Alper > > > > >>> > > > > >>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> netlmm mailing list > > > > >>> netlmm@ietf.org > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > "This email message and any attachments are confidential > information of > > Starent Networks, Corp. The information transmitted may not > be used to > > create or change any contractual obligations of Starent > Networks, Corp. > > Any review, retransmission, dissemination or other use of, > or taking of > > any action in reliance upon this e-mail and its attachments > by persons or > > entities other than the intended recipient is prohibited. > If you are not > > the intended recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of > this message > > and any attachments without reading or disclosing their > contents. Thank > > you." _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 03:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVMf0-0002Cl-0e; Wed, 12 Sep 2007 03:29:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVMey-0002Cf-1Y for netlmm@ietf.org; Wed, 12 Sep 2007 03:29:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVMex-0003Oo-KK for netlmm@ietf.org; Wed, 12 Sep 2007 03:29:15 -0400 X-IronPort-AV: E=Sophos;i="4.20,242,1186383600"; d="scan'208";a="216540169" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Sep 2007 00:29:15 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8C7TFRk002870; Wed, 12 Sep 2007 00:29:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8C7TAEw029365; Wed, 12 Sep 2007 07:29:14 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 00:29:10 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 00:29:09 -0700 From: "Sri Gundavelli" To: "'Julien Laganier'" , References: <200709111620.02475.julien.IETF@laposte.net> Subject: RE: [netlmm] DNAv6/SEND and timestamp synchronization problems Date: Wed, 12 Sep 2007 00:29:09 -0700 Message-ID: <000d01c7f50e$9bf6f9b0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf0ft+7S9kcp3rpRvK4ZcIqqBqVxwAji20Q In-Reply-To: <200709111620.02475.julien.IETF@laposte.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 12 Sep 2007 07:29:09.0846 (UTC) FILETIME=[9BF8A760:01C7F50E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1687; t=1189582155; x=1190446155; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20DNAv6/SEND=20and=20timestamp=20synchroniza tion=20problems |Sender:=20; bh=JCJsglZgci2EEW/2U3QWi8HeHkFHGkMKLVzYmy+lDxo=; b=bhLTUVvX+ZRhTJR456gZZ0ZOZ49i7tVDKwuSNQMPfOHUdQrsOJ91aL0UFNCuL+SX3gCjthx6 ck4xFUosb41q64ejqalh9fRYmfsdtN1vDcGWfU1RIVI5OtKYvL4wiAwQlnpTzV9SbGwJtyYIqO Nb/YC9FZhB8dxtrZWJYXTIn+g=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien, > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net] > Sent: Tuesday, September 11, 2007 7:20 AM > To: netlmm@ietf.org > Subject: [netlmm] DNAv6/SEND and timestamp synchronization problems > > Folks, > > It has been discussed on the mailing list that synchronizing > time across > different MAGs to allow reordering of pBUs might be a problem. While > thinking about the issue I got the idea to leverage on SEND to solve > that issue. > > When the MN uses DNAv6 for movement detection along with SEND > to secure > ND signaling (which includes DNAv6), all ND messages sent by the MN > will contain a timestamp representing the local time on the MN. Thus, > all MAGs to which a given MN attached to have access to a > single per-MN > timestamp source. > Good idea ! Will this require the RS as the only trigger for PMIP signaling ? Currently, any network attachment event or auth completion event can be used by the MAG as a trigger to start the PMIP signaling. This change requires the timestamp in PMIP message and that can come only in ND messages from the MN. Other comment is from the deployment perspective, do you think, we can expect operators to put DNAv6 in the handsets, right away ? That will be a factor as well. Sri > Using pBU timestamps from that source will avoid issues with time > synchronization of different MAGs since timestamps are > synchronized at > the source. > > Thoughts? > > --julien > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 04:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVNHZ-0004as-0Y; Wed, 12 Sep 2007 04:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVNHY-0004XG-2O for netlmm@ietf.org; Wed, 12 Sep 2007 04:09:08 -0400 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVNHW-0000uR-9c for netlmm@ietf.org; Wed, 12 Sep 2007 04:09:08 -0400 Received: from rly12e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly12e.srv.mailcontrol.com (MailControl) with ESMTP id l8C88Y2s019484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Sep 2007 09:09:03 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly12e.srv.mailcontrol.com (MailControl) id l8C8874C017831 for netlmm@ietf.org; Wed, 12 Sep 2007 09:08:07 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly12e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8C87xf4017182; Wed, 12 Sep 2007 09:08:07 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 3962_783152b4_6106_11dc_9bae_0030482aac25; Wed, 12 Sep 2007 10:02:11 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091210075048-106280 ; Wed, 12 Sep 2007 10:07:50 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.103,BAYES_00: -1.665,TOTAL_SCORE: -1.562 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 12 Sep 2007 10:08:18 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] timestamp vs seqno redux In-Reply-To: <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8A== References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> Date: Wed, 12 Sep 2007 10:07:29 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.69.1.122 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri,=20 please see my comments inline. > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Mittwoch, 12. September 2007 08:14 > To: 'Kilian Weniger' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Kilian/Federico, >=20 > =20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > > Sent: Tuesday, September 11, 2007 6:33 AM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > my point is that NOT mandating synchronization to an external clock > > source for the timestamp option implies that sending PBU msgs with > > timestamp option is allowed even when MAGs are not (yet)=20 > synchronized. > > I.e., it would be allowed that a deployment uses only the returned > > timestamps in PBA msgs to synchronize the MAG clocks. I think=20 > > the draft > > should not allow this for the following reasons: > >=20 >=20 > The stated assumption for the timestamp based approach to work, > is the requirement for the MAG's to have synchronized clocks. > That is a requirement. Now, if a given MAG sends a PBU with an > incorrect timestamp, its an error and as you and Federico pointed > out, there are cases where the LMA will not be able to determine > the sending order of the received packets. This is an error > condition, as the requirement is not met. Right, sending a PBU with timestamp option requires that the MAG's clock is synchronized. Hence, I don't see why the draft should specify a mechanism to synchronize a MAG's clock using a received PBA. Also, I think this mechanism has issues in some scenario (see my previous mail). The clock synchronization is the job of some PMIP-independent synchronization method like NTP and out of sync clocks can only occur if there is a problem with this PMIP-independent synchronization method. Hence, it is a non-recoverable error case from PMIP point of view IMHO.=20 >=20 > Now, should the draft state that the time synchronization is a > requirement and additionally mandate a method of time synchronization, > say by NTP ? But, the later has a system wide impact and additionally, > a given architecture where this protocol is applied, can achieve the > time synchronization through other non NTP means. IMO, we may not > be able dictate that. Also, we want implementations to support the > timestamp based scheme by default. Now, mandating the NTP usage will > create some restrictions for some deployments. So, that is the > reasoning behind not mandating the method of time synchronization. I'm not sure if the draft can say "a MAG's clock MUST be synchronized for this protocol to work, but how this is done is out of scope of the draft". I guess the draft has to mandate the implementation of one "default" synchronization protocol such as NTP to achieve interoperability. However, as long as the use of NTP is not mandated (e.g., just say "SHOULD use"), deployments can still use other methods. So I don't see restrictions for deployments in this case.=20 >=20 > W.r.t this below scenario, the reason for LMA to return its timestamp, > solves two purposes. 1.) Diagnostics (especially useful when the LMA > and MAG are in different admin domains) 2.) The MAG can detect that > its clock is not in sync and take the necessary actions. I guess, > Frederico has an issue with the second part. But, if you look at > the recommendation from the draft on handling this error case, > MAG signaling considerations,=20 >=20 > "If the received Proxy Binding Acknowledgement message has the > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > Timestamp), > the mobile access gateway SHOULD try to register again=20 > only after > it synchronized its clock with the local mobility=20 > anchor's system > clock or to a common time source that is used by all mobility > entities in that domain for their clock synchronization." >=20 I think it is good if the LMA informs the MAG about detected out of sync clocks for the purpose of diagnostics and as a trigger for re-sync. But why do we need the timestamp option in the PBA? The TIMESTAMP_MISMATCH value in the status field is enough for the purpose of diagnostics and as a trigger for re-sync.=20 > So, we are not really using the LMA as the time source. Now, with the > given assumptions, do you see an issue if we dont say NTP is a MUST, > but we say clock synch is a requirement, how they do it, draft does > not say. If this requirement is not met, its an incorrect usage of > the protocol and the PBU ordering will fail in that special rare > reordering scenario (IMO, its not a practical issue). see above BR, Kilian >=20 > The second question to this discussion, is Alex's point of not > mandating Timestamp option as a MUST implement. For this, as I stated > before, this is few lines of code for supporting this option=20 > and if seq > number scheme is in use, this need not be used at all. We=20 > need to mandate > this as there is no CT in the base spec. But, this is not a big issue > either way. If others agree, I'm fine not mandating this.=20 > But, I really > believe, implementations can support this option, at the least cost. >=20 > One last comment on the trust on LMA's clock for the sanity check, is > because its an anchor point and its typically well managed, compared > to MAG's, where they are scattered out. So, its reasonable to expect > the clock on the LMA to be in sync, else all registrations will fail > and will generate the traps. >=20 > So, let me know your comments on how we can move forward. >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > 1. If a MAG's clock is out of sync (i.e., not yet synced by=20 > > receiving a > > PBA with timestamp) AND PBUs sent by this MAG are delayed,=20 > the out of > > sync situation may not be detectable by the LMA and old PBUs may be > > accepted by the LMA.=20 > >=20 > > Consider the following example: MN attaches to MAG1 and shortly > > thereafter hands over to MAG2. MAG2's clock is in sync with=20 > > LMA's clock, > > but MAG1's clock is out of sync and is ahead of LMA's clock by 5 > > seconds. MAG1-LMA link is highly congested. When MN=20 > attaches to MAG1, > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before=20 > the MN hands > > over to MAG2. The PBU1 msg is delayed by 5 seconds due to the=20 > > congestion > > and hence arrives at LMA 2 seconds after handover. Despite of=20 > > the delay, > > PBU1 has a valid timestamp from LMA's point of view due to the wrong > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after=20 > handover. PBU2 is > > not significantly delayed and arrives at LMA ~1 seconds=20 > after handover > > with valid timestamp. In this scenario, the LMA will wrongly=20 > > accept PBU1 > > arriving after PBU2, since both have a valid timestamp.=20 > Consequently, > > the LMA forwards packets to the wrong MAG (MAG1) and will not=20 > > notice the > > out of sync of MAG1, which also means that the LMA doesn't return a > > timestamp in the PBA and MAG1's clock keeps to be out of sync. > >=20 > > 2. When packets on the link between MAG and LMA experience high (and > > varying) packet delays (e.g., due to congestion), the=20 > timestamp in the > > PBA returned by the LMA may already be outdated at the time=20 > it arrives > > at the MAG. So exactly in the situation where a re-ordering=20 > of PBUs is > > needed, the synchronization mechanism may fail. > >=20 > > My two cents. > >=20 > > BR, > >=20 > > Kilian > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > > > Sent: Freitag, 7. September 2007 18:48 > > > To: 'Kilian Weniger' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Kilian, > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri,=20 > > > >=20 > > > > > - We are NOT mandating the nodes in the domain to sync up to > > > > > a clock source.=20 > > > >=20 > > > > Hmm, so far I assumed that the proposal is to mandate the=20 > > > MAGs to sync > > > > up to an external clock source such as NTP server. > > > >=20 > > >=20 > > > For the timestamp option to work, we RECOMMEND the use of NTP for > > > synchronizing the clocks in the domain. However, we do not want to > > > mandate on a specific mechanism.=20 > > >=20 > > >=20 > > > > > Base draft does not support Context Transfers. Given that=20 > > > the draft > > > > > will be incomplete, if we dont mandate the support.=20 > By mandating > > > > > the support, the LMA can always return its timestamp=20 > and the MAG > > > > > can use that timestamp and register. This need to be done just > > > > > once whenever the LMA/MAG clocks are out of sync and=20 > > just for one > > > > > registration. One extra round trip for the 1st=20 > > > registration between > > > > > LMA/MAG pair. > > > >=20 > > > > So the proposal is to allow the use of the timestamp=20 > option in the > > > > absence of any external time synchronization like NTP and=20 > > > to mandate a > > > > mechanism to synchronize clocks between MAGs and LMA (and=20 > > > > hence between > > > > all MAGs) using the timestamp option in PBU/PBA only=20 > > (i.e., without > > > > utilizing NTP or an external clock source)? Is my=20 > > > > understanding correct? > > > >=20 > > >=20 > > > No. For this to work, we require the clocks to be in sync. > > > How its achieved, it could be based on NTP or some other=20 > protocols. > > > But, why should we mandate this. > > >=20 > > >=20 > > > > If so, can you please give some more details how the LMA can=20 > > > > detect that > > > > the clocks are out of sync? Is it based on a certain=20 > difference of > > > > timestamp in the received PBU and the current LMA's time?=20 > > > >=20 > > > > And how to differentiate the out of sync case from the=20 > > out-of-order > > > > delivery case (i.e., a PBU is delayed and overtaken by=20 > > > > another PBU from > > > > another MAG)? For instance, if the LMA receives a PBU=20 > > with timestamp > > > > equal to "current time of LMA - X" and X > threshold, how=20 > > > does the LMA > > > > know whether the=20 > > > > 1. the MAG clock is synchronized, but the PBU got=20 > delayed by X or > > > > 2. the PBU is not delayed, but the MAG's clock is out of=20 > > sync by X? > > > > Ideally, in case 1 the LMA should just ignore the PBU, in=20 > > case 2 it > > > > should accept it and sync clocks. > > > >=20 > > > > If the idea is to always reject a PBU with X > threshold=20 > > > and include a > > > > current timestamp in the PBA, then I guess the same could=20 > > > be done with > > > > sequence numbers instead of timestamps, right? > > > >=20 > > >=20 > > > For what ever reasons if the LMA and MAG clocks are out=20 > of sync, the > > > LMA can return its timestamp and the MAG can always apply=20 > that delta > > > in all the registration it sends. This is done just once,=20 > when ever > > > the clocks are off. But, with seq number scheme, this needs=20 > > to be done > > > for each MN registration. Its as per the 3775 per MN seq number. > > >=20 > > > Sri > > >=20 > > > > BR, > > > >=20 > > > > Kilian > > > >=20 > > > >=20 > > > > Panasonic R&D Center Germany GmbH > > > > 63225 Langen, Hessen, Germany > > > > Reg: AG Offenbach (Hessen) HRB 33974 > > > > Managing Director: Thomas Micke > > >=20 > > >=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 04:42:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVNnw-0002pk-WB; Wed, 12 Sep 2007 04:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVNnv-0002gm-Hm for netlmm@ietf.org; Wed, 12 Sep 2007 04:42:35 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVNnu-0001P9-3P for netlmm@ietf.org; Wed, 12 Sep 2007 04:42:35 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IVNnm3uVi-0008Vr; Wed, 12 Sep 2007 04:42:33 -0400 From: "Alper Yegin" To: "'Sri Gundavelli'" , "'Chowdhury, Kuntal'" Subject: RE: [netlmm] Significance of MN-Identifier Date: Wed, 12 Sep 2007 11:42:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZgAATcTHA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <000101c7f506$32738970$d5f6200a@amer.cisco.com> Message-Id: <0MKp8S-1IVNnm3uVi-0008Vr@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/lPGejr/EWUku6F1stUhcfuxGekcvLthTwAR4 JCguk6/LVFqnCUfS0SfEsnDQ13uTDS9bf/dAAlmLv5fyv/DFha zAAoWndi+YB+GqIEMD2Zg== X-Spam-Score: -0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, You are explaining how carrying some identifier representing the MN is useful. Not explaining why "it MUST always be carried". My point is two-fold: - There is one very strong case that the HNP is allocated as part of the network access authentication. In that case, we don't have to rely on "some identifier representing the MN", instead HNP is already bound to the MN. HNP becomes that identifier. - Use of RFC 4285 with MAG-LMA SA is one of the possible security models. And that requires carrying the "MAG id" in the NAI. Assuming the NAI always carries some "MN id" as the current spec does is disallowing this possibility. My proposal is to relax that language so that NAI is not "always" supposed to carry a "MN id". Specific exception case is when the MN is already assigned a HNP by an out-of band mechanisms. Alper > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Wednesday, September 12, 2007 9:29 AM > To: 'Alper Yegin'; 'Chowdhury, Kuntal' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Significance of MN-Identifier > > Hi Alper, > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Tuesday, September 11, 2007 2:08 PM > > To: 'Chowdhury, Kuntal'; 'Sri Gundavelli' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > Hi Kuntal, > > > > > I don't know what the issue is for MN-ID in the PMIP6 signaling > > > messages. Could you explain why we are having this debate? > > > > Because, the current text is locking all PMIP6 deployments to > > one security > > model and not leaving any room for using anything else. And > > it is doing so > > without a good reason (unintentionally, I believe). > > > > > MN-ID is the unique identifier to identify the session > > state in the LMA. > > > > It is necessary only of the MN does not know its HNP. As soon > > as it knows > > the HNP (e.g., when HNP is assigned during network access > > authentication), > > we can rely on HNP to identify the session state. > > > > HNP is dynamically generated. Initially, a MN may not have been > allocated any HNP, in that we have to send the MN identity for > the LMA to apply the proper policy checks and allocate a prefix. > After that point, when the mobile moves to a new MAG, the MAG > on the link would likely authenticate the MN, obtain its id > before it allows the MN for network access. So, most likely > the new MAG would know the MN id as supposed to knowing its > allocated prefix, that may be in the BCE state (unless statically > configured in AAA). > > Generally, I can see 3775 HA, identifying a MN with its HoA and > so not requiring the id in the signaling messages. But, in a > proxy model in combination with dynamic prefix allocation, is > it not reasonable to carry an identifier of the mobile node in > the messages ? Thats the stable identifier of the mobile node. > Its definetly more stable than an allocated prefix. The MAG may > authenticate the mobile node on the access link and will mo > t likely have some form of identifier, as supposed to it knowing > the prefix that is allocated by the LMA. Id is also required for > billing purposes as well and may very well be the corelation id. > > I do not think, we introduced this id requirement, just with one > scenario in mind. Its a very natural requirement and the information > is there on the MAG. Do not know, why this would be an issue for > WiMAX case. > > Sri > > > > > > > > > > There are several good reasons to mandate the presence of > > MN-ID in the > > > PBU/PBA. For example, it helps to identify the session > > state in the LMA > > > for PMIP6 - MIP6 transition scenarios, when the LMA is > > collocated with a > > > MIP6 HA. > > > > Can you elaborate on this scenario? You may have something > > here, but I need > > to understand. > > > > Alper > > > > > > > Note that during IKEv2 exchange for MIP6, the IDi field (that > > > carries the same MN-ID) in the IKE packets help identify the ongoing > > > (PMIP6) session related to the MN. > > > > > > Hope this helps. > > > > > > -Kuntal > > > > > > > > > > -----Original Message----- > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > > To: 'Sri Gundavelli' > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > Sri, > > > > > > > > > At handoff, nMAG may not know the HNP of the mobile > > node. How does > > > it > > > > > communicate with the LMA about the MN, if MN-Id is not > > used ? That's > > > > > is essential, its required in BCE and also in signaling > > messages. > > > > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > > > >>> Is it for the sake of identifying the MN during dynamic HNP > > > > >>> assignment in-band with PMIP? > > > > > > > > > > > > HNP can be assigned during network access authentication. I can't > > > imagine > > > > when this is not possible or desirable. > > > > > > > > That's why mandating presence of MN-id that identifies > > the MN is not > > > > necessary, imo. > > > > > > > > If people can show a reason why we must also support HNP > > assignment > > > in- > > > > band > > > > with PMIP, we can say: > > > > > > > > When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that > > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > >> Sri > > > > > >> > > > > > >> > > > > > >> > > > > > >>> -----Original Message----- > > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > > >>> To: netlmm@ietf.org > > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > > >>> > > > > > >>> What's the significance of MN-Identifier as carried in PBU? > > > > > >>> > > > > > >>> Is it for the sake of identifying the MN during dynamic HNP > > > > assignment > > > > > >>> in-band with PMIP? > > > > > >>> > > > > > >>> If so, given that the HNP may also be assigned > > during network > > > access > > > > > >>> authentication (out-of band with PMIP, as commonly done in > > > > integrated > > > > > >>> bootstrapping scenarios), we shall not mandate that the MN- > > > > identifier > > > > > >>> identifies the real MN. > > > > > >>> > > > > > >>> Another way of using of MN-identifier is to identify the > > > > > >>> "proxy MN" (MAG) > > > > > >>> with RFC 4285. > > > > > >>> > > > > > >>> Alper > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> netlmm mailing list > > > > > >>> netlmm@ietf.org > > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > "This email message and any attachments are confidential > > information of > > > Starent Networks, Corp. The information transmitted may not > > be used to > > > create or change any contractual obligations of Starent > > Networks, Corp. > > > Any review, retransmission, dissemination or other use of, > > or taking of > > > any action in reliance upon this e-mail and its attachments > > by persons or > > > entities other than the intended recipient is prohibited. > > If you are not > > > the intended recipient, please notify the sender immediately -- by > > > replying to this message or by sending an email to > > > postmaster@starentnetworks.com -- and destroy all copies of > > this message > > > and any attachments without reading or disclosing their > > contents. Thank > > > you." _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 04:59:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVO4T-0008Eb-Dk; Wed, 12 Sep 2007 04:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVO4Q-00088P-Ff for netlmm@ietf.org; Wed, 12 Sep 2007 04:59:38 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVO4O-0001gZ-Nx for netlmm@ietf.org; Wed, 12 Sep 2007 04:59:38 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id l8C8xVxF009239; Wed, 12 Sep 2007 10:59:31 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8C8xIBW000466; Wed, 12 Sep 2007 10:59:30 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Sep 2007 10:59:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Significance of MN-Identifier Date: Wed, 12 Sep 2007 10:59:26 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6802941BC7@zagh223a.ww300.siemens.net> In-Reply-To: <0MKp8S-1IVNnm3uVi-0008Vr@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Significance of MN-Identifier Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZgAATcTHAAAJrNcA== References: <000101c7f506$32738970$d5f6200a@amer.cisco.com> <0MKp8S-1IVNnm3uVi-0008Vr@mrelay.perfora.net> From: "Premec, Domagoj" To: "Alper Yegin" , "Sri Gundavelli" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 12 Sep 2007 08:59:28.0014 (UTC) FILETIME=[39737AE0:01C7F51B] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070912105931-0B32EBB0-715AE623/0-0/0-15 X-purgate-size: 9542/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper,=20 please see inline...=20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: 12. rujan 2007 10:42 > To: 'Sri Gundavelli'; 'Chowdhury, Kuntal' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Significance of MN-Identifier >=20 > Sri, >=20 > You are explaining how carrying some identifier representing=20 > the MN is useful. Not explaining why "it MUST always be carried". >=20 > My point is two-fold: >=20 > - There is one very strong case that the HNP is allocated as=20 > part of the network access authentication. In that case, we=20 > don't have to rely on "some identifier representing the MN",=20 > instead HNP is already bound to the MN. HNP becomes that identifier.=20 >=20 > - Use of RFC 4285 with MAG-LMA SA is one of the possible=20 > security models. > And that requires carrying the "MAG id" in the NAI. Assuming=20 > the NAI always carries some "MN id" as the current spec does=20 > is disallowing this possibility. Why is MAG id in the NAI option required for rfc 4285? The LMA could use = the SPI from the auth option to identify the MAG. The NAI option can = still carry the NAI of the MN. Would that work? >=20 > My proposal is to relax that language so that NAI is not=20 > "always" supposed to carry a "MN id". Specific exception case=20 > is when the MN is already assigned a HNP by an out-of band mechanisms. >=20 > Alper >=20 >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Wednesday, September 12, 2007 9:29 AM > > To: 'Alper Yegin'; 'Chowdhury, Kuntal' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Significance of MN-Identifier > >=20 > > Hi Alper, > >=20 > >=20 > > > -----Original Message----- > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > Sent: Tuesday, September 11, 2007 2:08 PM > > > To: 'Chowdhury, Kuntal'; 'Sri Gundavelli' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > Hi Kuntal, > > > > > > > I don't know what the issue is for MN-ID in the PMIP6 signaling=20 > > > > messages. Could you explain why we are having this debate? > > > > > > Because, the current text is locking all PMIP6 deployments to one=20 > > > security model and not leaving any room for using=20 > anything else. And=20 > > > it is doing so without a good reason (unintentionally, I believe). > > > > > > > MN-ID is the unique identifier to identify the session > > > state in the LMA. > > > > > > It is necessary only of the MN does not know its HNP. As=20 > soon as it=20 > > > knows the HNP (e.g., when HNP is assigned during network access=20 > > > authentication), we can rely on HNP to identify the session state. > > > > >=20 > > HNP is dynamically generated. Initially, a MN may not have been=20 > > allocated any HNP, in that we have to send the MN identity=20 > for the LMA=20 > > to apply the proper policy checks and allocate a prefix. > > After that point, when the mobile moves to a new MAG, the=20 > MAG on the=20 > > link would likely authenticate the MN, obtain its id before=20 > it allows=20 > > the MN for network access. So, most likely the new MAG=20 > would know the=20 > > MN id as supposed to knowing its allocated prefix, that may=20 > be in the=20 > > BCE state (unless statically configured in AAA). > >=20 > > Generally, I can see 3775 HA, identifying a MN with its HoA=20 > and so not=20 > > requiring the id in the signaling messages. But, in a proxy=20 > model in=20 > > combination with dynamic prefix allocation, is it not reasonable to=20 > > carry an identifier of the mobile node in the messages ? Thats the=20 > > stable identifier of the mobile node. > > Its definetly more stable than an allocated prefix. The MAG may=20 > > authenticate the mobile node on the access link and will mo=20 > t likely=20 > > have some form of identifier, as supposed to it knowing the prefix=20 > > that is allocated by the LMA. Id is also required for=20 > billing purposes=20 > > as well and may very well be the corelation id. > >=20 > > I do not think, we introduced this id requirement, just with one=20 > > scenario in mind. Its a very natural requirement and the=20 > information=20 > > is there on the MAG. Do not know, why this would be an=20 > issue for WiMAX=20 > > case. > >=20 > > Sri > >=20 > >=20 > >=20 > >=20 > >=20 > > > > > > > There are several good reasons to mandate the presence of > > > MN-ID in the > > > > PBU/PBA. For example, it helps to identify the session > > > state in the LMA > > > > for PMIP6 - MIP6 transition scenarios, when the LMA is > > > collocated with a > > > > MIP6 HA. > > > > > > Can you elaborate on this scenario? You may have=20 > something here, but=20 > > > I need to understand. > > > > > > Alper > > > > > > > > > > Note that during IKEv2 exchange for MIP6, the IDi field (that=20 > > > > carries the same MN-ID) in the IKE packets help identify the=20 > > > > ongoing > > > > (PMIP6) session related to the MN. > > > > > > > > Hope this helps. > > > > > > > > -Kuntal > > > > > > > > > > > > > -----Original Message----- > > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > > > To: 'Sri Gundavelli' > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > > > Sri, > > > > > > > > > > > At handoff, nMAG may not know the HNP of the mobile > > > node. How does > > > > it > > > > > > communicate with the LMA about the MN, if MN-Id is not > > > used ? That's > > > > > > is essential, its required in BCE and also in signaling > > > messages. > > > > > > > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > > > > > >>> Is it for the sake of identifying the MN during=20 > dynamic HNP=20 > > > > > >>> assignment in-band with PMIP? > > > > > > > > > > > > > > > HNP can be assigned during network access authentication. I=20 > > > > > can't > > > > imagine > > > > > when this is not possible or desirable. > > > > > > > > > > That's why mandating presence of MN-id that identifies > > > the MN is not > > > > > necessary, imo. > > > > > > > > > > If people can show a reason why we must also support HNP > > > assignment > > > > in- > > > > > band > > > > > with PMIP, we can say: > > > > > > > > > > When the HNP in PBU has the value 0::/0, an NAI=20 > [RFC4283] > that > > > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > >> Sri > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>> -----Original Message----- > > > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > > > >>> To: netlmm@ietf.org > > > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > > > >>> > > > > > > >>> What's the significance of MN-Identifier as=20 > carried in PBU? > > > > > > >>> > > > > > > >>> Is it for the sake of identifying the MN during dynamic=20 > > > > > > >>> HNP > > > > > assignment > > > > > > >>> in-band with PMIP? > > > > > > >>> > > > > > > >>> If so, given that the HNP may also be assigned > > > during network > > > > access > > > > > > >>> authentication (out-of band with PMIP, as=20 > commonly done in > > > > > integrated > > > > > > >>> bootstrapping scenarios), we shall not mandate that the=20 > > > > > > >>> MN- > > > > > identifier > > > > > > >>> identifies the real MN. > > > > > > >>> > > > > > > >>> Another way of using of MN-identifier is to=20 > identify the=20 > > > > > > >>> "proxy MN" (MAG) with RFC 4285. > > > > > > >>> > > > > > > >>> Alper > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> netlmm mailing list > > > > > > >>> netlmm@ietf.org > > > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > "This email message and any attachments are confidential > > > information of > > > > Starent Networks, Corp. The information transmitted may not > > > be used to > > > > create or change any contractual obligations of Starent > > > Networks, Corp. > > > > Any review, retransmission, dissemination or other use of, > > > or taking of > > > > any action in reliance upon this e-mail and its attachments > > > by persons or > > > > entities other than the intended recipient is prohibited. > > > If you are not > > > > the intended recipient, please notify the sender=20 > immediately -- by=20 > > > > replying to this message or by sending an email to=20 > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > this message > > > > and any attachments without reading or disclosing their > > > contents. Thank > > > > you." >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 05:30:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVOYE-0004wY-U5; Wed, 12 Sep 2007 05:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVOYD-0004wJ-9m for netlmm@ietf.org; Wed, 12 Sep 2007 05:30:25 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVOYC-00028e-20 for netlmm@ietf.org; Wed, 12 Sep 2007 05:30:25 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IVOY02sLe-0008RU; Wed, 12 Sep 2007 05:30:17 -0400 From: "Alper Yegin" To: "'Chowdhury, Kuntal'" , "'Sri Gundavelli'" Subject: RE: [netlmm] Significance of MN-Identifier Date: Wed, 12 Sep 2007 12:29:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAACYsLQABeNxNA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA56C$0001@exchtewks2.starentnetworks.com> Message-Id: <0MKp8S-1IVOY02sLe-0008RU@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18m4Ovik+2rLiXahm3cPalm4NG288tjlZYJAoB ttjr8D18/2fvyt2a+yYsy6+ci1bf59gt8FIFkWexAcLPhXyEfv VTBB2UlDkChoB88yZEB5A== X-Spam-Score: -0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Kuntal, > > Can you elaborate on this scenario? You may have something here, but I > > need > > to understand. > > > [KC>] Sure, please look in the MIP6-PMIP6 transitions I-D: > > http://www.ietf.org/internet-drafts/draft-giaretta-netlmm-mip-interactio > ns-01.txt Even this spec does not have to rely on MN-id. Match between MIP6 BCE and PMIP6 BCE can very well be accomplished by looking at the HoA and HNP. Additional level of indirection to a "MN-id" is not necessary. More than that, it does not even work! Note that this requires that the MN-ID used by the mobile node during the IKEv2 set-up is the same of the MN-ID used by the MAG in PMIPv6 signalling. Now that we all figured out the MN-id used in PMIP6 is more likely to be a RADIUS/Diameter-related identifier that is not known to the MN, the above statement cannot be satisfied. Alper _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 05:55:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVOwF-0001ZZ-LN; Wed, 12 Sep 2007 05:55:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVOwE-0001Wn-0m for netlmm@ietf.org; Wed, 12 Sep 2007 05:55:14 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVOwD-0006rz-Cq for netlmm@ietf.org; Wed, 12 Sep 2007 05:55:13 -0400 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8C9sZ08008932; Wed, 12 Sep 2007 11:54:35 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 12 Sep 2007 11:55:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] DNAv6/SEND and timestamp synchronization problems Date: Wed, 12 Sep 2007 11:54:45 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A2D@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <200709111620.02475.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] DNAv6/SEND and timestamp synchronization problems Thread-Index: Acf0ft/pFOsrrVhvQ3Gg/vsKQk+vBwAn0RJg References: <200709111620.02475.julien.IETF@laposte.net> From: "DE JUAN HUARTE FEDERICO" To: "Julien Laganier" X-OriginalArrivalTime: 12 Sep 2007 09:55:12.0295 (UTC) FILETIME=[02CC4370:01C7F523] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien, the concept looks good to me, but only useful when SEND is present I'm not uptodate with SEND, may I ask a pointer to this protocol? In my opinion in order to enable this solution, there should also be the = following requirements/constraints: - Each BU should be preceded by a SEND message: this phrasing is = intentional to cover not only the scenario of "HO from pMAG to nMAG" = (which seems to be the one that everybody has in mind) but also the = scenario of "lifetime expiration" (thus BU refresh) - The number of MAGs to which the MN is associated should be = constrained to only 1: if the MN can be connected to pMAG and nMAG = concurrently (from SEND point of view), then avoiding race conditions in = PMIP HO would become more complex A final comment is that the idea could be generalized to allow using a = sequence number or a timestamp generated by the MN whenever there's a = protocol (e.g. SEND) which is guaranteed to be executed before sending a = BU Regards federico -----Message d'origine----- De : Julien Laganier [mailto:julien.IETF@laposte.net]=20 Envoy=E9 : mardi 11 septembre 2007 16:20 =C0 : netlmm@ietf.org Objet : [netlmm] DNAv6/SEND and timestamp synchronization problems Folks, It has been discussed on the mailing list that synchronizing time across = different MAGs to allow reordering of pBUs might be a problem. While = thinking about the issue I got the idea to leverage on SEND to solve = that issue. When the MN uses DNAv6 for movement detection along with SEND to secure = ND signaling (which includes DNAv6), all ND messages sent by the MN will = contain a timestamp representing the local time on the MN. Thus, all = MAGs to which a given MN attached to have access to a single per-MN = timestamp source. Using pBU timestamps from that source will avoid issues with time = synchronization of different MAGs since timestamps are synchronized at = the source. Thoughts? --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 06:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVPUP-0005y0-QJ; Wed, 12 Sep 2007 06:30:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVPUM-0005sT-WB for netlmm@ietf.org; Wed, 12 Sep 2007 06:30:31 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVPUL-0007Sm-FE for netlmm@ietf.org; Wed, 12 Sep 2007 06:30:30 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8CATrr5004553; Wed, 12 Sep 2007 12:29:53 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 12 Sep 2007 12:30:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Significance of MN-Identifier Date: Wed, 12 Sep 2007 12:28:29 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A32@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <0MKp8S-1IVNnm3uVi-0008Vr@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Significance of MN-Identifier Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZgAATcTHAAA9ENQA== References: <000101c7f506$32738970$d5f6200a@amer.cisco.com> <0MKp8S-1IVNnm3uVi-0008Vr@mrelay.perfora.net> From: "DE JUAN HUARTE FEDERICO" To: "Alper Yegin" X-OriginalArrivalTime: 12 Sep 2007 10:30:26.0628 (UTC) FILETIME=[EF09E040:01C7F527] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper,=20 for my information, I guess that the following assumptions are needed = (at least) to enable the solution you mention: - in order to identify the MN with the HNP you're assuming per-MN HNP = model - in a per-MN HNP model, the HNP will have to be longer than 64 bits Am I right? Regards federico -----Message d'origine----- De : Alper Yegin [mailto:alper.yegin@yegin.org]=20 Envoy=E9 : mercredi 12 septembre 2007 10:42 =C0 : 'Sri Gundavelli'; 'Chowdhury, Kuntal' Cc : netlmm@ietf.org Objet : RE: [netlmm] Significance of MN-Identifier Sri, You are explaining how carrying some identifier representing the MN is = useful. Not explaining why "it MUST always be carried". My point is two-fold: - There is one very strong case that the HNP is allocated as part of the = network access authentication. In that case, we don't have to rely on = "some identifier representing the MN", instead HNP is already bound to = the MN. HNP becomes that identifier.=20 - Use of RFC 4285 with MAG-LMA SA is one of the possible security = models. And that requires carrying the "MAG id" in the NAI. Assuming the NAI = always carries some "MN id" as the current spec does is disallowing this = possibility. My proposal is to relax that language so that NAI is not "always" = supposed to carry a "MN id". Specific exception case is when the MN is = already assigned a HNP by an out-of band mechanisms. Alper > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Wednesday, September 12, 2007 9:29 AM > To: 'Alper Yegin'; 'Chowdhury, Kuntal' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Significance of MN-Identifier >=20 > Hi Alper, >=20 >=20 > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Tuesday, September 11, 2007 2:08 PM > > To: 'Chowdhury, Kuntal'; 'Sri Gundavelli' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > Hi Kuntal, > > > > > I don't know what the issue is for MN-ID in the PMIP6 signaling=20 > > > messages. Could you explain why we are having this debate? > > > > Because, the current text is locking all PMIP6 deployments to one=20 > > security model and not leaving any room for using anything else. And = > > it is doing so without a good reason (unintentionally, I believe). > > > > > MN-ID is the unique identifier to identify the session > > state in the LMA. > > > > It is necessary only of the MN does not know its HNP. As soon as it=20 > > knows the HNP (e.g., when HNP is assigned during network access=20 > > authentication), we can rely on HNP to identify the session state. > > >=20 > HNP is dynamically generated. Initially, a MN may not have been=20 > allocated any HNP, in that we have to send the MN identity for the LMA = > to apply the proper policy checks and allocate a prefix. > After that point, when the mobile moves to a new MAG, the MAG on the=20 > link would likely authenticate the MN, obtain its id before it allows=20 > the MN for network access. So, most likely the new MAG would know the=20 > MN id as supposed to knowing its allocated prefix, that may be in the=20 > BCE state (unless statically configured in AAA). >=20 > Generally, I can see 3775 HA, identifying a MN with its HoA and so not = > requiring the id in the signaling messages. But, in a proxy model in=20 > combination with dynamic prefix allocation, is it not reasonable to=20 > carry an identifier of the mobile node in the messages ? Thats the=20 > stable identifier of the mobile node. > Its definetly more stable than an allocated prefix. The MAG may=20 > authenticate the mobile node on the access link and will mo t likely=20 > have some form of identifier, as supposed to it knowing the prefix=20 > that is allocated by the LMA. Id is also required for billing purposes = > as well and may very well be the corelation id. >=20 > I do not think, we introduced this id requirement, just with one=20 > scenario in mind. Its a very natural requirement and the information=20 > is there on the MAG. Do not know, why this would be an issue for WiMAX = > case. >=20 > Sri >=20 >=20 >=20 >=20 >=20 > > > > > There are several good reasons to mandate the presence of > > MN-ID in the > > > PBU/PBA. For example, it helps to identify the session > > state in the LMA > > > for PMIP6 - MIP6 transition scenarios, when the LMA is > > collocated with a > > > MIP6 HA. > > > > Can you elaborate on this scenario? You may have something here, but = > > I need to understand. > > > > Alper > > > > > > > Note that during IKEv2 exchange for MIP6, the IDi field (that=20 > > > carries the same MN-ID) in the IKE packets help identify the=20 > > > ongoing > > > (PMIP6) session related to the MN. > > > > > > Hope this helps. > > > > > > -Kuntal > > > > > > > > > > -----Original Message----- > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > > To: 'Sri Gundavelli' > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > Sri, > > > > > > > > > At handoff, nMAG may not know the HNP of the mobile > > node. How does > > > it > > > > > communicate with the LMA about the MN, if MN-Id is not > > used ? That's > > > > > is essential, its required in BCE and also in signaling > > messages. > > > > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > > > >>> Is it for the sake of identifying the MN during dynamic HNP=20 > > > > >>> assignment in-band with PMIP? > > > > > > > > > > > > HNP can be assigned during network access authentication. I=20 > > > > can't > > > imagine > > > > when this is not possible or desirable. > > > > > > > > That's why mandating presence of MN-id that identifies > > the MN is not > > > > necessary, imo. > > > > > > > > If people can show a reason why we must also support HNP > > assignment > > > in- > > > > band > > > > with PMIP, we can say: > > > > > > > > When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that > > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > >> Sri > > > > > >> > > > > > >> > > > > > >> > > > > > >>> -----Original Message----- > > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > > >>> To: netlmm@ietf.org > > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > > >>> > > > > > >>> What's the significance of MN-Identifier as carried in = PBU? > > > > > >>> > > > > > >>> Is it for the sake of identifying the MN during dynamic=20 > > > > > >>> HNP > > > > assignment > > > > > >>> in-band with PMIP? > > > > > >>> > > > > > >>> If so, given that the HNP may also be assigned > > during network > > > access > > > > > >>> authentication (out-of band with PMIP, as commonly done in > > > > integrated > > > > > >>> bootstrapping scenarios), we shall not mandate that the=20 > > > > > >>> MN- > > > > identifier > > > > > >>> identifies the real MN. > > > > > >>> > > > > > >>> Another way of using of MN-identifier is to identify the=20 > > > > > >>> "proxy MN" (MAG) with RFC 4285. > > > > > >>> > > > > > >>> Alper > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> netlmm mailing list > > > > > >>> netlmm@ietf.org > > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > "This email message and any attachments are confidential > > information of > > > Starent Networks, Corp. The information transmitted may not > > be used to > > > create or change any contractual obligations of Starent > > Networks, Corp. > > > Any review, retransmission, dissemination or other use of, > > or taking of > > > any action in reliance upon this e-mail and its attachments > > by persons or > > > entities other than the intended recipient is prohibited. > > If you are not > > > the intended recipient, please notify the sender immediately -- by = > > > replying to this message or by sending an email to=20 > > > postmaster@starentnetworks.com -- and destroy all copies of > > this message > > > and any attachments without reading or disclosing their > > contents. Thank > > > you." _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 06:40:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVPeA-00016y-48; Wed, 12 Sep 2007 06:40:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVPe9-000147-Af for netlmm@ietf.org; Wed, 12 Sep 2007 06:40:37 -0400 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVPe7-0003Ae-V0 for netlmm@ietf.org; Wed, 12 Sep 2007 06:40:37 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IVPds0DzV-0007Xr; Wed, 12 Sep 2007 06:40:29 -0400 From: "Alper Yegin" To: "'DE JUAN HUARTE FEDERICO'" Subject: RE: [netlmm] Significance of MN-Identifier Date: Wed, 12 Sep 2007 13:40:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZgAATcTHAAA9ENQAAAa5Ag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A32@FRVELSMBS12.ad2.ad.alcatel.com> Message-Id: <0MKpCa-1IVPds0DzV-0007Xr@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/+kPeKo4AWITpJYFRAVi7385ZVtE9L3jbxk/s IZaWsE73n7rmH3kiYRE05GwLcXew2ZOzwFL7mwATaCyA9/WELN Xkgh/Si/FzW/pR3wAPFfw== X-Spam-Score: -0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, > for my information, I guess that the following assumptions are needed = (at > least) to enable the solution you mention: > - in order to identify the MN with the HNP you're assuming per-MN = HNP > model Yes. That's the case with the base PMIP6 spec anyways. > - in a per-MN HNP model, the HNP will have to be longer than 64 = bits > Am I right? Why is that so? Alper >=20 > Regards >=20 > federico >=20 >=20 >=20 > -----Message d'origine----- > De : Alper Yegin [mailto:alper.yegin@yegin.org] > Envoy=E9 : mercredi 12 septembre 2007 10:42 > =C0 : 'Sri Gundavelli'; 'Chowdhury, Kuntal' > Cc : netlmm@ietf.org > Objet : RE: [netlmm] Significance of MN-Identifier >=20 > Sri, >=20 > You are explaining how carrying some identifier representing the MN is > useful. Not explaining why "it MUST always be carried". >=20 > My point is two-fold: >=20 > - There is one very strong case that the HNP is allocated as part of = the > network access authentication. In that case, we don't have to rely on > "some identifier representing the MN", instead HNP is already bound to = the > MN. HNP becomes that identifier. >=20 > - Use of RFC 4285 with MAG-LMA SA is one of the possible security = models. > And that requires carrying the "MAG id" in the NAI. Assuming the NAI > always carries some "MN id" as the current spec does is disallowing = this > possibility. >=20 > My proposal is to relax that language so that NAI is not "always" = supposed > to carry a "MN id". Specific exception case is when the MN is already > assigned a HNP by an out-of band mechanisms. >=20 > Alper >=20 >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Wednesday, September 12, 2007 9:29 AM > > To: 'Alper Yegin'; 'Chowdhury, Kuntal' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > Hi Alper, > > > > > > > -----Original Message----- > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > Sent: Tuesday, September 11, 2007 2:08 PM > > > To: 'Chowdhury, Kuntal'; 'Sri Gundavelli' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > Hi Kuntal, > > > > > > > I don't know what the issue is for MN-ID in the PMIP6 signaling > > > > messages. Could you explain why we are having this debate? > > > > > > Because, the current text is locking all PMIP6 deployments to one > > > security model and not leaving any room for using anything else. = And > > > it is doing so without a good reason (unintentionally, I believe). > > > > > > > MN-ID is the unique identifier to identify the session > > > state in the LMA. > > > > > > It is necessary only of the MN does not know its HNP. As soon as = it > > > knows the HNP (e.g., when HNP is assigned during network access > > > authentication), we can rely on HNP to identify the session state. > > > > > > > HNP is dynamically generated. Initially, a MN may not have been > > allocated any HNP, in that we have to send the MN identity for the = LMA > > to apply the proper policy checks and allocate a prefix. > > After that point, when the mobile moves to a new MAG, the MAG on the > > link would likely authenticate the MN, obtain its id before it = allows > > the MN for network access. So, most likely the new MAG would know = the > > MN id as supposed to knowing its allocated prefix, that may be in = the > > BCE state (unless statically configured in AAA). > > > > Generally, I can see 3775 HA, identifying a MN with its HoA and so = not > > requiring the id in the signaling messages. But, in a proxy model in > > combination with dynamic prefix allocation, is it not reasonable to > > carry an identifier of the mobile node in the messages ? Thats the > > stable identifier of the mobile node. > > Its definetly more stable than an allocated prefix. The MAG may > > authenticate the mobile node on the access link and will mo t likely > > have some form of identifier, as supposed to it knowing the prefix > > that is allocated by the LMA. Id is also required for billing = purposes > > as well and may very well be the corelation id. > > > > I do not think, we introduced this id requirement, just with one > > scenario in mind. Its a very natural requirement and the information > > is there on the MAG. Do not know, why this would be an issue for = WiMAX > > case. > > > > Sri > > > > > > > > > > > > > > > > > There are several good reasons to mandate the presence of > > > MN-ID in the > > > > PBU/PBA. For example, it helps to identify the session > > > state in the LMA > > > > for PMIP6 - MIP6 transition scenarios, when the LMA is > > > collocated with a > > > > MIP6 HA. > > > > > > Can you elaborate on this scenario? You may have something here, = but > > > I need to understand. > > > > > > Alper > > > > > > > > > > Note that during IKEv2 exchange for MIP6, the IDi field (that > > > > carries the same MN-ID) in the IKE packets help identify the > > > > ongoing > > > > (PMIP6) session related to the MN. > > > > > > > > Hope this helps. > > > > > > > > -Kuntal > > > > > > > > > > > > > -----Original Message----- > > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > > > To: 'Sri Gundavelli' > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > > > Sri, > > > > > > > > > > > At handoff, nMAG may not know the HNP of the mobile > > > node. How does > > > > it > > > > > > communicate with the LMA about the MN, if MN-Id is not > > > used ? That's > > > > > > is essential, its required in BCE and also in signaling > > > messages. > > > > > > > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > > > > > >>> Is it for the sake of identifying the MN during dynamic = HNP > > > > > >>> assignment in-band with PMIP? > > > > > > > > > > > > > > > HNP can be assigned during network access authentication. I > > > > > can't > > > > imagine > > > > > when this is not possible or desirable. > > > > > > > > > > That's why mandating presence of MN-id that identifies > > > the MN is not > > > > > necessary, imo. > > > > > > > > > > If people can show a reason why we must also support HNP > > > assignment > > > > in- > > > > > band > > > > > with PMIP, we can say: > > > > > > > > > > When the HNP in PBU has the value 0::/0, an NAI [RFC4283] > that > > > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > >> Sri > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>> -----Original Message----- > > > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > > > >>> To: netlmm@ietf.org > > > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > > > >>> > > > > > > >>> What's the significance of MN-Identifier as carried in = PBU? > > > > > > >>> > > > > > > >>> Is it for the sake of identifying the MN during dynamic > > > > > > >>> HNP > > > > > assignment > > > > > > >>> in-band with PMIP? > > > > > > >>> > > > > > > >>> If so, given that the HNP may also be assigned > > > during network > > > > access > > > > > > >>> authentication (out-of band with PMIP, as commonly done = in > > > > > integrated > > > > > > >>> bootstrapping scenarios), we shall not mandate that the > > > > > > >>> MN- > > > > > identifier > > > > > > >>> identifies the real MN. > > > > > > >>> > > > > > > >>> Another way of using of MN-identifier is to identify the > > > > > > >>> "proxy MN" (MAG) with RFC 4285. > > > > > > >>> > > > > > > >>> Alper > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> netlmm mailing list > > > > > > >>> netlmm@ietf.org > > > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > "This email message and any attachments are confidential > > > information of > > > > Starent Networks, Corp. The information transmitted may not > > > be used to > > > > create or change any contractual obligations of Starent > > > Networks, Corp. > > > > Any review, retransmission, dissemination or other use of, > > > or taking of > > > > any action in reliance upon this e-mail and its attachments > > > by persons or > > > > entities other than the intended recipient is prohibited. > > > If you are not > > > > the intended recipient, please notify the sender immediately -- = by > > > > replying to this message or by sending an email to > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > this message > > > > and any attachments without reading or disclosing their > > > contents. Thank > > > > you." >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 07:12:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVQ9L-0003o7-2p; Wed, 12 Sep 2007 07:12:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVQ9J-0003o2-C9 for netlmm@ietf.org; Wed, 12 Sep 2007 07:12:49 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVQ9I-00048e-28 for netlmm@ietf.org; Wed, 12 Sep 2007 07:12:49 -0400 Received: by ug-out-1314.google.com with SMTP id u2so616684uge for ; Wed, 12 Sep 2007 04:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=mfvouda/S3J7nje66pltQKRi0lfmIyhD0V6rUwubOwY=; b=VshUCiB1SjJJDvIk3o+RjiJetYqIXPvLEHLSTrsu13fZyxLpNsy2/cXy5ypwtcd9ONXOxNm8ABPmgExyxcx3Fs+BK00Ebki964LNZ3c32svOZU4L+fsNaNAJwBj/qRoIOpKCmv+k4hj8a4Fgq31OM6MvN6Mpr20/+Nks9p2BaPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=fAHA7NrkcHmNTatw1UyqKmBpaxz3tdZKxdFf+4HjqaO/Th4qNKwfEk14rJc1v6W7GfTpGZtyXSrTZEIru+csnjJoC/dKaY6Jlcg0mAzZhGqx/7VUmgWQ6w6h4v3Ne6G4JSoji3tz+dTodmAsWv5t8M84l9+TD3zorZfcSyc22Os= Received: by 10.67.16.9 with SMTP id t9mr1738713ugi.1189595566918; Wed, 12 Sep 2007 04:12:46 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id b39sm2659182ugf.2007.09.12.04.12.44 (version=SSLv3 cipher=OTHER); Wed, 12 Sep 2007 04:12:45 -0700 (PDT) From: Julien Laganier To: "Sri Gundavelli" Subject: Re: [netlmm] DNAv6/SEND and timestamp synchronization problems Date: Wed, 12 Sep 2007 13:12:41 +0200 User-Agent: KMail/1.9.6 References: <200709111620.02475.julien.IETF@laposte.net> <000d01c7f50e$9bf6f9b0$d5f6200a@amer.cisco.com> In-Reply-To: <000d01c7f50e$9bf6f9b0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709121312.41422.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, On Wednesday 12 September 2007, Sri Gundavelli wrote: > Hi Julien, > > > -----Original Message----- > > From: Julien Laganier [mailto:julien.IETF@laposte.net] > > Sent: Tuesday, September 11, 2007 7:20 AM > > To: netlmm@ietf.org > > Subject: [netlmm] DNAv6/SEND and timestamp synchronization problems > > > > Folks, > > > > It has been discussed on the mailing list that synchronizing > > time across > > different MAGs to allow reordering of pBUs might be a problem. > > While thinking about the issue I got the idea to leverage on SEND > > to solve that issue. > > > > When the MN uses DNAv6 for movement detection along with SEND > > to secure > > ND signaling (which includes DNAv6), all ND messages sent by the MN > > will contain a timestamp representing the local time on the MN. > > Thus, all MAGs to which a given MN attached to have access to a > > single per-MN > > timestamp source. > > Good idea ! Glad you like it. > Will this require the RS as the only trigger for PMIP signaling ? Not necessarily. > Currently, any network attachment event or auth completion event > can be used by the MAG as a trigger to start the PMIP signaling. > This change requires the timestamp in PMIP message and that can > come only in ND messages from the MN. It is true that the methods requires the AR to receive a SEND-protected ND messages from the MN to get the SEND Timestamp. However the trigger to PMIP could still be something else (e.g. L2 link-up indication), while the timestamp to fill-in the pBU would still come from SEND, provided that the AR gets such a SEND-protected ND message from the MN. The AR can get a SEND-protected ND message from the MN in the following cases: - the MN has DNAv6 support and sends to all-routers a SEND-protected RA. - the AR gets to know a link-local IPv6 address of the MN (e.g. because the MN does DAD for the link-local, or via the AR sending a MLDv2 general query and getting a reply sourced from the MN link local, etc.) and can solicit that link local address with a NS, and will get a SEND-protected NA. > Other comment is from the deployment perspective, do you think, > we can expect operators to put DNAv6 in the handsets, right away ? > That will be a factor as well. I don't think DNAv6 is necessary per se. The requirements are that the MN and MAG supports SEND and that the AR receives a SEND-protected ND message from the MN. The latter doesn't necessarily requires DNAv6, as explained above. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 07:20:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVQHB-00026x-PB; Wed, 12 Sep 2007 07:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVQHA-00026s-VY for netlmm@ietf.org; Wed, 12 Sep 2007 07:20:56 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVQH9-0004H0-Cs for netlmm@ietf.org; Wed, 12 Sep 2007 07:20:56 -0400 Received: by ug-out-1314.google.com with SMTP id u2so618155uge for ; Wed, 12 Sep 2007 04:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=zQozHUdkJEOCYPB/5We9JKnrZ1huWYKesp2O25sFkOA=; b=Vyqq9Fs1s0VeQrLlFK/WVJEPjnZ5lU2BBL0R1MYn0Lm8q3HBedhBLaVoVON9tNfL9kq2yVk0YQvudzMUwavZqceGRFIBY8/gx7e0mq2BDrBlaPsJ9sWcIA2CH48Xn4b22Sa4lHi1AudGqhCuqS+SGCbAS1Eer8XS+8/YbmpJFP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=UtENzIHEXP8PFMawm94yCBPME61I9DGmdG1rb/2GQZaYM3Y4B7G87FROgUOYUVF7nh7MMku+DPHn/AkbokbVd35sJbFbAhAYoUsX6NRDeNNL9kKziGaq335dJYoBPDXVEEbGMZ80Lc7jddhnL3kZIgU9Yg6HJyX6zsd1eM2YTQc= Received: by 10.66.242.5 with SMTP id p5mr1761978ugh.1189596054541; Wed, 12 Sep 2007 04:20:54 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id b35sm2656753ugd.2007.09.12.04.20.53 (version=SSLv3 cipher=OTHER); Wed, 12 Sep 2007 04:20:53 -0700 (PDT) From: Julien Laganier To: "DE JUAN HUARTE FEDERICO" Subject: Re: [netlmm] DNAv6/SEND and timestamp synchronization problems Date: Wed, 12 Sep 2007 13:20:50 +0200 User-Agent: KMail/1.9.6 References: <200709111620.02475.julien.IETF@laposte.net> <319D54578EAC3147BA8CC78DAB5467A501399A2D@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A2D@FRVELSMBS12.ad2.ad.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709121320.50726.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, On Wednesday 12 September 2007, DE JUAN HUARTE FEDERICO wrote: > Hi Julien, > > the concept looks good to me, but only useful when SEND is present > I'm not uptodate with SEND, may I ask a pointer to this protocol? Right: RFC3971 > In my opinion in order to enable this solution, there should also be > the following requirements/constraints: > - Each BU should be preceded by a SEND message: this phrasing is > intentional to cover not only the scenario of "HO from pMAG to nMAG" > (which seems to be the one that everybody has in mind) but also the > scenario of "lifetime expiration" (thus BU refresh) That could also be phrased as: When both the MAG and the MN supports SEND, the MAG MAY use a pBU timestamp obtained from ND signalling issued by the MN. In such case, sending a pBU MUST be preceded by obtention of fresh SEND-protected ND message from the MN. > - The number of MAGs to which the MN is associated should be > constrained to only 1: if the MN can be connected to pMAG and nMAG > concurrently (from SEND point of view), then avoiding race conditions > in PMIP HO would become more complex The race condition problem occuring from simultaneous connexion at two MAGs cannot be defeated by timestamping alone, and is not specific to this SEND method. The only way to defeat such race conditions is that the MN can't be attached to more than one MAG, and a MAG must not send pBU when a MN is not attached. Otherwise it's not going to work, timestamps or not. > A final comment is that the idea could be generalized to allow using > a sequence number or a timestamp generated by the MN whenever there's > a protocol (e.g. SEND) which is guaranteed to be executed before > sending a BU Yeah, I thought about that generalization, but could not find examples of appropriate MN-generated sequence numbers. For example, it is possible that an L2 sequence number is reset or randomized after each L2 attachment, making it useless for the purpose of ordering pBUs. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 08:15:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVR82-0004My-Qv; Wed, 12 Sep 2007 08:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVR81-0004Ms-B8 for netlmm@ietf.org; Wed, 12 Sep 2007 08:15:33 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVR7z-0005C7-RA for netlmm@ietf.org; Wed, 12 Sep 2007 08:15:33 -0400 Received: from rly16b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly16b.srv.mailcontrol.com (MailControl) with ESMTP id l8CCFDqk023995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Sep 2007 13:15:28 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly16b.srv.mailcontrol.com (MailControl) id l8CCENCV018985 for netlmm@ietf.org; Wed, 12 Sep 2007 13:14:23 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly16b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8CCEMXu018748; Wed, 12 Sep 2007 13:14:23 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 39f1_e42823e0_6128_11dc_9f93_0030482aac25; Wed, 12 Sep 2007 14:08:36 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091214141779-128625 ; Wed, 12 Sep 2007 14:14:17 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.102,BAYES_00: -1.665,TOTAL_SCORE: -1.563 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 12 Sep 2007 14:14:46 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] DNAv6/SEND and timestamp synchronization problems In-Reply-To: <200709121320.50726.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] DNAv6/SEND and timestamp synchronization problems Thread-Index: Acf1LxWgX4Va/7p8QmSCT4VnDZEVKwAA1U4w References: <200709111620.02475.julien.IETF@laposte.net><319D54578EAC3147BA8CC78DAB5467A501399A2D@FRVELSMBS12.ad2.ad.alcatel.com> <200709121320.50726.julien.IETF@laposte.net> To: "Julien Laganier" , "DE JUAN HUARTE FEDERICO" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48AB5D@lan-ex-02.panasonic.de> Date: Wed, 12 Sep 2007 14:13:58 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.66.1.126 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien,=20 I like your idea of utilizing a timestamp or sequence number maintained by the MN for re-ordering PBU msgs.=20 > > A final comment is that the idea could be generalized to allow using > > a sequence number or a timestamp generated by the MN=20 > whenever there's > > a protocol (e.g. SEND) which is guaranteed to be executed before > > sending a BU >=20 > Yeah, I thought about that generalization, but could not find=20 > examples=20 > of appropriate MN-generated sequence numbers. For example, it is=20 > possible that an L2 sequence number is reset or randomized after each=20 > L2 attachment, making it useless for the purpose of ordering pBUs. Yes, generalization would be nice.=20 L2 sequence number would be one option, but as you said this may not always work. Any other? How about the EAP Identifier? At least the spec could say that if there is a MN-generated sequence number or timestamp available at the MN that is maintained across MAG attachements (i.e., not reset or randomized after each attachement) and signaled to the network at least after each MAG attachement, this sequence number/timestamp can be used in PBUs even if no context transfer is available. SeND is one example. BR, Kilian Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 08:29:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVRL4-00007X-Mc; Wed, 12 Sep 2007 08:29:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVRL2-00007R-RY for netlmm@ietf.org; Wed, 12 Sep 2007 08:29:00 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVRL1-0001oq-Nf for netlmm@ietf.org; Wed, 12 Sep 2007 08:29:00 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id l8CCSuS7007194; Wed, 12 Sep 2007 14:28:56 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8CCStlw028211; Wed, 12 Sep 2007 14:28:56 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Sep 2007 14:28:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Wed, 12 Sep 2007 14:28:53 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> In-Reply-To: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Thread-Index: Acf0Pq9T2NcAJj3HRZ+zuMUIF+h8RAAABK8AADdSTuA= References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> From: "Premec, Domagoj" To: "Sri Gundavelli" X-OriginalArrivalTime: 12 Sep 2007 12:28:55.0512 (UTC) FILETIME=[7C437D80:01C7F538] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070912142856-0B32CBB0-2A3ECFA6/0-0/0-15 X-purgate-size: 7565/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, A couple of comments... section 5.3 > o The local mobility anchor MUST ignore the check, specified in > Section 10.3.1 [RFC-3775], related to the presence of Home = Address > destination option in the Proxy Binding Update request. For the sake of completness, the draft should also state that the MAG = shall not add the Home address destination option to the PBU. Otherwise, = the compliant MAG would still be free to put it into the PBU. section 5.5.1 > Implementations MAY choose to use static > tunnels as supposed to dynamically creating and tearing them down > on a need basis. typo, s/as supposed/as opposed/ >6.3. Supported Access Link Types > > This specification supports only point-to-point access link types = and > thus it assumes that the mobile node and the mobile access gateway > are the only two nodes on the access link. The link is assumed to > have multicast capability. I understand that the decision to use per-MN prefix model was motivated = by the need to emulate the point-to-point link at the IP layer. As the = IP layer is configured in such a way that there are exactly two nodes on = the link, we're actually independet of the underlaying link layer = technology. I think the intent of the spec is to support any access link = type, including for example 802.11. The first sentence, claiming support = only for point-to-point link types, is too restrictive. Maybe it could = be reformulated to make it clear that point-to-point property is = realized at the IP layer. section 6.4 > However, > the advertised flags with respect the address configuration will be typo: add "to" between "respect" and "the address" section 6.14 > Upon obtaining the mobile node's profile after a successful access > authentication and after a policy consideration, the mobile access > gateway MUST determine if the network based mobility service should > be offered to that mobile node.=20 This sounds like the MAG looks only at MN's profile and policy to = determine the mobility mode of the MN. Looking at the MN's profile only = is too restrictive, the user can change his terminal or update it with a = MIP implementation and might prefere to use client based MIP. So I think = the language hier should keep the door open for deciding about the MN's = mobility mode in a more dynamic manner. The MAG could learn about the = MN's capabilities and preferences through link-layer or some future = enhancements at the IP layer. Would it be possible to add following = sentence at the end of the cited paragraph: "The MAG's decision can be influenced by the mobile node's MIP = capabilities and preferences. The MAG may learn about the MN's = capabilites and preferences through link-layer exchange or by some other = means out of the scope of this specificaton." section 7.3 > [...] the newly learnt default-router > as supposed to the previously known default-router. typo: s/as supposed/as opposed/ section 7.3 > There are other solutions possible for this problem, including the > assignment of a unique link-local address for all the mobile access > gateways [...] IMO "same link-local address" instead of "unique link-local address" = would be more clear. domagoj > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: 11. rujan 2007 08:44 > To: 'netlmm' > Subject: FW: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt=20 >=20 > A new revision of the Proxy Mobile IPv6 draft, based on the=20 > inpiuts received ... >=20 >=20 > Change log: >=20 > - Text related to allowing alternate security mechanisms for > protecting PMIP6 signaling messages (WG discussion) >=20 > - Retransmissions (Shyam's comments) >=20 > - Seq diagram for handoff.=20 >=20 > - Fixed the idnits warnings. >=20 > - References to 4283 NAI option (Genadi's comments) >=20 > - Minor editorial >=20 >=20 > Should close all the open issues in the issue tracker. >=20 > Please comment on any issues or nits. >=20 > Thanks > Sri >=20 >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Monday, September 10, 2007 11:40 PM > > To: i-d-announce@ietf.org > > Cc: netlmm@ietf.org > > Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > This draft is a work item of the Network-based Localized Mobility=20 > > Management Working Group of the IETF. > >=20 > >=20 > > Title : Proxy Mobile IPv6 > > Author(s) : S. Gundavelli, et al. > > Filename : draft-ietf-netlmm-proxymip6-04.txt > > Pages : 57 > > Date : 2007-09-11 > >=20 > > This specification describes a network-based mobility management=20 > > protocol. It is called Proxy Mobile IPv6 and is based on=20 > Mobile IPv6=20 > > [RFC-3775]. This protocol enables mobility support to a=20 > host without=20 > > requiring its participation in any mobility related signaling. The=20 > > design principle in the case of network-based mobility management=20 > > protocol relies on the network being in control of the mobility=20 > > management. The mobility entities in the network are=20 > responsible for=20 > > tracking the movements of the host and initiating the required=20 > > mobility signaling on its behalf. > >=20 > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-04.txt > >=20 > > To remove yourself from the I-D Announcement list, send a=20 > message to=20 > > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > > the message. > > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-netlmm-proxymip6-04.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-netlmm-proxymip6-04.txt". > >=20 > > 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=20 > 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. > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 08:40:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVRWb-000289-Su; Wed, 12 Sep 2007 08:40:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVRWa-000281-4M for netlmm@ietf.org; Wed, 12 Sep 2007 08:40:56 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVRWZ-000233-8R for netlmm@ietf.org; Wed, 12 Sep 2007 08:40:56 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8CCeGOv030101; Wed, 12 Sep 2007 14:40:16 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 12 Sep 2007 14:40:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] DNAv6/SEND and timestamp synchronization problems Date: Wed, 12 Sep 2007 14:40:48 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A35@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <200709121320.50726.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] DNAv6/SEND and timestamp synchronization problems Thread-Index: Acf1Lv5Aqj3vf0XPTEmtwpdzmUn8DwABYd/A References: <200709111620.02475.julien.IETF@laposte.net> <319D54578EAC3147BA8CC78DAB5467A501399A2D@FRVELSMBS12.ad2.ad.alcatel.com> <200709121320.50726.julien.IETF@laposte.net> From: "DE JUAN HUARTE FEDERICO" To: "Julien Laganier" X-OriginalArrivalTime: 12 Sep 2007 12:40:52.0943 (UTC) FILETIME=[27E2C5F0:01C7F53A] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien, See inline Regards federico -----Message d'origine----- De : julien laganier [mailto:julien.laganier@gmail.com] De la part de = Julien Laganier Envoy=E9 : mercredi 12 septembre 2007 13:21 =C0 : DE JUAN HUARTE FEDERICO Cc : netlmm@ietf.org Objet : Re: [netlmm] DNAv6/SEND and timestamp synchronization problems Hi Federico, On Wednesday 12 September 2007, DE JUAN HUARTE FEDERICO wrote: > Hi Julien, > > the concept looks good to me, but only useful when SEND is present I'm = > not uptodate with SEND, may I ask a pointer to this protocol? Right: RFC3971 [FDJ] Thanks > In my opinion in order to enable this solution, there should also be=20 > the following requirements/constraints: > - Each BU should be preceded by a SEND message: this phrasing is=20 > intentional to cover not only the scenario of "HO from pMAG to nMAG" > (which seems to be the one that everybody has in mind) but also the=20 > scenario of "lifetime expiration" (thus BU refresh) That could also be phrased as: When both the MAG and the MN supports = SEND, the MAG MAY use a pBU timestamp obtained from ND signalling issued = by the MN. In such case, sending a pBU MUST be preceded by obtention of = fresh SEND-protected ND message from the MN. [FDJ] That's fine > - The number of MAGs to which the MN is associated should be=20 > constrained to only 1: if the MN can be connected to pMAG and nMAG=20 > concurrently (from SEND point of view), then avoiding race conditions=20 > in PMIP HO would become more complex The race condition problem occuring from simultaneous connexion at two = MAGs cannot be defeated by timestamping alone, and is not specific to = this SEND method.=20 [FDJ] Indeed, the race condition problem is not specific to SEND. But I = thought proposing SEND was aimed to address the problem Otherwise, SEND is just another protocol for time synchronization = (instead of NTP) The only way to defeat such race conditions is that the MN can't be = attached to more than one MAG, and a MAG must not send pBU when a MN is = not attached. Otherwise it's not going to work, timestamps or not. [FDJ] Very well described. Only one nuance: with context transfers = there's no race condition problem Is the assumption that we can prevent a MAG to send BU when MN is not = attached? Depending on the deployment, there can be a significant delay between MN = detachment and MAG noticing it > A final comment is that the idea could be generalized to allow using a = > sequence number or a timestamp generated by the MN whenever there's a=20 > protocol (e.g. SEND) which is guaranteed to be executed before sending = > a BU Yeah, I thought about that generalization, but could not find examples = of appropriate MN-generated sequence numbers. For example, it is = possible that an L2 sequence number is reset or randomized after each L2 attachment, making it useless for the purpose of ordering pBUs. [FDJ] A secured L2 wireless interface should support sequence numbers = for replay protection In fact, it looks like SEND proposes timestamps for the sake of replay = protection Personally, I don't think that using timestamp for replay protection is = as secure as using sequence numbers, but that's a different topic --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 09:11:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVS0Z-0001uU-Kd; Wed, 12 Sep 2007 09:11:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVS0X-0001mH-Oj for netlmm@ietf.org; Wed, 12 Sep 2007 09:11:53 -0400 Received: from hu-out-0506.google.com ([72.14.214.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVS0W-0006dR-F7 for netlmm@ietf.org; Wed, 12 Sep 2007 09:11:53 -0400 Received: by hu-out-0506.google.com with SMTP id 31so75637huc for ; Wed, 12 Sep 2007 06:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=wfIij8T/WvQgErHsgj4OCRQVzUJ+7GYkDU8EX5l/MJY=; b=O1jvC5wJ7sMDXuhn7YUDIShvfjUF/scuTn8zjdvHnTE4Q1qPhLF0NEqA+/AuE+cbQZImPRxdg+A0F1FYlrmXuOrhyPl3WMaHOchUbfwtdev6KDHDxQUVLBEDPmBsocvk9rIhRXUfJcHoi5HldIn/Hv5OrgfdClFuUwxjNLk/+Rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=E+eYuDtaFJ7mYC2dpp6ts8vuUO9OBQ5jzYQBz5l0mIPWuliZBGKHr9IIj6vSP05P1XygHuv3oFBj3OK1TiOoM9QZkIHoUIqW4wKEKQeHm7uzTgeVT9iFrYwXvCcbtvB+I3vNOYE+Wn9PVumi/O3ik2FvNd8kx9OgDyPQBPgoZN0= Received: by 10.67.26.7 with SMTP id d7mr1856680ugj.1189602711260; Wed, 12 Sep 2007 06:11:51 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k30sm2806064ugc.2007.09.12.06.11.49 (version=SSLv3 cipher=OTHER); Wed, 12 Sep 2007 06:11:50 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] Re: timestamps description (was: I-D Action:draft-ietf-netlmm-proxymip6-04.txt) Date: Wed, 12 Sep 2007 15:11:47 +0200 User-Agent: KMail/1.9.6 References: <46E6A353.6020302@gmail.com> In-Reply-To: <46E6A353.6020302@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709121511.47389.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, I disagree with part of your comment: On Tuesday 11 September 2007, Alexandru Petrescu wrote: > > > Timestamp > > > > A 64-bit unsigned integer field containing a timestamp. The > > value indicates the number of seconds since January 1, 1970, 00:00 > > UTC, by using a fixed point format. In this format, the integer > > number of seconds is contained in the first 48 bits of the field, > > and the remaining 16 bits indicate the number of 1/64K fractions of > > a second. > > I think it should better say 1/65536 fractions of a second, and not > 1/64K fractions. Let me say why. 64k means 65535 when talking bits > and bytes. If we talk anything else then 64k means 64000 (meters, > seconds, Hertz, Joules, etc.) > > I think we should also say in the draft that the timestamp contains > the number of seconds measured at GMT (or some other place of your > choice) since Jan 1st, 1970, 00h00 UTC. Let me say why. If we don't > say where this timestamp was measured then there are different > timezones on Earth, and a MAG in eg New Delhi will have a different > timestamp than a LMA in Hyderabad, even if they represent the same > moment. UTC means coordinated universal time and is independent of any location. As such, the reference "January 1, 1970, 00:00 UTC" is a universal time value that has the same significance everywhere, independent of the location you're talking about. What goes in the timestamp in time elapsed since that reference (reference is used as an origin) and is thus also independent from the location. Now for PMIPv6 all entities get UTC time and can get appropriate timestamps and no problem happens. (If you are concerned about a MAG which has only access to a clock that gives presentation of time, e.g. the GMT _presentation_, it's up to that MAG to translate GMT to UTC.) In summary there's IMHO no need for additional text in the spec. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 09:16:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVS5O-0005Kd-VF; Wed, 12 Sep 2007 09:16:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVS5O-0005KX-DR for netlmm@ietf.org; Wed, 12 Sep 2007 09:16:54 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVS5N-0006mQ-65 for netlmm@ietf.org; Wed, 12 Sep 2007 09:16:54 -0400 Received: by ug-out-1314.google.com with SMTP id u2so660382uge for ; Wed, 12 Sep 2007 06:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=aWe5Bg3/2DPQy3aZyGHvC5oxITV910zPpC0Y3PTvjvs=; b=r9/o1ci2jjiVJYRSqdKfb+i6YRSqDACe7pUpet8AYDnP9PzmTlx1iK4Rbr8BtftzIOfLakM9wzSKn0YpOYw0rZOMW7awSjnFYbgklEhU6ggqcs3jruGtAiPihmi5Rxy9/rQ+kroF5mYQcF+2qtZypc1uT4JMFXnFiGHDeYTr6pM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Rnmbxy1w4hZpWQwxrwRuLLkPSV46GsDMqse2CBjp8JOclRVIDEaK0PNeR6aQIXe2TFjFqHJGF89B2cOpjtBSvnHU4QHXIRnFftUgPRpy6lR8NuywD1+vs+C1RaCbsC8GgEb7sxOgV9ynRvu4PXtlOqwRGYowDhoMRLUr5g2PxYo= Received: by 10.66.219.2 with SMTP id r2mr1834292ugg.1189603012320; Wed, 12 Sep 2007 06:16:52 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id b23sm2809495ugd.2007.09.12.06.16.50 (version=SSLv3 cipher=OTHER); Wed, 12 Sep 2007 06:16:51 -0700 (PDT) From: Julien Laganier To: "Kilian Weniger" Subject: Re: [netlmm] DNAv6/SEND and timestamp synchronization problems Date: Wed, 12 Sep 2007 15:16:47 +0200 User-Agent: KMail/1.9.6 References: <200709111620.02475.julien.IETF@laposte.net> <200709121320.50726.julien.IETF@laposte.net> <1FEB9B9F2EC38343955D02B2AE86AACB48AB5D@lan-ex-02.panasonic.de> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48AB5D@lan-ex-02.panasonic.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709121516.47793.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Wednesday 12 September 2007, Kilian Weniger wrote: > Hi Julien, > > I like your idea of utilizing a timestamp or sequence number > maintained by the MN for re-ordering PBU msgs. > > > > A final comment is that the idea could be generalized to allow > > > using a sequence number or a timestamp generated by the MN > > > whenever there's a protocol (e.g. SEND) which is guaranteed to be > > > executed before sending a BU > > > > Yeah, I thought about that generalization, but could not find > > examples of appropriate MN-generated sequence numbers. For example, > > it is possible that an L2 sequence number is reset or randomized > > after each L2 attachment, making it useless for the purpose of > > ordering pBUs. > > Yes, generalization would be nice. > > L2 sequence number would be one option, but as you said this may not > always work. Any other? How about the EAP Identifier? EAP does not require the Identifier to be monotonically increasing. And EAP will presumably be reset after each handover when no context transfer mechanism is present. Right know I can't think of any such identifier at L2 since they will most likely be reset/randomized on handover. At L3 we have only SEND timestamps AFAICS. > At least the spec could say that if there is a MN-generated sequence > number or timestamp available at the MN that is maintained across MAG > attachements (i.e., not reset or randomized after each attachement) > and signaled to the network at least after each MAG attachement, this > sequence number/timestamp can be used in PBUs even if no context > transfer is available. SeND is one example. Agree. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 09:41:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVST1-00031h-DV; Wed, 12 Sep 2007 09:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVSSz-0002rr-VC for netlmm@ietf.org; Wed, 12 Sep 2007 09:41:17 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVSSy-0007H1-Pe for netlmm@ietf.org; Wed, 12 Sep 2007 09:41:17 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1189604475!26254058!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2987 invoked from network); 12 Sep 2007 13:41:16 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 12 Sep 2007 13:41:16 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8CDfFug024807; Wed, 12 Sep 2007 06:41:15 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8CDfFqa004740; Wed, 12 Sep 2007 08:41:15 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8CDfDeP004665; Wed, 12 Sep 2007 08:41:14 -0500 (CDT) Message-ID: <46E7EC75.6050602@gmail.com> Date: Wed, 12 Sep 2007 15:41:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Re: timestamps description References: <46E6A353.6020302@gmail.com> <200709121511.47389.julien.IETF@laposte.net> In-Reply-To: <200709121511.47389.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-3, 11/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > Hi Alex, > > I disagree with part of your comment: > > On Tuesday 11 September 2007, Alexandru Petrescu wrote: >>> Timestamp >>> >>> A 64-bit unsigned integer field containing a timestamp. The >>> value indicates the number of seconds since January 1, 1970, >>> 00:00 UTC, by using a fixed point format. In this format, the >>> integer number of seconds is contained in the first 48 bits of >>> the field, and the remaining 16 bits indicate the number of 1/64K >>> fractions of a second. >> I think it should better say 1/65536 fractions of a second, and not >> 1/64K fractions. Let me say why. 64k means 65535 when talking >> bits and bytes. If we talk anything else then 64k means 64000 >> (meters, seconds, Hertz, Joules, etc.) >> >> I think we should also say in the draft that the timestamp contains >> the number of seconds measured at GMT (or some other place of your >> choice) since Jan 1st, 1970, 00h00 UTC. Let me say why. If we >> don't say where this timestamp was measured then there are >> different timezones on Earth, and a MAG in eg New Delhi will have a >> different timestamp than a LMA in Hyderabad, even if they represent >> the same moment. > > UTC means coordinated universal time and is independent of any > location. As such, the reference "January 1, 1970, 00:00 UTC" is a > universal time value that has the same significance everywhere, Right. In this perspective I think I was wrong. > independent of the location you're talking about. What goes in the > timestamp in time elapsed since that reference (reference is used as > an origin) and is thus also independent from the location. > > Now for PMIPv6 all entities get UTC time and can get appropriate > timestamps and no problem happens. Are you sure that all entities can get UTC time? In a reliable manner? This is actually a requirement you put on these entities: use time in this and that manner. > (If you are concerned about a MAG which has only access to a clock > that gives presentation of time, e.g. the GMT _presentation_, it's up > to that MAG to translate GMT to UTC.) (Isn't GMT and UTC the same?) I think you rely too much on requirements you can write in a spec. "It's up to that MAG to translate X-time to Y-time"? I don't think we can write in a PMIP spec what entities should do with respect to time... > In summary there's IMHO no need for additional text in the spec. Err... I think you are right on this. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 09:44:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVSW2-0005PZ-5N; Wed, 12 Sep 2007 09:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVSVw-0005PK-Fk for netlmm@ietf.org; Wed, 12 Sep 2007 09:44:20 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVSVv-0007Jk-4z for netlmm@ietf.org; Wed, 12 Sep 2007 09:44:20 -0400 Received: by ug-out-1314.google.com with SMTP id u2so677166uge for ; Wed, 12 Sep 2007 06:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=UUH58jroiBPPCwbUilKEd+pwaA4sp4m7YiR9N8Mi8IQ=; b=fJa+kjqBwTHUJfr6Q/txiev+h9xB2gBAnzCuI4v47jWcJ0WTclYSWssgtd7LwT8O+eQ1j2cDiqoz0oYCHn+zH39UvCWXu/c7mrbhkk2QZURsVjqkIGhCzdD+/QVOALaWhMtbDVqoHdn6YpyeYO+Fe1Ltz2rM5syUOklURMqilTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=qB4acMpZt6aHW0CbyL/oEXA0vWIaIPTqLgz5abCEi/5wmP+4AoJyavDqIGblewWNLnX88G2RTb7DGvxcbeIEcLdxDdjxyV+6Q/Q6ywYqbgNDOSZZOkNbUWNAwQwtTRVREFDMCjeOSa36AwzDCsrSHjmsjn41p0RaiZ+ntksfYOs= Received: by 10.67.30.13 with SMTP id h13mr1873333ugj.1189604658383; Wed, 12 Sep 2007 06:44:18 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e1sm2868127ugf.2007.09.12.06.44.16 (version=SSLv3 cipher=OTHER); Wed, 12 Sep 2007 06:44:17 -0700 (PDT) From: Julien Laganier To: "DE JUAN HUARTE FEDERICO" Subject: Re: [netlmm] DNAv6/SEND and timestamp synchronization problems Date: Wed, 12 Sep 2007 15:44:13 +0200 User-Agent: KMail/1.9.6 References: <200709111620.02475.julien.IETF@laposte.net> <200709121320.50726.julien.IETF@laposte.net> <319D54578EAC3147BA8CC78DAB5467A501399A35@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A35@FRVELSMBS12.ad2.ad.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709121544.14013.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Federico, On Wednesday 12 September 2007, DE JUAN HUARTE FEDERICO wrote: > Julien, > > See inline Ditto, > Julien Laganier wrote: > > [...] > > > In my opinion in order to enable this solution, there should also > > > be the following requirements/constraints: > > > > > > - Each BU should be preceded by a SEND message: this phrasing is > > > intentional to cover not only the scenario of "HO from pMAG to > > > nMAG" (which seems to be the one that everybody has in mind) but > > > also the scenario of "lifetime expiration" (thus BU refresh) > > > > That could also be phrased as: When both the MAG and the MN > > supports SEND, the MAG MAY use a pBU timestamp obtained from ND > > signalling issued by the MN. In such case, sending a pBU MUST be > > preceded by obtention of fresh SEND-protected ND message from the > > MN. > > That's fine > > > > - The number of MAGs to which the MN is associated should be > > > constrained to only 1: if the MN can be connected to pMAG and > > > nMAG concurrently (from SEND point of view), then avoiding race > > > conditions in PMIP HO would become more complex > > > > The race condition problem occuring from simultaneous connexion at > > two MAGs cannot be defeated by timestamping alone, and is not > > specific to this SEND method. > > Indeed, the race condition problem is not specific to SEND. But I > thought proposing SEND was aimed to address the problem. Otherwise, > SEND is just another protocol for time synchronization (instead of > NTP) Simultaneous attachments to different MAGs causes issues with PMIPv6 which are outside the scope of this specification. The problem cannot be addressed without protocol extensions. > > The only way to defeat such race conditions is that the MN can't be > > attached to more than one MAG, and a MAG must not send pBU when a > > MN is not attached. Otherwise it's not going to work, timestamps or > > not. > > Very well described. Only one nuance: with context transfers there's > no race condition problem. With context transfer you would in effect prevent attachment to more than two MAGs. > Is the assumption that we can prevent a MAG to send BU when MN is not > attached? At least I have been making that assumption. > Depending on the deployment, there can be a significant delay between > MN detachment and MAG noticing it If a MAG always test reachability of the MN before extending an existing binding (i.e. beyond initial registration) there we would have no problem. Maybe we should complete that part of Section 6.9.1.: > Binding Re-Registration: > > o For extending the lifetime of a currently existing binding at > the local mobility, the mobile access gateway MUST send a Proxy > Binding Update message to the local mobility anchor. The prefix > value in the Home Network Prefix option present in the request SHOULD > be set to the currently registered home network prefix and the value > in the Link-local Address option may be set to ALL_ZERO or to the > link-local address of the mobile node. with this sentence "the MAG MUST make sure the MN is still attached to it before extending the lifetime of an existing binding. That MAY be done by using Neighbor Unreachibility Detection (i.e. an NS/NA exchange.)" That could also be included in the MN-MAG interface draft (draft-ietf-netlmm-mn-ar) via inclusion of a new method MAG_TEST_MN_REACHABILITY. > > > A final comment is that the idea could be generalized to allow > > > using a sequence number or a timestamp generated by the MN > > > whenever there's a protocol (e.g. SEND) which is guaranteed to be > > > executed before sending a BU > > > > Yeah, I thought about that generalization, but could not find > > examples of appropriate MN-generated sequence numbers. For example, > > it is possible that an L2 sequence number is reset or randomized > > after each L2 attachment, making it useless for the purpose of > > ordering pBUs. > > A secured L2 wireless interface should support sequence numbers for > replay protection In fact, it looks like SEND proposes timestamps for > the sake of replay protection Personally, I don't think that using > timestamp for replay protection is as secure as using sequence > numbers, but that's a different topic. Yes, that's a difference topic. Anyway for the record, SEND deals with security of signaling that are not always request/response, hence making it impossible to use Nonces, or to initialy synchronize a sequence number. That's why a timestamp is included to provide reduced, but still useful security. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 09:51:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVScq-0004qo-23; Wed, 12 Sep 2007 09:51:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVSco-0004qh-UQ for netlmm@ietf.org; Wed, 12 Sep 2007 09:51:27 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVScn-0004D3-0T for netlmm@ietf.org; Wed, 12 Sep 2007 09:51:26 -0400 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8CDon10007479; Wed, 12 Sep 2007 15:50:49 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 12 Sep 2007 15:51:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Significance of MN-Identifier Date: Wed, 12 Sep 2007 15:51:22 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A38@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <0MKpCa-1IVPds0DzV-0007Xr@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Significance of MN-Identifier Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZgAATcTHAAA9ENQAAAa5AgAAXimcA= References: <319D54578EAC3147BA8CC78DAB5467A501399A32@FRVELSMBS12.ad2.ad.alcatel.com> <0MKpCa-1IVPds0DzV-0007Xr@mrelay.perfora.net> From: "DE JUAN HUARTE FEDERICO" To: "Alper Yegin" X-OriginalArrivalTime: 12 Sep 2007 13:51:23.0033 (UTC) FILETIME=[01374890:01C7F544] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, OK (minor comments inline) Regards federico -----Message d'origine----- De : Alper Yegin [mailto:alper.yegin@yegin.org]=20 Envoy=E9 : mercredi 12 septembre 2007 12:40 =C0 : DE JUAN HUARTE FEDERICO Cc : netlmm@ietf.org; 'Sri Gundavelli'; 'Chowdhury, Kuntal' Objet : RE: [netlmm] Significance of MN-Identifier Hi Federico, > for my information, I guess that the following assumptions are needed=20 > (at > least) to enable the solution you mention: > - in order to identify the MN with the HNP you're assuming per-MN=20 > HNP model Yes.=20 [FDJ] OK That's the case with the base PMIP6 spec anyways. [FDJ] That's what it says in the main body (5.2), indeed Then, there's shared model in the annex > - in a per-MN HNP model, the HNP will have to be longer than 64=20 > bits Am I right? Why is that so? [FDJ] What I had in mind was waste of IP@, but I guess this is arguable Anyway, it's not specific to this thread Alper >=20 > Regards >=20 > federico >=20 >=20 >=20 > -----Message d'origine----- > De : Alper Yegin [mailto:alper.yegin@yegin.org] Envoy=E9 : mercredi 12 = > septembre 2007 10:42 =C0 : 'Sri Gundavelli'; 'Chowdhury, Kuntal' > Cc : netlmm@ietf.org > Objet : RE: [netlmm] Significance of MN-Identifier >=20 > Sri, >=20 > You are explaining how carrying some identifier representing the MN is = > useful. Not explaining why "it MUST always be carried". >=20 > My point is two-fold: >=20 > - There is one very strong case that the HNP is allocated as part of=20 > the network access authentication. In that case, we don't have to rely = > on "some identifier representing the MN", instead HNP is already bound = > to the MN. HNP becomes that identifier. >=20 > - Use of RFC 4285 with MAG-LMA SA is one of the possible security = models. > And that requires carrying the "MAG id" in the NAI. Assuming the NAI=20 > always carries some "MN id" as the current spec does is disallowing=20 > this possibility. >=20 > My proposal is to relax that language so that NAI is not "always"=20 > supposed to carry a "MN id". Specific exception case is when the MN is = > already assigned a HNP by an out-of band mechanisms. >=20 > Alper >=20 >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Wednesday, September 12, 2007 9:29 AM > > To: 'Alper Yegin'; 'Chowdhury, Kuntal' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > Hi Alper, > > > > > > > -----Original Message----- > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > Sent: Tuesday, September 11, 2007 2:08 PM > > > To: 'Chowdhury, Kuntal'; 'Sri Gundavelli' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > Hi Kuntal, > > > > > > > I don't know what the issue is for MN-ID in the PMIP6 signaling=20 > > > > messages. Could you explain why we are having this debate? > > > > > > Because, the current text is locking all PMIP6 deployments to one=20 > > > security model and not leaving any room for using anything else.=20 > > > And it is doing so without a good reason (unintentionally, I = believe). > > > > > > > MN-ID is the unique identifier to identify the session > > > state in the LMA. > > > > > > It is necessary only of the MN does not know its HNP. As soon as=20 > > > it knows the HNP (e.g., when HNP is assigned during network access = > > > authentication), we can rely on HNP to identify the session state. > > > > > > > HNP is dynamically generated. Initially, a MN may not have been=20 > > allocated any HNP, in that we have to send the MN identity for the=20 > > LMA to apply the proper policy checks and allocate a prefix. > > After that point, when the mobile moves to a new MAG, the MAG on the = > > link would likely authenticate the MN, obtain its id before it=20 > > allows the MN for network access. So, most likely the new MAG would=20 > > know the MN id as supposed to knowing its allocated prefix, that may = > > be in the BCE state (unless statically configured in AAA). > > > > Generally, I can see 3775 HA, identifying a MN with its HoA and so=20 > > not requiring the id in the signaling messages. But, in a proxy=20 > > model in combination with dynamic prefix allocation, is it not=20 > > reasonable to carry an identifier of the mobile node in the messages = > > ? Thats the stable identifier of the mobile node. > > Its definetly more stable than an allocated prefix. The MAG may=20 > > authenticate the mobile node on the access link and will mo t likely = > > have some form of identifier, as supposed to it knowing the prefix=20 > > that is allocated by the LMA. Id is also required for billing=20 > > purposes as well and may very well be the corelation id. > > > > I do not think, we introduced this id requirement, just with one=20 > > scenario in mind. Its a very natural requirement and the information = > > is there on the MAG. Do not know, why this would be an issue for=20 > > WiMAX case. > > > > Sri > > > > > > > > > > > > > > > > > There are several good reasons to mandate the presence of > > > MN-ID in the > > > > PBU/PBA. For example, it helps to identify the session > > > state in the LMA > > > > for PMIP6 - MIP6 transition scenarios, when the LMA is > > > collocated with a > > > > MIP6 HA. > > > > > > Can you elaborate on this scenario? You may have something here,=20 > > > but I need to understand. > > > > > > Alper > > > > > > > > > > Note that during IKEv2 exchange for MIP6, the IDi field (that=20 > > > > carries the same MN-ID) in the IKE packets help identify the=20 > > > > ongoing > > > > (PMIP6) session related to the MN. > > > > > > > > Hope this helps. > > > > > > > > -Kuntal > > > > > > > > > > > > > -----Original Message----- > > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > > > To: 'Sri Gundavelli' > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > > > Sri, > > > > > > > > > > > At handoff, nMAG may not know the HNP of the mobile > > > node. How does > > > > it > > > > > > communicate with the LMA about the MN, if MN-Id is not > > > used ? That's > > > > > > is essential, its required in BCE and also in signaling > > > messages. > > > > > > > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > > > > > >>> Is it for the sake of identifying the MN during dynamic=20 > > > > > >>> HNP assignment in-band with PMIP? > > > > > > > > > > > > > > > HNP can be assigned during network access authentication. I=20 > > > > > can't > > > > imagine > > > > > when this is not possible or desirable. > > > > > > > > > > That's why mandating presence of MN-id that identifies > > > the MN is not > > > > > necessary, imo. > > > > > > > > > > If people can show a reason why we must also support HNP > > > assignment > > > > in- > > > > > band > > > > > with PMIP, we can say: > > > > > > > > > > When the HNP in PBU has the value 0::/0, an NAI [RFC4283] > that > > > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > >> Sri > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>> -----Original Message----- > > > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > > > >>> To: netlmm@ietf.org > > > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > > > >>> > > > > > > >>> What's the significance of MN-Identifier as carried in = PBU? > > > > > > >>> > > > > > > >>> Is it for the sake of identifying the MN during dynamic=20 > > > > > > >>> HNP > > > > > assignment > > > > > > >>> in-band with PMIP? > > > > > > >>> > > > > > > >>> If so, given that the HNP may also be assigned > > > during network > > > > access > > > > > > >>> authentication (out-of band with PMIP, as commonly done=20 > > > > > > >>> in > > > > > integrated > > > > > > >>> bootstrapping scenarios), we shall not mandate that the > > > > > > >>> MN- > > > > > identifier > > > > > > >>> identifies the real MN. > > > > > > >>> > > > > > > >>> Another way of using of MN-identifier is to identify the = > > > > > > >>> "proxy MN" (MAG) with RFC 4285. > > > > > > >>> > > > > > > >>> Alper > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> netlmm mailing list > > > > > > >>> netlmm@ietf.org > > > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > "This email message and any attachments are confidential > > > information of > > > > Starent Networks, Corp. The information transmitted may not > > > be used to > > > > create or change any contractual obligations of Starent > > > Networks, Corp. > > > > Any review, retransmission, dissemination or other use of, > > > or taking of > > > > any action in reliance upon this e-mail and its attachments > > > by persons or > > > > entities other than the intended recipient is prohibited. > > > If you are not > > > > the intended recipient, please notify the sender immediately --=20 > > > > by replying to this message or by sending an email to=20 > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > this message > > > > and any attachments without reading or disclosing their > > > contents. Thank > > > > you." >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 09:51:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVSct-0004rb-2P; Wed, 12 Sep 2007 09:51:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVScq-0004qz-Vr for netlmm@ietf.org; Wed, 12 Sep 2007 09:51:28 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVScp-0007Tk-9m for netlmm@ietf.org; Wed, 12 Sep 2007 09:51:28 -0400 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8CDomHs007475; Wed, 12 Sep 2007 15:50:48 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 12 Sep 2007 15:51:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Sep 2007 15:51:15 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A37@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HNP length Thread-Index: Acf1Q/zk/G1LNLOHQuGr5NEbOJ+qFQ== From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" X-OriginalArrivalTime: 12 Sep 2007 13:51:22.0814 (UTC) FILETIME=[0115DDE0:01C7F544] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: netlmm@ietf.org Subject: [netlmm] HNP length X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1258651128==" Errors-To: netlmm-bounces@ietf.org This is a multi-part message in MIME format. --===============1258651128== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F544.00BEEF5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F544.00BEEF5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sri, unless I missed it, the PMIP6 v3 I-D is silent about the HNP length. Is it intentional? I'm trying to find out if the HNP can be longer than 64 bits More specifically (avoiding variable length prefixes) is it possible to assign 128-bit HNP (in per-MN HNP model)? The motivation of my question is that I keep on getting contradictory answers in this respect: apparently legacy v6 implementations would not support prefixes longer than 64 bits Thanks federico ------_=_NextPart_001_01C7F544.00BEEF5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HNP length

Hi Sri,

unless I missed it, the PMIP6 v3 = I-D is silent about the HNP length. Is it intentional?

I'm trying to find out if the HNP = can be longer than 64 bits
More specifically (avoiding = variable length prefixes) is it possible to assign 128-bit HNP (in = per-MN HNP model)?

The motivation of my question is = that I keep on getting contradictory answers in this respect: apparently = legacy v6 implementations would not support prefixes longer than 64 = bits

Thanks

federico


------_=_NextPart_001_01C7F544.00BEEF5F-- --===============1258651128== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============1258651128==-- From netlmm-bounces@ietf.org Wed Sep 12 10:58:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVTg1-0001Ww-FC; Wed, 12 Sep 2007 10:58:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVTg0-0001Wr-Hu for netlmm@ietf.org; Wed, 12 Sep 2007 10:58:48 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVTfz-0006Nl-0P for netlmm@ietf.org; Wed, 12 Sep 2007 10:58:48 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8CEwdF17754; Wed, 12 Sep 2007 14:58:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Wed, 12 Sep 2007 09:58:33 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116AF9350@zrc2hxm2.corp.nortel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAMXqxQ References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" , "Sri Gundavelli" , "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian/Federico and All, There has been a lot of email exchange that the timestamp synchronization using the PMIPv6 signaling does not work. On the other hand, I have not seen any in detail analysis which proves that it does not work. I would like to share in details my thoughts on how this SHOULD work and please comment as necessary.=20 The following are a list of assumptions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. The time that the P-BU takes from MAG to LMA equals the time the P-BA takes from LMA to MAG. 2. LMA Timestamp included in the P-BA is the LMA timestamp when comparing timestamp in P-BU and LMA current timestamp. 3. MAG use the difference between the P-BU timestamp and P-BA timestamp for calculating the delta! 4. MAG and LMA maintains the same out of sync delta during the re-synchronization process. MAG LMA ---------- ---------- 1. Current Timestamp MAG.t1 LMA.t1 =3D MAG.t1 +d1 2. Timestamp in P-BU MAG.t1 LMA timestamp: LMA.t1 3. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t1) 4. P-BU arrives at LMA ....................... = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t1) 5. Arrival Timestamp MAG.t1 + d2 LMA.t1 + d2 6. delta based on P-BU timestamp (LMA.t1 + d2) - (MAG.t1) = =3D =20 ((MAG.t1+d1)+d2) - MAG.t1=09 = =3D =20 delta.P-BU =3D d2+d1 7. Real delta delta.real =3D d1 =20 8. Timestamp in P-BA MAG.t2 LMA.t2 =3D (LMA.t1 + d2) =20 P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in corresponding P-BU) =3D (LMA.t1 + d2) - MAG.t1 =3D ((MAG.t1 +d1)+d2) -MAG.t1 =20 delta =3D d1+d2 11. Real delta delta.real =3D d1 What is the problem here? Or am I missing something? Let us examine a re-registration or a P-BU/PA exchange based on the above synchronization: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D MN- Resynchronization/Re-registration: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 12. Current timestamp MAG.t3 LMA.t3 = =3D MAG.t3 + d1 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 14. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t3 + (d2+d1)) 15. P-BU arrives at LMA = .......................=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t3 + (d1+d2)) 16. Arrival Timestamp MAG.t3 + d2 LMA.t3 + d2 17. delta based on P-BU (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) = =3D ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) = =3D delta.P-BU =3D ZERO 18. Real delta delta.real =3D ZERO =20 Please let me know what I am missing. If nothing, I hope we can put an end to this debate and MOVE ON. =09 Regards, Ahmad =20 > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > Sent: Wednesday, September 12, 2007 3:07 AM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Sri,=20 >=20 > please see my comments inline. >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Mittwoch, 12. September 2007 08:14 > > To: 'Kilian Weniger' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Kilian/Federico, > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > To: Sri Gundavelli > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Sri, > > >=20 > > > my point is that NOT mandating synchronization to an=20 > external clock=20 > > > source for the timestamp option implies that sending PBU=20 > msgs with=20 > > > timestamp option is allowed even when MAGs are not (yet) > > synchronized. > > > I.e., it would be allowed that a deployment uses only the=20 > returned=20 > > > timestamps in PBA msgs to synchronize the MAG clocks. I think the=20 > > > draft should not allow this for the following reasons: > > >=20 > >=20 > > The stated assumption for the timestamp based approach to work, > > is the requirement for the MAG's to have synchronized clocks. > > That is a requirement. Now, if a given MAG sends a PBU with an > > incorrect timestamp, its an error and as you and Federico pointed > > out, there are cases where the LMA will not be able to determine > > the sending order of the received packets. This is an error > > condition, as the requirement is not met. >=20 > Right, sending a PBU with timestamp option requires that the=20 > MAG's clock > is synchronized. Hence, I don't see why the draft should specify a > mechanism to synchronize a MAG's clock using a received PBA. Also, I > think this mechanism has issues in some scenario (see my=20 > previous mail). >=20 >=20 > The clock synchronization is the job of some PMIP-independent > synchronization method like NTP and out of sync clocks can=20 > only occur if > there is a problem with this PMIP-independent synchronization method. > Hence, it is a non-recoverable error case from PMIP point of=20 > view IMHO.=20 >=20 > >=20 > > Now, should the draft state that the time synchronization is a > > requirement and additionally mandate a method of time=20 > synchronization, > > say by NTP ? But, the later has a system wide impact and=20 > additionally, > > a given architecture where this protocol is applied, can achieve the > > time synchronization through other non NTP means. IMO, we may not > > be able dictate that. Also, we want implementations to support the > > timestamp based scheme by default. Now, mandating the NTP usage will > > create some restrictions for some deployments. So, that is the > > reasoning behind not mandating the method of time synchronization. >=20 > I'm not sure if the draft can say "a MAG's clock MUST be synchronized > for this protocol to work, but how this is done is out of scope of the > draft". I guess the draft has to mandate the implementation of one > "default" synchronization protocol such as NTP to achieve > interoperability. However, as long as the use of NTP is not mandated > (e.g., just say "SHOULD use"), deployments can still use=20 > other methods. > So I don't see restrictions for deployments in this case.=20 >=20 > >=20 > > W.r.t this below scenario, the reason for LMA to return its=20 > timestamp, > > solves two purposes. 1.) Diagnostics (especially useful when the LMA > > and MAG are in different admin domains) 2.) The MAG can detect that > > its clock is not in sync and take the necessary actions. I guess, > > Frederico has an issue with the second part. But, if you look at > > the recommendation from the draft on handling this error case, > > MAG signaling considerations,=20 > >=20 > > "If the received Proxy Binding Acknowledgement message has the > > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > > Timestamp), > > the mobile access gateway SHOULD try to register again=20 > > only after > > it synchronized its clock with the local mobility=20 > > anchor's system > > clock or to a common time source that is used by all mobility > > entities in that domain for their clock synchronization." > >=20 >=20 > I think it is good if the LMA informs the MAG about detected=20 > out of sync > clocks for the purpose of diagnostics and as a trigger for=20 > re-sync. But > why do we need the timestamp option in the PBA? The TIMESTAMP_MISMATCH > value in the status field is enough for the purpose of diagnostics and > as a trigger for re-sync.=20 >=20 > > So, we are not really using the LMA as the time source.=20 > Now, with the > > given assumptions, do you see an issue if we dont say NTP is a MUST, > > but we say clock synch is a requirement, how they do it, draft does > > not say. If this requirement is not met, its an incorrect usage of > > the protocol and the PBU ordering will fail in that special rare > > reordering scenario (IMO, its not a practical issue). >=20 > see above >=20 > BR, >=20 > Kilian >=20 > >=20 > > The second question to this discussion, is Alex's point of not > > mandating Timestamp option as a MUST implement. For this,=20 > as I stated > > before, this is few lines of code for supporting this option=20 > > and if seq > > number scheme is in use, this need not be used at all. We=20 > > need to mandate > > this as there is no CT in the base spec. But, this is not a=20 > big issue > > either way. If others agree, I'm fine not mandating this.=20 > > But, I really > > believe, implementations can support this option, at the least cost. > >=20 > > One last comment on the trust on LMA's clock for the sanity=20 > check, is > > because its an anchor point and its typically well managed, compared > > to MAG's, where they are scattered out. So, its reasonable to expect > > the clock on the LMA to be in sync, else all registrations will fail > > and will generate the traps. > >=20 > > So, let me know your comments on how we can move forward. > >=20 > >=20 > > Sri > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > 1. If a MAG's clock is out of sync (i.e., not yet synced by=20 > > > receiving a > > > PBA with timestamp) AND PBUs sent by this MAG are delayed,=20 > > the out of > > > sync situation may not be detectable by the LMA and old=20 > PBUs may be > > > accepted by the LMA.=20 > > >=20 > > > Consider the following example: MN attaches to MAG1 and shortly > > > thereafter hands over to MAG2. MAG2's clock is in sync with=20 > > > LMA's clock, > > > but MAG1's clock is out of sync and is ahead of LMA's clock by 5 > > > seconds. MAG1-LMA link is highly congested. When MN=20 > > attaches to MAG1, > > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before=20 > > the MN hands > > > over to MAG2. The PBU1 msg is delayed by 5 seconds due to the=20 > > > congestion > > > and hence arrives at LMA 2 seconds after handover. Despite of=20 > > > the delay, > > > PBU1 has a valid timestamp from LMA's point of view due=20 > to the wrong > > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after=20 > > handover. PBU2 is > > > not significantly delayed and arrives at LMA ~1 seconds=20 > > after handover > > > with valid timestamp. In this scenario, the LMA will wrongly=20 > > > accept PBU1 > > > arriving after PBU2, since both have a valid timestamp.=20 > > Consequently, > > > the LMA forwards packets to the wrong MAG (MAG1) and will not=20 > > > notice the > > > out of sync of MAG1, which also means that the LMA=20 > doesn't return a > > > timestamp in the PBA and MAG1's clock keeps to be out of sync. > > >=20 > > > 2. When packets on the link between MAG and LMA=20 > experience high (and > > > varying) packet delays (e.g., due to congestion), the=20 > > timestamp in the > > > PBA returned by the LMA may already be outdated at the time=20 > > it arrives > > > at the MAG. So exactly in the situation where a re-ordering=20 > > of PBUs is > > > needed, the synchronization mechanism may fail. > > >=20 > > > My two cents. > > >=20 > > > BR, > > >=20 > > > Kilian > > >=20 > > > > -----Original Message----- > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > > > > Sent: Freitag, 7. September 2007 18:48 > > > > To: 'Kilian Weniger' > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Kilian, > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > > To: Sri Gundavelli > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > >=20 > > > > > Hi Sri,=20 > > > > >=20 > > > > > > - We are NOT mandating the nodes in the domain to sync up to > > > > > > a clock source.=20 > > > > >=20 > > > > > Hmm, so far I assumed that the proposal is to mandate the=20 > > > > MAGs to sync > > > > > up to an external clock source such as NTP server. > > > > >=20 > > > >=20 > > > > For the timestamp option to work, we RECOMMEND the use=20 > of NTP for > > > > synchronizing the clocks in the domain. However, we do=20 > not want to > > > > mandate on a specific mechanism.=20 > > > >=20 > > > >=20 > > > > > > Base draft does not support Context Transfers. Given that=20 > > > > the draft > > > > > > will be incomplete, if we dont mandate the support.=20 > > By mandating > > > > > > the support, the LMA can always return its timestamp=20 > > and the MAG > > > > > > can use that timestamp and register. This need to=20 > be done just > > > > > > once whenever the LMA/MAG clocks are out of sync and=20 > > > just for one > > > > > > registration. One extra round trip for the 1st=20 > > > > registration between > > > > > > LMA/MAG pair. > > > > >=20 > > > > > So the proposal is to allow the use of the timestamp=20 > > option in the > > > > > absence of any external time synchronization like NTP and=20 > > > > to mandate a > > > > > mechanism to synchronize clocks between MAGs and LMA (and=20 > > > > > hence between > > > > > all MAGs) using the timestamp option in PBU/PBA only=20 > > > (i.e., without > > > > > utilizing NTP or an external clock source)? Is my=20 > > > > > understanding correct? > > > > >=20 > > > >=20 > > > > No. For this to work, we require the clocks to be in sync. > > > > How its achieved, it could be based on NTP or some other=20 > > protocols. > > > > But, why should we mandate this. > > > >=20 > > > >=20 > > > > > If so, can you please give some more details how the LMA can=20 > > > > > detect that > > > > > the clocks are out of sync? Is it based on a certain=20 > > difference of > > > > > timestamp in the received PBU and the current LMA's time?=20 > > > > >=20 > > > > > And how to differentiate the out of sync case from the=20 > > > out-of-order > > > > > delivery case (i.e., a PBU is delayed and overtaken by=20 > > > > > another PBU from > > > > > another MAG)? For instance, if the LMA receives a PBU=20 > > > with timestamp > > > > > equal to "current time of LMA - X" and X > threshold, how=20 > > > > does the LMA > > > > > know whether the=20 > > > > > 1. the MAG clock is synchronized, but the PBU got=20 > > delayed by X or > > > > > 2. the PBU is not delayed, but the MAG's clock is out of=20 > > > sync by X? > > > > > Ideally, in case 1 the LMA should just ignore the PBU, in=20 > > > case 2 it > > > > > should accept it and sync clocks. > > > > >=20 > > > > > If the idea is to always reject a PBU with X > threshold=20 > > > > and include a > > > > > current timestamp in the PBA, then I guess the same could=20 > > > > be done with > > > > > sequence numbers instead of timestamps, right? > > > > >=20 > > > >=20 > > > > For what ever reasons if the LMA and MAG clocks are out=20 > > of sync, the > > > > LMA can return its timestamp and the MAG can always apply=20 > > that delta > > > > in all the registration it sends. This is done just once,=20 > > when ever > > > > the clocks are off. But, with seq number scheme, this needs=20 > > > to be done > > > > for each MN registration. Its as per the 3775 per MN seq number. > > > >=20 > > > > Sri > > > >=20 > > > > > BR, > > > > >=20 > > > > > Kilian > > > > >=20 > > > > >=20 > > > > > Panasonic R&D Center Germany GmbH > > > > > 63225 Langen, Hessen, Germany > > > > > Reg: AG Offenbach (Hessen) HRB 33974 > > > > > Managing Director: Thomas Micke > > > >=20 > > > >=20 > > >=20 > > >=20 > > > Panasonic R&D Center Germany GmbH > > > 63225 Langen, Hessen, Germany > > > Reg: AG Offenbach (Hessen) HRB 33974 > > > Managing Director: Thomas Micke > >=20 > >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 11:23:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVU4E-0007m7-An; Wed, 12 Sep 2007 11:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVU4D-0007m1-2S for netlmm@ietf.org; Wed, 12 Sep 2007 11:23:49 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVU4B-0001m0-Qf for netlmm@ietf.org; Wed, 12 Sep 2007 11:23:49 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1189610626!16509522!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 22802 invoked from network); 12 Sep 2007 15:23:46 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-14.tower-128.messagelabs.com with SMTP; 12 Sep 2007 15:23:46 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l8CFNjqV010232; Wed, 12 Sep 2007 08:23:45 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8CFNiu8023700; Wed, 12 Sep 2007 10:23:44 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8CFNfbk023593; Wed, 12 Sep 2007 10:23:42 -0500 (CDT) Message-ID: <46E80479.6030209@gmail.com> Date: Wed, 12 Sep 2007 17:23:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9350@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116AF9350@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-3, 11/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Hi Kilian/Federico and All, > > > There has been a lot of email exchange that the timestamp > synchronization using the PMIPv6 signaling does not work. It can work. Implementing it can work in a lab. But relying on timestamps and correct time keeping is too much reliance and too many assumptions on machines keeping correct time. > On the other > hand, I have not seen any in detail analysis which proves that it does > not work. I would like to share in details my thoughts on how this > SHOULD work and please comment as necessary. > > The following are a list of assumptions: > ======================================== > > 1. The time that the P-BU takes from MAG to LMA equals the time the P-BA > takes from LMA to MAG. Wrong assumption, lots of links are asymmetric. This includes ADSL, which is a very good candidate for linking the LMA to MAG, by existing commercial deployments of WiFi hotspots. > 2. LMA Timestamp included in the P-BA is the LMA timestamp when > comparing timestamp in P-BU and LMA current timestamp. > 3. MAG use the difference between the P-BU timestamp and P-BA timestamp > for calculating the delta! > 4. MAG and LMA maintains the same out of sync delta during the > re-synchronization process. > > > > MAG > LMA > ---------- > ---------- > 1. Current Timestamp MAG.t1 > LMA.t1 = MAG.t1 +d1 > 2. Timestamp in P-BU MAG.t1 LMA timestamp: > LMA.t1 > 3. MAG sends P-BU ============>>>>>>> P-BU(MAG.t1) > 4. P-BU arrives at LMA ....................... ===============>>>> > P-BU(MAG.t1) > 5. Arrival Timestamp MAG.t1 + d2 > LMA.t1 + d2 > > 6. delta based on P-BU timestamp (LMA.t1 + Could you please send diagrams that are more beautifully spaced, so the eye doesn't reject it instinctively... thanks. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 11:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVU5o-0008Me-Oq; Wed, 12 Sep 2007 11:25:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVU5o-0008MD-7v for netlmm@ietf.org; Wed, 12 Sep 2007 11:25:28 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVU5n-0001ob-0e for netlmm@ietf.org; Wed, 12 Sep 2007 11:25:28 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8CFPE712269; Wed, 12 Sep 2007 15:25:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Wed, 12 Sep 2007 10:25:11 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116AF9484@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E80479.6030209@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf1UOuumG4oYToRTwiYUmWmsFQ5UAAABTQg References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9350@zrc2hxm2.corp.nortel.com> <46E80479.6030209@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I am working on reformatting it. Sorry for that. Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Wednesday, September 12, 2007 10:24 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO;=20 > netlmm@ietf.org > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > > Hi Kilian/Federico and All, > >=20 > >=20 > > There has been a lot of email exchange that the timestamp=20 > > synchronization using the PMIPv6 signaling does not work. >=20 > It can work. Implementing it can work in a lab. >=20 > But relying on timestamps and correct time keeping is too=20 > much reliance and too many assumptions on machines keeping=20 > correct time. >=20 > > On the other > > hand, I have not seen any in detail analysis which proves=20 > that it does=20 > > not work. I would like to share in details my thoughts on how this=20 > > SHOULD work and please comment as necessary. > >=20 > > The following are a list of assumptions: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 1. The time that the P-BU takes from MAG to LMA equals the time the=20 > > P-BA takes from LMA to MAG. >=20 > Wrong assumption, lots of links are asymmetric. This=20 > includes ADSL, which is a very good candidate for linking the=20 > LMA to MAG, by existing commercial deployments of WiFi hotspots. >=20 > > 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > > comparing timestamp in P-BU and LMA current timestamp. > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > timestamp for calculating the delta! > > 4. MAG and LMA maintains the same out of sync delta during the=20 > > re-synchronization process. > >=20 > >=20 > >=20 > > MAG > > LMA > > ---------- > > ---------- > > 1. Current Timestamp MAG.t1 > > LMA.t1 =3D MAG.t1 +d1 > > 2. Timestamp in P-BU MAG.t1 LMA timestamp: > > LMA.t1 > > 3. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t1) > > 4. P-BU arrives at LMA .......................=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> > > P-BU(MAG.t1) > > 5. Arrival Timestamp MAG.t1 + d2 > > LMA.t1 + d2 > >=20 > > 6. delta based on P-BU timestamp =20 > (LMA.t1 + >=20 > Could you please send diagrams that are more beautifully=20 > spaced, so the eye doesn't reject it instinctively... thanks. >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 11:41:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUL3-0002aY-U0; Wed, 12 Sep 2007 11:41:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUL3-0002aN-3V for netlmm@ietf.org; Wed, 12 Sep 2007 11:41:13 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVUL1-0002DJ-PB for netlmm@ietf.org; Wed, 12 Sep 2007 11:41:13 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8CFcht20718; Wed, 12 Sep 2007 15:38:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Wed, 12 Sep 2007 10:40:58 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAMXqxQAAWRX+A= References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "Kilian Weniger" , "Sri Gundavelli" , "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3bef755d9f4ba0b7ac474570b36ffadb Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Resending hopefully with the correct format. +++++ Hi Kilian/Federico and All, There has been a lot of email exchange that the timestamp synchronization using the PMIPv6 signaling does not work. On the other hand, I have not seen any in detail analysis which proves that it does not work. I would like to share in details my thoughts on how this SHOULD work and please comment as necessary. The following are a list of assumptions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. The time that the P-BU takes from MAG to LMA equals the time the P-BA takes from LMA to MAG. 2. LMA Timestamp included in the P-BA is the LMA timestamp when comparing timestamp in P-BU and LMA current timestamp. 3. MAG use the difference between the P-BU timestamp and P-BA timestamp for calculating the delta! 4. MAG and LMA maintains the same out of sync delta during the re-synchronization process. MAG LMA ---------- ---------- 1. Current Timestamp MAG.t1 LMA.t1 =3D MAG.t1 +d1 2. Timestamp in P-BU MAG.t1 LMA timestamp: LMA.t1 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) 4. P-BU arrives at LMA .............. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t1) 5. Arrival Timestamp MAG.t1 + d2 LMA.t1 + d2 6. delta based on P-BU timestamp (LMA.t1 + d2)-(MAG.t1) =3D ((MAG.t1+d1)+d2) - MAG.t1 =3D delta.P-BU =3D d2+d1 7. Real delta delta.real =3D d1 8. Timestamp in P-BA MAG.t2 LMA.t2 =3D (LMA.t1 + d2) = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in corresponding P-BU) =3D (LMA.t1 + d2) - MAG.t1 =3D ((MAG.t1 +d1)+d2) -MAG.t1 delta =3D d1+d2 11. Real delta delta.real =3D d1 What is the problem here? Or am I missing something? Let us examine a re-registration or a P-BU/PA exchange based on the above synchronization: MN- Resynchronization/Re-registration: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 12. Current timestamp MAG.t3 LMA.t3 =3D MAG.t3 + d1 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 14. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t3 + (d2+d1)) 15. P-BU arrives at LMA .......=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> = P-BU(MAG.t3+(d1+d2)) 16. Arrival Timestamp MAG.t3 + d2 LMA.t3 + d2 17. delta based on P-BU (LMA.t3+d2)-(MAG.t3+(d2+d1)) =3D ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1)) =3D delta.P-BU =3D ZERO 18. Real delta delta.real =3D ZERO Please let me know what I am missing. If nothing, I hope we can put an end to this debate and MOVE ON. Regards, Ahmad =20 > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10)=20 > Sent: Wednesday, September 12, 2007 9:59 AM > To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE FEDERICO' > Cc: 'netlmm@ietf.org' > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Kilian/Federico and All, >=20 >=20 > There has been a lot of email exchange that the timestamp=20 > synchronization using the PMIPv6 signaling does not work. On=20 > the other hand, I have not seen any in detail analysis which=20 > proves that it does not work. I would like to share in=20 > details my thoughts on how this SHOULD work and please=20 > comment as necessary.=20 >=20 > The following are a list of assumptions: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. The time that the P-BU takes from MAG to LMA equals the=20 > time the P-BA takes from LMA to MAG. > 2. LMA Timestamp included in the P-BA is the LMA timestamp=20 > when comparing timestamp in P-BU and LMA current timestamp. > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > timestamp for calculating the delta! > 4. MAG and LMA maintains the same out of sync delta during=20 > the re-synchronization process. >=20 >=20 >=20 > MAG =20 > LMA > ---------- =20 > ---------- > 1. Current Timestamp MAG.t1 =20 > LMA.t1 =3D MAG.t1 +d1 > 2. Timestamp in P-BU MAG.t1 LMA=20 > timestamp: LMA.t1 > 3. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t1) > 4. P-BU arrives at LMA .......................=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t1) > 5. Arrival Timestamp MAG.t1 + d2 =20 > LMA.t1 + d2 >=20 > 6. delta based on P-BU timestamp =20 > (LMA.t1 + d2) - (MAG.t1) > =20 > =3D > =20 > ((MAG.t1+d1)+d2) - MAG.t1=09 > =20 > =3D > =20 > delta.P-BU =3D d2+d1 >=20 > 7. Real delta =20 > delta.real =3D d1 >=20 > =20 > 8. Timestamp in P-BA MAG.t2 =20 > LMA.t2 =3D (LMA.t1 + d2) > =20 > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 9. P-BA arrives @ MAG MAG.t2 + d2 =20 > LMA.t2 + d2 > 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in=20 > corresponding P-BU) > =3D > (LMA.t1 + d2) - MAG.t1 > =3D > ((MAG.t1 +d1)+d2) -MAG.t1 > =20 > delta =3D d1+d2 >=20 > 11. Real delta delta.real =3D d1 >=20 >=20 > What is the problem here? Or am I missing something? >=20 >=20 > Let us examine a re-registration or a P-BU/PA exchange based=20 > on the above synchronization: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > MN- Resynchronization/Re-registration: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 12. Current timestamp MAG.t3 =20 > LMA.t3 =3D MAG.t3 + d1 > 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 > 14. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t3 + (d2+d1)) > 15. P-BU arrives at LMA =20 > = .......................=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> = P-BU(MAG.t3 + (d1+d2)) > 16. Arrival Timestamp MAG.t3 + d2 =20 > LMA.t3 + d2 >=20 > 17. delta based on P-BU =20 > (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) > =20 > =3D > =20 > ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) > =20 > =3D > =20 > delta.P-BU =3D ZERO >=20 > 18. Real delta =20 > delta.real =3D ZERO =20 >=20 > Please let me know what I am missing. >=20 > If nothing, I hope we can put an end to this debate and MOVE ON. > =09 >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > Sent: Wednesday, September 12, 2007 3:07 AM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > please see my comments inline. > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Mittwoch, 12. September 2007 08:14 > > > To: 'Kilian Weniger' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Kilian/Federico, > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri, > > > >=20 > > > > my point is that NOT mandating synchronization to an > > external clock > > > > source for the timestamp option implies that sending PBU > > msgs with > > > > timestamp option is allowed even when MAGs are not (yet) > > > synchronized. > > > > I.e., it would be allowed that a deployment uses only the > > returned > > > > timestamps in PBA msgs to synchronize the MAG clocks. I=20 > think the=20 > > > > draft should not allow this for the following reasons: > > > >=20 > > >=20 > > > The stated assumption for the timestamp based approach to=20 > work, is=20 > > > the requirement for the MAG's to have synchronized clocks. > > > That is a requirement. Now, if a given MAG sends a PBU with an=20 > > > incorrect timestamp, its an error and as you and Federico pointed=20 > > > out, there are cases where the LMA will not be able to=20 > determine the=20 > > > sending order of the received packets. This is an error=20 > condition,=20 > > > as the requirement is not met. > >=20 > > Right, sending a PBU with timestamp option requires that the MAG's=20 > > clock is synchronized. Hence, I don't see why the draft=20 > should specify=20 > > a mechanism to synchronize a MAG's clock using a received=20 > PBA. Also, I=20 > > think this mechanism has issues in some scenario (see my previous=20 > > mail). > >=20 > >=20 > > The clock synchronization is the job of some PMIP-independent=20 > > synchronization method like NTP and out of sync clocks can=20 > only occur=20 > > if there is a problem with this PMIP-independent synchronization=20 > > method. > > Hence, it is a non-recoverable error case from PMIP point of view=20 > > IMHO. > >=20 > > >=20 > > > Now, should the draft state that the time synchronization is a=20 > > > requirement and additionally mandate a method of time > > synchronization, > > > say by NTP ? But, the later has a system wide impact and > > additionally, > > > a given architecture where this protocol is applied, can=20 > achieve the=20 > > > time synchronization through other non NTP means. IMO, we=20 > may not be=20 > > > able dictate that. Also, we want implementations to support the=20 > > > timestamp based scheme by default. Now, mandating the NTP=20 > usage will=20 > > > create some restrictions for some deployments. So, that is the=20 > > > reasoning behind not mandating the method of time synchronization. > >=20 > > I'm not sure if the draft can say "a MAG's clock MUST be=20 > synchronized=20 > > for this protocol to work, but how this is done is out of=20 > scope of the=20 > > draft". I guess the draft has to mandate the implementation of one=20 > > "default" synchronization protocol such as NTP to achieve=20 > > interoperability. However, as long as the use of NTP is not=20 > mandated=20 > > (e.g., just say "SHOULD use"), deployments can still use other=20 > > methods. > > So I don't see restrictions for deployments in this case.=20 > >=20 > > >=20 > > > W.r.t this below scenario, the reason for LMA to return its > > timestamp, > > > solves two purposes. 1.) Diagnostics (especially useful=20 > when the LMA=20 > > > and MAG are in different admin domains) 2.) The MAG can=20 > detect that=20 > > > its clock is not in sync and take the necessary actions. I guess,=20 > > > Frederico has an issue with the second part. But, if you=20 > look at the=20 > > > recommendation from the draft on handling this error case, MAG=20 > > > signaling considerations, > > >=20 > > > "If the received Proxy Binding Acknowledgement=20 > message has the > > > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > > > Timestamp), > > > the mobile access gateway SHOULD try to register again only=20 > > > after > > > it synchronized its clock with the local mobility anchor's=20 > > > system > > > clock or to a common time source that is used by=20 > all mobility > > > entities in that domain for their clock synchronization." > > >=20 > >=20 > > I think it is good if the LMA informs the MAG about detected out of=20 > > sync clocks for the purpose of diagnostics and as a trigger for=20 > > re-sync. But why do we need the timestamp option in the PBA? The=20 > > TIMESTAMP_MISMATCH value in the status field is enough for=20 > the purpose=20 > > of diagnostics and as a trigger for re-sync. > >=20 > > > So, we are not really using the LMA as the time source.=20 > > Now, with the > > > given assumptions, do you see an issue if we dont say NTP=20 > is a MUST,=20 > > > but we say clock synch is a requirement, how they do it,=20 > draft does=20 > > > not say. If this requirement is not met, its an incorrect=20 > usage of=20 > > > the protocol and the PBU ordering will fail in that special rare=20 > > > reordering scenario (IMO, its not a practical issue). > >=20 > > see above > >=20 > > BR, > >=20 > > Kilian > >=20 > > >=20 > > > The second question to this discussion, is Alex's point of not=20 > > > mandating Timestamp option as a MUST implement. For this, > > as I stated > > > before, this is few lines of code for supporting this=20 > option and if=20 > > > seq number scheme is in use, this need not be used at=20 > all. We need=20 > > > to mandate this as there is no CT in the base spec. But,=20 > this is not=20 > > > a > > big issue > > > either way. If others agree, I'm fine not mandating this.=20 > > > But, I really > > > believe, implementations can support this option, at the=20 > least cost. > > >=20 > > > One last comment on the trust on LMA's clock for the sanity > > check, is > > > because its an anchor point and its typically well=20 > managed, compared=20 > > > to MAG's, where they are scattered out. So, its=20 > reasonable to expect=20 > > > the clock on the LMA to be in sync, else all=20 > registrations will fail=20 > > > and will generate the traps. > > >=20 > > > So, let me know your comments on how we can move forward. > > >=20 > > >=20 > > > Sri > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > 1. If a MAG's clock is out of sync (i.e., not yet synced by=20 > > > > receiving a PBA with timestamp) AND PBUs sent by this MAG are=20 > > > > delayed, > > > the out of > > > > sync situation may not be detectable by the LMA and old > > PBUs may be > > > > accepted by the LMA.=20 > > > >=20 > > > > Consider the following example: MN attaches to MAG1 and shortly=20 > > > > thereafter hands over to MAG2. MAG2's clock is in sync=20 > with LMA's=20 > > > > clock, but MAG1's clock is out of sync and is ahead of=20 > LMA's clock=20 > > > > by 5 seconds. MAG1-LMA link is highly congested. When MN > > > attaches to MAG1, > > > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before > > > the MN hands > > > > over to MAG2. The PBU1 msg is delayed by 5 seconds due to the=20 > > > > congestion and hence arrives at LMA 2 seconds after handover.=20 > > > > Despite of the delay, > > > > PBU1 has a valid timestamp from LMA's point of view due > > to the wrong > > > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after > > > handover. PBU2 is > > > > not significantly delayed and arrives at LMA ~1 seconds > > > after handover > > > > with valid timestamp. In this scenario, the LMA will wrongly=20 > > > > accept PBU1 arriving after PBU2, since both have a valid=20 > > > > timestamp. > > > Consequently, > > > > the LMA forwards packets to the wrong MAG (MAG1) and will not=20 > > > > notice the out of sync of MAG1, which also means that the LMA > > doesn't return a > > > > timestamp in the PBA and MAG1's clock keeps to be out of sync. > > > >=20 > > > > 2. When packets on the link between MAG and LMA > > experience high (and > > > > varying) packet delays (e.g., due to congestion), the > > > timestamp in the > > > > PBA returned by the LMA may already be outdated at the time > > > it arrives > > > > at the MAG. So exactly in the situation where a re-ordering > > > of PBUs is > > > > needed, the synchronization mechanism may fail. > > > >=20 > > > > My two cents. > > > >=20 > > > > BR, > > > >=20 > > > > Kilian > > > >=20 > > > > > -----Original Message----- > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > Sent: Freitag, 7. September 2007 18:48 > > > > > To: 'Kilian Weniger' > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > >=20 > > > > > Hi Kilian, > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Kilian Weniger=20 > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > > > To: Sri Gundavelli > > > > > > Cc: netlmm@ietf.org > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > >=20 > > > > > > Hi Sri, > > > > > >=20 > > > > > > > - We are NOT mandating the nodes in the domain to=20 > sync up to=20 > > > > > > > a clock source. > > > > > >=20 > > > > > > Hmm, so far I assumed that the proposal is to mandate the > > > > > MAGs to sync > > > > > > up to an external clock source such as NTP server. > > > > > >=20 > > > > >=20 > > > > > For the timestamp option to work, we RECOMMEND the use > > of NTP for > > > > > synchronizing the clocks in the domain. However, we do > > not want to > > > > > mandate on a specific mechanism.=20 > > > > >=20 > > > > >=20 > > > > > > > Base draft does not support Context Transfers. Given that > > > > > the draft > > > > > > > will be incomplete, if we dont mandate the support.=20 > > > By mandating > > > > > > > the support, the LMA can always return its timestamp > > > and the MAG > > > > > > > can use that timestamp and register. This need to > > be done just > > > > > > > once whenever the LMA/MAG clocks are out of sync and > > > > just for one > > > > > > > registration. One extra round trip for the 1st > > > > > registration between > > > > > > > LMA/MAG pair. > > > > > >=20 > > > > > > So the proposal is to allow the use of the timestamp > > > option in the > > > > > > absence of any external time synchronization like NTP and > > > > > to mandate a > > > > > > mechanism to synchronize clocks between MAGs and LMA (and=20 > > > > > > hence between all MAGs) using the timestamp option=20 > in PBU/PBA=20 > > > > > > only > > > > (i.e., without > > > > > > utilizing NTP or an external clock source)? Is my=20 > > > > > > understanding correct? > > > > > >=20 > > > > >=20 > > > > > No. For this to work, we require the clocks to be in sync. > > > > > How its achieved, it could be based on NTP or some other > > > protocols. > > > > > But, why should we mandate this. > > > > >=20 > > > > >=20 > > > > > > If so, can you please give some more details how=20 > the LMA can=20 > > > > > > detect that the clocks are out of sync? Is it based on a=20 > > > > > > certain > > > difference of > > > > > > timestamp in the received PBU and the current LMA's time?=20 > > > > > >=20 > > > > > > And how to differentiate the out of sync case from the > > > > out-of-order > > > > > > delivery case (i.e., a PBU is delayed and overtaken=20 > by another=20 > > > > > > PBU from another MAG)? For instance, if the LMA=20 > receives a PBU > > > > with timestamp > > > > > > equal to "current time of LMA - X" and X > threshold, how > > > > > does the LMA > > > > > > know whether the > > > > > > 1. the MAG clock is synchronized, but the PBU got > > > delayed by X or > > > > > > 2. the PBU is not delayed, but the MAG's clock is out of > > > > sync by X? > > > > > > Ideally, in case 1 the LMA should just ignore the PBU, in > > > > case 2 it > > > > > > should accept it and sync clocks. > > > > > >=20 > > > > > > If the idea is to always reject a PBU with X > threshold > > > > > and include a > > > > > > current timestamp in the PBA, then I guess the same could > > > > > be done with > > > > > > sequence numbers instead of timestamps, right? > > > > > >=20 > > > > >=20 > > > > > For what ever reasons if the LMA and MAG clocks are out > > > of sync, the > > > > > LMA can return its timestamp and the MAG can always apply > > > that delta > > > > > in all the registration it sends. This is done just once, > > > when ever > > > > > the clocks are off. But, with seq number scheme, this needs > > > > to be done > > > > > for each MN registration. Its as per the 3775 per MN=20 > seq number. > > > > >=20 > > > > > Sri > > > > >=20 > > > > > > BR, > > > > > >=20 > > > > > > Kilian > > > > > >=20 > > > > > >=20 > > > > > > Panasonic R&D Center Germany GmbH > > > > > > 63225 Langen, Hessen, Germany > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing=20 > Director: Thomas=20 > > > > > > Micke > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > > Panasonic R&D Center Germany GmbH > > > > 63225 Langen, Hessen, Germany > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > > > > Micke > > >=20 > > >=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 11:53:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUWu-0002q5-M8; Wed, 12 Sep 2007 11:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUWs-0002mf-T0 for netlmm@ietf.org; Wed, 12 Sep 2007 11:53:26 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVUWr-0002TW-LD for netlmm@ietf.org; Wed, 12 Sep 2007 11:53:26 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8CFrH520171; Wed, 12 Sep 2007 15:53:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Wed, 12 Sep 2007 10:53:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116AF95B2@zrc2hxm2.corp.nortel.com> In-Reply-To: <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAFUmpcA== References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> From: "Ahmad Muhanna" To: "Sri Gundavelli" , "Kilian Weniger" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, I completely agree. There are several options for timestamp synchronization and any deployment can choose any of these mechanism. Nothing is mandated in the draft and that is good. On the other hand, if a deployment wants to use SQN, it is absolutely fine too. 1. If a deployment does not mind to have 2 round trips during initial attach or inter-MAG handoff, then straight forward use of the per-MN SQN is a possibility. 2. If a deployment would like to avoid two round trips during initial attach or inter-MAG handoff, then they need to synchronize per-MN SQN across MAGs. How, that is out-of-scope. I do not see any problem with the drafts options and I believe we have spent a lot of time debating this issue. IMO, The draft is good as far as this issue is concerned and the issue should be closed. Regards, Ahmad =20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Wednesday, September 12, 2007 1:14 AM > To: 'Kilian Weniger' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Kilian/Federico, >=20 > =20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > Sent: Tuesday, September 11, 2007 6:33 AM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > my point is that NOT mandating synchronization to an external clock=20 > > source for the timestamp option implies that sending PBU msgs with=20 > > timestamp option is allowed even when MAGs are not (yet)=20 > synchronized. > > I.e., it would be allowed that a deployment uses only the returned=20 > > timestamps in PBA msgs to synchronize the MAG clocks. I think the=20 > > draft should not allow this for the following reasons: > >=20 >=20 > The stated assumption for the timestamp based approach to=20 > work, is the requirement for the MAG's to have synchronized clocks. > That is a requirement. Now, if a given MAG sends a PBU with=20 > an incorrect timestamp, its an error and as you and Federico=20 > pointed out, there are cases where the LMA will not be able=20 > to determine the sending order of the received packets. This=20 > is an error condition, as the requirement is not met. >=20 > Now, should the draft state that the time synchronization is=20 > a requirement and additionally mandate a method of time=20 > synchronization, say by NTP ? But, the later has a system=20 > wide impact and additionally, a given architecture where this=20 > protocol is applied, can achieve the time synchronization=20 > through other non NTP means. IMO, we may not be able dictate=20 > that. Also, we want implementations to support the timestamp=20 > based scheme by default. Now, mandating the NTP usage will=20 > create some restrictions for some deployments. So, that is=20 > the reasoning behind not mandating the method of time synchronization. >=20 > W.r.t this below scenario, the reason for LMA to return its=20 > timestamp, solves two purposes. 1.) Diagnostics (especially=20 > useful when the LMA and MAG are in different admin domains)=20 > 2.) The MAG can detect that its clock is not in sync and take=20 > the necessary actions. I guess, Frederico has an issue with=20 > the second part. But, if you look at the recommendation from=20 > the draft on handling this error case, MAG signaling considerations,=20 >=20 > "If the received Proxy Binding Acknowledgement message has the > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > Timestamp), > the mobile access gateway SHOULD try to register again=20 > only after > it synchronized its clock with the local mobility=20 > anchor's system > clock or to a common time source that is used by all mobility > entities in that domain for their clock synchronization." >=20 > So, we are not really using the LMA as the time source. Now,=20 > with the given assumptions, do you see an issue if we dont=20 > say NTP is a MUST, but we say clock synch is a requirement,=20 > how they do it, draft does not say. If this requirement is=20 > not met, its an incorrect usage of the protocol and the PBU=20 > ordering will fail in that special rare reordering scenario=20 > (IMO, its not a practical issue). >=20 > The second question to this discussion, is Alex's point of=20 > not mandating Timestamp option as a MUST implement. For this,=20 > as I stated before, this is few lines of code for supporting=20 > this option and if seq number scheme is in use, this need not=20 > be used at all. We need to mandate this as there is no CT in=20 > the base spec. But, this is not a big issue either way. If=20 > others agree, I'm fine not mandating this. But, I really=20 > believe, implementations can support this option, at the least cost. >=20 > One last comment on the trust on LMA's clock for the sanity=20 > check, is because its an anchor point and its typically well=20 > managed, compared to MAG's, where they are scattered out. So,=20 > its reasonable to expect the clock on the LMA to be in sync,=20 > else all registrations will fail and will generate the traps. >=20 > So, let me know your comments on how we can move forward. >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > 1. If a MAG's clock is out of sync (i.e., not yet synced by=20 > receiving=20 > > a PBA with timestamp) AND PBUs sent by this MAG are=20 > delayed, the out=20 > > of sync situation may not be detectable by the LMA and old=20 > PBUs may be=20 > > accepted by the LMA. > >=20 > > Consider the following example: MN attaches to MAG1 and shortly=20 > > thereafter hands over to MAG2. MAG2's clock is in sync with LMA's=20 > > clock, but MAG1's clock is out of sync and is ahead of=20 > LMA's clock by=20 > > 5 seconds. MAG1-LMA link is highly congested. When MN attaches to=20 > > MAG1, > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before=20 > the MN hands=20 > > over to MAG2. The PBU1 msg is delayed by 5 seconds due to the=20 > > congestion and hence arrives at LMA 2 seconds after=20 > handover. Despite=20 > > of the delay, > > PBU1 has a valid timestamp from LMA's point of view due to=20 > the wrong=20 > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after=20 > handover. PBU2 is=20 > > not significantly delayed and arrives at LMA ~1 seconds=20 > after handover=20 > > with valid timestamp. In this scenario, the LMA will wrongly accept=20 > > PBU1 arriving after PBU2, since both have a valid timestamp.=20 > > Consequently, the LMA forwards packets to the wrong MAG (MAG1) and=20 > > will not notice the out of sync of MAG1, which also means=20 > that the LMA=20 > > doesn't return a timestamp in the PBA and MAG1's clock=20 > keeps to be out=20 > > of sync. > >=20 > > 2. When packets on the link between MAG and LMA experience high (and > > varying) packet delays (e.g., due to congestion), the=20 > timestamp in the=20 > > PBA returned by the LMA may already be outdated at the time=20 > it arrives=20 > > at the MAG. So exactly in the situation where a re-ordering=20 > of PBUs is=20 > > needed, the synchronization mechanism may fail. > >=20 > > My two cents. > >=20 > > BR, > >=20 > > Kilian > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Freitag, 7. September 2007 18:48 > > > To: 'Kilian Weniger' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Kilian, > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri, > > > >=20 > > > > > - We are NOT mandating the nodes in the domain to=20 > sync up to a=20 > > > > > clock source. > > > >=20 > > > > Hmm, so far I assumed that the proposal is to mandate the > > > MAGs to sync > > > > up to an external clock source such as NTP server. > > > >=20 > > >=20 > > > For the timestamp option to work, we RECOMMEND the use of NTP for=20 > > > synchronizing the clocks in the domain. However, we do=20 > not want to=20 > > > mandate on a specific mechanism. > > >=20 > > >=20 > > > > > Base draft does not support Context Transfers. Given that > > > the draft > > > > > will be incomplete, if we dont mandate the support.=20 > By mandating=20 > > > > > the support, the LMA can always return its timestamp=20 > and the MAG=20 > > > > > can use that timestamp and register. This need to be=20 > done just=20 > > > > > once whenever the LMA/MAG clocks are out of sync and > > just for one > > > > > registration. One extra round trip for the 1st > > > registration between > > > > > LMA/MAG pair. > > > >=20 > > > > So the proposal is to allow the use of the timestamp=20 > option in the=20 > > > > absence of any external time synchronization like NTP and > > > to mandate a > > > > mechanism to synchronize clocks between MAGs and LMA (and hence=20 > > > > between all MAGs) using the timestamp option in PBU/PBA only > > (i.e., without > > > > utilizing NTP or an external clock source)? Is my understanding=20 > > > > correct? > > > >=20 > > >=20 > > > No. For this to work, we require the clocks to be in sync. > > > How its achieved, it could be based on NTP or some other=20 > protocols. > > > But, why should we mandate this. > > >=20 > > >=20 > > > > If so, can you please give some more details how the LMA can=20 > > > > detect that the clocks are out of sync? Is it based on=20 > a certain=20 > > > > difference of timestamp in the received PBU and the=20 > current LMA's=20 > > > > time? > > > >=20 > > > > And how to differentiate the out of sync case from the > > out-of-order > > > > delivery case (i.e., a PBU is delayed and overtaken by=20 > another PBU=20 > > > > from another MAG)? For instance, if the LMA receives a PBU > > with timestamp > > > > equal to "current time of LMA - X" and X > threshold, how > > > does the LMA > > > > know whether the > > > > 1. the MAG clock is synchronized, but the PBU got=20 > delayed by X or=20 > > > > 2. the PBU is not delayed, but the MAG's clock is out of > > sync by X? > > > > Ideally, in case 1 the LMA should just ignore the PBU, in > > case 2 it > > > > should accept it and sync clocks. > > > >=20 > > > > If the idea is to always reject a PBU with X > threshold > > > and include a > > > > current timestamp in the PBA, then I guess the same could > > > be done with > > > > sequence numbers instead of timestamps, right? > > > >=20 > > >=20 > > > For what ever reasons if the LMA and MAG clocks are out=20 > of sync, the=20 > > > LMA can return its timestamp and the MAG can always apply=20 > that delta=20 > > > in all the registration it sends. This is done just once,=20 > when ever=20 > > > the clocks are off. But, with seq number scheme, this needs > > to be done > > > for each MN registration. Its as per the 3775 per MN seq number. > > >=20 > > > Sri > > >=20 > > > > BR, > > > >=20 > > > > Kilian > > > >=20 > > > >=20 > > > > Panasonic R&D Center Germany GmbH > > > > 63225 Langen, Hessen, Germany > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > > > > Micke > > >=20 > > >=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 12:05:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUiX-0003Qj-KK; Wed, 12 Sep 2007 12:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUiV-0003Qd-S1 for netlmm@ietf.org; Wed, 12 Sep 2007 12:05:27 -0400 Received: from cluster-j.mailcontrol.com ([86.111.223.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVUiT-0002iX-6E for netlmm@ietf.org; Wed, 12 Sep 2007 12:05:27 -0400 Received: from rly50j.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly50j.srv.mailcontrol.com (MailControl) with ESMTP id l8CG52hj026197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Sep 2007 17:05:20 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly50j.srv.mailcontrol.com (MailControl) id l8CG4VNf022755 for netlmm@ietf.org; Wed, 12 Sep 2007 17:04:31 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly50j-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8CG4PJA021876; Wed, 12 Sep 2007 17:04:31 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 5d85_06f61506_6149_11dc_8d13_0030482aac25; Wed, 12 Sep 2007 17:58:39 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091218040999-146467 ; Wed, 12 Sep 2007 18:04:09 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.101,BAYES_00: -1.665,TOTAL_SCORE: -1.564 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 12 Sep 2007 18:04:34 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] timestamp vs seqno redux In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116AF9350@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAMXqxQAATbBvA= References: <46DFC1C7.9060103@gmail.com><01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com><1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de><010301c7f16e$d25ec030$d4f6200a@amer.cisco.com><1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de><000001c7f504$24c8eb50$d5f6200a@amer.cisco.com><1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9350@zrc2hxm2.corp.nortel.com> To: "Ahmad Muhanna" , "Kilian Weniger" , "Sri Gundavelli" , "DE JUAN HUARTE FEDERICO" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48ABB8@lan-ex-02.panasonic.de> Date: Wed, 12 Sep 2007 18:03:47 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.74.1.160 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 0e831a3b581a967a651997b2cbc2bae7 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad,=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Mittwoch, 12. September 2007 16:59 > To: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Kilian/Federico and All, >=20 >=20 > There has been a lot of email exchange that the timestamp=20 > synchronization using the PMIPv6 signaling does not work. On=20 > the other hand, I have not seen any in detail analysis which=20 > proves that it does not work. I would like to share in=20 > details my thoughts on how this SHOULD work and please=20 > comment as necessary.=20 In one of my previous emails I described an example scenarios where it fails, at least according to my understanding of the sync method (which is not yet described anywhere in detail AFAIK). The point is that the LMA only sees a delta time consisting of two parts: 1.) transmission delay of PBU (d2 in your example) and 2.) clock difference (d1 in your example). The problem is that the LMA doesn't know d1 and d2 itself, it only knows d1+d2. If d2=3D~-d1, i.e., MAG's clock is ahead of LMA's = clock by a value that is roughly equal to the transmission delay, then d1+d2=3D~0, i.e., the LMA doesn't see any delta and assumes that the = MAG's clock is in sync (which is not true). Hence, no re-sync happens and the LMA may accept outdated PBUs. >=20 > The following are a list of assumptions: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. The time that the P-BU takes from MAG to LMA equals the=20 > time the P-BA takes from LMA to MAG. What is behind this assumption? Why not introduce another variable d3 for PBA delay (in addition to d2 for PBU delay). I'll wait for your reformatted diagrams before I comment on those.=20 BR, Kilian > 2. LMA Timestamp included in the P-BA is the LMA timestamp=20 > when comparing timestamp in P-BU and LMA current timestamp. > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > timestamp for calculating the delta! > 4. MAG and LMA maintains the same out of sync delta during=20 > the re-synchronization process. >=20 >=20 >=20 > MAG > LMA > ---------- > ---------- > 1. Current Timestamp MAG.t1 > LMA.t1 =3D MAG.t1 +d1 > 2. Timestamp in P-BU MAG.t1 LMA timestamp: > LMA.t1 > 3. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t1) > 4. P-BU arrives at LMA ....................... = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> > P-BU(MAG.t1) > 5. Arrival Timestamp MAG.t1 + d2 > LMA.t1 + d2 >=20 > 6. delta based on P-BU timestamp =20 > (LMA.t1 + > d2) - (MAG.t1) > =20 > =3D > =20 > ((MAG.t1+d1)+d2) - MAG.t1=09 > =20 > =3D > =20 > delta.P-BU =3D d2+d1 >=20 > 7. Real delta > delta.real =3D d1 >=20 > =20 > 8. Timestamp in P-BA MAG.t2 LMA.t2 = =3D > (LMA.t1 + d2) > =20 > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > 9. P-BA arrives @ MAG MAG.t2 + d2 =20 > LMA.t2 + > d2 > 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in corresponding > P-BU) > =3D > (LMA.t1 + d2) - MAG.t1 > =3D > ((MAG.t1 +d1)+d2) -MAG.t1 > =20 > delta =3D d1+d2 >=20 > 11. Real delta delta.real =3D d1 >=20 >=20 > What is the problem here? Or am I missing something? >=20 >=20 > Let us examine a re-registration or a P-BU/PA exchange based=20 > on the above synchronization: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > MN- Resynchronization/Re-registration: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 12. Current timestamp MAG.t3 =20 > LMA.t3 =3D > MAG.t3 + d1 > 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 > 14. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t3 + (d2+d1)) > 15. P-BU arrives at LMA = .......................=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> > P-BU(MAG.t3 + (d1+d2)) > 16. Arrival Timestamp MAG.t3 + d2 =20 > LMA.t3 + > d2 >=20 > 17. delta based on P-BU (LMA.t3 + > d2) - (MAG.t3 + (d2+d1)) > =20 > =3D > ((MAG.t3+d1)+ > d2) - (MAG.t3 + (d2+d1)) > =20 > =3D > =20 > delta.P-BU =3D ZERO >=20 > 18. Real delta =20 > delta.real > =3D ZERO =20 >=20 > Please let me know what I am missing. >=20 > If nothing, I hope we can put an end to this debate and MOVE ON. > =09 >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > Sent: Wednesday, September 12, 2007 3:07 AM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > please see my comments inline. > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Mittwoch, 12. September 2007 08:14 > > > To: 'Kilian Weniger' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Kilian/Federico, > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri, > > > >=20 > > > > my point is that NOT mandating synchronization to an > > external clock > > > > source for the timestamp option implies that sending PBU > > msgs with > > > > timestamp option is allowed even when MAGs are not (yet) > > > synchronized. > > > > I.e., it would be allowed that a deployment uses only the > > returned > > > > timestamps in PBA msgs to synchronize the MAG clocks. I=20 > think the=20 > > > > draft should not allow this for the following reasons: > > > >=20 > > >=20 > > > The stated assumption for the timestamp based approach to=20 > work, is=20 > > > the requirement for the MAG's to have synchronized clocks. > > > That is a requirement. Now, if a given MAG sends a PBU with an=20 > > > incorrect timestamp, its an error and as you and Federico pointed=20 > > > out, there are cases where the LMA will not be able to=20 > determine the=20 > > > sending order of the received packets. This is an error=20 > condition,=20 > > > as the requirement is not met. > >=20 > > Right, sending a PBU with timestamp option requires that the MAG's=20 > > clock is synchronized. Hence, I don't see why the draft=20 > should specify=20 > > a mechanism to synchronize a MAG's clock using a received=20 > PBA. Also, I=20 > > think this mechanism has issues in some scenario (see my previous=20 > > mail). > >=20 > >=20 > > The clock synchronization is the job of some PMIP-independent=20 > > synchronization method like NTP and out of sync clocks can=20 > only occur=20 > > if there is a problem with this PMIP-independent synchronization=20 > > method. > > Hence, it is a non-recoverable error case from PMIP point of view=20 > > IMHO. > >=20 > > >=20 > > > Now, should the draft state that the time synchronization is a=20 > > > requirement and additionally mandate a method of time > > synchronization, > > > say by NTP ? But, the later has a system wide impact and > > additionally, > > > a given architecture where this protocol is applied, can=20 > achieve the=20 > > > time synchronization through other non NTP means. IMO, we=20 > may not be=20 > > > able dictate that. Also, we want implementations to support the=20 > > > timestamp based scheme by default. Now, mandating the NTP=20 > usage will=20 > > > create some restrictions for some deployments. So, that is the=20 > > > reasoning behind not mandating the method of time synchronization. > >=20 > > I'm not sure if the draft can say "a MAG's clock MUST be=20 > synchronized=20 > > for this protocol to work, but how this is done is out of=20 > scope of the=20 > > draft". I guess the draft has to mandate the implementation of one=20 > > "default" synchronization protocol such as NTP to achieve=20 > > interoperability. However, as long as the use of NTP is not=20 > mandated=20 > > (e.g., just say "SHOULD use"), deployments can still use other=20 > > methods. > > So I don't see restrictions for deployments in this case.=20 > >=20 > > >=20 > > > W.r.t this below scenario, the reason for LMA to return its > > timestamp, > > > solves two purposes. 1.) Diagnostics (especially useful=20 > when the LMA=20 > > > and MAG are in different admin domains) 2.) The MAG can=20 > detect that=20 > > > its clock is not in sync and take the necessary actions. I guess,=20 > > > Frederico has an issue with the second part. But, if you=20 > look at the=20 > > > recommendation from the draft on handling this error case, MAG=20 > > > signaling considerations, > > >=20 > > > "If the received Proxy Binding Acknowledgement=20 > message has the > > > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > > > Timestamp), > > > the mobile access gateway SHOULD try to register again only=20 > > > after > > > it synchronized its clock with the local mobility anchor's=20 > > > system > > > clock or to a common time source that is used by=20 > all mobility > > > entities in that domain for their clock synchronization." > > >=20 > >=20 > > I think it is good if the LMA informs the MAG about detected out of=20 > > sync clocks for the purpose of diagnostics and as a trigger for=20 > > re-sync. But why do we need the timestamp option in the PBA? The=20 > > TIMESTAMP_MISMATCH value in the status field is enough for=20 > the purpose=20 > > of diagnostics and as a trigger for re-sync. > >=20 > > > So, we are not really using the LMA as the time source.=20 > > Now, with the > > > given assumptions, do you see an issue if we dont say NTP=20 > is a MUST,=20 > > > but we say clock synch is a requirement, how they do it,=20 > draft does=20 > > > not say. If this requirement is not met, its an incorrect=20 > usage of=20 > > > the protocol and the PBU ordering will fail in that special rare=20 > > > reordering scenario (IMO, its not a practical issue). > >=20 > > see above > >=20 > > BR, > >=20 > > Kilian > >=20 > > >=20 > > > The second question to this discussion, is Alex's point of not=20 > > > mandating Timestamp option as a MUST implement. For this, > > as I stated > > > before, this is few lines of code for supporting this=20 > option and if=20 > > > seq number scheme is in use, this need not be used at=20 > all. We need=20 > > > to mandate this as there is no CT in the base spec. But,=20 > this is not=20 > > > a > > big issue > > > either way. If others agree, I'm fine not mandating this.=20 > > > But, I really > > > believe, implementations can support this option, at the=20 > least cost. > > >=20 > > > One last comment on the trust on LMA's clock for the sanity > > check, is > > > because its an anchor point and its typically well=20 > managed, compared=20 > > > to MAG's, where they are scattered out. So, its=20 > reasonable to expect=20 > > > the clock on the LMA to be in sync, else all=20 > registrations will fail=20 > > > and will generate the traps. > > >=20 > > > So, let me know your comments on how we can move forward. > > >=20 > > >=20 > > > Sri > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > 1. If a MAG's clock is out of sync (i.e., not yet synced by=20 > > > > receiving a PBA with timestamp) AND PBUs sent by this MAG are=20 > > > > delayed, > > > the out of > > > > sync situation may not be detectable by the LMA and old > > PBUs may be > > > > accepted by the LMA.=20 > > > >=20 > > > > Consider the following example: MN attaches to MAG1 and shortly=20 > > > > thereafter hands over to MAG2. MAG2's clock is in sync=20 > with LMA's=20 > > > > clock, but MAG1's clock is out of sync and is ahead of=20 > LMA's clock=20 > > > > by 5 seconds. MAG1-LMA link is highly congested. When MN > > > attaches to MAG1, > > > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before > > > the MN hands > > > > over to MAG2. The PBU1 msg is delayed by 5 seconds due to the=20 > > > > congestion and hence arrives at LMA 2 seconds after handover.=20 > > > > Despite of the delay, > > > > PBU1 has a valid timestamp from LMA's point of view due > > to the wrong > > > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after > > > handover. PBU2 is > > > > not significantly delayed and arrives at LMA ~1 seconds > > > after handover > > > > with valid timestamp. In this scenario, the LMA will wrongly=20 > > > > accept PBU1 arriving after PBU2, since both have a valid=20 > > > > timestamp. > > > Consequently, > > > > the LMA forwards packets to the wrong MAG (MAG1) and will not=20 > > > > notice the out of sync of MAG1, which also means that the LMA > > doesn't return a > > > > timestamp in the PBA and MAG1's clock keeps to be out of sync. > > > >=20 > > > > 2. When packets on the link between MAG and LMA > > experience high (and > > > > varying) packet delays (e.g., due to congestion), the > > > timestamp in the > > > > PBA returned by the LMA may already be outdated at the time > > > it arrives > > > > at the MAG. So exactly in the situation where a re-ordering > > > of PBUs is > > > > needed, the synchronization mechanism may fail. > > > >=20 > > > > My two cents. > > > >=20 > > > > BR, > > > >=20 > > > > Kilian > > > >=20 > > > > > -----Original Message----- > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > Sent: Freitag, 7. September 2007 18:48 > > > > > To: 'Kilian Weniger' > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > >=20 > > > > > Hi Kilian, > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Kilian Weniger=20 > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > > > To: Sri Gundavelli > > > > > > Cc: netlmm@ietf.org > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > >=20 > > > > > > Hi Sri, > > > > > >=20 > > > > > > > - We are NOT mandating the nodes in the domain to=20 > sync up to=20 > > > > > > > a clock source. > > > > > >=20 > > > > > > Hmm, so far I assumed that the proposal is to mandate the > > > > > MAGs to sync > > > > > > up to an external clock source such as NTP server. > > > > > >=20 > > > > >=20 > > > > > For the timestamp option to work, we RECOMMEND the use > > of NTP for > > > > > synchronizing the clocks in the domain. However, we do > > not want to > > > > > mandate on a specific mechanism.=20 > > > > >=20 > > > > >=20 > > > > > > > Base draft does not support Context Transfers. Given that > > > > > the draft > > > > > > > will be incomplete, if we dont mandate the support.=20 > > > By mandating > > > > > > > the support, the LMA can always return its timestamp > > > and the MAG > > > > > > > can use that timestamp and register. This need to > > be done just > > > > > > > once whenever the LMA/MAG clocks are out of sync and > > > > just for one > > > > > > > registration. One extra round trip for the 1st > > > > > registration between > > > > > > > LMA/MAG pair. > > > > > >=20 > > > > > > So the proposal is to allow the use of the timestamp > > > option in the > > > > > > absence of any external time synchronization like NTP and > > > > > to mandate a > > > > > > mechanism to synchronize clocks between MAGs and LMA (and=20 > > > > > > hence between all MAGs) using the timestamp option=20 > in PBU/PBA=20 > > > > > > only > > > > (i.e., without > > > > > > utilizing NTP or an external clock source)? Is my=20 > > > > > > understanding correct? > > > > > >=20 > > > > >=20 > > > > > No. For this to work, we require the clocks to be in sync. > > > > > How its achieved, it could be based on NTP or some other > > > protocols. > > > > > But, why should we mandate this. > > > > >=20 > > > > >=20 > > > > > > If so, can you please give some more details how=20 > the LMA can=20 > > > > > > detect that the clocks are out of sync? Is it based on a=20 > > > > > > certain > > > difference of > > > > > > timestamp in the received PBU and the current LMA's time?=20 > > > > > >=20 > > > > > > And how to differentiate the out of sync case from the > > > > out-of-order > > > > > > delivery case (i.e., a PBU is delayed and overtaken=20 > by another=20 > > > > > > PBU from another MAG)? For instance, if the LMA=20 > receives a PBU > > > > with timestamp > > > > > > equal to "current time of LMA - X" and X > threshold, how > > > > > does the LMA > > > > > > know whether the > > > > > > 1. the MAG clock is synchronized, but the PBU got > > > delayed by X or > > > > > > 2. the PBU is not delayed, but the MAG's clock is out of > > > > sync by X? > > > > > > Ideally, in case 1 the LMA should just ignore the PBU, in > > > > case 2 it > > > > > > should accept it and sync clocks. > > > > > >=20 > > > > > > If the idea is to always reject a PBU with X > threshold > > > > > and include a > > > > > > current timestamp in the PBA, then I guess the same could > > > > > be done with > > > > > > sequence numbers instead of timestamps, right? > > > > > >=20 > > > > >=20 > > > > > For what ever reasons if the LMA and MAG clocks are out > > > of sync, the > > > > > LMA can return its timestamp and the MAG can always apply > > > that delta > > > > > in all the registration it sends. This is done just once, > > > when ever > > > > > the clocks are off. But, with seq number scheme, this needs > > > > to be done > > > > > for each MN registration. Its as per the 3775 per MN=20 > seq number. > > > > >=20 > > > > > Sri > > > > >=20 > > > > > > BR, > > > > > >=20 > > > > > > Kilian > > > > > >=20 > > > > > >=20 > > > > > > Panasonic R&D Center Germany GmbH > > > > > > 63225 Langen, Hessen, Germany > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing=20 > Director: Thomas=20 > > > > > > Micke > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > > Panasonic R&D Center Germany GmbH > > > > 63225 Langen, Hessen, Germany > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > > > > Micke > > >=20 > > >=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 12:05:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUib-0003YA-W5; Wed, 12 Sep 2007 12:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVUia-0003Rd-MV for netlmm@ietf.org; Wed, 12 Sep 2007 12:05:32 -0400 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVUiY-0002il-TU for netlmm@ietf.org; Wed, 12 Sep 2007 12:05:32 -0400 Received: from rly26e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly26e.srv.mailcontrol.com (MailControl) with ESMTP id l8CG4mQj021898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Sep 2007 17:05:16 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly26e.srv.mailcontrol.com (MailControl) id l8CG4bAx020767 for netlmm@ietf.org; Wed, 12 Sep 2007 17:04:37 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly26e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8CG4IwO019503; Wed, 12 Sep 2007 17:04:37 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 5d5e_03f42258_6149_11dc_8238_0030482aac25; Wed, 12 Sep 2007 17:58:34 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091218040524-146462 ; Wed, 12 Sep 2007 18:04:05 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.102,BAYES_00: -1.665,TOTAL_SCORE: -1.563 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 12 Sep 2007 18:04:34 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] timestamp vs seqno redux In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAMXqxQAAWRX+AAAB568A== References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de><6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> To: "Ahmad Muhanna" , "Sri Gundavelli" , "DE JUAN HUARTE FEDERICO" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48ABB7@lan-ex-02.panasonic.de> Date: Wed, 12 Sep 2007 18:03:15 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.69.1.136 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: ff8f6fb66123e35ba88156f838266c1a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Mittwoch, 12. September 2007 17:41 > To: Ahmad Muhanna; Kilian Weniger; Sri Gundavelli; DE JUAN=20 > HUARTE FEDERICO > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Resending hopefully with the correct format. thanks for re-sending. Much better to read now ;) >=20 > +++++ >=20 > Hi Kilian/Federico and All, >=20 > There has been a lot of email exchange that the timestamp > synchronization using the PMIPv6 signaling does not work. On the other > hand, I have not seen any in detail analysis which proves that it does > not work. I would like to share in details my thoughts on how this > SHOULD work and please comment as necessary. In one of my previous emails I described an example scenarios where it fails, at least according to my understanding of the sync method. According to my understanding, the LMA only sees a delta time consisting of two parts: 1.) transmission delay of PBU (d2 in your example) and 2.) clock difference (d1 in your example). The problem is that the LMA doesn't know d1 and d2 itself, it only knows d1+d2. If d2=3D~-d1, i.e., MAG's clock is ahead of LMA's clock by a value that is roughly equal to the transmission delay, then d1+d2=3D~0, i.e., the LMA doesn't see any delta and assumes that the MAG's clock is in sync (which is not true). Hence, no re-sync happens and the LMA may accept outdated PBUs (see my previous email). Please see some more comments inline. >=20 > The following are a list of assumptions: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. The time that the P-BU takes from MAG to LMA equals the=20 > time the P-BA > takes from LMA to MAG. What is behind this assumption? Why not introduce another variable d3 for PBA delay (in addition to d2 for PBU delay). > 2. LMA Timestamp included in the P-BA is the LMA timestamp when > comparing timestamp in P-BU and LMA current timestamp. > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > timestamp > for calculating the delta! > 4. MAG and LMA maintains the same out of sync delta during the > re-synchronization process. >=20 >=20 > MAG LMA > ---------- ---------- > 1. Current Timestamp MAG.t1 LMA.t1 =3D MAG.t1 = +d1 > 2. Timestamp in P-BU MAG.t1 LMA timestamp: LMA.t1 > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) >=20 > 4. P-BU arrives at LMA .............. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>=20 > P-BU(MAG.t1) >=20 > 5. Arrival Timestamp MAG.t1 + d2 LMA.t1 + d2 > 6. delta based on P-BU timestamp (LMA.t1 + d2)-(MAG.t1) > =3D > =20 > ((MAG.t1+d1)+d2) - MAG.t1 > =3D > delta.P-BU =3D d2+d1 right, d2+d1 is the delta that the LMA measures. >=20 > 7. Real delta delta.real =3D d1 How is the real delta d1 known by the LMA?=20 >=20 >=20 >=20 > 8. Timestamp in P-BA MAG.t2 LMA.t2 =3D (LMA.t1 + = d2) > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D How does the LMA know d2? IMO, LMA only knows delta.P-BU =3D d2+d1.=20 Hence, P-BA can only contain LMA.t2 =3D (LMA.t1 + delta.P-BU) =3D = (LMA.t1 + d1 + d2) > 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 > 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in=20 > corresponding P-BU) > =3D > (LMA.t1 + d2) - MAG.t1 > =3D > ((MAG.t1 +d1)+d2) -MAG.t1 >=20 > delta =3D d1+d2 delta should be d1+2*d2 >=20 > 11. Real delta delta.real =3D d1 How does the LMA know the real delta? BR, Kilian >=20 >=20 > What is the problem here? Or am I missing something? > Let us examine a re-registration or a P-BU/PA exchange based on the > above synchronization: >=20 >=20 > MN- Resynchronization/Re-registration: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 12. Current timestamp MAG.t3 LMA.t3 =3D MAG.t3 + = d1 > 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 > 14. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t3 + (d2+d1)) >=20 > 15. P-BU arrives at LMA = .......=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t3+(d1+d2)) > 16. Arrival Timestamp MAG.t3 + d2 LMA.t3 + d2 > 17. delta based on P-BU =20 > (LMA.t3+d2)-(MAG.t3+(d2+d1)) > =3D > =20 > ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1)) > =3D >=20 > delta.P-BU =3D ZERO > 18. Real delta delta.real =3D ZERO >=20 > Please let me know what I am missing. > If nothing, I hope we can put an end to this debate and MOVE ON. >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Muhanna, Ahmad (RICH1:2H10)=20 > > Sent: Wednesday, September 12, 2007 9:59 AM > > To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE FEDERICO' > > Cc: 'netlmm@ietf.org' > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Kilian/Federico and All, > >=20 > >=20 > > There has been a lot of email exchange that the timestamp=20 > > synchronization using the PMIPv6 signaling does not work. On=20 > > the other hand, I have not seen any in detail analysis which=20 > > proves that it does not work. I would like to share in=20 > > details my thoughts on how this SHOULD work and please=20 > > comment as necessary.=20 > >=20 > > The following are a list of assumptions: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 1. The time that the P-BU takes from MAG to LMA equals the=20 > > time the P-BA takes from LMA to MAG. > > 2. LMA Timestamp included in the P-BA is the LMA timestamp=20 > > when comparing timestamp in P-BU and LMA current timestamp. > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > timestamp for calculating the delta! > > 4. MAG and LMA maintains the same out of sync delta during=20 > > the re-synchronization process. > >=20 > >=20 > >=20 > > MAG =20 > > LMA > > ---------- =20 > > ---------- > > 1. Current Timestamp MAG.t1 =20 > > LMA.t1 =3D MAG.t1 +d1 > > 2. Timestamp in P-BU MAG.t1 LMA=20 > > timestamp: LMA.t1 > > 3. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t1) > > 4. P-BU arrives at LMA .......................=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t1) > > 5. Arrival Timestamp MAG.t1 + d2 =20 > > LMA.t1 + d2 > >=20 > > 6. delta based on P-BU timestamp =20 > > (LMA.t1 + d2) - (MAG.t1) > > =20 > > =3D > > =20 > > ((MAG.t1+d1)+d2) - MAG.t1=09 > > =20 > > =3D > > =20 > > delta.P-BU =3D d2+d1 > >=20 > > 7. Real delta =20 > > delta.real =3D d1 > >=20 > > =20 > > 8. Timestamp in P-BA MAG.t2 =20 > > LMA.t2 =3D (LMA.t1 + d2) > > =20 > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > 9. P-BA arrives @ MAG MAG.t2 + d2 =20 > > LMA.t2 + d2 > > 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in=20 > > corresponding P-BU) > > =3D > > (LMA.t1 + d2) - MAG.t1 > > =3D > > ((MAG.t1 +d1)+d2) -MAG.t1 > > =20 > > delta =3D d1+d2 > >=20 > > 11. Real delta delta.real =3D d1 > >=20 > >=20 > > What is the problem here? Or am I missing something? > >=20 > >=20 > > Let us examine a re-registration or a P-BU/PA exchange based=20 > > on the above synchronization: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >=20 > > MN- Resynchronization/Re-registration: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 12. Current timestamp MAG.t3 =20 > > LMA.t3 =3D MAG.t3 + d1 > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) =20 > LMA.t3 > > 14. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t3 + (d2+d1)) > > 15. P-BU arrives at LMA =20 > > = .......................=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> = P-BU(MAG.t3 + (d1+d2)) > > 16. Arrival Timestamp MAG.t3 + d2 =20 > > LMA.t3 + d2 > >=20 > > 17. delta based on P-BU =20 > > (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) > > =20 > > =3D > > =20 > > ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) > > =20 > > =3D > > =20 > > delta.P-BU =3D ZERO > >=20 > > 18. Real delta =20 > > delta.real =3D ZERO =20 > >=20 > > Please let me know what I am missing. > >=20 > > If nothing, I hope we can put an end to this debate and MOVE ON. > > =09 > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > Sent: Wednesday, September 12, 2007 3:07 AM > > > To: Sri Gundavelli > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Sri, > > >=20 > > > please see my comments inline. > > >=20 > > > > -----Original Message----- > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > Sent: Mittwoch, 12. September 2007 08:14 > > > > To: 'Kilian Weniger' > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Kilian/Federico, > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > > > To: Sri Gundavelli > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > >=20 > > > > > Hi Sri, > > > > >=20 > > > > > my point is that NOT mandating synchronization to an > > > external clock > > > > > source for the timestamp option implies that sending PBU > > > msgs with > > > > > timestamp option is allowed even when MAGs are not (yet) > > > > synchronized. > > > > > I.e., it would be allowed that a deployment uses only the > > > returned > > > > > timestamps in PBA msgs to synchronize the MAG clocks. I=20 > > think the=20 > > > > > draft should not allow this for the following reasons: > > > > >=20 > > > >=20 > > > > The stated assumption for the timestamp based approach to=20 > > work, is=20 > > > > the requirement for the MAG's to have synchronized clocks. > > > > That is a requirement. Now, if a given MAG sends a PBU with an=20 > > > > incorrect timestamp, its an error and as you and=20 > Federico pointed=20 > > > > out, there are cases where the LMA will not be able to=20 > > determine the=20 > > > > sending order of the received packets. This is an error=20 > > condition,=20 > > > > as the requirement is not met. > > >=20 > > > Right, sending a PBU with timestamp option requires that=20 > the MAG's=20 > > > clock is synchronized. Hence, I don't see why the draft=20 > > should specify=20 > > > a mechanism to synchronize a MAG's clock using a received=20 > > PBA. Also, I=20 > > > think this mechanism has issues in some scenario (see my previous=20 > > > mail). > > >=20 > > >=20 > > > The clock synchronization is the job of some PMIP-independent=20 > > > synchronization method like NTP and out of sync clocks can=20 > > only occur=20 > > > if there is a problem with this PMIP-independent synchronization=20 > > > method. > > > Hence, it is a non-recoverable error case from PMIP point of view=20 > > > IMHO. > > >=20 > > > >=20 > > > > Now, should the draft state that the time synchronization is a=20 > > > > requirement and additionally mandate a method of time > > > synchronization, > > > > say by NTP ? But, the later has a system wide impact and > > > additionally, > > > > a given architecture where this protocol is applied, can=20 > > achieve the=20 > > > > time synchronization through other non NTP means. IMO, we=20 > > may not be=20 > > > > able dictate that. Also, we want implementations to support the=20 > > > > timestamp based scheme by default. Now, mandating the NTP=20 > > usage will=20 > > > > create some restrictions for some deployments. So, that is the=20 > > > > reasoning behind not mandating the method of time=20 > synchronization. > > >=20 > > > I'm not sure if the draft can say "a MAG's clock MUST be=20 > > synchronized=20 > > > for this protocol to work, but how this is done is out of=20 > > scope of the=20 > > > draft". I guess the draft has to mandate the=20 > implementation of one=20 > > > "default" synchronization protocol such as NTP to achieve=20 > > > interoperability. However, as long as the use of NTP is not=20 > > mandated=20 > > > (e.g., just say "SHOULD use"), deployments can still use other=20 > > > methods. > > > So I don't see restrictions for deployments in this case.=20 > > >=20 > > > >=20 > > > > W.r.t this below scenario, the reason for LMA to return its > > > timestamp, > > > > solves two purposes. 1.) Diagnostics (especially useful=20 > > when the LMA=20 > > > > and MAG are in different admin domains) 2.) The MAG can=20 > > detect that=20 > > > > its clock is not in sync and take the necessary=20 > actions. I guess,=20 > > > > Frederico has an issue with the second part. But, if you=20 > > look at the=20 > > > > recommendation from the draft on handling this error case, MAG=20 > > > > signaling considerations, > > > >=20 > > > > "If the received Proxy Binding Acknowledgement=20 > > message has the > > > > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > > > > Timestamp), > > > > the mobile access gateway SHOULD try to register=20 > again only=20 > > > > after > > > > it synchronized its clock with the local mobility=20 > anchor's=20 > > > > system > > > > clock or to a common time source that is used by=20 > > all mobility > > > > entities in that domain for their clock synchronization." > > > >=20 > > >=20 > > > I think it is good if the LMA informs the MAG about=20 > detected out of=20 > > > sync clocks for the purpose of diagnostics and as a trigger for=20 > > > re-sync. But why do we need the timestamp option in the PBA? The=20 > > > TIMESTAMP_MISMATCH value in the status field is enough for=20 > > the purpose=20 > > > of diagnostics and as a trigger for re-sync. > > >=20 > > > > So, we are not really using the LMA as the time source.=20 > > > Now, with the > > > > given assumptions, do you see an issue if we dont say NTP=20 > > is a MUST,=20 > > > > but we say clock synch is a requirement, how they do it,=20 > > draft does=20 > > > > not say. If this requirement is not met, its an incorrect=20 > > usage of=20 > > > > the protocol and the PBU ordering will fail in that=20 > special rare=20 > > > > reordering scenario (IMO, its not a practical issue). > > >=20 > > > see above > > >=20 > > > BR, > > >=20 > > > Kilian > > >=20 > > > >=20 > > > > The second question to this discussion, is Alex's point of not=20 > > > > mandating Timestamp option as a MUST implement. For this, > > > as I stated > > > > before, this is few lines of code for supporting this=20 > > option and if=20 > > > > seq number scheme is in use, this need not be used at=20 > > all. We need=20 > > > > to mandate this as there is no CT in the base spec. But,=20 > > this is not=20 > > > > a > > > big issue > > > > either way. If others agree, I'm fine not mandating this.=20 > > > > But, I really > > > > believe, implementations can support this option, at the=20 > > least cost. > > > >=20 > > > > One last comment on the trust on LMA's clock for the sanity > > > check, is > > > > because its an anchor point and its typically well=20 > > managed, compared=20 > > > > to MAG's, where they are scattered out. So, its=20 > > reasonable to expect=20 > > > > the clock on the LMA to be in sync, else all=20 > > registrations will fail=20 > > > > and will generate the traps. > > > >=20 > > > > So, let me know your comments on how we can move forward. > > > >=20 > > > >=20 > > > > Sri > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > 1. If a MAG's clock is out of sync (i.e., not yet synced by=20 > > > > > receiving a PBA with timestamp) AND PBUs sent by this MAG are=20 > > > > > delayed, > > > > the out of > > > > > sync situation may not be detectable by the LMA and old > > > PBUs may be > > > > > accepted by the LMA.=20 > > > > >=20 > > > > > Consider the following example: MN attaches to MAG1=20 > and shortly=20 > > > > > thereafter hands over to MAG2. MAG2's clock is in sync=20 > > with LMA's=20 > > > > > clock, but MAG1's clock is out of sync and is ahead of=20 > > LMA's clock=20 > > > > > by 5 seconds. MAG1-LMA link is highly congested. When MN > > > > attaches to MAG1, > > > > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before > > > > the MN hands > > > > > over to MAG2. The PBU1 msg is delayed by 5 seconds due to the=20 > > > > > congestion and hence arrives at LMA 2 seconds after handover.=20 > > > > > Despite of the delay, > > > > > PBU1 has a valid timestamp from LMA's point of view due > > > to the wrong > > > > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after > > > > handover. PBU2 is > > > > > not significantly delayed and arrives at LMA ~1 seconds > > > > after handover > > > > > with valid timestamp. In this scenario, the LMA will wrongly=20 > > > > > accept PBU1 arriving after PBU2, since both have a valid=20 > > > > > timestamp. > > > > Consequently, > > > > > the LMA forwards packets to the wrong MAG (MAG1) and will not=20 > > > > > notice the out of sync of MAG1, which also means that the LMA > > > doesn't return a > > > > > timestamp in the PBA and MAG1's clock keeps to be out of sync. > > > > >=20 > > > > > 2. When packets on the link between MAG and LMA > > > experience high (and > > > > > varying) packet delays (e.g., due to congestion), the > > > > timestamp in the > > > > > PBA returned by the LMA may already be outdated at the time > > > > it arrives > > > > > at the MAG. So exactly in the situation where a re-ordering > > > > of PBUs is > > > > > needed, the synchronization mechanism may fail. > > > > >=20 > > > > > My two cents. > > > > >=20 > > > > > BR, > > > > >=20 > > > > > Kilian > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > > Sent: Freitag, 7. September 2007 18:48 > > > > > > To: 'Kilian Weniger' > > > > > > Cc: netlmm@ietf.org > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > >=20 > > > > > > Hi Kilian, > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Kilian Weniger=20 > > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > > > > To: Sri Gundavelli > > > > > > > Cc: netlmm@ietf.org > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > >=20 > > > > > > > Hi Sri, > > > > > > >=20 > > > > > > > > - We are NOT mandating the nodes in the domain to=20 > > sync up to=20 > > > > > > > > a clock source. > > > > > > >=20 > > > > > > > Hmm, so far I assumed that the proposal is to mandate the > > > > > > MAGs to sync > > > > > > > up to an external clock source such as NTP server. > > > > > > >=20 > > > > > >=20 > > > > > > For the timestamp option to work, we RECOMMEND the use > > > of NTP for > > > > > > synchronizing the clocks in the domain. However, we do > > > not want to > > > > > > mandate on a specific mechanism.=20 > > > > > >=20 > > > > > >=20 > > > > > > > > Base draft does not support Context Transfers.=20 > Given that > > > > > > the draft > > > > > > > > will be incomplete, if we dont mandate the support.=20 > > > > By mandating > > > > > > > > the support, the LMA can always return its timestamp > > > > and the MAG > > > > > > > > can use that timestamp and register. This need to > > > be done just > > > > > > > > once whenever the LMA/MAG clocks are out of sync and > > > > > just for one > > > > > > > > registration. One extra round trip for the 1st > > > > > > registration between > > > > > > > > LMA/MAG pair. > > > > > > >=20 > > > > > > > So the proposal is to allow the use of the timestamp > > > > option in the > > > > > > > absence of any external time synchronization like NTP and > > > > > > to mandate a > > > > > > > mechanism to synchronize clocks between MAGs and LMA (and=20 > > > > > > > hence between all MAGs) using the timestamp option=20 > > in PBU/PBA=20 > > > > > > > only > > > > > (i.e., without > > > > > > > utilizing NTP or an external clock source)? Is my=20 > > > > > > > understanding correct? > > > > > > >=20 > > > > > >=20 > > > > > > No. For this to work, we require the clocks to be in sync. > > > > > > How its achieved, it could be based on NTP or some other > > > > protocols. > > > > > > But, why should we mandate this. > > > > > >=20 > > > > > >=20 > > > > > > > If so, can you please give some more details how=20 > > the LMA can=20 > > > > > > > detect that the clocks are out of sync? Is it based on a=20 > > > > > > > certain > > > > difference of > > > > > > > timestamp in the received PBU and the current LMA's time?=20 > > > > > > >=20 > > > > > > > And how to differentiate the out of sync case from the > > > > > out-of-order > > > > > > > delivery case (i.e., a PBU is delayed and overtaken=20 > > by another=20 > > > > > > > PBU from another MAG)? For instance, if the LMA=20 > > receives a PBU > > > > > with timestamp > > > > > > > equal to "current time of LMA - X" and X > threshold, how > > > > > > does the LMA > > > > > > > know whether the > > > > > > > 1. the MAG clock is synchronized, but the PBU got > > > > delayed by X or > > > > > > > 2. the PBU is not delayed, but the MAG's clock is out of > > > > > sync by X? > > > > > > > Ideally, in case 1 the LMA should just ignore the PBU, in > > > > > case 2 it > > > > > > > should accept it and sync clocks. > > > > > > >=20 > > > > > > > If the idea is to always reject a PBU with X > threshold > > > > > > and include a > > > > > > > current timestamp in the PBA, then I guess the same could > > > > > > be done with > > > > > > > sequence numbers instead of timestamps, right? > > > > > > >=20 > > > > > >=20 > > > > > > For what ever reasons if the LMA and MAG clocks are out > > > > of sync, the > > > > > > LMA can return its timestamp and the MAG can always apply > > > > that delta > > > > > > in all the registration it sends. This is done just once, > > > > when ever > > > > > > the clocks are off. But, with seq number scheme, this needs > > > > > to be done > > > > > > for each MN registration. Its as per the 3775 per MN=20 > > seq number. > > > > > >=20 > > > > > > Sri > > > > > >=20 > > > > > > > BR, > > > > > > >=20 > > > > > > > Kilian > > > > > > >=20 > > > > > > >=20 > > > > > > > Panasonic R&D Center Germany GmbH > > > > > > > 63225 Langen, Hessen, Germany > > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing=20 > > Director: Thomas=20 > > > > > > > Micke > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Panasonic R&D Center Germany GmbH > > > > > 63225 Langen, Hessen, Germany > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing=20 > Director: Thomas=20 > > > > > Micke > > > >=20 > > > >=20 > > >=20 > > >=20 > > > Panasonic R&D Center Germany GmbH > > > 63225 Langen, Hessen, Germany > > > Reg: AG Offenbach (Hessen) HRB 33974 > > > Managing Director: Thomas Micke > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 16:20:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYgx-0004xx-Eh; Wed, 12 Sep 2007 16:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYgv-0004wt-D1 for netlmm@ietf.org; Wed, 12 Sep 2007 16:20:05 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVYgu-00010g-1y for netlmm@ietf.org; Wed, 12 Sep 2007 16:20:05 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8CKJu701511; Wed, 12 Sep 2007 20:19:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Wed, 12 Sep 2007 15:19:48 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B4978F@zrc2hxm2.corp.nortel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48ABB7@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAMXqxQAAWRX+AAAB568AAE2X+Q References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de><6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <1FEB9B9F2EC38343955D02B2AE86AACB48ABB7@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" , "Sri Gundavelli" , "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a9d8f61f7718176ef97b85bbcc64331 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Please see comments inline. Regards, Ahmad =20 >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Mittwoch, 12. September 2007 17:41 > > To: Ahmad Muhanna; Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE=20 > > FEDERICO > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Resending hopefully with the correct format. >=20 > thanks for re-sending. Much better to read now ;) >=20 > >=20 > > +++++ > >=20 > > Hi Kilian/Federico and All, > >=20 > > There has been a lot of email exchange that the timestamp=20 > > synchronization using the PMIPv6 signaling does not work.=20 > On the other=20 > > hand, I have not seen any in detail analysis which proves=20 > that it does=20 > > not work. I would like to share in details my thoughts on how this=20 > > SHOULD work and please comment as necessary. >=20 > In one of my previous emails I described an example scenarios=20 > where it fails, at least according to my understanding of the=20 > sync method. > According to my understanding, the LMA only sees a delta time=20 > consisting of two parts: 1.) transmission delay of PBU (d2 in=20 > your example) and 2.) clock difference (d1 in your example).=20 > The problem is that the LMA doesn't know d1 and d2 itself, it=20 > only knows d1+d2. If d2=3D~-d1, i.e., MAG's clock is ahead of=20 > LMA's clock by a value that is roughly equal to the=20 > transmission delay, then d1+d2=3D~0, i.e., the LMA doesn't see=20 > any delta and assumes that the MAG's clock is in sync (which=20 > is not true). > Hence, no re-sync happens and the LMA may accept outdated=20 > PBUs (see my previous email). [Ahmad] Kilian, This is the same race condition that we have discussed too many times and people do not like to accept the unpopular solution :-) I have no problem with that. But let us exactly identify all conditions related to the scenario: 1. A race condition scenario which happens during handoff. 2. It assumes that the MAGs are not properly synchronized with each other using an outside mechanism. We are here talking here about the MAGs not the (LMA and MAGs). In other words, if the MAGs in the same local domain are synchronized this issue will never happen. 3. It assumes that the pMAG sent a P-BU as a re-registration in a race condition as the MN moves from pMAG (previous MAG) to nMAG (next MAG). 4. Due to some network conditions, the P-BU of the pMAG arrives at the LMA after the P-BU of the nMAG. 5. It also assumes that not only pMAG and nMAG is out of sync, but also nMAG is slower than pMAG by almost double the delta between any of them and the LMA. 6. Not only that but also, the nMAG is slower enough to the degree that when the P-BU arrives at the LMA it is within the threshold. Finally, -------- I am not saying that the possibility of this scenario to happen is ZERO. No. There is a possibility that it MAY happen but , at the same time, it is very very slim. Not only that, I think according to the PMIPv6 draft, MAG needs to make sure that the MN is currently attached before sending a re-registration P-BU. If the MAG is not sure, then MAG does not send the P-BU. NOW: what can we do about it: ----------------------------- 1. The very famous but un-popular solution that we mentioned several time. In case of handoff, i.e. when the LMA receives the P-BU from nMAG, LMA considers this as a case of handoff. When LMA receives a P-BU from the pMAG, LMA drops or rejects it with a code MN-in-handoff, for example. Since it is a race condition, that will take care of it. 2. LMA needs to track the delta for each MAG. Then after the P-BU passes the LMA timestamp check and in case of handoff, LMA can always make sure that the adjusted timestamp of the received P-BU is always larger than the adjusted timestamp of the last received P-BU which is already saved as part of the MN BCE. I hope that this will take care of this issue and we can finally move on. Best Regards, Ahmad BTW: please see more comments below. >=20 > Please see some more comments inline. >=20 > >=20 > > The following are a list of assumptions: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 1. The time that the P-BU takes from MAG to LMA equals the time the=20 > > P-BA takes from LMA to MAG. >=20 > What is behind this assumption? Why not introduce another=20 > variable d3 for PBA delay (in addition to d2 for PBU delay). [Ahmad] Actually d3 is irrelevant in this regard. Because the timestamp delta that the MAG is tracking does not depend on d3, because, MAG considers the timestamp delta as the difference between the LMA-timestamp in P-BA (which is independent of d3) and the MAG-timestamp in the corresponding P-BU (which is again independent of d3).=20 This means that regardless of the delay in the downlink direction, only the delay in the uplink direction has an impact and that impact is already factored IN and does not influence synchronization scheme. >=20 >=20 > > 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > > comparing timestamp in P-BU and LMA current timestamp. > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > timestamp for calculating the delta! > > 4. MAG and LMA maintains the same out of sync delta during the=20 > > re-synchronization process. > >=20 > >=20 > > MAG LMA > > ---------- =20 > ---------- > > 1. Current Timestamp MAG.t1 LMA.t1 =3D=20 > MAG.t1 +d1 > > 2. Timestamp in P-BU MAG.t1 LMA timestamp: LMA.t1 > > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) > >=20 > > 4. P-BU arrives at LMA .............. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> > > P-BU(MAG.t1) > >=20 > > 5. Arrival Timestamp MAG.t1 + d2 LMA.t1 + d2 > > 6. delta based on P-BU timestamp (LMA.t1 +=20 > d2)-(MAG.t1) > > =3D > > =20 > > ((MAG.t1+d1)+d2) - MAG.t1 > > =3D > > delta.P-BU =3D = d2+d1 >=20 > right, d2+d1 is the delta that the LMA measures. [Ahmad] Correct. Measured from the MAG timestamp. Right? >=20 > >=20 > > 7. Real delta delta.real =3D d1 >=20 > How is the real delta d1 known by the LMA? [Ahmad] LMA does not need to know it. As long as the scheme works to resynchronize the MAG with the LMA, no need for LMA to know it. Right? =20 >=20 > >=20 > >=20 > >=20 > > 8. Timestamp in P-BA MAG.t2 LMA.t2 =3D=20 > (LMA.t1 + d2) > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > How does the LMA know d2? IMO, LMA only knows delta.P-BU =3D d2+d1.=20 [Ahmad] Absolutely. LMA does not know what d2 and does not need to. This is used for proving the scheme.=20 > Hence, P-BA can only contain LMA.t2 =3D (LMA.t1 + delta.P-BU) =3D=20 > (LMA.t1 + > d1 + d2) [Ahmad] I am afraid that is not correct. You probably meant to say: LMA.t2 =3D (MAG.t1 + (d1+d2)). Right? Otherwise, LMA.t2 in terms of LMA.t1 is as follows: LMA.t2 =3D LMA.t1 + d2. NO? >=20 > > 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 > > 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in corresponding=20 > > P-BU) > > =3D > > (LMA.t1 + d2) - MAG.t1 > > =3D > > ((MAG.t1 +d1)+d2) -MAG.t1 > >=20 > > delta =3D d1+d2 >=20 > delta should be d1+2*d2 [Ahmad] No. That is not correct. Delta =3D d1+d2. Please see above comment. >=20 > >=20 > > 11. Real delta delta.real =3D d1 >=20 > How does the LMA know the real delta? [Ahmad] It does not need to know. ONLY MAG needs to track a delta with the LMA. Well, we can make both track each other deltas but that will be too much for the LMA and , honestly, it is not needed. =20 >=20 > BR, >=20 > Kilian >=20 >=20 > >=20 > >=20 > > What is the problem here? Or am I missing something? > > Let us examine a re-registration or a P-BU/PA exchange based on the=20 > > above synchronization: > >=20 > >=20 > > MN- Resynchronization/Re-registration: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 12. Current timestamp MAG.t3 LMA.t3 =3D=20 > MAG.t3 + d1 > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 > > 14. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t3 + (d2+d1)) > >=20 > > 15. P-BU arrives at LMA = .......=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>=20 > P-BU(MAG.t3+(d1+d2)) > > 16. Arrival Timestamp MAG.t3 + d2 LMA.t3 + d2 > > 17. delta based on P-BU =20 > > (LMA.t3+d2)-(MAG.t3+(d2+d1)) > > =3D > > =20 > > ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1)) > > =3D > >=20 > > delta.P-BU =3D ZERO > > 18. Real delta delta.real =3D ZERO > >=20 > > Please let me know what I am missing. > > If nothing, I hope we can put an end to this debate and MOVE ON. > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Muhanna, Ahmad (RICH1:2H10) > > > Sent: Wednesday, September 12, 2007 9:59 AM > > > To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE FEDERICO' > > > Cc: 'netlmm@ietf.org' > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Kilian/Federico and All, > > >=20 > > >=20 > > > There has been a lot of email exchange that the timestamp=20 > > > synchronization using the PMIPv6 signaling does not work. On the=20 > > > other hand, I have not seen any in detail analysis which=20 > proves that=20 > > > it does not work. I would like to share in details my thoughts on=20 > > > how this SHOULD work and please comment as necessary. > > >=20 > > > The following are a list of assumptions: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > 1. The time that the P-BU takes from MAG to LMA equals=20 > the time the=20 > > > P-BA takes from LMA to MAG. > > > 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > > > comparing timestamp in P-BU and LMA current timestamp. > > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > > timestamp for calculating the delta! > > > 4. MAG and LMA maintains the same out of sync delta during the=20 > > > re-synchronization process. > > >=20 > > >=20 > > >=20 > > > MAG =20 > > > LMA > > > ---------- =20 > > > ---------- > > > 1. Current Timestamp MAG.t1 =20 > > > LMA.t1 =3D MAG.t1 +d1 > > > 2. Timestamp in P-BU MAG.t1 LMA=20 > > > timestamp: LMA.t1 > > > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) > > > 4. P-BU arrives at LMA .......................=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t1) > > > 5. Arrival Timestamp MAG.t1 + d2 =20 > > > LMA.t1 + d2 > > >=20 > > > 6. delta based on P-BU timestamp =20 > > > (LMA.t1 + d2) - (MAG.t1) > > > =20 > > > =3D > > > =20 > > > ((MAG.t1+d1)+d2) - MAG.t1=09 > > > =20 > > > =3D > > > =20 > > > delta.P-BU =3D d2+d1 > > >=20 > > > 7. Real delta =20 > > > delta.real =3D d1 > > >=20 > > > =20 > > > 8. Timestamp in P-BA MAG.t2 =20 > > > LMA.t2 =3D (LMA.t1 + d2) > > > =20 > > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > 9. P-BA arrives @ MAG MAG.t2 + d2 =20 > > > LMA.t2 + d2 > > > 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in=20 > corresponding=20 > > > P-BU) > > > =3D > > > (LMA.t1 + d2) - MAG.t1 > > > =3D > > > ((MAG.t1 +d1)+d2) -MAG.t1 > > > =20 > > > delta =3D d1+d2 > > >=20 > > > 11. Real delta delta.real =3D d1 > > >=20 > > >=20 > > > What is the problem here? Or am I missing something? > > >=20 > > >=20 > > > Let us examine a re-registration or a P-BU/PA exchange=20 > based on the=20 > > > above synchronization: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > >=20 > > > MN- Resynchronization/Re-registration: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > 12. Current timestamp MAG.t3 =20 > > > LMA.t3 =3D MAG.t3 + d1 > > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) =20 > > LMA.t3 > > > 14. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t3=20 > + (d2+d1)) > > > 15. P-BU arrives at LMA > > > = .......................=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> = P-BU(MAG.t3 + (d1+d2)) > > > 16. Arrival Timestamp MAG.t3 + d2 =20 > > > LMA.t3 + d2 > > >=20 > > > 17. delta based on P-BU =20 > > > (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) > > > =20 > > > =3D > > > =20 > > > ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) > > > =20 > > > =3D > > > =20 > > > delta.P-BU =3D ZERO > > >=20 > > > 18. Real delta =20 > > > delta.real =3D ZERO =20 > > >=20 > > > Please let me know what I am missing. > > >=20 > > > If nothing, I hope we can put an end to this debate and MOVE ON. > > > =09 > > >=20 > > > Regards, > > > Ahmad > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > Sent: Wednesday, September 12, 2007 3:07 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri, > > > >=20 > > > > please see my comments inline. > > > >=20 > > > > > -----Original Message----- > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > Sent: Mittwoch, 12. September 2007 08:14 > > > > > To: 'Kilian Weniger' > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > >=20 > > > > > Hi Kilian/Federico, > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Kilian Weniger=20 > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > > > > To: Sri Gundavelli > > > > > > Cc: netlmm@ietf.org > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > >=20 > > > > > > Hi Sri, > > > > > >=20 > > > > > > my point is that NOT mandating synchronization to an > > > > external clock > > > > > > source for the timestamp option implies that sending PBU > > > > msgs with > > > > > > timestamp option is allowed even when MAGs are not (yet) > > > > > synchronized. > > > > > > I.e., it would be allowed that a deployment uses only the > > > > returned > > > > > > timestamps in PBA msgs to synchronize the MAG clocks. I > > > think the > > > > > > draft should not allow this for the following reasons: > > > > > >=20 > > > > >=20 > > > > > The stated assumption for the timestamp based approach to > > > work, is > > > > > the requirement for the MAG's to have synchronized clocks. > > > > > That is a requirement. Now, if a given MAG sends a=20 > PBU with an=20 > > > > > incorrect timestamp, its an error and as you and > > Federico pointed > > > > > out, there are cases where the LMA will not be able to > > > determine the > > > > > sending order of the received packets. This is an error > > > condition, > > > > > as the requirement is not met. > > > >=20 > > > > Right, sending a PBU with timestamp option requires that > > the MAG's > > > > clock is synchronized. Hence, I don't see why the draft > > > should specify > > > > a mechanism to synchronize a MAG's clock using a received > > > PBA. Also, I > > > > think this mechanism has issues in some scenario (see=20 > my previous=20 > > > > mail). > > > >=20 > > > >=20 > > > > The clock synchronization is the job of some PMIP-independent=20 > > > > synchronization method like NTP and out of sync clocks can > > > only occur > > > > if there is a problem with this PMIP-independent=20 > synchronization=20 > > > > method. > > > > Hence, it is a non-recoverable error case from PMIP=20 > point of view=20 > > > > IMHO. > > > >=20 > > > > >=20 > > > > > Now, should the draft state that the time=20 > synchronization is a=20 > > > > > requirement and additionally mandate a method of time > > > > synchronization, > > > > > say by NTP ? But, the later has a system wide impact and > > > > additionally, > > > > > a given architecture where this protocol is applied, can > > > achieve the > > > > > time synchronization through other non NTP means. IMO, we > > > may not be > > > > > able dictate that. Also, we want implementations to=20 > support the=20 > > > > > timestamp based scheme by default. Now, mandating the NTP > > > usage will > > > > > create some restrictions for some deployments. So,=20 > that is the=20 > > > > > reasoning behind not mandating the method of time > > synchronization. > > > >=20 > > > > I'm not sure if the draft can say "a MAG's clock MUST be > > > synchronized > > > > for this protocol to work, but how this is done is out of > > > scope of the > > > > draft". I guess the draft has to mandate the > > implementation of one > > > > "default" synchronization protocol such as NTP to achieve=20 > > > > interoperability. However, as long as the use of NTP is not > > > mandated > > > > (e.g., just say "SHOULD use"), deployments can still use other=20 > > > > methods. > > > > So I don't see restrictions for deployments in this case.=20 > > > >=20 > > > > >=20 > > > > > W.r.t this below scenario, the reason for LMA to return its > > > > timestamp, > > > > > solves two purposes. 1.) Diagnostics (especially useful > > > when the LMA > > > > > and MAG are in different admin domains) 2.) The MAG can > > > detect that > > > > > its clock is not in sync and take the necessary > > actions. I guess, > > > > > Frederico has an issue with the second part. But, if you > > > look at the > > > > > recommendation from the draft on handling this error=20 > case, MAG=20 > > > > > signaling considerations, > > > > >=20 > > > > > "If the received Proxy Binding Acknowledgement > > > message has the > > > > > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > > > > > Timestamp), > > > > > the mobile access gateway SHOULD try to register > > again only > > > > > after > > > > > it synchronized its clock with the local mobility > > anchor's > > > > > system > > > > > clock or to a common time source that is used by > > > all mobility > > > > > entities in that domain for their clock=20 > synchronization." > > > > >=20 > > > >=20 > > > > I think it is good if the LMA informs the MAG about > > detected out of > > > > sync clocks for the purpose of diagnostics and as a trigger for=20 > > > > re-sync. But why do we need the timestamp option in the=20 > PBA? The=20 > > > > TIMESTAMP_MISMATCH value in the status field is enough for > > > the purpose > > > > of diagnostics and as a trigger for re-sync. > > > >=20 > > > > > So, we are not really using the LMA as the time source.=20 > > > > Now, with the > > > > > given assumptions, do you see an issue if we dont say NTP > > > is a MUST, > > > > > but we say clock synch is a requirement, how they do it, > > > draft does > > > > > not say. If this requirement is not met, its an incorrect > > > usage of > > > > > the protocol and the PBU ordering will fail in that > > special rare > > > > > reordering scenario (IMO, its not a practical issue). > > > >=20 > > > > see above > > > >=20 > > > > BR, > > > >=20 > > > > Kilian > > > >=20 > > > > >=20 > > > > > The second question to this discussion, is Alex's=20 > point of not=20 > > > > > mandating Timestamp option as a MUST implement. For this, > > > > as I stated > > > > > before, this is few lines of code for supporting this > > > option and if > > > > > seq number scheme is in use, this need not be used at > > > all. We need > > > > > to mandate this as there is no CT in the base spec. But, > > > this is not > > > > > a > > > > big issue > > > > > either way. If others agree, I'm fine not mandating this.=20 > > > > > But, I really > > > > > believe, implementations can support this option, at the > > > least cost. > > > > >=20 > > > > > One last comment on the trust on LMA's clock for the sanity > > > > check, is > > > > > because its an anchor point and its typically well > > > managed, compared > > > > > to MAG's, where they are scattered out. So, its > > > reasonable to expect > > > > > the clock on the LMA to be in sync, else all > > > registrations will fail > > > > > and will generate the traps. > > > > >=20 > > > > > So, let me know your comments on how we can move forward. > > > > >=20 > > > > >=20 > > > > > Sri > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > 1. If a MAG's clock is out of sync (i.e., not yet synced by=20 > > > > > > receiving a PBA with timestamp) AND PBUs sent by=20 > this MAG are=20 > > > > > > delayed, > > > > > the out of > > > > > > sync situation may not be detectable by the LMA and old > > > > PBUs may be > > > > > > accepted by the LMA.=20 > > > > > >=20 > > > > > > Consider the following example: MN attaches to MAG1 > > and shortly > > > > > > thereafter hands over to MAG2. MAG2's clock is in sync > > > with LMA's > > > > > > clock, but MAG1's clock is out of sync and is ahead of > > > LMA's clock > > > > > > by 5 seconds. MAG1-LMA link is highly congested. When MN > > > > > attaches to MAG1, > > > > > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before > > > > > the MN hands > > > > > > over to MAG2. The PBU1 msg is delayed by 5 seconds=20 > due to the=20 > > > > > > congestion and hence arrives at LMA 2 seconds after=20 > handover. > > > > > > Despite of the delay, > > > > > > PBU1 has a valid timestamp from LMA's point of view due > > > > to the wrong > > > > > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after > > > > > handover. PBU2 is > > > > > > not significantly delayed and arrives at LMA ~1 seconds > > > > > after handover > > > > > > with valid timestamp. In this scenario, the LMA=20 > will wrongly=20 > > > > > > accept PBU1 arriving after PBU2, since both have a valid=20 > > > > > > timestamp. > > > > > Consequently, > > > > > > the LMA forwards packets to the wrong MAG (MAG1)=20 > and will not=20 > > > > > > notice the out of sync of MAG1, which also means=20 > that the LMA > > > > doesn't return a > > > > > > timestamp in the PBA and MAG1's clock keeps to be=20 > out of sync. > > > > > >=20 > > > > > > 2. When packets on the link between MAG and LMA > > > > experience high (and > > > > > > varying) packet delays (e.g., due to congestion), the > > > > > timestamp in the > > > > > > PBA returned by the LMA may already be outdated at the time > > > > > it arrives > > > > > > at the MAG. So exactly in the situation where a re-ordering > > > > > of PBUs is > > > > > > needed, the synchronization mechanism may fail. > > > > > >=20 > > > > > > My two cents. > > > > > >=20 > > > > > > BR, > > > > > >=20 > > > > > > Kilian > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > > > Sent: Freitag, 7. September 2007 18:48 > > > > > > > To: 'Kilian Weniger' > > > > > > > Cc: netlmm@ietf.org > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > >=20 > > > > > > > Hi Kilian, > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Kilian Weniger > > > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > > > > > To: Sri Gundavelli > > > > > > > > Cc: netlmm@ietf.org > > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > > >=20 > > > > > > > > Hi Sri, > > > > > > > >=20 > > > > > > > > > - We are NOT mandating the nodes in the domain to > > > sync up to > > > > > > > > > a clock source. > > > > > > > >=20 > > > > > > > > Hmm, so far I assumed that the proposal is to=20 > mandate the > > > > > > > MAGs to sync > > > > > > > > up to an external clock source such as NTP server. > > > > > > > >=20 > > > > > > >=20 > > > > > > > For the timestamp option to work, we RECOMMEND the use > > > > of NTP for > > > > > > > synchronizing the clocks in the domain. However, we do > > > > not want to > > > > > > > mandate on a specific mechanism.=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > > Base draft does not support Context Transfers.=20 > > Given that > > > > > > > the draft > > > > > > > > > will be incomplete, if we dont mandate the support.=20 > > > > > By mandating > > > > > > > > > the support, the LMA can always return its timestamp > > > > > and the MAG > > > > > > > > > can use that timestamp and register. This need to > > > > be done just > > > > > > > > > once whenever the LMA/MAG clocks are out of sync and > > > > > > just for one > > > > > > > > > registration. One extra round trip for the 1st > > > > > > > registration between > > > > > > > > > LMA/MAG pair. > > > > > > > >=20 > > > > > > > > So the proposal is to allow the use of the timestamp > > > > > option in the > > > > > > > > absence of any external time synchronization=20 > like NTP and > > > > > > > to mandate a > > > > > > > > mechanism to synchronize clocks between MAGs=20 > and LMA (and=20 > > > > > > > > hence between all MAGs) using the timestamp option > > > in PBU/PBA > > > > > > > > only > > > > > > (i.e., without > > > > > > > > utilizing NTP or an external clock source)? Is my=20 > > > > > > > > understanding correct? > > > > > > > >=20 > > > > > > >=20 > > > > > > > No. For this to work, we require the clocks to be in sync. > > > > > > > How its achieved, it could be based on NTP or some other > > > > > protocols. > > > > > > > But, why should we mandate this. > > > > > > >=20 > > > > > > >=20 > > > > > > > > If so, can you please give some more details how > > > the LMA can > > > > > > > > detect that the clocks are out of sync? Is it=20 > based on a=20 > > > > > > > > certain > > > > > difference of > > > > > > > > timestamp in the received PBU and the current=20 > LMA's time?=20 > > > > > > > >=20 > > > > > > > > And how to differentiate the out of sync case from the > > > > > > out-of-order > > > > > > > > delivery case (i.e., a PBU is delayed and overtaken > > > by another > > > > > > > > PBU from another MAG)? For instance, if the LMA > > > receives a PBU > > > > > > with timestamp > > > > > > > > equal to "current time of LMA - X" and X >=20 > threshold, how > > > > > > > does the LMA > > > > > > > > know whether the > > > > > > > > 1. the MAG clock is synchronized, but the PBU got > > > > > delayed by X or > > > > > > > > 2. the PBU is not delayed, but the MAG's clock is out of > > > > > > sync by X? > > > > > > > > Ideally, in case 1 the LMA should just ignore=20 > the PBU, in > > > > > > case 2 it > > > > > > > > should accept it and sync clocks. > > > > > > > >=20 > > > > > > > > If the idea is to always reject a PBU with X > threshold > > > > > > > and include a > > > > > > > > current timestamp in the PBA, then I guess the=20 > same could > > > > > > > be done with > > > > > > > > sequence numbers instead of timestamps, right? > > > > > > > >=20 > > > > > > >=20 > > > > > > > For what ever reasons if the LMA and MAG clocks are out > > > > > of sync, the > > > > > > > LMA can return its timestamp and the MAG can always apply > > > > > that delta > > > > > > > in all the registration it sends. This is done just once, > > > > > when ever > > > > > > > the clocks are off. But, with seq number scheme,=20 > this needs > > > > > > to be done > > > > > > > for each MN registration. Its as per the 3775 per MN > > > seq number. > > > > > > >=20 > > > > > > > Sri > > > > > > >=20 > > > > > > > > BR, > > > > > > > >=20 > > > > > > > > Kilian > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Panasonic R&D Center Germany GmbH > > > > > > > > 63225 Langen, Hessen, Germany > > > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing > > > Director: Thomas > > > > > > > > Micke > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Panasonic R&D Center Germany GmbH > > > > > > 63225 Langen, Hessen, Germany > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing > > Director: Thomas > > > > > > Micke > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > > Panasonic R&D Center Germany GmbH > > > > 63225 Langen, Hessen, Germany > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > > > > Micke > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 > >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 17:34:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZrF-0005VH-DA; Wed, 12 Sep 2007 17:34:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZrD-0005Ul-Mo for netlmm@ietf.org; Wed, 12 Sep 2007 17:34:47 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVZrC-0008Jb-JR for netlmm@ietf.org; Wed, 12 Sep 2007 17:34:47 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8CLYf723464; Wed, 12 Sep 2007 21:34:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Significance of MN-Identifier Date: Wed, 12 Sep 2007 16:34:40 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B49A4C@zrc2hxm2.corp.nortel.com> In-Reply-To: <0MKp8S-1IVNnm3uVi-0008Vr@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Significance of MN-Identifier Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZgAATcTHAAGkVXIA== References: <000101c7f506$32738970$d5f6200a@amer.cisco.com> <0MKp8S-1IVNnm3uVi-0008Vr@mrelay.perfora.net> From: "Ahmad Muhanna" To: "Alper Yegin" , "Sri Gundavelli" , "Chowdhury, Kuntal" X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, Please see comments inline. Regards, Ahmad =20 > Subject: RE: [netlmm] Significance of MN-Identifier >=20 > Sri, >=20 > You are explaining how carrying some identifier representing=20 > the MN is useful. Not explaining why "it MUST always be carried". >=20 > My point is two-fold: >=20 > - There is one very strong case that the HNP is allocated as=20 > part of the network access authentication. In that case, we=20 > don't have to rely on "some identifier representing the MN",=20 > instead HNP is already bound to the MN. HNP becomes that identifier.=20 >=20 > - Use of RFC 4285 with MAG-LMA SA is one of the possible=20 > security models. > And that requires carrying the "MAG id" in the NAI. Assuming=20 > the NAI always carries some "MN id" as the current spec does=20 > is disallowing this possibility. [Ahmad] I guess this a multilayered complexity question which probably needs to have several different threads to address them. However, we are forced to handle them all together in a single thread!=20 IMO, You already assumed the following: 1. RFC4285 is used for PMIPv6. ? 2. RFC4285 has a mechanism to securely protect P-BU and P-BA based on a MAG-LMA SA. Similar to FA-HA AE!? :-( 3. The LMA is able to distinguish that the ID included in the BU is the MAG-ID.=20 Now: If the MAG is able to somehow identify that the ID included is the MAG ID, then why there is a problem if the MN-ID is included.? May be I am missing something here. >=20 > My proposal is to relax that language so that NAI is not=20 > "always" supposed to carry a "MN id". Specific exception case=20 > is when the MN is already assigned a HNP by an out-of band mechanisms. [Ahmad] I am not sure where these series of relaxation will end up getting this draft? >=20 > Alper >=20 >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Wednesday, September 12, 2007 9:29 AM > > To: 'Alper Yegin'; 'Chowdhury, Kuntal' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Significance of MN-Identifier > >=20 > > Hi Alper, > >=20 > >=20 > > > -----Original Message----- > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > Sent: Tuesday, September 11, 2007 2:08 PM > > > To: 'Chowdhury, Kuntal'; 'Sri Gundavelli' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > Hi Kuntal, > > > > > > > I don't know what the issue is for MN-ID in the PMIP6 signaling=20 > > > > messages. Could you explain why we are having this debate? > > > > > > Because, the current text is locking all PMIP6 deployments to one=20 > > > security model and not leaving any room for using=20 > anything else. And=20 > > > it is doing so without a good reason (unintentionally, I believe). > > > > > > > MN-ID is the unique identifier to identify the session > > > state in the LMA. > > > > > > It is necessary only of the MN does not know its HNP. As=20 > soon as it=20 > > > knows the HNP (e.g., when HNP is assigned during network access=20 > > > authentication), we can rely on HNP to identify the session state. > > > > >=20 > > HNP is dynamically generated. Initially, a MN may not have been=20 > > allocated any HNP, in that we have to send the MN identity=20 > for the LMA=20 > > to apply the proper policy checks and allocate a prefix. > > After that point, when the mobile moves to a new MAG, the=20 > MAG on the=20 > > link would likely authenticate the MN, obtain its id before=20 > it allows=20 > > the MN for network access. So, most likely the new MAG=20 > would know the=20 > > MN id as supposed to knowing its allocated prefix, that may=20 > be in the=20 > > BCE state (unless statically configured in AAA). > >=20 > > Generally, I can see 3775 HA, identifying a MN with its HoA=20 > and so not=20 > > requiring the id in the signaling messages. But, in a proxy=20 > model in=20 > > combination with dynamic prefix allocation, is it not reasonable to=20 > > carry an identifier of the mobile node in the messages ? Thats the=20 > > stable identifier of the mobile node. > > Its definetly more stable than an allocated prefix. The MAG may=20 > > authenticate the mobile node on the access link and will mo=20 > t likely=20 > > have some form of identifier, as supposed to it knowing the prefix=20 > > that is allocated by the LMA. Id is also required for=20 > billing purposes=20 > > as well and may very well be the corelation id. > >=20 > > I do not think, we introduced this id requirement, just with one=20 > > scenario in mind. Its a very natural requirement and the=20 > information=20 > > is there on the MAG. Do not know, why this would be an=20 > issue for WiMAX=20 > > case. > >=20 > > Sri > >=20 > >=20 > >=20 > >=20 > >=20 > > > > > > > There are several good reasons to mandate the presence of > > > MN-ID in the > > > > PBU/PBA. For example, it helps to identify the session > > > state in the LMA > > > > for PMIP6 - MIP6 transition scenarios, when the LMA is > > > collocated with a > > > > MIP6 HA. > > > > > > Can you elaborate on this scenario? You may have=20 > something here, but=20 > > > I need to understand. > > > > > > Alper > > > > > > > > > > Note that during IKEv2 exchange for MIP6, the IDi field (that=20 > > > > carries the same MN-ID) in the IKE packets help identify the=20 > > > > ongoing > > > > (PMIP6) session related to the MN. > > > > > > > > Hope this helps. > > > > > > > > -Kuntal > > > > > > > > > > > > > -----Original Message----- > > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > > > To: 'Sri Gundavelli' > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > > > Sri, > > > > > > > > > > > At handoff, nMAG may not know the HNP of the mobile > > > node. How does > > > > it > > > > > > communicate with the LMA about the MN, if MN-Id is not > > > used ? That's > > > > > > is essential, its required in BCE and also in signaling > > > messages. > > > > > > > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > > > > > >>> Is it for the sake of identifying the MN during=20 > dynamic HNP=20 > > > > > >>> assignment in-band with PMIP? > > > > > > > > > > > > > > > HNP can be assigned during network access authentication. I=20 > > > > > can't > > > > imagine > > > > > when this is not possible or desirable. > > > > > > > > > > That's why mandating presence of MN-id that identifies > > > the MN is not > > > > > necessary, imo. > > > > > > > > > > If people can show a reason why we must also support HNP > > > assignment > > > > in- > > > > > band > > > > > with PMIP, we can say: > > > > > > > > > > When the HNP in PBU has the value 0::/0, an NAI=20 > [RFC4283] > that > > > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > >> Sri > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >>> -----Original Message----- > > > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > > > >>> To: netlmm@ietf.org > > > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > > > >>> > > > > > > >>> What's the significance of MN-Identifier as=20 > carried in PBU? > > > > > > >>> > > > > > > >>> Is it for the sake of identifying the MN during dynamic=20 > > > > > > >>> HNP > > > > > assignment > > > > > > >>> in-band with PMIP? > > > > > > >>> > > > > > > >>> If so, given that the HNP may also be assigned > > > during network > > > > access > > > > > > >>> authentication (out-of band with PMIP, as=20 > commonly done in > > > > > integrated > > > > > > >>> bootstrapping scenarios), we shall not mandate that the=20 > > > > > > >>> MN- > > > > > identifier > > > > > > >>> identifies the real MN. > > > > > > >>> > > > > > > >>> Another way of using of MN-identifier is to=20 > identify the=20 > > > > > > >>> "proxy MN" (MAG) with RFC 4285. > > > > > > >>> > > > > > > >>> Alper > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> netlmm mailing list > > > > > > >>> netlmm@ietf.org > > > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > "This email message and any attachments are confidential > > > information of > > > > Starent Networks, Corp. The information transmitted may not > > > be used to > > > > create or change any contractual obligations of Starent > > > Networks, Corp. > > > > Any review, retransmission, dissemination or other use of, > > > or taking of > > > > any action in reliance upon this e-mail and its attachments > > > by persons or > > > > entities other than the intended recipient is prohibited. > > > If you are not > > > > the intended recipient, please notify the sender=20 > immediately -- by=20 > > > > replying to this message or by sending an email to=20 > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > this message > > > > and any attachments without reading or disclosing their > > > contents. Thank > > > > you." >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 17:38:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZua-0007Mf-U1; Wed, 12 Sep 2007 17:38:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZuZ-0007MY-U5 for netlmm@ietf.org; Wed, 12 Sep 2007 17:38:16 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVZuY-0008NH-Sj for netlmm@ietf.org; Wed, 12 Sep 2007 17:38:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8CLcA723787; Wed, 12 Sep 2007 21:38:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Significance of MN-Identifier Date: Wed, 12 Sep 2007 16:37:47 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B49A69@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B49A4C@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Significance of MN-Identifier Thread-Index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZgAATcTHAAGkVXIAABAajg References: <000101c7f506$32738970$d5f6200a@amer.cisco.com> <0MKp8S-1IVNnm3uVi-0008Vr@mrelay.perfora.net> <6FC4416DDE56C44DA0AEE67BC7CA437116B49A4C@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "Alper Yegin" , "Sri Gundavelli" , "Chowdhury, Kuntal" X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sorry one typo. I meant to say: "if the LMA not the MAG ... Now: If the LMA is able to somehow identify that the ID included is the MAG ID, then why there is a problem if the MN-ID is included.? May be I am missing something here. Regards, Ahmad =20 > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10)=20 > Sent: Wednesday, September 12, 2007 4:35 PM > To: Alper Yegin; Sri Gundavelli; Chowdhury, Kuntal > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Significance of MN-Identifier >=20 > Hi Alper, > Please see comments inline. >=20 > Regards, > Ahmad > =20 >=20 > > Subject: RE: [netlmm] Significance of MN-Identifier > >=20 > > Sri, > >=20 > > You are explaining how carrying some identifier=20 > representing the MN is=20 > > useful. Not explaining why "it MUST always be carried". > >=20 > > My point is two-fold: > >=20 > > - There is one very strong case that the HNP is allocated=20 > as part of=20 > > the network access authentication. In that case, we don't=20 > have to rely=20 > > on "some identifier representing the MN", instead HNP is=20 > already bound=20 > > to the MN. HNP becomes that identifier. > >=20 > > - Use of RFC 4285 with MAG-LMA SA is one of the possible security=20 > > models. > > And that requires carrying the "MAG id" in the NAI.=20 > Assuming the NAI=20 > > always carries some "MN id" as the current spec does is disallowing=20 > > this possibility. >=20 > [Ahmad] > I guess this a multilayered complexity question which=20 > probably needs to have several different threads to address=20 > them. However, we are forced to handle them all together in a=20 > single thread!=20 > IMO, You already assumed the following: >=20 > 1. RFC4285 is used for PMIPv6. ? > 2. RFC4285 has a mechanism to securely protect P-BU and P-BA=20 > based on a MAG-LMA SA. Similar to FA-HA AE!? :-( 3. The LMA=20 > is able to distinguish that the ID included in the BU is the MAG-ID.=20 >=20 > Now: If the MAG is able to somehow identify that the ID=20 > included is the MAG ID, then why there is a problem if the=20 > MN-ID is included.? May be I am missing something here. >=20 > >=20 > > My proposal is to relax that language so that NAI is not "always"=20 > > supposed to carry a "MN id". Specific exception case is=20 > when the MN is=20 > > already assigned a HNP by an out-of band mechanisms. >=20 > [Ahmad] > I am not sure where these series of relaxation will end up=20 > getting this draft? >=20 > >=20 > > Alper > >=20 > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Wednesday, September 12, 2007 9:29 AM > > > To: 'Alper Yegin'; 'Chowdhury, Kuntal' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] Significance of MN-Identifier > > >=20 > > > Hi Alper, > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > Sent: Tuesday, September 11, 2007 2:08 PM > > > > To: 'Chowdhury, Kuntal'; 'Sri Gundavelli' > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > Hi Kuntal, > > > > > > > > > I don't know what the issue is for MN-ID in the PMIP6=20 > signaling=20 > > > > > messages. Could you explain why we are having this debate? > > > > > > > > Because, the current text is locking all PMIP6=20 > deployments to one=20 > > > > security model and not leaving any room for using > > anything else. And > > > > it is doing so without a good reason (unintentionally,=20 > I believe). > > > > > > > > > MN-ID is the unique identifier to identify the session > > > > state in the LMA. > > > > > > > > It is necessary only of the MN does not know its HNP. As > > soon as it > > > > knows the HNP (e.g., when HNP is assigned during network access=20 > > > > authentication), we can rely on HNP to identify the=20 > session state. > > > > > > >=20 > > > HNP is dynamically generated. Initially, a MN may not have been=20 > > > allocated any HNP, in that we have to send the MN identity > > for the LMA > > > to apply the proper policy checks and allocate a prefix. > > > After that point, when the mobile moves to a new MAG, the > > MAG on the > > > link would likely authenticate the MN, obtain its id before > > it allows > > > the MN for network access. So, most likely the new MAG > > would know the > > > MN id as supposed to knowing its allocated prefix, that may > > be in the > > > BCE state (unless statically configured in AAA). > > >=20 > > > Generally, I can see 3775 HA, identifying a MN with its HoA > > and so not > > > requiring the id in the signaling messages. But, in a proxy > > model in > > > combination with dynamic prefix allocation, is it not=20 > reasonable to=20 > > > carry an identifier of the mobile node in the messages ?=20 > Thats the=20 > > > stable identifier of the mobile node. > > > Its definetly more stable than an allocated prefix. The MAG may=20 > > > authenticate the mobile node on the access link and will mo > > t likely > > > have some form of identifier, as supposed to it knowing=20 > the prefix=20 > > > that is allocated by the LMA. Id is also required for > > billing purposes > > > as well and may very well be the corelation id. > > >=20 > > > I do not think, we introduced this id requirement, just with one=20 > > > scenario in mind. Its a very natural requirement and the > > information > > > is there on the MAG. Do not know, why this would be an > > issue for WiMAX > > > case. > > >=20 > > > Sri > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > > > > > > There are several good reasons to mandate the presence of > > > > MN-ID in the > > > > > PBU/PBA. For example, it helps to identify the session > > > > state in the LMA > > > > > for PMIP6 - MIP6 transition scenarios, when the LMA is > > > > collocated with a > > > > > MIP6 HA. > > > > > > > > Can you elaborate on this scenario? You may have > > something here, but > > > > I need to understand. > > > > > > > > Alper > > > > > > > > > > > > > Note that during IKEv2 exchange for MIP6, the IDi field (that=20 > > > > > carries the same MN-ID) in the IKE packets help identify the=20 > > > > > ongoing > > > > > (PMIP6) session related to the MN. > > > > > > > > > > Hope this helps. > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > > > > To: 'Sri Gundavelli' > > > > > > Cc: netlmm@ietf.org > > > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > > > > > Sri, > > > > > > > > > > > > > At handoff, nMAG may not know the HNP of the mobile > > > > node. How does > > > > > it > > > > > > > communicate with the LMA about the MN, if MN-Id is not > > > > used ? That's > > > > > > > is essential, its required in BCE and also in signaling > > > > messages. > > > > > > > > > > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > > > > > > > >>> Is it for the sake of identifying the MN during > > dynamic HNP > > > > > > >>> assignment in-band with PMIP? > > > > > > > > > > > > > > > > > > HNP can be assigned during network access authentication. I=20 > > > > > > can't > > > > > imagine > > > > > > when this is not possible or desirable. > > > > > > > > > > > > That's why mandating presence of MN-id that identifies > > > > the MN is not > > > > > > necessary, imo. > > > > > > > > > > > > If people can show a reason why we must also support HNP > > > > assignment > > > > > in- > > > > > > band > > > > > > with PMIP, we can say: > > > > > > > > > > > > When the HNP in PBU has the value 0::/0, an NAI > > [RFC4283] > > that > > > > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > >> Sri > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >>> -----Original Message----- > > > > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > > > > >>> To: netlmm@ietf.org > > > > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > > > > >>> > > > > > > > >>> What's the significance of MN-Identifier as > > carried in PBU? > > > > > > > >>> > > > > > > > >>> Is it for the sake of identifying the MN=20 > during dynamic=20 > > > > > > > >>> HNP > > > > > > assignment > > > > > > > >>> in-band with PMIP? > > > > > > > >>> > > > > > > > >>> If so, given that the HNP may also be assigned > > > > during network > > > > > access > > > > > > > >>> authentication (out-of band with PMIP, as > > commonly done in > > > > > > integrated > > > > > > > >>> bootstrapping scenarios), we shall not=20 > mandate that the > > > > > > > >>> MN- > > > > > > identifier > > > > > > > >>> identifies the real MN. > > > > > > > >>> > > > > > > > >>> Another way of using of MN-identifier is to > > identify the > > > > > > > >>> "proxy MN" (MAG) with RFC 4285. > > > > > > > >>> > > > > > > > >>> Alper > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> _______________________________________________ > > > > > > > >>> netlmm mailing list > > > > > > > >>> netlmm@ietf.org > > > > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netlmm mailing list > > > > > > netlmm@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > information of > > > > > Starent Networks, Corp. The information transmitted may not > > > > be used to > > > > > create or change any contractual obligations of Starent > > > > Networks, Corp. > > > > > Any review, retransmission, dissemination or other use of, > > > > or taking of > > > > > any action in reliance upon this e-mail and its attachments > > > > by persons or > > > > > entities other than the intended recipient is prohibited. > > > > If you are not > > > > > the intended recipient, please notify the sender > > immediately -- by > > > > > replying to this message or by sending an email to=20 > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > this message > > > > > and any attachments without reading or disclosing their > > > > contents. Thank > > > > > you." > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 20:50:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVcum-0004mU-8Z; Wed, 12 Sep 2007 20:50:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVcul-0004mO-5X for netlmm@ietf.org; Wed, 12 Sep 2007 20:50:39 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVcuk-0004Mu-CD for netlmm@ietf.org; Wed, 12 Sep 2007 20:50:39 -0400 X-IronPort-AV: E=Sophos;i="4.20,247,1186383600"; d="scan'208,217";a="523350385" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 12 Sep 2007 17:50:33 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8D0oWsC003699; Wed, 12 Sep 2007 17:50:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8D0oIbH017740; Thu, 13 Sep 2007 00:50:32 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 17:50:25 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 17:50:24 -0700 From: "Sri Gundavelli" To: "'DE JUAN HUARTE FEDERICO'" References: <319D54578EAC3147BA8CC78DAB5467A501399A37@FRVELSMBS12.ad2.ad.alcatel.com> Date: Wed, 12 Sep 2007 17:50:24 -0700 Message-ID: <00fe01c7f5a0$11a7a380$d5f6200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A37@FRVELSMBS12.ad2.ad.alcatel.com> Thread-Index: Acf1Q/zk/G1LNLOHQuGr5NEbOJ+qFQAO9tbA X-OriginalArrivalTime: 13 Sep 2007 00:50:24.0948 (UTC) FILETIME=[1208AF40:01C7F5A0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8220; t=1189644632; x=1190508632; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20HNP=20length |Sender:=20; bh=lAOgRL9TYvbDyKzhz5e8dnwWg20HG3rc5HV4ak1vB14=; b=YheQe8FFJlOKIKihPfd3oxmP+LDYWIGoMnrQx2u/XvbwO5lS9Jvi4yGnPzzYIJKiv1SoE1CN t8Detz5hnqOkL9Rga8Ro3bbKDdgbmwPLqntN7Yh0HrduHkmE3I2L8wr6; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: netlmm@ietf.org Subject: [netlmm] RE: HNP length X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0400513174==" Errors-To: netlmm-bounces@ietf.org This is a multi-part message in MIME format. --===============0400513174== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FF_01C7F565.6548CB80" This is a multi-part message in MIME format. ------=_NextPart_000_00FF_01C7F565.6548CB80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Federico, > if the HNP can be longer than 64 bits. Yes, that was intentional. The parameter for storing the prefix should implicitly contain the prefix length. Thats the integral property of a prefix and so did not define a seperate parameter for it in the conceptual data structures. > The motivation of my question is that I keep on getting contradictory answers in this > respect: apparently legacy v6 implementations would not support prefixes longer than 64 bits As per 3587 or as per 3177 recommendations, interface id length is 64 bits long, for the current 001 allocation. Also, the EUI-64 format for the identifier generation requires 64 bits. So, not sure, if the prefix length can be greater than 64 bits, atleast for now. But, the draft does not assume any prefix length or mandate on the prefix lengths. Sri _____ From: DE JUAN HUARTE FEDERICO [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] Sent: Wednesday, September 12, 2007 6:51 AM To: Sri Gundavelli Cc: netlmm@ietf.org Subject: HNP length Hi Sri, unless I missed it, the PMIP6 v3 I-D is silent about the HNP length. Is it intentional? I'm trying to find out if the HNP can be longer than 64 bits More specifically (avoiding variable length prefixes) is it possible to assign 128-bit HNP (in per-MN HNP model)? The motivation of my question is that I keep on getting contradictory answers in this respect: apparently legacy v6 implementations would not support prefixes longer than 64 bits Thanks federico ------=_NextPart_000_00FF_01C7F565.6548CB80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HNP length
Hi Federico,
 
 
> if the HNP can be longer than 64 = bits.
 
Yes, that was intentional. The parameter for storing the = prefix=20 should implicitly
contain the prefix length. Thats the integral property = of a prefix=20 and so did not
define a seperate parameter for it in the = conceptual data=20 structures.
 
 
> The motivation of my question is that I keep on = getting=20 contradictory answers in this
> respect: apparently legacy v6 implementations would = not=20 support prefixes longer than 64 bits
 
As per 3587 or as per 3177=20 recommendations,  interface id length is 64 bits = long, for the
current 001 allocation. Also, the EUI-64 format for the = identifier=20 generation requires 64 bits.
So, not = sure, if the=20 prefix length can be  greater than 64 bits, atleast for now. = But,=20 the draft
does not assume any prefix length or mandate on the = prefix=20 lengths.
 
Sri
 
   

From: DE JUAN HUARTE FEDERICO=20 [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]
Sent: = Wednesday,=20 September 12, 2007 6:51 AM
To: Sri Gundavelli
Cc:=20 netlmm@ietf.org
Subject: HNP length

Hi Sri,

unless I missed it, the PMIP6 = v3 I-D is=20 silent about the HNP length. Is it intentional?

I'm trying to find out if the = HNP can be=20 longer than 64 bits
More=20 specifically (avoiding variable length prefixes) is it possible to = assign=20 128-bit HNP (in per-MN HNP model)?

The motivation of my question = is that I=20 keep on getting contradictory answers in this respect: apparently = legacy v6=20 implementations would not support prefixes longer than 64 = bits

Thanks

federico=20


------=_NextPart_000_00FF_01C7F565.6548CB80-- --===============0400513174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0400513174==-- From netlmm-bounces@ietf.org Wed Sep 12 21:00:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVd4T-0006DJ-RT; Wed, 12 Sep 2007 21:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVd4S-0006CR-3y for netlmm@ietf.org; Wed, 12 Sep 2007 21:00:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVd4Q-0006KN-Bt for netlmm@ietf.org; Wed, 12 Sep 2007 21:00:39 -0400 X-IronPort-AV: E=Sophos;i="4.20,247,1186383600"; d="scan'208";a="217118151" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 12 Sep 2007 18:00:37 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8D10b33013451; Wed, 12 Sep 2007 18:00:37 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8D10boJ017004; Thu, 13 Sep 2007 01:00:37 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 18:00:37 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 18:00:36 -0700 From: "Sri Gundavelli" To: "'Premec, Domagoj'" References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Wed, 12 Sep 2007 18:00:36 -0700 Message-ID: <011501c7f5a1$7e873b40$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> Thread-Index: Acf0Pq9T2NcAJj3HRZ+zuMUIF+h8RAAABK8AADdSTuAAIR7gEA== X-OriginalArrivalTime: 13 Sep 2007 01:00:36.0823 (UTC) FILETIME=[7EBD6670:01C7F5A1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4116; t=1189645237; x=1190509237; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-proxymip6 -04.txt=20 |Sender:=20; bh=To5Fvu6zxGC6jYAyQFwjnDrVMTnJIsoxyTT4oKdXWXA=; b=rm/I+JcWIx2Q+0rrPHTfILDxUFp/6YYoViixzxEMz9oSPJZeEQvlMuYyeh+/t7RJlO/K2DI9 hJEtLWimmXYOyrY3CvrjzBhv3YlWGkCqgAYC9jeId9tosoXtsle34vPu; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Domagoj, Thanks for reviewing the doc. Please see inline .. > -----Original Message----- > From: Premec, Domagoj [mailto:domagoj.premec@siemens.com] > Sent: Wednesday, September 12, 2007 5:29 AM > To: Sri Gundavelli > Cc: netlmm > Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt > > Hi Sri, > > A couple of comments... > > section 5.3 > > o The local mobility anchor MUST ignore the check, specified in > > Section 10.3.1 [RFC-3775], related to the presence of > Home Address > > destination option in the Proxy Binding Update request. > > For the sake of completness, the draft should also state that > the MAG shall not add the Home address destination option to > the PBU. Otherwise, the compliant MAG would still be free to > put it into the PBU. > > section 5.5.1 > > Implementations MAY choose to use static > > tunnels as supposed to dynamically creating and > tearing them down > > on a need basis. > > typo, s/as supposed/as opposed/ > Will rephrase it, if this is not clear. > > >6.3. Supported Access Link Types > > > > This specification supports only point-to-point access > link types and > > thus it assumes that the mobile node and the mobile access gateway > > are the only two nodes on the access link. The link is assumed to > > have multicast capability. > > I understand that the decision to use per-MN prefix model was > motivated by the need to emulate the point-to-point link at > the IP layer. As the IP layer is configured in such a way > that there are exactly two nodes on the link, we're actually > independet of the underlaying link layer technology. I think > the intent of the spec is to support any access link type, > including for example 802.11. The first sentence, claiming > support only for point-to-point link types, is too > restrictive. Maybe it could be reformulated to make it clear > that point-to-point property is realized at the IP layer. > Ok. This is a good comment. I see what you mean from the 802.11 point of view. We will rephrase this. If you can provide some text that will be good. > section 6.4 > > However, > > the advertised flags with respect the address > configuration will be > > typo: add "to" between "respect" and "the address" > Ok > section 6.14 > > Upon obtaining the mobile node's profile after a successful access > > authentication and after a policy consideration, the mobile access > > gateway MUST determine if the network based mobility > service should > > be offered to that mobile node. > > This sounds like the MAG looks only at MN's profile and > policy to determine the mobility mode of the MN. Looking at > the MN's profile only is too restrictive, the user can change > his terminal or update it with a MIP implementation and might > prefere to use client based MIP. So I think the language hier > should keep the door open for deciding about the MN's > mobility mode in a more dynamic manner. The MAG could learn > about the MN's capabilities and preferences through > link-layer or some future enhancements at the IP layer. Would > it be possible to add following sentence at the end of the > cited paragraph: > "The MAG's decision can be influenced by the mobile node's > MIP capabilities and preferences. The MAG may learn about the > MN's capabilites and preferences through link-layer exchange > or by some other means out of the scope of this specificaton." > Fine. > section 7.3 > > [...] the newly learnt default-router > > as supposed to the previously known default-router. > > typo: s/as supposed/as opposed/ > Will rephrase this, if its not clear. > section 7.3 > > There are other solutions possible for this problem, including the > > assignment of a unique link-local address for all the > mobile access > > gateways [...] > > IMO "same link-local address" instead of "unique link-local > address" would be more clear. > ok. Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 12 21:14:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVdHt-0003Ts-SC; Wed, 12 Sep 2007 21:14:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVdHp-0003Tm-Vn for netlmm@ietf.org; Wed, 12 Sep 2007 21:14:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVdHp-0004mG-3K for netlmm@ietf.org; Wed, 12 Sep 2007 21:14:29 -0400 X-IronPort-AV: E=Sophos;i="4.20,247,1186383600"; d="scan'208";a="523357081" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 12 Sep 2007 18:14:28 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8D1ESug022649; Wed, 12 Sep 2007 18:14:28 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8D1ESat011696; Thu, 13 Sep 2007 01:14:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 18:14:28 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 18:14:27 -0700 From: "Sri Gundavelli" To: "'Kilian Weniger'" References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> Subject: RE: [netlmm] timestamp vs seqno redux Date: Wed, 12 Sep 2007 18:14:27 -0700 Message-ID: <011901c7f5a3$6dd04ab0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAlmf7Q X-OriginalArrivalTime: 13 Sep 2007 01:14:27.0708 (UTC) FILETIME=[6DFC63C0:01C7F5A3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6316; t=1189646068; x=1190510068; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20timestamp=20vs=20seqno=20redux |Sender:=20; bh=cKoJ6c18p5DAeELwbOjhI7SCCwRxF2rjEEK9BCtf9fE=; b=gYeqg1WHygfVq4w8pHLTwNBUGUUrlIsDoC4f86Mi8Zto9KRzpJY8jMSwU27KlCPMQstSPpnw lj4dpPYaQ1M98SqPm7iVmPDgXWXFLU18mCk9j2ey048DY87HGq1ZxrH6; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: Wednesday, September 12, 2007 1:07 AM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux > > Hi Sri, > > please see my comments inline. > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Mittwoch, 12. September 2007 08:14 > > To: 'Kilian Weniger' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > Hi Kilian/Federico, > > > > > > > > > -----Original Message----- > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > To: Sri Gundavelli > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > Hi Sri, > > > > > > my point is that NOT mandating synchronization to an > external clock > > > source for the timestamp option implies that sending PBU msgs with > > > timestamp option is allowed even when MAGs are not (yet) > > synchronized. > > > I.e., it would be allowed that a deployment uses only the returned > > > timestamps in PBA msgs to synchronize the MAG clocks. I think > > > the draft > > > should not allow this for the following reasons: > > > > > > > The stated assumption for the timestamp based approach to work, > > is the requirement for the MAG's to have synchronized clocks. > > That is a requirement. Now, if a given MAG sends a PBU with an > > incorrect timestamp, its an error and as you and Federico pointed > > out, there are cases where the LMA will not be able to determine > > the sending order of the received packets. This is an error > > condition, as the requirement is not met. > > Right, sending a PBU with timestamp option requires that the > MAG's clock > is synchronized. Hence, I don't see why the draft should specify a > mechanism to synchronize a MAG's clock using a received PBA. Also, I > think this mechanism has issues in some scenario (see my > previous mail). > The draft is not mandating on MAG to sync with the LMA clock. Its really upto the MAG on what do do. Its requiring the MAG to sync up to a clock source. I can slightly modify the below text suggesting it to sync up to LMAs clock. "If the received Proxy Binding Acknowledgement message has the Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), the mobile access gateway SHOULD try to register again only after it synchronized its clock with the local mobility anchor's system clock or to a common time source that is used by all mobility entities in that domain for their clock synchronization." > > The clock synchronization is the job of some PMIP-independent > synchronization method like NTP and out of sync clocks can > only occur if > there is a problem with this PMIP-independent synchronization method. > Hence, it is a non-recoverable error case from PMIP point of > view IMHO. > Sure. > > > > Now, should the draft state that the time synchronization is a > > requirement and additionally mandate a method of time > synchronization, > > say by NTP ? But, the later has a system wide impact and > additionally, > > a given architecture where this protocol is applied, can achieve the > > time synchronization through other non NTP means. IMO, we may not > > be able dictate that. Also, we want implementations to support the > > timestamp based scheme by default. Now, mandating the NTP usage will > > create some restrictions for some deployments. So, that is the > > reasoning behind not mandating the method of time synchronization. > > I'm not sure if the draft can say "a MAG's clock MUST be synchronized > for this protocol to work, but how this is done is out of scope of the > draft". I guess the draft has to mandate the implementation of one > "default" synchronization protocol such as NTP to achieve > interoperability. However, as long as the use of NTP is not mandated > (e.g., just say "SHOULD use"), deployments can still use > other methods. > So I don't see restrictions for deployments in this case. > I'm not sure, if we should mandate on NTP. The protocol has a requirement and I think, how deployments achieve that is not our issue. For ex, we need Routing between LMA and MAG. That's the assumption, we dont say there MUST be OSPF enabled between them. I really think, we should just state the requirement strongly and make a note that the mechanism will not work, if the requirement is not met. It is sufficient, IMHO. > > > > W.r.t this below scenario, the reason for LMA to return its > timestamp, > > solves two purposes. 1.) Diagnostics (especially useful when the LMA > > and MAG are in different admin domains) 2.) The MAG can detect that > > its clock is not in sync and take the necessary actions. I guess, > > Frederico has an issue with the second part. But, if you look at > > the recommendation from the draft on handling this error case, > > MAG signaling considerations, > > > > "If the received Proxy Binding Acknowledgement message has the > > Status field value set to TIMESTAMP_MISMATCH (Invalid > > Timestamp), > > the mobile access gateway SHOULD try to register again > > only after > > it synchronized its clock with the local mobility > > anchor's system > > clock or to a common time source that is used by all mobility > > entities in that domain for their clock synchronization." > > > > I think it is good if the LMA informs the MAG about detected > out of sync > clocks for the purpose of diagnostics and as a trigger for > re-sync. But > why do we need the timestamp option in the PBA? The TIMESTAMP_MISMATCH > value in the status field is enough for the purpose of diagnostics and > as a trigger for re-sync. > Returning just an error code is not sufficient. It will be very hard to run any diagnostics. I suggest we leave this. I'm ok on not stating that the MAG should not sync up to the LMA's clock and should use a common clock source. The returned timestamp is also used for matching request to response. So, we can leave this there. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 03:18:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IViy7-0005lk-QZ; Thu, 13 Sep 2007 03:18:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IViy5-0005lc-Pr for netlmm@ietf.org; Thu, 13 Sep 2007 03:18:29 -0400 Received: from cluster-f.mailcontrol.com ([85.119.2.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IViy4-0005SH-4S for netlmm@ietf.org; Thu, 13 Sep 2007 03:18:29 -0400 Received: from rly17f.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly17f.srv.mailcontrol.com (MailControl) with ESMTP id l8D7IMLh019781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Sep 2007 08:18:22 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly17f.srv.mailcontrol.com (MailControl) id l8D7I2S2018856 for netlmm@ietf.org; Thu, 13 Sep 2007 08:18:02 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly17f-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8D7HxSW018700; Thu, 13 Sep 2007 08:18:01 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 7f30_a935611c_61c8_11dc_96c2_0030482aac25; Thu, 13 Sep 2007 09:12:16 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091309175607-166590 ; Thu, 13 Sep 2007 09:17:56 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.101,BAYES_00: -1.665,TOTAL_SCORE: -1.564 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 13 Sep 2007 09:18:24 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] timestamp vs seqno redux In-Reply-To: <011901c7f5a3$6dd04ab0$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAlmf7QAAwgPsA= References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <011901c7f5a3$6dd04ab0$d5f6200a@amer.cisco.com> To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48ABC9@lan-ex-02.panasonic.de> Date: Thu, 13 Sep 2007 09:17:37 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.70.1.127 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, the simple method of using the timestamp in the PBA sent by the LMA to sync MAG's clock has issues in some scenarios IMO. As explained in the previous emails of this thread, these issues can lead to unsuccessful clock sync and wrong BCEs, which in turn may result in significant packet loss. Do you agree that this can happen?=20 If so, my suggestion is to disallow the synchronization of MAG's clock using the timestamp in the PBA as specified in the draft currently. At least there should be some text in the draft explaining the issues to the reader, so that an implementor is aware of them. Please note that I'm only talking about *synchronization of MAG's clock using the timestamp in the PBA*. Using the timestamp in PBUs to re-order PBUs is not related to that and ok (under the assumption that the MAGs' clocks are synchronized using some PMIP-independent mechanism like NTP) Please see some more comments inline.=20 BR, Kilian > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Donnerstag, 13. September 2007 03:14 > To: 'Kilian Weniger' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Kilian, > =20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > > Sent: Wednesday, September 12, 2007 1:07 AM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri,=20 > >=20 > > please see my comments inline. > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > > > Sent: Mittwoch, 12. September 2007 08:14 > > > To: 'Kilian Weniger' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Kilian/Federico, > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri, > > > >=20 > > > > my point is that NOT mandating synchronization to an=20 > > external clock > > > > source for the timestamp option implies that sending=20 > PBU msgs with > > > > timestamp option is allowed even when MAGs are not (yet)=20 > > > synchronized. > > > > I.e., it would be allowed that a deployment uses only=20 > the returned > > > > timestamps in PBA msgs to synchronize the MAG clocks. I think=20 > > > > the draft > > > > should not allow this for the following reasons: > > > >=20 > > >=20 > > > The stated assumption for the timestamp based approach to work, > > > is the requirement for the MAG's to have synchronized clocks. > > > That is a requirement. Now, if a given MAG sends a PBU with an > > > incorrect timestamp, its an error and as you and Federico pointed > > > out, there are cases where the LMA will not be able to determine > > > the sending order of the received packets. This is an error > > > condition, as the requirement is not met. > >=20 > > Right, sending a PBU with timestamp option requires that the=20 > > MAG's clock > > is synchronized. Hence, I don't see why the draft should specify a > > mechanism to synchronize a MAG's clock using a received PBA. Also, I > > think this mechanism has issues in some scenario (see my=20 > > previous mail). > >=20 >=20 > The draft is not mandating on MAG to sync with the LMA clock. Its > really upto the MAG on what do do. Its requiring the MAG to sync up > to a clock source. I can slightly modify the below text suggesting > it to sync up to LMAs clock. >=20 > "If the received Proxy Binding Acknowledgement message has the > Status field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), > the mobile access gateway SHOULD try to register again only after > it synchronized its clock with the local mobility anchor's system > clock or to a common time source that is used by all mobility > entities in that domain for their clock synchronization." > =20 >=20 >=20 > >=20 > > The clock synchronization is the job of some PMIP-independent > > synchronization method like NTP and out of sync clocks can=20 > > only occur if > > there is a problem with this PMIP-independent=20 > synchronization method. > > Hence, it is a non-recoverable error case from PMIP point of=20 > > view IMHO.=20 > >=20 >=20 > Sure. >=20 > > >=20 > > > Now, should the draft state that the time synchronization is a > > > requirement and additionally mandate a method of time=20 > > synchronization, > > > say by NTP ? But, the later has a system wide impact and=20 > > additionally, > > > a given architecture where this protocol is applied, can=20 > achieve the > > > time synchronization through other non NTP means. IMO, we may not > > > be able dictate that. Also, we want implementations to support the > > > timestamp based scheme by default. Now, mandating the NTP=20 > usage will > > > create some restrictions for some deployments. So, that is the > > > reasoning behind not mandating the method of time synchronization. > >=20 > > I'm not sure if the draft can say "a MAG's clock MUST be=20 > synchronized > > for this protocol to work, but how this is done is out of=20 > scope of the > > draft". I guess the draft has to mandate the implementation of one > > "default" synchronization protocol such as NTP to achieve > > interoperability. However, as long as the use of NTP is not mandated > > (e.g., just say "SHOULD use"), deployments can still use=20 > > other methods. > > So I don't see restrictions for deployments in this case.=20 > >=20 >=20 > I'm not sure, if we should mandate on NTP. The protocol has a=20 > requirement > and I think, how deployments achieve that is not our issue. For ex, we > need Routing between LMA and MAG. That's the assumption, we dont say=20 > there MUST be OSPF enabled between them. I really think, we=20 > should just > state the requirement strongly and make a note that the mechanism will > not work, if the requirement is not met. It is sufficient, IMHO. If this is really sufficient for standards track, I'm fine with not mandating any time sync protocol. >=20 > > >=20 > > > W.r.t this below scenario, the reason for LMA to return its=20 > > timestamp, > > > solves two purposes. 1.) Diagnostics (especially useful=20 > when the LMA > > > and MAG are in different admin domains) 2.) The MAG can=20 > detect that > > > its clock is not in sync and take the necessary actions. I guess, > > > Frederico has an issue with the second part. But, if you look at > > > the recommendation from the draft on handling this error case, > > > MAG signaling considerations,=20 > > >=20 > > > "If the received Proxy Binding Acknowledgement=20 > message has the > > > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > > > Timestamp), > > > the mobile access gateway SHOULD try to register again=20 > > > only after > > > it synchronized its clock with the local mobility=20 > > > anchor's system > > > clock or to a common time source that is used by=20 > all mobility > > > entities in that domain for their clock synchronization." > > >=20 > >=20 > > I think it is good if the LMA informs the MAG about detected=20 > > out of sync > > clocks for the purpose of diagnostics and as a trigger for=20 > > re-sync. But > > why do we need the timestamp option in the PBA? The=20 > TIMESTAMP_MISMATCH > > value in the status field is enough for the purpose of=20 > diagnostics and > > as a trigger for re-sync.=20 > >=20 >=20 > Returning just an error code is not sufficient. It will be=20 > very hard to > run any diagnostics. I suggest we leave this. I'm ok on not stating > that the MAG should not sync up to the LMA's clock and should use a=20 > common clock source. The returned timestamp is also used for matching You mean "stating" or "not stating"?=20 I'm not against syncing up to the LMA's clock per se. The point is that the timestamp in the PBA should not be used to do that. Instead, a dedicated sync protocol like NTP (which also considers packet delay) should be used to sync up to LMA's clock. > request to response. So, we can leave this there. >=20 >=20 > Sri >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 04:10:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVjms-0006kI-CQ; Thu, 13 Sep 2007 04:10:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVjmq-0006SP-B8 for netlmm@ietf.org; Thu, 13 Sep 2007 04:10:56 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVjmo-0006i1-V5 for netlmm@ietf.org; Thu, 13 Sep 2007 04:10:56 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1169322uge for ; Thu, 13 Sep 2007 01:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=wnVyOFEcuSJXxk0Mm7u6LQeAAdSCRnnzL4mgd7497l8=; b=U87zHWDZONs1BwysWZWfyejGOt9pSdJzv61XA0Yo1kkXKG8NOFyvx/dPsdjdZB6SvWg60R663mwbmR7NgOyr3TFnjJfpCaZDFFeTFkuspFPyStQG3xYOUwsogGSkk6Ag+IxXMt4ggCjCN//EzTYoyLBjASG1XLaHRUJCuhXHE5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=P45nuhLkk+vFFqEGZIXTZj+nMaqOjGtExAEERaWnNKPBab+M+hKAoL/PFnfNBDAQcRHrYuWND/VEPQCFgNQSBFyPFamvv5hpv4WDNxGL6LqoQvZU9f5Foteb8PePd+dOAAMiZ7ZOGt56vsI8lgvwupCwJYsubkP9AEf5yYOIvVE= Received: by 10.66.222.9 with SMTP id u9mr2785019ugg.1189671053063; Thu, 13 Sep 2007 01:10:53 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id u1sm710062uge.2007.09.13.01.10.51 (version=SSLv3 cipher=OTHER); Thu, 13 Sep 2007 01:10:52 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Thu, 13 Sep 2007 10:10:48 +0200 User-Agent: KMail/1.9.6 References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200709131010.48638.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Domagoj, I disagree with one of your comment below: On Wednesday 12 September 2007, Premec, Domagoj wrote: > >6.3. =A0Supported Access Link Types > > > > =A0 This specification supports only point-to-point access link types > > and thus it assumes that the mobile node and the mobile access > > gateway are the only two nodes on the access link. =A0The link is > > assumed to have multicast capability. > > I understand that the decision to use per-MN prefix model was > motivated by the need to emulate the point-to-point link at the IP > layer.=20 Not true.=20 Use of a per-MN prefix model has been motivated by the need to avoid=20 multilink subnet issues [RFC4903]. =46ollowing that prefix model choice, we have discussed at length on that=20 mailing list what are the implication of that model on the supported=20 underlying link (i.e. below IP). The per-MN prefix on a pt-to-pt link=20 has no issue. It is not clear however if it would work well on a shared=20 link. The consensus of the WG has been that the current spec will be=20 limited to support of pt-to-pt links. Support for shared link can be added later in another specification. > As the IP layer is configured in such a way that there are=20 > exactly two nodes on the link, we're actually independet of the > underlaying link layer technology.=20 No configuration of the IP layer can restrict the number of nodes on a=20 link. The link properties are independent from those of the IP layer. > I think the intent of the spec is to support any access link type, > including for example 802.11.=20 I think the intent of the spec is to support only pt-to-pt links for now=20 since that's the only type of link where the per-MN prefix model has no=20 known issues. > The first sentence, claiming support only for point-to-point link > types, is too restrictive.=20 That has been the consensus of the WG. You might disagree. > Maybe it could be reformulated to make it clear that point-to-point > property is realized at the IP layer.=20 There's no way to realize a property of the link at the IP layer. A link=20 is below IP... Best, =2D-julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 05:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVkna-0007g8-4N; Thu, 13 Sep 2007 05:15:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVknZ-0007g3-Di for netlmm@ietf.org; Thu, 13 Sep 2007 05:15:45 -0400 Received: from mout.perfora.net ([74.208.4.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVknZ-0007oK-2N for netlmm@ietf.org; Thu, 13 Sep 2007 05:15:45 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IVknB1Qhm-0007Ou; Thu, 13 Sep 2007 05:15:31 -0400 From: "Alper Yegin" To: "'Premec, Domagoj'" , "'Sri Gundavelli'" , "'Chowdhury, Kuntal'" Subject: RE: [netlmm] Significance of MN-Identifier Date: Thu, 13 Sep 2007 12:15:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <3C31CDD06342EA4A8137716247B1CD6802941BC7@zagh223a.ww300.siemens.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZgAATcTHAAAJrNcAAy8iHA Message-Id: <0MKpCa-1IVknB1Qhm-0007Ou@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18ISYfs6xqdB1ITt+jvR7FZ9rY5lFPY2RA90Dy 3AbTfzA29F0pBQM7fmdeAj6+z9OT1OMD7iNBqT8Zl6/1TEUHSv 2ZeoPLQrGet5VFtohXTpQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Domagoj, > > - Use of RFC 4285 with MAG-LMA SA is one of the possible > > security models. > > And that requires carrying the "MAG id" in the NAI. Assuming > > the NAI always carries some "MN id" as the current spec does > > is disallowing this possibility. > > Why is MAG id in the NAI option required for rfc 4285? The LMA could use > the SPI from the auth option to identify the MAG. The NAI option can still > carry the NAI of the MN. Would that work? Only the combination of SPI with some other node identifier (e.g., IP address or NAI) can uniquely identify an SA. In the case of RFC4285, it's the NAI. I still don't understand why NAI must always carry MN's NAI. It's only needed when HNP is not assigned. When it is assigned, we don't need that. Alper _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 05:23:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVkv6-0004PG-Ml; Thu, 13 Sep 2007 05:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVkv4-0004Os-V7 for netlmm@ietf.org; Thu, 13 Sep 2007 05:23:30 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVkv3-0007sM-GG for netlmm@ietf.org; Thu, 13 Sep 2007 05:23:30 -0400 Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IVkut3tJE-0008Ux; Thu, 13 Sep 2007 05:23:28 -0400 From: "Alper Yegin" To: "'Ahmad Muhanna'" , "'Sri Gundavelli'" , "'Chowdhury, Kuntal'" Subject: RE: [netlmm] Significance of MN-Identifier Date: Thu, 13 Sep 2007 12:23:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437116B49A4C@zrc2hxm2.corp.nortel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acfz4ysg9DIwxAs2Tc2jO2vc2pv0mwAawfOAABOkQaAABpFssAATUaZgAATcTHAAGkVXIAAZdmbA Message-Id: <0MKp8S-1IVkut3tJE-0008Ux@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18yIVo0iqHWVpMrAuuWagINAl0guzL05sNSH6i 091NIgkvcos7QwqnRuHcvnDI2XvvlxbaLq5Olw67YrqU6O4/f0 zVm2T6E0PRRw0NQUN/+YA== X-Spam-Score: -0.0 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad, Not sure where the "multilayered complexity" is, but to re-iterate... Another alternative to IPsec is to use RFC4285. One mode to use RFC4285 is to rely on per-MAG-LMA SA. In that model, "MAG" appears as the "proxy MN" (pMN). RFC4285 security needs to authenticate the pMN. And that's when the NAI shall identify the pMN, not a specific MN behind the pMN. ... Going back to the current spec now... It assumes NAI always identifies the MN. This is not necessary. Why such an over-specification when we cannot even figure out how to identify the MN?? NAI shall identify the MN only when HNP is not assigned. And let the spec be silent about whether NAI is used, or what NAI carries when the HNP is already in the PBU. That's the proposed change. ... Unless we are trying to block use of RFC4285 (a separate discussion if necessary), I cannot see any technical reason why this change is not acceptable. Alper > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Thursday, September 13, 2007 12:35 AM > To: Alper Yegin; Sri Gundavelli; Chowdhury, Kuntal > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Significance of MN-Identifier > > Hi Alper, > Please see comments inline. > > Regards, > Ahmad > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > Sri, > > > > You are explaining how carrying some identifier representing > > the MN is useful. Not explaining why "it MUST always be carried". > > > > My point is two-fold: > > > > - There is one very strong case that the HNP is allocated as > > part of the network access authentication. In that case, we > > don't have to rely on "some identifier representing the MN", > > instead HNP is already bound to the MN. HNP becomes that identifier. > > > > - Use of RFC 4285 with MAG-LMA SA is one of the possible > > security models. > > And that requires carrying the "MAG id" in the NAI. Assuming > > the NAI always carries some "MN id" as the current spec does > > is disallowing this possibility. > > [Ahmad] > I guess this a multilayered complexity question which probably needs to > have several different threads to address them. However, we are forced > to handle them all together in a single thread! > IMO, You already assumed the following: > > 1. RFC4285 is used for PMIPv6. ? > 2. RFC4285 has a mechanism to securely protect P-BU and P-BA based on a > MAG-LMA SA. Similar to FA-HA AE!? :-( > 3. The LMA is able to distinguish that the ID included in the BU is the > MAG-ID. > > Now: If the MAG is able to somehow identify that the ID included is the > MAG ID, then why there is a problem if the MN-ID is included.? May be I > am missing something here. > > > > > My proposal is to relax that language so that NAI is not > > "always" supposed to carry a "MN id". Specific exception case > > is when the MN is already assigned a HNP by an out-of band mechanisms. > > [Ahmad] > I am not sure where these series of relaxation will end up getting this > draft? > > > > > Alper > > > > > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Wednesday, September 12, 2007 9:29 AM > > > To: 'Alper Yegin'; 'Chowdhury, Kuntal' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > Hi Alper, > > > > > > > > > > -----Original Message----- > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > Sent: Tuesday, September 11, 2007 2:08 PM > > > > To: 'Chowdhury, Kuntal'; 'Sri Gundavelli' > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > Hi Kuntal, > > > > > > > > > I don't know what the issue is for MN-ID in the PMIP6 signaling > > > > > messages. Could you explain why we are having this debate? > > > > > > > > Because, the current text is locking all PMIP6 deployments to one > > > > security model and not leaving any room for using > > anything else. And > > > > it is doing so without a good reason (unintentionally, I believe). > > > > > > > > > MN-ID is the unique identifier to identify the session > > > > state in the LMA. > > > > > > > > It is necessary only of the MN does not know its HNP. As > > soon as it > > > > knows the HNP (e.g., when HNP is assigned during network access > > > > authentication), we can rely on HNP to identify the session state. > > > > > > > > > > HNP is dynamically generated. Initially, a MN may not have been > > > allocated any HNP, in that we have to send the MN identity > > for the LMA > > > to apply the proper policy checks and allocate a prefix. > > > After that point, when the mobile moves to a new MAG, the > > MAG on the > > > link would likely authenticate the MN, obtain its id before > > it allows > > > the MN for network access. So, most likely the new MAG > > would know the > > > MN id as supposed to knowing its allocated prefix, that may > > be in the > > > BCE state (unless statically configured in AAA). > > > > > > Generally, I can see 3775 HA, identifying a MN with its HoA > > and so not > > > requiring the id in the signaling messages. But, in a proxy > > model in > > > combination with dynamic prefix allocation, is it not reasonable to > > > carry an identifier of the mobile node in the messages ? Thats the > > > stable identifier of the mobile node. > > > Its definetly more stable than an allocated prefix. The MAG may > > > authenticate the mobile node on the access link and will mo > > t likely > > > have some form of identifier, as supposed to it knowing the prefix > > > that is allocated by the LMA. Id is also required for > > billing purposes > > > as well and may very well be the corelation id. > > > > > > I do not think, we introduced this id requirement, just with one > > > scenario in mind. Its a very natural requirement and the > > information > > > is there on the MAG. Do not know, why this would be an > > issue for WiMAX > > > case. > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > There are several good reasons to mandate the presence of > > > > MN-ID in the > > > > > PBU/PBA. For example, it helps to identify the session > > > > state in the LMA > > > > > for PMIP6 - MIP6 transition scenarios, when the LMA is > > > > collocated with a > > > > > MIP6 HA. > > > > > > > > Can you elaborate on this scenario? You may have > > something here, but > > > > I need to understand. > > > > > > > > Alper > > > > > > > > > > > > > Note that during IKEv2 exchange for MIP6, the IDi field (that > > > > > carries the same MN-ID) in the IKE packets help identify the > > > > > ongoing > > > > > (PMIP6) session related to the MN. > > > > > > > > > > Hope this helps. > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > > Sent: Tuesday, September 11, 2007 3:46 AM > > > > > > To: 'Sri Gundavelli' > > > > > > Cc: netlmm@ietf.org > > > > > > Subject: RE: [netlmm] Significance of MN-Identifier > > > > > > > > > > > > Sri, > > > > > > > > > > > > > At handoff, nMAG may not know the HNP of the mobile > > > > node. How does > > > > > it > > > > > > > communicate with the LMA about the MN, if MN-Id is not > > > > used ? That's > > > > > > > is essential, its required in BCE and also in signaling > > > > messages. > > > > > > > > > > > > > > > > > > So it is just for HNP assignment as I was saying: > > > > > > > > > > > > >>> Is it for the sake of identifying the MN during > > dynamic HNP > > > > > > >>> assignment in-band with PMIP? > > > > > > > > > > > > > > > > > > HNP can be assigned during network access authentication. I > > > > > > can't > > > > > imagine > > > > > > when this is not possible or desirable. > > > > > > > > > > > > That's why mandating presence of MN-id that identifies > > > > the MN is not > > > > > > necessary, imo. > > > > > > > > > > > > If people can show a reason why we must also support HNP > > > > assignment > > > > > in- > > > > > > band > > > > > > with PMIP, we can say: > > > > > > > > > > > > When the HNP in PBU has the value 0::/0, an NAI > > [RFC4283] > > that > > > > > > carries the MN-id MUST be included in the PBU. > > > > > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > >> Sri > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >>> -----Original Message----- > > > > > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > > > > >>> Sent: Monday, September 10, 2007 4:27 AM > > > > > > > >>> To: netlmm@ietf.org > > > > > > > >>> Subject: [netlmm] Significance of MN-Identifier > > > > > > > >>> > > > > > > > >>> What's the significance of MN-Identifier as > > carried in PBU? > > > > > > > >>> > > > > > > > >>> Is it for the sake of identifying the MN during dynamic > > > > > > > >>> HNP > > > > > > assignment > > > > > > > >>> in-band with PMIP? > > > > > > > >>> > > > > > > > >>> If so, given that the HNP may also be assigned > > > > during network > > > > > access > > > > > > > >>> authentication (out-of band with PMIP, as > > commonly done in > > > > > > integrated > > > > > > > >>> bootstrapping scenarios), we shall not mandate that the > > > > > > > >>> MN- > > > > > > identifier > > > > > > > >>> identifies the real MN. > > > > > > > >>> > > > > > > > >>> Another way of using of MN-identifier is to > > identify the > > > > > > > >>> "proxy MN" (MAG) with RFC 4285. > > > > > > > >>> > > > > > > > >>> Alper > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> _______________________________________________ > > > > > > > >>> netlmm mailing list > > > > > > > >>> netlmm@ietf.org > > > > > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netlmm mailing list > > > > > > netlmm@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > "This email message and any attachments are confidential > > > > information of > > > > > Starent Networks, Corp. The information transmitted may not > > > > be used to > > > > > create or change any contractual obligations of Starent > > > > Networks, Corp. > > > > > Any review, retransmission, dissemination or other use of, > > > > or taking of > > > > > any action in reliance upon this e-mail and its attachments > > > > by persons or > > > > > entities other than the intended recipient is prohibited. > > > > If you are not > > > > > the intended recipient, please notify the sender > > immediately -- by > > > > > replying to this message or by sending an email to > > > > > postmaster@starentnetworks.com -- and destroy all copies of > > > > this message > > > > > and any attachments without reading or disclosing their > > > > contents. Thank > > > > > you." > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 05:38:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVl9L-0003WM-Kz; Thu, 13 Sep 2007 05:38:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVl9K-0003WF-KX for netlmm@ietf.org; Thu, 13 Sep 2007 05:38:14 -0400 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVl9H-0008HF-Bo for netlmm@ietf.org; Thu, 13 Sep 2007 05:38:14 -0400 Received: from rly28e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly28e.srv.mailcontrol.com (MailControl) with ESMTP id l8D9brIt030921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Sep 2007 10:38:03 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly28e.srv.mailcontrol.com (MailControl) id l8D9bmip030516 for netlmm@ietf.org; Thu, 13 Sep 2007 10:37:48 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly28e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8D9bhT4030298; Thu, 13 Sep 2007 10:37:47 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 7ed9_2ebc6034_61dc_11dc_85d4_0030482aac25; Thu, 13 Sep 2007 11:32:01 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091311373427-179298 ; Thu, 13 Sep 2007 11:37:34 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.101,BAYES_00: -1.665,TOTAL_SCORE: -1.564 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 13 Sep 2007 11:37:58 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] timestamp vs seqno redux In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B4978F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAMXqxQAAWRX+AAAB568AAE2X+QABvRPKA= References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de><6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <1FEB9B9F2EC38343955D02B2AE86AACB48ABB7@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4978F@zrc2hxm2.corp.nortel.com> To: "Ahmad Muhanna" , "Sri Gundavelli" , "DE JUAN HUARTE FEDERICO" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48AC13@lan-ex-02.panasonic.de> Date: Thu, 13 Sep 2007 11:36:45 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.69.1.138 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ddfd5a9c868cfab7d9493f20ea6d0fa3 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, the issue only occurs when d2=3D~-d1 (PBU delay =3D~ amount that MAG's = clock is ahead of LMA's clock). Then the LMA doesn't send a PBA with timestamp_mismatch status code and MAG doesn't compute a delta. I agree that the probability that this situation will occur may be low, but the consequences can be serious: Wrong BCE and packet loss till the next PBU. Is this acceptable? I'm not sure.=20 Furthermore, I don't really understand why we can't rely on an outside mechanism like NTP. Is there any scenario where NTP fails, but the PBA-based time sync does not fail? Please see my email to Sri for suggestions to move on. Some more comments inline.=20 BR, Kilian > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Mittwoch, 12. September 2007 22:20 > To: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Kilian, >=20 > Please see comments inline. >=20 > Regards, > Ahmad > =20 > >=20 > > > -----Original Message----- > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > Sent: Mittwoch, 12. September 2007 17:41 > > > To: Ahmad Muhanna; Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE=20 > > > FEDERICO > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Resending hopefully with the correct format. > >=20 > > thanks for re-sending. Much better to read now ;) > >=20 > > >=20 > > > +++++ > > >=20 > > > Hi Kilian/Federico and All, > > >=20 > > > There has been a lot of email exchange that the timestamp=20 > > > synchronization using the PMIPv6 signaling does not work.=20 > > On the other=20 > > > hand, I have not seen any in detail analysis which proves=20 > > that it does=20 > > > not work. I would like to share in details my thoughts on=20 > how this=20 > > > SHOULD work and please comment as necessary. > >=20 > > In one of my previous emails I described an example scenarios=20 > > where it fails, at least according to my understanding of the=20 > > sync method. > > According to my understanding, the LMA only sees a delta time=20 > > consisting of two parts: 1.) transmission delay of PBU (d2 in=20 > > your example) and 2.) clock difference (d1 in your example).=20 > > The problem is that the LMA doesn't know d1 and d2 itself, it=20 > > only knows d1+d2. If d2=3D~-d1, i.e., MAG's clock is ahead of=20 > > LMA's clock by a value that is roughly equal to the=20 > > transmission delay, then d1+d2=3D~0, i.e., the LMA doesn't see=20 > > any delta and assumes that the MAG's clock is in sync (which=20 > > is not true). > > Hence, no re-sync happens and the LMA may accept outdated=20 > > PBUs (see my previous email). >=20 > [Ahmad] > Kilian, >=20 > This is the same race condition that we have discussed too many times When did we discuss the scenario where d2=3D~-d1 before? Can you please give me a pointer? > and people do not like to accept the unpopular solution :-) I have no > problem with that. But let us exactly identify all conditions=20 > related to > the scenario: >=20 > 1. A race condition scenario which happens during handoff. >=20 > 2. It assumes that the MAGs are not properly synchronized with each > other using an outside mechanism. We are here talking here about the > MAGs not the (LMA and MAGs). In other words, if the MAGs in the same > local domain are synchronized this issue will never happen. If you assume that the clocks of all MAGs are always properly synchronized using an outside mechanism, why do you want to specify a mechanism to synchronize the MAG's clock using timestamps in PBAs? >=20 > 3. It assumes that the pMAG sent a P-BU as a re-registration in a race > condition as the MN moves from pMAG (previous MAG) to nMAG (next MAG). >=20 > 4. Due to some network conditions, the P-BU of the pMAG arrives at the > LMA after the P-BU of the nMAG. >=20 > 5. It also assumes that not only pMAG and nMAG is out of=20 > sync, but also > nMAG is slower than pMAG by almost double the delta between=20 > any of them > and the LMA. >=20 > 6. Not only that but also, the nMAG is slower enough to the=20 > degree that > when the P-BU arrives at the LMA it is within the threshold. >=20 >=20 > Finally, > -------- > I am not saying that the possibility of this scenario to=20 > happen is ZERO. > No. There is a possibility that it MAY happen but , at the=20 > same time, it > is very very slim. Not only that, I think according to the=20 Maybe the probability that it happens is quite low, but the consequences can be serious: Wrong BCE and packet loss till the next PBU. > PMIPv6 draft, > MAG needs to make sure that the MN is currently attached=20 > before sending > a re-registration P-BU. If the MAG is not sure, then MAG does not send > the P-BU. Why is this related to the scenario in discussion? The MAG does not send a PBU if the MN is not attached. >=20 > NOW: what can we do about it: > ----------------------------- >=20 > 1. The very famous but un-popular solution that we mentioned several > time. In case of handoff, i.e. when the LMA receives the P-BU=20 > from nMAG, > LMA considers this as a case of handoff. When LMA receives a P-BU from > the pMAG, LMA drops or rejects it with a code MN-in-handoff, for > example. Since it is a race condition, that will take care of it. >=20 > 2. LMA needs to track the delta for each MAG. Then after the=20 > P-BU passes > the LMA timestamp check and in case of handoff, LMA can=20 > always make sure > that the adjusted timestamp of the received P-BU is always larger than > the adjusted timestamp of the last received P-BU which is=20 > already saved > as part of the MN BCE. As you said this was already discussed and there was no consensus for it AFAIK. I don't understand why we cannot just rely on the outside time sync mechnanism like NTP? What is the problem with using a protocol like NTP, which was specifically designed to sync time? Why do we need a second time sync mechanism based on PBAs? >=20 > I hope that this will take care of this issue and we can finally move > on. >=20 > Best Regards, > Ahmad >=20 > BTW: please see more comments below. >=20 > >=20 > > Please see some more comments inline. > >=20 > > >=20 > > > The following are a list of assumptions: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > 1. The time that the P-BU takes from MAG to LMA equals=20 > the time the=20 > > > P-BA takes from LMA to MAG. > >=20 > > What is behind this assumption? Why not introduce another=20 > > variable d3 for PBA delay (in addition to d2 for PBU delay). >=20 > [Ahmad] > Actually d3 is irrelevant in this regard. Because the timestamp delta > that the MAG is tracking does not depend on d3, because, MAG considers > the timestamp delta as the difference between the=20 > LMA-timestamp in P-BA > (which is independent of d3) and the MAG-timestamp in the=20 > corresponding > P-BU (which is again independent of d3).=20 >=20 > This means that regardless of the delay in the downlink=20 > direction, only > the delay in the uplink direction has an impact and that impact is > already factored IN and does not influence synchronization scheme. >=20 > >=20 > >=20 > > > 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > > > comparing timestamp in P-BU and LMA current timestamp. > > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > > timestamp for calculating the delta! > > > 4. MAG and LMA maintains the same out of sync delta during the=20 > > > re-synchronization process. > > >=20 > > >=20 > > > MAG =20 > LMA > > > ---------- =20 > > ---------- > > > 1. Current Timestamp MAG.t1 LMA.t1 =3D=20 > > MAG.t1 +d1 > > > 2. Timestamp in P-BU MAG.t1 LMA=20 > timestamp: LMA.t1 > > > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) > > >=20 > > > 4. P-BU arrives at LMA .............. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> > > > P-BU(MAG.t1) > > >=20 > > > 5. Arrival Timestamp MAG.t1 + d2 LMA.t1 + d2 > > > 6. delta based on P-BU timestamp (LMA.t1 +=20 > > d2)-(MAG.t1) > > > =3D > > > =20 > > > ((MAG.t1+d1)+d2) - MAG.t1 > > > =3D > > > =20 > delta.P-BU =3D d2+d1 > >=20 > > right, d2+d1 is the delta that the LMA measures. >=20 > [Ahmad] > Correct. Measured from the MAG timestamp. Right? >=20 > >=20 > > >=20 > > > 7. Real delta delta.real =3D = d1 > >=20 > > How is the real delta d1 known by the LMA? >=20 > [Ahmad] > LMA does not need to know it. As long as the scheme works to > resynchronize the MAG with the LMA, no need for LMA to know it. Right? ok > =20 > >=20 > > >=20 > > >=20 > > >=20 > > > 8. Timestamp in P-BA MAG.t2 LMA.t2 =3D=20 > > (LMA.t1 + d2) > > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > How does the LMA know d2? IMO, LMA only knows delta.P-BU =3D d2+d1.=20 >=20 > [Ahmad] > Absolutely. LMA does not know what d2 and does not need to.=20 > This is used > for proving the scheme.=20 ok >=20 > > Hence, P-BA can only contain LMA.t2 =3D (LMA.t1 + delta.P-BU) =3D=20 > > (LMA.t1 + > > d1 + d2) >=20 > [Ahmad] > I am afraid that is not correct. You probably meant to say: LMA.t2 =3D > (MAG.t1 + (d1+d2)). Right? > Otherwise, LMA.t2 in terms of LMA.t1 is as follows: LMA.t2 =3D LMA.t1 = + > d2. NO? right, P-BA contains current timestamp of LMA, which is LMA.t2 =3D = LMA.t1 + d2. >=20 > >=20 > > > 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 > > > 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in corresponding=20 > > > P-BU) > > > =3D > > > (LMA.t1 + d2) - MAG.t1 > > > =3D > > > ((MAG.t1 +d1)+d2) -MAG.t1 > > >=20 > > > delta =3D d1+d2 > >=20 > > delta should be d1+2*d2 >=20 > [Ahmad] > No. That is not correct. Delta =3D d1+d2. Please see above comment. right, delta is d1+d2. >=20 > >=20 > > >=20 > > > 11. Real delta delta.real =3D d1 > >=20 > > How does the LMA know the real delta? >=20 > [Ahmad] > It does not need to know. ONLY MAG needs to track a delta=20 > with the LMA. > Well, we can make both track each other deltas but that will=20 > be too much > for the LMA and , honestly, it is not needed. > =20 > >=20 > > BR, > >=20 > > Kilian > >=20 > >=20 > > >=20 > > >=20 > > > What is the problem here? Or am I missing something? > > > Let us examine a re-registration or a P-BU/PA exchange=20 > based on the=20 > > > above synchronization: > > >=20 > > >=20 > > > MN- Resynchronization/Re-registration: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > 12. Current timestamp MAG.t3 LMA.t3 =3D=20 > > MAG.t3 + d1 > > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 > > > 14. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t3=20 > + (d2+d1)) > > >=20 > > > 15. P-BU arrives at LMA = .......=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>=20 > > P-BU(MAG.t3+(d1+d2)) > > > 16. Arrival Timestamp MAG.t3 + d2 LMA.t3 + d2 > > > 17. delta based on P-BU =20 > > > (LMA.t3+d2)-(MAG.t3+(d2+d1)) > > > =3D > > > =20 > > > ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1)) > > > =3D > > >=20 > > > delta.P-BU =3D = ZERO > > > 18. Real delta delta.real =3D = ZERO right.=20 The issue only occurs when d2=3D~-d1, because then the LMA doesn't send = a PBA with timestamp_mismatch status code and MAG doesn't compute a delta. This scenario is not shown in your diagrams... BR, Kilian > > >=20 > > > Please let me know what I am missing. > > > If nothing, I hope we can put an end to this debate and MOVE ON. > > >=20 > > > Regards, > > > Ahmad > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Muhanna, Ahmad (RICH1:2H10) > > > > Sent: Wednesday, September 12, 2007 9:59 AM > > > > To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE=20 > FEDERICO' > > > > Cc: 'netlmm@ietf.org' > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Kilian/Federico and All, > > > >=20 > > > >=20 > > > > There has been a lot of email exchange that the timestamp=20 > > > > synchronization using the PMIPv6 signaling does not=20 > work. On the=20 > > > > other hand, I have not seen any in detail analysis which=20 > > proves that=20 > > > > it does not work. I would like to share in details my=20 > thoughts on=20 > > > > how this SHOULD work and please comment as necessary. > > > >=20 > > > > The following are a list of assumptions: > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > 1. The time that the P-BU takes from MAG to LMA equals=20 > > the time the=20 > > > > P-BA takes from LMA to MAG. > > > > 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > > > > comparing timestamp in P-BU and LMA current timestamp. > > > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > > > timestamp for calculating the delta! > > > > 4. MAG and LMA maintains the same out of sync delta during the=20 > > > > re-synchronization process. > > > >=20 > > > >=20 > > > >=20 > > > > MAG =20 > > > > LMA > > > > ---------- =20 > > > > ---------- > > > > 1. Current Timestamp MAG.t1 =20 > > > > LMA.t1 =3D MAG.t1 +d1 > > > > 2. Timestamp in P-BU MAG.t1 LMA=20 > > > > timestamp: LMA.t1 > > > > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) > > > > 4. P-BU arrives at LMA .......................=20 > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t1) > > > > 5. Arrival Timestamp MAG.t1 + d2 =20 > > > > LMA.t1 + d2 > > > >=20 > > > > 6. delta based on P-BU timestamp =20 > > > > (LMA.t1 + d2) - (MAG.t1) > > > > =20 > > > > =3D > > > > =20 > > > > ((MAG.t1+d1)+d2) - MAG.t1=09 > > > > =20 > > > > =3D > > > > =20 > > > > delta.P-BU =3D d2+d1 > > > >=20 > > > > 7. Real delta =20 > > > > delta.real =3D d1 > > > >=20 > > > > =20 > =20 > > > > 8. Timestamp in P-BA MAG.t2 =20 > > > > LMA.t2 =3D (LMA.t1 + d2) > > > > =20 > > > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > 9. P-BA arrives @ MAG MAG.t2 + d2 =20 > > > > LMA.t2 + d2 > > > > 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in=20 > > corresponding=20 > > > > P-BU) > > > > =3D > > > > (LMA.t1 + d2) - MAG.t1 > > > > =3D > > > > ((MAG.t1 +d1)+d2) -MAG.t1 > > > > =20 > > > > delta =3D d1+d2 > > > >=20 > > > > 11. Real delta delta.real =3D d1 > > > >=20 > > > >=20 > > > > What is the problem here? Or am I missing something? > > > >=20 > > > >=20 > > > > Let us examine a re-registration or a P-BU/PA exchange=20 > > based on the=20 > > > > above synchronization: > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > >=20 > > > > MN- Resynchronization/Re-registration: > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > 12. Current timestamp MAG.t3 =20 > > > > LMA.t3 =3D MAG.t3 + d1 > > > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) =20 > > > LMA.t3 > > > > 14. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t3=20 > > + (d2+d1)) > > > > 15. P-BU arrives at LMA > > > > = .......................=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> = P-BU(MAG.t3=20 > + (d1+d2)) > > > > 16. Arrival Timestamp MAG.t3 + d2 =20 > > > > LMA.t3 + d2 > > > >=20 > > > > 17. delta based on P-BU =20 > > > > (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) > > > > =20 > > > > =3D > > > > =20 > > > > ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) > > > > =20 > > > > =3D > > > > =20 > > > > delta.P-BU =3D ZERO > > > >=20 > > > > 18. Real delta =20 > > > > delta.real =3D ZERO =20 > > > >=20 > > > > Please let me know what I am missing. > > > >=20 > > > > If nothing, I hope we can put an end to this debate and MOVE ON. > > > > =09 > > > >=20 > > > > Regards, > > > > Ahmad > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > Sent: Wednesday, September 12, 2007 3:07 AM > > > > > To: Sri Gundavelli > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > >=20 > > > > > Hi Sri, > > > > >=20 > > > > > please see my comments inline. > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > > Sent: Mittwoch, 12. September 2007 08:14 > > > > > > To: 'Kilian Weniger' > > > > > > Cc: netlmm@ietf.org > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > >=20 > > > > > > Hi Kilian/Federico, > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Kilian Weniger=20 > > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > > > > > To: Sri Gundavelli > > > > > > > Cc: netlmm@ietf.org > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > >=20 > > > > > > > Hi Sri, > > > > > > >=20 > > > > > > > my point is that NOT mandating synchronization to an > > > > > external clock > > > > > > > source for the timestamp option implies that sending PBU > > > > > msgs with > > > > > > > timestamp option is allowed even when MAGs are not (yet) > > > > > > synchronized. > > > > > > > I.e., it would be allowed that a deployment uses only the > > > > > returned > > > > > > > timestamps in PBA msgs to synchronize the MAG clocks. I > > > > think the > > > > > > > draft should not allow this for the following reasons: > > > > > > >=20 > > > > > >=20 > > > > > > The stated assumption for the timestamp based approach to > > > > work, is > > > > > > the requirement for the MAG's to have synchronized clocks. > > > > > > That is a requirement. Now, if a given MAG sends a=20 > > PBU with an=20 > > > > > > incorrect timestamp, its an error and as you and > > > Federico pointed > > > > > > out, there are cases where the LMA will not be able to > > > > determine the > > > > > > sending order of the received packets. This is an error > > > > condition, > > > > > > as the requirement is not met. > > > > >=20 > > > > > Right, sending a PBU with timestamp option requires that > > > the MAG's > > > > > clock is synchronized. Hence, I don't see why the draft > > > > should specify > > > > > a mechanism to synchronize a MAG's clock using a received > > > > PBA. Also, I > > > > > think this mechanism has issues in some scenario (see=20 > > my previous=20 > > > > > mail). > > > > >=20 > > > > >=20 > > > > > The clock synchronization is the job of some PMIP-independent=20 > > > > > synchronization method like NTP and out of sync clocks can > > > > only occur > > > > > if there is a problem with this PMIP-independent=20 > > synchronization=20 > > > > > method. > > > > > Hence, it is a non-recoverable error case from PMIP=20 > > point of view=20 > > > > > IMHO. > > > > >=20 > > > > > >=20 > > > > > > Now, should the draft state that the time=20 > > synchronization is a=20 > > > > > > requirement and additionally mandate a method of time > > > > > synchronization, > > > > > > say by NTP ? But, the later has a system wide impact and > > > > > additionally, > > > > > > a given architecture where this protocol is applied, can > > > > achieve the > > > > > > time synchronization through other non NTP means. IMO, we > > > > may not be > > > > > > able dictate that. Also, we want implementations to=20 > > support the=20 > > > > > > timestamp based scheme by default. Now, mandating the NTP > > > > usage will > > > > > > create some restrictions for some deployments. So,=20 > > that is the=20 > > > > > > reasoning behind not mandating the method of time > > > synchronization. > > > > >=20 > > > > > I'm not sure if the draft can say "a MAG's clock MUST be > > > > synchronized > > > > > for this protocol to work, but how this is done is out of > > > > scope of the > > > > > draft". I guess the draft has to mandate the > > > implementation of one > > > > > "default" synchronization protocol such as NTP to achieve=20 > > > > > interoperability. However, as long as the use of NTP is not > > > > mandated > > > > > (e.g., just say "SHOULD use"), deployments can still=20 > use other=20 > > > > > methods. > > > > > So I don't see restrictions for deployments in this case.=20 > > > > >=20 > > > > > >=20 > > > > > > W.r.t this below scenario, the reason for LMA to return its > > > > > timestamp, > > > > > > solves two purposes. 1.) Diagnostics (especially useful > > > > when the LMA > > > > > > and MAG are in different admin domains) 2.) The MAG can > > > > detect that > > > > > > its clock is not in sync and take the necessary > > > actions. I guess, > > > > > > Frederico has an issue with the second part. But, if you > > > > look at the > > > > > > recommendation from the draft on handling this error=20 > > case, MAG=20 > > > > > > signaling considerations, > > > > > >=20 > > > > > > "If the received Proxy Binding Acknowledgement > > > > message has the > > > > > > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > > > > > > Timestamp), > > > > > > the mobile access gateway SHOULD try to register > > > again only > > > > > > after > > > > > > it synchronized its clock with the local mobility > > > anchor's > > > > > > system > > > > > > clock or to a common time source that is used by > > > > all mobility > > > > > > entities in that domain for their clock=20 > > synchronization." > > > > > >=20 > > > > >=20 > > > > > I think it is good if the LMA informs the MAG about > > > detected out of > > > > > sync clocks for the purpose of diagnostics and as a=20 > trigger for=20 > > > > > re-sync. But why do we need the timestamp option in the=20 > > PBA? The=20 > > > > > TIMESTAMP_MISMATCH value in the status field is enough for > > > > the purpose > > > > > of diagnostics and as a trigger for re-sync. > > > > >=20 > > > > > > So, we are not really using the LMA as the time source.=20 > > > > > Now, with the > > > > > > given assumptions, do you see an issue if we dont say NTP > > > > is a MUST, > > > > > > but we say clock synch is a requirement, how they do it, > > > > draft does > > > > > > not say. If this requirement is not met, its an incorrect > > > > usage of > > > > > > the protocol and the PBU ordering will fail in that > > > special rare > > > > > > reordering scenario (IMO, its not a practical issue). > > > > >=20 > > > > > see above > > > > >=20 > > > > > BR, > > > > >=20 > > > > > Kilian > > > > >=20 > > > > > >=20 > > > > > > The second question to this discussion, is Alex's=20 > > point of not=20 > > > > > > mandating Timestamp option as a MUST implement. For this, > > > > > as I stated > > > > > > before, this is few lines of code for supporting this > > > > option and if > > > > > > seq number scheme is in use, this need not be used at > > > > all. We need > > > > > > to mandate this as there is no CT in the base spec. But, > > > > this is not > > > > > > a > > > > > big issue > > > > > > either way. If others agree, I'm fine not mandating this.=20 > > > > > > But, I really > > > > > > believe, implementations can support this option, at the > > > > least cost. > > > > > >=20 > > > > > > One last comment on the trust on LMA's clock for the sanity > > > > > check, is > > > > > > because its an anchor point and its typically well > > > > managed, compared > > > > > > to MAG's, where they are scattered out. So, its > > > > reasonable to expect > > > > > > the clock on the LMA to be in sync, else all > > > > registrations will fail > > > > > > and will generate the traps. > > > > > >=20 > > > > > > So, let me know your comments on how we can move forward. > > > > > >=20 > > > > > >=20 > > > > > > Sri > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > > 1. If a MAG's clock is out of sync (i.e., not yet=20 > synced by=20 > > > > > > > receiving a PBA with timestamp) AND PBUs sent by=20 > > this MAG are=20 > > > > > > > delayed, > > > > > > the out of > > > > > > > sync situation may not be detectable by the LMA and old > > > > > PBUs may be > > > > > > > accepted by the LMA.=20 > > > > > > >=20 > > > > > > > Consider the following example: MN attaches to MAG1 > > > and shortly > > > > > > > thereafter hands over to MAG2. MAG2's clock is in sync > > > > with LMA's > > > > > > > clock, but MAG1's clock is out of sync and is ahead of > > > > LMA's clock > > > > > > > by 5 seconds. MAG1-LMA link is highly congested. When MN > > > > > > attaches to MAG1, > > > > > > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before > > > > > > the MN hands > > > > > > > over to MAG2. The PBU1 msg is delayed by 5 seconds=20 > > due to the=20 > > > > > > > congestion and hence arrives at LMA 2 seconds after=20 > > handover. > > > > > > > Despite of the delay, > > > > > > > PBU1 has a valid timestamp from LMA's point of view due > > > > > to the wrong > > > > > > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after > > > > > > handover. PBU2 is > > > > > > > not significantly delayed and arrives at LMA ~1 seconds > > > > > > after handover > > > > > > > with valid timestamp. In this scenario, the LMA=20 > > will wrongly=20 > > > > > > > accept PBU1 arriving after PBU2, since both have a valid=20 > > > > > > > timestamp. > > > > > > Consequently, > > > > > > > the LMA forwards packets to the wrong MAG (MAG1)=20 > > and will not=20 > > > > > > > notice the out of sync of MAG1, which also means=20 > > that the LMA > > > > > doesn't return a > > > > > > > timestamp in the PBA and MAG1's clock keeps to be=20 > > out of sync. > > > > > > >=20 > > > > > > > 2. When packets on the link between MAG and LMA > > > > > experience high (and > > > > > > > varying) packet delays (e.g., due to congestion), the > > > > > > timestamp in the > > > > > > > PBA returned by the LMA may already be outdated=20 > at the time > > > > > > it arrives > > > > > > > at the MAG. So exactly in the situation where a=20 > re-ordering > > > > > > of PBUs is > > > > > > > needed, the synchronization mechanism may fail. > > > > > > >=20 > > > > > > > My two cents. > > > > > > >=20 > > > > > > > BR, > > > > > > >=20 > > > > > > > Kilian > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > > > > Sent: Freitag, 7. September 2007 18:48 > > > > > > > > To: 'Kilian Weniger' > > > > > > > > Cc: netlmm@ietf.org > > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > > >=20 > > > > > > > > Hi Kilian, > > > > > > > >=20 > > > > > > > > =20 > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: Kilian Weniger > > > > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > > > > > > To: Sri Gundavelli > > > > > > > > > Cc: netlmm@ietf.org > > > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > > > >=20 > > > > > > > > > Hi Sri, > > > > > > > > >=20 > > > > > > > > > > - We are NOT mandating the nodes in the domain to > > > > sync up to > > > > > > > > > > a clock source. > > > > > > > > >=20 > > > > > > > > > Hmm, so far I assumed that the proposal is to=20 > > mandate the > > > > > > > > MAGs to sync > > > > > > > > > up to an external clock source such as NTP server. > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > For the timestamp option to work, we RECOMMEND the use > > > > > of NTP for > > > > > > > > synchronizing the clocks in the domain. However, we do > > > > > not want to > > > > > > > > mandate on a specific mechanism.=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > > > Base draft does not support Context Transfers.=20 > > > Given that > > > > > > > > the draft > > > > > > > > > > will be incomplete, if we dont mandate the support.=20 > > > > > > By mandating > > > > > > > > > > the support, the LMA can always return its timestamp > > > > > > and the MAG > > > > > > > > > > can use that timestamp and register. This need to > > > > > be done just > > > > > > > > > > once whenever the LMA/MAG clocks are out of sync and > > > > > > > just for one > > > > > > > > > > registration. One extra round trip for the 1st > > > > > > > > registration between > > > > > > > > > > LMA/MAG pair. > > > > > > > > >=20 > > > > > > > > > So the proposal is to allow the use of the timestamp > > > > > > option in the > > > > > > > > > absence of any external time synchronization=20 > > like NTP and > > > > > > > > to mandate a > > > > > > > > > mechanism to synchronize clocks between MAGs=20 > > and LMA (and=20 > > > > > > > > > hence between all MAGs) using the timestamp option > > > > in PBU/PBA > > > > > > > > > only > > > > > > > (i.e., without > > > > > > > > > utilizing NTP or an external clock source)? Is my=20 > > > > > > > > > understanding correct? > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > No. For this to work, we require the clocks to=20 > be in sync. > > > > > > > > How its achieved, it could be based on NTP or some other > > > > > > protocols. > > > > > > > > But, why should we mandate this. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > > If so, can you please give some more details how > > > > the LMA can > > > > > > > > > detect that the clocks are out of sync? Is it=20 > > based on a=20 > > > > > > > > > certain > > > > > > difference of > > > > > > > > > timestamp in the received PBU and the current=20 > > LMA's time?=20 > > > > > > > > >=20 > > > > > > > > > And how to differentiate the out of sync case from the > > > > > > > out-of-order > > > > > > > > > delivery case (i.e., a PBU is delayed and overtaken > > > > by another > > > > > > > > > PBU from another MAG)? For instance, if the LMA > > > > receives a PBU > > > > > > > with timestamp > > > > > > > > > equal to "current time of LMA - X" and X >=20 > > threshold, how > > > > > > > > does the LMA > > > > > > > > > know whether the > > > > > > > > > 1. the MAG clock is synchronized, but the PBU got > > > > > > delayed by X or > > > > > > > > > 2. the PBU is not delayed, but the MAG's=20 > clock is out of > > > > > > > sync by X? > > > > > > > > > Ideally, in case 1 the LMA should just ignore=20 > > the PBU, in > > > > > > > case 2 it > > > > > > > > > should accept it and sync clocks. > > > > > > > > >=20 > > > > > > > > > If the idea is to always reject a PBU with X=20 > > threshold > > > > > > > > and include a > > > > > > > > > current timestamp in the PBA, then I guess the=20 > > same could > > > > > > > > be done with > > > > > > > > > sequence numbers instead of timestamps, right? > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > For what ever reasons if the LMA and MAG clocks are out > > > > > > of sync, the > > > > > > > > LMA can return its timestamp and the MAG can=20 > always apply > > > > > > that delta > > > > > > > > in all the registration it sends. This is done=20 > just once, > > > > > > when ever > > > > > > > > the clocks are off. But, with seq number scheme,=20 > > this needs > > > > > > > to be done > > > > > > > > for each MN registration. Its as per the 3775 per MN > > > > seq number. > > > > > > > >=20 > > > > > > > > Sri > > > > > > > >=20 > > > > > > > > > BR, > > > > > > > > >=20 > > > > > > > > > Kilian > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Panasonic R&D Center Germany GmbH > > > > > > > > > 63225 Langen, Hessen, Germany > > > > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing > > > > Director: Thomas > > > > > > > > > Micke > > > > > > > >=20 > > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Panasonic R&D Center Germany GmbH > > > > > > > 63225 Langen, Hessen, Germany > > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing > > > Director: Thomas > > > > > > > Micke > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Panasonic R&D Center Germany GmbH > > > > > 63225 Langen, Hessen, Germany > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing=20 > Director: Thomas=20 > > > > > Micke > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > > >=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 > >=20 > >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 06:57:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVmNr-0007XS-Rc; Thu, 13 Sep 2007 06:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVmNr-0007XN-9V for netlmm@ietf.org; Thu, 13 Sep 2007 06:57:19 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVmNp-0000wx-Jo for netlmm@ietf.org; Thu, 13 Sep 2007 06:57:19 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8DAucqN028601; Thu, 13 Sep 2007 12:56:39 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 12:57:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] DNAv6/SEND and timestamp synchronization problems Date: Thu, 13 Sep 2007 12:57:15 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A41@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <200709121544.14013.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] DNAv6/SEND and timestamp synchronization problems Thread-Index: Acf1QwcOIxmb7gmjQyK+MD11FTPdHQAAg/qA References: <200709111620.02475.julien.IETF@laposte.net> <200709121320.50726.julien.IETF@laposte.net> <319D54578EAC3147BA8CC78DAB5467A501399A35@FRVELSMBS12.ad2.ad.alcatel.com> <200709121544.14013.julien.IETF@laposte.net> From: "DE JUAN HUARTE FEDERICO" To: "Julien Laganier" X-OriginalArrivalTime: 13 Sep 2007 10:57:15.0827 (UTC) FILETIME=[D89BE830:01C7F5F4] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien, Julien> If a MAG always test reachability of the MN before extending an = existing binding (i.e. beyond initial registration) there we would have = no problem. Maybe we should complete that part of Section 6.9.1.: ... [FDJ] It makes sense to me to avoid the race condition problem when = using timestamps. For the case of context transfer, I don't think it's = necessary Note that if the concern is only the case I mentioned (race condition = because MN attached to nMAG but pMAG didn't notice) then it may be = unnecesary if the LMA can tell when a BU is a refresh There are other corner cases (ping-pong between MAGs, fast HO from pMAG = to nMAG1 and then to nMAG2) where it helps but is not bullet-proof If the timestamp came from the MN (as per you SEND proposal) it would be = bullet-proof Still, the case of MN connected/reachable by multiple MAGs would need = further consideration (I'm fine if it's out of scope) Regards federico -----Message d'origine----- De : julien laganier [mailto:julien.laganier@gmail.com] De la part de = Julien Laganier Envoy=E9 : mercredi 12 septembre 2007 15:44 =C0 : DE JUAN HUARTE FEDERICO Cc : netlmm@ietf.org Objet : Re: [netlmm] DNAv6/SEND and timestamp synchronization problems Federico, On Wednesday 12 September 2007, DE JUAN HUARTE FEDERICO wrote: > Julien, > > See inline Ditto, > Julien Laganier wrote: > > [...] > > > In my opinion in order to enable this solution, there should also=20 > > > be the following requirements/constraints: > > > > > > - Each BU should be preceded by a SEND message: this phrasing is=20 > > > intentional to cover not only the scenario of "HO from pMAG to=20 > > > nMAG" (which seems to be the one that everybody has in mind) but=20 > > > also the scenario of "lifetime expiration" (thus BU refresh) > > > > That could also be phrased as: When both the MAG and the MN supports = > > SEND, the MAG MAY use a pBU timestamp obtained from ND signalling=20 > > issued by the MN. In such case, sending a pBU MUST be preceded by=20 > > obtention of fresh SEND-protected ND message from the MN. > > That's fine >=20 > > > - The number of MAGs to which the MN is associated should be=20 > > > constrained to only 1: if the MN can be connected to pMAG and nMAG = > > > concurrently (from SEND point of view), then avoiding race=20 > > > conditions in PMIP HO would become more complex > > > > The race condition problem occuring from simultaneous connexion at=20 > > two MAGs cannot be defeated by timestamping alone, and is not=20 > > specific to this SEND method. >=20 > Indeed, the race condition problem is not specific to SEND. But I=20 > thought proposing SEND was aimed to address the problem. Otherwise,=20 > SEND is just another protocol for time synchronization (instead of > NTP) Simultaneous attachments to different MAGs causes issues with PMIPv6 = which are outside the scope of this specification. The problem cannot be = addressed without protocol extensions.=20 =20 > > The only way to defeat such race conditions is that the MN can't be=20 > > attached to more than one MAG, and a MAG must not send pBU when a MN = > > is not attached. Otherwise it's not going to work, timestamps or=20 > > not. >=20 > Very well described. Only one nuance: with context transfers there's=20 > no race condition problem. With context transfer you would in effect prevent attachment to more = than two MAGs. > Is the assumption that we can prevent a MAG to send BU when MN is not=20 > attached? At least I have been making that assumption. > Depending on the deployment, there can be a significant delay between=20 > MN detachment and MAG noticing it If a MAG always test reachability of the MN before extending an existing = binding (i.e. beyond initial registration) there we would have no = problem. Maybe we should complete that part of Section 6.9.1.: > Binding Re-Registration: > > o For extending the lifetime of a currently existing binding at=20 > the local mobility, the mobile access gateway MUST send a Proxy=20 > Binding Update message to the local mobility anchor. The prefix value = > in the Home Network Prefix option present in the request SHOULD be set = > to the currently registered home network prefix and the value in the=20 > Link-local Address option may be set to ALL_ZERO or to the link-local=20 > address of the mobile node. with this sentence "the MAG MUST make sure the MN is still attached to = it before extending the lifetime of an existing binding. That MAY be = done by using Neighbor Unreachibility Detection (i.e. an NS/NA = exchange.)" That could also be included in the MN-MAG interface draft (draft-ietf-netlmm-mn-ar) via inclusion of a new method = MAG_TEST_MN_REACHABILITY. > > > A final comment is that the idea could be generalized to allow=20 > > > using a sequence number or a timestamp generated by the MN=20 > > > whenever there's a protocol (e.g. SEND) which is guaranteed to be=20 > > > executed before sending a BU > > > > Yeah, I thought about that generalization, but could not find=20 > > examples of appropriate MN-generated sequence numbers. For example,=20 > > it is possible that an L2 sequence number is reset or randomized=20 > > after each L2 attachment, making it useless for the purpose of=20 > > ordering pBUs. > > A secured L2 wireless interface should support sequence numbers for=20 > replay protection In fact, it looks like SEND proposes timestamps for=20 > the sake of replay protection Personally, I don't think that using=20 > timestamp for replay protection is as secure as using sequence=20 > numbers, but that's a different topic. Yes, that's a difference topic. Anyway for the record, SEND deals with = security of signaling that are not always request/response, hence making = it impossible to use Nonces, or to initialy synchronize a sequence = number. That's why a timestamp is included to provide reduced, but still = useful security. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 06:58:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVmOb-0000FD-JS; Thu, 13 Sep 2007 06:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVmOZ-0000F3-JK for netlmm@ietf.org; Thu, 13 Sep 2007 06:58:03 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVmOX-0000xa-Sk for netlmm@ietf.org; Thu, 13 Sep 2007 06:58:03 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8DAucqL028601; Thu, 13 Sep 2007 12:56:38 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 12:57:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 12:57:01 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A40@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B4978F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAMXqxQAAWRX+AAAB568AAE2X+QACH/keA= References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de><6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <1FEB9B9F2EC38343955D02B2AE86AACB48ABB7@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4978F@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Ahmad Muhanna" X-OriginalArrivalTime: 13 Sep 2007 10:57:15.0608 (UTC) FILETIME=[D87A7D80:01C7F5F4] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6dd7161d991fe2952d0c2dd902dbed7e Cc: Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, I understand now that you're not proposing to resynch the clock in the = MAG, but only to keep a delta Nonetheless, it's still not clear to me what is the benefit of your = proposal In simple words: - MAG sends BU with TS=3DX - LMA returns BAck with error and TS=3DY - (second roundtrip) MAG resends BU with TS=3DY and deduces that = delta(d)=3DY-X My comments: - I don't see the usefulness of the 2 roundtrip to set the binding: = you can achieve the same with only 1 roundtrip - Are you assuming that you can reuse the same delta for the = following BU? If yes, this (intentionally?) ignores the variablity of = delta due to clock deviation (d1) and congestion (d2). The delta will = change with every BU and each BU could (potentially) require 2 = roundtrips (I guess we can give up the 2nd roundtrip) I guess you assume that the variablity of the delta can be dealt with by = fine-tuning the thresholds in the LMA to declare a TIMESTAMP-MISMATCH. = Fine The final result is that we have all MAGs maintaining a delta (d) per = LMA, which changes now and then What's the added value of this delta? - It is not useful to synchronize the MAG clock and the LMA clock = (for this synchronization you would need to be able to tell d1, not d) - It is not useful to solve the race condition problem >From your answer, it seems to me that we don't have the same = understanding of the race condition problem, let me describe it again The race condition problem occurs when more than 1 MAG (e.g. MAG1 and = MAG2) send a BU at the same time. Note that MAG1 and MAG2 maybe = perfectly synchronized in time The problem is that the LMA can not tell which is the right sequence of = the Bus. Typical use case: - MN moves from pMAG to nMAG (both perfectly synchronized). nMAG = sends BU with timestamp X - the lifetime of the binding in pMAG expires. pMAG sends BU with = timestamp Y (Y>X) When LMA receives the BU from nMAG (timestamp X) it updates the BCE When LMA receives the BU from pMAG (timestamp Y) it also updates the BCE = (because Y>X, thus correct) The final result is that the binding in the LMA points to the pMAG, but = the MN is attached to the nMAG There are other use cases but I find this one as the most clear Does this make sense or is it me that I'm missing something? Regards federico -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Envoy=E9 : mercredi 12 septembre 2007 22:20 =C0 : Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO Cc : netlmm@ietf.org Objet : RE: [netlmm] timestamp vs seqno redux Hi Kilian, Please see comments inline. Regards, Ahmad =20 >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Mittwoch, 12. September 2007 17:41 > > To: Ahmad Muhanna; Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE=20 > > FEDERICO > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Resending hopefully with the correct format. >=20 > thanks for re-sending. Much better to read now ;) >=20 > >=20 > > +++++ > >=20 > > Hi Kilian/Federico and All, > >=20 > > There has been a lot of email exchange that the timestamp=20 > > synchronization using the PMIPv6 signaling does not work. > On the other > > hand, I have not seen any in detail analysis which proves > that it does > > not work. I would like to share in details my thoughts on how this=20 > > SHOULD work and please comment as necessary. >=20 > In one of my previous emails I described an example scenarios where it = > fails, at least according to my understanding of the sync method. > According to my understanding, the LMA only sees a delta time=20 > consisting of two parts: 1.) transmission delay of PBU (d2 in your=20 > example) and 2.) clock difference (d1 in your example). > The problem is that the LMA doesn't know d1 and d2 itself, it only=20 > knows d1+d2. If d2=3D~-d1, i.e., MAG's clock is ahead of LMA's clock = by=20 > a value that is roughly equal to the transmission delay, then=20 > d1+d2=3D~0, i.e., the LMA doesn't see any delta and assumes that the=20 > MAG's clock is in sync (which is not true). > Hence, no re-sync happens and the LMA may accept outdated PBUs (see my = > previous email). [Ahmad] Kilian, This is the same race condition that we have discussed too many times = and people do not like to accept the unpopular solution :-) I have no = problem with that. But let us exactly identify all conditions related to = the scenario: 1. A race condition scenario which happens during handoff. 2. It assumes that the MAGs are not properly synchronized with each = other using an outside mechanism. We are here talking here about the = MAGs not the (LMA and MAGs). In other words, if the MAGs in the same = local domain are synchronized this issue will never happen. 3. It assumes that the pMAG sent a P-BU as a re-registration in a race = condition as the MN moves from pMAG (previous MAG) to nMAG (next MAG). 4. Due to some network conditions, the P-BU of the pMAG arrives at the = LMA after the P-BU of the nMAG. 5. It also assumes that not only pMAG and nMAG is out of sync, but also = nMAG is slower than pMAG by almost double the delta between any of them = and the LMA. 6. Not only that but also, the nMAG is slower enough to the degree that = when the P-BU arrives at the LMA it is within the threshold. Finally, -------- I am not saying that the possibility of this scenario to happen is ZERO. No. There is a possibility that it MAY happen but , at the same time, it = is very very slim. Not only that, I think according to the PMIPv6 draft, = MAG needs to make sure that the MN is currently attached before sending = a re-registration P-BU. If the MAG is not sure, then MAG does not send = the P-BU. NOW: what can we do about it: ----------------------------- 1. The very famous but un-popular solution that we mentioned several = time. In case of handoff, i.e. when the LMA receives the P-BU from nMAG, = LMA considers this as a case of handoff. When LMA receives a P-BU from = the pMAG, LMA drops or rejects it with a code MN-in-handoff, for = example. Since it is a race condition, that will take care of it. 2. LMA needs to track the delta for each MAG. Then after the P-BU passes = the LMA timestamp check and in case of handoff, LMA can always make sure = that the adjusted timestamp of the received P-BU is always larger than = the adjusted timestamp of the last received P-BU which is already saved = as part of the MN BCE. I hope that this will take care of this issue and we can finally move = on. Best Regards, Ahmad BTW: please see more comments below. >=20 > Please see some more comments inline. >=20 > >=20 > > The following are a list of assumptions: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 1. The time that the P-BU takes from MAG to LMA equals the time the=20 > > P-BA takes from LMA to MAG. >=20 > What is behind this assumption? Why not introduce another variable d3=20 > for PBA delay (in addition to d2 for PBU delay). [Ahmad] Actually d3 is irrelevant in this regard. Because the timestamp delta = that the MAG is tracking does not depend on d3, because, MAG considers = the timestamp delta as the difference between the LMA-timestamp in P-BA = (which is independent of d3) and the MAG-timestamp in the corresponding = P-BU (which is again independent of d3).=20 This means that regardless of the delay in the downlink direction, only = the delay in the uplink direction has an impact and that impact is = already factored IN and does not influence synchronization scheme. >=20 >=20 > > 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > > comparing timestamp in P-BU and LMA current timestamp. > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > timestamp for calculating the delta! > > 4. MAG and LMA maintains the same out of sync delta during the=20 > > re-synchronization process. > >=20 > >=20 > > MAG LMA > > ---------- =20 > ---------- > > 1. Current Timestamp MAG.t1 LMA.t1 =3D=20 > MAG.t1 +d1 > > 2. Timestamp in P-BU MAG.t1 LMA timestamp: LMA.t1 > > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) > >=20 > > 4. P-BU arrives at LMA .............. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> > > P-BU(MAG.t1) > >=20 > > 5. Arrival Timestamp MAG.t1 + d2 LMA.t1 + d2 > > 6. delta based on P-BU timestamp (LMA.t1 +=20 > d2)-(MAG.t1) > > =3D > > =20 > > ((MAG.t1+d1)+d2) - MAG.t1 > > =3D > > delta.P-BU =3D = d2+d1 >=20 > right, d2+d1 is the delta that the LMA measures. [Ahmad] Correct. Measured from the MAG timestamp. Right? >=20 > >=20 > > 7. Real delta delta.real =3D d1 >=20 > How is the real delta d1 known by the LMA? [Ahmad] LMA does not need to know it. As long as the scheme works to = resynchronize the MAG with the LMA, no need for LMA to know it. Right? =20 >=20 > >=20 > >=20 > >=20 > > 8. Timestamp in P-BA MAG.t2 LMA.t2 =3D=20 > (LMA.t1 + d2) > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > How does the LMA know d2? IMO, LMA only knows delta.P-BU =3D d2+d1.=20 [Ahmad] Absolutely. LMA does not know what d2 and does not need to. This is used = for proving the scheme.=20 > Hence, P-BA can only contain LMA.t2 =3D (LMA.t1 + delta.P-BU) =3D > (LMA.t1 + > d1 + d2) [Ahmad] I am afraid that is not correct. You probably meant to say: LMA.t2 =3D (MAG.t1 + (d1+d2)). Right? Otherwise, LMA.t2 in terms of LMA.t1 is as follows: LMA.t2 =3D LMA.t1 + = d2. NO? >=20 > > 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 > > 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in corresponding > > P-BU) > > =3D > > (LMA.t1 + d2) - MAG.t1 > > =3D > > ((MAG.t1 +d1)+d2) -MAG.t1 > >=20 > > delta =3D d1+d2 >=20 > delta should be d1+2*d2 [Ahmad] No. That is not correct. Delta =3D d1+d2. Please see above comment. >=20 > >=20 > > 11. Real delta delta.real =3D d1 >=20 > How does the LMA know the real delta? [Ahmad] It does not need to know. ONLY MAG needs to track a delta with the LMA. Well, we can make both track each other deltas but that will be too much = for the LMA and , honestly, it is not needed. =20 >=20 > BR, >=20 > Kilian >=20 >=20 > >=20 > >=20 > > What is the problem here? Or am I missing something? > > Let us examine a re-registration or a P-BU/PA exchange based on the=20 > > above synchronization: > >=20 > >=20 > > MN- Resynchronization/Re-registration: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 12. Current timestamp MAG.t3 LMA.t3 =3D=20 > MAG.t3 + d1 > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 > > 14. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t3 + (d2+d1)) > >=20 > > 15. P-BU arrives at LMA = .......=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> > P-BU(MAG.t3+(d1+d2)) > > 16. Arrival Timestamp MAG.t3 + d2 LMA.t3 + d2 > > 17. delta based on P-BU =20 > > (LMA.t3+d2)-(MAG.t3+(d2+d1)) > > =3D > > =20 > > ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1)) > > =3D > >=20 > > delta.P-BU =3D ZERO > > 18. Real delta delta.real =3D ZERO > >=20 > > Please let me know what I am missing. > > If nothing, I hope we can put an end to this debate and MOVE ON. > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Muhanna, Ahmad (RICH1:2H10) > > > Sent: Wednesday, September 12, 2007 9:59 AM > > > To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE FEDERICO' > > > Cc: 'netlmm@ietf.org' > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Kilian/Federico and All, > > >=20 > > >=20 > > > There has been a lot of email exchange that the timestamp=20 > > > synchronization using the PMIPv6 signaling does not work. On the=20 > > > other hand, I have not seen any in detail analysis which > proves that > > > it does not work. I would like to share in details my thoughts on=20 > > > how this SHOULD work and please comment as necessary. > > >=20 > > > The following are a list of assumptions: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > 1. The time that the P-BU takes from MAG to LMA equals > the time the > > > P-BA takes from LMA to MAG. > > > 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > > > comparing timestamp in P-BU and LMA current timestamp. > > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > > timestamp for calculating the delta! > > > 4. MAG and LMA maintains the same out of sync delta during the=20 > > > re-synchronization process. > > >=20 > > >=20 > > >=20 > > > MAG =20 > > > LMA > > > ---------- =20 > > > ---------- > > > 1. Current Timestamp MAG.t1 =20 > > > LMA.t1 =3D MAG.t1 +d1 > > > 2. Timestamp in P-BU MAG.t1 LMA=20 > > > timestamp: LMA.t1 > > > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) > > > 4. P-BU arrives at LMA .......................=20 > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t1) > > > 5. Arrival Timestamp MAG.t1 + d2 =20 > > > LMA.t1 + d2 > > >=20 > > > 6. delta based on P-BU timestamp =20 > > > (LMA.t1 + d2) - (MAG.t1) > > > =20 > > > =3D > > > =20 > > > ((MAG.t1+d1)+d2) - MAG.t1=09 > > > =20 > > > =3D > > > =20 > > > delta.P-BU =3D d2+d1 > > >=20 > > > 7. Real delta =20 > > > delta.real =3D d1 > > >=20 > > > =20 > > > 8. Timestamp in P-BA MAG.t2 =20 > > > LMA.t2 =3D (LMA.t1 + d2) > > > =20 > > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > 9. P-BA arrives @ MAG MAG.t2 + d2 =20 > > > LMA.t2 + d2 > > > 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in > corresponding > > > P-BU) > > > =3D > > > (LMA.t1 + d2) - MAG.t1 > > > =3D > > > ((MAG.t1 +d1)+d2) -MAG.t1 > > > =20 > > > delta =3D d1+d2 > > >=20 > > > 11. Real delta delta.real =3D d1 > > >=20 > > >=20 > > > What is the problem here? Or am I missing something? > > >=20 > > >=20 > > > Let us examine a re-registration or a P-BU/PA exchange > based on the > > > above synchronization: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > >=20 > > > MN- Resynchronization/Re-registration: > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > 12. Current timestamp MAG.t3 =20 > > > LMA.t3 =3D MAG.t3 + d1 > > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) =20 > > LMA.t3 > > > 14. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t3=20 > + (d2+d1)) > > > 15. P-BU arrives at LMA > > > = .......................=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> = P-BU(MAG.t3 + (d1+d2)) > > > 16. Arrival Timestamp MAG.t3 + d2 =20 > > > LMA.t3 + d2 > > >=20 > > > 17. delta based on P-BU =20 > > > (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) > > > =20 > > > =3D > > > =20 > > > ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) > > > =20 > > > =3D > > > =20 > > > delta.P-BU =3D ZERO > > >=20 > > > 18. Real delta =20 > > > delta.real =3D ZERO =20 > > >=20 > > > Please let me know what I am missing. > > >=20 > > > If nothing, I hope we can put an end to this debate and MOVE ON. > > > =09 > > >=20 > > > Regards, > > > Ahmad > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > Sent: Wednesday, September 12, 2007 3:07 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri, > > > >=20 > > > > please see my comments inline. > > > >=20 > > > > > -----Original Message----- > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > Sent: Mittwoch, 12. September 2007 08:14 > > > > > To: 'Kilian Weniger' > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > >=20 > > > > > Hi Kilian/Federico, > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Kilian Weniger > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > > > > To: Sri Gundavelli > > > > > > Cc: netlmm@ietf.org > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > >=20 > > > > > > Hi Sri, > > > > > >=20 > > > > > > my point is that NOT mandating synchronization to an > > > > external clock > > > > > > source for the timestamp option implies that sending PBU > > > > msgs with > > > > > > timestamp option is allowed even when MAGs are not (yet) > > > > > synchronized. > > > > > > I.e., it would be allowed that a deployment uses only the > > > > returned > > > > > > timestamps in PBA msgs to synchronize the MAG clocks. I > > > think the > > > > > > draft should not allow this for the following reasons: > > > > > >=20 > > > > >=20 > > > > > The stated assumption for the timestamp based approach to > > > work, is > > > > > the requirement for the MAG's to have synchronized clocks. > > > > > That is a requirement. Now, if a given MAG sends a > PBU with an > > > > > incorrect timestamp, its an error and as you and > > Federico pointed > > > > > out, there are cases where the LMA will not be able to > > > determine the > > > > > sending order of the received packets. This is an error > > > condition, > > > > > as the requirement is not met. > > > >=20 > > > > Right, sending a PBU with timestamp option requires that > > the MAG's > > > > clock is synchronized. Hence, I don't see why the draft > > > should specify > > > > a mechanism to synchronize a MAG's clock using a received > > > PBA. Also, I > > > > think this mechanism has issues in some scenario (see > my previous > > > > mail). > > > >=20 > > > >=20 > > > > The clock synchronization is the job of some PMIP-independent=20 > > > > synchronization method like NTP and out of sync clocks can > > > only occur > > > > if there is a problem with this PMIP-independent > synchronization > > > > method. > > > > Hence, it is a non-recoverable error case from PMIP > point of view > > > > IMHO. > > > >=20 > > > > >=20 > > > > > Now, should the draft state that the time > synchronization is a > > > > > requirement and additionally mandate a method of time > > > > synchronization, > > > > > say by NTP ? But, the later has a system wide impact and > > > > additionally, > > > > > a given architecture where this protocol is applied, can > > > achieve the > > > > > time synchronization through other non NTP means. IMO, we > > > may not be > > > > > able dictate that. Also, we want implementations to > support the > > > > > timestamp based scheme by default. Now, mandating the NTP > > > usage will > > > > > create some restrictions for some deployments. So, > that is the > > > > > reasoning behind not mandating the method of time > > synchronization. > > > >=20 > > > > I'm not sure if the draft can say "a MAG's clock MUST be > > > synchronized > > > > for this protocol to work, but how this is done is out of > > > scope of the > > > > draft". I guess the draft has to mandate the > > implementation of one > > > > "default" synchronization protocol such as NTP to achieve=20 > > > > interoperability. However, as long as the use of NTP is not > > > mandated > > > > (e.g., just say "SHOULD use"), deployments can still use other=20 > > > > methods. > > > > So I don't see restrictions for deployments in this case.=20 > > > >=20 > > > > >=20 > > > > > W.r.t this below scenario, the reason for LMA to return its > > > > timestamp, > > > > > solves two purposes. 1.) Diagnostics (especially useful > > > when the LMA > > > > > and MAG are in different admin domains) 2.) The MAG can > > > detect that > > > > > its clock is not in sync and take the necessary > > actions. I guess, > > > > > Frederico has an issue with the second part. But, if you > > > look at the > > > > > recommendation from the draft on handling this error > case, MAG > > > > > signaling considerations, > > > > >=20 > > > > > "If the received Proxy Binding Acknowledgement > > > message has the > > > > > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > > > > > Timestamp), > > > > > the mobile access gateway SHOULD try to register > > again only > > > > > after > > > > > it synchronized its clock with the local mobility > > anchor's > > > > > system > > > > > clock or to a common time source that is used by > > > all mobility > > > > > entities in that domain for their clock > synchronization." > > > > >=20 > > > >=20 > > > > I think it is good if the LMA informs the MAG about > > detected out of > > > > sync clocks for the purpose of diagnostics and as a trigger for=20 > > > > re-sync. But why do we need the timestamp option in the > PBA? The > > > > TIMESTAMP_MISMATCH value in the status field is enough for > > > the purpose > > > > of diagnostics and as a trigger for re-sync. > > > >=20 > > > > > So, we are not really using the LMA as the time source.=20 > > > > Now, with the > > > > > given assumptions, do you see an issue if we dont say NTP > > > is a MUST, > > > > > but we say clock synch is a requirement, how they do it, > > > draft does > > > > > not say. If this requirement is not met, its an incorrect > > > usage of > > > > > the protocol and the PBU ordering will fail in that > > special rare > > > > > reordering scenario (IMO, its not a practical issue). > > > >=20 > > > > see above > > > >=20 > > > > BR, > > > >=20 > > > > Kilian > > > >=20 > > > > >=20 > > > > > The second question to this discussion, is Alex's > point of not > > > > > mandating Timestamp option as a MUST implement. For this, > > > > as I stated > > > > > before, this is few lines of code for supporting this > > > option and if > > > > > seq number scheme is in use, this need not be used at > > > all. We need > > > > > to mandate this as there is no CT in the base spec. But, > > > this is not > > > > > a > > > > big issue > > > > > either way. If others agree, I'm fine not mandating this.=20 > > > > > But, I really > > > > > believe, implementations can support this option, at the > > > least cost. > > > > >=20 > > > > > One last comment on the trust on LMA's clock for the sanity > > > > check, is > > > > > because its an anchor point and its typically well > > > managed, compared > > > > > to MAG's, where they are scattered out. So, its > > > reasonable to expect > > > > > the clock on the LMA to be in sync, else all > > > registrations will fail > > > > > and will generate the traps. > > > > >=20 > > > > > So, let me know your comments on how we can move forward. > > > > >=20 > > > > >=20 > > > > > Sri > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > 1. If a MAG's clock is out of sync (i.e., not yet synced by=20 > > > > > > receiving a PBA with timestamp) AND PBUs sent by > this MAG are > > > > > > delayed, > > > > > the out of > > > > > > sync situation may not be detectable by the LMA and old > > > > PBUs may be > > > > > > accepted by the LMA.=20 > > > > > >=20 > > > > > > Consider the following example: MN attaches to MAG1 > > and shortly > > > > > > thereafter hands over to MAG2. MAG2's clock is in sync > > > with LMA's > > > > > > clock, but MAG1's clock is out of sync and is ahead of > > > LMA's clock > > > > > > by 5 seconds. MAG1-LMA link is highly congested. When MN > > > > > attaches to MAG1, > > > > > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before > > > > > the MN hands > > > > > > over to MAG2. The PBU1 msg is delayed by 5 seconds > due to the > > > > > > congestion and hence arrives at LMA 2 seconds after > handover. > > > > > > Despite of the delay, > > > > > > PBU1 has a valid timestamp from LMA's point of view due > > > > to the wrong > > > > > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after > > > > > handover. PBU2 is > > > > > > not significantly delayed and arrives at LMA ~1 seconds > > > > > after handover > > > > > > with valid timestamp. In this scenario, the LMA > will wrongly > > > > > > accept PBU1 arriving after PBU2, since both have a valid=20 > > > > > > timestamp. > > > > > Consequently, > > > > > > the LMA forwards packets to the wrong MAG (MAG1) > and will not > > > > > > notice the out of sync of MAG1, which also means > that the LMA > > > > doesn't return a > > > > > > timestamp in the PBA and MAG1's clock keeps to be > out of sync. > > > > > >=20 > > > > > > 2. When packets on the link between MAG and LMA > > > > experience high (and > > > > > > varying) packet delays (e.g., due to congestion), the > > > > > timestamp in the > > > > > > PBA returned by the LMA may already be outdated at the time > > > > > it arrives > > > > > > at the MAG. So exactly in the situation where a re-ordering > > > > > of PBUs is > > > > > > needed, the synchronization mechanism may fail. > > > > > >=20 > > > > > > My two cents. > > > > > >=20 > > > > > > BR, > > > > > >=20 > > > > > > Kilian > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > > > Sent: Freitag, 7. September 2007 18:48 > > > > > > > To: 'Kilian Weniger' > > > > > > > Cc: netlmm@ietf.org > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > >=20 > > > > > > > Hi Kilian, > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Kilian Weniger > > > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > > > > > To: Sri Gundavelli > > > > > > > > Cc: netlmm@ietf.org > > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > > >=20 > > > > > > > > Hi Sri, > > > > > > > >=20 > > > > > > > > > - We are NOT mandating the nodes in the domain to > > > sync up to > > > > > > > > > a clock source. > > > > > > > >=20 > > > > > > > > Hmm, so far I assumed that the proposal is to > mandate the > > > > > > > MAGs to sync > > > > > > > > up to an external clock source such as NTP server. > > > > > > > >=20 > > > > > > >=20 > > > > > > > For the timestamp option to work, we RECOMMEND the use > > > > of NTP for > > > > > > > synchronizing the clocks in the domain. However, we do > > > > not want to > > > > > > > mandate on a specific mechanism.=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > > Base draft does not support Context Transfers.=20 > > Given that > > > > > > > the draft > > > > > > > > > will be incomplete, if we dont mandate the support.=20 > > > > > By mandating > > > > > > > > > the support, the LMA can always return its timestamp > > > > > and the MAG > > > > > > > > > can use that timestamp and register. This need to > > > > be done just > > > > > > > > > once whenever the LMA/MAG clocks are out of sync and > > > > > > just for one > > > > > > > > > registration. One extra round trip for the 1st > > > > > > > registration between > > > > > > > > > LMA/MAG pair. > > > > > > > >=20 > > > > > > > > So the proposal is to allow the use of the timestamp > > > > > option in the > > > > > > > > absence of any external time synchronization > like NTP and > > > > > > > to mandate a > > > > > > > > mechanism to synchronize clocks between MAGs > and LMA (and > > > > > > > > hence between all MAGs) using the timestamp option > > > in PBU/PBA > > > > > > > > only > > > > > > (i.e., without > > > > > > > > utilizing NTP or an external clock source)? Is my=20 > > > > > > > > understanding correct? > > > > > > > >=20 > > > > > > >=20 > > > > > > > No. For this to work, we require the clocks to be in sync. > > > > > > > How its achieved, it could be based on NTP or some other > > > > > protocols. > > > > > > > But, why should we mandate this. > > > > > > >=20 > > > > > > >=20 > > > > > > > > If so, can you please give some more details how > > > the LMA can > > > > > > > > detect that the clocks are out of sync? Is it > based on a > > > > > > > > certain > > > > > difference of > > > > > > > > timestamp in the received PBU and the current > LMA's time?=20 > > > > > > > >=20 > > > > > > > > And how to differentiate the out of sync case from the > > > > > > out-of-order > > > > > > > > delivery case (i.e., a PBU is delayed and overtaken > > > by another > > > > > > > > PBU from another MAG)? For instance, if the LMA > > > receives a PBU > > > > > > with timestamp > > > > > > > > equal to "current time of LMA - X" and X > > threshold, how > > > > > > > does the LMA > > > > > > > > know whether the > > > > > > > > 1. the MAG clock is synchronized, but the PBU got > > > > > delayed by X or > > > > > > > > 2. the PBU is not delayed, but the MAG's clock is out of > > > > > > sync by X? > > > > > > > > Ideally, in case 1 the LMA should just ignore > the PBU, in > > > > > > case 2 it > > > > > > > > should accept it and sync clocks. > > > > > > > >=20 > > > > > > > > If the idea is to always reject a PBU with X > threshold > > > > > > > and include a > > > > > > > > current timestamp in the PBA, then I guess the > same could > > > > > > > be done with > > > > > > > > sequence numbers instead of timestamps, right? > > > > > > > >=20 > > > > > > >=20 > > > > > > > For what ever reasons if the LMA and MAG clocks are out > > > > > of sync, the > > > > > > > LMA can return its timestamp and the MAG can always apply > > > > > that delta > > > > > > > in all the registration it sends. This is done just once, > > > > > when ever > > > > > > > the clocks are off. But, with seq number scheme, > this needs > > > > > > to be done > > > > > > > for each MN registration. Its as per the 3775 per MN > > > seq number. > > > > > > >=20 > > > > > > > Sri > > > > > > >=20 > > > > > > > > BR, > > > > > > > >=20 > > > > > > > > Kilian > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Panasonic R&D Center Germany GmbH > > > > > > > > 63225 Langen, Hessen, Germany > > > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing > > > Director: Thomas > > > > > > > > Micke > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Panasonic R&D Center Germany GmbH > > > > > > 63225 Langen, Hessen, Germany > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing > > Director: Thomas > > > > > > Micke > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > > Panasonic R&D Center Germany GmbH > > > > 63225 Langen, Hessen, Germany > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > > > > Micke > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 > >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 06:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVmP1-0000Vm-BI; Thu, 13 Sep 2007 06:58:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVmOz-0000Ng-Cw for netlmm@ietf.org; Thu, 13 Sep 2007 06:58:29 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVmOx-0000xy-HT for netlmm@ietf.org; Thu, 13 Sep 2007 06:58:29 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8DAucqP028601; Thu, 13 Sep 2007 12:56:39 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 12:57:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Sep 2007 12:57:15 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A42@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116AF95B2@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SQN reset Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAFUmpcAAlg48Q References: <46DFC1C7.9060103@gmail.com><01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com><1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de><010301c7f16e$d25ec030$d4f6200a@amer.cisco.com><1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de><000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF95B2@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Ahmad Muhanna" , "Sri Gundavelli" X-OriginalArrivalTime: 13 Sep 2007 10:57:16.0046 (UTC) FILETIME=[D8BD52E0:01C7F5F4] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: Kilian Weniger , netlmm@ietf.org Subject: [netlmm] SQN reset X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, why would there be 2 roundtrips during initial attach when using SQN? = (by definition there's no context transfer in initial attach) I also want to clarify something about using SQNs in inter-MAG handoff = as I believe the current text can be improved I see 2 scenarios:=20 - SQN-error: the LMA receives a SQN that is out of order (smaller = than current SQN) =3D> then LMA should return an error - SQN-reset: the LMA can tell from the BU that it has to reset the = SQN algorithm. This is useful in the following use cases: * The deployment doesn't support context transfer nor timestamps * The deployment supports context transfer but the context transfer = failed (for whatever the reason) * The deployment supports context transfer and the context transfer = was succeful, but the LMA returns SQN-error (for whatever the reason). = Then the MAG can initiate a second BU (with SQN-reset this time) * Optionally, also in initial attach (not neecessary) The SQN-reset concept could be conveyed explicitly (new flag) or = implicitly (SQN=3D0) I don't have an opinion one way or the other but I think that it would = be useful if the specification supported this concept I wonder if basic MIP has built-in something similar (for some sort of = fast-reset) Regards federico -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Envoy=E9 : mercredi 12 septembre 2007 17:53 =C0 : Sri Gundavelli; Kilian Weniger Cc : netlmm@ietf.org Objet : RE: [netlmm] timestamp vs seqno redux Hi Sri, I completely agree. There are several options for timestamp = synchronization and any deployment can choose any of these mechanism. Nothing is mandated in the draft and that is good. On the other hand, if = a deployment wants to use SQN, it is absolutely fine too. 1. If a deployment does not mind to have 2 round trips during initial = attach or inter-MAG handoff, then straight forward use of the per-MN SQN = is a possibility. 2. If a deployment would like to avoid two round trips during initial = attach or inter-MAG handoff, then they need to synchronize per-MN SQN = across MAGs. How, that is out-of-scope. I do not see any problem with the drafts options and I believe we have = spent a lot of time debating this issue. IMO, The draft is good as far = as this issue is concerned and the issue should be closed. Regards, Ahmad =20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Wednesday, September 12, 2007 1:14 AM > To: 'Kilian Weniger' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Kilian/Federico, >=20 > =20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > Sent: Tuesday, September 11, 2007 6:33 AM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > my point is that NOT mandating synchronization to an external clock=20 > > source for the timestamp option implies that sending PBU msgs with=20 > > timestamp option is allowed even when MAGs are not (yet) > synchronized. > > I.e., it would be allowed that a deployment uses only the returned=20 > > timestamps in PBA msgs to synchronize the MAG clocks. I think the=20 > > draft should not allow this for the following reasons: > >=20 >=20 > The stated assumption for the timestamp based approach to work, is the = > requirement for the MAG's to have synchronized clocks. > That is a requirement. Now, if a given MAG sends a PBU with an=20 > incorrect timestamp, its an error and as you and Federico pointed out, = > there are cases where the LMA will not be able to determine the=20 > sending order of the received packets. This is an error condition, as=20 > the requirement is not met. >=20 > Now, should the draft state that the time synchronization is a=20 > requirement and additionally mandate a method of time synchronization, = > say by NTP ? But, the later has a system wide impact and additionally, = > a given architecture where this protocol is applied, can achieve the=20 > time synchronization through other non NTP means. IMO, we may not be=20 > able dictate that. Also, we want implementations to support the=20 > timestamp based scheme by default. Now, mandating the NTP usage will=20 > create some restrictions for some deployments. So, that is the=20 > reasoning behind not mandating the method of time synchronization. >=20 > W.r.t this below scenario, the reason for LMA to return its timestamp, = > solves two purposes. 1.) Diagnostics (especially useful when the LMA=20 > and MAG are in different admin domains) > 2.) The MAG can detect that its clock is not in sync and take the=20 > necessary actions. I guess, Frederico has an issue with the second=20 > part. But, if you look at the recommendation from the draft on=20 > handling this error case, MAG signaling considerations, >=20 > "If the received Proxy Binding Acknowledgement message has the > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > Timestamp), > the mobile access gateway SHOULD try to register again only=20 > after > it synchronized its clock with the local mobility anchor's=20 > system > clock or to a common time source that is used by all mobility > entities in that domain for their clock synchronization." >=20 > So, we are not really using the LMA as the time source. Now, with the=20 > given assumptions, do you see an issue if we dont say NTP is a MUST,=20 > but we say clock synch is a requirement, how they do it, draft does=20 > not say. If this requirement is not met, its an incorrect usage of the = > protocol and the PBU ordering will fail in that special rare=20 > reordering scenario (IMO, its not a practical issue). >=20 > The second question to this discussion, is Alex's point of not=20 > mandating Timestamp option as a MUST implement. For this, as I stated=20 > before, this is few lines of code for supporting this option and if=20 > seq number scheme is in use, this need not be used at all. We need to=20 > mandate this as there is no CT in the base spec. But, this is not a=20 > big issue either way. If others agree, I'm fine not mandating this.=20 > But, I really believe, implementations can support this option, at the = > least cost. >=20 > One last comment on the trust on LMA's clock for the sanity check, is=20 > because its an anchor point and its typically well managed, compared=20 > to MAG's, where they are scattered out. So, its reasonable to expect=20 > the clock on the LMA to be in sync, else all registrations will fail=20 > and will generate the traps. >=20 > So, let me know your comments on how we can move forward. >=20 >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > 1. If a MAG's clock is out of sync (i.e., not yet synced by > receiving > > a PBA with timestamp) AND PBUs sent by this MAG are > delayed, the out > > of sync situation may not be detectable by the LMA and old > PBUs may be > > accepted by the LMA. > >=20 > > Consider the following example: MN attaches to MAG1 and shortly=20 > > thereafter hands over to MAG2. MAG2's clock is in sync with LMA's=20 > > clock, but MAG1's clock is out of sync and is ahead of > LMA's clock by > > 5 seconds. MAG1-LMA link is highly congested. When MN attaches to=20 > > MAG1, > > MAG1 sends PBU1 msg to LMA. This happens 3 seconds before > the MN hands > > over to MAG2. The PBU1 msg is delayed by 5 seconds due to the=20 > > congestion and hence arrives at LMA 2 seconds after > handover. Despite > > of the delay, > > PBU1 has a valid timestamp from LMA's point of view due to > the wrong > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after > handover. PBU2 is > > not significantly delayed and arrives at LMA ~1 seconds > after handover > > with valid timestamp. In this scenario, the LMA will wrongly accept > > PBU1 arriving after PBU2, since both have a valid timestamp.=20 > > Consequently, the LMA forwards packets to the wrong MAG (MAG1) and=20 > > will not notice the out of sync of MAG1, which also means > that the LMA > > doesn't return a timestamp in the PBA and MAG1's clock > keeps to be out > > of sync. > >=20 > > 2. When packets on the link between MAG and LMA experience high (and > > varying) packet delays (e.g., due to congestion), the > timestamp in the > > PBA returned by the LMA may already be outdated at the time > it arrives > > at the MAG. So exactly in the situation where a re-ordering > of PBUs is > > needed, the synchronization mechanism may fail. > >=20 > > My two cents. > >=20 > > BR, > >=20 > > Kilian > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Freitag, 7. September 2007 18:48 > > > To: 'Kilian Weniger' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Kilian, > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri, > > > >=20 > > > > > - We are NOT mandating the nodes in the domain to > sync up to a > > > > > clock source. > > > >=20 > > > > Hmm, so far I assumed that the proposal is to mandate the > > > MAGs to sync > > > > up to an external clock source such as NTP server. > > > >=20 > > >=20 > > > For the timestamp option to work, we RECOMMEND the use of NTP for=20 > > > synchronizing the clocks in the domain. However, we do > not want to > > > mandate on a specific mechanism. > > >=20 > > >=20 > > > > > Base draft does not support Context Transfers. Given that > > > the draft > > > > > will be incomplete, if we dont mandate the support.=20 > By mandating > > > > > the support, the LMA can always return its timestamp > and the MAG > > > > > can use that timestamp and register. This need to be > done just > > > > > once whenever the LMA/MAG clocks are out of sync and > > just for one > > > > > registration. One extra round trip for the 1st > > > registration between > > > > > LMA/MAG pair. > > > >=20 > > > > So the proposal is to allow the use of the timestamp > option in the > > > > absence of any external time synchronization like NTP and > > > to mandate a > > > > mechanism to synchronize clocks between MAGs and LMA (and hence=20 > > > > between all MAGs) using the timestamp option in PBU/PBA only > > (i.e., without > > > > utilizing NTP or an external clock source)? Is my understanding=20 > > > > correct? > > > >=20 > > >=20 > > > No. For this to work, we require the clocks to be in sync. > > > How its achieved, it could be based on NTP or some other > protocols. > > > But, why should we mandate this. > > >=20 > > >=20 > > > > If so, can you please give some more details how the LMA can=20 > > > > detect that the clocks are out of sync? Is it based on > a certain > > > > difference of timestamp in the received PBU and the > current LMA's > > > > time? > > > >=20 > > > > And how to differentiate the out of sync case from the > > out-of-order > > > > delivery case (i.e., a PBU is delayed and overtaken by > another PBU > > > > from another MAG)? For instance, if the LMA receives a PBU > > with timestamp > > > > equal to "current time of LMA - X" and X > threshold, how > > > does the LMA > > > > know whether the > > > > 1. the MAG clock is synchronized, but the PBU got > delayed by X or > > > > 2. the PBU is not delayed, but the MAG's clock is out of > > sync by X? > > > > Ideally, in case 1 the LMA should just ignore the PBU, in > > case 2 it > > > > should accept it and sync clocks. > > > >=20 > > > > If the idea is to always reject a PBU with X > threshold > > > and include a > > > > current timestamp in the PBA, then I guess the same could > > > be done with > > > > sequence numbers instead of timestamps, right? > > > >=20 > > >=20 > > > For what ever reasons if the LMA and MAG clocks are out > of sync, the > > > LMA can return its timestamp and the MAG can always apply > that delta > > > in all the registration it sends. This is done just once, > when ever > > > the clocks are off. But, with seq number scheme, this needs > > to be done > > > for each MN registration. Its as per the 3775 per MN seq number. > > >=20 > > > Sri > > >=20 > > > > BR, > > > >=20 > > > > Kilian > > > >=20 > > > >=20 > > > > Panasonic R&D Center Germany GmbH > > > > 63225 Langen, Hessen, Germany > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > > > > Micke > > >=20 > > >=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 07:58:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnKs-0000RO-6G; Thu, 13 Sep 2007 07:58:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnKn-0000Qu-O6 for netlmm@ietf.org; Thu, 13 Sep 2007 07:58:15 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVnKm-0001yS-Ic for netlmm@ietf.org; Thu, 13 Sep 2007 07:58:13 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1189684691!28667153!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12087 invoked from network); 13 Sep 2007 11:58:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 13 Sep 2007 11:58:11 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8DBw6aa026720; Thu, 13 Sep 2007 04:58:11 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l8DBw6HM020185; Thu, 13 Sep 2007 06:58:06 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8DBw4Hc020131; Thu, 13 Sep 2007 06:58:05 -0500 (CDT) Message-ID: <46E925C6.9070903@gmail.com> Date: Thu, 13 Sep 2007 13:57:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF95B2@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116AF95B2@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Hi Sri, > > I completely agree. There are several options for timestamp > synchronization and any deployment can choose any of these mechanism. Right. > Nothing is mandated in the draft and that is good. I don't agree: the draft uses the word 'RECOMMENDED' for timestamp, which is equivalent to 'SHOULD'. draft proxymip6-04: > For solving this [determining sending order] problem, this > specification RECOMMENDS the use of Timestamp option [Section 8.4]. What does 'RECOMMENDS' mean? RFC2119 and Errata: > 3. SHOULD This word, or the adjective "RECOMMENDED", means that > there may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. Putting it all together, a standards reader and implementer thinks like this: "I better implement timestamp option until I demonstrate the particular circumstances where the implications of not using timestamps and using seqnos are understood". I think that up to now I have showed that there are particular circumstances and implications of using timestamps, that may lead to non-working protocol. I think the seqnos method should be default and, if people understand the full implications of using timestamps then timestamps should be weighed before choosing a different course. > On the other hand, if a deployment wants to use SQN, it is absolutely > fine too. > > 1. If a deployment does not mind to have 2 round trips during initial > attach or inter-MAG handoff, then straight forward use of the per-MN > SQN is a possibility. This is not true. It is possible to have the seqno method with only one roundtrip, not two. As I described earlier, one can take advantage of the exchange where the MNP is learned by MAG to also learn the seqno. Thus, a deployment doesn't have to have 2 round trips in order to support per-MN SQN. > 2. If a deployment would like to avoid two round trips during initial > attach or inter-MAG handoff, then they need to synchronize per-MN > SQN across MAGs. How, that is out-of-scope. It is as much out-of-scope as learning the MNP at MAG is. > I do not see any problem with the drafts options and I believe we > have spent a lot of time debating this issue. IMO, The draft is good > as far as this issue is concerned and the issue should be closed. I think it should be closed, yes, but not with the resolution you propose. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnXg-0002Ix-Tj; Thu, 13 Sep 2007 08:11:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnXe-0002Fq-CF for netlmm@ietf.org; Thu, 13 Sep 2007 08:11:30 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVnXe-00039Z-0s for netlmm@ietf.org; Thu, 13 Sep 2007 08:11:30 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1189685489!28255602!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22318 invoked from network); 13 Sep 2007 12:11:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-119.messagelabs.com with SMTP; 13 Sep 2007 12:11:29 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8DCBSvl029778; Thu, 13 Sep 2007 05:11:28 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l8DCBSia015199; Thu, 13 Sep 2007 07:11:28 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l8DCBPRX015137; Thu, 13 Sep 2007 07:11:26 -0500 (CDT) Message-ID: <46E928E8.4070809@gmail.com> Date: Thu, 13 Sep 2007 14:11:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Resending hopefully with the correct format. Thanks. > Hi Kilian/Federico and All, > > There has been a lot of email exchange that the timestamp > synchronization using the PMIPv6 signaling does not work. On the > other hand, I have not seen any in detail analysis which proves that > it does not work. I would like to share in details my thoughts on how > this SHOULD work and please comment as necessary. > > The following are a list of assumptions: > ======================================== > > 1. The time that the P-BU takes from MAG to LMA equals the time the > P-BA takes from LMA to MAG. Ahmad, this is a wrong assumption. As I said earlier, the links between LMA and MAG can easily be asymmetric. One hotspot public deployment uses this ADSL link between the DHCP Server and DHCP Relay; ADSL stands for assymmetric DSL, with a asymmetry of like 25%. This means that the time P-BA takes is like 3 times shorter than the P-BU. Does this affect your calculations? Otherwise, do you assume that always the MAG-LMA link is symmetric? Which link-layer technology? Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnbC-0004YC-UL; Thu, 13 Sep 2007 08:15:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnbC-0004Y6-Fy for netlmm@ietf.org; Thu, 13 Sep 2007 08:15:10 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVnbB-0003HT-G7 for netlmm@ietf.org; Thu, 13 Sep 2007 08:15:10 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1208002uge for ; Thu, 13 Sep 2007 05:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=GfJNXuHS61HSSK4BX+o+vu5BDVcbKQao1qh+mUcd+aU=; b=ghP4u3EQJtbjEe9v0qCM3kQVAfNxuBfAZLcx0AfCN0GBBxX1rYJInxyxJ47yebojhXdNmAPRw59QedYowprPSpzkIumF3wBRtgXiihOQe3CTCE0pdFCt3LYBSBrzCRwtB/SFDfyMW96hXsfjj0PEEfGV5NmK34SU00SA8BNJGQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=cHsNBFLNBHPpGS/K8+8PwyNmiv7nFS1J7bqqXsMjZUubtyapW5IItPxYWhr+zhuoet1EJbP5/K/PCQThj6jzuPa7rLxdmBUOsNYihPYmUrgKXT14s0PPw/1931P6eT5AMsiOU3GqG9V87dYgWTEkHmOpIX1WABEhmA0f5exvlec= Received: by 10.66.221.17 with SMTP id t17mr2954340ugg.1189685708299; Thu, 13 Sep 2007 05:15:08 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id u6sm1047439uge.2007.09.13.05.15.06 (version=SSLv3 cipher=OTHER); Thu, 13 Sep 2007 05:15:07 -0700 (PDT) From: Julien Laganier To: "DE JUAN HUARTE FEDERICO" Subject: Re: [netlmm] DNAv6/SEND and timestamp synchronization problems Date: Thu, 13 Sep 2007 14:15:03 +0200 User-Agent: KMail/1.9.6 References: <200709111620.02475.julien.IETF@laposte.net> <200709121544.14013.julien.IETF@laposte.net> <319D54578EAC3147BA8CC78DAB5467A501399A41@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A41@FRVELSMBS12.ad2.ad.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200709131415.04003.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, On Thursday 13 September 2007, DE JUAN HUARTE FEDERICO wrote: > Hi Julien, > > Julien Laganier wrote: > > If a MAG always test reachability of the MN before extending > > an existing binding (i.e. beyond initial registration) there we > > would have no problem. Maybe we should complete that part of Section > > 6.9.1.: ...=20 > > It makes sense to me to avoid the race condition=20 > problem when using timestamps. For the case of context transfer, I > don't think it's necessary With context transfer inter-MAG handover synchronization would have less=20 problem, I agree. > Note that if the concern is only the case I mentioned (race condition > because MN attached to nMAG but pMAG didn't notice) then it may be > unnecesary if the LMA can tell when a BU is a refresh.=20 Yes, it might be useful to differentiate between pBU establishing a=20 binding at a new MAG, and pBU extending an existing binding. We could=20 have a flag in the pBU to do that. =46WIW, the NETLMM Design Team protocol was making this distinction IIRC. > There are other corner cases (ping-pong between MAGs, fast HO from > pMAG to nMAG1 and then to nMAG2) where it helps but is not > bullet-proof.=20 What would be needed to avoid all race conditions would be a message=20 that is sent LMA to pMAG to delete a previous binding when the LMA=20 receives a pBU from a nMAG with the 'new binding' flag =46WIW again the NETLMM Design Team protocol had such a functionality. > If the timestamp came from the MN (as per you SEND proposal) it would > be bullet-proof Agree. I like the SEND scheme since beside the added value of SEND=20 itself it defeats all race conditions with timestamping. > Still, the case of MN connected/reachable by multiple MAGs would need > further consideration (I'm fine if it's out of scope) This cases actually requires more work than just taking care of race=20 conditions. It needs protocol extensions (e.g. how does the LMA know to=20 which MAG route packets), but that is another topic. Best, =2D-julien > -----Message d'origine----- > De : julien laganier [mailto:julien.laganier@gmail.com] De la part de > Julien Laganier Envoy=E9 : mercredi 12 septembre 2007 15:44 > =C0 : DE JUAN HUARTE FEDERICO > Cc : netlmm@ietf.org > Objet : Re: [netlmm] DNAv6/SEND and timestamp synchronization > problems > > Federico, > > On Wednesday 12 September 2007, DE JUAN HUARTE FEDERICO wrote: > > Julien, > > > > See inline > > Ditto, > > > Julien Laganier wrote: > > > > [...] > > > > > > In my opinion in order to enable this solution, there should > > > > also be the following requirements/constraints: > > > > > > > > - Each BU should be preceded by a SEND message: this phrasing > > > > is intentional to cover not only the scenario of "HO from pMAG > > > > to nMAG" (which seems to be the one that everybody has in mind) > > > > but also the scenario of "lifetime expiration" (thus BU > > > > refresh) > > > > > > That could also be phrased as: When both the MAG and the MN > > > supports SEND, the MAG MAY use a pBU timestamp obtained from ND > > > signalling issued by the MN. In such case, sending a pBU MUST be > > > preceded by obtention of fresh SEND-protected ND message from the > > > MN. > > > > That's fine > > > > > > - The number of MAGs to which the MN is associated should be > > > > constrained to only 1: if the MN can be connected to pMAG and > > > > nMAG concurrently (from SEND point of view), then avoiding race > > > > conditions in PMIP HO would become more complex > > > > > > The race condition problem occuring from simultaneous connexion > > > at two MAGs cannot be defeated by timestamping alone, and is not > > > specific to this SEND method. > > > > Indeed, the race condition problem is not specific to SEND. But I > > thought proposing SEND was aimed to address the problem. Otherwise, > > SEND is just another protocol for time synchronization (instead of > > NTP) > > Simultaneous attachments to different MAGs causes issues with PMIPv6 > which are outside the scope of this specification. The problem cannot > be addressed without protocol extensions. > > > > The only way to defeat such race conditions is that the MN can't > > > be attached to more than one MAG, and a MAG must not send pBU > > > when a MN is not attached. Otherwise it's not going to work, > > > timestamps or not. > > > > Very well described. Only one nuance: with context transfers > > there's no race condition problem. > > With context transfer you would in effect prevent attachment to more > than two MAGs. > > > Is the assumption that we can prevent a MAG to send BU when MN is > > not attached? > > At least I have been making that assumption. > > > Depending on the deployment, there can be a significant delay > > between MN detachment and MAG noticing it > > If a MAG always test reachability of the MN before extending an > existing binding (i.e. beyond initial registration) there we would > have no problem. > > Maybe we should complete that part of Section 6.9.1.: > > Binding Re-Registration: > > > > o For extending the lifetime of a currently existing binding at > > the local mobility, the mobile access gateway MUST send a Proxy > > Binding Update message to the local mobility anchor. The prefix > > value in the Home Network Prefix option present in the request > > SHOULD be set to the currently registered home network prefix and > > the value in the Link-local Address option may be set to ALL_ZERO > > or to the link-local address of the mobile node. > > with this sentence "the MAG MUST make sure the MN is still attached > to it before extending the lifetime of an existing binding. That MAY > be done by using Neighbor Unreachibility Detection (i.e. an NS/NA > exchange.)" > > That could also be included in the MN-MAG interface draft > (draft-ietf-netlmm-mn-ar) via inclusion of a new method > MAG_TEST_MN_REACHABILITY. > > > > > A final comment is that the idea could be generalized to allow > > > > using a sequence number or a timestamp generated by the MN > > > > whenever there's a protocol (e.g. SEND) which is guaranteed to > > > > be executed before sending a BU > > > > > > Yeah, I thought about that generalization, but could not find > > > examples of appropriate MN-generated sequence numbers. For > > > example, it is possible that an L2 sequence number is reset or > > > randomized after each L2 attachment, making it useless for the > > > purpose of ordering pBUs. > > > > A secured L2 wireless interface should support sequence numbers for > > replay protection In fact, it looks like SEND proposes timestamps > > for the sake of replay protection Personally, I don't think that > > using timestamp for replay protection is as secure as using > > sequence numbers, but that's a different topic. > > Yes, that's a difference topic. Anyway for the record, SEND deals > with security of signaling that are not always request/response, > hence making it impossible to use Nonces, or to initialy synchronize > a sequence number. That's why a timestamp is included to provide > reduced, but still useful security. > > --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:21:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVngr-0002B0-Ek; Thu, 13 Sep 2007 08:21:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVngq-0002At-Q0 for netlmm@ietf.org; Thu, 13 Sep 2007 08:21:00 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVngq-0003Vg-CH for netlmm@ietf.org; Thu, 13 Sep 2007 08:21:00 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DCKok02817; Thu, 13 Sep 2007 12:20:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 07:20:49 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E928E8.4070809@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf1/zlDd8TiNOhlSemyEUHkjIRSjwAAAikQ References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, No it does not have an effect on the calculation. Actually the MAG always calculate the timestamp delta based on two things: 1. The timestamp of the P-BA (which is independent from the time the P-BA takes to arrive at the MAG) and=20 2. The timestamp of the corresponding P-BU (Which also independent of downlink delay) Here is the delta: " 6. delta based on P-BU timestamp (LMA.t1 + d2)-(MAG.t1) =3D ((MAG.t1+d1)+d2) - MAG.t1 =3D delta.P-BU =3D d2+d1 " Please see my reply to Kilian for more information. Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Thursday, September 13, 2007 7:11 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO;=20 > netlmm@ietf.org > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > > Resending hopefully with the correct format. >=20 > Thanks. >=20 > > Hi Kilian/Federico and All, > >=20 > > There has been a lot of email exchange that the timestamp=20 > > synchronization using the PMIPv6 signaling does not work.=20 > On the other=20 > > hand, I have not seen any in detail analysis which proves=20 > that it does=20 > > not work. I would like to share in details my thoughts on how this=20 > > SHOULD work and please comment as necessary. > >=20 > > The following are a list of assumptions:=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 1. The time that the P-BU takes from MAG to LMA equals the time the=20 > > P-BA takes from LMA to MAG. >=20 > Ahmad, this is a wrong assumption. As I said earlier, the=20 > links between LMA and MAG can easily be asymmetric. One=20 > hotspot public deployment uses this ADSL link between the=20 > DHCP Server and DHCP Relay; ADSL stands for assymmetric DSL,=20 > with a asymmetry of like 25%. This means that the time P-BA=20 > takes is like 3 times shorter than the P-BU. >=20 > Does this affect your calculations? >=20 > Otherwise, do you assume that always the MAG-LMA link is symmetric? > Which link-layer technology? >=20 > Thanks, >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:21:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnh3-0002EI-O5; Thu, 13 Sep 2007 08:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnh3-0002Dl-0T for netlmm@ietf.org; Thu, 13 Sep 2007 08:21:13 -0400 Received: from hu-out-0506.google.com ([72.14.214.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVnh0-0002sc-TF for netlmm@ietf.org; Thu, 13 Sep 2007 08:21:12 -0400 Received: by hu-out-0506.google.com with SMTP id 31so185028huc for ; Thu, 13 Sep 2007 05:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=UbqXaniDolUQdkSL4LSXKzm53EQ5YZGd/mX1MNQ6JFE=; b=ciQrUI9CXUym/npbEMveIatLUBxYuuaGUoII7QKRnUhgLAkP6BYWIXKMK8j2IkwvS92b7K0fvVrX2L1AYy6yTZtmCUoBRM3x4u60Us2E2Lr126WDMy85lyHe+dIEjO70T6iJ+m0Z0ir9l9JMgFesTl87zWippTTtbxWpr6ogZu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=C/DzvYQZm8hHUzvuenfalFxTvZaZRCNppS5+WRPGTQNATu3Oh4qD6qZ2QyZ/Ldl5eMjcz7zFnoykK8P1iA+9xtwjGUttEYWGf3WWSY0oE72Ayicd5gkhHEXDRfohNxPveIqCs5KxOXwhRHmWhgZ2pLnOZv/KEcQBLKWqZJS1SlA= Received: by 10.67.32.9 with SMTP id k9mr2958651ugj.1189686069807; Thu, 13 Sep 2007 05:21:09 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id o30sm1049028ugd.2007.09.13.05.21.08 (version=SSLv3 cipher=OTHER); Thu, 13 Sep 2007 05:21:09 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 14:21:05 +0200 User-Agent: KMail/1.9.6 References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> In-Reply-To: <46E928E8.4070809@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200709131421.05930.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Thursday 13 September 2007, Alexandru Petrescu wrote: > > The following are a list of assumptions: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 1. The time that the P-BU takes from MAG to LMA equals the time the > > P-BA takes from LMA to MAG. > > Ahmad, this is a wrong assumption. =A0As I said earlier, the links > between LMA and MAG can easily be asymmetric. =A0One hotspot public > deployment uses this ADSL link between the DHCP Server and DHCP > Relay; ADSL stands for assymmetric DSL, with a asymmetry of like 25%. > =A0This means that the time P-BA takes is like 3 times shorter than the > P-BU. =46WIW the asymmetry in ADSL is w.r.t. bandwidth, not end-to-end delivery=20 delay as you indicate above. =2D-julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:23:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnj4-00039o-DH; Thu, 13 Sep 2007 08:23:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnj3-00039i-KW for netlmm@ietf.org; Thu, 13 Sep 2007 08:23:17 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVnj2-0002xe-Fz for netlmm@ietf.org; Thu, 13 Sep 2007 08:23:17 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1189686194!28669359!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 4553 invoked from network); 13 Sep 2007 12:23:14 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-14.tower-119.messagelabs.com with SMTP; 13 Sep 2007 12:23:14 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8DCN9dE029949; Thu, 13 Sep 2007 05:23:09 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l8DCN8J9028526; Thu, 13 Sep 2007 07:23:08 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8DCN4uA028438; Thu, 13 Sep 2007 07:23:05 -0500 (CDT) Message-ID: <46E92BA3.2030502@gmail.com> Date: Thu, 13 Sep 2007 14:22:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <200709131421.05930.julien.IETF@laposte.net> In-Reply-To: <200709131421.05930.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > On Thursday 13 September 2007, Alexandru Petrescu wrote: >>> The following are a list of assumptions: >>> ======================================== >>> >>> 1. The time that the P-BU takes from MAG to LMA equals the time the >>> P-BA takes from LMA to MAG. >> Ahmad, this is a wrong assumption. As I said earlier, the links >> between LMA and MAG can easily be asymmetric. One hotspot public >> deployment uses this ADSL link between the DHCP Server and DHCP >> Relay; ADSL stands for assymmetric DSL, with a asymmetry of like 25%. >> This means that the time P-BA takes is like 3 times shorter than the >> P-BU. > > FWIW the asymmetry in ADSL is w.r.t. bandwidth, not end-to-end delivery > delay as you indicate above. What do you mean Julien? Bandwidth is directly related to end to end delivery delay isn't it? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:36:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnw7-0003gg-LA; Thu, 13 Sep 2007 08:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnw6-0003f7-7Z for netlmm@ietf.org; Thu, 13 Sep 2007 08:36:46 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVnw4-0003Iz-VV for netlmm@ietf.org; Thu, 13 Sep 2007 08:36:46 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1189687003!2294096!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 25991 invoked from network); 13 Sep 2007 12:36:43 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-3.tower-128.messagelabs.com with SMTP; 13 Sep 2007 12:36:43 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8DCacks001928; Thu, 13 Sep 2007 05:36:42 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8DCabi7007674; Thu, 13 Sep 2007 07:36:37 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8DCaXA2007569; Thu, 13 Sep 2007 07:36:34 -0500 (CDT) Message-ID: <46E92ECB.9080106@gmail.com> Date: Thu, 13 Sep 2007 14:36:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Hi Alex, > > No it does not have an effect on the calculation. So why do you mention it as an assumption? Alex > > Actually the MAG always calculate the timestamp delta based on two > things: > > 1. The timestamp of the P-BA (which is independent from the time the > P-BA takes to arrive at the MAG) and > 2. The timestamp of the corresponding P-BU (Which also independent of > downlink delay) > > Here is the delta: > > " > 6. delta based on P-BU timestamp (LMA.t1 + d2)-(MAG.t1) > = > ((MAG.t1+d1)+d2) - MAG.t1 > = > delta.P-BU = d2+d1 > > " > > Please see my reply to Kilian for more information. > > Regards, > Ahmad > > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Thursday, September 13, 2007 7:11 AM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO; >> netlmm@ietf.org >> Subject: Re: [netlmm] timestamp vs seqno redux >> >> Ahmad Muhanna wrote: >>> Resending hopefully with the correct format. >> Thanks. >> >>> Hi Kilian/Federico and All, >>> >>> There has been a lot of email exchange that the timestamp >>> synchronization using the PMIPv6 signaling does not work. >> On the other >>> hand, I have not seen any in detail analysis which proves >> that it does >>> not work. I would like to share in details my thoughts on how this >>> SHOULD work and please comment as necessary. >>> >>> The following are a list of assumptions: >>> ======================================== >>> >>> 1. The time that the P-BU takes from MAG to LMA equals the time the >>> P-BA takes from LMA to MAG. >> Ahmad, this is a wrong assumption. As I said earlier, the >> links between LMA and MAG can easily be asymmetric. One >> hotspot public deployment uses this ADSL link between the >> DHCP Server and DHCP Relay; ADSL stands for assymmetric DSL, >> with a asymmetry of like 25%. This means that the time P-BA >> takes is like 3 times shorter than the P-BU. >> >> Does this affect your calculations? >> >> Otherwise, do you assume that always the MAG-LMA link is symmetric? >> Which link-layer technology? >> >> Thanks, >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnxf-0004xd-9j; Thu, 13 Sep 2007 08:38:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnxd-0004xX-Jl for netlmm@ietf.org; Thu, 13 Sep 2007 08:38:21 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVnxd-000422-01 for netlmm@ietf.org; Thu, 13 Sep 2007 08:38:21 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8DCZs609208; Thu, 13 Sep 2007 12:35:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 07:38:09 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E92ECB.9080106@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2AsJasIG8vj67R4i8lOnehN0qsgAAAUtw References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > > Hi Alex, > >=20 > > No it does not have an effect on the calculation. >=20 > So why do you mention it as an assumption? [Ahmad] It is an over sight on my part. Sorry for the confusion. >=20 > Alex >=20 > >=20 > > Actually the MAG always calculate the timestamp delta based on two > > things: > >=20 > > 1. The timestamp of the P-BA (which is independent from the=20 > time the=20 > > P-BA takes to arrive at the MAG) and 2. The timestamp of the=20 > > corresponding P-BU (Which also independent of downlink delay) > >=20 > > Here is the delta: > >=20 > > " > > 6. delta based on P-BU timestamp (LMA.t1 + d2)-(MAG.t1) > > =3D > > =20 > ((MAG.t1+d1)+d2) - MAG.t1 > > =3D > > delta.P-BU =3D = d2+d1 > >=20 > > " > >=20 > > Please see my reply to Kilian for more information. > >=20 > > Regards, > > Ahmad > > =20 > >=20 > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Thursday, September 13, 2007 7:11 AM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO;=20 > >> netlmm@ietf.org > >> Subject: Re: [netlmm] timestamp vs seqno redux > >> > >> Ahmad Muhanna wrote: > >>> Resending hopefully with the correct format. > >> Thanks. > >> > >>> Hi Kilian/Federico and All, > >>> > >>> There has been a lot of email exchange that the timestamp=20 > >>> synchronization using the PMIPv6 signaling does not work. > >> On the other > >>> hand, I have not seen any in detail analysis which proves > >> that it does > >>> not work. I would like to share in details my thoughts on=20 > how this=20 > >>> SHOULD work and please comment as necessary. > >>> > >>> The following are a list of assumptions:=20 > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> 1. The time that the P-BU takes from MAG to LMA equals=20 > the time the=20 > >>> P-BA takes from LMA to MAG. > >> Ahmad, this is a wrong assumption. As I said earlier, the links=20 > >> between LMA and MAG can easily be asymmetric. One hotspot public=20 > >> deployment uses this ADSL link between the DHCP Server and DHCP=20 > >> Relay; ADSL stands for assymmetric DSL, with a asymmetry=20 > of like 25%. =20 > >> This means that the time P-BA takes is like 3 times=20 > shorter than the=20 > >> P-BU. > >> > >> Does this affect your calculations? > >> > >> Otherwise, do you assume that always the MAG-LMA link is symmetric? > >> Which link-layer technology? > >> > >> Thanks, > >> > >> Alex > >> > >> > >>=20 > _____________________________________________________________________ > >> _ This email has been scanned by the MessageLabs Email Security=20 > >> System. > >> For more information please visit > >> http://www.messagelabs.com/email > >>=20 > _____________________________________________________________________ > >> _ > >> > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:44:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVo3R-0002uO-SK; Thu, 13 Sep 2007 08:44:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVo3Q-0002uE-DV for netlmm@ietf.org; Thu, 13 Sep 2007 08:44:20 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVo3P-0004DZ-PY for netlmm@ietf.org; Thu, 13 Sep 2007 08:44:20 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DCiGt05328; Thu, 13 Sep 2007 12:44:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 07:44:14 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B49F49@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E925C6.9070903@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf1/V6IkZUjNpbDSkOXrbUksZQhWgAAy30A References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF95B2@zrc2hxm2.corp.nortel.com> <46E925C6.9070903@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, Please see comments inline. Regards, Ahmad =20 > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > > Hi Sri, > >=20 > > I completely agree. There are several options for timestamp=20 > > synchronization and any deployment can choose any of these=20 > mechanism. >=20 > Right. >=20 > > Nothing is mandated in the draft and that is good. >=20 > I don't agree: the draft uses the word 'RECOMMENDED' for=20 > timestamp, which is equivalent to 'SHOULD'. [Ahmad] I agree with the draft recommendation for the following reason: Timestamp with a synchronization mechanism (where the choice is not mandated) successfully address all P-BU/P-BA ordering including inter-MAG handoff in a single round trip. If PMIPv6 signaling is used for synchronization there is a very slim chance that it may require 2 round trips. On the other hand, the use of SQN without an out-of-scope mechanism to synchronize the SQN across MAGs will always require 2 round trips. The fact that the synchronization mechanism of SQN across MAGs is currently undefined, I support the draft recommendation. There has to be a defined default working mechanism in the draft which does not depend on any undefined mechanism. >=20 > draft proxymip6-04: > > For solving this [determining sending order] problem, this=20 > > specification RECOMMENDS the use of Timestamp option [Section 8.4]. >=20 > What does 'RECOMMENDS' mean? RFC2119 and Errata: > > 3. SHOULD This word, or the adjective "RECOMMENDED", means that=20 > > there may exist valid reasons in particular circumstances=20 > to ignore a =20 > > particular item, but the full implications must be understood and=20 > > carefully weighed before choosing a different course. >=20 > Putting it all together, a standards reader and implementer=20 > thinks like this: "I better implement timestamp option until=20 > I demonstrate the particular circumstances where the=20 > implications of not using timestamps and using seqnos are understood". [Ahmad] We can check the draft text, I believe it requires the SQN synchronization across MAGs. In there the draft also can mention if no SQN synchronization is available, an initial attach and inter-MAG handoff requires 2 round trips.=20 >=20 > I think that up to now I have showed that there are=20 > particular circumstances and implications of using=20 > timestamps, that may lead to non-working protocol. [Ahmad] I am sorry, that is not true and I have not seen that proof. >=20 > I think the seqnos method should be default and, if people=20 > understand the full implications of using timestamps then=20 > timestamps should be weighed before choosing a different course. [Ahmad] IMO, That is backward. >=20 > > On the other hand, if a deployment wants to use SQN, it is=20 > absolutely=20 > > fine too. > >=20 > > 1. If a deployment does not mind to have 2 round trips=20 > during initial =20 > > attach or inter-MAG handoff, then straight forward use of=20 > the per-MN =20 > > SQN is a possibility. >=20 > This is not true. >=20 > It is possible to have the seqno method with only one=20 > roundtrip, not two. As I described earlier, one can take=20 > advantage of the exchange where the MNP is learned by MAG to=20 > also learn the seqno. >=20 > Thus, a deployment doesn't have to have 2 round trips in=20 > order to support per-MN SQN. [Ahmad] Alex, you failed to address all concerns about your proposal and at the end you decided to not address the latest concerns saying that the Co-chairs need to make a decision. IMO, before asking the chairs to decide on a technical issue, we need to answer all questions raised in order for anyone to make a good judgment of the proposal. So far, I disagree that you have presented a working mechanism. >=20 > > 2. If a deployment would like to avoid two round trips=20 > during initial =20 > > attach or inter-MAG handoff, then they need to synchronize=20 > per-MN SQN=20 > > across MAGs. How, that is out-of-scope. >=20 > It is as much out-of-scope as learning the MNP at MAG is. [Ahmad] Alex, Please, That is not true. We can go over this again. If you would like. >=20 > > I do not see any problem with the drafts options and I=20 > believe we have=20 > > spent a lot of time debating this issue. IMO, The draft is good as=20 > > far as this issue is concerned and the issue should be closed. >=20 > I think it should be closed, yes, but not with the resolution=20 > you propose. [Ahmad] Unless you point a valid reason not to close it, otherwise, it should be closed, IMO. >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:47:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVo61-0004z5-9v; Thu, 13 Sep 2007 08:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVo60-0004yU-5k for netlmm@ietf.org; Thu, 13 Sep 2007 08:47:00 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVo5y-0003cy-1m for netlmm@ietf.org; Thu, 13 Sep 2007 08:47:00 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8DCjQYo024397; Thu, 13 Sep 2007 14:45:26 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 14:44:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 14:44:54 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A46@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48ABC9@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAlmf7QAAwgPsAABPRSMA== References: <46DFC1C7.9060103@gmail.com><01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com><1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de><010301c7f16e$d25ec030$d4f6200a@amer.cisco.com><1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de><000001c7f504$24c8eb50$d5f6200a@amer.cisco.com><1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de><011901c7f5a3$6dd04ab0$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48ABC9@lan-ex-02.panasonic.de> From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" X-OriginalArrivalTime: 13 Sep 2007 12:44:55.0324 (UTC) FILETIME=[E2C4EDC0:01C7F603] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, in my opinion, from deployment point of view: - In order to use the timestamp option MAGs need to have their clock = synchronized. This should be a conditional requirement (only applicable = if deployment chooses to use timestamps) - The LMAs may also be synchronized to the same time source (e.g. to = use timestamp in Back for diagnostics). But it's enough as a = recommendation (thus not a requirement) - The means used to synchronize MAGs (and potentially LMAs) should be = a deployment decision And from implementation point of view: - The MAG capability to add the timestamp option in the BU should be = a recommendation rather than a requirement - The LMA capability to process the timestamp option in the BU should = be a requirement (otherwise MAGs would not be able to use it) - The LMA capability to add timestamp in Back should be a = recommendation (thus not a requirement) - The MAG capability to process the timestamp in Back should be a = recommendation (thus not a requirement) - The MAG capability to re-synch its own clock with the timestamp in = Back should be a recommendation (thus not a requirement) at most. = Depending on the result of the discussion with Ahmad, I would even = prefer to not mention it Other aspects: - The proposal from Julien (preferably in generalized format) to use = information from the MN (when available) should be a recommendation - It would be good to mention the race condition problem when using = timestamps: 2 MAGs may send BU very close in time. The result of a race = condition may be that the MN is connected to MAG2, but the the binding = in the LMA is to MAG1, so it should not be neglected When I say recommendation, I don't have a strong opinion between SHOULD = or MAY Regards federico -----Message d'origine----- De : Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 Envoy=E9 : jeudi 13 septembre 2007 09:18 =C0 : Sri Gundavelli Cc : netlmm@ietf.org Objet : RE: [netlmm] timestamp vs seqno redux Hi Sri, the simple method of using the timestamp in the PBA sent by the LMA to = sync MAG's clock has issues in some scenarios IMO. As explained in the = previous emails of this thread, these issues can lead to unsuccessful = clock sync and wrong BCEs, which in turn may result in significant = packet loss. Do you agree that this can happen?=20 If so, my suggestion is to disallow the synchronization of MAG's clock = using the timestamp in the PBA as specified in the draft currently. At = least there should be some text in the draft explaining the issues to = the reader, so that an implementor is aware of them. Please note that I'm only talking about *synchronization of MAG's clock = using the timestamp in the PBA*. Using the timestamp in PBUs to re-order = PBUs is not related to that and ok (under the assumption that the MAGs' clocks are synchronized using some PMIP-independent mechanism like NTP) Please see some more comments inline.=20 BR, Kilian > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Donnerstag, 13. September 2007 03:14 > To: 'Kilian Weniger' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Kilian, > =20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > Sent: Wednesday, September 12, 2007 1:07 AM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Sri, > >=20 > > please see my comments inline. > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Mittwoch, 12. September 2007 08:14 > > > To: 'Kilian Weniger' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] timestamp vs seqno redux > > >=20 > > > Hi Kilian/Federico, > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Hi Sri, > > > >=20 > > > > my point is that NOT mandating synchronization to an > > external clock > > > > source for the timestamp option implies that sending > PBU msgs with > > > > timestamp option is allowed even when MAGs are not (yet) > > > synchronized. > > > > I.e., it would be allowed that a deployment uses only > the returned > > > > timestamps in PBA msgs to synchronize the MAG clocks. I think=20 > > > > the draft should not allow this for the following reasons: > > > >=20 > > >=20 > > > The stated assumption for the timestamp based approach to work, is = > > > the requirement for the MAG's to have synchronized clocks. > > > That is a requirement. Now, if a given MAG sends a PBU with an=20 > > > incorrect timestamp, its an error and as you and Federico pointed=20 > > > out, there are cases where the LMA will not be able to determine=20 > > > the sending order of the received packets. This is an error=20 > > > condition, as the requirement is not met. > >=20 > > Right, sending a PBU with timestamp option requires that the MAG's=20 > > clock is synchronized. Hence, I don't see why the draft should=20 > > specify a mechanism to synchronize a MAG's clock using a received=20 > > PBA. Also, I think this mechanism has issues in some scenario (see=20 > > my previous mail). > >=20 >=20 > The draft is not mandating on MAG to sync with the LMA clock. Its=20 > really upto the MAG on what do do. Its requiring the MAG to sync up to = > a clock source. I can slightly modify the below text suggesting it to=20 > sync up to LMAs clock. >=20 > "If the received Proxy Binding Acknowledgement message has the Status=20 > field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), the mobile=20 > access gateway SHOULD try to register again only after it synchronized = > its clock with the local mobility anchor's system clock or to a common = > time source that is used by all mobility entities in that domain for=20 > their clock synchronization." > =20 >=20 >=20 > >=20 > > The clock synchronization is the job of some PMIP-independent=20 > > synchronization method like NTP and out of sync clocks can only=20 > > occur if there is a problem with this PMIP-independent > synchronization method. > > Hence, it is a non-recoverable error case from PMIP point of view=20 > > IMHO. > >=20 >=20 > Sure. >=20 > > >=20 > > > Now, should the draft state that the time synchronization is a=20 > > > requirement and additionally mandate a method of time > > synchronization, > > > say by NTP ? But, the later has a system wide impact and > > additionally, > > > a given architecture where this protocol is applied, can > achieve the > > > time synchronization through other non NTP means. IMO, we may not=20 > > > be able dictate that. Also, we want implementations to support the = > > > timestamp based scheme by default. Now, mandating the NTP > usage will > > > create some restrictions for some deployments. So, that is the=20 > > > reasoning behind not mandating the method of time synchronization. > >=20 > > I'm not sure if the draft can say "a MAG's clock MUST be > synchronized > > for this protocol to work, but how this is done is out of > scope of the > > draft". I guess the draft has to mandate the implementation of one=20 > > "default" synchronization protocol such as NTP to achieve=20 > > interoperability. However, as long as the use of NTP is not mandated = > > (e.g., just say "SHOULD use"), deployments can still use other=20 > > methods. > > So I don't see restrictions for deployments in this case.=20 > >=20 >=20 > I'm not sure, if we should mandate on NTP. The protocol has a=20 > requirement and I think, how deployments achieve that is not our=20 > issue. For ex, we need Routing between LMA and MAG. That's the=20 > assumption, we dont say there MUST be OSPF enabled between them. I=20 > really think, we should just state the requirement strongly and make a = > note that the mechanism will not work, if the requirement is not met.=20 > It is sufficient, IMHO. If this is really sufficient for standards track, I'm fine with not = mandating any time sync protocol. >=20 > > >=20 > > > W.r.t this below scenario, the reason for LMA to return its > > timestamp, > > > solves two purposes. 1.) Diagnostics (especially useful > when the LMA > > > and MAG are in different admin domains) 2.) The MAG can > detect that > > > its clock is not in sync and take the necessary actions. I guess,=20 > > > Frederico has an issue with the second part. But, if you look at=20 > > > the recommendation from the draft on handling this error case, MAG = > > > signaling considerations, > > >=20 > > > "If the received Proxy Binding Acknowledgement > message has the > > > Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > > > Timestamp), > > > the mobile access gateway SHOULD try to register again only=20 > > > after > > > it synchronized its clock with the local mobility anchor's=20 > > > system > > > clock or to a common time source that is used by > all mobility > > > entities in that domain for their clock synchronization." > > >=20 > >=20 > > I think it is good if the LMA informs the MAG about detected out of=20 > > sync clocks for the purpose of diagnostics and as a trigger for=20 > > re-sync. But why do we need the timestamp option in the PBA? The > TIMESTAMP_MISMATCH > > value in the status field is enough for the purpose of > diagnostics and > > as a trigger for re-sync.=20 > >=20 >=20 > Returning just an error code is not sufficient. It will be very hard=20 > to run any diagnostics. I suggest we leave this. I'm ok on not stating = > that the MAG should not sync up to the LMA's clock and should use a=20 > common clock source. The returned timestamp is also used for matching You mean "stating" or "not stating"?=20 I'm not against syncing up to the LMA's clock per se. The point is that = the timestamp in the PBA should not be used to do that. Instead, a = dedicated sync protocol like NTP (which also considers packet delay) = should be used to sync up to LMA's clock. > request to response. So, we can leave this there. >=20 >=20 > Sri >=20 >=20 >=20 Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:49:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVo8Q-0007GB-EF; Thu, 13 Sep 2007 08:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVo8P-0007A0-5U for netlmm@ietf.org; Thu, 13 Sep 2007 08:49:29 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVo8N-0003jt-G1 for netlmm@ietf.org; Thu, 13 Sep 2007 08:49:29 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1189687765!4177462!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 5837 invoked from network); 13 Sep 2007 12:49:25 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-153.messagelabs.com with SMTP; 13 Sep 2007 12:49:25 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l8DCnKXe001327; Thu, 13 Sep 2007 05:49:25 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l8DCnJ7W016508; Thu, 13 Sep 2007 07:49:19 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8DCnGtr016435; Thu, 13 Sep 2007 07:49:17 -0500 (CDT) Message-ID: <46E931C6.5060600@gmail.com> Date: Thu, 13 Sep 2007 14:49:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: >> Subject: Re: [netlmm] timestamp vs seqno redux >> >> Ahmad Muhanna wrote: >>> Hi Alex, >>> >>> No it does not have an effect on the calculation. >> So why do you mention it as an assumption? > > [Ahmad] > It is an over sight on my part. Sorry for the confusion. Ahmad, I think any assumption on a constant delay of the network is wrong, be it symmetric or asymmetric. You do a measurement now and ten minutes later the delays are different because somebody else loads the network. You do 10 measurements in a burst and you get different times, eventually with a Gaussian distribution. That's the first experience with ping. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:52:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoBf-0003t6-Gm; Thu, 13 Sep 2007 08:52:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoBe-0003pZ-Cq for netlmm@ietf.org; Thu, 13 Sep 2007 08:52:50 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVoBc-0004av-4H for netlmm@ietf.org; Thu, 13 Sep 2007 08:52:50 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1189687965!7634141!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 7860 invoked from network); 13 Sep 2007 12:52:46 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-9.tower-153.messagelabs.com with SMTP; 13 Sep 2007 12:52:46 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8DCqjnB004496; Thu, 13 Sep 2007 05:52:45 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l8DCqiOU018890; Thu, 13 Sep 2007 07:52:44 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8DCqfZp018797; Thu, 13 Sep 2007 07:52:41 -0500 (CDT) Message-ID: <46E93293.1050801@gmail.com> Date: Thu, 13 Sep 2007 14:52:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Resending hopefully with the correct format. > > +++++ > > Hi Kilian/Federico and All, > > There has been a lot of email exchange that the timestamp > synchronization using the PMIPv6 signaling does not work. On the other > hand, I have not seen any in detail analysis which proves that it does > not work. I would like to share in details my thoughts on how this > SHOULD work and please comment as necessary. > > The following are a list of assumptions: > ======================================== > > 1. The time that the P-BU takes from MAG to LMA equals the time the P-BA > takes from LMA to MAG. > 2. LMA Timestamp included in the P-BA is the LMA timestamp when > comparing timestamp in P-BU and LMA current timestamp. > 3. MAG use the difference between the P-BU timestamp and P-BA timestamp > for calculating the delta! > 4. MAG and LMA maintains the same out of sync delta during the > re-synchronization process. Ahmad, you should also list the implicit assumption you make that MAG and LMA will keep time ok, once synchronized. Or, that assumption can sometimes be not true. An LMA or MAG's LiIon BIOS battery can dry out and reset the clocks on an arbitrary basis. Alex > > > MAG LMA > ---------- ---------- > 1. Current Timestamp MAG.t1 LMA.t1 = MAG.t1 +d1 > 2. Timestamp in P-BU MAG.t1 LMA timestamp: LMA.t1 > 3. MAG sends P-BU ============>>>>>>> P-BU(MAG.t1) > > 4. P-BU arrives at LMA .............. ===============>>>> P-BU(MAG.t1) > > 5. Arrival Timestamp MAG.t1 + d2 LMA.t1 + d2 > 6. delta based on P-BU timestamp (LMA.t1 + d2)-(MAG.t1) > = > ((MAG.t1+d1)+d2) - MAG.t1 > = > delta.P-BU = d2+d1 > > 7. Real delta delta.real = d1 > > > > 8. Timestamp in P-BA MAG.t2 LMA.t2 = (LMA.t1 + d2) > P-BA(LMA.t2)<<<<<<<<<<<============== > 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 > 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in corresponding P-BU) > = > (LMA.t1 + d2) - MAG.t1 > = > ((MAG.t1 +d1)+d2) -MAG.t1 > > delta = d1+d2 > > 11. Real delta delta.real = d1 > > > What is the problem here? Or am I missing something? > Let us examine a re-registration or a P-BU/PA exchange based on the > above synchronization: > > > MN- Resynchronization/Re-registration: > ======================================= > > 12. Current timestamp MAG.t3 LMA.t3 = MAG.t3 + d1 > 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 > 14. MAG sends P-BU ============>>>>>>> P-BU(MAG.t3 + (d2+d1)) > > 15. P-BU arrives at LMA .......============>>>> P-BU(MAG.t3+(d1+d2)) > 16. Arrival Timestamp MAG.t3 + d2 LMA.t3 + d2 > 17. delta based on P-BU (LMA.t3+d2)-(MAG.t3+(d2+d1)) > = > ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1)) > = > > delta.P-BU = ZERO > 18. Real delta delta.real = ZERO > > Please let me know what I am missing. > If nothing, I hope we can put an end to this debate and MOVE ON. > > Regards, > Ahmad > > >> -----Original Message----- >> From: Muhanna, Ahmad (RICH1:2H10) >> Sent: Wednesday, September 12, 2007 9:59 AM >> To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE FEDERICO' >> Cc: 'netlmm@ietf.org' >> Subject: RE: [netlmm] timestamp vs seqno redux >> >> Hi Kilian/Federico and All, >> >> >> There has been a lot of email exchange that the timestamp >> synchronization using the PMIPv6 signaling does not work. On >> the other hand, I have not seen any in detail analysis which >> proves that it does not work. I would like to share in >> details my thoughts on how this SHOULD work and please >> comment as necessary. >> >> The following are a list of assumptions: >> ======================================== >> >> 1. The time that the P-BU takes from MAG to LMA equals the >> time the P-BA takes from LMA to MAG. >> 2. LMA Timestamp included in the P-BA is the LMA timestamp >> when comparing timestamp in P-BU and LMA current timestamp. >> 3. MAG use the difference between the P-BU timestamp and P-BA >> timestamp for calculating the delta! >> 4. MAG and LMA maintains the same out of sync delta during >> the re-synchronization process. >> >> >> >> MAG >> LMA >> ---------- >> ---------- >> 1. Current Timestamp MAG.t1 >> LMA.t1 = MAG.t1 +d1 >> 2. Timestamp in P-BU MAG.t1 LMA >> timestamp: LMA.t1 >> 3. MAG sends P-BU ============>>>>>>> P-BU(MAG.t1) >> 4. P-BU arrives at LMA ....................... >> ===============>>>> P-BU(MAG.t1) >> 5. Arrival Timestamp MAG.t1 + d2 >> LMA.t1 + d2 >> >> 6. delta based on P-BU timestamp >> (LMA.t1 + d2) - (MAG.t1) >> >> = >> >> ((MAG.t1+d1)+d2) - MAG.t1 >> >> = >> >> delta.P-BU = d2+d1 >> >> 7. Real delta >> delta.real = d1 >> >> >> 8. Timestamp in P-BA MAG.t2 >> LMA.t2 = (LMA.t1 + d2) >> >> P-BA(LMA.t2)<<<<<<<<<<<===================== >> 9. P-BA arrives @ MAG MAG.t2 + d2 >> LMA.t2 + d2 >> 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in >> corresponding P-BU) >> = >> (LMA.t1 + d2) - MAG.t1 >> = >> ((MAG.t1 +d1)+d2) -MAG.t1 >> >> delta = d1+d2 >> >> 11. Real delta delta.real = d1 >> >> >> What is the problem here? Or am I missing something? >> >> >> Let us examine a re-registration or a P-BU/PA exchange based >> on the above synchronization: >> ============================================================== >> ============================ >> >> MN- Resynchronization/Re-registration: >> ======================================= >> >> 12. Current timestamp MAG.t3 >> LMA.t3 = MAG.t3 + d1 >> 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 >> 14. MAG sends P-BU ============>>>>>>> P-BU(MAG.t3 + (d2+d1)) >> 15. P-BU arrives at LMA >> .......................===============>>>> P-BU(MAG.t3 + (d1+d2)) >> 16. Arrival Timestamp MAG.t3 + d2 >> LMA.t3 + d2 >> >> 17. delta based on P-BU >> (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) >> >> = >> >> ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) >> >> = >> >> delta.P-BU = ZERO >> >> 18. Real delta >> delta.real = ZERO >> >> Please let me know what I am missing. >> >> If nothing, I hope we can put an end to this debate and MOVE ON. >> >> >> Regards, >> Ahmad >> >> >>> -----Original Message----- >>> From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] >>> Sent: Wednesday, September 12, 2007 3:07 AM >>> To: Sri Gundavelli >>> Cc: netlmm@ietf.org >>> Subject: RE: [netlmm] timestamp vs seqno redux >>> >>> Hi Sri, >>> >>> please see my comments inline. >>> >>>> -----Original Message----- >>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>> Sent: Mittwoch, 12. September 2007 08:14 >>>> To: 'Kilian Weniger' >>>> Cc: netlmm@ietf.org >>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>> >>>> Hi Kilian/Federico, >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] >>>>> Sent: Tuesday, September 11, 2007 6:33 AM >>>>> To: Sri Gundavelli >>>>> Cc: netlmm@ietf.org >>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>> >>>>> Hi Sri, >>>>> >>>>> my point is that NOT mandating synchronization to an >>> external clock >>>>> source for the timestamp option implies that sending PBU >>> msgs with >>>>> timestamp option is allowed even when MAGs are not (yet) >>>> synchronized. >>>>> I.e., it would be allowed that a deployment uses only the >>> returned >>>>> timestamps in PBA msgs to synchronize the MAG clocks. I >> think the >>>>> draft should not allow this for the following reasons: >>>>> >>>> The stated assumption for the timestamp based approach to >> work, is >>>> the requirement for the MAG's to have synchronized clocks. >>>> That is a requirement. Now, if a given MAG sends a PBU with an >>>> incorrect timestamp, its an error and as you and Federico pointed >>>> out, there are cases where the LMA will not be able to >> determine the >>>> sending order of the received packets. This is an error >> condition, >>>> as the requirement is not met. >>> Right, sending a PBU with timestamp option requires that the MAG's >>> clock is synchronized. Hence, I don't see why the draft >> should specify >>> a mechanism to synchronize a MAG's clock using a received >> PBA. Also, I >>> think this mechanism has issues in some scenario (see my previous >>> mail). >>> >>> >>> The clock synchronization is the job of some PMIP-independent >>> synchronization method like NTP and out of sync clocks can >> only occur >>> if there is a problem with this PMIP-independent synchronization >>> method. >>> Hence, it is a non-recoverable error case from PMIP point of view >>> IMHO. >>> >>>> Now, should the draft state that the time synchronization is a >>>> requirement and additionally mandate a method of time >>> synchronization, >>>> say by NTP ? But, the later has a system wide impact and >>> additionally, >>>> a given architecture where this protocol is applied, can >> achieve the >>>> time synchronization through other non NTP means. IMO, we >> may not be >>>> able dictate that. Also, we want implementations to support the >>>> timestamp based scheme by default. Now, mandating the NTP >> usage will >>>> create some restrictions for some deployments. So, that is the >>>> reasoning behind not mandating the method of time synchronization. >>> I'm not sure if the draft can say "a MAG's clock MUST be >> synchronized >>> for this protocol to work, but how this is done is out of >> scope of the >>> draft". I guess the draft has to mandate the implementation of one >>> "default" synchronization protocol such as NTP to achieve >>> interoperability. However, as long as the use of NTP is not >> mandated >>> (e.g., just say "SHOULD use"), deployments can still use other >>> methods. >>> So I don't see restrictions for deployments in this case. >>> >>>> W.r.t this below scenario, the reason for LMA to return its >>> timestamp, >>>> solves two purposes. 1.) Diagnostics (especially useful >> when the LMA >>>> and MAG are in different admin domains) 2.) The MAG can >> detect that >>>> its clock is not in sync and take the necessary actions. I guess, >>>> Frederico has an issue with the second part. But, if you >> look at the >>>> recommendation from the draft on handling this error case, MAG >>>> signaling considerations, >>>> >>>> "If the received Proxy Binding Acknowledgement >> message has the >>>> Status field value set to TIMESTAMP_MISMATCH (Invalid >>>> Timestamp), >>>> the mobile access gateway SHOULD try to register again only >>>> after >>>> it synchronized its clock with the local mobility anchor's >>>> system >>>> clock or to a common time source that is used by >> all mobility >>>> entities in that domain for their clock synchronization." >>>> >>> I think it is good if the LMA informs the MAG about detected out of >>> sync clocks for the purpose of diagnostics and as a trigger for >>> re-sync. But why do we need the timestamp option in the PBA? The >>> TIMESTAMP_MISMATCH value in the status field is enough for >> the purpose >>> of diagnostics and as a trigger for re-sync. >>> >>>> So, we are not really using the LMA as the time source. >>> Now, with the >>>> given assumptions, do you see an issue if we dont say NTP >> is a MUST, >>>> but we say clock synch is a requirement, how they do it, >> draft does >>>> not say. If this requirement is not met, its an incorrect >> usage of >>>> the protocol and the PBU ordering will fail in that special rare >>>> reordering scenario (IMO, its not a practical issue). >>> see above >>> >>> BR, >>> >>> Kilian >>> >>>> The second question to this discussion, is Alex's point of not >>>> mandating Timestamp option as a MUST implement. For this, >>> as I stated >>>> before, this is few lines of code for supporting this >> option and if >>>> seq number scheme is in use, this need not be used at >> all. We need >>>> to mandate this as there is no CT in the base spec. But, >> this is not >>>> a >>> big issue >>>> either way. If others agree, I'm fine not mandating this. >>>> But, I really >>>> believe, implementations can support this option, at the >> least cost. >>>> One last comment on the trust on LMA's clock for the sanity >>> check, is >>>> because its an anchor point and its typically well >> managed, compared >>>> to MAG's, where they are scattered out. So, its >> reasonable to expect >>>> the clock on the LMA to be in sync, else all >> registrations will fail >>>> and will generate the traps. >>>> >>>> So, let me know your comments on how we can move forward. >>>> >>>> >>>> Sri >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 1. If a MAG's clock is out of sync (i.e., not yet synced by >>>>> receiving a PBA with timestamp) AND PBUs sent by this MAG are >>>>> delayed, >>>> the out of >>>>> sync situation may not be detectable by the LMA and old >>> PBUs may be >>>>> accepted by the LMA. >>>>> >>>>> Consider the following example: MN attaches to MAG1 and shortly >>>>> thereafter hands over to MAG2. MAG2's clock is in sync >> with LMA's >>>>> clock, but MAG1's clock is out of sync and is ahead of >> LMA's clock >>>>> by 5 seconds. MAG1-LMA link is highly congested. When MN >>>> attaches to MAG1, >>>>> MAG1 sends PBU1 msg to LMA. This happens 3 seconds before >>>> the MN hands >>>>> over to MAG2. The PBU1 msg is delayed by 5 seconds due to the >>>>> congestion and hence arrives at LMA 2 seconds after handover. >>>>> Despite of the delay, >>>>> PBU1 has a valid timestamp from LMA's point of view due >>> to the wrong >>>>> clock of MAG1. MAG2 sends a PBU2 msg 1 second after >>>> handover. PBU2 is >>>>> not significantly delayed and arrives at LMA ~1 seconds >>>> after handover >>>>> with valid timestamp. In this scenario, the LMA will wrongly >>>>> accept PBU1 arriving after PBU2, since both have a valid >>>>> timestamp. >>>> Consequently, >>>>> the LMA forwards packets to the wrong MAG (MAG1) and will not >>>>> notice the out of sync of MAG1, which also means that the LMA >>> doesn't return a >>>>> timestamp in the PBA and MAG1's clock keeps to be out of sync. >>>>> >>>>> 2. When packets on the link between MAG and LMA >>> experience high (and >>>>> varying) packet delays (e.g., due to congestion), the >>>> timestamp in the >>>>> PBA returned by the LMA may already be outdated at the time >>>> it arrives >>>>> at the MAG. So exactly in the situation where a re-ordering >>>> of PBUs is >>>>> needed, the synchronization mechanism may fail. >>>>> >>>>> My two cents. >>>>> >>>>> BR, >>>>> >>>>> Kilian >>>>> >>>>>> -----Original Message----- >>>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>>>> Sent: Freitag, 7. September 2007 18:48 >>>>>> To: 'Kilian Weniger' >>>>>> Cc: netlmm@ietf.org >>>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>>> >>>>>> Hi Kilian, >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Kilian Weniger >> [mailto:Kilian.Weniger@eu.panasonic.com] >>>>>>> Sent: Friday, September 07, 2007 2:09 AM >>>>>>> To: Sri Gundavelli >>>>>>> Cc: netlmm@ietf.org >>>>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>>>> >>>>>>> Hi Sri, >>>>>>> >>>>>>>> - We are NOT mandating the nodes in the domain to >> sync up to >>>>>>>> a clock source. >>>>>>> Hmm, so far I assumed that the proposal is to mandate the >>>>>> MAGs to sync >>>>>>> up to an external clock source such as NTP server. >>>>>>> >>>>>> For the timestamp option to work, we RECOMMEND the use >>> of NTP for >>>>>> synchronizing the clocks in the domain. However, we do >>> not want to >>>>>> mandate on a specific mechanism. >>>>>> >>>>>> >>>>>>>> Base draft does not support Context Transfers. Given that >>>>>> the draft >>>>>>>> will be incomplete, if we dont mandate the support. >>>> By mandating >>>>>>>> the support, the LMA can always return its timestamp >>>> and the MAG >>>>>>>> can use that timestamp and register. This need to >>> be done just >>>>>>>> once whenever the LMA/MAG clocks are out of sync and >>>>> just for one >>>>>>>> registration. One extra round trip for the 1st >>>>>> registration between >>>>>>>> LMA/MAG pair. >>>>>>> So the proposal is to allow the use of the timestamp >>>> option in the >>>>>>> absence of any external time synchronization like NTP and >>>>>> to mandate a >>>>>>> mechanism to synchronize clocks between MAGs and LMA (and >>>>>>> hence between all MAGs) using the timestamp option >> in PBU/PBA >>>>>>> only >>>>> (i.e., without >>>>>>> utilizing NTP or an external clock source)? Is my >>>>>>> understanding correct? >>>>>>> >>>>>> No. For this to work, we require the clocks to be in sync. >>>>>> How its achieved, it could be based on NTP or some other >>>> protocols. >>>>>> But, why should we mandate this. >>>>>> >>>>>> >>>>>>> If so, can you please give some more details how >> the LMA can >>>>>>> detect that the clocks are out of sync? Is it based on a >>>>>>> certain >>>> difference of >>>>>>> timestamp in the received PBU and the current LMA's time? >>>>>>> >>>>>>> And how to differentiate the out of sync case from the >>>>> out-of-order >>>>>>> delivery case (i.e., a PBU is delayed and overtaken >> by another >>>>>>> PBU from another MAG)? For instance, if the LMA >> receives a PBU >>>>> with timestamp >>>>>>> equal to "current time of LMA - X" and X > threshold, how >>>>>> does the LMA >>>>>>> know whether the >>>>>>> 1. the MAG clock is synchronized, but the PBU got >>>> delayed by X or >>>>>>> 2. the PBU is not delayed, but the MAG's clock is out of >>>>> sync by X? >>>>>>> Ideally, in case 1 the LMA should just ignore the PBU, in >>>>> case 2 it >>>>>>> should accept it and sync clocks. >>>>>>> >>>>>>> If the idea is to always reject a PBU with X > threshold >>>>>> and include a >>>>>>> current timestamp in the PBA, then I guess the same could >>>>>> be done with >>>>>>> sequence numbers instead of timestamps, right? >>>>>>> >>>>>> For what ever reasons if the LMA and MAG clocks are out >>>> of sync, the >>>>>> LMA can return its timestamp and the MAG can always apply >>>> that delta >>>>>> in all the registration it sends. This is done just once, >>>> when ever >>>>>> the clocks are off. But, with seq number scheme, this needs >>>>> to be done >>>>>> for each MN registration. Its as per the 3775 per MN >> seq number. >>>>>> Sri >>>>>> >>>>>>> BR, >>>>>>> >>>>>>> Kilian >>>>>>> >>>>>>> >>>>>>> Panasonic R&D Center Germany GmbH >>>>>>> 63225 Langen, Hessen, Germany >>>>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing >> Director: Thomas >>>>>>> Micke >>>>>> >>>>> >>>>> Panasonic R&D Center Germany GmbH >>>>> 63225 Langen, Hessen, Germany >>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas >>>>> Micke >>>> >>> >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 >>> Managing Director: Thomas Micke >>> >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >>> > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 08:58:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoHS-0000wH-PD; Thu, 13 Sep 2007 08:58:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoHR-0000w0-Kh for netlmm@ietf.org; Thu, 13 Sep 2007 08:58:49 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVoHR-0004n5-8W for netlmm@ietf.org; Thu, 13 Sep 2007 08:58:49 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DCwfk08693; Thu, 13 Sep 2007 12:58:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 07:58:25 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B49F93@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E931C6.5060600@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2BIvMdH1qvgW2TqehZSrVsutnXAAABBag References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > >> Subject: Re: [netlmm] timestamp vs seqno redux > >> > >> Ahmad Muhanna wrote: > >>> Hi Alex, > >>> > >>> No it does not have an effect on the calculation. > >> So why do you mention it as an assumption? > >=20 > > [Ahmad] > > It is an over sight on my part. Sorry for the confusion. >=20 > Ahmad, I think any assumption on a constant delay of the=20 > network is wrong, be it symmetric or asymmetric. You do a=20 > measurement now and ten minutes later the delays are=20 > different because somebody else loads the network. >=20 > You do 10 measurements in a burst and you get different=20 > times, eventually with a Gaussian distribution. That's the=20 > first experience with ping. [Ahmad] Alex, There is no assumption about a constant delay? This is just used for a snap shot analysis to prove the concept is valid. That is all. If the network condition changes, the concept still valid and should adjust itself and work. NO? >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 09:00:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoIp-0001Qx-PO; Thu, 13 Sep 2007 09:00:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoIn-0001Qc-9b for netlmm@ietf.org; Thu, 13 Sep 2007 09:00:13 -0400 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVoIm-0004pz-EV for netlmm@ietf.org; Thu, 13 Sep 2007 09:00:13 -0400 Received: from rly32e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly32e.srv.mailcontrol.com (MailControl) with ESMTP id l8DCxpNx030937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Sep 2007 14:00:09 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly32e.srv.mailcontrol.com (MailControl) id l8DCxXdE030249 for netlmm@ietf.org; Thu, 13 Sep 2007 13:59:33 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly32e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8DCxMaE029681; Thu, 13 Sep 2007 13:59:33 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 7e9f_5ab2fee8_61f8_11dc_8c0c_0030482aac25; Thu, 13 Sep 2007 14:53:40 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091314591663-196152 ; Thu, 13 Sep 2007 14:59:16 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.100,BAYES_00: -1.665,TOTAL_SCORE: -1.565 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 13 Sep 2007 14:59:42 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] timestamp vs seqno redux In-Reply-To: <46E931C6.5060600@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2BJvgsBJkra0vSKqac8wYWVd2XAAAHRvg References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> To: "Alexandru Petrescu" , "Ahmad Muhanna" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> Date: Thu, 13 Sep 2007 14:59:14 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.69.1.142 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alexandru Petrescu wrote: > Ahmad, I think any assumption on a constant delay of the network is=20 > wrong, be it symmetric or asymmetric. You do a measurement=20 > now and ten=20 > minutes later the delays are different because somebody else=20 > loads the=20 > network. >=20 > You do 10 measurements in a burst and you get different times,=20 > eventually with a Gaussian distribution. That's the first experience=20 > with ping. >=20 Right, that's why NTP requires several packet exchanges with sophisticated statistical calculations. From http://www.ntp.org/ntpfaq/NTP-s-algo.htm: "Time is not believed until several packet exchanges have taken place, each passing a set of sanity checks. Only if the replies from a server satisfy the conditions defined in the protocol specification, the server is considered valid. Time cannot be synchronized from a server that is considered invalid by the protocol. Some essential values are put into multi-stage filters for statistical purposes to improve and estimate the quality of the samples from each server." BR, Kilian Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 09:00:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoJD-0001cu-AF; Thu, 13 Sep 2007 09:00:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoJC-0001cm-E6 for netlmm@ietf.org; Thu, 13 Sep 2007 09:00:38 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVoJB-0004r5-Sg for netlmm@ietf.org; Thu, 13 Sep 2007 09:00:38 -0400 Received: from rly15b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly15b.srv.mailcontrol.com (MailControl) with ESMTP id l8DD074b002183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Sep 2007 14:00:34 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly15b.srv.mailcontrol.com (MailControl) id l8DCxZXp032064 for netlmm@ietf.org; Thu, 13 Sep 2007 13:59:35 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly15b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8DCxTdD031535; Thu, 13 Sep 2007 13:59:35 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 7f11_5dae3568_61f8_11dc_9527_0030482aac25; Thu, 13 Sep 2007 14:53:46 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007091314591995-196158 ; Thu, 13 Sep 2007 14:59:19 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.100,BAYES_00: -1.665,TOTAL_SCORE: -1.565 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 13 Sep 2007 14:59:42 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] timestamp vs seqno redux In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B49F49@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf1/V6IkZUjNpbDSkOXrbUksZQhWgAAy30AAADzs7A= References: <46DFC1C7.9060103@gmail.com> <01dc01c7f0c0$3e238210$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48A83E@lan-ex-02.panasonic.de> <010301c7f16e$d25ec030$d4f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AA7B@lan-ex-02.panasonic.de> <000001c7f504$24c8eb50$d5f6200a@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF95B2@zrc2hxm2.corp.nortel.com> <46E925C6.9070903@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F49@zrc2hxm2.corp.nortel.com> To: "Ahmad Muhanna" , "Alexandru Petrescu" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48AC7F@lan-ex-02.panasonic.de> Date: Thu, 13 Sep 2007 14:59:02 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.66.1.125 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad,=20 =20 > There has to be a defined default working mechanism in the draft which > does not depend on any undefined mechanism. I discussed this with Sri and according to his understanding this is not true. From his recent email: > The protocol has a requirement > and I think, how deployments achieve that is not our issue. For ex, we > need Routing between LMA and MAG. That's the assumption, we dont say=20 > there MUST be OSPF enabled between them. I really think, we=20 > should just > state the requirement strongly and make a note that the mechanism will > not work, if the requirement is not met. It is sufficient, IMHO. Furthermore, this is no argument for specifying a PMIP-based time sync mechanism. One could mandate, e.g., NTP instead. BR, Kilian Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 09:04:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoMq-00045z-7j; Thu, 13 Sep 2007 09:04:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoMp-00045c-0f for netlmm@ietf.org; Thu, 13 Sep 2007 09:04:23 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVoMn-0004A1-Oi for netlmm@ietf.org; Thu, 13 Sep 2007 09:04:22 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1189688673!2407845!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31089 invoked from network); 13 Sep 2007 13:04:33 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 13 Sep 2007 13:04:33 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8DD4IDH013819; Thu, 13 Sep 2007 06:04:18 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l8DD4HOV025605; Thu, 13 Sep 2007 08:04:17 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8DD4Fx1025545; Thu, 13 Sep 2007 08:04:16 -0500 (CDT) Message-ID: <46E9354A.3030303@gmail.com> Date: Thu, 13 Sep 2007 15:04:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F93@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B49F93@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: >> Subject: Re: [netlmm] timestamp vs seqno redux >> >> Ahmad Muhanna wrote: >>>> Subject: Re: [netlmm] timestamp vs seqno redux >>>> >>>> Ahmad Muhanna wrote: >>>>> Hi Alex, >>>>> >>>>> No it does not have an effect on the calculation. >>>> So why do you mention it as an assumption? >>> [Ahmad] >>> It is an over sight on my part. Sorry for the confusion. >> Ahmad, I think any assumption on a constant delay of the >> network is wrong, be it symmetric or asymmetric. You do a >> measurement now and ten minutes later the delays are >> different because somebody else loads the network. >> >> You do 10 measurements in a burst and you get different >> times, eventually with a Gaussian distribution. That's the >> first experience with ping. > > [Ahmad] > Alex, There is no assumption about a constant delay? > This is just used for a snap shot analysis to prove the concept is > valid. That is all. What makes you think that the situation is the same when you make your snapshot and 10minutes later? > If the network condition changes, the concept still valid and should > adjust itself and work. NO? Don't you assume that when network conditions change a new measurement is necessary? How do you know when network conditions change? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 09:14:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoWO-0002pS-3h; Thu, 13 Sep 2007 09:14:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoWM-0002kl-L9 for netlmm@ietf.org; Thu, 13 Sep 2007 09:14:14 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVoWJ-0005CB-Fb for netlmm@ietf.org; Thu, 13 Sep 2007 09:14:14 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DDDr511423; Thu, 13 Sep 2007 13:13:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 08:13:38 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B49FE1@zrc2hxm2.corp.nortel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48AC13@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: AcfwZIAbrVWG4MICT1+fq2+7+PUdPAAWG/pwABshGsAAEPuewADBYkGwACLqs5AAAy3X8AAMXqxQAAWRX+AAAB568AAE2X+QABvRPKAAC4NMMA== References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de><6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <1FEB9B9F2EC38343955D02B2AE86AACB48ABB7@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4978F@zrc2hxm2.corp.nortel.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC13@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" , "Sri Gundavelli" , "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1338f4ee677fe822e4246c6560199c52 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Please see comments inline. Regards, Ahmad > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Hi Ahmad, >=20 > the issue only occurs when d2=3D~-d1 (PBU delay =3D~ amount that=20 > MAG's clock is ahead of LMA's clock). Then the LMA doesn't=20 > send a PBA with timestamp_mismatch status code and MAG=20 > doesn't compute a delta. I agree that the probability that=20 > this situation will occur may be low, but the consequences=20 > can be serious: Wrong BCE and packet loss till the next PBU.=20 > Is this acceptable? I'm not sure.=20 [Ahmad] I do not understand what is the problem here. Are we talking about the race condition here or about synchronization. If you are talking about the race condition, then there are a couple of options to address it and the choice is yours. On the other hand, if we are talking about this synchronization issue, IMO, as long as ordering P-BU/P-BA works and that MAG continuously monitor the LMA timestamp through all P-BU and P-BA, then I do not see a great impact here. >=20 > Furthermore, I don't really understand why we can't rely on=20 > an outside mechanism like NTP. Is there any scenario where=20 > NTP fails, but the PBA-based time sync does not fail? [Ahmad] Kilian, I have no problem with that requirement. Life will be good for everyone:-) The point here is that some people on the list do not want to mandate the use of NTP server. I personally, respect that choice. It is valid and hence, we should not mandate it. Again, personally, I have no problem. >=20 > Please see my email to Sri for suggestions to move on. Please note that I'm only talking about *synchronization of MAG's clock using the timestamp in the PBA*. Using the timestamp in PBUs to re-order PBUs is not related to that and ok (under the assumption that the MAGs' clocks are synchronized using some PMIP-independent mechanism like NTP) [Ahmad] Kilian, Using the PMIPv6 signaling does not have the objective of synchronizing timestamp in an accuracy as NTP server. That is a whole protocol by itself. However, what we are talking about is the use of timestamp in ordering the P-BU/P-PA. And using PMIPv6 signaling as an alternative mechanism should work. >=20 > Some more comments inline.=20 >=20 > BR, >=20 > Kilian >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Mittwoch, 12. September 2007 22:20 > > To: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] timestamp vs seqno redux > >=20 > > Hi Kilian, > >=20 > > Please see comments inline. > >=20 > > Regards, > > Ahmad > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > Sent: Mittwoch, 12. September 2007 17:41 > > > > To: Ahmad Muhanna; Kilian Weniger; Sri Gundavelli; DE=20 > JUAN HUARTE=20 > > > > FEDERICO > > > > Cc: netlmm@ietf.org > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > >=20 > > > > Resending hopefully with the correct format. > > >=20 > > > thanks for re-sending. Much better to read now ;) > > >=20 > > > >=20 > > > > +++++ > > > >=20 > > > > Hi Kilian/Federico and All, > > > >=20 > > > > There has been a lot of email exchange that the timestamp=20 > > > > synchronization using the PMIPv6 signaling does not work. > > > On the other > > > > hand, I have not seen any in detail analysis which proves > > > that it does > > > > not work. I would like to share in details my thoughts on > > how this > > > > SHOULD work and please comment as necessary. > > >=20 > > > In one of my previous emails I described an example=20 > scenarios where=20 > > > it fails, at least according to my understanding of the=20 > sync method. > > > According to my understanding, the LMA only sees a delta time=20 > > > consisting of two parts: 1.) transmission delay of PBU=20 > (d2 in your=20 > > > example) and 2.) clock difference (d1 in your example). > > > The problem is that the LMA doesn't know d1 and d2=20 > itself, it only=20 > > > knows d1+d2. If d2=3D~-d1, i.e., MAG's clock is ahead of=20 > LMA's clock=20 > > > by a value that is roughly equal to the transmission delay, then=20 > > > d1+d2=3D~0, i.e., the LMA doesn't see any delta and assumes=20 > that the=20 > > > MAG's clock is in sync (which is not true). > > > Hence, no re-sync happens and the LMA may accept outdated=20 > PBUs (see=20 > > > my previous email). > >=20 > > [Ahmad] > > Kilian, > >=20 > > This is the same race condition that we have discussed too=20 > many times >=20 > When did we discuss the scenario where d2=3D~-d1 before? Can=20 > you please give me a pointer? >=20 > > and people do not like to accept the unpopular solution :-)=20 > I have no=20 > > problem with that. But let us exactly identify all=20 > conditions related=20 > > to the scenario: > >=20 > > 1. A race condition scenario which happens during handoff. > >=20 > > 2. It assumes that the MAGs are not properly synchronized with each=20 > > other using an outside mechanism. We are here talking here=20 > about the=20 > > MAGs not the (LMA and MAGs). In other words, if the MAGs in=20 > the same=20 > > local domain are synchronized this issue will never happen. >=20 > If you assume that the clocks of all MAGs are always properly=20 > synchronized using an outside mechanism, why do you want to=20 > specify a mechanism to synchronize the MAG's clock using=20 > timestamps in PBAs? >=20 >=20 > >=20 > > 3. It assumes that the pMAG sent a P-BU as a=20 > re-registration in a race=20 > > condition as the MN moves from pMAG (previous MAG) to nMAG=20 > (next MAG). > >=20 > > 4. Due to some network conditions, the P-BU of the pMAG=20 > arrives at the=20 > > LMA after the P-BU of the nMAG. > >=20 > > 5. It also assumes that not only pMAG and nMAG is out of sync, but=20 > > also nMAG is slower than pMAG by almost double the delta=20 > between any=20 > > of them and the LMA. > >=20 > > 6. Not only that but also, the nMAG is slower enough to the degree=20 > > that when the P-BU arrives at the LMA it is within the threshold. > >=20 > >=20 > > Finally, > > -------- > > I am not saying that the possibility of this scenario to happen is=20 > > ZERO. > > No. There is a possibility that it MAY happen but , at the=20 > same time,=20 > > it is very very slim. Not only that, I think according to the >=20 > Maybe the probability that it happens is quite low, but the=20 > consequences can be serious: Wrong BCE and packet loss till=20 > the next PBU. >=20 > > PMIPv6 draft, > > MAG needs to make sure that the MN is currently attached before=20 > > sending a re-registration P-BU. If the MAG is not sure,=20 > then MAG does=20 > > not send the P-BU. >=20 > Why is this related to the scenario in discussion? The MAG=20 > does not send a PBU if the MN is not attached. >=20 > >=20 > > NOW: what can we do about it: > > ----------------------------- > >=20 > > 1. The very famous but un-popular solution that we=20 > mentioned several=20 > > time. In case of handoff, i.e. when the LMA receives the P-BU from=20 > > nMAG, LMA considers this as a case of handoff. When LMA receives a=20 > > P-BU from the pMAG, LMA drops or rejects it with a code=20 > MN-in-handoff,=20 > > for example. Since it is a race condition, that will take=20 > care of it. > >=20 > > 2. LMA needs to track the delta for each MAG. Then after the P-BU=20 > > passes the LMA timestamp check and in case of handoff, LMA=20 > can always=20 > > make sure that the adjusted timestamp of the received P-BU=20 > is always=20 > > larger than the adjusted timestamp of the last received=20 > P-BU which is=20 > > already saved as part of the MN BCE. >=20 > As you said this was already discussed and there was no=20 > consensus for it AFAIK. >=20 > I don't understand why we cannot just rely on the outside=20 > time sync mechnanism like NTP? What is the problem with using=20 > a protocol like NTP, which was specifically designed to sync=20 > time? Why do we need a second time sync mechanism based on PBAs? >=20 > >=20 > > I hope that this will take care of this issue and we can=20 > finally move=20 > > on. > >=20 > > Best Regards, > > Ahmad > >=20 > > BTW: please see more comments below. > >=20 > > >=20 > > > Please see some more comments inline. > > >=20 > > > >=20 > > > > The following are a list of assumptions: > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > 1. The time that the P-BU takes from MAG to LMA equals > > the time the > > > > P-BA takes from LMA to MAG. > > >=20 > > > What is behind this assumption? Why not introduce another=20 > variable=20 > > > d3 for PBA delay (in addition to d2 for PBU delay). > >=20 > > [Ahmad] > > Actually d3 is irrelevant in this regard. Because the=20 > timestamp delta=20 > > that the MAG is tracking does not depend on d3, because,=20 > MAG considers=20 > > the timestamp delta as the difference between the LMA-timestamp in=20 > > P-BA (which is independent of d3) and the MAG-timestamp in the=20 > > corresponding P-BU (which is again independent of d3). > >=20 > > This means that regardless of the delay in the downlink direction,=20 > > only the delay in the uplink direction has an impact and=20 > that impact=20 > > is already factored IN and does not influence=20 > synchronization scheme. > >=20 > > >=20 > > >=20 > > > > 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > > > > comparing timestamp in P-BU and LMA current timestamp. > > > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > > > timestamp for calculating the delta! > > > > 4. MAG and LMA maintains the same out of sync delta during the=20 > > > > re-synchronization process. > > > >=20 > > > >=20 > > > > MAG =20 > > LMA > > > > ---------- =20 > > > ---------- > > > > 1. Current Timestamp MAG.t1 LMA.t1 =3D=20 > > > MAG.t1 +d1 > > > > 2. Timestamp in P-BU MAG.t1 LMA=20 > > timestamp: LMA.t1 > > > > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) > > > >=20 > > > > 4. P-BU arrives at LMA .............. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> > > > > P-BU(MAG.t1) > > > >=20 > > > > 5. Arrival Timestamp MAG.t1 + d2 =20 > LMA.t1 + d2 > > > > 6. delta based on P-BU timestamp (LMA.t1 +=20 > > > d2)-(MAG.t1) > > > > =3D > > > > =20 > > > > ((MAG.t1+d1)+d2) - MAG.t1 > > > > =3D > > > > =20 > > delta.P-BU =3D d2+d1 > > >=20 > > > right, d2+d1 is the delta that the LMA measures. > >=20 > > [Ahmad] > > Correct. Measured from the MAG timestamp. Right? > >=20 > > >=20 > > > >=20 > > > > 7. Real delta =20 > delta.real =3D d1 > > >=20 > > > How is the real delta d1 known by the LMA? > >=20 > > [Ahmad] > > LMA does not need to know it. As long as the scheme works to=20 > > resynchronize the MAG with the LMA, no need for LMA to know=20 > it. Right? >=20 > ok >=20 > > =20 > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > 8. Timestamp in P-BA MAG.t2 LMA.t2 =3D=20 > > > (LMA.t1 + d2) > > > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > How does the LMA know d2? IMO, LMA only knows delta.P-BU =3D = d2+d1.=20 > >=20 > > [Ahmad] > > Absolutely. LMA does not know what d2 and does not need to.=20 > > This is used > > for proving the scheme.=20 >=20 > ok >=20 > >=20 > > > Hence, P-BA can only contain LMA.t2 =3D (LMA.t1 + delta.P-BU) =3D > > > (LMA.t1 + > > > d1 + d2) > >=20 > > [Ahmad] > > I am afraid that is not correct. You probably meant to say: LMA.t2 = =3D > > (MAG.t1 + (d1+d2)). Right? > > Otherwise, LMA.t2 in terms of LMA.t1 is as follows: LMA.t2=20 > =3D LMA.t1 +=20 > > d2. NO? >=20 > right, P-BA contains current timestamp of LMA, which is=20 > LMA.t2 =3D LMA.t1 > + d2. >=20 > >=20 > > >=20 > > > > 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 > > > > 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in=20 > corresponding > > > > P-BU) > > > > =3D > > > > (LMA.t1 + d2) - MAG.t1 > > > > =3D > > > > ((MAG.t1 +d1)+d2) -MAG.t1 > > > >=20 > > > > delta =3D d1+d2 > > >=20 > > > delta should be d1+2*d2 > >=20 > > [Ahmad] > > No. That is not correct. Delta =3D d1+d2. Please see above comment. >=20 > right, delta is d1+d2. >=20 > >=20 > > >=20 > > > >=20 > > > > 11. Real delta delta.real =3D d1 > > >=20 > > > How does the LMA know the real delta? > >=20 > > [Ahmad] > > It does not need to know. ONLY MAG needs to track a delta with the=20 > > LMA. > > Well, we can make both track each other deltas but that will be too=20 > > much for the LMA and , honestly, it is not needed. > > =20 > > >=20 > > > BR, > > >=20 > > > Kilian > > >=20 > > >=20 > > > >=20 > > > >=20 > > > > What is the problem here? Or am I missing something? > > > > Let us examine a re-registration or a P-BU/PA exchange > > based on the > > > > above synchronization: > > > >=20 > > > >=20 > > > > MN- Resynchronization/Re-registration: > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > 12. Current timestamp MAG.t3 LMA.t3 =3D=20 > > > MAG.t3 + d1 > > > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 > > > > 14. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t3=20 > > + (d2+d1)) > > > >=20 > > > > 15. P-BU arrives at LMA = .......=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> > > > P-BU(MAG.t3+(d1+d2)) > > > > 16. Arrival Timestamp MAG.t3 + d2 =20 > LMA.t3 + d2 > > > > 17. delta based on P-BU =20 > > > > (LMA.t3+d2)-(MAG.t3+(d2+d1)) > > > > =3D > > > > =20 > > > > ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1)) > > > > =3D > > > >=20 > > > > =20 > delta.P-BU =3D ZERO > > > > 18. Real delta =20 > delta.real =3D ZERO >=20 > right.=20 >=20 > The issue only occurs when d2=3D~-d1, because then the LMA=20 > doesn't send a PBA with timestamp_mismatch status code and=20 > MAG doesn't compute a delta. > This scenario is not shown in your diagrams... >=20 > BR, >=20 > Kilian >=20 > > > >=20 > > > > Please let me know what I am missing. > > > > If nothing, I hope we can put an end to this debate and MOVE ON. > > > >=20 > > > > Regards, > > > > Ahmad > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Muhanna, Ahmad (RICH1:2H10) > > > > > Sent: Wednesday, September 12, 2007 9:59 AM > > > > > To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE > > FEDERICO' > > > > > Cc: 'netlmm@ietf.org' > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > >=20 > > > > > Hi Kilian/Federico and All, > > > > >=20 > > > > >=20 > > > > > There has been a lot of email exchange that the timestamp=20 > > > > > synchronization using the PMIPv6 signaling does not > > work. On the > > > > > other hand, I have not seen any in detail analysis which > > > proves that > > > > > it does not work. I would like to share in details my > > thoughts on > > > > > how this SHOULD work and please comment as necessary. > > > > >=20 > > > > > The following are a list of assumptions: > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >=20 > > > > > 1. The time that the P-BU takes from MAG to LMA equals > > > the time the > > > > > P-BA takes from LMA to MAG. > > > > > 2. LMA Timestamp included in the P-BA is the LMA=20 > timestamp when=20 > > > > > comparing timestamp in P-BU and LMA current timestamp. > > > > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > > > > timestamp for calculating the delta! > > > > > 4. MAG and LMA maintains the same out of sync delta=20 > during the=20 > > > > > re-synchronization process. > > > > >=20 > > > > >=20 > > > > >=20 > > > > > MAG =20 > > > > > LMA > > > > > ---------- =20 > > > > > ---------- > > > > > 1. Current Timestamp MAG.t1 =20 > > > > > LMA.t1 =3D MAG.t1 +d1 > > > > > 2. Timestamp in P-BU MAG.t1 LMA=20 > > > > > timestamp: LMA.t1 > > > > > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) > > > > > 4. P-BU arrives at LMA .......................=20 > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t1) > > > > > 5. Arrival Timestamp MAG.t1 + d2 =20 > > > > > LMA.t1 + d2 > > > > >=20 > > > > > 6. delta based on P-BU timestamp =20 > > > > > (LMA.t1 + d2) - (MAG.t1) > > > > > =20 > > > > > =3D > > > > > =20 > > > > > ((MAG.t1+d1)+d2) - MAG.t1=09 > > > > > =20 > > > > > =3D > > > > > =20 > > > > > delta.P-BU =3D d2+d1 > > > > >=20 > > > > > 7. Real delta =20 > > > > > delta.real =3D d1 > > > > >=20 > > > > > =20 > > =20 > > > > > 8. Timestamp in P-BA MAG.t2 =20 > > > > > LMA.t2 =3D (LMA.t1 + d2) > > > > > =20 > > > > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > > 9. P-BA arrives @ MAG MAG.t2 + d2 =20 > > > > > LMA.t2 + d2 > > > > > 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in > > > corresponding > > > > > P-BU) > > > > > =3D > > > > > (LMA.t1 + d2) - MAG.t1 > > > > > =3D > > > > > ((MAG.t1 +d1)+d2) -MAG.t1 > > > > > =20 > > > > > delta =3D d1+d2 > > > > >=20 > > > > > 11. Real delta delta.real =3D d1 > > > > >=20 > > > > >=20 > > > > > What is the problem here? Or am I missing something? > > > > >=20 > > > > >=20 > > > > > Let us examine a re-registration or a P-BU/PA exchange > > > based on the > > > > > above synchronization: > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > > >=20 > > > > > MN- Resynchronization/Re-registration: > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >=20 > > > > > 12. Current timestamp MAG.t3 =20 > > > > > LMA.t3 =3D MAG.t3 + d1 > > > > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) =20 > > > > LMA.t3 > > > > > 14. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t3=20 > > > + (d2+d1)) > > > > > 15. P-BU arrives at LMA > > > > > = .......................=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> = P-BU(MAG.t3 > > + (d1+d2)) > > > > > 16. Arrival Timestamp MAG.t3 + d2 =20 > > > > > LMA.t3 + d2 > > > > >=20 > > > > > 17. delta based on P-BU =20 > > > > > (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) > > > > > =20 > > > > > =3D > > > > > =20 > > > > > ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) > > > > > =20 > > > > > =3D > > > > > =20 > > > > > delta.P-BU =3D ZERO > > > > >=20 > > > > > 18. Real delta =20 > > > > > delta.real =3D ZERO =20 > > > > >=20 > > > > > Please let me know what I am missing. > > > > >=20 > > > > > If nothing, I hope we can put an end to this debate=20 > and MOVE ON. > > > > > =09 > > > > >=20 > > > > > Regards, > > > > > Ahmad > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Kilian Weniger=20 > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > Sent: Wednesday, September 12, 2007 3:07 AM > > > > > > To: Sri Gundavelli > > > > > > Cc: netlmm@ietf.org > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > >=20 > > > > > > Hi Sri, > > > > > >=20 > > > > > > please see my comments inline. > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > > > Sent: Mittwoch, 12. September 2007 08:14 > > > > > > > To: 'Kilian Weniger' > > > > > > > Cc: netlmm@ietf.org > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > >=20 > > > > > > > Hi Kilian/Federico, > > > > > > >=20 > > > > > > > =20 > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Kilian Weniger > > > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > > > Sent: Tuesday, September 11, 2007 6:33 AM > > > > > > > > To: Sri Gundavelli > > > > > > > > Cc: netlmm@ietf.org > > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > > >=20 > > > > > > > > Hi Sri, > > > > > > > >=20 > > > > > > > > my point is that NOT mandating synchronization to an > > > > > > external clock > > > > > > > > source for the timestamp option implies that sending PBU > > > > > > msgs with > > > > > > > > timestamp option is allowed even when MAGs are not (yet) > > > > > > > synchronized. > > > > > > > > I.e., it would be allowed that a deployment=20 > uses only the > > > > > > returned > > > > > > > > timestamps in PBA msgs to synchronize the MAG clocks. I > > > > > think the > > > > > > > > draft should not allow this for the following reasons: > > > > > > > >=20 > > > > > > >=20 > > > > > > > The stated assumption for the timestamp based approach to > > > > > work, is > > > > > > > the requirement for the MAG's to have synchronized clocks. > > > > > > > That is a requirement. Now, if a given MAG sends a > > > PBU with an > > > > > > > incorrect timestamp, its an error and as you and > > > > Federico pointed > > > > > > > out, there are cases where the LMA will not be able to > > > > > determine the > > > > > > > sending order of the received packets. This is an error > > > > > condition, > > > > > > > as the requirement is not met. > > > > > >=20 > > > > > > Right, sending a PBU with timestamp option requires that > > > > the MAG's > > > > > > clock is synchronized. Hence, I don't see why the draft > > > > > should specify > > > > > > a mechanism to synchronize a MAG's clock using a received > > > > > PBA. Also, I > > > > > > think this mechanism has issues in some scenario (see > > > my previous > > > > > > mail). > > > > > >=20 > > > > > >=20 > > > > > > The clock synchronization is the job of some=20 > PMIP-independent=20 > > > > > > synchronization method like NTP and out of sync clocks can > > > > > only occur > > > > > > if there is a problem with this PMIP-independent > > > synchronization > > > > > > method. > > > > > > Hence, it is a non-recoverable error case from PMIP > > > point of view > > > > > > IMHO. > > > > > >=20 > > > > > > >=20 > > > > > > > Now, should the draft state that the time > > > synchronization is a > > > > > > > requirement and additionally mandate a method of time > > > > > > synchronization, > > > > > > > say by NTP ? But, the later has a system wide impact and > > > > > > additionally, > > > > > > > a given architecture where this protocol is applied, can > > > > > achieve the > > > > > > > time synchronization through other non NTP means. IMO, we > > > > > may not be > > > > > > > able dictate that. Also, we want implementations to > > > support the > > > > > > > timestamp based scheme by default. Now, mandating the NTP > > > > > usage will > > > > > > > create some restrictions for some deployments. So, > > > that is the > > > > > > > reasoning behind not mandating the method of time > > > > synchronization. > > > > > >=20 > > > > > > I'm not sure if the draft can say "a MAG's clock MUST be > > > > > synchronized > > > > > > for this protocol to work, but how this is done is out of > > > > > scope of the > > > > > > draft". I guess the draft has to mandate the > > > > implementation of one > > > > > > "default" synchronization protocol such as NTP to achieve=20 > > > > > > interoperability. However, as long as the use of NTP is not > > > > > mandated > > > > > > (e.g., just say "SHOULD use"), deployments can still > > use other > > > > > > methods. > > > > > > So I don't see restrictions for deployments in this case.=20 > > > > > >=20 > > > > > > >=20 > > > > > > > W.r.t this below scenario, the reason for LMA to=20 > return its > > > > > > timestamp, > > > > > > > solves two purposes. 1.) Diagnostics (especially useful > > > > > when the LMA > > > > > > > and MAG are in different admin domains) 2.) The MAG can > > > > > detect that > > > > > > > its clock is not in sync and take the necessary > > > > actions. I guess, > > > > > > > Frederico has an issue with the second part. But, if you > > > > > look at the > > > > > > > recommendation from the draft on handling this error > > > case, MAG > > > > > > > signaling considerations, > > > > > > >=20 > > > > > > > "If the received Proxy Binding Acknowledgement > > > > > message has the > > > > > > > Status field value set to=20 > TIMESTAMP_MISMATCH (Invalid=20 > > > > > > > Timestamp), > > > > > > > the mobile access gateway SHOULD try to register > > > > again only > > > > > > > after > > > > > > > it synchronized its clock with the local mobility > > > > anchor's > > > > > > > system > > > > > > > clock or to a common time source that is used by > > > > > all mobility > > > > > > > entities in that domain for their clock > > > synchronization." > > > > > > >=20 > > > > > >=20 > > > > > > I think it is good if the LMA informs the MAG about > > > > detected out of > > > > > > sync clocks for the purpose of diagnostics and as a > > trigger for > > > > > > re-sync. But why do we need the timestamp option in the > > > PBA? The > > > > > > TIMESTAMP_MISMATCH value in the status field is enough for > > > > > the purpose > > > > > > of diagnostics and as a trigger for re-sync. > > > > > >=20 > > > > > > > So, we are not really using the LMA as the time source.=20 > > > > > > Now, with the > > > > > > > given assumptions, do you see an issue if we dont say NTP > > > > > is a MUST, > > > > > > > but we say clock synch is a requirement, how they do it, > > > > > draft does > > > > > > > not say. If this requirement is not met, its an incorrect > > > > > usage of > > > > > > > the protocol and the PBU ordering will fail in that > > > > special rare > > > > > > > reordering scenario (IMO, its not a practical issue). > > > > > >=20 > > > > > > see above > > > > > >=20 > > > > > > BR, > > > > > >=20 > > > > > > Kilian > > > > > >=20 > > > > > > >=20 > > > > > > > The second question to this discussion, is Alex's > > > point of not > > > > > > > mandating Timestamp option as a MUST implement. For this, > > > > > > as I stated > > > > > > > before, this is few lines of code for supporting this > > > > > option and if > > > > > > > seq number scheme is in use, this need not be used at > > > > > all. We need > > > > > > > to mandate this as there is no CT in the base spec. But, > > > > > this is not > > > > > > > a > > > > > > big issue > > > > > > > either way. If others agree, I'm fine not mandating this.=20 > > > > > > > But, I really > > > > > > > believe, implementations can support this option, at the > > > > > least cost. > > > > > > >=20 > > > > > > > One last comment on the trust on LMA's clock for=20 > the sanity > > > > > > check, is > > > > > > > because its an anchor point and its typically well > > > > > managed, compared > > > > > > > to MAG's, where they are scattered out. So, its > > > > > reasonable to expect > > > > > > > the clock on the LMA to be in sync, else all > > > > > registrations will fail > > > > > > > and will generate the traps. > > > > > > >=20 > > > > > > > So, let me know your comments on how we can move forward. > > > > > > >=20 > > > > > > >=20 > > > > > > > Sri > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > 1. If a MAG's clock is out of sync (i.e., not yet > > synced by > > > > > > > > receiving a PBA with timestamp) AND PBUs sent by > > > this MAG are > > > > > > > > delayed, > > > > > > > the out of > > > > > > > > sync situation may not be detectable by the LMA and old > > > > > > PBUs may be > > > > > > > > accepted by the LMA.=20 > > > > > > > >=20 > > > > > > > > Consider the following example: MN attaches to MAG1 > > > > and shortly > > > > > > > > thereafter hands over to MAG2. MAG2's clock is in sync > > > > > with LMA's > > > > > > > > clock, but MAG1's clock is out of sync and is ahead of > > > > > LMA's clock > > > > > > > > by 5 seconds. MAG1-LMA link is highly congested. When MN > > > > > > > attaches to MAG1, > > > > > > > > MAG1 sends PBU1 msg to LMA. This happens 3=20 > seconds before > > > > > > > the MN hands > > > > > > > > over to MAG2. The PBU1 msg is delayed by 5 seconds > > > due to the > > > > > > > > congestion and hence arrives at LMA 2 seconds after > > > handover. > > > > > > > > Despite of the delay, > > > > > > > > PBU1 has a valid timestamp from LMA's point of view due > > > > > > to the wrong > > > > > > > > clock of MAG1. MAG2 sends a PBU2 msg 1 second after > > > > > > > handover. PBU2 is > > > > > > > > not significantly delayed and arrives at LMA ~1 seconds > > > > > > > after handover > > > > > > > > with valid timestamp. In this scenario, the LMA > > > will wrongly > > > > > > > > accept PBU1 arriving after PBU2, since both=20 > have a valid=20 > > > > > > > > timestamp. > > > > > > > Consequently, > > > > > > > > the LMA forwards packets to the wrong MAG (MAG1) > > > and will not > > > > > > > > notice the out of sync of MAG1, which also means > > > that the LMA > > > > > > doesn't return a > > > > > > > > timestamp in the PBA and MAG1's clock keeps to be > > > out of sync. > > > > > > > >=20 > > > > > > > > 2. When packets on the link between MAG and LMA > > > > > > experience high (and > > > > > > > > varying) packet delays (e.g., due to congestion), the > > > > > > > timestamp in the > > > > > > > > PBA returned by the LMA may already be outdated > > at the time > > > > > > > it arrives > > > > > > > > at the MAG. So exactly in the situation where a > > re-ordering > > > > > > > of PBUs is > > > > > > > > needed, the synchronization mechanism may fail. > > > > > > > >=20 > > > > > > > > My two cents. > > > > > > > >=20 > > > > > > > > BR, > > > > > > > >=20 > > > > > > > > Kilian > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > > > > > Sent: Freitag, 7. September 2007 18:48 > > > > > > > > > To: 'Kilian Weniger' > > > > > > > > > Cc: netlmm@ietf.org > > > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > > > >=20 > > > > > > > > > Hi Kilian, > > > > > > > > >=20 > > > > > > > > > =20 > > > > > > > > >=20 > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Kilian Weniger > > > > > [mailto:Kilian.Weniger@eu.panasonic.com] > > > > > > > > > > Sent: Friday, September 07, 2007 2:09 AM > > > > > > > > > > To: Sri Gundavelli > > > > > > > > > > Cc: netlmm@ietf.org > > > > > > > > > > Subject: RE: [netlmm] timestamp vs seqno redux > > > > > > > > > >=20 > > > > > > > > > > Hi Sri, > > > > > > > > > >=20 > > > > > > > > > > > - We are NOT mandating the nodes in the domain to > > > > > sync up to > > > > > > > > > > > a clock source. > > > > > > > > > >=20 > > > > > > > > > > Hmm, so far I assumed that the proposal is to > > > mandate the > > > > > > > > > MAGs to sync > > > > > > > > > > up to an external clock source such as NTP server. > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > For the timestamp option to work, we RECOMMEND the use > > > > > > of NTP for > > > > > > > > > synchronizing the clocks in the domain. However, we do > > > > > > not want to > > > > > > > > > mandate on a specific mechanism.=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > > > Base draft does not support Context Transfers.=20 > > > > Given that > > > > > > > > > the draft > > > > > > > > > > > will be incomplete, if we dont mandate=20 > the support.=20 > > > > > > > By mandating > > > > > > > > > > > the support, the LMA can always return=20 > its timestamp > > > > > > > and the MAG > > > > > > > > > > > can use that timestamp and register. This need to > > > > > > be done just > > > > > > > > > > > once whenever the LMA/MAG clocks are out=20 > of sync and > > > > > > > > just for one > > > > > > > > > > > registration. One extra round trip for the 1st > > > > > > > > > registration between > > > > > > > > > > > LMA/MAG pair. > > > > > > > > > >=20 > > > > > > > > > > So the proposal is to allow the use of the timestamp > > > > > > > option in the > > > > > > > > > > absence of any external time synchronization > > > like NTP and > > > > > > > > > to mandate a > > > > > > > > > > mechanism to synchronize clocks between MAGs > > > and LMA (and > > > > > > > > > > hence between all MAGs) using the timestamp option > > > > > in PBU/PBA > > > > > > > > > > only > > > > > > > > (i.e., without > > > > > > > > > > utilizing NTP or an external clock source)? Is my=20 > > > > > > > > > > understanding correct? > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > No. For this to work, we require the clocks to > > be in sync. > > > > > > > > > How its achieved, it could be based on NTP or=20 > some other > > > > > > > protocols. > > > > > > > > > But, why should we mandate this. > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > > If so, can you please give some more details how > > > > > the LMA can > > > > > > > > > > detect that the clocks are out of sync? Is it > > > based on a > > > > > > > > > > certain > > > > > > > difference of > > > > > > > > > > timestamp in the received PBU and the current > > > LMA's time?=20 > > > > > > > > > >=20 > > > > > > > > > > And how to differentiate the out of sync=20 > case from the > > > > > > > > out-of-order > > > > > > > > > > delivery case (i.e., a PBU is delayed and overtaken > > > > > by another > > > > > > > > > > PBU from another MAG)? For instance, if the LMA > > > > > receives a PBU > > > > > > > > with timestamp > > > > > > > > > > equal to "current time of LMA - X" and X > > > > threshold, how > > > > > > > > > does the LMA > > > > > > > > > > know whether the > > > > > > > > > > 1. the MAG clock is synchronized, but the PBU got > > > > > > > delayed by X or > > > > > > > > > > 2. the PBU is not delayed, but the MAG's > > clock is out of > > > > > > > > sync by X? > > > > > > > > > > Ideally, in case 1 the LMA should just ignore > > > the PBU, in > > > > > > > > case 2 it > > > > > > > > > > should accept it and sync clocks. > > > > > > > > > >=20 > > > > > > > > > > If the idea is to always reject a PBU with X > > > threshold > > > > > > > > > and include a > > > > > > > > > > current timestamp in the PBA, then I guess the > > > same could > > > > > > > > > be done with > > > > > > > > > > sequence numbers instead of timestamps, right? > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > For what ever reasons if the LMA and MAG=20 > clocks are out > > > > > > > of sync, the > > > > > > > > > LMA can return its timestamp and the MAG can > > always apply > > > > > > > that delta > > > > > > > > > in all the registration it sends. This is done > > just once, > > > > > > > when ever > > > > > > > > > the clocks are off. But, with seq number scheme, > > > this needs > > > > > > > > to be done > > > > > > > > > for each MN registration. Its as per the 3775 per MN > > > > > seq number. > > > > > > > > >=20 > > > > > > > > > Sri > > > > > > > > >=20 > > > > > > > > > > BR, > > > > > > > > > >=20 > > > > > > > > > > Kilian > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > Panasonic R&D Center Germany GmbH > > > > > > > > > > 63225 Langen, Hessen, Germany > > > > > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing > > > > > Director: Thomas > > > > > > > > > > Micke > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Panasonic R&D Center Germany GmbH > > > > > > > > 63225 Langen, Hessen, Germany > > > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing > > > > Director: Thomas > > > > > > > > Micke > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Panasonic R&D Center Germany GmbH > > > > > > 63225 Langen, Hessen, Germany > > > > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing > > Director: Thomas > > > > > > Micke > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > netlmm mailing list > > > > > > netlmm@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > >=20 > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 > > > >=20 > > >=20 > > >=20 > > > Panasonic R&D Center Germany GmbH > > > 63225 Langen, Hessen, Germany > > > Reg: AG Offenbach (Hessen) HRB 33974 Managing Director:=20 > Thomas Micke > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 09:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVocW-0007Vi-IW; Thu, 13 Sep 2007 09:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVocV-0007VE-Gu for netlmm@ietf.org; Thu, 13 Sep 2007 09:20:35 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVocT-0004aw-S2 for netlmm@ietf.org; Thu, 13 Sep 2007 09:20:35 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1189689632!11885263!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23384 invoked from network); 13 Sep 2007 13:20:32 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 13 Sep 2007 13:20:32 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8DDKRqb019118; Thu, 13 Sep 2007 06:20:27 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8DDKQTe002481; Thu, 13 Sep 2007 08:20:26 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8DDKN3d002361; Thu, 13 Sep 2007 08:20:24 -0500 (CDT) Message-ID: <46E93912.10208@gmail.com> Date: Thu, 13 Sep 2007 15:20:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de><6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <1FEB9B9F2EC38343955D02B2AE86AACB48ABB7@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4978F@zrc2hxm2.corp.nortel.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC13@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B49FE1@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B49FE1@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: bae22017ea94d808e6875b7fc764857f Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Let's try to see whether we can formulate some questions to the group. -do we want or don't want to require that MAG and LMA are time synchronized. -do we want or don't want to use NTP for that. -do we want or don't want to use PBU/PBAck to sync times. -do we want or don't want to use timestamps at all. -do we want or don't want to use sequence numbers. Feel free to reformulate as you wish. Alex PS: I didn't describe the problem because the problem is described in the draft: draft proxymip6-04: > Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding > registration messages as a way for the home agent to process the > binding updates in the order they were sent by a mobile node. The > home agent and the mobile node are required to manage this counter > over the lifetime of a binding. However, in Proxy Mobile IPv6, as > the mobile node moves from one mobile access gateway to another and > in the absence of context transfer mechanism, the serving mobile > access gateway will be unable to determine the sequence number that > it needs to use in the signaling messages. Hence, the sequence > number scheme as specified in [RFC-3775], will be insufficient for > Proxy Mobile IPv6. > > If the local mobility anchor cannot determine the sending order of > the received binding registration messages, it may potentially > process an older message sent by a mobile access gateway, where the > mobile node was previously anchored, resulting in an incorrect > Binding Cache entry. Alex Ahmad Muhanna wrote: > Hi Kilian, > Please see comments inline. > > Regards, > Ahmad > >> Subject: RE: [netlmm] timestamp vs seqno redux >> >> Hi Ahmad, >> >> the issue only occurs when d2=~-d1 (PBU delay =~ amount that >> MAG's clock is ahead of LMA's clock). Then the LMA doesn't >> send a PBA with timestamp_mismatch status code and MAG >> doesn't compute a delta. I agree that the probability that >> this situation will occur may be low, but the consequences >> can be serious: Wrong BCE and packet loss till the next PBU. >> Is this acceptable? I'm not sure. > > [Ahmad] > I do not understand what is the problem here. Are we talking about the > race condition here or about synchronization. > If you are talking about the race condition, then there are a couple of > options to address it and the choice is yours. > > On the other hand, if we are talking about this synchronization issue, > IMO, as long as ordering P-BU/P-BA works and that MAG continuously > monitor the LMA timestamp through all P-BU and P-BA, then I do not see a > great impact here. > >> Furthermore, I don't really understand why we can't rely on >> an outside mechanism like NTP. Is there any scenario where >> NTP fails, but the PBA-based time sync does not fail? > > [Ahmad] > Kilian, > I have no problem with that requirement. Life will be good for > everyone:-) > The point here is that some people on the list do not want to mandate > the use of NTP server. I personally, respect that choice. It is valid > and hence, we should not mandate it. Again, personally, I have no > problem. >> Please see my email to Sri for suggestions to move on. > > > Please note that I'm only talking about *synchronization of MAG's clock > using the timestamp in the PBA*. Using the timestamp in PBUs to re-order > PBUs is not related to that and ok (under the assumption that the MAGs' > clocks are synchronized using some PMIP-independent mechanism like NTP) > > > [Ahmad] > Kilian, > > Using the PMIPv6 signaling does not have the objective of synchronizing > timestamp in an accuracy as NTP server. That is a whole protocol by > itself. However, what we are talking about is the use of timestamp in > ordering the P-BU/P-PA. And using PMIPv6 signaling as an alternative > mechanism should work. > >> Some more comments inline. >> >> BR, >> >> Kilian >> >>> -----Original Message----- >>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >>> Sent: Mittwoch, 12. September 2007 22:20 >>> To: Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE FEDERICO >>> Cc: netlmm@ietf.org >>> Subject: RE: [netlmm] timestamp vs seqno redux >>> >>> Hi Kilian, >>> >>> Please see comments inline. >>> >>> Regards, >>> Ahmad >>> >>>>> -----Original Message----- >>>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >>>>> Sent: Mittwoch, 12. September 2007 17:41 >>>>> To: Ahmad Muhanna; Kilian Weniger; Sri Gundavelli; DE >> JUAN HUARTE >>>>> FEDERICO >>>>> Cc: netlmm@ietf.org >>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>> >>>>> Resending hopefully with the correct format. >>>> thanks for re-sending. Much better to read now ;) >>>> >>>>> +++++ >>>>> >>>>> Hi Kilian/Federico and All, >>>>> >>>>> There has been a lot of email exchange that the timestamp >>>>> synchronization using the PMIPv6 signaling does not work. >>>> On the other >>>>> hand, I have not seen any in detail analysis which proves >>>> that it does >>>>> not work. I would like to share in details my thoughts on >>> how this >>>>> SHOULD work and please comment as necessary. >>>> In one of my previous emails I described an example >> scenarios where >>>> it fails, at least according to my understanding of the >> sync method. >>>> According to my understanding, the LMA only sees a delta time >>>> consisting of two parts: 1.) transmission delay of PBU >> (d2 in your >>>> example) and 2.) clock difference (d1 in your example). >>>> The problem is that the LMA doesn't know d1 and d2 >> itself, it only >>>> knows d1+d2. If d2=~-d1, i.e., MAG's clock is ahead of >> LMA's clock >>>> by a value that is roughly equal to the transmission delay, then >>>> d1+d2=~0, i.e., the LMA doesn't see any delta and assumes >> that the >>>> MAG's clock is in sync (which is not true). >>>> Hence, no re-sync happens and the LMA may accept outdated >> PBUs (see >>>> my previous email). >>> [Ahmad] >>> Kilian, >>> >>> This is the same race condition that we have discussed too >> many times >> >> When did we discuss the scenario where d2=~-d1 before? Can >> you please give me a pointer? >> >>> and people do not like to accept the unpopular solution :-) >> I have no >>> problem with that. But let us exactly identify all >> conditions related >>> to the scenario: >>> >>> 1. A race condition scenario which happens during handoff. >>> >>> 2. It assumes that the MAGs are not properly synchronized with each >>> other using an outside mechanism. We are here talking here >> about the >>> MAGs not the (LMA and MAGs). In other words, if the MAGs in >> the same >>> local domain are synchronized this issue will never happen. >> If you assume that the clocks of all MAGs are always properly >> synchronized using an outside mechanism, why do you want to >> specify a mechanism to synchronize the MAG's clock using >> timestamps in PBAs? >> >> >>> 3. It assumes that the pMAG sent a P-BU as a >> re-registration in a race >>> condition as the MN moves from pMAG (previous MAG) to nMAG >> (next MAG). >>> 4. Due to some network conditions, the P-BU of the pMAG >> arrives at the >>> LMA after the P-BU of the nMAG. >>> >>> 5. It also assumes that not only pMAG and nMAG is out of sync, but >>> also nMAG is slower than pMAG by almost double the delta >> between any >>> of them and the LMA. >>> >>> 6. Not only that but also, the nMAG is slower enough to the degree >>> that when the P-BU arrives at the LMA it is within the threshold. >>> >>> >>> Finally, >>> -------- >>> I am not saying that the possibility of this scenario to happen is >>> ZERO. >>> No. There is a possibility that it MAY happen but , at the >> same time, >>> it is very very slim. Not only that, I think according to the >> Maybe the probability that it happens is quite low, but the >> consequences can be serious: Wrong BCE and packet loss till >> the next PBU. >> >>> PMIPv6 draft, >>> MAG needs to make sure that the MN is currently attached before >>> sending a re-registration P-BU. If the MAG is not sure, >> then MAG does >>> not send the P-BU. >> Why is this related to the scenario in discussion? The MAG >> does not send a PBU if the MN is not attached. >> >>> NOW: what can we do about it: >>> ----------------------------- >>> >>> 1. The very famous but un-popular solution that we >> mentioned several >>> time. In case of handoff, i.e. when the LMA receives the P-BU from >>> nMAG, LMA considers this as a case of handoff. When LMA receives a >>> P-BU from the pMAG, LMA drops or rejects it with a code >> MN-in-handoff, >>> for example. Since it is a race condition, that will take >> care of it. >>> 2. LMA needs to track the delta for each MAG. Then after the P-BU >>> passes the LMA timestamp check and in case of handoff, LMA >> can always >>> make sure that the adjusted timestamp of the received P-BU >> is always >>> larger than the adjusted timestamp of the last received >> P-BU which is >>> already saved as part of the MN BCE. >> As you said this was already discussed and there was no >> consensus for it AFAIK. >> >> I don't understand why we cannot just rely on the outside >> time sync mechnanism like NTP? What is the problem with using >> a protocol like NTP, which was specifically designed to sync >> time? Why do we need a second time sync mechanism based on PBAs? >> >>> I hope that this will take care of this issue and we can >> finally move >>> on. >>> >>> Best Regards, >>> Ahmad >>> >>> BTW: please see more comments below. >>> >>>> Please see some more comments inline. >>>> >>>>> The following are a list of assumptions: >>>>> ======================================== >>>>> >>>>> 1. The time that the P-BU takes from MAG to LMA equals >>> the time the >>>>> P-BA takes from LMA to MAG. >>>> What is behind this assumption? Why not introduce another >> variable >>>> d3 for PBA delay (in addition to d2 for PBU delay). >>> [Ahmad] >>> Actually d3 is irrelevant in this regard. Because the >> timestamp delta >>> that the MAG is tracking does not depend on d3, because, >> MAG considers >>> the timestamp delta as the difference between the LMA-timestamp in >>> P-BA (which is independent of d3) and the MAG-timestamp in the >>> corresponding P-BU (which is again independent of d3). >>> >>> This means that regardless of the delay in the downlink direction, >>> only the delay in the uplink direction has an impact and >> that impact >>> is already factored IN and does not influence >> synchronization scheme. >>>> >>>>> 2. LMA Timestamp included in the P-BA is the LMA timestamp when >>>>> comparing timestamp in P-BU and LMA current timestamp. >>>>> 3. MAG use the difference between the P-BU timestamp and P-BA >>>>> timestamp for calculating the delta! >>>>> 4. MAG and LMA maintains the same out of sync delta during the >>>>> re-synchronization process. >>>>> >>>>> >>>>> MAG >>> LMA >>>>> ---------- >>>> ---------- >>>>> 1. Current Timestamp MAG.t1 LMA.t1 = >>>> MAG.t1 +d1 >>>>> 2. Timestamp in P-BU MAG.t1 LMA >>> timestamp: LMA.t1 >>>>> 3. MAG sends P-BU ============>>>>>>> P-BU(MAG.t1) >>>>> >>>>> 4. P-BU arrives at LMA .............. ===============>>>> >>>>> P-BU(MAG.t1) >>>>> >>>>> 5. Arrival Timestamp MAG.t1 + d2 >> LMA.t1 + d2 >>>>> 6. delta based on P-BU timestamp (LMA.t1 + >>>> d2)-(MAG.t1) >>>>> = >>>>> >>>>> ((MAG.t1+d1)+d2) - MAG.t1 >>>>> = >>>>> >>> delta.P-BU = d2+d1 >>>> right, d2+d1 is the delta that the LMA measures. >>> [Ahmad] >>> Correct. Measured from the MAG timestamp. Right? >>> >>>>> 7. Real delta >> delta.real = d1 >>>> How is the real delta d1 known by the LMA? >>> [Ahmad] >>> LMA does not need to know it. As long as the scheme works to >>> resynchronize the MAG with the LMA, no need for LMA to know >> it. Right? >> >> ok >> >>> >>>>> >>>>> >>>>> 8. Timestamp in P-BA MAG.t2 LMA.t2 = >>>> (LMA.t1 + d2) >>>>> P-BA(LMA.t2)<<<<<<<<<<<============== >>>> How does the LMA know d2? IMO, LMA only knows delta.P-BU = d2+d1. >>> [Ahmad] >>> Absolutely. LMA does not know what d2 and does not need to. >>> This is used >>> for proving the scheme. >> ok >> >>>> Hence, P-BA can only contain LMA.t2 = (LMA.t1 + delta.P-BU) = >>>> (LMA.t1 + >>>> d1 + d2) >>> [Ahmad] >>> I am afraid that is not correct. You probably meant to say: LMA.t2 = >>> (MAG.t1 + (d1+d2)). Right? >>> Otherwise, LMA.t2 in terms of LMA.t1 is as follows: LMA.t2 >> = LMA.t1 + >>> d2. NO? >> right, P-BA contains current timestamp of LMA, which is >> LMA.t2 = LMA.t1 >> + d2. >> >>>>> 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 >>>>> 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in >> corresponding >>>>> P-BU) >>>>> = >>>>> (LMA.t1 + d2) - MAG.t1 >>>>> = >>>>> ((MAG.t1 +d1)+d2) -MAG.t1 >>>>> >>>>> delta = d1+d2 >>>> delta should be d1+2*d2 >>> [Ahmad] >>> No. That is not correct. Delta = d1+d2. Please see above comment. >> right, delta is d1+d2. >> >>>>> 11. Real delta delta.real = d1 >>>> How does the LMA know the real delta? >>> [Ahmad] >>> It does not need to know. ONLY MAG needs to track a delta with the >>> LMA. >>> Well, we can make both track each other deltas but that will be too >>> much for the LMA and , honestly, it is not needed. >>> >>>> BR, >>>> >>>> Kilian >>>> >>>> >>>>> >>>>> What is the problem here? Or am I missing something? >>>>> Let us examine a re-registration or a P-BU/PA exchange >>> based on the >>>>> above synchronization: >>>>> >>>>> >>>>> MN- Resynchronization/Re-registration: >>>>> ======================================= >>>>> >>>>> 12. Current timestamp MAG.t3 LMA.t3 = >>>> MAG.t3 + d1 >>>>> 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 >>>>> 14. MAG sends P-BU ============>>>>>>> P-BU(MAG.t3 >>> + (d2+d1)) >>>>> 15. P-BU arrives at LMA .......============>>>> >>>> P-BU(MAG.t3+(d1+d2)) >>>>> 16. Arrival Timestamp MAG.t3 + d2 >> LMA.t3 + d2 >>>>> 17. delta based on P-BU >>>>> (LMA.t3+d2)-(MAG.t3+(d2+d1)) >>>>> = >>>>> >>>>> ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1)) >>>>> = >>>>> >>>>> >> delta.P-BU = ZERO >>>>> 18. Real delta >> delta.real = ZERO >> >> right. >> >> The issue only occurs when d2=~-d1, because then the LMA >> doesn't send a PBA with timestamp_mismatch status code and >> MAG doesn't compute a delta. >> This scenario is not shown in your diagrams... >> >> BR, >> >> Kilian >> >>>>> Please let me know what I am missing. >>>>> If nothing, I hope we can put an end to this debate and MOVE ON. >>>>> >>>>> Regards, >>>>> Ahmad >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Muhanna, Ahmad (RICH1:2H10) >>>>>> Sent: Wednesday, September 12, 2007 9:59 AM >>>>>> To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE >>> FEDERICO' >>>>>> Cc: 'netlmm@ietf.org' >>>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>>> >>>>>> Hi Kilian/Federico and All, >>>>>> >>>>>> >>>>>> There has been a lot of email exchange that the timestamp >>>>>> synchronization using the PMIPv6 signaling does not >>> work. On the >>>>>> other hand, I have not seen any in detail analysis which >>>> proves that >>>>>> it does not work. I would like to share in details my >>> thoughts on >>>>>> how this SHOULD work and please comment as necessary. >>>>>> >>>>>> The following are a list of assumptions: >>>>>> ======================================== >>>>>> >>>>>> 1. The time that the P-BU takes from MAG to LMA equals >>>> the time the >>>>>> P-BA takes from LMA to MAG. >>>>>> 2. LMA Timestamp included in the P-BA is the LMA >> timestamp when >>>>>> comparing timestamp in P-BU and LMA current timestamp. >>>>>> 3. MAG use the difference between the P-BU timestamp and P-BA >>>>>> timestamp for calculating the delta! >>>>>> 4. MAG and LMA maintains the same out of sync delta >> during the >>>>>> re-synchronization process. >>>>>> >>>>>> >>>>>> >>>>>> MAG >>>>>> LMA >>>>>> ---------- >>>>>> ---------- >>>>>> 1. Current Timestamp MAG.t1 >>>>>> LMA.t1 = MAG.t1 +d1 >>>>>> 2. Timestamp in P-BU MAG.t1 LMA >>>>>> timestamp: LMA.t1 >>>>>> 3. MAG sends P-BU ============>>>>>>> P-BU(MAG.t1) >>>>>> 4. P-BU arrives at LMA ....................... >>>>>> ===============>>>> P-BU(MAG.t1) >>>>>> 5. Arrival Timestamp MAG.t1 + d2 >>>>>> LMA.t1 + d2 >>>>>> >>>>>> 6. delta based on P-BU timestamp >>>>>> (LMA.t1 + d2) - (MAG.t1) >>>>>> >>>>>> = >>>>>> >>>>>> ((MAG.t1+d1)+d2) - MAG.t1 >>>>>> >>>>>> = >>>>>> >>>>>> delta.P-BU = d2+d1 >>>>>> >>>>>> 7. Real delta >>>>>> delta.real = d1 >>>>>> >>>>>> >>> >>>>>> 8. Timestamp in P-BA MAG.t2 >>>>>> LMA.t2 = (LMA.t1 + d2) >>>>>> >>>>>> P-BA(LMA.t2)<<<<<<<<<<<===================== >>>>>> 9. P-BA arrives @ MAG MAG.t2 + d2 >>>>>> LMA.t2 + d2 >>>>>> 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in >>>> corresponding >>>>>> P-BU) >>>>>> = >>>>>> (LMA.t1 + d2) - MAG.t1 >>>>>> = >>>>>> ((MAG.t1 +d1)+d2) -MAG.t1 >>>>>> >>>>>> delta = d1+d2 >>>>>> >>>>>> 11. Real delta delta.real = d1 >>>>>> >>>>>> >>>>>> What is the problem here? Or am I missing something? >>>>>> >>>>>> >>>>>> Let us examine a re-registration or a P-BU/PA exchange >>>> based on the >>>>>> above synchronization: >>>>>> ============================================================== >>>>>> ============================ >>>>>> >>>>>> MN- Resynchronization/Re-registration: >>>>>> ======================================= >>>>>> >>>>>> 12. Current timestamp MAG.t3 >>>>>> LMA.t3 = MAG.t3 + d1 >>>>>> 13. Timestamp in P-BU MAG.t3 + (d1+d2) >>>>> LMA.t3 >>>>>> 14. MAG sends P-BU ============>>>>>>> P-BU(MAG.t3 >>>> + (d2+d1)) >>>>>> 15. P-BU arrives at LMA >>>>>> .......................===============>>>> P-BU(MAG.t3 >>> + (d1+d2)) >>>>>> 16. Arrival Timestamp MAG.t3 + d2 >>>>>> LMA.t3 + d2 >>>>>> >>>>>> 17. delta based on P-BU >>>>>> (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) >>>>>> >>>>>> = >>>>>> >>>>>> ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) >>>>>> >>>>>> = >>>>>> >>>>>> delta.P-BU = ZERO >>>>>> >>>>>> 18. Real delta >>>>>> delta.real = ZERO >>>>>> >>>>>> Please let me know what I am missing. >>>>>> >>>>>> If nothing, I hope we can put an end to this debate >> and MOVE ON. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Ahmad >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Kilian Weniger >> [mailto:Kilian.Weniger@eu.panasonic.com] >>>>>>> Sent: Wednesday, September 12, 2007 3:07 AM >>>>>>> To: Sri Gundavelli >>>>>>> Cc: netlmm@ietf.org >>>>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>>>> >>>>>>> Hi Sri, >>>>>>> >>>>>>> please see my comments inline. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>>>>>> Sent: Mittwoch, 12. September 2007 08:14 >>>>>>>> To: 'Kilian Weniger' >>>>>>>> Cc: netlmm@ietf.org >>>>>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>>>>> >>>>>>>> Hi Kilian/Federico, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Kilian Weniger >>>> [mailto:Kilian.Weniger@eu.panasonic.com] >>>>>>>>> Sent: Tuesday, September 11, 2007 6:33 AM >>>>>>>>> To: Sri Gundavelli >>>>>>>>> Cc: netlmm@ietf.org >>>>>>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>>>>>> >>>>>>>>> Hi Sri, >>>>>>>>> >>>>>>>>> my point is that NOT mandating synchronization to an >>>>>>> external clock >>>>>>>>> source for the timestamp option implies that sending PBU >>>>>>> msgs with >>>>>>>>> timestamp option is allowed even when MAGs are not (yet) >>>>>>>> synchronized. >>>>>>>>> I.e., it would be allowed that a deployment >> uses only the >>>>>>> returned >>>>>>>>> timestamps in PBA msgs to synchronize the MAG clocks. I >>>>>> think the >>>>>>>>> draft should not allow this for the following reasons: >>>>>>>>> >>>>>>>> The stated assumption for the timestamp based approach to >>>>>> work, is >>>>>>>> the requirement for the MAG's to have synchronized clocks. >>>>>>>> That is a requirement. Now, if a given MAG sends a >>>> PBU with an >>>>>>>> incorrect timestamp, its an error and as you and >>>>> Federico pointed >>>>>>>> out, there are cases where the LMA will not be able to >>>>>> determine the >>>>>>>> sending order of the received packets. This is an error >>>>>> condition, >>>>>>>> as the requirement is not met. >>>>>>> Right, sending a PBU with timestamp option requires that >>>>> the MAG's >>>>>>> clock is synchronized. Hence, I don't see why the draft >>>>>> should specify >>>>>>> a mechanism to synchronize a MAG's clock using a received >>>>>> PBA. Also, I >>>>>>> think this mechanism has issues in some scenario (see >>>> my previous >>>>>>> mail). >>>>>>> >>>>>>> >>>>>>> The clock synchronization is the job of some >> PMIP-independent >>>>>>> synchronization method like NTP and out of sync clocks can >>>>>> only occur >>>>>>> if there is a problem with this PMIP-independent >>>> synchronization >>>>>>> method. >>>>>>> Hence, it is a non-recoverable error case from PMIP >>>> point of view >>>>>>> IMHO. >>>>>>> >>>>>>>> Now, should the draft state that the time >>>> synchronization is a >>>>>>>> requirement and additionally mandate a method of time >>>>>>> synchronization, >>>>>>>> say by NTP ? But, the later has a system wide impact and >>>>>>> additionally, >>>>>>>> a given architecture where this protocol is applied, can >>>>>> achieve the >>>>>>>> time synchronization through other non NTP means. IMO, we >>>>>> may not be >>>>>>>> able dictate that. Also, we want implementations to >>>> support the >>>>>>>> timestamp based scheme by default. Now, mandating the NTP >>>>>> usage will >>>>>>>> create some restrictions for some deployments. So, >>>> that is the >>>>>>>> reasoning behind not mandating the method of time >>>>> synchronization. >>>>>>> I'm not sure if the draft can say "a MAG's clock MUST be >>>>>> synchronized >>>>>>> for this protocol to work, but how this is done is out of >>>>>> scope of the >>>>>>> draft". I guess the draft has to mandate the >>>>> implementation of one >>>>>>> "default" synchronization protocol such as NTP to achieve >>>>>>> interoperability. However, as long as the use of NTP is not >>>>>> mandated >>>>>>> (e.g., just say "SHOULD use"), deployments can still >>> use other >>>>>>> methods. >>>>>>> So I don't see restrictions for deployments in this case. >>>>>>> >>>>>>>> W.r.t this below scenario, the reason for LMA to >> return its >>>>>>> timestamp, >>>>>>>> solves two purposes. 1.) Diagnostics (especially useful >>>>>> when the LMA >>>>>>>> and MAG are in different admin domains) 2.) The MAG can >>>>>> detect that >>>>>>>> its clock is not in sync and take the necessary >>>>> actions. I guess, >>>>>>>> Frederico has an issue with the second part. But, if you >>>>>> look at the >>>>>>>> recommendation from the draft on handling this error >>>> case, MAG >>>>>>>> signaling considerations, >>>>>>>> >>>>>>>> "If the received Proxy Binding Acknowledgement >>>>>> message has the >>>>>>>> Status field value set to >> TIMESTAMP_MISMATCH (Invalid >>>>>>>> Timestamp), >>>>>>>> the mobile access gateway SHOULD try to register >>>>> again only >>>>>>>> after >>>>>>>> it synchronized its clock with the local mobility >>>>> anchor's >>>>>>>> system >>>>>>>> clock or to a common time source that is used by >>>>>> all mobility >>>>>>>> entities in that domain for their clock >>>> synchronization." >>>>>>> I think it is good if the LMA informs the MAG about >>>>> detected out of >>>>>>> sync clocks for the purpose of diagnostics and as a >>> trigger for >>>>>>> re-sync. But why do we need the timestamp option in the >>>> PBA? The >>>>>>> TIMESTAMP_MISMATCH value in the status field is enough for >>>>>> the purpose >>>>>>> of diagnostics and as a trigger for re-sync. >>>>>>> >>>>>>>> So, we are not really using the LMA as the time source. >>>>>>> Now, with the >>>>>>>> given assumptions, do you see an issue if we dont say NTP >>>>>> is a MUST, >>>>>>>> but we say clock synch is a requirement, how they do it, >>>>>> draft does >>>>>>>> not say. If this requirement is not met, its an incorrect >>>>>> usage of >>>>>>>> the protocol and the PBU ordering will fail in that >>>>> special rare >>>>>>>> reordering scenario (IMO, its not a practical issue). >>>>>>> see above >>>>>>> >>>>>>> BR, >>>>>>> >>>>>>> Kilian >>>>>>> >>>>>>>> The second question to this discussion, is Alex's >>>> point of not >>>>>>>> mandating Timestamp option as a MUST implement. For this, >>>>>>> as I stated >>>>>>>> before, this is few lines of code for supporting this >>>>>> option and if >>>>>>>> seq number scheme is in use, this need not be used at >>>>>> all. We need >>>>>>>> to mandate this as there is no CT in the base spec. But, >>>>>> this is not >>>>>>>> a >>>>>>> big issue >>>>>>>> either way. If others agree, I'm fine not mandating this. >>>>>>>> But, I really >>>>>>>> believe, implementations can support this option, at the >>>>>> least cost. >>>>>>>> One last comment on the trust on LMA's clock for >> the sanity >>>>>>> check, is >>>>>>>> because its an anchor point and its typically well >>>>>> managed, compared >>>>>>>> to MAG's, where they are scattered out. So, its >>>>>> reasonable to expect >>>>>>>> the clock on the LMA to be in sync, else all >>>>>> registrations will fail >>>>>>>> and will generate the traps. >>>>>>>> >>>>>>>> So, let me know your comments on how we can move forward. >>>>>>>> >>>>>>>> >>>>>>>> Sri >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 1. If a MAG's clock is out of sync (i.e., not yet >>> synced by >>>>>>>>> receiving a PBA with timestamp) AND PBUs sent by >>>> this MAG are >>>>>>>>> delayed, >>>>>>>> the out of >>>>>>>>> sync situation may not be detectable by the LMA and old >>>>>>> PBUs may be >>>>>>>>> accepted by the LMA. >>>>>>>>> >>>>>>>>> Consider the following example: MN attaches to MAG1 >>>>> and shortly >>>>>>>>> thereafter hands over to MAG2. MAG2's clock is in sync >>>>>> with LMA's >>>>>>>>> clock, but MAG1's clock is out of sync and is ahead of >>>>>> LMA's clock >>>>>>>>> by 5 seconds. MAG1-LMA link is highly congested. When MN >>>>>>>> attaches to MAG1, >>>>>>>>> MAG1 sends PBU1 msg to LMA. This happens 3 >> seconds before >>>>>>>> the MN hands >>>>>>>>> over to MAG2. The PBU1 msg is delayed by 5 seconds >>>> due to the >>>>>>>>> congestion and hence arrives at LMA 2 seconds after >>>> handover. >>>>>>>>> Despite of the delay, >>>>>>>>> PBU1 has a valid timestamp from LMA's point of view due >>>>>>> to the wrong >>>>>>>>> clock of MAG1. MAG2 sends a PBU2 msg 1 second after >>>>>>>> handover. PBU2 is >>>>>>>>> not significantly delayed and arrives at LMA ~1 seconds >>>>>>>> after handover >>>>>>>>> with valid timestamp. In this scenario, the LMA >>>> will wrongly >>>>>>>>> accept PBU1 arriving after PBU2, since both >> have a valid >>>>>>>>> timestamp. >>>>>>>> Consequently, >>>>>>>>> the LMA forwards packets to the wrong MAG (MAG1) >>>> and will not >>>>>>>>> notice the out of sync of MAG1, which also means >>>> that the LMA >>>>>>> doesn't return a >>>>>>>>> timestamp in the PBA and MAG1's clock keeps to be >>>> out of sync. >>>>>>>>> 2. When packets on the link between MAG and LMA >>>>>>> experience high (and >>>>>>>>> varying) packet delays (e.g., due to congestion), the >>>>>>>> timestamp in the >>>>>>>>> PBA returned by the LMA may already be outdated >>> at the time >>>>>>>> it arrives >>>>>>>>> at the MAG. So exactly in the situation where a >>> re-ordering >>>>>>>> of PBUs is >>>>>>>>> needed, the synchronization mechanism may fail. >>>>>>>>> >>>>>>>>> My two cents. >>>>>>>>> >>>>>>>>> BR, >>>>>>>>> >>>>>>>>> Kilian >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>>>>>>>> Sent: Freitag, 7. September 2007 18:48 >>>>>>>>>> To: 'Kilian Weniger' >>>>>>>>>> Cc: netlmm@ietf.org >>>>>>>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>>>>>>> >>>>>>>>>> Hi Kilian, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Kilian Weniger >>>>>> [mailto:Kilian.Weniger@eu.panasonic.com] >>>>>>>>>>> Sent: Friday, September 07, 2007 2:09 AM >>>>>>>>>>> To: Sri Gundavelli >>>>>>>>>>> Cc: netlmm@ietf.org >>>>>>>>>>> Subject: RE: [netlmm] timestamp vs seqno redux >>>>>>>>>>> >>>>>>>>>>> Hi Sri, >>>>>>>>>>> >>>>>>>>>>>> - We are NOT mandating the nodes in the domain to >>>>>> sync up to >>>>>>>>>>>> a clock source. >>>>>>>>>>> Hmm, so far I assumed that the proposal is to >>>> mandate the >>>>>>>>>> MAGs to sync >>>>>>>>>>> up to an external clock source such as NTP server. >>>>>>>>>>> >>>>>>>>>> For the timestamp option to work, we RECOMMEND the use >>>>>>> of NTP for >>>>>>>>>> synchronizing the clocks in the domain. However, we do >>>>>>> not want to >>>>>>>>>> mandate on a specific mechanism. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Base draft does not support Context Transfers. >>>>> Given that >>>>>>>>>> the draft >>>>>>>>>>>> will be incomplete, if we dont mandate >> the support. >>>>>>>> By mandating >>>>>>>>>>>> the support, the LMA can always return >> its timestamp >>>>>>>> and the MAG >>>>>>>>>>>> can use that timestamp and register. This need to >>>>>>> be done just >>>>>>>>>>>> once whenever the LMA/MAG clocks are out >> of sync and >>>>>>>>> just for one >>>>>>>>>>>> registration. One extra round trip for the 1st >>>>>>>>>> registration between >>>>>>>>>>>> LMA/MAG pair. >>>>>>>>>>> So the proposal is to allow the use of the timestamp >>>>>>>> option in the >>>>>>>>>>> absence of any external time synchronization >>>> like NTP and >>>>>>>>>> to mandate a >>>>>>>>>>> mechanism to synchronize clocks between MAGs >>>> and LMA (and >>>>>>>>>>> hence between all MAGs) using the timestamp option >>>>>> in PBU/PBA >>>>>>>>>>> only >>>>>>>>> (i.e., without >>>>>>>>>>> utilizing NTP or an external clock source)? Is my >>>>>>>>>>> understanding correct? >>>>>>>>>>> >>>>>>>>>> No. For this to work, we require the clocks to >>> be in sync. >>>>>>>>>> How its achieved, it could be based on NTP or >> some other >>>>>>>> protocols. >>>>>>>>>> But, why should we mandate this. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> If so, can you please give some more details how >>>>>> the LMA can >>>>>>>>>>> detect that the clocks are out of sync? Is it >>>> based on a >>>>>>>>>>> certain >>>>>>>> difference of >>>>>>>>>>> timestamp in the received PBU and the current >>>> LMA's time? >>>>>>>>>>> And how to differentiate the out of sync >> case from the >>>>>>>>> out-of-order >>>>>>>>>>> delivery case (i.e., a PBU is delayed and overtaken >>>>>> by another >>>>>>>>>>> PBU from another MAG)? For instance, if the LMA >>>>>> receives a PBU >>>>>>>>> with timestamp >>>>>>>>>>> equal to "current time of LMA - X" and X > >>>> threshold, how >>>>>>>>>> does the LMA >>>>>>>>>>> know whether the >>>>>>>>>>> 1. the MAG clock is synchronized, but the PBU got >>>>>>>> delayed by X or >>>>>>>>>>> 2. the PBU is not delayed, but the MAG's >>> clock is out of >>>>>>>>> sync by X? >>>>>>>>>>> Ideally, in case 1 the LMA should just ignore >>>> the PBU, in >>>>>>>>> case 2 it >>>>>>>>>>> should accept it and sync clocks. >>>>>>>>>>> >>>>>>>>>>> If the idea is to always reject a PBU with X >>>> threshold >>>>>>>>>> and include a >>>>>>>>>>> current timestamp in the PBA, then I guess the >>>> same could >>>>>>>>>> be done with >>>>>>>>>>> sequence numbers instead of timestamps, right? >>>>>>>>>>> >>>>>>>>>> For what ever reasons if the LMA and MAG >> clocks are out >>>>>>>> of sync, the >>>>>>>>>> LMA can return its timestamp and the MAG can >>> always apply >>>>>>>> that delta >>>>>>>>>> in all the registration it sends. This is done >>> just once, >>>>>>>> when ever >>>>>>>>>> the clocks are off. But, with seq number scheme, >>>> this needs >>>>>>>>> to be done >>>>>>>>>> for each MN registration. Its as per the 3775 per MN >>>>>> seq number. >>>>>>>>>> Sri >>>>>>>>>> >>>>>>>>>>> BR, >>>>>>>>>>> >>>>>>>>>>> Kilian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Panasonic R&D Center Germany GmbH >>>>>>>>>>> 63225 Langen, Hessen, Germany >>>>>>>>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing >>>>>> Director: Thomas >>>>>>>>>>> Micke >>>>>>>>>> >>>>>>>>> >>>>>>>>> Panasonic R&D Center Germany GmbH >>>>>>>>> 63225 Langen, Hessen, Germany >>>>>>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing >>>>> Director: Thomas >>>>>>>>> Micke >>>>>>>> >>>>>>> >>>>>>> Panasonic R&D Center Germany GmbH >>>>>>> 63225 Langen, Hessen, Germany >>>>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing >>> Director: Thomas >>>>>>> Micke >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netlmm mailing list >>>>>>> netlmm@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>> >>>>> >>>> >>>> Panasonic R&D Center Germany GmbH >>>> 63225 Langen, Hessen, Germany >>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: >> Thomas Micke >>>> >>>> >>> >> >> Panasonic R&D Center Germany GmbH >> 63225 Langen, Hessen, Germany >> Reg: AG Offenbach (Hessen) HRB 33974 >> Managing Director: Thomas Micke >> >> >> > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 09:34:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoqE-0003dZ-KJ; Thu, 13 Sep 2007 09:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVoqD-0003dT-EH for netlmm@ietf.org; Thu, 13 Sep 2007 09:34:45 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVoqC-0004t8-7s for netlmm@ietf.org; Thu, 13 Sep 2007 09:34:45 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DDYW516145; Thu, 13 Sep 2007 13:34:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 08:34:24 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B4A06E@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E9354A.3030303@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2Bpxz2dKD+4ETQPCL9E8p7nSJ2AAA9aGg References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F93@zrc2hxm2.corp.nortel.com> <46E9354A.3030303@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Okay, Then you assume that the MAG will not send any other P-BU for any other MN in 10 minutes. That is possible. However, reality is a little different than that. On the other hand, let us argue to the extreme that you are right. MAG is not sending any other P-BU for 10 minutes and the network state has changed. What the consequences. 2 round trips right? The idea here, how often that should happen?=20 Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Thursday, September 13, 2007 8:04 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Alexandru Petrescu; Kilian Weniger; Sri Gundavelli; DE=20 > JUAN HUARTE FEDERICO; netlmm@ietf.org > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > >> Subject: Re: [netlmm] timestamp vs seqno redux > >> > >> Ahmad Muhanna wrote: > >>>> Subject: Re: [netlmm] timestamp vs seqno redux > >>>> > >>>> Ahmad Muhanna wrote: > >>>>> Hi Alex, > >>>>> > >>>>> No it does not have an effect on the calculation. > >>>> So why do you mention it as an assumption? > >>> [Ahmad] > >>> It is an over sight on my part. Sorry for the confusion. > >> Ahmad, I think any assumption on a constant delay of the=20 > network is=20 > >> wrong, be it symmetric or asymmetric. You do a=20 > measurement now and=20 > >> ten minutes later the delays are different because somebody else=20 > >> loads the network. > >> > >> You do 10 measurements in a burst and you get different times,=20 > >> eventually with a Gaussian distribution. That's the first=20 > experience=20 > >> with ping. > >=20 > > [Ahmad] > > Alex, There is no assumption about a constant delay? > > This is just used for a snap shot analysis to prove the concept is=20 > > valid. That is all. >=20 > What makes you think that the situation is the same when you=20 > make your snapshot and 10minutes later? >=20 > > If the network condition changes, the concept still valid=20 > and should=20 > > adjust itself and work. NO? >=20 > Don't you assume that when network conditions change a new=20 > measurement is necessary? How do you know when network=20 > conditions change? >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 09:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVozY-0005nK-Ap; Thu, 13 Sep 2007 09:44:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVozX-0005nE-3I for netlmm@ietf.org; Thu, 13 Sep 2007 09:44:23 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVozV-0005tw-3S for netlmm@ietf.org; Thu, 13 Sep 2007 09:44:23 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DDhxk24765; Thu, 13 Sep 2007 13:43:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 08:43:58 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B4A0BC@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E93293.1050801@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2BQE6QxcKhQ1pS26bkygVXSNx4AABnmyQ References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E93293.1050801@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 76fee95f697ac1bd4d0bfe58b40699d9 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hello Alex, Please see inline. Regards, Ahmad =20 > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > > Resending hopefully with the correct format. > >=20 > > +++++ > >=20 > > Hi Kilian/Federico and All, > >=20 > > There has been a lot of email exchange that the timestamp=20 > > synchronization using the PMIPv6 signaling does not work.=20 > On the other=20 > > hand, I have not seen any in detail analysis which proves=20 > that it does=20 > > not work. I would like to share in details my thoughts on how this=20 > > SHOULD work and please comment as necessary. > >=20 > > The following are a list of assumptions: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 1. The time that the P-BU takes from MAG to LMA equals the time the=20 > > P-BA takes from LMA to MAG. > > 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > > comparing timestamp in P-BU and LMA current timestamp. > > 3. MAG use the difference between the P-BU timestamp and P-BA=20 > > timestamp for calculating the delta! > > 4. MAG and LMA maintains the same out of sync delta during the=20 > > re-synchronization process. >=20 > Ahmad, you should also list the implicit assumption you make=20 > that MAG and LMA will keep time ok, once synchronized. [Ahmad] The assumption is that it is synchronized during the synchronization process. If you see another assumption, please come forward and identify and qualify it and we will discuss it. >=20 > Or, that assumption can sometimes be not true. >=20 > An LMA or MAG's LiIon BIOS battery can dry out and reset the=20 > clocks on an arbitrary basis. [Ahmad] Another bad luck, but what is the consequence? Does the concept work or NOT? That is what important? >=20 > Alex >=20 > >=20 > >=20 > > MAG LMA > > ---------- =20 > ---------- > > 1. Current Timestamp MAG.t1 LMA.t1 =3D=20 > MAG.t1 +d1 > > 2. Timestamp in P-BU MAG.t1 LMA timestamp: LMA.t1 > > 3. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t1) > >=20 > > 4. P-BU arrives at LMA .............. = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>=20 > > P-BU(MAG.t1) > >=20 > > 5. Arrival Timestamp MAG.t1 + d2 LMA.t1 + d2 > > 6. delta based on P-BU timestamp (LMA.t1 +=20 > d2)-(MAG.t1) > > =3D > > =20 > ((MAG.t1+d1)+d2) - MAG.t1 > > =3D > > delta.P-BU =3D = d2+d1 > >=20 > > 7. Real delta delta.real =3D d1 > >=20 > >=20 > >=20 > > 8. Timestamp in P-BA MAG.t2 LMA.t2 =3D=20 > (LMA.t1 + d2) > > = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 9. P-BA arrives @ MAG MAG.t2 + d2 LMA.t2 + d2 > > 10. Delta based on P-BA LMA.t2-MAG.t1 (timestamp in=20 > corresponding P-BU) > > =3D > > (LMA.t1 + d2) - MAG.t1 > > =3D > > ((MAG.t1 +d1)+d2) -MAG.t1 > >=20 > > delta =3D d1+d2 > >=20 > > 11. Real delta delta.real =3D d1 > >=20 > >=20 > > What is the problem here? Or am I missing something? > > Let us examine a re-registration or a P-BU/PA exchange based on the=20 > > above synchronization: > >=20 > >=20 > > MN- Resynchronization/Re-registration: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > 12. Current timestamp MAG.t3 LMA.t3 =3D=20 > MAG.t3 + d1 > > 13. Timestamp in P-BU MAG.t3 + (d1+d2) LMA.t3 > > 14. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t3 + (d2+d1)) > >=20 > > 15. P-BU arrives at LMA = .......=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>=20 > P-BU(MAG.t3+(d1+d2)) > > 16. Arrival Timestamp MAG.t3 + d2 LMA.t3 + d2 > > 17. delta based on P-BU =20 > (LMA.t3+d2)-(MAG.t3+(d2+d1)) > > =3D > > =20 > ((MAG.t3+d1)+d2)-(MAG.t3+(d2+d1)) > > =3D > >=20 > > delta.P-BU =3D ZERO > > 18. Real delta delta.real =3D ZERO > >=20 > > Please let me know what I am missing. > > If nothing, I hope we can put an end to this debate and MOVE ON. > >=20 > > Regards, > > Ahmad > > =20 > >=20 > >> -----Original Message----- > >> From: Muhanna, Ahmad (RICH1:2H10) > >> Sent: Wednesday, September 12, 2007 9:59 AM > >> To: 'Kilian Weniger'; 'Sri Gundavelli'; 'DE JUAN HUARTE FEDERICO' > >> Cc: 'netlmm@ietf.org' > >> Subject: RE: [netlmm] timestamp vs seqno redux > >> > >> Hi Kilian/Federico and All, > >> > >> > >> There has been a lot of email exchange that the timestamp=20 > >> synchronization using the PMIPv6 signaling does not work. On the=20 > >> other hand, I have not seen any in detail analysis which=20 > proves that=20 > >> it does not work. I would like to share in details my=20 > thoughts on how=20 > >> this SHOULD work and please comment as necessary. > >> > >> The following are a list of assumptions: > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> 1. The time that the P-BU takes from MAG to LMA equals the=20 > time the=20 > >> P-BA takes from LMA to MAG. > >> 2. LMA Timestamp included in the P-BA is the LMA timestamp when=20 > >> comparing timestamp in P-BU and LMA current timestamp. > >> 3. MAG use the difference between the P-BU timestamp and P-BA=20 > >> timestamp for calculating the delta! > >> 4. MAG and LMA maintains the same out of sync delta during the=20 > >> re-synchronization process. > >> > >> > >> > >> MAG =20 > >> LMA > >> ---------- =20 > >> ---------- > >> 1. Current Timestamp MAG.t1 =20 > >> LMA.t1 =3D MAG.t1 +d1 > >> 2. Timestamp in P-BU MAG.t1 LMA=20 > >> timestamp: LMA.t1 > >> 3. MAG sends P-BU =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> = P-BU(MAG.t1) > >> 4. P-BU arrives at LMA .......................=20 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> P-BU(MAG.t1) > >> 5. Arrival Timestamp MAG.t1 + d2 =20 > >> LMA.t1 + d2 > >> > >> 6. delta based on P-BU timestamp =20 > >> (LMA.t1 + d2) - (MAG.t1) > >> =20 > >> =3D > >> =20 > >> ((MAG.t1+d1)+d2) - MAG.t1=09 > >> =20 > >> =3D > >> =20 > >> delta.P-BU =3D d2+d1 > >> > >> 7. Real delta =20 > >> delta.real =3D d1 > >> > >> =20 > >> 8. Timestamp in P-BA MAG.t2 =20 > >> LMA.t2 =3D (LMA.t1 + d2) > >> =20 > >> = P-BA(LMA.t2)<<<<<<<<<<<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> 9. P-BA arrives @ MAG MAG.t2 + d2 =20 > >> LMA.t2 + d2 > >> 10. Delta based on P-BA LMA.t2 - MAG.t1 (timestamp in=20 > corresponding=20 > >> P-BU) > >> =3D > >> (LMA.t1 + d2) - MAG.t1 > >> =3D > >> ((MAG.t1 +d1)+d2) -MAG.t1 > >> =20 > >> delta =3D d1+d2 > >> > >> 11. Real delta delta.real =3D d1 > >> > >> > >> What is the problem here? Or am I missing something? > >> > >> > >> Let us examine a re-registration or a P-BU/PA exchange=20 > based on the=20 > >> above synchronization: > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >> > >> MN- Resynchronization/Re-registration: > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> 12. Current timestamp MAG.t3 =20 > >> LMA.t3 =3D MAG.t3 + d1 > >> 13. Timestamp in P-BU MAG.t3 + (d1+d2) =20 > LMA.t3 > >> 14. MAG sends P-BU = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>> P-BU(MAG.t3 + (d2+d1)) > >> 15. P-BU arrives at LMA > >> = .......................=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>> = P-BU(MAG.t3 + (d1+d2)) > >> 16. Arrival Timestamp MAG.t3 + d2 =20 > >> LMA.t3 + d2 > >> > >> 17. delta based on P-BU =20 > >> (LMA.t3 + d2) - (MAG.t3 + (d2+d1)) > >> =20 > >> =3D > >> =20 > >> ((MAG.t3+d1)+ d2) - (MAG.t3 + (d2+d1)) > >> =20 > >> =3D > >> =20 > >> delta.P-BU =3D ZERO > >> > >> 18. Real delta =20 > >> delta.real =3D ZERO =20 > >> > >> Please let me know what I am missing. > >> > >> If nothing, I hope we can put an end to this debate and MOVE ON. > >> =09 > >> > >> Regards, > >> Ahmad > >> =20 > >> > >>> -----Original Message----- > >>> From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > >>> Sent: Wednesday, September 12, 2007 3:07 AM > >>> To: Sri Gundavelli > >>> Cc: netlmm@ietf.org > >>> Subject: RE: [netlmm] timestamp vs seqno redux > >>> > >>> Hi Sri, > >>> > >>> please see my comments inline. > >>> > >>>> -----Original Message----- > >>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >>>> Sent: Mittwoch, 12. September 2007 08:14 > >>>> To: 'Kilian Weniger' > >>>> Cc: netlmm@ietf.org > >>>> Subject: RE: [netlmm] timestamp vs seqno redux > >>>> > >>>> Hi Kilian/Federico, > >>>> > >>>> =20 > >>>> > >>>>> -----Original Message----- > >>>>> From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > >>>>> Sent: Tuesday, September 11, 2007 6:33 AM > >>>>> To: Sri Gundavelli > >>>>> Cc: netlmm@ietf.org > >>>>> Subject: RE: [netlmm] timestamp vs seqno redux > >>>>> > >>>>> Hi Sri, > >>>>> > >>>>> my point is that NOT mandating synchronization to an > >>> external clock > >>>>> source for the timestamp option implies that sending PBU > >>> msgs with > >>>>> timestamp option is allowed even when MAGs are not (yet) > >>>> synchronized. > >>>>> I.e., it would be allowed that a deployment uses only the > >>> returned > >>>>> timestamps in PBA msgs to synchronize the MAG clocks. I > >> think the > >>>>> draft should not allow this for the following reasons: > >>>>> > >>>> The stated assumption for the timestamp based approach to > >> work, is > >>>> the requirement for the MAG's to have synchronized clocks. > >>>> That is a requirement. Now, if a given MAG sends a PBU with an=20 > >>>> incorrect timestamp, its an error and as you and=20 > Federico pointed=20 > >>>> out, there are cases where the LMA will not be able to > >> determine the > >>>> sending order of the received packets. This is an error > >> condition, > >>>> as the requirement is not met. > >>> Right, sending a PBU with timestamp option requires that=20 > the MAG's=20 > >>> clock is synchronized. Hence, I don't see why the draft > >> should specify > >>> a mechanism to synchronize a MAG's clock using a received > >> PBA. Also, I > >>> think this mechanism has issues in some scenario (see my previous=20 > >>> mail). > >>> > >>> > >>> The clock synchronization is the job of some PMIP-independent=20 > >>> synchronization method like NTP and out of sync clocks can > >> only occur > >>> if there is a problem with this PMIP-independent synchronization=20 > >>> method. > >>> Hence, it is a non-recoverable error case from PMIP point of view=20 > >>> IMHO. > >>> > >>>> Now, should the draft state that the time synchronization is a=20 > >>>> requirement and additionally mandate a method of time > >>> synchronization, > >>>> say by NTP ? But, the later has a system wide impact and > >>> additionally, > >>>> a given architecture where this protocol is applied, can > >> achieve the > >>>> time synchronization through other non NTP means. IMO, we > >> may not be > >>>> able dictate that. Also, we want implementations to support the=20 > >>>> timestamp based scheme by default. Now, mandating the NTP > >> usage will > >>>> create some restrictions for some deployments. So, that is the=20 > >>>> reasoning behind not mandating the method of time=20 > synchronization. > >>> I'm not sure if the draft can say "a MAG's clock MUST be > >> synchronized > >>> for this protocol to work, but how this is done is out of > >> scope of the > >>> draft". I guess the draft has to mandate the=20 > implementation of one=20 > >>> "default" synchronization protocol such as NTP to achieve=20 > >>> interoperability. However, as long as the use of NTP is not > >> mandated > >>> (e.g., just say "SHOULD use"), deployments can still use other=20 > >>> methods. > >>> So I don't see restrictions for deployments in this case.=20 > >>> > >>>> W.r.t this below scenario, the reason for LMA to return its > >>> timestamp, > >>>> solves two purposes. 1.) Diagnostics (especially useful > >> when the LMA > >>>> and MAG are in different admin domains) 2.) The MAG can > >> detect that > >>>> its clock is not in sync and take the necessary actions.=20 > I guess,=20 > >>>> Frederico has an issue with the second part. But, if you > >> look at the > >>>> recommendation from the draft on handling this error case, MAG=20 > >>>> signaling considerations, > >>>> > >>>> "If the received Proxy Binding Acknowledgement > >> message has the > >>>> Status field value set to TIMESTAMP_MISMATCH (Invalid=20 > >>>> Timestamp), > >>>> the mobile access gateway SHOULD try to register=20 > again only=20 > >>>> after > >>>> it synchronized its clock with the local mobility anchor's=20 > >>>> system > >>>> clock or to a common time source that is used by > >> all mobility > >>>> entities in that domain for their clock synchronization." > >>>> > >>> I think it is good if the LMA informs the MAG about=20 > detected out of=20 > >>> sync clocks for the purpose of diagnostics and as a trigger for=20 > >>> re-sync. But why do we need the timestamp option in the PBA? The=20 > >>> TIMESTAMP_MISMATCH value in the status field is enough for > >> the purpose > >>> of diagnostics and as a trigger for re-sync. > >>> > >>>> So, we are not really using the LMA as the time source.=20 > >>> Now, with the > >>>> given assumptions, do you see an issue if we dont say NTP > >> is a MUST, > >>>> but we say clock synch is a requirement, how they do it, > >> draft does > >>>> not say. If this requirement is not met, its an incorrect > >> usage of > >>>> the protocol and the PBU ordering will fail in that special rare=20 > >>>> reordering scenario (IMO, its not a practical issue). > >>> see above > >>> > >>> BR, > >>> > >>> Kilian > >>> > >>>> The second question to this discussion, is Alex's point of not=20 > >>>> mandating Timestamp option as a MUST implement. For this, > >>> as I stated > >>>> before, this is few lines of code for supporting this > >> option and if > >>>> seq number scheme is in use, this need not be used at > >> all. We need > >>>> to mandate this as there is no CT in the base spec. But, > >> this is not > >>>> a > >>> big issue > >>>> either way. If others agree, I'm fine not mandating this.=20 > >>>> But, I really > >>>> believe, implementations can support this option, at the > >> least cost. > >>>> One last comment on the trust on LMA's clock for the sanity > >>> check, is > >>>> because its an anchor point and its typically well > >> managed, compared > >>>> to MAG's, where they are scattered out. So, its > >> reasonable to expect > >>>> the clock on the LMA to be in sync, else all > >> registrations will fail > >>>> and will generate the traps. > >>>> > >>>> So, let me know your comments on how we can move forward. > >>>> > >>>> > >>>> Sri > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> 1. If a MAG's clock is out of sync (i.e., not yet synced by=20 > >>>>> receiving a PBA with timestamp) AND PBUs sent by this MAG are=20 > >>>>> delayed, > >>>> the out of > >>>>> sync situation may not be detectable by the LMA and old > >>> PBUs may be > >>>>> accepted by the LMA.=20 > >>>>> > >>>>> Consider the following example: MN attaches to MAG1 and shortly=20 > >>>>> thereafter hands over to MAG2. MAG2's clock is in sync > >> with LMA's > >>>>> clock, but MAG1's clock is out of sync and is ahead of > >> LMA's clock > >>>>> by 5 seconds. MAG1-LMA link is highly congested. When MN > >>>> attaches to MAG1, > >>>>> MAG1 sends PBU1 msg to LMA. This happens 3 seconds before > >>>> the MN hands > >>>>> over to MAG2. The PBU1 msg is delayed by 5 seconds due to the=20 > >>>>> congestion and hence arrives at LMA 2 seconds after handover. > >>>>> Despite of the delay, > >>>>> PBU1 has a valid timestamp from LMA's point of view due > >>> to the wrong > >>>>> clock of MAG1. MAG2 sends a PBU2 msg 1 second after > >>>> handover. PBU2 is > >>>>> not significantly delayed and arrives at LMA ~1 seconds > >>>> after handover > >>>>> with valid timestamp. In this scenario, the LMA will wrongly=20 > >>>>> accept PBU1 arriving after PBU2, since both have a valid=20 > >>>>> timestamp. > >>>> Consequently, > >>>>> the LMA forwards packets to the wrong MAG (MAG1) and will not=20 > >>>>> notice the out of sync of MAG1, which also means that the LMA > >>> doesn't return a > >>>>> timestamp in the PBA and MAG1's clock keeps to be out of sync. > >>>>> > >>>>> 2. When packets on the link between MAG and LMA > >>> experience high (and > >>>>> varying) packet delays (e.g., due to congestion), the > >>>> timestamp in the > >>>>> PBA returned by the LMA may already be outdated at the time > >>>> it arrives > >>>>> at the MAG. So exactly in the situation where a re-ordering > >>>> of PBUs is > >>>>> needed, the synchronization mechanism may fail. > >>>>> > >>>>> My two cents. > >>>>> > >>>>> BR, > >>>>> > >>>>> Kilian > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >>>>>> Sent: Freitag, 7. September 2007 18:48 > >>>>>> To: 'Kilian Weniger' > >>>>>> Cc: netlmm@ietf.org > >>>>>> Subject: RE: [netlmm] timestamp vs seqno redux > >>>>>> > >>>>>> Hi Kilian, > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Kilian Weniger > >> [mailto:Kilian.Weniger@eu.panasonic.com] > >>>>>>> Sent: Friday, September 07, 2007 2:09 AM > >>>>>>> To: Sri Gundavelli > >>>>>>> Cc: netlmm@ietf.org > >>>>>>> Subject: RE: [netlmm] timestamp vs seqno redux > >>>>>>> > >>>>>>> Hi Sri, > >>>>>>> > >>>>>>>> - We are NOT mandating the nodes in the domain to > >> sync up to > >>>>>>>> a clock source. > >>>>>>> Hmm, so far I assumed that the proposal is to mandate the > >>>>>> MAGs to sync > >>>>>>> up to an external clock source such as NTP server. > >>>>>>> > >>>>>> For the timestamp option to work, we RECOMMEND the use > >>> of NTP for > >>>>>> synchronizing the clocks in the domain. However, we do > >>> not want to > >>>>>> mandate on a specific mechanism.=20 > >>>>>> > >>>>>> > >>>>>>>> Base draft does not support Context Transfers. Given that > >>>>>> the draft > >>>>>>>> will be incomplete, if we dont mandate the support.=20 > >>>> By mandating > >>>>>>>> the support, the LMA can always return its timestamp > >>>> and the MAG > >>>>>>>> can use that timestamp and register. This need to > >>> be done just > >>>>>>>> once whenever the LMA/MAG clocks are out of sync and > >>>>> just for one > >>>>>>>> registration. One extra round trip for the 1st > >>>>>> registration between > >>>>>>>> LMA/MAG pair. > >>>>>>> So the proposal is to allow the use of the timestamp > >>>> option in the > >>>>>>> absence of any external time synchronization like NTP and > >>>>>> to mandate a > >>>>>>> mechanism to synchronize clocks between MAGs and LMA=20 > (and hence=20 > >>>>>>> between all MAGs) using the timestamp option > >> in PBU/PBA > >>>>>>> only > >>>>> (i.e., without > >>>>>>> utilizing NTP or an external clock source)? Is my=20 > understanding=20 > >>>>>>> correct? > >>>>>>> > >>>>>> No. For this to work, we require the clocks to be in sync. > >>>>>> How its achieved, it could be based on NTP or some other > >>>> protocols. > >>>>>> But, why should we mandate this. > >>>>>> > >>>>>> > >>>>>>> If so, can you please give some more details how > >> the LMA can > >>>>>>> detect that the clocks are out of sync? Is it based=20 > on a certain > >>>> difference of > >>>>>>> timestamp in the received PBU and the current LMA's time?=20 > >>>>>>> > >>>>>>> And how to differentiate the out of sync case from the > >>>>> out-of-order > >>>>>>> delivery case (i.e., a PBU is delayed and overtaken > >> by another > >>>>>>> PBU from another MAG)? For instance, if the LMA > >> receives a PBU > >>>>> with timestamp > >>>>>>> equal to "current time of LMA - X" and X > threshold, how > >>>>>> does the LMA > >>>>>>> know whether the > >>>>>>> 1. the MAG clock is synchronized, but the PBU got > >>>> delayed by X or > >>>>>>> 2. the PBU is not delayed, but the MAG's clock is out of > >>>>> sync by X? > >>>>>>> Ideally, in case 1 the LMA should just ignore the PBU, in > >>>>> case 2 it > >>>>>>> should accept it and sync clocks. > >>>>>>> > >>>>>>> If the idea is to always reject a PBU with X > threshold > >>>>>> and include a > >>>>>>> current timestamp in the PBA, then I guess the same could > >>>>>> be done with > >>>>>>> sequence numbers instead of timestamps, right? > >>>>>>> > >>>>>> For what ever reasons if the LMA and MAG clocks are out > >>>> of sync, the > >>>>>> LMA can return its timestamp and the MAG can always apply > >>>> that delta > >>>>>> in all the registration it sends. This is done just once, > >>>> when ever > >>>>>> the clocks are off. But, with seq number scheme, this needs > >>>>> to be done > >>>>>> for each MN registration. Its as per the 3775 per MN > >> seq number. > >>>>>> Sri > >>>>>> > >>>>>>> BR, > >>>>>>> > >>>>>>> Kilian > >>>>>>> > >>>>>>> > >>>>>>> Panasonic R&D Center Germany GmbH > >>>>>>> 63225 Langen, Hessen, Germany > >>>>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing > >> Director: Thomas > >>>>>>> Micke > >>>>>> > >>>>> > >>>>> Panasonic R&D Center Germany GmbH > >>>>> 63225 Langen, Hessen, Germany > >>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > >>>>> Micke > >>>> > >>> > >>> Panasonic R&D Center Germany GmbH > >>> 63225 Langen, Hessen, Germany > >>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director:=20 > Thomas Micke > >>> > >>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 09:51:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVp6o-00083V-3H; Thu, 13 Sep 2007 09:51:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVp6n-00083Q-Pg for netlmm@ietf.org; Thu, 13 Sep 2007 09:51:53 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVp6n-00069j-5K for netlmm@ietf.org; Thu, 13 Sep 2007 09:51:53 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1189691511!1312654!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5691 invoked from network); 13 Sep 2007 13:51:51 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 13 Sep 2007 13:51:51 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8DDpppm027928; Thu, 13 Sep 2007 06:51:51 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l8DDpoX0026348; Thu, 13 Sep 2007 08:51:51 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8DDpmbL026259; Thu, 13 Sep 2007 08:51:49 -0500 (CDT) Message-ID: <46E9406E.2080204@gmail.com> Date: Thu, 13 Sep 2007 15:51:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F93@zrc2hxm2.corp.nortel.com> <46E9354A.3030303@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A06E@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B4A06E@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Okay, > > Then you assume that the MAG will not send any other P-BU for any other > MN in 10 minutes. That is possible. However, reality is a little > different than that. On the other hand, let us argue to the extreme that > you are right. MAG is not sending any other P-BU for 10 minutes and the > network state has changed. What the consequences. 2 round trips right? > > The idea here, how often that should happen? Ahmad, thanks for assuming that idea along my own thoughts, and agreeing that it might lead to something undesirable. It's true that if it requires 2 round trips every 10minutes then it's not much an overload. I've used the same argumentation previously for saying that maybe 2 round trips now and then for seqno at first attachment is not that much an overload. Let's say that the requirement is to ensure ordering of P-BUs at LMA _without_ extraneous P-BU/P-BAck roundtrips. Then we can only do this: (1) do seqno stuff at the shadowy AAA phase xor (2) rely on NTP/GPS/GSM for time synchronizaion. I think doing only timestamps without NTP/GSM/GPS synchronization doesn't save us the risk of extraneous roundtrips. I also think doing both timestamps+seqnos doesn't save us the same risk. I also think reusing the timestamps from DNA/SeND doesn't save us the risk of sometimes running two round trips. Alex PS: if we change the requirement to allow for a three-way handshake (still forbid 2 round trips) then the solutions change again. > > Regards, > Ahmad > > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Thursday, September 13, 2007 8:04 AM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: Alexandru Petrescu; Kilian Weniger; Sri Gundavelli; DE >> JUAN HUARTE FEDERICO; netlmm@ietf.org >> Subject: Re: [netlmm] timestamp vs seqno redux >> >> Ahmad Muhanna wrote: >>>> Subject: Re: [netlmm] timestamp vs seqno redux >>>> >>>> Ahmad Muhanna wrote: >>>>>> Subject: Re: [netlmm] timestamp vs seqno redux >>>>>> >>>>>> Ahmad Muhanna wrote: >>>>>>> Hi Alex, >>>>>>> >>>>>>> No it does not have an effect on the calculation. >>>>>> So why do you mention it as an assumption? >>>>> [Ahmad] >>>>> It is an over sight on my part. Sorry for the confusion. >>>> Ahmad, I think any assumption on a constant delay of the >> network is >>>> wrong, be it symmetric or asymmetric. You do a >> measurement now and >>>> ten minutes later the delays are different because somebody else >>>> loads the network. >>>> >>>> You do 10 measurements in a burst and you get different times, >>>> eventually with a Gaussian distribution. That's the first >> experience >>>> with ping. >>> [Ahmad] >>> Alex, There is no assumption about a constant delay? >>> This is just used for a snap shot analysis to prove the concept is >>> valid. That is all. >> What makes you think that the situation is the same when you >> make your snapshot and 10minutes later? >> >>> If the network condition changes, the concept still valid >> and should >>> adjust itself and work. NO? >> Don't you assume that when network conditions change a new >> measurement is necessary? How do you know when network >> conditions change? >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 09:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVp7z-0001nM-3g; Thu, 13 Sep 2007 09:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVp7y-0001nB-B5 for netlmm@ietf.org; Thu, 13 Sep 2007 09:53:06 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVp7x-0005EZ-4d for netlmm@ietf.org; Thu, 13 Sep 2007 09:53:06 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8DDob624878; Thu, 13 Sep 2007 13:50:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 08:52:53 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B4A102@zrc2hxm2.corp.nortel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2BJvgsBJkra0vSKqac8wYWVd2XAAAHRvgAAHkdQA= References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" , "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Please see inline. Regards, Ahmad =20 > Subject: RE: [netlmm] timestamp vs seqno redux >=20 > Alexandru Petrescu wrote: > > Ahmad, I think any assumption on a constant delay of the network is=20 > > wrong, be it symmetric or asymmetric. You do a measurement now and=20 > > ten minutes later the delays are different because somebody=20 > else loads=20 > > the network. > >=20 > > You do 10 measurements in a burst and you get different times,=20 > > eventually with a Gaussian distribution. That's the first=20 > experience=20 > > with ping. > >=20 >=20 > Right, that's why NTP requires several packet exchanges with=20 > sophisticated statistical calculations. From > http://www.ntp.org/ntpfaq/NTP-s-algo.htm: >=20 [Ahmad] And that why NTP needs a whole different protocol and different equipment and everything else in between. And let me say some $$$$ CASH. Right? Please let us take this in prospective. If the group agree to mandate NTP time synchronization, we do not need to go through all of this and we could have save plenty of man hours for all of us. Reality is a little different and timestamp is used per other signaling protocols in other IETF standards. Nothing new here. > "Time is not believed until several packet exchanges have=20 > taken place, each passing a set of sanity checks. Only if the=20 > replies from a server satisfy the conditions defined in the=20 > protocol specification, the server is considered valid. Time=20 > cannot be synchronized from a server that is considered=20 > invalid by the protocol. Some essential values are put into=20 > multi-stage filters for statistical purposes to improve and=20 > estimate the quality of the samples from each server." [Ahmad] As long as the proposed mechanism works for ordering P-BU/P-BA, then that should be fine. >=20 > BR, >=20 > Kilian >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 10:32:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVpkV-0000WU-6g; Thu, 13 Sep 2007 10:32:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVpkT-0000WJ-7o for netlmm@ietf.org; Thu, 13 Sep 2007 10:32:53 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVpkR-00067z-Uq for netlmm@ietf.org; Thu, 13 Sep 2007 10:32:53 -0400 X-IronPort-AV: E=Sophos;i="4.20,250,1186383600"; d="scan'208";a="523568499" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 13 Sep 2007 07:32:52 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8DEWpoX031152; Thu, 13 Sep 2007 07:32:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8DEWkF6019716; Thu, 13 Sep 2007 14:32:51 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 07:32:19 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 07:32:18 -0700 From: "Sri Gundavelli" To: "'Julien Laganier'" , References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> <200709131010.48638.julien.IETF@laposte.net> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Thu, 13 Sep 2007 07:32:17 -0700 Message-ID: <016f01c7f612$e36aa5d0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <200709131010.48638.julien.IETF@laposte.net> Thread-Index: Acf13aPqb8aDcLQ2SPyQtElJXW59vQANIgJg X-OriginalArrivalTime: 13 Sep 2007 14:32:19.0287 (UTC) FILETIME=[E3ABA670:01C7F612] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2607; t=1189693971; x=1190557971; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-proxymip6 -04.txt |Sender:=20; bh=v4yt4MWvupjRJHEeLJPU0D2wzYnQHUe/RfggV2CYJ1I=; b=EeWW4/P1uqLLUxYvzBihTyScSYBygoDs2CcpELoSs1Zxr5lMord4uXMOWT7i2BgCIDJNsMZ5 OmE/qgOieu+jzLvoDtuAjuCvwX8+X/4VAnr9AV3pC9weApTf/w2t1v3Z; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien,=20 > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On=20 > Behalf Of Julien Laganier > Sent: Thursday, September 13, 2007 1:11 AM > To: netlmm@ietf.org > Cc: Premec, Domagoj; Sri Gundavelli > Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt >=20 > Hi Domagoj, >=20 > I disagree with one of your comment below: >=20 > On Wednesday 12 September 2007, Premec, Domagoj wrote: > > >6.3. =A0Supported Access Link Types > > > > > > =A0 This specification supports only point-to-point access=20 > link types > > > and thus it assumes that the mobile node and the mobile access > > > gateway are the only two nodes on the access link. =A0The link is > > > assumed to have multicast capability. > > > > I understand that the decision to use per-MN prefix model was > > motivated by the need to emulate the point-to-point link at the IP > > layer.=20 >=20 > Not true.=20 >=20 > Use of a per-MN prefix model has been motivated by the need to avoid=20 > multilink subnet issues [RFC4903]. >=20 > Following that prefix model choice, we have discussed at=20 > length on that=20 > mailing list what are the implication of that model on the supported=20 > underlying link (i.e. below IP). The per-MN prefix on a pt-to-pt link=20 > has no issue. It is not clear however if it would work well=20 > on a shared=20 > link. The consensus of the WG has been that the current spec will be=20 > limited to support of pt-to-pt links. >=20 > Support for shared link can be added later in another specification. >=20 > > As the IP layer is configured in such a way that there are=20 > > exactly two nodes on the link, we're actually independet of the > > underlaying link layer technology.=20 >=20 > No configuration of the IP layer can restrict the number of=20 > nodes on a=20 > link. The link properties are independent from those of the IP layer. >=20 > > I think the intent of the spec is to support any access link type, > > including for example 802.11.=20 >=20 > I think the intent of the spec is to support only pt-to-pt=20 > links for now=20 > since that's the only type of link where the per-MN prefix=20 > model has no=20 > known issues. >=20 May be I misunderstood what Domagoj comment. My point is that we do allow access links such as 802.11, as long as the p2p requirement is met from L3 perspective, implies, there are only two nodes on the access link. A multicast RA sent by the MAG is received just by one node, as long as the link meets this requirement we are ok.=20 Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 10:33:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVplW-00015W-4H; Thu, 13 Sep 2007 10:33:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVplU-00015R-TL for netlmm@ietf.org; Thu, 13 Sep 2007 10:33:56 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVplU-00076m-Eg for netlmm@ietf.org; Thu, 13 Sep 2007 10:33:56 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1189694032!17434760!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1070 invoked from network); 13 Sep 2007 14:33:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 13 Sep 2007 14:33:52 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8DEXq6b010938; Thu, 13 Sep 2007 07:33:52 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l8DEXpeF022257; Thu, 13 Sep 2007 09:33:51 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l8DEXnL0022237; Thu, 13 Sep 2007 09:33:50 -0500 (CDT) Message-ID: <46E94A49.7000108@gmail.com> Date: Thu, 13 Sep 2007 16:33:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A102@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B4A102@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Hi Kilian, > > Please see inline. > > Regards, > Ahmad > > >> Subject: RE: [netlmm] timestamp vs seqno redux >> >> Alexandru Petrescu wrote: >>> Ahmad, I think any assumption on a constant delay of the network is >>> wrong, be it symmetric or asymmetric. You do a measurement now and >>> ten minutes later the delays are different because somebody >> else loads >>> the network. >>> >>> You do 10 measurements in a burst and you get different times, >>> eventually with a Gaussian distribution. That's the first >> experience >>> with ping. >>> >> Right, that's why NTP requires several packet exchanges with >> sophisticated statistical calculations. From >> http://www.ntp.org/ntpfaq/NTP-s-algo.htm: >> > > [Ahmad] > And that why NTP needs a whole different protocol and different > equipment and everything else in between. And let me say some $$$$ CASH. > Right? Please let us take this in prospective. If the group agree to > mandate NTP time synchronization, we do not need to go through all of > this and we could have save plenty of man hours for all of us. Reality > is a little different and timestamp is used per other signaling > protocols in other IETF standards. Nothing new here. Which ones other than SEND and MIP4? In both it's used for replay protection, not ordered delivery of messages. Take other routing protocols OSPF and BGP and there's no timestamps transmitted in messages. I think there's no other IETF protocol that uses timestamps in messages in order to ensure ordered delivery of messages. Alex >> "Time is not believed until several packet exchanges have >> taken place, each passing a set of sanity checks. Only if the >> replies from a server satisfy the conditions defined in the >> protocol specification, the server is considered valid. Time >> cannot be synchronized from a server that is considered >> invalid by the protocol. Some essential values are put into >> multi-stage filters for statistical purposes to improve and >> estimate the quality of the samples from each server." > > [Ahmad] > As long as the proposed mechanism works for ordering P-BU/P-BA, then > that should be fine. > >> BR, >> >> Kilian >> >> >> Panasonic R&D Center Germany GmbH >> 63225 Langen, Hessen, Germany >> Reg: AG Offenbach (Hessen) HRB 33974 >> Managing Director: Thomas Micke >> >> >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 10:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVpmj-0001pP-Mn; Thu, 13 Sep 2007 10:35:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVpmi-0001pK-R1 for netlmm@ietf.org; Thu, 13 Sep 2007 10:35:12 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVpmi-00078Z-8I for netlmm@ietf.org; Thu, 13 Sep 2007 10:35:12 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DEYw529425; Thu, 13 Sep 2007 14:34:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 09:34:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B9A364@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E9406E.2080204@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2DU/edFPUa30VTFCB9/ADlytMLQABGxzg References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F93@zrc2hxm2.corp.nortel.com> <46E9354A.3030303@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A06E@zrc2hxm2.corp.nortel.com> <46E9406E.2080204@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > > Okay, > >=20 > > Then you assume that the MAG will not send any other P-BU for any=20 > > other MN in 10 minutes. That is possible. However, reality=20 > is a little=20 > > different than that. On the other hand, let us argue to the extreme=20 > > that you are right. MAG is not sending any other P-BU for=20 > 10 minutes=20 > > and the network state has changed. What the consequences. 2=20 > round trips right? > >=20 > > The idea here, how often that should happen? >=20 > Ahmad, thanks for assuming that idea along my own thoughts,=20 > and agreeing > that it might lead to something undesirable. >=20 > It's true that if it requires 2 round trips every 10minutes=20 > then it's not much an overload. >=20 > I've used the same argumentation previously for saying that=20 > maybe 2 round trips now and then for seqno at first=20 > attachment is not that much an overload. >=20 > Let's say that the requirement is to ensure ordering of P-BUs=20 > at LMA _without_ extraneous P-BU/P-BAck roundtrips. Then we=20 > can only do this:=20 > (1) do seqno stuff at the shadowy AAA phase xor (2) rely on=20 > NTP/GPS/GSM for time synchronizaion. [Ahmad] I am not sure about the shadowy AAA phase does. Without understanding the details this for me is undefined. >=20 > I think doing only timestamps without NTP/GSM/GPS=20 > synchronization doesn't save us the risk of extraneous=20 > roundtrips. =20 [Ahmad] True. However, I do not believe that it is as bad as using SQN without synchronization. I hope you agree.=20 > I also think doing both timestamps+seqnos=20 > doesn't save us the same risk. I also think reusing the=20 > timestamps from DNA/SeND doesn't save us the risk of=20 > sometimes running two round trips. >=20 > Alex > PS: if we change the requirement to allow for a three-way handshake > (still forbid 2 round trips) then the solutions change again. [Ahmad] I do not think there is currently a mechanism to enable this three-way handshake in MIPv6 or PMIPv6.=20 > >=20 > > Regards, > > Ahmad > > =20 > >=20 > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Thursday, September 13, 2007 8:04 AM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: Alexandru Petrescu; Kilian Weniger; Sri Gundavelli; DE JUAN=20 > >> HUARTE FEDERICO; netlmm@ietf.org > >> Subject: Re: [netlmm] timestamp vs seqno redux > >> > >> Ahmad Muhanna wrote: > >>>> Subject: Re: [netlmm] timestamp vs seqno redux > >>>> > >>>> Ahmad Muhanna wrote: > >>>>>> Subject: Re: [netlmm] timestamp vs seqno redux > >>>>>> > >>>>>> Ahmad Muhanna wrote: > >>>>>>> Hi Alex, > >>>>>>> > >>>>>>> No it does not have an effect on the calculation. > >>>>>> So why do you mention it as an assumption? > >>>>> [Ahmad] > >>>>> It is an over sight on my part. Sorry for the confusion. > >>>> Ahmad, I think any assumption on a constant delay of the > >> network is > >>>> wrong, be it symmetric or asymmetric. You do a > >> measurement now and > >>>> ten minutes later the delays are different because somebody else=20 > >>>> loads the network. > >>>> > >>>> You do 10 measurements in a burst and you get different times,=20 > >>>> eventually with a Gaussian distribution. That's the first > >> experience > >>>> with ping. > >>> [Ahmad] > >>> Alex, There is no assumption about a constant delay? > >>> This is just used for a snap shot analysis to prove the=20 > concept is=20 > >>> valid. That is all. > >> What makes you think that the situation is the same when you make=20 > >> your snapshot and 10minutes later? > >> > >>> If the network condition changes, the concept still valid > >> and should > >>> adjust itself and work. NO? > >> Don't you assume that when network conditions change a new=20 > >> measurement is necessary? How do you know when network conditions=20 > >> change? > >> > >> Alex > >> > >> > >>=20 > _____________________________________________________________________ > >> _ This email has been scanned by the MessageLabs Email Security=20 > >> System. > >> For more information please visit > >> http://www.messagelabs.com/email > >>=20 > _____________________________________________________________________ > >> _ > >> > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 10:50:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVq1M-0002xb-0n; Thu, 13 Sep 2007 10:50:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVq1K-0002xW-RZ for netlmm@ietf.org; Thu, 13 Sep 2007 10:50:18 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVq1K-0007Vt-8Z for netlmm@ietf.org; Thu, 13 Sep 2007 10:50:18 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DEo9502684; Thu, 13 Sep 2007 14:50:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 09:50:08 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B9A418@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E94A49.7000108@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2EyGm5tDX1xN4TSOhZKECAyfw9wAAYg5A References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A102@zrc2hxm2.corp.nortel.com> <46E94A49.7000108@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > >> > >=20 > > [Ahmad] > > And that why NTP needs a whole different protocol and different=20 > > equipment and everything else in between. And let me say=20 > some $$$$ CASH. > > Right? Please let us take this in prospective. If the group=20 > agree to=20 > > mandate NTP time synchronization, we do not need to go=20 > through all of=20 > > this and we could have save plenty of man hours for all of=20 > us. Reality=20 > > is a little different and timestamp is used per other signaling=20 > > protocols in other IETF standards. Nothing new here. >=20 > Which ones other than SEND and MIP4? In both it's used for=20 > replay protection, not ordered delivery of messages. [Ahmad] Let us talk about MIPv4. I understand that MIPv4 use timestamp for replay protection, but you are saying that does not guarantee ordering? In other words, are you saying that the HA will accept an out of order packets? For example: RRQ(t1-d1) can be accepted if HA already has already accepted another RRQ with timestamp (t1)? >=20 > Take other routing protocols OSPF and BGP and there's no=20 > timestamps transmitted in messages. >=20 > I think there's no other IETF protocol that uses timestamps=20 > in messages in order to ensure ordered delivery of messages. >=20 > Alex >=20 > >> "Time is not believed until several packet exchanges have taken=20 > >> place, each passing a set of sanity checks. Only if the=20 > replies from=20 > >> a server satisfy the conditions defined in the protocol=20 > >> specification, the server is considered valid. Time cannot be=20 > >> synchronized from a server that is considered invalid by the=20 > >> protocol. Some essential values are put into multi-stage=20 > filters for=20 > >> statistical purposes to improve and estimate the quality of the=20 > >> samples from each server." > >=20 > > [Ahmad] > > As long as the proposed mechanism works for ordering=20 > P-BU/P-BA, then=20 > > that should be fine. > >=20 > >> BR, > >> > >> Kilian > >> > >> > >> Panasonic R&D Center Germany GmbH > >> 63225 Langen, Hessen, Germany > >> Reg: AG Offenbach (Hessen) HRB 33974 > >> Managing Director: Thomas Micke > >> > >> > >> > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 10:56:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVq7Z-00065t-Tu; Thu, 13 Sep 2007 10:56:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVq7Y-00065o-QG for netlmm@ietf.org; Thu, 13 Sep 2007 10:56:44 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVq7X-0006YA-Ez for netlmm@ietf.org; Thu, 13 Sep 2007 10:56:44 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1189695401!4187566!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29290 invoked from network); 13 Sep 2007 14:56:42 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 13 Sep 2007 14:56:42 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8DEufe1017899; Thu, 13 Sep 2007 07:56:41 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8DEufGr010019; Thu, 13 Sep 2007 09:56:41 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8DEuc1S009999; Thu, 13 Sep 2007 09:56:39 -0500 (CDT) Message-ID: <46E94FA5.3070302@gmail.com> Date: Thu, 13 Sep 2007 16:56:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F93@zrc2hxm2.corp.nortel.com> <46E9354A.3030303@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A06E@zrc2hxm2.corp.nortel.com> <46E9406E.2080204@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A364@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B9A364@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: >> Subject: Re: [netlmm] timestamp vs seqno redux >> >> Ahmad Muhanna wrote: >>> Okay, >>> >>> Then you assume that the MAG will not send any other P-BU for any >>> other MN in 10 minutes. That is possible. However, reality >> is a little >>> different than that. On the other hand, let us argue to the >>> extreme that you are right. MAG is not sending any other P-BU for >>> >> 10 minutes >>> and the network state has changed. What the consequences. 2 >> round trips right? >>> The idea here, how often that should happen? >> Ahmad, thanks for assuming that idea along my own thoughts, and >> agreeing that it might lead to something undesirable. >> >> It's true that if it requires 2 round trips every 10minutes then >> it's not much an overload. >> >> I've used the same argumentation previously for saying that maybe 2 >> round trips now and then for seqno at first attachment is not that >> much an overload. >> >> Let's say that the requirement is to ensure ordering of P-BUs at >> LMA _without_ extraneous P-BU/P-BAck roundtrips. Then we can only >> do this: (1) do seqno stuff at the shadowy AAA phase xor (2) rely >> on NTP/GPS/GSM for time synchronizaion. > > [Ahmad] I am not sure about the shadowy AAA phase does. Without > understanding the details this for me is undefined. I am not sure either. However, without it the MAG can not send the P-BUs on behalf of MN. If I knew what it does and how it works then I could say how it distributes the seqno as well. >> I think doing only timestamps without NTP/GSM/GPS synchronization >> doesn't save us the risk of extraneous roundtrips. > > [Ahmad] True. However, I do not believe that it is as bad as using > SQN without synchronization. I hope you agree. No :-) >> I also think doing both timestamps+seqnos doesn't save us the same >> risk. I also think reusing the timestamps from DNA/SeND doesn't >> save us the risk of sometimes running two round trips. >> >> Alex PS: if we change the requirement to allow for a three-way >> handshake (still forbid 2 round trips) then the solutions change >> again. > > [Ahmad] I do not think there is currently a mechanism to enable this > three-way handshake in MIPv6 or PMIPv6. Right, there isn't. And there are many things in PMIPv6 that aren't in MIP6 either: reliance on timestamps and timesync, HNP in PBack, reliance on AAA, reliance on prefix-per-MN - to name a few. You were talking about money and dollars: how much does it cost to upgrade the MIP6 HA software to PMIPv6? how much does it cost to have all entities time synchronized? I'm sure one could reuse much more of MIP6 than that. Alex > >>> Regards, Ahmad >>> >>> >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, September >>>> 13, 2007 8:04 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: Alexandru >>>> Petrescu; Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE >>>> FEDERICO; netlmm@ietf.org Subject: Re: [netlmm] timestamp vs >>>> seqno redux >>>> >>>> Ahmad Muhanna wrote: >>>>>> Subject: Re: [netlmm] timestamp vs seqno redux >>>>>> >>>>>> Ahmad Muhanna wrote: >>>>>>>> Subject: Re: [netlmm] timestamp vs seqno redux >>>>>>>> >>>>>>>> Ahmad Muhanna wrote: >>>>>>>>> Hi Alex, >>>>>>>>> >>>>>>>>> No it does not have an effect on the calculation. >>>>>>>> So why do you mention it as an assumption? >>>>>>> [Ahmad] It is an over sight on my part. Sorry for the >>>>>>> confusion. >>>>>> Ahmad, I think any assumption on a constant delay of the >>>> network is >>>>>> wrong, be it symmetric or asymmetric. You do a >>>> measurement now and >>>>>> ten minutes later the delays are different because somebody >>>>>> else loads the network. >>>>>> >>>>>> You do 10 measurements in a burst and you get different >>>>>> times, eventually with a Gaussian distribution. That's the >>>>>> first >>>> experience >>>>>> with ping. >>>>> [Ahmad] Alex, There is no assumption about a constant delay? >>>>> This is just used for a snap shot analysis to prove the >> concept is >>>>> valid. That is all. >>>> What makes you think that the situation is the same when you >>>> make your snapshot and 10minutes later? >>>> >>>>> If the network condition changes, the concept still valid >>>> and should >>>>> adjust itself and work. NO? >>>> Don't you assume that when network conditions change a new >>>> measurement is necessary? How do you know when network >>>> conditions change? >>>> >>>> Alex >>>> >>>> >>>> >> _____________________________________________________________________ >> >>>> _ This email has been scanned by the MessageLabs Email Security >>>> System. For more information please visit >>>> http://www.messagelabs.com/email >>>> >> _____________________________________________________________________ >> >>>> _ >>>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 11:01:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqCJ-0002kU-MN; Thu, 13 Sep 2007 11:01:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqCI-0002kO-6I for netlmm@ietf.org; Thu, 13 Sep 2007 11:01:38 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVqCH-0006dt-1C for netlmm@ietf.org; Thu, 13 Sep 2007 11:01:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1189695695!19588418!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 23719 invoked from network); 13 Sep 2007 15:01:35 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-2.tower-119.messagelabs.com with SMTP; 13 Sep 2007 15:01:35 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8DF1YMl027409; Thu, 13 Sep 2007 08:01:34 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8DF1XUk000604; Thu, 13 Sep 2007 10:01:33 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8DF1TV5000525; Thu, 13 Sep 2007 10:01:30 -0500 (CDT) Message-ID: <46E950C8.9080408@gmail.com> Date: Thu, 13 Sep 2007 17:01:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A102@zrc2hxm2.corp.nortel.com> <46E94A49.7000108@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A418@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B9A418@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: >>> [Ahmad] >>> And that why NTP needs a whole different protocol and different >>> equipment and everything else in between. And let me say >> some $$$$ CASH. >>> Right? Please let us take this in prospective. If the group >> agree to >>> mandate NTP time synchronization, we do not need to go >> through all of >>> this and we could have save plenty of man hours for all of >> us. Reality >>> is a little different and timestamp is used per other signaling >>> protocols in other IETF standards. Nothing new here. >> Which ones other than SEND and MIP4? In both it's used for >> replay protection, not ordered delivery of messages. > > [Ahmad] > Let us talk about MIPv4. I understand that MIPv4 use timestamp for > replay protection, but you are saying that does not guarantee ordering? Good question. I can say that my mip4 implementation doesn't rely on MN and HA be time synched and MIP4 messages are ordered. But it's prototype. (it's not "my" implementation, it has its open source origins as you may be aware). > In other words, are you saying that the HA will accept an out of order > packets? In extreme conditions, my implementation - yes. Its problem is not packets being disordered, but security: another MN sending RegReq for the victim MN's Home Address. And I plan to solve security by using IPsec encapsulated UDP. > For example: RRQ(t1-d1) can be accepted if HA already has already > accepted another RRQ with timestamp (t1)? YEs, it can. And it has problems - security problems, not ordering problems. Alex >> Take other routing protocols OSPF and BGP and there's no >> timestamps transmitted in messages. >> >> I think there's no other IETF protocol that uses timestamps >> in messages in order to ensure ordered delivery of messages. >> >> Alex >> >>>> "Time is not believed until several packet exchanges have taken >>>> place, each passing a set of sanity checks. Only if the >> replies from >>>> a server satisfy the conditions defined in the protocol >>>> specification, the server is considered valid. Time cannot be >>>> synchronized from a server that is considered invalid by the >>>> protocol. Some essential values are put into multi-stage >> filters for >>>> statistical purposes to improve and estimate the quality of the >>>> samples from each server." >>> [Ahmad] >>> As long as the proposed mechanism works for ordering >> P-BU/P-BA, then >>> that should be fine. >>> >>>> BR, >>>> >>>> Kilian >>>> >>>> >>>> Panasonic R&D Center Germany GmbH >>>> 63225 Langen, Hessen, Germany >>>> Reg: AG Offenbach (Hessen) HRB 33974 >>>> Managing Director: Thomas Micke >>>> >>>> >>>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 11:08:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqJO-0000LA-Dy; Thu, 13 Sep 2007 11:08:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqJN-0000Kz-HH for netlmm@ietf.org; Thu, 13 Sep 2007 11:08:57 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVqJM-0006oP-BM for netlmm@ietf.org; Thu, 13 Sep 2007 11:08:57 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DF8m519963; Thu, 13 Sep 2007 15:08:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 10:08:32 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B9A4E2@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E950C8.9080408@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2Fv+kEE+z25u4RBm0POzhjA2VEgAAEgXQ References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A102@zrc2hxm2.corp.nortel.com> <46E94A49.7000108@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A418@zrc2hxm2.corp.nortel.com> <46E950C8.9080408@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex, You can call it security or whatever, it is part of the MIP4 replay protection which guarantees ordering. If you would like to use IPsec with MIP4 that is fine, but, then you may as well forget about MIPv4 replay protection because that is supposedly handled by IPsec too. Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Thursday, September 13, 2007 10:01 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Alexandru Petrescu; Kilian Weniger; Sri Gundavelli; DE=20 > JUAN HUARTE FEDERICO; netlmm@ietf.org > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > >>> [Ahmad] > >>> And that why NTP needs a whole different protocol and different=20 > >>> equipment and everything else in between. And let me say > >> some $$$$ CASH. > >>> Right? Please let us take this in prospective. If the group > >> agree to > >>> mandate NTP time synchronization, we do not need to go > >> through all of > >>> this and we could have save plenty of man hours for all of > >> us. Reality > >>> is a little different and timestamp is used per other signaling=20 > >>> protocols in other IETF standards. Nothing new here. > >> Which ones other than SEND and MIP4? In both it's used for replay=20 > >> protection, not ordered delivery of messages. > >=20 > > [Ahmad] > > Let us talk about MIPv4. I understand that MIPv4 use timestamp for=20 > > replay protection, but you are saying that does not=20 > guarantee ordering? >=20 > Good question. >=20 > I can say that my mip4 implementation doesn't rely on MN and=20 > HA be time synched and MIP4 messages are ordered. But it's prototype. >=20 > (it's not "my" implementation, it has its open source origins=20 > as you may > be aware). >=20 > > In other words, are you saying that the HA will accept an=20 > out of order=20 > > packets? >=20 > In extreme conditions, my implementation - yes. Its problem=20 > is not packets being disordered, but security: another MN=20 > sending RegReq for the victim MN's Home Address. And I plan=20 > to solve security by using IPsec encapsulated UDP. >=20 > > For example: RRQ(t1-d1) can be accepted if HA already has already=20 > > accepted another RRQ with timestamp (t1)? >=20 > YEs, it can. And it has problems - security problems, not=20 > ordering problems. >=20 > Alex >=20 > >> Take other routing protocols OSPF and BGP and there's no=20 > timestamps=20 > >> transmitted in messages. > >> > >> I think there's no other IETF protocol that uses timestamps in=20 > >> messages in order to ensure ordered delivery of messages. > >> > >> Alex > >> > >>>> "Time is not believed until several packet exchanges have taken=20 > >>>> place, each passing a set of sanity checks. Only if the > >> replies from > >>>> a server satisfy the conditions defined in the protocol=20 > >>>> specification, the server is considered valid. Time cannot be=20 > >>>> synchronized from a server that is considered invalid by the=20 > >>>> protocol. Some essential values are put into multi-stage > >> filters for > >>>> statistical purposes to improve and estimate the quality of the=20 > >>>> samples from each server." > >>> [Ahmad] > >>> As long as the proposed mechanism works for ordering > >> P-BU/P-BA, then > >>> that should be fine. > >>> > >>>> BR, > >>>> > >>>> Kilian > >>>> > >>>> > >>>> Panasonic R&D Center Germany GmbH > >>>> 63225 Langen, Hessen, Germany > >>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > >>>> Micke > >>>> > >>>> > >>>> > >> > >>=20 > _____________________________________________________________________ > >> _ This email has been scanned by the MessageLabs Email Security=20 > >> System. > >> For more information please visit > >> http://www.messagelabs.com/email > >>=20 > _____________________________________________________________________ > >> _ > >> > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 11:17:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqRy-00064q-B1; Thu, 13 Sep 2007 11:17:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqRw-00062B-5N for netlmm@ietf.org; Thu, 13 Sep 2007 11:17:48 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVqRk-0007CW-K1 for netlmm@ietf.org; Thu, 13 Sep 2007 11:17:48 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DFHPt09142; Thu, 13 Sep 2007 15:17:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 10:17:24 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B9A53C@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E94FA5.3070302@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2FmHsrsO5t+9NRaO1wlRXnIWosQAAcZaQ References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F93@zrc2hxm2.corp.nortel.com> <46E9354A.3030303@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A06E@zrc2hxm2.corp.nortel.com> <46E9406E.2080204@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A364@zrc2hxm2.corp.nortel.com> <46E94FA5.3070302@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex, We are going in circle. This is my last response.=20 Unfortunately or fortunately, I have other tasks that I need to work on too. Please see comments below. Best Regards, Ahmad > >>=20 > >> I've used the same argumentation previously for saying=20 > that maybe 2=20 > >> round trips now and then for seqno at first attachment is not that=20 > >> much an overload. > >>=20 > >> Let's say that the requirement is to ensure ordering of=20 > P-BUs at LMA=20 > >> _without_ extraneous P-BU/P-BAck roundtrips. Then we can only do=20 > >> this: (1) do seqno stuff at the shadowy AAA phase xor (2) rely on=20 > >> NTP/GPS/GSM for time synchronizaion. > >=20 > > [Ahmad] I am not sure about the shadowy AAA phase does. Without=20 > > understanding the details this for me is undefined. >=20 > I am not sure either. >=20 > However, without it the MAG can not send the P-BUs on behalf of MN. [Ahmad] The functionality of the use of AAA in MN access authentication and possible assignment of HNP, other MN information is well known concept. However, what you are proposing is the use of keeping AAA always updated with the last used SQN per-MN. I am not sure how realistic that approach but at least , IMO, it is undefined. >=20 > If I knew what it does and how it works then I could say how=20 > it distributes the seqno as well. >=20 > >> I think doing only timestamps without NTP/GSM/GPS synchronization=20 > >> doesn't save us the risk of extraneous roundtrips. > >=20 > > [Ahmad] True. However, I do not believe that it is as bad=20 > as using SQN=20 > > without synchronization. I hope you agree. >=20 > No :-) [Ahmad] That is fine. I am not trying to change your mind:-) >=20 > >> I also think doing both timestamps+seqnos doesn't save us the same=20 > >> risk. I also think reusing the timestamps from DNA/SeND=20 > doesn't save=20 > >> us the risk of sometimes running two round trips. > >>=20 > >> Alex PS: if we change the requirement to allow for a three-way=20 > >> handshake (still forbid 2 round trips) then the solutions change=20 > >> again. > >=20 > > [Ahmad] I do not think there is currently a mechanism to=20 > enable this=20 > > three-way handshake in MIPv6 or PMIPv6. >=20 > Right, there isn't. And there are many things in PMIPv6 that=20 > aren't in > MIP6 either: reliance on timestamps and timesync, HNP in=20 > PBack, reliance on AAA, reliance on prefix-per-MN - to name a few. >=20 > You were talking about money and dollars: how much does it=20 > cost to upgrade the MIP6 HA software to PMIPv6? how much=20 > does it cost to have all entities time synchronized? >=20 > I'm sure one could reuse much more of MIP6 than that. [Ahmad] That is also a cool thing! :-) >=20 > Alex >=20 > >=20 > >>> Regards, Ahmad > >>>=20 > >>>=20 > >>>> -----Original Message----- From: Alexandru Petrescu=20 > >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday,=20 > September 13,=20 > >>>> 2007 8:04 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: Alexandru=20 > >>>> Petrescu; Kilian Weniger; Sri Gundavelli; DE JUAN HUARTE=20 > FEDERICO;=20 > >>>> netlmm@ietf.org Subject: Re: [netlmm] timestamp vs seqno redux > >>>>=20 > >>>> Ahmad Muhanna wrote: > >>>>>> Subject: Re: [netlmm] timestamp vs seqno redux > >>>>>>=20 > >>>>>> Ahmad Muhanna wrote: > >>>>>>>> Subject: Re: [netlmm] timestamp vs seqno redux > >>>>>>>>=20 > >>>>>>>> Ahmad Muhanna wrote: > >>>>>>>>> Hi Alex, > >>>>>>>>>=20 > >>>>>>>>> No it does not have an effect on the calculation. > >>>>>>>> So why do you mention it as an assumption? > >>>>>>> [Ahmad] It is an over sight on my part. Sorry for the=20 > confusion. > >>>>>> Ahmad, I think any assumption on a constant delay of the > >>>> network is > >>>>>> wrong, be it symmetric or asymmetric. You do a > >>>> measurement now and > >>>>>> ten minutes later the delays are different because=20 > somebody else=20 > >>>>>> loads the network. > >>>>>>=20 > >>>>>> You do 10 measurements in a burst and you get different times,=20 > >>>>>> eventually with a Gaussian distribution. That's the first > >>>> experience > >>>>>> with ping. > >>>>> [Ahmad] Alex, There is no assumption about a constant delay?=20 > >>>>> This is just used for a snap shot analysis to prove the > >> concept is > >>>>> valid. That is all. > >>>> What makes you think that the situation is the same when=20 > you make=20 > >>>> your snapshot and 10minutes later? > >>>>=20 > >>>>> If the network condition changes, the concept still valid > >>>> and should > >>>>> adjust itself and work. NO? > >>>> Don't you assume that when network conditions change a new=20 > >>>> measurement is necessary? How do you know when network=20 > conditions=20 > >>>> change? > >>>>=20 > >>>> Alex > >>>>=20 > >>>>=20 > >>>>=20 > >>=20 > _____________________________________________________________________ > >>=20 > >>>> _ This email has been scanned by the MessageLabs Email Security =20 > >>>> System. For more information please visit=20 > >>>> http://www.messagelabs.com/email > >>>>=20 > >>=20 > _____________________________________________________________________ > >>=20 > >>>> _ > >>>>=20 > >>=20 > >>=20 > _____________________________________________________________________ > >> _ This email has been scanned by the MessageLabs Email Security=20 > >> System. For more information please visit=20 > >> http://www.messagelabs.com/email=20 > >>=20 > _____________________________________________________________________ > >> _ > >>=20 > >>=20 > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 11:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqcc-0001tx-Ay; Thu, 13 Sep 2007 11:28:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqca-0001rZ-L3 for netlmm@ietf.org; Thu, 13 Sep 2007 11:28:48 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVqca-0000P8-2U for netlmm@ietf.org; Thu, 13 Sep 2007 11:28:48 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8DFS9PZ032335 for ; Thu, 13 Sep 2007 17:28:09 +0200 Received: from [172.27.205.222] ([172.27.205.222]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 13 Sep 2007 17:28:46 +0200 Message-ID: <46E9572F.2070806@alcatel-lucent.fr> Date: Thu, 13 Sep 2007 17:28:47 +0200 From: Bruno Mongazon-Cazavet User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: netlmm@ietf.org Subject: [netlmm] LMA as a time keeper Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Sep 2007 15:28:46.0245 (UTC) FILETIME=[C6746D50:01C7F61A] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org An idea regarding PBU ordering problem: -The LMA is the time keeper -When a MAG boots, it sends a dummy PBU to the LMA to request current time (time synchronization). LMA provides current time in the PBU-Ack. MAG set its time to LMA time received in PBU-Ack (a latency can be added for network transit). -All MAG linked to the same LMA will get synchronized with LMA time this way -the timestamp option is then used in real PBU/PBU-ACK, because all MAG are synchronized they can be ordered by LMA -only related LMA's and MAG are synchronized this way. Stupid? Bruno. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 11:49:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqw7-0002Og-QY; Thu, 13 Sep 2007 11:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVqw6-0002Oa-Ln for netlmm@ietf.org; Thu, 13 Sep 2007 11:48:58 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVqw5-0008FR-0u for netlmm@ietf.org; Thu, 13 Sep 2007 11:48:58 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id l8DFmuM6021444; Thu, 13 Sep 2007 17:48:56 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8DFmrRT000506; Thu, 13 Sep 2007 17:48:54 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Sep 2007 17:48:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Thu, 13 Sep 2007 17:48:52 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD680296BA0A@zagh223a.ww300.siemens.net> In-Reply-To: <016f01c7f612$e36aa5d0$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Thread-Index: Acf13aPqb8aDcLQ2SPyQtElJXW59vQANIgJgAAFcVUA= References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> <200709131010.48638.julien.IETF@laposte.net> <016f01c7f612$e36aa5d0$d5f6200a@amer.cisco.com> From: "Premec, Domagoj" To: "Sri Gundavelli" , "Julien Laganier" X-OriginalArrivalTime: 13 Sep 2007 15:48:53.0482 (UTC) FILETIME=[96062CA0:01C7F61D] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070913174856-54E8FBB0-3608B78A/0-0/0-15 X-purgate-size: 3625/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien, Sri, Julien's interpretation of my comment is right, but I don't want to = trigger the discussion about the link model type. I would be fine if = following clarification sentence could be added to section 6.3 Supported = Access Link Types: "This protocol may be used also with other access link types, such as = multi-access links, as long as the access link is configured in such a = way that it guarantees a point-to-point delivery between the MAG and the = MN for all types of traffic."=20 Would that be acceptable? domagoj > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: 13. rujan 2007 16:32 > To: 'Julien Laganier'; netlmm@ietf.org > Cc: Premec, Domagoj > Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt >=20 > Hi Julien,=20 >=20 > > -----Original Message----- > > From: julien laganier [mailto:julien.laganier@gmail.com] On=20 > Behalf Of=20 > > Julien Laganier > > Sent: Thursday, September 13, 2007 1:11 AM > > To: netlmm@ietf.org > > Cc: Premec, Domagoj; Sri Gundavelli > > Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt > >=20 > > Hi Domagoj, > >=20 > > I disagree with one of your comment below: > >=20 > > On Wednesday 12 September 2007, Premec, Domagoj wrote: > > > >6.3. =A0Supported Access Link Types > > > > > > > > =A0 This specification supports only point-to-point access > > link types > > > > and thus it assumes that the mobile node and the mobile access=20 > > > > gateway are the only two nodes on the access link. =A0The link = is=20 > > > > assumed to have multicast capability. > > > > > > I understand that the decision to use per-MN prefix model was=20 > > > motivated by the need to emulate the point-to-point link=20 > at the IP=20 > > > layer. > >=20 > > Not true.=20 > >=20 > > Use of a per-MN prefix model has been motivated by the need=20 > to avoid=20 > > multilink subnet issues [RFC4903]. > >=20 > > Following that prefix model choice, we have discussed at length on=20 > > that mailing list what are the implication of that model on the=20 > > supported underlying link (i.e. below IP). The per-MN prefix on a=20 > > pt-to-pt link has no issue. It is not clear however if it=20 > would work=20 > > well on a shared link. The consensus of the WG has been that the=20 > > current spec will be limited to support of pt-to-pt links. > >=20 > > Support for shared link can be added later in another specification. > >=20 > > > As the IP layer is configured in such a way that there=20 > are exactly=20 > > > two nodes on the link, we're actually independet of the=20 > underlaying=20 > > > link layer technology. > >=20 > > No configuration of the IP layer can restrict the number of=20 > nodes on a=20 > > link. The link properties are independent from those of the=20 > IP layer. > >=20 > > > I think the intent of the spec is to support any access=20 > link type,=20 > > > including for example 802.11. > >=20 > > I think the intent of the spec is to support only pt-to-pt=20 > links for=20 > > now since that's the only type of link where the per-MN=20 > prefix model=20 > > has no known issues. > >=20 >=20 > May be I misunderstood what Domagoj comment. My point is that=20 > we do allow access links such as 802.11, as long as the p2p=20 > requirement is met from L3 perspective, implies, there are=20 > only two nodes on the access link. A multicast RA sent by the=20 > MAG is received just by one node, as long as the link meets=20 > this requirement we are ok.=20 >=20 > Sri >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 11:56:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVr3q-0006I3-6I; Thu, 13 Sep 2007 11:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVr3o-0006Hy-Ha for netlmm@ietf.org; Thu, 13 Sep 2007 11:56:56 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVr3m-0008Qn-Q2 for netlmm@ietf.org; Thu, 13 Sep 2007 11:56:56 -0400 X-IronPort-AV: E=Sophos;i="4.20,250,1186383600"; d="scan'208";a="17853028" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Sep 2007 08:56:54 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8DFusd1029477; Thu, 13 Sep 2007 08:56:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8DFunoJ019565; Thu, 13 Sep 2007 15:56:54 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 08:56:49 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 08:56:48 -0700 From: "Sri Gundavelli" To: "'Premec, Domagoj'" , "'Julien Laganier'" References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> <200709131010.48638.julien.IETF@laposte.net> <016f01c7f612$e36aa5d0$d5f6200a@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD680296BA0A@zagh223a.ww300.siemens.net> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Thu, 13 Sep 2007 08:56:48 -0700 Message-ID: <018c01c7f61e$b19a26f0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680296BA0A@zagh223a.ww300.siemens.net> Thread-Index: Acf13aPqb8aDcLQ2SPyQtElJXW59vQANIgJgAAFcVUAAAY4/0A== X-OriginalArrivalTime: 13 Sep 2007 15:56:49.0185 (UTC) FILETIME=[B190B110:01C7F61E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4309; t=1189699014; x=1190563014; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-proxymip6 -04.txt |Sender:=20; bh=zKsqQoQJuw1oT9T32JuWjAZXO2bgEJMVqzm1ZFqwRwk=; b=dzQJaOKDA8EdHU1mSbjyeSRpuAYEgJCqk4w+VQsQZs+pnyse4W/jgkhnSme0JFFBCYKo4GgL eQlU9nfcWVhqhi/REcY4WWymNRcuVw8ZppKMq2As++t+6XR0Avu0UMGN; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Domagoj, =20 > -----Original Message----- > From: Premec, Domagoj [mailto:domagoj.premec@siemens.com]=20 > Sent: Thursday, September 13, 2007 8:49 AM > To: Sri Gundavelli; Julien Laganier > Cc: netlmm@ietf.org > Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt >=20 > Hi Julien, Sri, >=20 > Julien's interpretation of my comment is right, but I don't=20 > want to trigger the discussion about the link model type. I=20 > would be fine if following clarification sentence could be=20 > added to section 6.3 Supported Access Link Types: >=20 > "This protocol may be used also with other access link types,=20 > such as multi-access links, as long as the access link is=20 > configured in such a way that it guarantees a point-to-point=20 > delivery between the MAG and the MN for all types of traffic."=20 >=20 Exactly, this was my point. > Would that be acceptable? I'm ok with this. This still meets the P2P link model requirement as agreed upon by the WG. Sri >=20 > domagoj >=20 >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > > Sent: 13. rujan 2007 16:32 > > To: 'Julien Laganier'; netlmm@ietf.org > > Cc: Premec, Domagoj > > Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt > >=20 > > Hi Julien,=20 > >=20 > > > -----Original Message----- > > > From: julien laganier [mailto:julien.laganier@gmail.com] On=20 > > Behalf Of=20 > > > Julien Laganier > > > Sent: Thursday, September 13, 2007 1:11 AM > > > To: netlmm@ietf.org > > > Cc: Premec, Domagoj; Sri Gundavelli > > > Subject: Re: [netlmm] I-D=20 > Action:draft-ietf-netlmm-proxymip6-04.txt > > >=20 > > > Hi Domagoj, > > >=20 > > > I disagree with one of your comment below: > > >=20 > > > On Wednesday 12 September 2007, Premec, Domagoj wrote: > > > > >6.3. =A0Supported Access Link Types > > > > > > > > > > =A0 This specification supports only point-to-point access > > > link types > > > > > and thus it assumes that the mobile node and the=20 > mobile access=20 > > > > > gateway are the only two nodes on the access link. =A0 > The link is=20 > > > > > assumed to have multicast capability. > > > > > > > > I understand that the decision to use per-MN prefix model was=20 > > > > motivated by the need to emulate the point-to-point link=20 > > at the IP=20 > > > > layer. > > >=20 > > > Not true.=20 > > >=20 > > > Use of a per-MN prefix model has been motivated by the need=20 > > to avoid=20 > > > multilink subnet issues [RFC4903]. > > >=20 > > > Following that prefix model choice, we have discussed at=20 > length on=20 > > > that mailing list what are the implication of that model on the=20 > > > supported underlying link (i.e. below IP). The per-MN prefix on a=20 > > > pt-to-pt link has no issue. It is not clear however if it=20 > > would work=20 > > > well on a shared link. The consensus of the WG has been that the=20 > > > current spec will be limited to support of pt-to-pt links. > > >=20 > > > Support for shared link can be added later in another=20 > specification. > > >=20 > > > > As the IP layer is configured in such a way that there=20 > > are exactly=20 > > > > two nodes on the link, we're actually independet of the=20 > > underlaying=20 > > > > link layer technology. > > >=20 > > > No configuration of the IP layer can restrict the number of=20 > > nodes on a=20 > > > link. The link properties are independent from those of the=20 > > IP layer. > > >=20 > > > > I think the intent of the spec is to support any access=20 > > link type,=20 > > > > including for example 802.11. > > >=20 > > > I think the intent of the spec is to support only pt-to-pt=20 > > links for=20 > > > now since that's the only type of link where the per-MN=20 > > prefix model=20 > > > has no known issues. > > >=20 > >=20 > > May be I misunderstood what Domagoj comment. My point is that=20 > > we do allow access links such as 802.11, as long as the p2p=20 > > requirement is met from L3 perspective, implies, there are=20 > > only two nodes on the access link. A multicast RA sent by the=20 > > MAG is received just by one node, as long as the link meets=20 > > this requirement we are ok.=20 > >=20 > > Sri > >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 12:22:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVrSB-0001os-Jd; Thu, 13 Sep 2007 12:22:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVrS9-0001eC-Di for netlmm@ietf.org; Thu, 13 Sep 2007 12:22:05 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IVrS8-0000b0-3V for netlmm@ietf.org; Thu, 13 Sep 2007 12:22:05 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1189700522!17980123!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 18071 invoked from network); 13 Sep 2007 16:22:02 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-8.tower-128.messagelabs.com with SMTP; 13 Sep 2007 16:22:02 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l8DGLv4Z018361; Thu, 13 Sep 2007 09:22:01 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8DGLuvG009602; Thu, 13 Sep 2007 11:21:56 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8DGLrGW009568; Thu, 13 Sep 2007 11:21:54 -0500 (CDT) Message-ID: <46E963A0.5000404@gmail.com> Date: Thu, 13 Sep 2007 18:21:52 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A102@zrc2hxm2.corp.nortel.com> <46E94A49.7000108@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A418@zrc2hxm2.corp.nortel.com> <46E950C8.9080408@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A4E2@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B9A4E2@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-4, 12/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Alex, > > You can call it security or whatever, it is part of the MIP4 replay > protection which guarantees ordering. If you would like to use IPsec > with MIP4 that is fine, but, then you may as well forget about MIPv4 > replay protection because that is supposedly handled by IPsec too. And that is a good thing. Alex > > > Regards, > Ahmad > > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Thursday, September 13, 2007 10:01 AM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: Alexandru Petrescu; Kilian Weniger; Sri Gundavelli; DE >> JUAN HUARTE FEDERICO; netlmm@ietf.org >> Subject: Re: [netlmm] timestamp vs seqno redux >> >> Ahmad Muhanna wrote: >>>>> [Ahmad] >>>>> And that why NTP needs a whole different protocol and different >>>>> equipment and everything else in between. And let me say >>>> some $$$$ CASH. >>>>> Right? Please let us take this in prospective. If the group >>>> agree to >>>>> mandate NTP time synchronization, we do not need to go >>>> through all of >>>>> this and we could have save plenty of man hours for all of >>>> us. Reality >>>>> is a little different and timestamp is used per other signaling >>>>> protocols in other IETF standards. Nothing new here. >>>> Which ones other than SEND and MIP4? In both it's used for replay >>>> protection, not ordered delivery of messages. >>> [Ahmad] >>> Let us talk about MIPv4. I understand that MIPv4 use timestamp for >>> replay protection, but you are saying that does not >> guarantee ordering? >> >> Good question. >> >> I can say that my mip4 implementation doesn't rely on MN and >> HA be time synched and MIP4 messages are ordered. But it's prototype. >> >> (it's not "my" implementation, it has its open source origins >> as you may >> be aware). >> >>> In other words, are you saying that the HA will accept an >> out of order >>> packets? >> In extreme conditions, my implementation - yes. Its problem >> is not packets being disordered, but security: another MN >> sending RegReq for the victim MN's Home Address. And I plan >> to solve security by using IPsec encapsulated UDP. >> >>> For example: RRQ(t1-d1) can be accepted if HA already has already >>> accepted another RRQ with timestamp (t1)? >> YEs, it can. And it has problems - security problems, not >> ordering problems. >> >> Alex >> >>>> Take other routing protocols OSPF and BGP and there's no >> timestamps >>>> transmitted in messages. >>>> >>>> I think there's no other IETF protocol that uses timestamps in >>>> messages in order to ensure ordered delivery of messages. >>>> >>>> Alex >>>> >>>>>> "Time is not believed until several packet exchanges have taken >>>>>> place, each passing a set of sanity checks. Only if the >>>> replies from >>>>>> a server satisfy the conditions defined in the protocol >>>>>> specification, the server is considered valid. Time cannot be >>>>>> synchronized from a server that is considered invalid by the >>>>>> protocol. Some essential values are put into multi-stage >>>> filters for >>>>>> statistical purposes to improve and estimate the quality of the >>>>>> samples from each server." >>>>> [Ahmad] >>>>> As long as the proposed mechanism works for ordering >>>> P-BU/P-BA, then >>>>> that should be fine. >>>>> >>>>>> BR, >>>>>> >>>>>> Kilian >>>>>> >>>>>> >>>>>> Panasonic R&D Center Germany GmbH >>>>>> 63225 Langen, Hessen, Germany >>>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas >>>>>> Micke >>>>>> >>>>>> >>>>>> >>>> >> _____________________________________________________________________ >>>> _ This email has been scanned by the MessageLabs Email Security >>>> System. >>>> For more information please visit >>>> http://www.messagelabs.com/email >>>> >> _____________________________________________________________________ >>>> _ >>>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 12:50:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVrtm-0000rY-4g; Thu, 13 Sep 2007 12:50:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVrtk-0000rQ-3k for netlmm@ietf.org; Thu, 13 Sep 2007 12:50:36 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVrtj-0002ie-PU for netlmm@ietf.org; Thu, 13 Sep 2007 12:50:36 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8DGoSt08993; Thu, 13 Sep 2007 16:50:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] timestamp vs seqno redux Date: Thu, 13 Sep 2007 11:50:27 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116B9A8A7@zrc2hxm2.corp.nortel.com> In-Reply-To: <46E963A0.5000404@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] timestamp vs seqno redux Thread-Index: Acf2IkUj6pOoWC1vRqm4YzqfmVw5HQAAm9EA References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A102@zrc2hxm2.corp.nortel.com> <46E94A49.7000108@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A418@zrc2hxm2.corp.nortel.com> <46E950C8.9080408@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A4E2@zrc2hxm2.corp.nortel.com> <46E963A0.5000404@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Subject: Re: [netlmm] timestamp vs seqno redux >=20 > Ahmad Muhanna wrote: > > Alex, > >=20 > > You can call it security or whatever, it is part of the MIP4 replay=20 > > protection which guarantees ordering. If you would like to=20 > use IPsec=20 > > with MIP4 that is fine, but, then you may as well forget=20 > about MIPv4=20 > > replay protection because that is supposedly handled by IPsec too. >=20 > And that is a good thing. [Ahmad] Hi Alex, I could not resist this one.:-)=20 Distorting MIPv4 replay protection to prove a point that MIP4 replay protection (based on timestamp) does not guarantee ordering and then you suggest using IPsec to fix the distortion and finally calling that a good thing. :-) >=20 > Alex >=20 > >=20 > >=20 > > Regards, > > Ahmad > > =20 > >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 13 17:07:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvtu-0007m7-N1; Thu, 13 Sep 2007 17:07:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVvts-0007bb-NM for netlmm@ietf.org; Thu, 13 Sep 2007 17:07:00 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IVvts-0004Mu-7L for netlmm@ietf.org; Thu, 13 Sep 2007 17:07:00 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1189717618!4378922!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 15950 invoked from network); 13 Sep 2007 21:06:58 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-10.tower-153.messagelabs.com with SMTP; 13 Sep 2007 21:06:58 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8DL6rHZ002302; Thu, 13 Sep 2007 14:06:53 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l8DL6pZO022167; Thu, 13 Sep 2007 16:06:52 -0500 (CDT) Received: from [127.0.0.1] ([10.129.44.188]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8DL6mD2022110; Thu, 13 Sep 2007 16:06:49 -0500 (CDT) Message-ID: <46E9A667.1080108@gmail.com> Date: Thu, 13 Sep 2007 23:06:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] timestamp vs seqno redux References: <1FEB9B9F2EC38343955D02B2AE86AACB48AB04@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA43710F500AE4@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116AF9543@zrc2hxm2.corp.nortel.com> <46E928E8.4070809@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49EEE@zrc2hxm2.corp.nortel.com> <46E92ECB.9080106@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B49F28@zrc2hxm2.corp.nortel.com> <46E931C6.5060600@gmail.com> <1FEB9B9F2EC38343955D02B2AE86AACB48AC80@lan-ex-02.panasonic.de> <6FC4416DDE56C44DA0AEE67BC7CA437116B4A102@zrc2hxm2.corp.nortel.com> <46E94A49.7000108@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A418@zrc2hxm2.corp.nortel.com> <46E950C8.9080408@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A4E2@zrc2hxm2.corp.nortel.com> <46E963A0.5000404@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116B9A8A7@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116B9A8A7@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-5, 13/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: DE JUAN HUARTE FEDERICO , Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: >> Subject: Re: [netlmm] timestamp vs seqno redux >> >> Ahmad Muhanna wrote: >>> Alex, >>> >>> You can call it security or whatever, it is part of the MIP4 replay >>> protection which guarantees ordering. If you would like to >> use IPsec >>> with MIP4 that is fine, but, then you may as well forget >> about MIPv4 >>> replay protection because that is supposedly handled by IPsec too. >> And that is a good thing. > > [Ahmad] > Hi Alex, > > I could not resist this one.:-) > > Distorting MIPv4 replay protection to prove a point that MIP4 replay > protection (based on timestamp) does not guarantee ordering and then you > suggest using IPsec to fix the distortion and finally calling that a > good thing. :-) Hi Ahmad... sorry for misunderstanding... I didn't mean the MIP4 replay protection based on timestamps doesn't work. It can work. IPsec used on MIP4 to ensure replay protection is a good thing. I even think it's better than using timestamps in MIP4. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 03:15:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW5Oe-0003Bc-Eh; Fri, 14 Sep 2007 03:15:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW5Od-0003BW-T6 for netlmm@ietf.org; Fri, 14 Sep 2007 03:15:23 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW5Od-0002uq-5P for netlmm@ietf.org; Fri, 14 Sep 2007 03:15:23 -0400 Received: by rv-out-0910.google.com with SMTP id l15so601978rvb for ; Fri, 14 Sep 2007 00:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=SPFJP/02cH3kGNBSvU5//976KHaNJ/MKDPaUfGdW4M4=; b=AVvLM/yCUSsqvtDH0nNKz47lvrKcRcsh6V6Lpm56b5HGKT0iIVbGOrQo9DO/0JFQA9ASUOASCIOBC1CkZMYuuY16YEC2HlfEjPtexra/PaD/vYpL7jhsdrxvPHTcZCFQXfi//9jqDQ6k/iA+VREP+LXQtrr9NMsx2xR4l20nGP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=W3BsileCcWOG0fgm8vsYJlPjCxdcwmAf4SnLIYYZjTSJkq10Ypbq3NKWjy53REAI9Dzmp3YeGC4T6nyLbmj/JutOwEgGqHckiCcZMuoQBhd6El1zjMGhTme6OdqNwNPA49hh9JI48hAV5EPeBBFR1wIhYRBwZkSxT/OPAz7ktfQ= Received: by 10.114.200.2 with SMTP id x2mr1448325waf.1189754121350; Fri, 14 Sep 2007 00:15:21 -0700 (PDT) Received: by 10.141.78.6 with HTTP; Fri, 14 Sep 2007 00:15:21 -0700 (PDT) Message-ID: Date: Fri, 14 Sep 2007 16:15:21 +0900 From: "Jong-Hyouk Lee" To: "Bruno Mongazon-Cazavet" Subject: Re: [netlmm] LMA as a time keeper In-Reply-To: <46E9572F.2070806@alcatel-lucent.fr> MIME-Version: 1.0 References: <46E9572F.2070806@alcatel-lucent.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1301811994==" Errors-To: netlmm-bounces@ietf.org --===============1301811994== Content-Type: multipart/alternative; boundary="----=_Part_155_18214898.1189754121325" ------=_Part_155_18214898.1189754121325 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Bruno. The introduced way seems to be simple and enough to end this issue. I take sides with this. Cheers. On 9/14/07, Bruno Mongazon-Cazavet wrote: > > An idea regarding PBU ordering problem: > > -The LMA is the time keeper > -When a MAG boots, it sends a dummy PBU to the LMA to request current > time (time synchronization). LMA provides current time in the PBU-Ack. > MAG set its time to LMA time received in PBU-Ack (a latency can be added > for network transit). > -All MAG linked to the same LMA will get synchronized with LMA time this > way > -the timestamp option is then used in real PBU/PBU-ACK, because all MAG > are synchronized they can be ordered by LMA > -only related LMA's and MAG are synchronized this way. > > Stupid? > > Bruno. > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://www.hurryon.org ------=_Part_155_18214898.1189754121325 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear Bruno.
 
The introduced way seems to be simple and enough to end this issue. I take sides with this.
 
Cheers.

 
On 9/14/07, Bruno Mongazon-Cazavet <bruno.mongazon-cazavet@alcatel-lucent.fr> wrote:
An idea regarding PBU ordering problem:

-The LMA is the time keeper
-When a MAG boots, it sends a dummy PBU to the LMA to request current
time (time synchronization). LMA provides current time in the PBU-Ack.
MAG set its time to LMA time received in PBU-Ack (a latency can be added
for network transit).
-All MAG linked to the same LMA will get synchronized with LMA time this way
-the timestamp option is then used in real PBU/PBU-ACK, because all MAG
are synchronized they can be ordered by LMA
-only related LMA's and MAG are synchronized this way.

Stupid?

Bruno.

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm



--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org ------=_Part_155_18214898.1189754121325-- --===============1301811994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============1301811994==-- From netlmm-bounces@ietf.org Fri Sep 14 03:46:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW5sT-0007r2-Cl; Fri, 14 Sep 2007 03:46:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW5sR-0007lt-1d for netlmm@ietf.org; Fri, 14 Sep 2007 03:46:11 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW5sP-00043a-G1 for netlmm@ietf.org; Fri, 14 Sep 2007 03:46:10 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOC00A8NLJVC3@szxga02-in.huawei.com> for netlmm@ietf.org; Fri, 14 Sep 2007 15:45:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOC000XMLJTKD@szxga02-in.huawei.com> for netlmm@ietf.org; Fri, 14 Sep 2007 15:45:31 +0800 (CST) Received: from z49950 ([10.121.32.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOC00AIWLJOE1@szxml04-in.huawei.com> for netlmm@ietf.org; Fri, 14 Sep 2007 15:45:29 +0800 (CST) Date: Fri, 14 Sep 2007 15:45:15 +0800 From: "John.zhao" Subject: RE: [netlmm] LMA as a time keeper In-reply-to: To: 'Jong-Hyouk Lee' , 'Bruno Mongazon-Cazavet' Message-id: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acf2nxGqVcPl42MbTYKVhcoqt6hTcAAA4rtA X-Spam-Score: 0.6 (/) X-Scan-Signature: 3a364894605f80b4cf7342846f9183e6 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1923030182==" Errors-To: netlmm-bounces@ietf.org This is a multi-part message in MIME format. --===============1923030182== Content-type: multipart/alternative; boundary="Boundary_(ID_jP1wrN/OieVE5taWbD36gQ)" This is a multi-part message in MIME format. --Boundary_(ID_jP1wrN/OieVE5taWbD36gQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi,all =20 To this method , I doubt whether something need to be clarified = at the first: 1) If we have assumed that all of the MAG can maintenance the same clock with the LMA after it get the time from that LMA? 2) What is the precision requirement for this timestamp used here? 3) If can every MAG only connect to one LMA? =20 Best Rgds, Thanks, =20 John.zhao =20 _____ =20 =B7=A2=BC=FE=C8=CB: Jong-Hyouk Lee [mailto:jonghyouk@gmail.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA9=D4=C214=C8=D5 15:15 =CA=D5=BC=FE=C8=CB: Bruno Mongazon-Cazavet =B3=AD=CB=CD: netlmm@ietf.org =D6=F7=CC=E2: Re: [netlmm] LMA as a time keeper =20 Dear Bruno. =20 The introduced way seems to be simple and enough to end this issue. I = take sides with this. =20 Cheers. =20 On 9/14/07, Bruno Mongazon-Cazavet wrote:=20 An idea regarding PBU ordering problem: -The LMA is the time keeper -When a MAG boots, it sends a dummy PBU to the LMA to request current=20 time (time synchronization). LMA provides current time in the PBU-Ack. MAG set its time to LMA time received in PBU-Ack (a latency can be added for network transit). -All MAG linked to the same LMA will get synchronized with LMA time this = way -the timestamp option is then used in real PBU/PBU-ACK, because all MAG are synchronized they can be ordered by LMA -only related LMA's and MAG are synchronized this way. Stupid? Bruno. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm=20 --=20 Internet Management Technology Lab, Sungkyunkwan University.=20 Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com=20 #webpage: http://www.hurryon.org=20 --Boundary_(ID_jP1wrN/OieVE5taWbD36gQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi,all<= /span>

 <= /span>

   =       To this method , I doubt whether something need to be clarified at the = first:

1)       If we have assumed that all of the MAG can maintenance the = same clock with the LMA after it get the time from that = LMA?

2)       What is the precision requirement for this timestamp used = here?

3)       If can every MAG only connect to one = LMA?

 

Best Rgds,

Thanks,=

 <= /span>

John.zhao

 <= /span>

=B7=A2=BC=FE= =C8=CB: Jong-Hyouk = Lee [mailto:jonghyouk@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA9=D4=C214=C8=D5 15:15
=CA=D5=BC=FE=C8=CB: Bruno = Mongazon-Cazavet
=B3=AD=CB=CD: netlmm@ietf.org
=D6=F7=CC=E2: Re: [netlmm] LMA as a time = keeper

 

Dear = Bruno.

 

The introduced way seems to = be simple and enough to end this issue. I take sides with = this.

 

Cheers.

 

On 9/14/07, Bruno Mongazon-Cazavet = <bruno.mongazon-c= azavet@alcatel-lucent.fr> wrote:

An idea regarding PBU ordering problem:

-The LMA is the time keeper
-When a MAG boots, it sends a dummy PBU to the LMA to request current =
time (time synchronization). LMA provides current time in the = PBU-Ack.
MAG set its time to LMA time received in PBU-Ack (a latency can be = added
for network transit).
-All MAG linked to the same LMA will get synchronized with LMA time this = way
-the timestamp option is then used in real PBU/PBU-ACK, because all = MAG
are synchronized they can be ordered by LMA
-only related LMA's and MAG are synchronized this way.

Stupid?

Bruno.

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.= org/mailman/listinfo/netlmm




--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org =

--Boundary_(ID_jP1wrN/OieVE5taWbD36gQ)-- --===============1923030182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============1923030182==-- From netlmm-bounces@ietf.org Fri Sep 14 04:24:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6Tr-0002Bu-UY; Fri, 14 Sep 2007 04:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6Tq-0002Bj-T2 for netlmm@ietf.org; Fri, 14 Sep 2007 04:24:50 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW6Tp-0005sX-IG for netlmm@ietf.org; Fri, 14 Sep 2007 04:24:50 -0400 Received: by nz-out-0506.google.com with SMTP id n1so576349nzf for ; Fri, 14 Sep 2007 01:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=LrpSs48ptyz/2MefQN7zyumR2QwXqcoVYOPSVrTK70g=; b=K+UnxU6DrJ7S+37SSTGM14jr4awRTFg+QnmNqn0rbuszNm7uw59PUVr7thtuDFyhB+Uqe+LzS1G1vkWb49DkXsq1HGzd1kR7Q862iwEj7DRWz5wZ4Z77hE1sbdyKyNSQNjZcCZmQlZy7UgLEH7AC1tRiq+7gG6csxNpzP56zVoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FBaS2RDEYR1FGFaWS79V4v6zmN90YMgcdMNtq74AD5acJBWhJ/bGBOZexKf3jyoaC3N6Tt4KXx97Mbz4F6rcLgqUCm25OFX/Iq5Ob5UGhkShPreyYPSHJb+MNm7VMCr5jnttb/KwBLDCbi5iMGNHFpEN302/BGFyT4mbookgi3o= Received: by 10.142.77.11 with SMTP id z11mr351941wfa.1189758288328; Fri, 14 Sep 2007 01:24:48 -0700 (PDT) Received: by 10.141.78.6 with HTTP; Fri, 14 Sep 2007 01:24:48 -0700 (PDT) Message-ID: Date: Fri, 14 Sep 2007 17:24:48 +0900 From: "Jong-Hyouk Lee" To: john.zhao@huawei.com Subject: Re: [netlmm] LMA as a time keeper In-Reply-To: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> MIME-Version: 1.0 References: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0744890096==" Errors-To: netlmm-bounces@ietf.org --===============0744890096== Content-Type: multipart/alternative; boundary="----=_Part_231_28357860.1189758288334" ------=_Part_231_28357860.1189758288334 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIGFsbC4KClRvIGdldCB0aGUgdGltZSBzeW5jaHJvbml6YXRpb24gYnkgdGhlIGludHJvZHVj ZWQgbWV0aG9kLCBldmVyeSBNQUcga25vd3MKd2hpY2ggTE1BIGlzIHRoZSB0aW1lIHN5bmMgTE1B IGluIGNhc2Ugb2YgbXVsdGlwbGUgTE1BcyBpbiB0aGUgZG9tYWluLiBJdAptZWFucyB0aGF0IGV2 ZXJ5IE1BRyBvbmx5IG5vdCBjb25uZWN0IHRvIG9uZSBMTUEuIEFsc28sIGFsbCBMTUEgc2hvdWxk CnNoYXJlIHRoZSBzYW1lIHRpbWUgaW5mb3JtYXRpb24gYnkgb3RoZXIgd2F5LCBlLmcuLCBOVFAu CgpDaGVlcnMuCgoKT24gOS8xNC8wNywgSm9obi56aGFvIDxqb2huLnpoYW9AaHVhd2VpLmNvbT4g d3JvdGU6Cj4KPiAgSGksYWxsCj4KPgo+Cj4gICAgICAgICAgVG8gdGhpcyBtZXRob2QgLCBJIGRv dWJ0IHdoZXRoZXIgc29tZXRoaW5nIG5lZWQgdG8gYmUgY2xhcmlmaWVkCj4gYXQgdGhlIGZpcnN0 Ogo+Cj4gMSkgICAgICAgSWYgd2UgaGF2ZSBhc3N1bWVkIHRoYXQgYWxsIG9mIHRoZSBNQUcgY2Fu IG1haW50ZW5hbmNlIHRoZSBzYW1lCj4gY2xvY2sgd2l0aCB0aGUgTE1BIGFmdGVyIGl0IGdldCB0 aGUgdGltZSBmcm9tIHRoYXQgTE1BPwo+Cj4gMikgICAgICAgV2hhdCBpcyB0aGUgcHJlY2lzaW9u IHJlcXVpcmVtZW50IGZvciB0aGlzIHRpbWVzdGFtcCB1c2VkIGhlcmU/Cj4KPiAzKSAgICAgICBJ ZiBjYW4gZXZlcnkgTUFHIG9ubHkgY29ubmVjdCB0byBvbmUgTE1BPwo+Cj4KPgo+IEJlc3QgUmdk cywKPgo+IFRoYW5rcywKPgo+Cj4KPiBKb2huLnpoYW8KPgo+Cj4gICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KPgo+ICq3orz+yMs6KiBKb25nLUh5b3VrIExlZSBbbWFpbHRvOmpvbmdo eW91a0BnbWFpbC5jb21dCj4gKreiy83KsbzkOiogMjAwN8TqOdTCMTTI1SAxNToxNQo+ICrK1bz+ yMs6KiBCcnVubyBNb25nYXpvbi1DYXphdmV0Cj4gKrOty806KiBuZXRsbW1AaWV0Zi5vcmcKPiAq 1vfM4joqIFJlOiBbbmV0bG1tXSBMTUEgYXMgYSB0aW1lIGtlZXBlcgo+Cj4KPgo+IERlYXIgQnJ1 bm8uCj4KPgo+Cj4gVGhlIGludHJvZHVjZWQgd2F5IHNlZW1zIHRvIGJlIHNpbXBsZSBhbmQgZW5v dWdoIHRvIGVuZCB0aGlzIGlzc3VlLiBJIHRha2UKPiBzaWRlcyB3aXRoIHRoaXMuCj4KPgo+Cj4g Q2hlZXJzLgo+Cj4KPgo+IE9uIDkvMTQvMDcsICpCcnVubyBNb25nYXpvbi1DYXphdmV0KiA8Cj4g YnJ1bm8ubW9uZ2F6b24tY2F6YXZldEBhbGNhdGVsLWx1Y2VudC5mcj4gd3JvdGU6Cj4KPiBBbiBp ZGVhIHJlZ2FyZGluZyBQQlUgb3JkZXJpbmcgcHJvYmxlbToKPgo+IC1UaGUgTE1BIGlzIHRoZSB0 aW1lIGtlZXBlcgo+IC1XaGVuIGEgTUFHIGJvb3RzLCBpdCBzZW5kcyBhIGR1bW15IFBCVSB0byB0 aGUgTE1BIHRvIHJlcXVlc3QgY3VycmVudAo+IHRpbWUgKHRpbWUgc3luY2hyb25pemF0aW9uKS4g TE1BIHByb3ZpZGVzIGN1cnJlbnQgdGltZSBpbiB0aGUgUEJVLUFjay4KPiBNQUcgc2V0IGl0cyB0 aW1lIHRvIExNQSB0aW1lIHJlY2VpdmVkIGluIFBCVS1BY2sgKGEgbGF0ZW5jeSBjYW4gYmUgYWRk ZWQKPiBmb3IgbmV0d29yayB0cmFuc2l0KS4KPiAtQWxsIE1BRyBsaW5rZWQgdG8gdGhlIHNhbWUg TE1BIHdpbGwgZ2V0IHN5bmNocm9uaXplZCB3aXRoIExNQSB0aW1lIHRoaXMKPiB3YXkKPiAtdGhl IHRpbWVzdGFtcCBvcHRpb24gaXMgdGhlbiB1c2VkIGluIHJlYWwgUEJVL1BCVS1BQ0ssIGJlY2F1 c2UgYWxsIE1BRwo+IGFyZSBzeW5jaHJvbml6ZWQgdGhleSBjYW4gYmUgb3JkZXJlZCBieSBMTUEK PiAtb25seSByZWxhdGVkIExNQSdzIGFuZCBNQUcgYXJlIHN5bmNocm9uaXplZCB0aGlzIHdheS4K Pgo+IFN0dXBpZD8KPgo+IEJydW5vLgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPiBuZXRsbW0gbWFpbGluZyBsaXN0Cj4gbmV0bG1tQGlldGYub3Jn Cj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bG1tCj4KPgo+Cj4K PiAtLQo+IEludGVybmV0IE1hbmFnZW1lbnQgVGVjaG5vbG9neSBMYWIsIFN1bmdreXVua3dhbiBV bml2ZXJzaXR5Lgo+IEpvbmctSHlvdWsgTGVlLgo+Cj4gI2VtYWlsOiBqb25naHlvdWsgKGF0KSBn bWFpbCAoZG90KSBjb20KPiAjd2VicGFnZTogaHR0cDovL3d3dy5odXJyeW9uLm9yZwo+CgoKCi0t IApJbnRlcm5ldCBNYW5hZ2VtZW50IFRlY2hub2xvZ3kgTGFiLCBTdW5na3l1bmt3YW4gVW5pdmVy c2l0eS4KSm9uZy1IeW91ayBMZWUuCgojZW1haWw6IGpvbmdoeW91ayAoYXQpIGdtYWlsIChkb3Qp IGNvbQojd2VicGFnZTogaHR0cDovL3d3dy5odXJyeW9uLm9yZwo= ------=_Part_231_28357860.1189758288334 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSwgYWxsLjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PlRvJm5ic3A7Z2V0IHRo ZSB0aW1lIHN5bmNocm9uaXphdGlvbiBieSB0aGUgaW50cm9kdWNlZCBtZXRob2QsIGV2ZXJ5IE1B RyZuYnNwO2tub3dzIHdoaWNoIExNQSBpcyB0aGUgdGltZSBzeW5jIExNQSBpbiBjYXNlIG9mIG11 bHRpcGxlJm5ic3A7TE1BcyZuYnNwO2luIHRoZSBkb21haW4uIEl0IG1lYW5zIHRoYXQgZXZlcnkg TUFHIG9ubHkmbmJzcDtub3QgY29ubmVjdCB0byBvbmUgTE1BLiBBbHNvLCBhbGwgTE1BJm5ic3A7 c2hvdWxkIHNoYXJlJm5ic3A7dGhlIHNhbWUgdGltZSBpbmZvcm1hdGlvbiBieSBvdGhlciB3YXks Jm5ic3A7CmUuZy4sIE5UUC48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5DaGVlcnMuPGJy Pjxicj4mbmJzcDs8L2Rpdj4KPGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDkvMTQv MDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5Kb2huLnpoYW88L2I+ICZsdDs8YSBocmVm PSJtYWlsdG86am9obi56aGFvQGh1YXdlaS5jb20iPmpvaG4uemhhb0BodWF3ZWkuY29tPC9hPiZn dDsgd3JvdGU6PC9zcGFuPiAKPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i UEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZU OiAjY2NjIDFweCBzb2xpZCI+CjxkaXYgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJi bHVlIj4KPGRpdj4KPHA+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJuYXZ5IiBzaXplPSIxIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9O VC1GQU1JTFk6IEFyaWFsIj5IaSxhbGw8L3NwYW4+PC9mb250PjwvcD4KPHA+PGZvbnQgZmFjZT0i QXJpYWwiIGNvbG9yPSJuYXZ5IiBzaXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZP TlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDs8L3Nw YW4+PC9mb250PjwvcD4KPHA+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJuYXZ5IiBzaXplPSIx Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsg Rk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVG8gdGhpcyBtZXRob2QgLCBJIGRvdWJ0IHdoZXRoZXIgc29tZXRoaW5nIG5l ZWQgdG8gYmUgY2xhcmlmaWVkIGF0IHRoZSBmaXJzdDo8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0 eWxlPSJNQVJHSU4tTEVGVDogNjBwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0Ij48Zm9udCBmYWNlPSJB cmlhbCIgY29sb3I9Im5hdnkiIHNpemU9IjEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9O VC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxzcGFuPjEpPGZv bnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIxIj48c3Bhbj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+ PHNwYW4gZGlyPSJsdHIiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0ibmF2eSIgc2l6ZT0iMSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZP TlQtRkFNSUxZOiBBcmlhbCI+SWYgd2UgaGF2ZSBhc3N1bWVkIHRoYXQgYWxsIG9mIHRoZSBNQUcg Y2FuIG1haW50ZW5hbmNlIHRoZSBzYW1lIGNsb2NrIHdpdGggdGhlIExNQSBhZnRlciBpdCBnZXQg dGhlIHRpbWUgZnJvbSB0aGF0IExNQT8KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9wPgo8cCBzdHls ZT0iTUFSR0lOLUxFRlQ6IDYwcHQ7IFRFWFQtSU5ERU5UOiAtMThwdCI+PGZvbnQgZmFjZT0iQXJp YWwiIGNvbG9yPSJuYXZ5IiBzaXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48c3Bhbj4yKTxmb250 IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMSI+PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IAo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250Pjxz cGFuIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9Im5hdnkiIHNpemU9IjEiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05U LUZBTUlMWTogQXJpYWwiPldoYXQgaXMgdGhlIHByZWNpc2lvbiByZXF1aXJlbWVudCBmb3IgdGhp cyB0aW1lc3RhbXAgdXNlZCBoZXJlPwo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3A+CjxwIHN0eWxl PSJNQVJHSU4tTEVGVDogNjBwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0Ij48Zm9udCBmYWNlPSJBcmlh bCIgY29sb3I9Im5hdnkiIHNpemU9IjEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1T SVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxzcGFuPjMpPGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIxIj48c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PHNw YW4gZGlyPSJsdHIiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0ibmF2eSIgc2l6ZT0iMSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQt RkFNSUxZOiBBcmlhbCI+SWYgY2FuIGV2ZXJ5IE1BRyBvbmx5IGNvbm5lY3QgdG8gb25lIExNQT88 L3NwYW4+PC9mb250Pgo8L3NwYW4+PC9wPgo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQycHQiPjxm b250IGZhY2U9IkFyaWFsIiBjb2xvcj0ibmF2eSIgc2l6ZT0iMSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+CjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMjFwdCI+PGZv bnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJuYXZ5IiBzaXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5C ZXN0IFJnZHMsPC9zcGFuPjwvZm9udD48L3A+CjxwPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0i bmF2eSIgc2l6ZT0iMSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsg Q09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+VGhhbmtzLDwvc3Bhbj48L2ZvbnQ+PC9w Pgo8cD48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9Im5hdnkiIHNpemU9IjEiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTog QXJpYWwiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgo8cD48Zm9udCBmYWNlPSJBcmlhbCIgY29s b3I9Im5hdnkiIHNpemU9IjEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiA5 cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkpvaG4uemhhbzwvc3Bhbj48L2Zv bnQ+PC9wPgo8cD48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9Im5hdnkiIHNpemU9IjEiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZB TUlMWTogQXJpYWwiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgo8ZGl2IHN0eWxlPSJCT1JERVIt UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6IG1lZGl1 bSBub25lOyBQQURESU5HLUxFRlQ6IDRwdDsgUEFERElORy1CT1RUT006IDBjbTsgQk9SREVSLUxF RlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwY207IEJPUkRFUi1CT1RUT006IG1l ZGl1bSBub25lIj4KPGRpdj4KPGRpdiBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBhbGlnbj0i Y2VudGVyIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4KPGhyIGFsaWduPSJjZW50ZXIiIHdpZHRo PSIxMDAlIiBzaXplPSIyIj4KPC9zcGFuPjwvZm9udD48L2Rpdj4KPHA+PGI+PGZvbnQgZmFjZT0i y87M5SIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4iPreivP7IyzxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj4K IEpvbmctSHlvdWsgTGVlIFttYWlsdG86PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0 TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpqb25naHlvdWtAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+am9uZ2h5b3VrQGdtYWlsLmNvbTwvYT5dIDxicj48L3NwYW4+PC9m b250PjxiPjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJGT05ULVdFSUdI VDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj4Kt6LLzcqxvOQ8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9mb250PjwvYj48Zm9udCBmYWNlPSLL zszlIiBzaXplPSIyIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IFNpbVN1biI+IDIwMDc8c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gbGFuZz0i RU4tVVMiPsTqOTwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIGxhbmc9IkVO LVVTIj4K1MIxNDwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIGxhbmc9IkVO LVVTIj7I1Twvc3Bhbj48L3NwYW4+IDE1OjE1PGJyPjwvc3Bhbj48L2ZvbnQ+PGI+PGZvbnQgZmFj ZT0iy87M5SIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4iPsrVvP7IyzxzcGFuIGxhbmc9IkVOLVVTIj46 PC9zcGFuPgo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFNpbVN1 biI+IEJydW5vIE1vbmdhem9uLUNhemF2ZXQ8YnI+PC9zcGFuPjwvZm9udD48Yj48Zm9udCBmYWNl PSLLzszlIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IFNpbVN1biI+CrOty808c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9mb250PjwvYj48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFNpbVN1biI+ IDxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp IiBocmVmPSJtYWlsdG86bmV0bG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Cm5ldGxtbUBp ZXRmLm9yZzwvYT48YnI+PC9zcGFuPjwvZm9udD48Yj48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIy Ij48c3BhbiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IFNpbVN1biI+1vfM4jxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2Zv bnQ+PC9iPjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj4KIFJlOiBbbmV0bG1tXSBM TUEgYXMgYSB0aW1lIGtlZXBlcjwvc3Bhbj48L2ZvbnQ+PHNwYW4gbGFuZz0iRU4tVVMiPjwvc3Bh bj48L3A+PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9InEiIGlkPSJxXzExNTAyZmFkYWU3YjkyYWFf MSI+CjxwPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgo8 cD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYXIg QnJ1bm8uPC9zcGFuPjwvZm9udD48L3A+CjxkaXY+CjxwPjxmb250IGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgc2l6ZT0iMyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEycHQi PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPjwvZGl2Pgo8ZGl2Pgo8cD48Zm9udCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIHNpemU9IjMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0Ij5UaGUgaW50cm9kdWNlZCB3YXkmbmJzcDtzZWVtcyB0byBiZSZuYnNwO3NpbXBsZSBh bmQgZW5vdWdoIHRvIGVuZCB0aGlzIGlzc3VlLiBJIHRha2Ugc2lkZXMgd2l0aCB0aGlzLjwvc3Bh bj48L2ZvbnQ+PC9wPjwvZGl2Pgo8ZGl2Pgo8cD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9IjMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJz cDs8L3NwYW4+PC9mb250PjwvcD48L2Rpdj4KPGRpdj4KPHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBzaXplPSIzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJw dCI+Q2hlZXJzLjxicj48YnI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+PC9kaXY+CjxkaXY+Cjxw PjxzcGFuPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPk9uIDkvMTQvMDcsIDxiPjxzcGFuIHN0eWxl PSJGT05ULVdFSUdIVDogYm9sZCI+QnJ1bm8gTW9uZ2F6b24tQ2F6YXZldDwvc3Bhbj48L2I+ICZs dDs8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSIgaHJlZj0ibWFpbHRvOmJydW5vLm1vbmdhem9uLWNhemF2ZXRAYWxjYXRlbC1sdWNlbnQuZnIi IHRhcmdldD0iX2JsYW5rIj4KYnJ1bm8ubW9uZ2F6b24tY2F6YXZldEBhbGNhdGVsLWx1Y2VudC5m cjwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4g PC9zcGFuPjwvcD4KPHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+QW4gaWRlYSByZWdhcmRpbmcg UEJVIG9yZGVyaW5nIHByb2JsZW06PGJyPjxicj4tVGhlIExNQSBpcyB0aGUgdGltZSBrZWVwZXI8 YnI+LVdoZW4gYSBNQUcgYm9vdHMsIGl0IHNlbmRzIGEgZHVtbXkgUEJVIHRvIHRoZSBMTUEgdG8g cmVxdWVzdCBjdXJyZW50IAo8YnI+dGltZSAodGltZSBzeW5jaHJvbml6YXRpb24pLiBMTUEgcHJv dmlkZXMgY3VycmVudCB0aW1lIGluIHRoZSBQQlUtQWNrLjxicj5NQUcgc2V0IGl0cyB0aW1lIHRv IExNQSB0aW1lIHJlY2VpdmVkIGluIFBCVS1BY2sgKGEgbGF0ZW5jeSBjYW4gYmUgYWRkZWQ8YnI+ Zm9yIG5ldHdvcmsgdHJhbnNpdCkuPGJyPi1BbGwgTUFHIGxpbmtlZCB0byB0aGUgc2FtZSBMTUEg d2lsbCBnZXQgc3luY2hyb25pemVkIHdpdGggTE1BIHRpbWUgdGhpcyB3YXkgCjxicj4tdGhlIHRp bWVzdGFtcCBvcHRpb24gaXMgdGhlbiB1c2VkIGluIHJlYWwgUEJVL1BCVS1BQ0ssIGJlY2F1c2Ug YWxsIE1BRzxicj5hcmUgc3luY2hyb25pemVkIHRoZXkgY2FuIGJlIG9yZGVyZWQgYnkgTE1BPGJy Pi1vbmx5IHJlbGF0ZWQgTE1BJiMzOTtzIGFuZCBNQUcgYXJlIHN5bmNocm9uaXplZCB0aGlzIHdh eS48YnI+PGJyPlN0dXBpZD88YnI+PGJyPkJydW5vLjxicj48YnI+Cl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPm5ldGxtbSBtYWlsaW5nIGxpc3Q8YnI+ PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcyki IGhyZWY9Im1haWx0bzpuZXRsbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRsbW1AaWV0 Zi5vcmc8L2E+PGJyPjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93 LGV2ZW50LHRoaXMpIiBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRsbW0iIHRhcmdldD0iX2JsYW5rIj4KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bG1tIDwvYT48L3NwYW4+PC9mb250PjwvcD48L2Rpdj4KPHA+PGZvbnQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZP TlQtU0laRTogMTJwdCI+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPkludGVybmV0IE1h bmFnZW1lbnQgVGVjaG5vbG9neSBMYWIsIFN1bmdreXVua3dhbiBVbml2ZXJzaXR5LiA8YnI+Sm9u Zy1IeW91ayBMZWUuPGJyPjxicj4jZW1haWw6IGpvbmdoeW91ayAoYXQpIGdtYWlsIChkb3QpIGNv bSAKPGJyPiN3ZWJwYWdlOiA8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdp bmRvdyxldmVudCx0aGlzKSIgaHJlZj0iaHR0cDovL3d3dy5odXJyeW9uLm9yZy8iIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3Lmh1cnJ5b24ub3JnPC9hPiA8L3NwYW4+PC9mb250PjwvcD48L3Nw YW4+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xl YXI9ImFsbCI+Cjxicj4tLSA8YnI+SW50ZXJuZXQgTWFuYWdlbWVudCBUZWNobm9sb2d5IExhYiwg U3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHkuIDxicj5Kb25nLUh5b3VrIExlZS48YnI+PGJyPiNlbWFp bDogam9uZ2h5b3VrIChhdCkgZ21haWwgKGRvdCkgY29tIDxicj4jd2VicGFnZTogPGEgaHJlZj0i aHR0cDovL3d3dy5odXJyeW9uLm9yZyI+aHR0cDovL3d3dy5odXJyeW9uLm9yZzwvYT4gCg== ------=_Part_231_28357860.1189758288334-- --===============0744890096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0744890096==-- From netlmm-bounces@ietf.org Fri Sep 14 05:00:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW72a-0003OE-As; Fri, 14 Sep 2007 05:00:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW72Y-0003O5-Qc for netlmm@ietf.org; Fri, 14 Sep 2007 05:00:43 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW72X-0006UU-9M for netlmm@ietf.org; Fri, 14 Sep 2007 05:00:42 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8E8xg5P026417; Fri, 14 Sep 2007 10:59:43 +0200 Received: from [172.27.205.222] ([172.27.205.222]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Fri, 14 Sep 2007 11:00:20 +0200 Message-ID: <46EA4DA5.5050807@alcatel-lucent.fr> Date: Fri, 14 Sep 2007 11:00:21 +0200 From: Bruno Mongazon-Cazavet User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: john.zhao@huawei.com Subject: Re: [netlmm] LMA as a time keeper References: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> In-Reply-To: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> X-OriginalArrivalTime: 14 Sep 2007 09:00:20.0403 (UTC) FILETIME=[AD80E830:01C7F6AD] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-MIME-Autoconverted: from 8bit to quoted-printable by smail5.alcatel.fr id l8E8xg5P026417 X-Spam-Score: 2.3 (++) X-Scan-Signature: 285c5d2442d4c903d8dda55de04f5334 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1679551447==" Errors-To: netlmm-bounces@ietf.org --===============1679551447== Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable John.zhao wrote:

<= span style=3D"font-size: 9pt; font-family: Arial; color: navy;" lang=3D"EN-US= ">Hi,all

<= span style=3D"font-size: 9pt; font-family: Arial; color: navy;" lang=3D"EN-US= "> 

<= span style=3D"font-size: 9pt; font-family: Arial; color: navy;" lang=3D"EN-US= ">         To this method , I doubt whether something need to be clarified at the first:

1)   &n= bsp;   If we have assumed that all of the MAG can maintenance the same clock with the LMA after it get the time from that LMA?

[BM] MAG can either:
a) set its system time (machine time) as the LMA time. In such a case, the time will be maintained by the system
b) keep this time as an internal MAG time. In such a case it needs to maintain it  on its own with the help of timing functions of the system.

2)   &n= bsp;   What is the precision requirement for this timestamp used here?<= /span>

[BM] second or millisecond i guess

3)   &n= bsp;   If can every MAG only connect to one LMA?

[BM] good point. According to the draft LMA can connect to multiple MAG. In such a case, each LMA reference time shall be kept and used separately by the LMA. Which in turn might imply that time is maintain as an internal MAG time, that is option b) in above question.

Best regards, Bruno.

 

Best Rgds,

<= span style=3D"font-size: 9pt; font-family: Arial; color: navy;" lang=3D"EN-US= ">Thanks,

<= span style=3D"font-size: 9pt; font-family: Arial; color: navy;" lang=3D"EN-US= "> 

<= span style=3D"font-size: 9pt; font-family: Arial; color: navy;" lang=3D"EN-US= ">John.zhao

<= span style=3D"font-size: 9pt; font-family: Arial; color: navy;" lang=3D"EN-US= "> 

<= /font>

=B7=A2= =BC=FE=C8=CB: Jong-Hyo= uk Lee [m= ailto:jonghyouk@gmail.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2007=C4=EA9= =D4=C214=C8=D5 15:15
=CA=D5= =BC=FE=C8=CB: Bruno Mongazon-Cazavet
=B3=AD= =CB=CD: net= lmm@ietf.org
=D6=F7= =CC=E2: Re: [netlmm] LMA as a time keeper

 

Dear Bruno.

 

The introduced way seems = to be simple and enough to end this issue. I take sides with this.

 

Cheers.

 

On 9/14/07, Bruno Mongazon-Cazavet <bruno.mon= gazon-cazavet@alcatel-lucent.fr> wrote:

An idea regarding PBU ordering problem:

-The LMA is the time keeper
-When a MAG boots, it sends a dummy PBU to the LMA to request current time (time synchronization). LMA provides current time in the PBU-Ack. MAG set its time to LMA time received in PBU-Ack (a latency can be added<= br> for network transit).
-All MAG linked to the same LMA will get synchronized with LMA time this way
-the timestamp option is then used in real PBU/PBU-ACK, because all MAG are synchronized they can be ordered by LMA
-only related LMA's and MAG are synchronized this way.

Stupid?

Bruno.

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.= ietf.org/mailman/listinfo/netlmm




--
Internet Management Technology Lab, Sungkyunkwan Univ= ersity.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org <= o:p>


--===============1679551447== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============1679551447==-- From netlmm-bounces@ietf.org Fri Sep 14 05:20:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7M9-0000or-MO; Fri, 14 Sep 2007 05:20:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7M8-0000o1-O1 for netlmm@ietf.org; Fri, 14 Sep 2007 05:20:56 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IW7M8-0007CL-2Y for netlmm@ietf.org; Fri, 14 Sep 2007 05:20:56 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1189761654!20830146!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19078 invoked from network); 14 Sep 2007 09:20:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 14 Sep 2007 09:20:54 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8E9Ks14020202; Fri, 14 Sep 2007 02:20:54 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l8E9KsXr007293; Fri, 14 Sep 2007 04:20:54 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8E9KqF6007252; Fri, 14 Sep 2007 04:20:52 -0500 (CDT) Message-ID: <46EA526F.7010800@gmail.com> Date: Fri, 14 Sep 2007 11:20:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bruno Mongazon-Cazavet Subject: Re: [netlmm] LMA as a time keeper References: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> <46EA4DA5.5050807@alcatel-lucent.fr> In-Reply-To: <46EA4DA5.5050807@alcatel-lucent.fr> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 000774-5, 13/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Bruno, just to add some thoughts... I'm not trying in no way to discard it, just discussion. Bruno Mongazon-Cazavet wrote: >> To this method , I doubt whether something need to be clarified at >> the first: >> >> 1) If we have assumed that all of the MAG can maintenance the >> same clock with the LMA after it get the time from that LMA? >> > [BM] MAG can either: a) set its system time (machine time) as the LMA > time. In such a case, the time will be maintained by the system Can a PC maintain the time correctly when its battery is no longer working correctly. > b) keep this time as an internal MAG time. In such a case it needs to > maintain it on its own with the help of timing functions of the > system. >> >> 2) What is the precision requirement for this timestamp used >> here? >> > [BM] second or millisecond i guess This should be dictated by the ordering requirement. I guess we want the precision to be directly related to how many handovers per second can a mobile do, and the P-BUs sent. For example, in WiFi, a typical link-layer handover is in the order of 500ms; for this, we don't need a time precision in the order of milliseconds, but hundreds of milliseconds. (at the same time, some very performant wifi link-layers can do in the order of 4ms.) WiFi is but one technology. I expect WiMax to have handover latencies in the order of seconds. >> 3) If can every MAG only connect to one LMA? >> > [BM] good point. According to the draft LMA can connect to multiple > MAG. In such a case, each LMA reference time shall be kept and used > separately by the LMA. Which in turn might imply that time is > maintain as an internal MAG time, that is option b) in above > question. In a deployment, LMA is probably the anchor point for mobility, the sort of controlling point and thus it makes sense to have LMA to keep time for everybody. But for anything else than mobility maybe other entities are such controlling points. I'm thinking of DHCP Server or LDAP Server or AAA Server, because they control the existence proper of mobiles. It is probably important that these machines are the time keepers. Alex > Best regards, Bruno. >> >> >> >> Best Rgds, >> >> Thanks, >> >> >> >> John.zhao >> >> >> >> ------------------------------------------------------------------------ >> >> >> *·¢¼þÈË:* Jong-Hyouk Lee [mailto:jonghyouk@gmail.com] *·¢ËÍʱ¼ä:* 2007Äê9Ô >> 14ÈÕ 15:15 *ÊÕ¼þÈË:* Bruno Mongazon-Cazavet *³­ËÍ:* netlmm@ietf.org *Ö÷Ìâ:* >> Re: [netlmm] LMA as a time keeper >> >> >> >> Dear Bruno. >> >> >> >> The introduced way seems to be simple and enough to end this issue. >> I take sides with this. >> >> >> >> Cheers. >> >> >> >> On 9/14/07, *Bruno Mongazon-Cazavet* >> > > wrote: >> >> An idea regarding PBU ordering problem: >> >> -The LMA is the time keeper -When a MAG boots, it sends a dummy PBU >> to the LMA to request current time (time synchronization). LMA >> provides current time in the PBU-Ack. MAG set its time to LMA time >> received in PBU-Ack (a latency can be added for network transit). >> -All MAG linked to the same LMA will get synchronized with LMA time >> this way -the timestamp option is then used in real PBU/PBU-ACK, >> because all MAG are synchronized they can be ordered by LMA -only >> related LMA's and MAG are synchronized this way. >> >> Stupid? >> >> Bruno. >> >> _______________________________________________ netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> >> >> >> >> >> -- Internet Management Technology Lab, Sungkyunkwan University. >> Jong-Hyouk Lee. >> >> #email: jonghyouk (at) gmail (dot) com #webpage: >> http://www.hurryon.org >> > > > ------------------------------------------------------------------------ > > > _______________________________________________ netlmm mailing list > netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 06:13:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW8B1-0001jM-0f; Fri, 14 Sep 2007 06:13:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW8Az-0001jC-56 for netlmm@ietf.org; Fri, 14 Sep 2007 06:13:29 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IW8Ay-0000Q2-QW for netlmm@ietf.org; Fri, 14 Sep 2007 06:13:29 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1189764808!23230020!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10576 invoked from network); 14 Sep 2007 10:13:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 14 Sep 2007 10:13:28 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8EADNQt002485 for ; Fri, 14 Sep 2007 03:13:27 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l8EADNod016046 for ; Fri, 14 Sep 2007 05:13:23 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l8EADLXc016034 for ; Fri, 14 Sep 2007 05:13:22 -0500 (CDT) Message-ID: <46EA5EC1.8020707@gmail.com> Date: Fri, 14 Sep 2007 12:13:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: netlmm Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-5, 13/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [netlmm] Other IETF protocols and time dependency X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Following my quest on what and how other IETF protocols depend on time, here's my current list; there may be errors. Timestamps in messages ---------------------- Mobile IPv4 RFC3344 -for security -requirement on entities be time synchronized SeND Secure Neighbor Discovery RFC3971 -for security -requirement on entities be time synchronized SCTP Stream Control Transmission Protocol RFC2960 -for security -no requirement on entities be time synchronized RTP A Transport Protocol for Real-Time Applications RFC3550 -for ordering -yes and no requirement on entities be time synchronized No timestamps in messages ------------------------- TCP RFC 793 ND Neighbor Discovery RFC 2461 ICMPv6 RFC 4443 BGP Border Gateway Protocol RFC4271 OSPF Open Shortest Path First RFC2328 Mobile IPv6 RFC3775 MOBIKE IKEv2 Mobility and Multihoming RFC4555 IKEv2 Internet Key Exchange RFC4306 Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 07:48:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9ew-0003Aj-Lu; Fri, 14 Sep 2007 07:48:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9ev-00034z-13 for netlmm@ietf.org; Fri, 14 Sep 2007 07:48:29 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW9et-0002uT-Ac for netlmm@ietf.org; Fri, 14 Sep 2007 07:48:28 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 13:47:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [netlmm] LMA as a time keeper Date: Fri, 14 Sep 2007 13:47:57 +0200 Message-ID: In-Reply-To: <46EA4DA5.5050807@alcatel-lucent.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] LMA as a time keeper Thread-Index: Acf2rcBZKo8IjUqCSPuegAzlsXm4gAAFzk+g References: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> <46EA4DA5.5050807@alcatel-lucent.fr> From: "SEITE Pierrick RD-RESA-REN" To: "Bruno Mongazon-Cazavet" , X-OriginalArrivalTime: 14 Sep 2007 11:47:58.0847 (UTC) FILETIME=[18CDA8F0:01C7F6C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: cb592aae7f4601895f35714165597859 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0394934835==" Errors-To: netlmm-bounces@ietf.org This is a multi-part message in MIME format. --===============0394934835== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7F6C5.18C21412" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7F6C5.18C21412 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQnJ1bm8sDQogDQpJZiBJIGNvcnJlY3RseSB1bmRlcnN0b29kIE1BRyBnZXQgc3luY2hyb25p emVkIHdpdGggTE1BIG9ubHkgd2hlbiBib290aW5nLCByaWdodD8gQnV0IGluIG9wZXJhdGlvbmFs IHN5c3RlbSBNQUdzIHdpbGwgbm90IG9mdGVuIHJlYm9vdCwgc28gaG93IGNhbiB5b3UgdGFrZSBp bnRvIGFjY291bnQgTUFHcyBkZXN5bmNocm9uaXphdGlvbiBkdWUgdG8gY2xvY2tzIGluZGVwZW5k ZW50IGRyaWZ0IHdoZW4gTUFHcyBydW4gZm9yIGEgbG9uZyB0aW1lPw0KIA0KQlIsDQpQaWVycmlj ayAgICANCiANCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkRlIDogQnJ1 bm8gTW9uZ2F6b24tQ2F6YXZldCBbbWFpbHRvOmJydW5vLm1vbmdhem9uLWNhemF2ZXRAYWxjYXRl bC1sdWNlbnQuZnJdIA0KRW52b3nDqSA6IHZlbmRyZWRpIDE0IHNlcHRlbWJyZSAyMDA3IDExOjAw DQrDgCA6IGpvaG4uemhhb0BodWF3ZWkuY29tDQpDYyA6IG5ldGxtbUBpZXRmLm9yZw0KT2JqZXQg OiBSZTogW25ldGxtbV0gTE1BIGFzIGEgdGltZSBrZWVwZXINCiANCkpvaG4uemhhbyB3cm90ZTog DQpIaSxhbGwNCiANCiAgICAgICAgIFRvIHRoaXMgbWV0aG9kICwgSSBkb3VidCB3aGV0aGVyIHNv bWV0aGluZyBuZWVkIHRvIGJlIGNsYXJpZmllZCBhdCB0aGUgZmlyc3Q6DQpJZiB3ZSBoYXZlIGFz c3VtZWQgdGhhdCBhbGwgb2YgdGhlIE1BRyBjYW4gbWFpbnRlbmFuY2UgdGhlIHNhbWUgY2xvY2sg d2l0aCB0aGUgTE1BIGFmdGVyIGl0IGdldCB0aGUgdGltZSBmcm9tIHRoYXQgTE1BPw0KW0JNXSBN QUcgY2FuIGVpdGhlcjoNCmEpIHNldCBpdHMgc3lzdGVtIHRpbWUgKG1hY2hpbmUgdGltZSkgYXMg dGhlIExNQSB0aW1lLiBJbiBzdWNoIGEgY2FzZSwgdGhlIHRpbWUgd2lsbCBiZSBtYWludGFpbmVk IGJ5IHRoZSBzeXN0ZW0NCmIpIGtlZXAgdGhpcyB0aW1lIGFzIGFuIGludGVybmFsIE1BRyB0aW1l LiBJbiBzdWNoIGEgY2FzZSBpdCBuZWVkcyB0byBtYWludGFpbiBpdCAgb24gaXRzIG93biB3aXRo IHRoZSBoZWxwIG9mIHRpbWluZyBmdW5jdGlvbnMgb2YgdGhlIHN5c3RlbS4gDQoNCg0KV2hhdCBp cyB0aGUgcHJlY2lzaW9uIHJlcXVpcmVtZW50IGZvciB0aGlzIHRpbWVzdGFtcCB1c2VkIGhlcmU/ DQpbQk1dIHNlY29uZCBvciBtaWxsaXNlY29uZCBpIGd1ZXNzDQoNCg0KSWYgY2FuIGV2ZXJ5IE1B RyBvbmx5IGNvbm5lY3QgdG8gb25lIExNQT8NCltCTV0gZ29vZCBwb2ludC4gQWNjb3JkaW5nIHRv IHRoZSBkcmFmdCBMTUEgY2FuIGNvbm5lY3QgdG8gbXVsdGlwbGUgTUFHLiBJbiBzdWNoIGEgY2Fz ZSwgZWFjaCBMTUEgcmVmZXJlbmNlIHRpbWUgc2hhbGwgYmUga2VwdCBhbmQgdXNlZCBzZXBhcmF0 ZWx5IGJ5IHRoZSBMTUEuIFdoaWNoIGluIHR1cm4gbWlnaHQgaW1wbHkgdGhhdCB0aW1lIGlzIG1h aW50YWluIGFzIGFuIGludGVybmFsIE1BRyB0aW1lLCB0aGF0IGlzIG9wdGlvbiBiKSBpbiBhYm92 ZSBxdWVzdGlvbi4NCg0KQmVzdCByZWdhcmRzLCBCcnVuby4NCg0KDQogDQpCZXN0IFJnZHMsDQpU aGFua3MsDQogDQpKb2huLnpoYW8NCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCuWPkeS7tuS6ujogSm9uZy1IeW91ayBMZWUgW21haWx0bzpqb25naHlvdWtAZ21haWwuY29t XSANCuWPkemAgeaXtumXtDogMjAwN+W5tDnmnIgxNOaXpSAxNToxNQ0K5pS25Lu25Lq6OiBCcnVu byBNb25nYXpvbi1DYXphdmV0DQrmioTpgIE6IG5ldGxtbUBpZXRmLm9yZw0K5Li76aKYOiBSZTog W25ldGxtbV0gTE1BIGFzIGEgdGltZSBrZWVwZXINCiANCkRlYXIgQnJ1bm8uDQogDQpUaGUgaW50 cm9kdWNlZCB3YXkgc2VlbXMgdG8gYmUgc2ltcGxlIGFuZCBlbm91Z2ggdG8gZW5kIHRoaXMgaXNz dWUuIEkgdGFrZSBzaWRlcyB3aXRoIHRoaXMuDQogDQpDaGVlcnMuDQoNCiANCk9uIDkvMTQvMDcs IEJydW5vIE1vbmdhem9uLUNhemF2ZXQgPGJydW5vLm1vbmdhem9uLWNhemF2ZXRAYWxjYXRlbC1s dWNlbnQuZnI+IHdyb3RlOiANCkFuIGlkZWEgcmVnYXJkaW5nIFBCVSBvcmRlcmluZyBwcm9ibGVt Og0KDQotVGhlIExNQSBpcyB0aGUgdGltZSBrZWVwZXINCi1XaGVuIGEgTUFHIGJvb3RzLCBpdCBz ZW5kcyBhIGR1bW15IFBCVSB0byB0aGUgTE1BIHRvIHJlcXVlc3QgY3VycmVudCANCnRpbWUgKHRp bWUgc3luY2hyb25pemF0aW9uKS4gTE1BIHByb3ZpZGVzIGN1cnJlbnQgdGltZSBpbiB0aGUgUEJV LUFjay4NCk1BRyBzZXQgaXRzIHRpbWUgdG8gTE1BIHRpbWUgcmVjZWl2ZWQgaW4gUEJVLUFjayAo YSBsYXRlbmN5IGNhbiBiZSBhZGRlZA0KZm9yIG5ldHdvcmsgdHJhbnNpdCkuDQotQWxsIE1BRyBs aW5rZWQgdG8gdGhlIHNhbWUgTE1BIHdpbGwgZ2V0IHN5bmNocm9uaXplZCB3aXRoIExNQSB0aW1l IHRoaXMgd2F5IA0KLXRoZSB0aW1lc3RhbXAgb3B0aW9uIGlzIHRoZW4gdXNlZCBpbiByZWFsIFBC VS9QQlUtQUNLLCBiZWNhdXNlIGFsbCBNQUcNCmFyZSBzeW5jaHJvbml6ZWQgdGhleSBjYW4gYmUg b3JkZXJlZCBieSBMTUENCi1vbmx5IHJlbGF0ZWQgTE1BJ3MgYW5kIE1BRyBhcmUgc3luY2hyb25p emVkIHRoaXMgd2F5Lg0KDQpTdHVwaWQ/DQoNCkJydW5vLg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bG1tIG1haWxpbmcgbGlzdA0KbmV0bG1t QGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRsbW0g DQoNCg0KDQotLSANCkludGVybmV0IE1hbmFnZW1lbnQgVGVjaG5vbG9neSBMYWIsIFN1bmdreXVu a3dhbiBVbml2ZXJzaXR5LiANCkpvbmctSHlvdWsgTGVlLg0KDQojZW1haWw6IGpvbmdoeW91ayAo YXQpIGdtYWlsIChkb3QpIGNvbSANCiN3ZWJwYWdlOiBodHRwOi8vd3d3Lmh1cnJ5b24ub3JnIA0K IA0K ------_=_NextPart_001_01C7F6C5.18C21412 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQoNCjxtZXRhIG5hbWU9UHJvZ0lkIGNv bnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jv c29mdCBXb3JkIDExIj4NCjxtZXRhIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3NvZnQg V29yZCAxMSI+DQo8bGluayByZWw9RmlsZS1MaXN0IGhyZWY9ImNpZDpmaWxlbGlzdC54bWxAMDFD N0Y2RDUuREI0NUNDNDAiPg0KPGxpbmsgcmVsPUVkaXQtVGltZS1EYXRhIGhyZWY9ImNpZDplZGl0 ZGF0YS5tc28iPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgj ZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOiog e2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZh dWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZQ0KIG5hbWVz cGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1l PSJQbGFjZVR5cGUiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJQbGFjZU5hbWUiLz4NCjxv OlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOnNtYXJ0dGFncyINCiBuYW1lPSJwbGFjZSIvPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQogPG86T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86UmVseU9uVk1MLz4NCiAgPG86RG9O b3RSZWx5T25DU1MvPg0KIDwvbzpPZmZpY2VEb2N1bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6V29yZERvY3VtZW50Pg0KICA8dzpE b250RGlzcGxheVBhZ2VCb3VuZGFyaWVzLz4NCiAgPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpT cGVsbGluZ1N0YXRlPg0KICA8dzpHcmFtbWFyU3RhdGU+Q2xlYW48L3c6R3JhbW1hclN0YXRlPg0K ICA8dzpEb2N1bWVudEtpbmQ+RG9jdW1lbnRFbWFpbDwvdzpEb2N1bWVudEtpbmQ+DQogIDx3Okh5 cGhlbmF0aW9uWm9uZT4yMTwvdzpIeXBoZW5hdGlvblpvbmU+DQogIDx3OkVudmVsb3BlVmlzLz4N CiAgPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQogIDx3OlNhdmVJZlhNTEludmFsaWQ+ZmFs c2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCiAgPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93 Oklnbm9yZU1peGVkQ29udGVudD4NCiAgPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxz ZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KICA8dzpDb21wYXRpYmlsaXR5Pg0KICAg PHc6VXNlRkVMYXlvdXQvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiA8L3c6V29yZERvY3VtZW50 Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPHc6TGF0ZW50 U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgTGF0ZW50U3R5bGVDb3VudD0iMTU2Ij4NCiA8 L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiAhbXNvXT4NCjxzdHls ZT4NCnN0MVw6KntiZWhhdmlvcjp1cmwoI2RlZmF1bHQjaWVvb3VpKSB9DQo8L3N0eWxlPg0KPCFb ZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7DQoJbXNvLWZvbnQtYWx0OlNpbVN1bjsNCgltc28tZm9udC1jaGFyc2V0OjEzNDsNCgltc28t Z2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDphdXRvOw0KCW1zby1m b250LXNpZ25hdHVyZTozIDEzNTEzNTIzMiAxNiAwIDI2MjE0NSAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0Ow0KCW1z by1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28t Zm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MTYyNzQyMTMxOSAtMjE0 NzQ4MzY0OCA4IDAgNjYwNDcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1 biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTsNCgltc28tZm9udC1jaGFyc2V0OjEz NDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LXBpdGNoOnZhcmlh YmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTozIDEzNTEzNTIzMiAxNiAwIDI2MjE0NSAwO30NCiAv KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpTaW1TdW47DQoJY29sb3I6YmxhY2s7fQ0KaDENCgl7bWFyZ2luLXRvcDoxMi4w cHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjEyLjBwdDsNCgltYXJnaW4t bGVmdDoyMS42cHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1p ZGVvZ3JhcGg7DQoJdGV4dC1pbmRlbnQ6LTIxLjZwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1v cnBoYW47DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCgltc28tb3V0bGluZS1sZXZlbDoxOw0K CW1zby1saXN0OmwwIGxldmVsMSBsZm8zOw0KCXRhYi1zdG9wczpsaXN0IDM2LjBwdDsNCglmb250 LXNpemU6MTYuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOmJsYWNrO30NCmgyDQoJ e21hcmdpbi10b3A6MTIuMHB0Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTox Mi4wcHQ7DQoJbWFyZ2luLWxlZnQ6MjguOHB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0 LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCXRleHQtaW5kZW50Oi0yOC44cHQ7DQoJbXNvLXBh Z2luYXRpb246d2lkb3ctb3JwaGFuOw0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLW91 dGxpbmUtbGV2ZWw6MjsNCgltc28tbGlzdDpsMCBsZXZlbDIgbGZvMzsNCgl0YWItc3RvcHM6bGlz dCA3Mi4wcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpBcmlhbDsNCgljb2xv cjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7fQ0KaDMNCgl7bWFyZ2luLXRvcDoxMy4wcHQ7 DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjEzLjBwdDsNCgltYXJnaW4tbGVm dDozNi4wcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVv Z3JhcGg7DQoJdGV4dC1pbmRlbnQ6LTM2LjBwdDsNCglsaW5lLWhlaWdodDoxNzIlOw0KCW1zby1w YWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1zby1v dXRsaW5lLWxldmVsOjM7DQoJbXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzM7DQoJdGFiLXN0b3BzOmxp c3QgMTA4LjBwdDsNCglsYXlvdXQtZ3JpZC1tb2RlOmNoYXI7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjpibGFjazsNCglmb250LXdl aWdodDpub3JtYWw7fQ0KaDQNCgl7bXNvLXN0eWxlLXVwZGF0ZTphdXRvOw0KCW1zby1zdHlsZS1w YXJlbnQ6IkNvcnBzIGRlIHRleHRlIjsNCgltc28tc3R5bGUtbmV4dDpOb3JtYWw7DQoJbWFyZ2lu LXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjYuMHB0Ow0KCW1h cmdpbi1sZWZ0OjQzLjJwdDsNCgl0ZXh0LWluZGVudDotNDMuMnB0Ow0KCW1zby1wYWdpbmF0aW9u OndpZG93LW9ycGhhbjsNCglwYWdlLWJyZWFrLWFmdGVyOmF2b2lkOw0KCW1zby1vdXRsaW5lLWxl dmVsOjQ7DQoJbXNvLWxpc3Q6bDIgbGV2ZWw0IGxmbzE7DQoJdGFiLXN0b3BzOmxpc3QgNDMuMnB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpBcmlhbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYW5zaS1s YW5ndWFnZTpJVDsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpwLk1zb0hlYWRlciwg bGkuTXNvSGVhZGVyLCBkaXYuTXNvSGVhZGVyDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRl b2dyYXBoOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglsYXlvdXQtZ3JpZC1tb2Rl OmNoYXI7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OlNpbVN1bjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0Zvb3RlciwgbGku TXNvRm9vdGVyLCBkaXYuTXNvRm9vdGVyDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6OS4wcHQ7 DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6U2ltU3VuOw0K CWNvbG9yOmJsYWNrO30NCnAuTXNvQm9keVRleHQsIGxpLk1zb0JvZHlUZXh0LCBkaXYuTXNvQm9k eVRleHQNCgl7bWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90 dG9tOjYuMHB0Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBo YW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTpTaW1TdW47fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11 bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxp bmU6c2luZ2xlO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246 d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpTaW1TdW47DQoJY29sb3I6YmxhY2s7 fQ0KcC5hLCBsaS5hLCBkaXYuYQ0KCXttc28tc3R5bGUtbmFtZTphOw0KCW1hcmdpbi10b3A6MGNt Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6 Mzc4LjQ1cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYXJhLW1hcmdpbi10b3A6 MS4wZ2Q7DQoJbXNvLXBhcmEtbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90 dG9tOjBjbTsNCgltc28tcGFyYS1tYXJnaW4tbGVmdDozNzguNDVwdDsNCgltc28tcGFyYS1tYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJdGV4dC1hbGlnbjpjZW50ZXI7DQoJdGV4dC1pbmRlbnQ6LTE4 LjQ1cHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCW1zby1saXN0OmwxIGxldmVs OSBsZm81Ow0KCXRhYi1zdG9wczpsaXN0IDMyNC4wcHQ7DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZv bnQtZmFtaWx5OkFyaWFsOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OlNpbVN1bjsNCgljb2xv cjpibGFjazt9DQpwLmEwLCBsaS5hMCwgZGl2LmEwDQoJe21zby1zdHlsZS1uYW1lOmEwOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93 LW9ycGhhbjsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OlNpbVN1bjsNCgljb2xvcjpibGFjazt9DQpwLmExLCBsaS5hMSwg ZGl2LmExDQoJe21zby1zdHlsZS1uYW1lOmExOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCXRleHQtYWxpZ246Y2VudGVyOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9y cGhhbjsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OlNpbVN1bjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpib2xk O30NCnAuYTIsIGxpLmEyLCBkaXYuYTINCgl7bXNvLXN0eWxlLW5hbWU6YTI7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNDIuNDVwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhcmEtbWFyZ2lu LXRvcDowY207DQoJbXNvLXBhcmEtbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tcGFyYS1tYXJnaW4t Ym90dG9tOjEuMGdkOw0KCW1zby1wYXJhLW1hcmdpbi1sZWZ0OjM0Mi40NXB0Ow0KCW1zby1wYXJh LW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmNlbnRlcjsNCgl0ZXh0LWluZGVu dDotMTguNDVwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJbXNvLWxpc3Q6bDEg bGV2ZWw4IGxmbzU7DQoJdGFiLXN0b3BzOmxpc3QgMjg4LjBwdDsNCglmb250LXNpemU6OS4wcHQ7 DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6U2ltU3VuOw0K CWNvbG9yOmJsYWNrO30NCnAuYTMsIGxpLmEzLCBkaXYuYTMNCgl7bXNvLXN0eWxlLW5hbWU6YTM7 DQoJbWFyZ2luLXRvcDo0LjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206 NC4wcHQ7DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCXRleHQtYWxpZ246Y2VudGVyOw0KCWxpbmUtaGVp Z2h0OjE1MCU7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCXBhZ2UtYnJlYWstYWZ0 ZXI6YXZvaWQ7DQoJbGF5b3V0LWdyaWQtbW9kZTpjaGFyOw0KCXRleHQtYXV0b3NwYWNlOm5vbmU7 DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpTaW1TdW47DQoJY29sb3I6YmxhY2s7fQ0KcC5hNCwgbGku YTQsIGRpdi5hNA0KCXttc28tc3R5bGUtbmFtZTphNDsNCgltYXJnaW4tdG9wOjE1LjBwdDsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MTUuMHB0Ow0KCW1hcmdpbi1sZWZ0OjBj bTsNCgl0ZXh0LWFsaWduOmNlbnRlcjsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJ Zm9udC1zaXplOjE4LjBwdDsNCglmb250LWZhbWlseTpBcmlhbDsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpTaW1TdW47DQoJY29sb3I6YmxhY2s7fQ0KcC5hNSwgbGkuYTUsIGRpdi5hNQ0KCXtt c28tc3R5bGUtbmFtZTphNTsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpTaW1T dW47DQoJY29sb3I6YmxhY2s7fQ0KcC5hNiwgbGkuYTYsIGRpdi5hNg0KCXttc28tc3R5bGUtbmFt ZTphNjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWdu Omp1c3RpZnk7DQoJdGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaDsNCgltc28tcGFnaW5hdGlv bjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0K CW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OlNpbVN1bjsNCgljb2xvcjpibGFjazt9DQpwLmE3LCBs aS5hNywgZGl2LmE3DQoJe21zby1zdHlsZS1uYW1lOmE3Ow0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50 ZXItaWRlb2dyYXBoOw0KCXRleHQtaW5kZW50OjE4LjBwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRv dy1vcnBoYW47DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OlNpbVN1bjsNCgljb2xvcjpibGFjazt9DQpwLmE4LCBsaS5hOCwg ZGl2LmE4DQoJe21zby1zdHlsZS1uYW1lOmE4Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1v cnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpBcmlhbDsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpTaW1TdW47DQoJY29sb3I6Ymx1ZTsNCglmb250LXN0eWxlOml0YWxp Yzt9DQpzcGFuLmE5DQoJe21zby1zdHlsZS1uYW1lOmE5Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjsN Cgltc28tYXNjaWktZm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OlNpbVN1bjsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6U2ltU3VuOw0KCWNvbG9yOmJsYWNrOw0K CWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5hYQ0KCXttc28tc3R5bGUtbmFtZTphYTsNCglmb250 LWZhbWlseTpTaW1TdW47DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OlNpbVN1bjsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpTaW1TdW47DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OlNpbVN1bjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpib2xkO30NCnNwYW4uRW1haWxTdHlsZTMzDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCWZvbnQt ZmFtaWx5OkFyaWFsOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpBcmlhbDsNCgltc28taGFuc2kt Zm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6 bmF2eTt9DQpzcGFuLmdtYWlscXVvdGUNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWxxdW90ZTt9DQpz cGFuLkVtYWlsU3R5bGUzNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28t c3R5bGUtbm9zaG93OnllczsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1zby1iaWRp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWFzY2lpLWZvbnQt ZmFtaWx5OkFyaWFsOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpBcmlhbDsNCgltc28tYmlkaS1m b250LWZhbWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCnNwYW4uU3BlbGxFDQoJe21zby1zdHls ZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5ZXM7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo1OTUu M3B0IDg0MS45cHQ7DQoJbWFyZ2luOjY1LjZwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsNCgltc28t aGVhZGVyLW1hcmdpbjozNS40cHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzUuNHB0Ow0KCW1zby1w YXBlci1zb3VyY2U6MDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQogLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQ3OTAwNjE7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjIxNDA1Mzg1ODQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWIt c3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDgu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWIt c3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjcyMTE5MzQyOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTU1MjY2MTc4Njt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1z dG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ e21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTczMjU3NTY1NDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6NzAyODQ0OTE0O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGV4dDolMTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjEuNnB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMS42cHQ7DQoJdGV4dC1pbmRlbnQ6LTIx LjZwdDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLXRleHQ6IiUxXC4lMiI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjI4LjhwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6MjguOHB0Ow0KCXRleHQtaW5kZW50Oi0yOC44cHQ7fQ0KQGxpc3QgbDI6 bGV2ZWwzDQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzIjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDozNi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTM2LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNv LWxldmVsLXN0eWxlLWxpbms6IlRpdHJlIDQiOw0KCW1zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUz XC4lNCI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQzLjJwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NDMuMnB0Ow0KCXRleHQtaW5kZW50Oi00My4ycHQ7 fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzXC4lNFwuJTUi Ow0KCW1zby1sZXZlbC10YWItc3RvcDo1MC40cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjUwLjRwdDsNCgl0ZXh0LWluZGVudDotNTAuNHB0O30NCkBs aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRcLiU1XC4lNiI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjU3LjZwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTcuNnB0Ow0KCXRleHQtaW5kZW50Oi01Ny42cHQ7fQ0KQGxp c3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzXC4lNFwuJTVcLiU2XC4l NyI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjY0LjhwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NjQuOHB0Ow0KCXRleHQtaW5kZW50Oi02NC44cHQ7fQ0K QGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC10ZXh0OiIlMVwuJTJcLiUzXC4lNFwuJTVcLiU2 XC4lN1wuJTgiOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjcyLjBwdDsNCgl0ZXh0LWluZGVudDotNzIu MHB0O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcLiUyXC4lM1wuJTRc LiU1XC4lNlwuJTdcLiU4XC4lOSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjc5LjJwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NzkuMnB0Ow0KCXRleHQt aW5kZW50Oi03OS4ycHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowY207fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDEwXT4NCjxzdHls ZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLyANCiB0YWJsZS5Nc29Ob3JtYWxUYWJsZQ0KCXtt c28tc3R5bGUtbmFtZToiVGFibGVhdSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXpl OjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsN Cgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDowY20gNS40cHQgMGNtIDUu NHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowY207DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1hbnNpLWxhbmd1YWdlOiMwNDAw Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOiMwNDAwOw0KCW1zby1iaWRpLWxhbmd1YWdlOiMwNDAw O30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGJnY29sb3I9d2hpdGUgbGFu Zz1GUiBsaW5rPWJsdWUgdmxpbms9Ymx1ZSBzdHlsZT0ndGFiLWludGVydmFsOjM1LjRwdCc+DQoN CjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnk7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4t R0InPkhpDQpCcnVubyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVO LUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5 O21zby1hbnNpLWxhbmd1YWdlOkVOLUdCJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1B cmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpuYXZ5O21zby1hbnNpLWxhbmd1YWdlOkVOLUdCJz5JZg0KSSBjb3JyZWN0 bHkgdW5kZXJzdG9vZCBNQUcgZ2V0IHN5bmNocm9uaXplZCB3aXRoIExNQSBvbmx5IHdoZW4gYm9v dGluZywgcmlnaHQ/IEJ1dA0KaW4gb3BlcmF0aW9uYWwgc3lzdGVtIDxzcGFuIGNsYXNzPVNwZWxs RT5NQUdzPC9zcGFuPiB3aWxsIG5vdCBvZnRlbiByZWJvb3QsIHNvIGhvdw0KY2FuIHlvdSB0YWtl IGludG8gYWNjb3VudCA8c3BhbiBjbGFzcz1TcGVsbEU+TUFHczwvc3Bhbj4gPHNwYW4gY2xhc3M9 U3BlbGxFPmRlc3luY2hyb25pemF0aW9uPC9zcGFuPg0KZHVlIHRvIGNsb2NrcyBpbmRlcGVuZGVu dCBkcmlmdCB3aGVuIDxzcGFuIGNsYXNzPVNwZWxsRT5NQUdzPC9zcGFuPiBydW4gZm9yIGENCmxv bmcgdGltZT88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5O21zby1h bnNpLWxhbmd1YWdlOkVOLUdCJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48 c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlh bDtjb2xvcjpuYXZ5O21zby1hbnNpLWxhbmd1YWdlOkVOLUdCJz5CUiw8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5h dnkgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5O21zby1hbnNpLWxhbmd1YWdlOkVOLUdCJz5QaWVy cmljaw0KPHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPiZuYnNwOzwvc3Bhbj48c3Bhbg0K c3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPiZuYnNwOzwvc3Bhbj48c3Bhbg0Kc3R5bGU9J21zby1z cGFjZXJ1bjp5ZXMnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5h dnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwg YWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpjb2xv cj1ibGFjayBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTpTaW1TdW47DQptc28tYmlkaS1mb250LWZhbWlseTpTaW1TdW47Y29sb3I6d2luZG93dGV4 dCc+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT4N Cg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNp emU9MiBjb2xvcj1ibGFjayBmYWNlPVRhaG9tYT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6VGFob21hO2NvbG9yOndpbmRvd3RleHQ7Zm9udC13ZWlnaHQ6Ym9sZCc+ RGUmbmJzcDs6PC9zcGFuPjwvZm9udD48L2I+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNl PVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7 DQpjb2xvcjp3aW5kb3d0ZXh0Jz4gQnJ1bm8gTW9uZ2F6b24tQ2F6YXZldA0KW21haWx0bzpicnVu by5tb25nYXpvbi1jYXphdmV0QGFsY2F0ZWwtbHVjZW50LmZyXSA8YnI+DQo8Yj48c3BhbiBzdHls ZT0nZm9udC13ZWlnaHQ6Ym9sZCc+RW52b3nDqSZuYnNwOzo8L3NwYW4+PC9iPiB2ZW5kcmVkaSAx NA0Kc2VwdGVtYnJlIDIwMDcgMTE6MDA8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6 Ym9sZCc+JkFncmF2ZTsmbmJzcDs6PC9zcGFuPjwvYj4gam9obi56aGFvQGh1YXdlaS5jb208YnI+ DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2MmbmJzcDs6PC9zcGFuPjwvYj4g bmV0bG1tQGlldGYub3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPk9i amV0Jm5ic3A7Ojwvc3Bhbj48L2I+IFJlOiBbbmV0bG1tXSBMTUEgYXMgYQ0KdGltZSBrZWVwZXI8 L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPWJsYWNrIGZhY2U9U2ltU3VuPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToNClNpbVN1bjttc28tYmlkaS1mb250LWZhbWlseTpTaW1TdW47Y29sb3I6d2lu ZG93dGV4dCc+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgY29sb3I9 YmxhY2sgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMi4w cHQnPkpvaG4uemhhbyB3cm90ZTogPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MSBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4g bGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpuYXZ5O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48dTE6U21hcnRUYWdUeXBlIG5hbWVzcGFj ZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1lPSJw bGFjZSI+PHUxOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFtZT0iUGxhY2VOYW1lIj48dTE6U21hcnRUYWdUeXBl IG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdz IiBuYW1lPSJQbGFjZVR5cGUiPjx1MTpTbWFydFRhZ1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIG5hbWU9ImNoc2RhdGUiPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KICAgICA8dTE6c2hhcGVkZWZhdWx0cyB1MjpleHQ9ImVkaXQi IHNwaWRtYXg9IjIwNzkiLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KICAgICA8dTE6c2hhcGVsYXlvdXQgdTM6ZXh0PSJlZGl0Ij4NCiAgICAgIDx1MTppZG1h cCB1MzpleHQ9ImVkaXQiIGRhdGE9IjIiLz4NCiAgICAgIDx1MTpyZWdyb3VwdGFibGUgdTM6ZXh0 PSJlZGl0Ij4NCiAgICAgICA8dTE6ZW50cnkgbmV3PSIxIiBvbGQ9IjAiLz4NCiAgICAgIDwvdTE6 cmVncm91cHRhYmxlPg0KICAgICA8L3UxOnNoYXBlbGF5b3V0Pg0KPC94bWw+PCFbZW5kaWZdLS0+ PC91MTpTbWFydFRhZ1R5cGU+PC91MTpTbWFydFRhZ1R5cGU+PC91MTpTbWFydFRhZ1R5cGU+PC91 MTpTbWFydFRhZ1R5cGU+SGksYWxsPHUxOnA+PC91MTpwPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTEgY29sb3I9bmF2eSBmYWNl PUFyaWFsPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6bmF2eTttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PHUxOnA+Jm5ic3A7 PC91MTpwPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTEgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tVVMNCnN0 eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eTttc28tYW5z aS1sYW5ndWFnZTpFTi1VUyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQpUbyB0aGlzIG1ldGhvZCAsIEkgZG91YnQgd2hldGhlciBzb21ldGhpbmcgbmVl ZCB0byBiZSBjbGFyaWZpZWQgYXQgdGhlIGZpcnN0Ojx1MTpwPjwvdTE6cD48L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 OjYwLjBwdDt0ZXh0LWluZGVudDotMTguMHB0Jz48Zm9udCBzaXplPTENCmNvbG9yPW5hdnkgZmFj ZT1BcmlhbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7DQpjb2xvcjpuYXZ5O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz5JZiB3ZSBoYXZl IGFzc3VtZWQgdGhhdCBhbGwgb2YgdGhlIE1BRyBjYW4NCm1haW50ZW5hbmNlIHRoZSBzYW1lIGNs b2NrIHdpdGggdGhlIExNQSBhZnRlciBpdCBnZXQgdGhlIHRpbWUgZnJvbSB0aGF0IExNQT88L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0zIGNvbG9yPWJsYWNrIGZhY2U9U2ltU3VuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1iaWRpLWZvbnQtZmFtaWx5OlNpbVN1bic+W0JNXSBN QUcgY2FuIGVpdGhlcjo8YnI+DQphKSBzZXQgaXRzIHN5c3RlbSB0aW1lIChtYWNoaW5lIHRpbWUp IGFzIHRoZSBMTUEgdGltZS4gSW4gc3VjaCBhIGNhc2UsIHRoZSB0aW1lDQp3aWxsIGJlIG1haW50 YWluZWQgYnkgdGhlIHN5c3RlbTxicj4NCmIpIGtlZXAgdGhpcyB0aW1lIGFzIGFuIGludGVybmFs IE1BRyB0aW1lLiBJbiBzdWNoIGEgY2FzZSBpdCBuZWVkcyB0byBtYWludGFpbg0KaXQmbmJzcDsg b24gaXRzIG93biB3aXRoIHRoZSBoZWxwIG9mIHRpbWluZyBmdW5jdGlvbnMgb2YgdGhlIHN5c3Rl bS4gPGJyDQpzdHlsZT0nbXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsnPg0KPCFbaWYg IXN1cHBvcnRMaW5lQnJlYWtOZXdMaW5lXT48YnIgc3R5bGU9J21zby1zcGVjaWFsLWNoYXJhY3Rl cjpsaW5lLWJyZWFrJz4NCjwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjYwLjBwdDt0ZXh0LWluZGVu dDotMTguMHB0Jz48Zm9udCBzaXplPTENCmNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7DQpjb2xvcjpu YXZ5O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48dTE6cD48L3UxOnA+V2hhdCBpcyB0aGUgcHJl Y2lzaW9uDQpyZXF1aXJlbWVudCBmb3IgdGhpcyB0aW1lc3RhbXAgdXNlZCBoZXJlPzwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMg Y29sb3I9YmxhY2sgZmFjZT1TaW1TdW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdDtm b250LWZhbWlseTpTaW1TdW47bXNvLWJpZGktZm9udC1mYW1pbHk6U2ltU3VuJz5bQk1dIHNlY29u ZCBvcg0KbWlsbGlzZWNvbmQgaSBndWVzczxiciBzdHlsZT0nbXNvLXNwZWNpYWwtY2hhcmFjdGVy OmxpbmUtYnJlYWsnPg0KPCFbaWYgIXN1cHBvcnRMaW5lQnJlYWtOZXdMaW5lXT48YnIgc3R5bGU9 J21zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrJz4NCjwhW2VuZGlmXT48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0OjYwLjBwdDt0ZXh0LWluZGVudDotMTguMHB0Jz48Zm9udCBzaXplPTENCmNvbG9yPW5hdnkg ZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6QXJpYWw7DQpjb2xvcjpuYXZ5O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48dTE6cD48 L3UxOnA+SWYgY2FuIGV2ZXJ5IE1BRyBvbmx5IGNvbm5lY3QNCnRvIG9uZSBMTUE/PC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBj b2xvcj1ibGFjayBmYWNlPVNpbVN1bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bjttc28tYmlkaS1mb250LWZhbWlseTpTaW1TdW4nPltCTV0gZ29vZCBw b2ludC4NCkFjY29yZGluZyB0byB0aGUgZHJhZnQgTE1BIGNhbiBjb25uZWN0IHRvIG11bHRpcGxl IE1BRy4gSW4gc3VjaCBhIGNhc2UsIGVhY2gNCkxNQSByZWZlcmVuY2UgdGltZSBzaGFsbCBiZSBr ZXB0IGFuZCB1c2VkIHNlcGFyYXRlbHkgYnkgdGhlIExNQS4gV2hpY2ggaW4gdHVybg0KbWlnaHQg aW1wbHkgdGhhdCB0aW1lIGlzIG1haW50YWluIGFzIGFuIGludGVybmFsIE1BRyB0aW1lLCB0aGF0 IGlzIG9wdGlvbiBiKSBpbg0KYWJvdmUgcXVlc3Rpb24uPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRz LCBCcnVuby48YnIgc3R5bGU9J21zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrJz4NCjwh W2lmICFzdXBwb3J0TGluZUJyZWFrTmV3TGluZV0+PGJyIHN0eWxlPSdtc28tc3BlY2lhbC1jaGFy YWN0ZXI6bGluZS1icmVhayc+DQo8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDo0Mi4wcHQnPjxmb250 IHNpemU9MSBjb2xvcj1uYXZ5DQpmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOm5hdnk7bXNvLWFuc2ktbGFu Z3VhZ2U6RU4tVVMnPjx1MTpwPjwvdTE6cD48dTE6cD4mbmJzcDs8L3UxOnA+PC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDoyMS4wcHQnPjxmb250IHNpemU9MSBjb2xvcj1uYXZ5DQpmYWNlPUFyaWFsPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOm5h dnk7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPkJlc3QgUmdkcyw8dTE6cD48L3UxOnA+PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MSBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gbGFuZz1FTi1VUw0Kc3R5bGU9J2ZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5O21zby1hbnNpLWxhbmd1YWdlOkVO LVVTJz5UaGFua3MsPHUxOnA+PC91MTpwPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTEgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxz cGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6bmF2eTttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PHUxOnA+Jm5ic3A7PC91MTpwPjwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTEgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eTttc28tYW5zaS1sYW5ndWFn ZTpFTi1VUyc+Sm9obi56aGFvPHUxOnA+PC91MTpwPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTEgY29sb3I9bmF2eSBmYWNlPUFy aWFsPjxzcGFuIGxhbmc9RU4tVVMNCnN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6bmF2eTttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+PHUxOnA+Jm5ic3A7PC91 MTpwPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdDsNCmJvcmRlci1jb2xvcjotbW96LXVzZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQt Y29sb3IgLW1vei11c2UtdGV4dC1jb2xvciBibHVlJz4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1N c29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6 ZT0zDQpjb2xvcj1ibGFjayBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+DQoNCjxo ciBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT4NCg0KPC9zcGFu PjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MiBjb2xv cj1ibGFjayBmYWNlPVNpbVN1bj48c3BhbiBsYW5nPVpILUNODQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTaW1TdW47Zm9udC13ZWlnaHQ6Ym9sZCc+5Y+R5Lu25Lq6PC9zcGFu PjwvZm9udD48L2I+PGI+PGZvbnQNCnNpemU9MiBmYWNlPVNpbVN1bj48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjsNCm1zby1hbnNpLWxh bmd1YWdlOkVOLVVTO2ZvbnQtd2VpZ2h0OmJvbGQnPjo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBz aXplPTINCmZhY2U9U2ltU3VuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6U2ltU3VuOw0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPiBKb25nLUh5 b3VrIExlZSBbPGEgaHJlZj0ibWFpbHRvOmpvbmdoeW91a0BnbWFpbC5jb20iPm1haWx0bzpqb25n aHlvdWtAZ21haWwuY29tPC9hPl0NCjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGI+PGZvbnQgc2l6ZT0y IGZhY2U9U2ltU3VuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtm b250LWZhbWlseTpTaW1TdW47Zm9udC13ZWlnaHQ6Ym9sZCc+5Y+R6YCB5pe26Ze0PC9zcGFuPjwv Zm9udD48L2I+PGI+PGZvbnQNCnNpemU9MiBmYWNlPVNpbVN1bj48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjsNCm1zby1hbnNpLWxhbmd1 YWdlOkVOLVVTO2ZvbnQtd2VpZ2h0OmJvbGQnPjo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXpl PTINCmZhY2U9U2ltU3VuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U2ltU3VuOw0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPiA8c3QxOmNoc2Rh dGUgaXNyb2NkYXRlPSJGYWxzZSIgaXNsdW5hcmRhdGU9IkZhbHNlIiBkYXk9IjE0IiBtb250aD0i OSIgeWVhcj0iMjAwNyIgdTQ6c3Q9Im9uIj4yMDA3PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0y IGZhY2U9U2ltU3VuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U2ltU3VuOw0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPuW5tDwvc3Bhbj48L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9U2ltU3VuPjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+ OTwvc3Bhbj48L2ZvbnQ+PGZvbnQNCnNpemU9MiBmYWNlPVNpbVN1bj48c3BhbiBsYW5nPVpILUNO IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjsNCm1zby1hbnNpLWxh bmd1YWdlOkVOLVVTJz7mnIg8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPVNpbVN1bj48 c3Bhbg0KbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T dW47bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjE0PC9zcGFuPjwvZm9udD48Zm9udA0Kc2l6ZT0y IGZhY2U9U2ltU3VuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U2ltU3VuOw0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPuaXpTwvc3QxOmNoc2Rh dGU+PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT1TaW1TdW4+PHNwYW4NCmxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1hbnNpLWxh bmd1YWdlOkVOLVVTJz4NCjE1OjE1PGJyPg0KPC9zcGFuPjwvZm9udD48Yj48Zm9udCBzaXplPTIg ZmFjZT1TaW1TdW4+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2Zv bnQtZmFtaWx5OlNpbVN1bjtmb250LXdlaWdodDpib2xkJz7mlLbku7bkuro8L3NwYW4+PC9mb250 PjwvYj48Yj48Zm9udA0Kc2l6ZT0yIGZhY2U9U2ltU3VuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuOw0KbXNvLWFuc2ktbGFuZ3VhZ2U6 RU4tVVM7Zm9udC13ZWlnaHQ6Ym9sZCc+Ojwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9Mg0K ZmFjZT1TaW1TdW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpTaW1TdW47DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+IEJydW5vIE1vbmdhem9u LUNhemF2ZXQ8YnI+DQo8L3NwYW4+PC9mb250PjxiPjxmb250IHNpemU9MiBmYWNlPVNpbVN1bj48 c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2ZvbnQtd2VpZ2h0OmJvbGQnPuaKhOmAgTwvc3Bhbj48L2ZvbnQ+PC9iPjxiPjxmb250DQpz aXplPTIgZmFjZT1TaW1TdW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTaW1TdW47DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUztmb250LXdlaWdo dDpib2xkJz46PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpmYWNlPVNpbVN1bj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjsN Cm1zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz4gPGEgaHJlZj0ibWFpbHRvOm5ldGxtbUBpZXRmLm9y ZyI+bmV0bG1tQGlldGYub3JnPC9hPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGI+PGZvbnQgc2l6ZT0y IGZhY2U9U2ltU3VuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtm b250LWZhbWlseTpTaW1TdW47Zm9udC13ZWlnaHQ6Ym9sZCc+5Li76aKYPC9zcGFuPjwvZm9udD48 L2I+PGI+PGZvbnQNCnNpemU9MiBmYWNlPVNpbVN1bj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjsNCm1zby1hbnNpLWxhbmd1YWdlOkVO LVVTO2ZvbnQtd2VpZ2h0OmJvbGQnPjo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPTINCmZh Y2U9U2ltU3VuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6U2ltU3VuOw0KbXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPiBSZTogW25ldGxtbV0gTE1B IGFzIGEgdGltZSBrZWVwZXI8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPHUxOnA+PC91MTpwPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsYWNrIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjx1MTpwPiZuYnNwOzwvdTE6 cD48L3NwYW4+PG86cD48L286cD48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCmxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPjx1 NTpzaGFwZXR5cGUgaWQ9Il94MDAwMF90NzQiIGNvb3Jkc2l6ZT0iMjE2MDAsMjE2MDAiIHUxOnNw dD0iNzQiIHBhdGg9Im0xMDg2MCwyMTg3YzEwNDUxLDE3NDYsOTUyOSwxMDE4LDkwMTUsNzMwLDc4 NjUsMTUyLDY2ODUsLDU0MTUsLDQxNzUsMTUyLDI5OTUsNTc1LDE5NjcsMTMwNSwxMTUwLDIxODcs NTc1LDMyMjIsMjQyLDQyMjAsLDU0MTAsMjQyLDY1NjAsNTc1LDc1OTdsMTA4NjAsMjE2MDAsMjA5 OTUsNzU5N3Y0ODUsLTEwMzcsNjA1LC0yMTg3LDQ4NSwtMzM3N2MyMTExNSwzMjIyLDIwNDIwLDIx ODcsMTk2MzIsMTMwNSwxODU3NSw1NzUsMTc0MjUsMTUyLDE2Mjc1LCwxNTAwNSwsMTM3MzUsMTUy LDEyNzA1LDczMHYtNTI5LDI4OCwtMTQ1MSwxMDE2LC0xODQ1LDE0NTd4ZSI+PHU1OnN0cm9rZSBq b2luc3R5bGU9Im1pdGVyIi8+PHU1OnBhdGggZ3JhZGllbnRzaGFwZW9rPSJ0IiB1MTpjb25uZWN0 dHlwZT0iY3VzdG9tIiB1MTpjb25uZWN0bG9jcz0iMTA4NjAsMjE4NzsyOTI4LDEwODAwOzEwODYw LDIxNjAwOzE4NjcyLDEwODAwIiB1MTpjb25uZWN0YW5nbGVzPSIyNzAsMTgwLDkwLDAiIHRleHRi b3hyZWN0PSI1MDM3LDIyNzcsMTY1NTcsMTM2NzciLz48L3U1OnNoYXBldHlwZT48dTU6c2hhcGUg aWQ9IkR0c1NoYXBlTmFtZSIgdTE6c3BpZD0iX3gwMDAwX3MyMDc4IiB0eXBlPSIjX3gwMDAwX3Q3 NCIgYWx0PSIzNzAxRTVCODA3MjU1NjhFOTE3MUJAM0dHQEU2OEMxNzA2OCZsdDs4ZjY4PzgmZ3Q7 WzU4ODQxISEhISEhQklIT0BdezU4ODQxISEhQjFAOTc1QDkxMzExNUI1RzVHNDFPbnNsYG0vZW51 ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISYjMTM7JiMxMDshISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEmIzEzOyYjMTA7ISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhJiMxMzsmIzEwOyEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhITEhPSIgc3R5bGU9 InBvc2l0aW9uOmFic29sdXRlO21hcmdpbi1sZWZ0OjA7bWFyZ2luLXRvcDowO3dpZHRoOi4wNXB0 O2hlaWdodDouMDVwdDsmIzEzOyYjMTA7IHotaW5kZXg6MTt2aXNpYmlsaXR5OmhpZGRlbiI+PHU0 OmFuY2hvcmxvY2svPjwvdTU6c2hhcGU+RGVhcg0KQnJ1bm8uPHUxOnA+PC91MTpwPjwvc3Bhbj48 bzpwPjwvbzpwPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgY29sb3I9YmxhY2sgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+Jm5i c3A7PHUxOnA+PC91MTpwPjwvc3Bhbj48bzpwPjwvbzpwPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsYWNrIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox Mi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPlRoZSBpbnRyb2R1Y2VkDQp3YXkmbmJzcDtz ZWVtcyB0byBiZSZuYnNwO3NpbXBsZSBhbmQgZW5vdWdoIHRvIGVuZCB0aGlzIGlzc3VlLiBJIHRh a2Ugc2lkZXMNCndpdGggdGhpcy48dTE6cD48L3UxOnA+PC9zcGFuPjxvOnA+PC9vOnA+PC9mb250 PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTMgY29sb3I9YmxhY2sgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEyLjBwdDttc28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+Jm5ic3A7PHUx OnA+PC91MTpwPjwvc3Bhbj48bzpwPjwvbzpwPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsYWNrIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7 bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPkNoZWVycy48YnI+DQo8YnI+DQombmJzcDs8dTE6cD48 L3UxOnA+PC9zcGFuPjxvOnA+PC9vOnA+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1nbWFpbHF1b3RlPjxmb250IHNpemU9MyBj b2xvcj1ibGFjaw0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6MTIuMHB0O21zby1hbnNpLWxhbmd1YWdlOg0KRU4tVVMnPk9uIDxzdDE6Y2hz ZGF0ZSBpc3JvY2RhdGU9IkZhbHNlIiBpc2x1bmFyZGF0ZT0iRmFsc2UiIGRheT0iMTQiIG1vbnRo PSI5IiB5ZWFyPSIyMDA3IiB1NDpzdD0ib24iPjkvMTQvMDc8L3N0MTpjaHNkYXRlPiwNCjxiPjxz cGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5CcnVubyBNb25nYXpvbi1DYXphdmV0PC9zcGFu PjwvYj4gJmx0OzxhDQpocmVmPSJtYWlsdG86YnJ1bm8ubW9uZ2F6b24tY2F6YXZldEBhbGNhdGVs LWx1Y2VudC5mciI+YnJ1bm8ubW9uZ2F6b24tY2F6YXZldEBhbGNhdGVsLWx1Y2VudC5mcjwvYT4m Z3Q7DQp3cm90ZTo8L3NwYW4+PC9mb250Pjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdt c28tYW5zaS1sYW5ndWFnZTpFTi1VUyc+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHUxOnA+ PC91MTpwPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsYWNrIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox Mi4wcHQ7bXNvLWFuc2ktbGFuZ3VhZ2U6RU4tVVMnPkFuIGlkZWEgcmVnYXJkaW5nDQpQQlUgb3Jk ZXJpbmcgcHJvYmxlbTo8YnI+DQo8YnI+DQotVGhlIExNQSBpcyB0aGUgdGltZSBrZWVwZXI8YnI+ DQotV2hlbiBhIE1BRyBib290cywgaXQgc2VuZHMgYSBkdW1teSBQQlUgdG8gdGhlIExNQSB0byBy ZXF1ZXN0IGN1cnJlbnQgPGJyPg0KdGltZSAodGltZSBzeW5jaHJvbml6YXRpb24pLiBMTUEgcHJv dmlkZXMgY3VycmVudCB0aW1lIGluIHRoZSBQQlUtQWNrLjxicj4NCk1BRyBzZXQgaXRzIHRpbWUg dG8gTE1BIHRpbWUgcmVjZWl2ZWQgaW4gUEJVLUFjayAoYSBsYXRlbmN5IGNhbiBiZSBhZGRlZDxi cj4NCmZvciBuZXR3b3JrIHRyYW5zaXQpLjxicj4NCi1BbGwgTUFHIGxpbmtlZCB0byB0aGUgc2Ft ZSBMTUEgd2lsbCBnZXQgc3luY2hyb25pemVkIHdpdGggTE1BIHRpbWUgdGhpcyB3YXkgPGJyPg0K LXRoZSB0aW1lc3RhbXAgb3B0aW9uIGlzIHRoZW4gdXNlZCBpbiByZWFsIFBCVS9QQlUtQUNLLCBi ZWNhdXNlIGFsbCBNQUc8YnI+DQphcmUgc3luY2hyb25pemVkIHRoZXkgY2FuIGJlIG9yZGVyZWQg YnkgTE1BPGJyPg0KLW9ubHkgcmVsYXRlZCBMTUEncyBhbmQgTUFHIGFyZSBzeW5jaHJvbml6ZWQg dGhpcyB3YXkuPGJyPg0KPGJyPg0KU3R1cGlkPzxicj4NCjxicj4NCkJydW5vLjxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0 bG1tIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRsbW1AaWV0Zi5vcmciPm5l dGxtbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRsbW0iPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGxtbQ0KPC9hPjx1MTpwPjwvdTE6cD48L3NwYW4+PG86cD48L286cD48L2ZvbnQ+PC9w Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFj ayBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQpsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O21zby1hbnNpLWxhbmd1YWdlOkVOLVVTJz48YnI+DQo8YnIgY2xlYXI9YWxsPg0K PGJyPg0KLS0gPGJyPg0KSW50ZXJuZXQgTWFuYWdlbWVudCBUZWNobm9sb2d5IExhYiwgPHN0MTpw bGFjZSB1NDpzdD0ib24iPjxzdDE6UGxhY2VOYW1lIHU0OnN0PSJvbiI+PHN0MTpwbGFjZQ0Kdzpz dD0ib24iPjxzdDE6UGxhY2VOYW1lIHc6c3Q9Im9uIj5TdW5na3l1bmt3YW48L3N0MTpQbGFjZU5h bWU+PC9zdDE6UGxhY2VOYW1lPg0KIDxzdDE6UGxhY2VUeXBlIHU0OnN0PSJvbiI+PHN0MTpQbGFj ZVR5cGUgdzpzdD0ib24iPlVuaXZlcnNpdHk8L3N0MTpQbGFjZVR5cGU+PC9zdDE6cGxhY2U+PC9z dDE6UGxhY2VUeXBlPjwvc3QxOnBsYWNlPi4NCjxicj4NCkpvbmctSHlvdWsgTGVlLjxicj4NCjxi cj4NCiNlbWFpbDogam9uZ2h5b3VrIChhdCkgZ21haWwgKGRvdCkgY29tIDxicj4NCiN3ZWJwYWdl OiA8YSBocmVmPSJodHRwOi8vd3d3Lmh1cnJ5b24ub3JnIj5odHRwOi8vd3d3Lmh1cnJ5b24ub3Jn PC9hPiA8dTE6cD48L3UxOnA+PC9zcGFuPjxvOnA+PC9vOnA+PC9mb250PjwvcD4NCg0KPC9kaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgY29sb3I9YmxhY2sgZmFjZT1TaW1T dW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdDtmb250LWZhbWlseTpTaW1TdW47bXNv LWJpZGktZm9udC1mYW1pbHk6U2ltU3VuJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01C7F6C5.18C21412-- --===============0394934835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0394934835==-- From netlmm-bounces@ietf.org Fri Sep 14 07:53:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9jN-0004BD-9d; Fri, 14 Sep 2007 07:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9jL-00045w-Lm for netlmm@ietf.org; Fri, 14 Sep 2007 07:53:03 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW9jJ-0002mc-Tc for netlmm@ietf.org; Fri, 14 Sep 2007 07:53:03 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8EBqFpt022602; Fri, 14 Sep 2007 13:52:15 +0200 Received: from [172.27.205.222] ([172.27.205.222]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Fri, 14 Sep 2007 13:52:53 +0200 Message-ID: <46EA7615.1040503@alcatel-lucent.fr> Date: Fri, 14 Sep 2007 13:52:53 +0200 From: Bruno Mongazon-Cazavet User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Jong-Hyouk Lee Subject: Re: [netlmm] LMA as a time keeper References: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> In-Reply-To: X-OriginalArrivalTime: 14 Sep 2007 11:52:53.0036 (UTC) FILETIME=[C82756C0:01C7F6C5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-MIME-Autoconverted: from 8bit to quoted-printable by smail5.alcatel.fr id l8EBqFpt022602 X-Spam-Score: 2.3 (++) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1022113898==" Errors-To: netlmm-bounces@ietf.org --===============1022113898== Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Jong-Hyouk Lee wrote:
Hi, all.
 
To get the time synchronization by the introduced method, eve= ry MAG knows which LMA is the time sync LMA in case of multiple LM= As in the domain. It means that every MAG only not connect to one LMA. Als= o, all LMA should share the same time information by other way,&nb= sp; e.g., NTP.
[BM] To be check but i think that it is not necessary that all LMA be time synchronized.
Basically, each LMA needs to be capable to re-order PBU from the MAGs it is connected to. If all MAGs share the same time for this LMA, then MAG can make re-ordering. This implies that when a MAG first connects to a LMA, it gets its time first.

 
Cheers.

 
On 9/14/07, John.zhao <john.zhao@huawei.com> wrote:=

Hi,all

 

         To this method , I doubt whether something need to be clarified at the first:

1)     =   If we have assumed that all of the MAG can maintenance the same clock with the LMA after it get the time from that LMA?

2)     =   What is the precision requirement for this timestamp used here?

3)     =   If can every MAG only connect to one LMA?

 

Best Rgds,

Thanks,

 

John.zhao

 

=B7=A2= =BC=FE=C8=CB: Jong-Hyo= uk Lee [mailto:jonghyouk@gmail.co= m]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2007=C4=EA9 =D4=C214=C8=D5 15:15
=CA=D5= =BC=FE=C8=CB: Bruno Mongazon-Cazavet
=B3=AD= =CB=CD: netlmm@ietf.org
=D6=F7= =CC=E2: Re: [netlmm] LMA as a time keeper

 

De= ar Bruno.

 

The introduced way seems = to be simple and enough to end this issue. I take sides with this.

 

Cheers.

 

On 9/14/07, Bruno Mongazon-Cazavet < bruno.mongazon-cazavet@alcatel-lucent.fr> wrote:

An idea regarding PBU ordering problem:

-The LMA is the time keeper
-When a MAG boots, it sends a dummy PBU to the LMA to request current time (time synchronization). LMA provides current time in the PBU-Ack. MAG set its time to LMA time received in PBU-Ack (a latency can be added<= br> for network transit).
-All MAG linked to the same LMA will get synchronized with LMA time this way
-the timestamp option is then used in real PBU/PBU-ACK, because all MAG are synchronized they can be ordered by LMA
-only related LMA's and MAG are synchronized this way.

Stupid?

Bruno.

_______________________________________________
netlmm mailing list
netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm




--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.or= g




--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org <= /blockquote>
--===============1022113898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============1022113898==-- From netlmm-bounces@ietf.org Fri Sep 14 08:07:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9xY-00073A-FR; Fri, 14 Sep 2007 08:07:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9xX-000734-HM for netlmm@ietf.org; Fri, 14 Sep 2007 08:07:43 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW9xW-0003Je-GL for netlmm@ietf.org; Fri, 14 Sep 2007 08:07:43 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8EC6pXE023051; Fri, 14 Sep 2007 14:06:59 +0200 Received: from [172.27.205.222] ([172.27.205.222]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Fri, 14 Sep 2007 14:07:33 +0200 Message-ID: <46EA7986.3060208@alcatel-lucent.fr> Date: Fri, 14 Sep 2007 14:07:34 +0200 From: Bruno Mongazon-Cazavet User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [netlmm] LMA as a time keeper References: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> <46EA4DA5.5050807@alcatel-lucent.fr> <46EA526F.7010800@gmail.com> In-Reply-To: <46EA526F.7010800@gmail.com> X-OriginalArrivalTime: 14 Sep 2007 12:07:33.0812 (UTC) FILETIME=[D5231740:01C7F6C7] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-MIME-Autoconverted: from 8bit to quoted-printable by smail6.alcatel.fr id l8EC6pXE023051 X-Spam-Score: 1.7 (+) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0090356796==" Errors-To: netlmm-bounces@ietf.org --===============0090356796== Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Alexandru Petrescu wrote: 
Hi Bruno, just to add some thoughts... I'm not trying in=
 no way to
discard it, just discussion.
[BM] No problem. Just trying to share some ideas on the mailing list and find out a solution.
Bruno Mongazon-Cazavet wrote:
  
To this method , I doubt whether something need to b=
e clarified at
the first:

1)       If we have assumed that all of the MAG can maintenance the
 same clock with the LMA after it get the time from that LMA?

      
[BM] MAG can either: a) set its system time (machine t=
ime) as the LMA
time. In such a case, the time will be maintained by the system
    

Can a PC maintain the time correctly when its battery is no longer
working correctly.
[BM] Don't know about PC behavior. I think a MAG equipment will rather be a fixed robust system that provides power redundancy with accurate timing functions. 
  
b) keep this time as an internal MAG time. In such a c=
ase it needs to
 maintain it  on its own with the help of timing functions of the
system.
    
2)       What is the precision requirement for this =
timestamp used
here?

      
[BM] second or millisecond i guess
    

This should be dictated by the ordering requirement.  I guess we want
the precision to be directly related to how many handovers per second
can a mobile do, and the P-BUs sent.
[BM] yes precision is related to handover frequency.
For example, in WiFi, a typical link-layer handover is in the order of
500ms; for this, we don't need a time precision in the order of
milliseconds, but hundreds of milliseconds.  (at the same time, some
very performant wifi link-layers can do in the order of 4ms.)

WiFi is but one technology.

I expect WiMax to have handover latencies in the order of seconds.
[BM] Good point. The time unit can be carried together with the time value in PBU/PBU-Ack, as a millisecond multiple.
  
3)       If can every MAG only connect to one LMA?

      
[BM] good point. According to the draft LMA can connec=
t to multiple
MAG. In such a case, each LMA reference time shall be kept and used=20
separately by the LMA. Which in turn might imply that time is
maintain as an internal MAG time, that is option b) in above
question.
    

In a deployment, LMA is probably the anchor point for mobility, the sort
of controlling point and thus it makes sense to have LMA to keep time
for everybody.
[BM] Yes, that's why i am suggesting this idea.
But for anything else than mobility maybe other entities are such
controlling points.  I'm thinking of DHCP Server or LDAP Server or AAA
Server, because they control the existence proper of mobiles.  It is
probably important that these machines are the time keepers.
[BM] Yes but it's not MIP-builtin'. A matter of choice.
Alex

  
Best regards, Bruno.
    

Best Rgds,

Thanks,



John.zhao



------------------------------------------------------------------------


*=B7=A2=BC=FE=C8=CB:* Jong-Hyouk Lee [mailto:jonghyouk@gmail.com] *=B7=A2=
=CB=CD=CA=B1=BC=E4:* 2007=C4=EA9=D4=C2
14=C8=D5 15:15 *=CA=D5=BC=FE=C8=CB:* Bruno Mongazon-Cazavet *=B3=AD=CB=CD=
:* =
netlmm@ietf.org *=D6=F7=CC=E2:*
Re: [netlmm] LMA as a time keeper



Dear Bruno.



The introduced way seems to be simple and enough to end this issue.
I take sides with this.



Cheers.



On 9/14/07, *Bruno Mongazon-Cazavet*=20
<bruno.mongazon-cazavet@alcatel-lucent.fr=20
<mailto:bruno.mongazon-cazavet@alcatel-lucent.fr>=
;> wrote:

An idea regarding PBU ordering problem:

-The LMA is the time keeper -When a MAG boots, it sends a dummy PBU
to the LMA to request current time (time synchronization). LMA
provides current time in the PBU-Ack. MAG set its time to LMA time
received in PBU-Ack (a latency can be added for network transit).=20
-All MAG linked to the same LMA will get synchronized with LMA time
 this way -the timestamp option is then used in real PBU/PBU-ACK,
because all MAG are synchronized they can be ordered by LMA -only
related LMA's and MAG are synchronized this way.

Stupid?

Bruno.

_______________________________________________ netlmm mailing list
 ne=
tlmm@ietf.org <mailto:netlmm@ietf.org>=20
https://www1.ietf.org/mailman/listinfo/netlmm=20
<https://www1.ietf.org/mailman/listinfo/netlmm>




-- Internet Management Technology Lab, Sungkyunkwan University.=20
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com #webpage:
http:/=
/www.hurryon.org

      
------------------------------------------------------------------------


_______________________________________________ netlmm mailing list=20
net=
lmm@ietf.org https://www1.ietf.org/mailman/listinfo/=
netlmm
    


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email=20
______________________________________________________________________

--===============0090356796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0090356796==-- From netlmm-bounces@ietf.org Fri Sep 14 08:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWAOL-0002tB-9v; Fri, 14 Sep 2007 08:35:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWAOK-0002t6-KN for netlmm@ietf.org; Fri, 14 Sep 2007 08:35:24 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWAOK-0003qW-4q for netlmm@ietf.org; Fri, 14 Sep 2007 08:35:24 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1189773322!8471003!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 15086 invoked from network); 14 Sep 2007 12:35:22 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-14.tower-153.messagelabs.com with SMTP; 14 Sep 2007 12:35:22 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l8ECZMsC014995; Fri, 14 Sep 2007 05:35:22 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l8ECZLPF024789; Fri, 14 Sep 2007 07:35:21 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8ECZIh5024756; Fri, 14 Sep 2007 07:35:19 -0500 (CDT) Message-ID: <46EA8006.6080104@gmail.com> Date: Fri, 14 Sep 2007 14:35:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bruno Mongazon-Cazavet Subject: Re: [netlmm] LMA as a time keeper References: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> <46EA4DA5.5050807@alcatel-lucent.fr> <46EA526F.7010800@gmail.com> <46EA7986.3060208@alcatel-lucent.fr> In-Reply-To: <46EA7986.3060208@alcatel-lucent.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-5, 13/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Bruno Mongazon-Cazavet wrote: > Alexandru Petrescu wrote: >> Hi Bruno, just to add some thoughts... I'm not trying in no way to >> discard it, just discussion. >> > [BM] No problem. Just trying to share some ideas on the mailing list and > find out a solution. >> Bruno Mongazon-Cazavet wrote: >> >>>> To this method , I doubt whether something need to be clarified at >>>> the first: >>>> >>>> 1) If we have assumed that all of the MAG can maintenance the >>>> same clock with the LMA after it get the time from that LMA? >>>> >>>> >>> [BM] MAG can either: a) set its system time (machine time) as the LMA >>> time. In such a case, the time will be maintained by the system >>> >> >> Can a PC maintain the time correctly when its battery is no longer >> working correctly. >> > [BM] Don't know about PC behavior. I think a MAG equipment will rather > be a fixed robust system that provides power redundancy with accurate > timing functions. I think many deployed systems have a PC architecture, with a long term battery for the BIOS. When that battery dies the Uninteruptible Power Supply is of no use. The UPS powers the main power unit, not the BIOS. I think I've encountered at least twice a situation where the whole operating system gets mangled simply because the time kept by the PC system (and its BIOS battery) was too long time in service and needed BIOS battery replacement. Alex [...] ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 09:25:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBAU-0008Bf-NE; Fri, 14 Sep 2007 09:25:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBAT-0008BY-RU for netlmm@ietf.org; Fri, 14 Sep 2007 09:25:09 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWBAS-0005pO-LC for netlmm@ietf.org; Fri, 14 Sep 2007 09:25:09 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8EDP5s11566; Fri, 14 Sep 2007 13:25:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Other IETF protocols and time dependency Date: Fri, 14 Sep 2007 08:25:04 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116BD8023@zrc2hxm2.corp.nortel.com> In-Reply-To: <46EA5EC1.8020707@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Other IETF protocols and time dependency Thread-Index: Acf2t+2A1XTIXI/ARsGSrs4h/FPaCgAGhG8w References: <46EA5EC1.8020707@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" , "netlmm" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex, You may need to add RFC3543 to the list. It is probably the most relevant to the discussion. On the other hand, I just would like to mention that when timestamp is used for replay protection, message ordering is already guaranteed; for FREE! Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Friday, September 14, 2007 5:13 AM > To: netlmm > Subject: [netlmm] Other IETF protocols and time dependency >=20 > Following my quest on what and how other IETF protocols=20 > depend on time, here's my current list; there may be errors. >=20 > Timestamps in messages > ---------------------- > Mobile IPv4 RFC3344 > -for security > -requirement on entities be time synchronized >=20 > SeND Secure Neighbor Discovery RFC3971 > -for security > -requirement on entities be time synchronized >=20 > SCTP Stream Control Transmission Protocol RFC2960 > -for security > -no requirement on entities be time synchronized >=20 > RTP A Transport Protocol for Real-Time Applications RFC3550 > -for ordering > -yes and no requirement on entities be time synchronized >=20 > No timestamps in messages > ------------------------- > TCP RFC 793 > ND Neighbor Discovery RFC 2461 > ICMPv6 RFC 4443 > BGP Border Gateway Protocol RFC4271 > OSPF Open Shortest Path First RFC2328 > Mobile IPv6 RFC3775 > MOBIKE IKEv2 Mobility and Multihoming RFC4555 > IKEv2 Internet Key Exchange RFC4306 >=20 > Alex >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 09:48:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBWj-0006Jw-1s; Fri, 14 Sep 2007 09:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWBWi-0006F0-2e for netlmm@ietf.org; Fri, 14 Sep 2007 09:48:08 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWBWg-0006jY-Ts for netlmm@ietf.org; Fri, 14 Sep 2007 09:48:08 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1189777685!33305115!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 23083 invoked from network); 14 Sep 2007 13:48:06 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-13.tower-119.messagelabs.com with SMTP; 14 Sep 2007 13:48:06 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l8EDm4FQ021627; Fri, 14 Sep 2007 06:48:04 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8EDm3mo002938; Fri, 14 Sep 2007 08:48:04 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8EDm1n8002884; Fri, 14 Sep 2007 08:48:02 -0500 (CDT) Message-ID: <46EA9110.5020109@gmail.com> Date: Fri, 14 Sep 2007 15:48:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] Other IETF protocols and time dependency References: <46EA5EC1.8020707@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116BD8023@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116BD8023@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-5, 13/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Alex, > > You may need to add RFC3543 to the list. It is probably the most > relevant to the discussion. Right, that is "Registration Revocation in Mobile IPv4". -for security -no requirement on time synchronization between entities. > On the other hand, I just would like to mention that when timestamp > is used for replay protection, message ordering is already > guaranteed; for FREE! Hehe right :-) If replay protection is provided then message ordering is guaranteed too, for free. But how? If we provide replay protection (and implicitely message ordering) by using timestamps then we need to write code to extend that P-BU with timestamps encoding, and rely on time, etc etc. If we provide replay protection with off-the-shelf IPsec (both IKEv2 and ESP/AH do replay protection) then we can take advantage of MIP6 implementations doing it, of P-MIP6 already relying on IPsec and not have to encode timestamp format. All we'd have to do is link the IPsec SA MAG-LMA to the MN's Home Address, a thing which was somehow already done by rfc3776 and implementations of it. It may be that using IPsec and not timestamps - for guaranteeing replay protection and implicitly P-BU ordering - is more gratuitous. Alex > > Regards, Ahmad > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, September 14, >> 2007 5:13 AM To: netlmm Subject: [netlmm] Other IETF protocols and >> time dependency >> >> Following my quest on what and how other IETF protocols depend on >> time, here's my current list; there may be errors. >> >> Timestamps in messages ---------------------- Mobile IPv4 RFC3344 >> -for security -requirement on entities be time synchronized >> >> SeND Secure Neighbor Discovery RFC3971 -for security -requirement >> on entities be time synchronized >> >> SCTP Stream Control Transmission Protocol RFC2960 -for security -no >> requirement on entities be time synchronized >> >> RTP A Transport Protocol for Real-Time Applications RFC3550 -for >> ordering -yes and no requirement on entities be time synchronized >> >> No timestamps in messages ------------------------- TCP RFC 793 ND >> Neighbor Discovery RFC 2461 ICMPv6 RFC 4443 BGP Border Gateway >> Protocol RFC4271 OSPF Open Shortest Path First RFC2328 Mobile IPv6 >> RFC3775 MOBIKE IKEv2 Mobility and Multihoming RFC4555 IKEv2 >> Internet Key Exchange RFC4306 >> >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> >> _______________________________________________ netlmm mailing list >> netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 10:22:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWC3m-00070K-4Z; Fri, 14 Sep 2007 10:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWC3k-0006yK-Ql for netlmm@ietf.org; Fri, 14 Sep 2007 10:22:16 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWC3j-0007ZQ-K4 for netlmm@ietf.org; Fri, 14 Sep 2007 10:22:16 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8EEMCs07855; Fri, 14 Sep 2007 14:22:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Other IETF protocols and time dependency Date: Fri, 14 Sep 2007 09:22:12 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116BD81EB@zrc2hxm2.corp.nortel.com> In-Reply-To: <46EA9110.5020109@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Other IETF protocols and time dependency Thread-Index: Acf21gIILRUAvHpfTzefmeaF7eewCgAAG34w References: <46EA5EC1.8020707@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116BD8023@zrc2hxm2.corp.nortel.com> <46EA9110.5020109@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Subject: Re: [netlmm] Other IETF protocols and time dependency >=20 > Ahmad Muhanna wrote: > > Alex, > >=20 > > You may need to add RFC3543 to the list. It is probably the most=20 > > relevant to the discussion. >=20 > Right, that is "Registration Revocation in Mobile IPv4". > -for security > -no requirement on time synchronization between entities. >=20 > > On the other hand, I just would like to mention that when=20 > timestamp is=20 > > used for replay protection, message ordering is already guaranteed;=20 > > for FREE! >=20 > Hehe right :-) If replay protection is provided then message=20 > ordering is guaranteed too, for free. >=20 > But how? >=20 > If we provide replay protection (and implicitely message=20 > ordering) by using timestamps then we need to write code to=20 > extend that P-BU with timestamps encoding, and rely on time, etc etc. >=20 > If we provide replay protection with off-the-shelf IPsec=20 > (both IKEv2 and ESP/AH do replay protection) then we can take=20 > advantage of MIP6 implementations doing it, of P-MIP6 already=20 > relying on IPsec and not have to encode timestamp format. =20 > All we'd have to do is link the IPsec SA MAG-LMA to the MN's=20 > Home Address, a thing which was somehow already done by=20 > rfc3776 and implementations of it. >=20 > It may be that using IPsec and not timestamps - for=20 > guaranteeing replay protection and implicitly P-BU ordering -=20 > is more gratuitous. >=20 [Ahmad] Man. Listen, timestamp is not used for replay protection in MIP6. You know that right! The comment was related to MIP4 and probably to be more specific to your own understanding of MIP4! :-) On the other hand, you may continue your off-shelf prototyping in order to judge how protocols out there works. Not a bad idea. > Alex >=20 > >=20 > > Regards, Ahmad > >=20 > >=20 > >> -----Original Message----- From: Alexandru Petrescu=20 > >> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, September 14, > >> 2007 5:13 AM To: netlmm Subject: [netlmm] Other IETF protocols and=20 > >> time dependency > >>=20 > >> Following my quest on what and how other IETF protocols depend on=20 > >> time, here's my current list; there may be errors. > >>=20 > >> Timestamps in messages ---------------------- Mobile IPv4 RFC3344=20 > >> -for security -requirement on entities be time synchronized > >>=20 > >> SeND Secure Neighbor Discovery RFC3971 -for security=20 > -requirement on=20 > >> entities be time synchronized > >>=20 > >> SCTP Stream Control Transmission Protocol RFC2960 -for=20 > security -no =20 > >> requirement on entities be time synchronized > >>=20 > >> RTP A Transport Protocol for Real-Time Applications RFC3550 -for=20 > >> ordering -yes and no requirement on entities be time synchronized > >>=20 > >> No timestamps in messages ------------------------- TCP RFC 793 ND=20 > >> Neighbor Discovery RFC 2461 ICMPv6 RFC 4443 BGP Border Gateway=20 > >> Protocol RFC4271 OSPF Open Shortest Path First RFC2328 Mobile IPv6 > >> RFC3775 MOBIKE IKEv2 Mobility and Multihoming RFC4555=20 > IKEv2 Internet=20 > >> Key Exchange RFC4306 > >>=20 > >> Alex > >>=20 > >>=20 > _____________________________________________________________________ > >> _ This email has been scanned by the MessageLabs Email Security=20 > >> System. For more information please visit=20 > >> http://www.messagelabs.com/email=20 > >>=20 > _____________________________________________________________________ > >> _ > >>=20 > >>=20 > >>=20 > >> _______________________________________________ netlmm=20 > mailing list =20 > >> netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > >>=20 > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 10:31:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCCJ-0004J7-QB; Fri, 14 Sep 2007 10:31:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCCI-0004GW-6H for netlmm@ietf.org; Fri, 14 Sep 2007 10:31:06 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWCCH-0000FQ-FF for netlmm@ietf.org; Fri, 14 Sep 2007 10:31:05 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1189780264!5874316!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27644 invoked from network); 14 Sep 2007 14:31:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 14 Sep 2007 14:31:04 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8EEV3mt004899; Fri, 14 Sep 2007 07:31:03 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8EEV3XU029198; Fri, 14 Sep 2007 09:31:03 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8EEV1Om029176; Fri, 14 Sep 2007 09:31:02 -0500 (CDT) Message-ID: <46EA9B25.9070802@gmail.com> Date: Fri, 14 Sep 2007 16:31:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] Other IETF protocols and time dependency References: <46EA5EC1.8020707@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116BD8023@zrc2hxm2.corp.nortel.com> <46EA9110.5020109@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116BD81EB@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116BD81EB@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-5, 13/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: >> Subject: Re: [netlmm] Other IETF protocols and time dependency >> >> Ahmad Muhanna wrote: >>> Alex, >>> >>> You may need to add RFC3543 to the list. It is probably the most >>> relevant to the discussion. >> Right, that is "Registration Revocation in Mobile IPv4". >> -for security >> -no requirement on time synchronization between entities. >> >>> On the other hand, I just would like to mention that when >> timestamp is >>> used for replay protection, message ordering is already guaranteed; >>> for FREE! >> Hehe right :-) If replay protection is provided then message >> ordering is guaranteed too, for free. >> >> But how? >> >> If we provide replay protection (and implicitely message >> ordering) by using timestamps then we need to write code to >> extend that P-BU with timestamps encoding, and rely on time, etc etc. >> >> If we provide replay protection with off-the-shelf IPsec >> (both IKEv2 and ESP/AH do replay protection) then we can take >> advantage of MIP6 implementations doing it, of P-MIP6 already >> relying on IPsec and not have to encode timestamp format. >> All we'd have to do is link the IPsec SA MAG-LMA to the MN's >> Home Address, a thing which was somehow already done by >> rfc3776 and implementations of it. >> >> It may be that using IPsec and not timestamps - for >> guaranteeing replay protection and implicitly P-BU ordering - >> is more gratuitous. >> > > [Ahmad] > Man. Listen, timestamp is not used for replay protection in MIP6. You > know that right! > The comment was related to MIP4 and probably to be more specific to your > own understanding of MIP4! :-) So what you want to say is that timestamps in PMIPv6 is not used for replay protection, but for message ordering, right? What I'm saying is that if IPsec provides replay protection and implicitly message ordering then no need of timestamps, right? Especially since PMIPv6 does use IPsec. > On the other hand, you may continue your off-shelf prototyping in order > to judge how protocols out there works. Not a bad idea. Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 10:45:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCQP-0002qx-CM; Fri, 14 Sep 2007 10:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCQN-0002ez-Je for netlmm@ietf.org; Fri, 14 Sep 2007 10:45:39 -0400 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWCQM-0008Dx-4q for netlmm@ietf.org; Fri, 14 Sep 2007 10:45:39 -0400 Received: by wr-out-0506.google.com with SMTP id 70so469138wra for ; Fri, 14 Sep 2007 07:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=EM5w90Qb6toN7vUPKPN/t63cUvbZXCXHA1fiUKeZ+70=; b=EhPSZDtee+3yeTiBha/bixsdJmMWx8JqXEwLgnxrdHbiQjKPadbkaJwFOORlFo6whOvKOTvtOTpRqXfxs1X9fUJbLc+czRj+jAYvm1hbArHyCaB7AsB5wHZqIEZAg3Wyu7HU5amp2Cxae14k4NX3KLcDV9XgIZ7V7c6XL1Y0pRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YKymvJlV977pH4MEEdfPparqryhX6me8jw2QH+qcgRCaWaUFw6aS2qSmNwdYfnzDbV+oCrwaUNuIXbPtMJUTGniWurhsZTJoS1p90SJeBjAMJ67w8x3IzePBd+tt6RiM1ejWDy/rFQgQd2JiFB2EfnfqLWHuXuEQWhBwy6nCmXU= Received: by 10.142.97.20 with SMTP id u20mr493260wfb.1189781136366; Fri, 14 Sep 2007 07:45:36 -0700 (PDT) Received: by 10.141.78.6 with HTTP; Fri, 14 Sep 2007 07:45:36 -0700 (PDT) Message-ID: Date: Fri, 14 Sep 2007 23:45:36 +0900 From: "Jong-Hyouk Lee" To: "Bruno Mongazon-Cazavet" Subject: Re: [netlmm] LMA as a time keeper In-Reply-To: <46EA7615.1040503@alcatel-lucent.fr> MIME-Version: 1.0 References: <00b801c7f6a3$30ba0cf0$a864a8c0@china.huawei.com> <46EA7615.1040503@alcatel-lucent.fr> X-Spam-Score: 0.6 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2023387945==" Errors-To: netlmm-bounces@ietf.org --===============2023387945== Content-Type: multipart/alternative; boundary="----=_Part_717_6160440.1189781136353" ------=_Part_717_6160440.1189781136353 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkuIEJydW5vLgoKV2Ugc2hvdWxkIHRoaW5rIGFib3V0IG11bHRpcGxlIExNQXMgZW52aXJvbm1l bnRzIGFuZCB3aHkgdGhhdCBuZWVkcy4gSWYgYW4KTE1BIGhhcyBleGNlZWRlZCBpdHMgc3lzdGVt IHJlc291cmNlIG9yIGl0cyBjYXBhY2l0eSwgdGhlbiB0aGUgTE1BIGlzIGZhaWxlZApvciBjcmFz aGVkLiBGb3Igc3VjaCBjYXNlcywgdGhlIGZhaWxlZCBvciBjcmFzaGVkIExNQSdzIGluZm9ybWF0 aW9uIChhYm91dApNQUdzKSBoYXMgdG8gYmUgc2VudCBhbm90aGVyIExNQSBpbiB0aGUgc2FtZSBk b21haW4gKEl0IGlzIHNpbWlsYXIgY29uY2VwdAp0byBzd2l0Y2hpbmcgSEEgaW4gTUlQNikuIElm IHdlIGNvbnNpZGVyIHRoaXMsIHdlIHNob3VsZCBjb25zaWRlciB0aGF0IGFsbApMTUFzIG1ha2Ug YSB0aW1lIHN5bmNocm9uaXphdGlvbi4KCkFzIHJlZmVyZW5jZXMsIHRoZXJlIGFyZSBhbHJlYWR5 IG1lY2hhbmlzbXMgZm9yIHJlYWNoYWJpbGl0eSBjaGVjayBiZXR3ZWVuCkxNQSBhbmQgTUFHIChk cmFmdC1kZXZhcmFwYWxsaS1uZXRsbW0tcGltcHY2LWhlYXJ0YmVhdC0wMClvciBMTUFzCihkcmFm dC1qaGxlZS1uZXRsbW0taGVhcnRiZWF0bG1hLTAwKWluIFBNSVA2LiBJIGJlbGlldmUgdGhhdCB0 aGUgYmFzZQpkb2N1bWVudCBzaG91bGQgYmUgb3BlbmVkIGZvciBleHBhbnNpb25zLgoKQ2hlZXJz LgoKCk9uIDkvMTQvMDcsIEJydW5vIE1vbmdhem9uLUNhemF2ZXQgPGJydW5vLm1vbmdhem9uLWNh emF2ZXRAYWxjYXRlbC1sdWNlbnQuZnI+Cndyb3RlOgo+Cj4gSm9uZy1IeW91ayBMZWUgd3JvdGU6 Cj4KPiBIaSwgYWxsLgo+Cj4gVG8gZ2V0IHRoZSB0aW1lIHN5bmNocm9uaXphdGlvbiBieSB0aGUg aW50cm9kdWNlZCBtZXRob2QsIGV2ZXJ5IE1BRyBrbm93cwo+IHdoaWNoIExNQSBpcyB0aGUgdGlt ZSBzeW5jIExNQSBpbiBjYXNlIG9mIG11bHRpcGxlIExNQXMgaW4gdGhlIGRvbWFpbi4gSXQKPiBt ZWFucyB0aGF0IGV2ZXJ5IE1BRyBvbmx5IG5vdCBjb25uZWN0IHRvIG9uZSBMTUEuIEFsc28sIGFs bCBMTUEgc2hvdWxkCj4gc2hhcmUgdGhlIHNhbWUgdGltZSBpbmZvcm1hdGlvbiBieSBvdGhlciB3 YXksICBlLmcuLCBOVFAuCj4KPiBbQk1dIFRvIGJlIGNoZWNrIGJ1dCBpIHRoaW5rIHRoYXQgaXQg aXMgbm90IG5lY2Vzc2FyeSB0aGF0IGFsbCBMTUEgYmUgdGltZQo+IHN5bmNocm9uaXplZC4KPiBC YXNpY2FsbHksIGVhY2ggTE1BIG5lZWRzIHRvIGJlIGNhcGFibGUgdG8gcmUtb3JkZXIgUEJVIGZy b20gdGhlIE1BR3MgaXQKPiBpcyBjb25uZWN0ZWQgdG8uIElmIGFsbCBNQUdzIHNoYXJlIHRoZSBz YW1lIHRpbWUgZm9yIHRoaXMgTE1BLCB0aGVuIE1BRyBjYW4KPiBtYWtlIHJlLW9yZGVyaW5nLiBU aGlzIGltcGxpZXMgdGhhdCB3aGVuIGEgTUFHIGZpcnN0IGNvbm5lY3RzIHRvIGEgTE1BLCBpdAo+ IGdldHMgaXRzIHRpbWUgZmlyc3QuCj4KPgo+IENoZWVycy4KPgo+Cj4gT24gOS8xNC8wNywgSm9o bi56aGFvIDxqb2huLnpoYW9AaHVhd2VpLmNvbT4gd3JvdGU6Cj4gPgo+ID4gIEhpLGFsbAo+ID4K PiA+Cj4gPgo+ID4gICAgICAgICAgVG8gdGhpcyBtZXRob2QgLCBJIGRvdWJ0IHdoZXRoZXIgc29t ZXRoaW5nIG5lZWQgdG8gYmUgY2xhcmlmaWVkCj4gPiBhdCB0aGUgZmlyc3Q6Cj4gPgo+ID4gMSkg ICAgICAgSWYgd2UgaGF2ZSBhc3N1bWVkIHRoYXQgYWxsIG9mIHRoZSBNQUcgY2FuIG1haW50ZW5h bmNlIHRoZSBzYW1lCj4gPiBjbG9jayB3aXRoIHRoZSBMTUEgYWZ0ZXIgaXQgZ2V0IHRoZSB0aW1l IGZyb20gdGhhdCBMTUE/Cj4gPgo+ID4gMikgICAgICAgV2hhdCBpcyB0aGUgcHJlY2lzaW9uIHJl cXVpcmVtZW50IGZvciB0aGlzIHRpbWVzdGFtcCB1c2VkIGhlcmU/Cj4gPgo+ID4KPiA+IDMpICAg ICAgIElmIGNhbiBldmVyeSBNQUcgb25seSBjb25uZWN0IHRvIG9uZSBMTUE/Cj4gPgo+ID4KPiA+ Cj4gPiBCZXN0IFJnZHMsCj4gPgo+ID4gVGhhbmtzLAo+ID4KPiA+Cj4gPgo+ID4gSm9obi56aGFv Cj4gPgo+ID4KPiA+ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gPgo+ID4gKrei vP7IyzoqIEpvbmctSHlvdWsgTGVlIFttYWlsdG86am9uZ2h5b3VrQGdtYWlsLmNvbV0KPiA+ICq3 osvNyrG85DoqIDIwMDfE6jkg1MIxNMjVIDE1OjE1Cj4gPiAqytW8/sjLOiAqQnJ1bm8gTW9uZ2F6 b24tQ2F6YXZldAo+ID4gKrOty806KiBuZXRsbW1AaWV0Zi5vcmcKPiA+ICrW98ziOiogUmU6IFtu ZXRsbW1dIExNQSBhcyBhIHRpbWUga2VlcGVyCj4gPgo+ID4KPiA+Cj4gPiBEZWFyIEJydW5vLgo+ ID4KPiA+Cj4gPgo+ID4gVGhlIGludHJvZHVjZWQgd2F5IHNlZW1zIHRvIGJlIHNpbXBsZSBhbmQg ZW5vdWdoIHRvIGVuZCB0aGlzIGlzc3VlLiBJCj4gPiB0YWtlIHNpZGVzIHdpdGggdGhpcy4KPiA+ Cj4gPgo+ID4KPiA+IENoZWVycy4KPiA+Cj4gPgo+ID4KPiA+IE9uIDkvMTQvMDcsICpCcnVubyBN b25nYXpvbi1DYXphdmV0KiA8YnJ1bm8ubW9uZ2F6b24tY2F6YXZldEBhbGNhdGVsLWx1Y2VudC5m cj4KPiA+IHdyb3RlOgo+ID4KPiA+IEFuIGlkZWEgcmVnYXJkaW5nIFBCVSBvcmRlcmluZyBwcm9i bGVtOgo+ID4KPiA+IC1UaGUgTE1BIGlzIHRoZSB0aW1lIGtlZXBlcgo+ID4gLVdoZW4gYSBNQUcg Ym9vdHMsIGl0IHNlbmRzIGEgZHVtbXkgUEJVIHRvIHRoZSBMTUEgdG8gcmVxdWVzdCBjdXJyZW50 Cj4gPiB0aW1lICh0aW1lIHN5bmNocm9uaXphdGlvbikuIExNQSBwcm92aWRlcyBjdXJyZW50IHRp bWUgaW4gdGhlIFBCVS1BY2suCj4gPiBNQUcgc2V0IGl0cyB0aW1lIHRvIExNQSB0aW1lIHJlY2Vp dmVkIGluIFBCVS1BY2sgKGEgbGF0ZW5jeSBjYW4gYmUgYWRkZWQKPiA+IGZvciBuZXR3b3JrIHRy YW5zaXQpLgo+ID4gLUFsbCBNQUcgbGlua2VkIHRvIHRoZSBzYW1lIExNQSB3aWxsIGdldCBzeW5j aHJvbml6ZWQgd2l0aCBMTUEgdGltZSB0aGlzCj4gPiB3YXkKPiA+IC10aGUgdGltZXN0YW1wIG9w dGlvbiBpcyB0aGVuIHVzZWQgaW4gcmVhbCBQQlUvUEJVLUFDSywgYmVjYXVzZSBhbGwgTUFHCj4g PiBhcmUgc3luY2hyb25pemVkIHRoZXkgY2FuIGJlIG9yZGVyZWQgYnkgTE1BCj4gPiAtb25seSBy ZWxhdGVkIExNQSdzIGFuZCBNQUcgYXJlIHN5bmNocm9uaXplZCB0aGlzIHdheS4KPiA+Cj4gPiBT dHVwaWQ/Cj4gPgo+ID4gQnJ1bm8uCj4gPgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPiA+IG5ldGxtbSBtYWlsaW5nIGxpc3QKPiA+IG5ldGxtbUBp ZXRmLm9yZwo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bG1t Cj4gPgo+ID4KPiA+Cj4gPgo+ID4gLS0KPiA+IEludGVybmV0IE1hbmFnZW1lbnQgVGVjaG5vbG9n eSBMYWIsIFN1bmdreXVua3dhbiBVbml2ZXJzaXR5Lgo+ID4gSm9uZy1IeW91ayBMZWUuCj4gPgo+ ID4gI2VtYWlsOiBqb25naHlvdWsgKGF0KSBnbWFpbCAoZG90KSBjb20KPiA+ICN3ZWJwYWdlOiBo dHRwOi8vd3d3Lmh1cnJ5b24ub3JnCj4gPgo+Cj4KPgo+IC0tCj4gSW50ZXJuZXQgTWFuYWdlbWVu dCBUZWNobm9sb2d5IExhYiwgU3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHkuCj4gSm9uZy1IeW91ayBM ZWUuCj4KPiAjZW1haWw6IGpvbmdoeW91ayAoYXQpIGdtYWlsIChkb3QpIGNvbQo+ICN3ZWJwYWdl OiBodHRwOi8vd3d3Lmh1cnJ5b24ub3JnCj4KPgo+CgoKLS0gCkludGVybmV0IE1hbmFnZW1lbnQg VGVjaG5vbG9neSBMYWIsIFN1bmdreXVua3dhbiBVbml2ZXJzaXR5LgpKb25nLUh5b3VrIExlZS4K CiNlbWFpbDogam9uZ2h5b3VrIChhdCkgZ21haWwgKGRvdCkgY29tCiN3ZWJwYWdlOiBodHRwOi8v d3d3Lmh1cnJ5b24ub3JnCg== ------=_Part_717_6160440.1189781136353 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaS4gQnJ1bm8uPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+V2Ugc2hvdWxkIHRo aW5rIGFib3V0IG11bHRpcGxlIExNQXMgZW52aXJvbm1lbnRzIGFuZCB3aHkgdGhhdCBuZWVkcy4g SWYgYW4gTE1BIGhhcyBleGNlZWRlZCBpdHMgc3lzdGVtIHJlc291cmNlIG9yIGl0cyBjYXBhY2l0 eSwgdGhlbiB0aGUgTE1BIGlzIGZhaWxlZCBvciBjcmFzaGVkLiBGb3Igc3VjaCBjYXNlcywgdGhl IGZhaWxlZCBvciBjcmFzaGVkIExNQSYjMzk7cyBpbmZvcm1hdGlvbiAoYWJvdXQgTUFHcykgaGFz IHRvIGJlIHNlbnQgYW5vdGhlciBMTUEgaW4gdGhlIHNhbWUgZG9tYWluIChJdCBpcyBzaW1pbGFy IGNvbmNlcHQgdG8gc3dpdGNoaW5nIEhBIGluIE1JUDYpLiBJZiB3ZSBjb25zaWRlciB0aGlzLCB3 ZSBzaG91bGQgY29uc2lkZXIgdGhhdCBhbGwgTE1BcyBtYWtlIGEgdGltZSBzeW5jaHJvbml6YXRp b24uCjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PkFzIHJlZmVyZW5jZXMsIHRoZXJlIGFy ZSBhbHJlYWR5IG1lY2hhbmlzbXMgZm9yIHJlYWNoYWJpbGl0eSBjaGVjayBiZXR3ZWVuIExNQSBh bmQgTUFHIChkcmFmdC1kZXZhcmFwYWxsaS1uZXRsbW0tcGltcHY2LWhlYXJ0YmVhdC0wMClvciBM TUFzIChkcmFmdC1qaGxlZS1uZXRsbW0taGVhcnRiZWF0bG1hLTAwKWluIFBNSVA2LiBJIGJlbGll dmUgdGhhdCB0aGUgYmFzZSBkb2N1bWVudCBzaG91bGQgYmUgb3BlbmVkIGZvciBleHBhbnNpb25z Lgo8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5DaGVlcnMuPGJyPjxicj4mbmJzcDs8L2Rp dj4KPGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDkvMTQvMDcsIDxiIGNsYXNzPSJn bWFpbF9zZW5kZXJuYW1lIj5CcnVubyBNb25nYXpvbi1DYXphdmV0PC9iPiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmJydW5vLm1vbmdhem9uLWNhemF2ZXRAYWxjYXRlbC1sdWNlbnQuZnIiPmJydW5vLm1v bmdhem9uLWNhemF2ZXRAYWxjYXRlbC1sdWNlbnQuZnI8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+Cgo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsg TUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4K PGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjZmZmZmZmIj5Kb25nLUh5b3VrIExlZSB3cm90 ZTogCjxibG9ja3F1b3RlIGNpdGU9Imh0dHA6Ly9taWRmNTQwNzAwNzA3MDkxNDAxMjRuYWFkZmVl MmxjYjA1NzRjNTRkZDYxMWYxQG1haWwuZ21haWwuY29tIiB0eXBlPSJjaXRlIj48c3BhbiBjbGFz cz0icSI+CjxkaXY+SGksIGFsbC48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5UbyZuYnNw O2dldCB0aGUgdGltZSBzeW5jaHJvbml6YXRpb24gYnkgdGhlIGludHJvZHVjZWQgbWV0aG9kLCBl dmVyeSBNQUcmbmJzcDtrbm93cyB3aGljaCBMTUEgaXMgdGhlIHRpbWUgc3luYyBMTUEgaW4gY2Fz ZSBvZiBtdWx0aXBsZSZuYnNwO0xNQXMmbmJzcDtpbiB0aGUgZG9tYWluLiBJdCBtZWFucyB0aGF0 IGV2ZXJ5IE1BRyBvbmx5Jm5ic3A7bm90IGNvbm5lY3QgdG8gb25lIExNQS4gQWxzbywgYWxsIExN QSZuYnNwO3Nob3VsZCBzaGFyZSZuYnNwO3RoZSBzYW1lIHRpbWUgaW5mb3JtYXRpb24gYnkgb3Ro ZXIgd2F5LCZuYnNwOyAKZS5nLiwgTlRQLjwvZGl2Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+W0JNXSBU byBiZSBjaGVjayBidXQgaSB0aGluayB0aGF0IGl0IGlzIG5vdCBuZWNlc3NhcnkgdGhhdCBhbGwg TE1BIGJlIHRpbWUgc3luY2hyb25pemVkLjxicj5CYXNpY2FsbHksIGVhY2ggTE1BIG5lZWRzIHRv IGJlIGNhcGFibGUgdG8gcmUtb3JkZXIgUEJVIGZyb20gdGhlIE1BR3MgaXQgaXMgY29ubmVjdGVk IHRvLiBJZiBhbGwgTUFHcyBzaGFyZSB0aGUgc2FtZSB0aW1lIGZvciB0aGlzIExNQSwgdGhlbiBN QUcgY2FuIG1ha2UgcmUtb3JkZXJpbmcuIFRoaXMgaW1wbGllcyB0aGF0IHdoZW4gYSBNQUcgZmly c3QgY29ubmVjdHMgdG8gYSBMTUEsIGl0IGdldHMgaXRzIHRpbWUgZmlyc3QuIAo8ZGl2PjxzcGFu IGNsYXNzPSJlIiBpZD0icV8xMTUwM2RkNDk3NjE5ZjUyXzMiPjxicj48YnI+CjxibG9ja3F1b3Rl IGNpdGU9Imh0dHA6Ly9taWRmNTQwNzAwNzA3MDkxNDAxMjRuYWFkZmVlMmxjYjA1NzRjNTRkZDYx MWYxQG1haWwuZ21haWwuY29tIiB0eXBlPSJjaXRlIj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5D aGVlcnMuPGJyPjxicj4mbmJzcDs8L2Rpdj4KPGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUi Pk9uIDkvMTQvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5Kb2huLnpoYW88L2I+ICZs dDs8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSIgaHJlZj0ibWFpbHRvOmpvaG4uemhhb0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+am9o bi56aGFvQGh1YXdlaS5jb208L2E+CiZndDsgd3JvdGU6PC9zcGFuPiAKPGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBw eCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZCI+Cjxk aXYgbGFuZz0iWkgtQ04iIHZsaW5rPSJibHVlIiBsaW5rPSJibHVlIj4KPGRpdj4KPHA+PGZvbnQg ZmFjZT0iQXJpYWwiIGNvbG9yPSJuYXZ5IiBzaXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5IaSxh bGw8L3NwYW4+PC9mb250PjwvcD4KPHA+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJuYXZ5IiBz aXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjog bmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KPHA+PGZv bnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJuYXZ5IiBzaXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG8gdGhpcyBt ZXRob2QgLCBJIGRvdWJ0IHdoZXRoZXIgc29tZXRoaW5nIG5lZWQgdG8gYmUgY2xhcmlmaWVkIGF0 IHRoZSBmaXJzdDo8L3NwYW4+PC9mb250PjwvcD4KCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogNjBw dDsgVEVYVC1JTkRFTlQ6IC0xOHB0Ij48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9Im5hdnkiIHNp emU9IjEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBu YXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxzcGFuPjEpPGZvbnQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBzaXplPSIxIj48c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Cjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PHNwYW4gZGlyPSJsdHIiPjxmb250 IGZhY2U9IkFyaWFsIiBjb2xvcj0ibmF2eSIgc2l6ZT0iMSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SWYg d2UgaGF2ZSBhc3N1bWVkIHRoYXQgYWxsIG9mIHRoZSBNQUcgY2FuIG1haW50ZW5hbmNlIHRoZSBz YW1lIGNsb2NrIHdpdGggdGhlIExNQSBhZnRlciBpdCBnZXQgdGhlIHRpbWUgZnJvbSB0aGF0IExN QT8gCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvcD4KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiA2MHB0 OyBURVhULUlOREVOVDogLTE4cHQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0ibmF2eSIgc2l6 ZT0iMSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5h dnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PHNwYW4+Mik8Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIHNpemU9IjEiPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAK PC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48c3BhbiBkaXI9Imx0ciI+PGZvbnQg ZmFjZT0iQXJpYWwiIGNvbG9yPSJuYXZ5IiBzaXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5XaGF0 IGlzIHRoZSBwcmVjaXNpb24gcmVxdWlyZW1lbnQgZm9yIHRoaXMgdGltZXN0YW1wIHVzZWQgaGVy ZT8gCjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvcD4KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiA2MHB0 OyBURVhULUlOREVOVDogLTE4cHQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0ibmF2eSIgc2l6 ZT0iMSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5h dnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PHNwYW4+Myk8Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIHNpemU9IjEiPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAK PC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48c3BhbiBkaXI9Imx0ciI+PGZvbnQg ZmFjZT0iQXJpYWwiIGNvbG9yPSJuYXZ5IiBzaXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5JZiBj YW4gZXZlcnkgTUFHIG9ubHkgY29ubmVjdCB0byBvbmUgTE1BPzwvc3Bhbj48L2ZvbnQ+CiA8L3Nw YW4+PC9wPgo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDQycHQiPjxmb250IGZhY2U9IkFyaWFsIiBj b2xvcj0ibmF2eSIgc2l6ZT0iMSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6 IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L3A+CjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMjFwdCI+PGZvbnQgZmFjZT0iQXJpYWwiIGNv bG9yPSJuYXZ5IiBzaXplPSIxIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTog OXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5CZXN0IFJnZHMsPC9zcGFuPjwv Zm9udD48L3A+CjxwPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0ibmF2eSIgc2l6ZT0iMSI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQt RkFNSUxZOiBBcmlhbCI+VGhhbmtzLDwvc3Bhbj48L2ZvbnQ+PC9wPgo8cD48Zm9udCBmYWNlPSJB cmlhbCIgY29sb3I9Im5hdnkiIHNpemU9IjEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9O VC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PC9wPgo8cD48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9Im5hdnkiIHNpemU9IjEi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBG T05ULUZBTUlMWTogQXJpYWwiPkpvaG4uemhhbzwvc3Bhbj48L2ZvbnQ+PC9wPgo8cD48Zm9udCBm YWNlPSJBcmlhbCIgY29sb3I9Im5hdnkiIHNpemU9IjEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9wPgo8ZGl2IHN0eWxlPSJCT1JERVItUklHSFQ6IG1lZGl1bSBub25l OyBQQURESU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBQQURESU5HLUxF RlQ6IDRwdDsgUEFERElORy1CT1RUT006IDBjbTsgQk9SREVSLUxFRlQ6IDEuNXB0IHNvbGlkOyBQ QURESU5HLVRPUDogMGNtOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZSI+CjxkaXY+CjxkaXYg c3R5bGU9IlRFWFQtQUxJR046IGNlbnRlciIgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+CjxociBhbGlnbj0iY2VudGVyIiB3aWR0aD0iMTAwJSIgc2l6ZT0iMiI+Cjwvc3Bh bj48L2ZvbnQ+PC9kaXY+CjxwPjxiPjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIHN0 eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU2lt U3VuIj63orz+yMs8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9mb250PjwvYj48 Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFNpbVN1biI+CiBKb25nLUh5b3VrIExlZSBbbWFpbHRv OjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp IiBocmVmPSJtYWlsdG86am9uZ2h5b3VrQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvbmdo eW91a0BnbWFpbC5jb208L2E+XSA8YnI+PC9zcGFuPjwvZm9udD48Yj48Zm9udCBmYWNlPSLLzszl IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IFNpbVN1biI+Creiy83KsbzkPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgZmFjZT0iy87M5SIgc2l6ZT0iMiI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4iPiAy MDA3PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIGxhbmc9IkVOLVVTIj7E6jk8L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBsYW5nPSJFTi1VUyI+CiDUwjE0PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gbGFuZz0iRU4tVVMiPsjVPC9zcGFuPjwvc3Bhbj4g MTU6MTU8YnI+PC9zcGFuPjwvZm9udD48Yj48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj48c3Bh biBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IFNpbVN1biI+ytW8/sjLPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+CiA8L3NwYW4+PC9mb250 PjwvYj48Zm9udCBmYWNlPSLLzszlIiBzaXplPSIyIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFNpbVN1biI+QnJ1bm8gTW9uZ2F6b24tQ2F6 YXZldDxicj48L3NwYW4+PC9mb250PjxiPjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFu IHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog U2ltU3VuIj4Ks63LzTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9i Pjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj4gPGEgb25jbGljaz0icmV0dXJuIHRv cC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpuZXRsbW1A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4KbmV0bG1tQGlldGYub3JnPC9hPjxicj48L3NwYW4+ PC9mb250PjxiPjxmb250IGZhY2U9IsvOzOUiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJGT05ULVdF SUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj7W98ziPHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgZmFjZT0iy87M 5SIgc2l6ZT0iMiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBTaW1TdW4iPgogUmU6IFtuZXRsbW1dIExNQSBhcyBhIHRpbWUga2VlcGVyPC9z cGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PC9zcGFuPjwvcD48L2Rpdj4KPGRpdj48c3Bh bj4KPHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+Cjxw Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBC cnVuby48L3NwYW4+PC9mb250PjwvcD4KPGRpdj4KPHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBzaXplPSIzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ Jm5ic3A7PC9zcGFuPjwvZm9udD48L3A+PC9kaXY+CjxkaXY+CjxwPjxmb250IGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPlRoZSBpbnRyb2R1Y2VkIHdheSZuYnNwO3NlZW1zIHRvIGJlJm5ic3A7c2ltcGxlIGFu ZCBlbm91Z2ggdG8gZW5kIHRoaXMgaXNzdWUuIEkgdGFrZSBzaWRlcyB3aXRoIHRoaXMuPC9zcGFu PjwvZm9udD48L3A+PC9kaXY+CjxkaXY+CjxwPjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg c2l6ZT0iMyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNw Ozwvc3Bhbj48L2ZvbnQ+PC9wPjwvZGl2Pgo8ZGl2Pgo8cD48Zm9udCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIHNpemU9IjMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0 Ij5DaGVlcnMuPGJyPjxicj4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD48L2Rpdj4KPGRpdj4KPHA+ PHNwYW4+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+T24gOS8xNC8wNywgPGI+PHNwYW4gc3R5bGU9 IkZPTlQtV0VJR0hUOiBib2xkIj5CcnVubyBNb25nYXpvbi1DYXphdmV0PC9zcGFuPjwvYj4gJmx0 OzxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp IiBocmVmPSJtYWlsdG86YnJ1bm8ubW9uZ2F6b24tY2F6YXZldEBhbGNhdGVsLWx1Y2VudC5mciIg dGFyZ2V0PSJfYmxhbmsiPgogYnJ1bm8ubW9uZ2F6b24tY2F6YXZldEBhbGNhdGVsLWx1Y2VudC5m cjwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4g PC9zcGFuPjwvcD4KPHA+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+QW4gaWRlYSByZWdhcmRpbmcg UEJVIG9yZGVyaW5nIHByb2JsZW06PGJyPjxicj4tVGhlIExNQSBpcyB0aGUgdGltZSBrZWVwZXI8 YnI+LVdoZW4gYSBNQUcgYm9vdHMsIGl0IHNlbmRzIGEgZHVtbXkgUEJVIHRvIHRoZSBMTUEgdG8g cmVxdWVzdCBjdXJyZW50IAo8YnI+dGltZSAodGltZSBzeW5jaHJvbml6YXRpb24pLiBMTUEgcHJv dmlkZXMgY3VycmVudCB0aW1lIGluIHRoZSBQQlUtQWNrLjxicj5NQUcgc2V0IGl0cyB0aW1lIHRv IExNQSB0aW1lIHJlY2VpdmVkIGluIFBCVS1BY2sgKGEgbGF0ZW5jeSBjYW4gYmUgYWRkZWQ8YnI+ Zm9yIG5ldHdvcmsgdHJhbnNpdCkuPGJyPi1BbGwgTUFHIGxpbmtlZCB0byB0aGUgc2FtZSBMTUEg d2lsbCBnZXQgc3luY2hyb25pemVkIHdpdGggTE1BIHRpbWUgdGhpcyB3YXkgCjxicj4tdGhlIHRp bWVzdGFtcCBvcHRpb24gaXMgdGhlbiB1c2VkIGluIHJlYWwgUEJVL1BCVS1BQ0ssIGJlY2F1c2Ug YWxsIE1BRzxicj5hcmUgc3luY2hyb25pemVkIHRoZXkgY2FuIGJlIG9yZGVyZWQgYnkgTE1BPGJy Pi1vbmx5IHJlbGF0ZWQgTE1BJiMzOTtzIGFuZCBNQUcgYXJlIHN5bmNocm9uaXplZCB0aGlzIHdh eS48YnI+PGJyPlN0dXBpZD88YnI+PGJyPkJydW5vLjxicj48YnI+Cl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPm5ldGxtbSBtYWlsaW5nIGxpc3Q8YnI+ PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcyki IGhyZWY9Im1haWx0bzpuZXRsbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRsbW1AaWV0 Zi5vcmc8L2E+PGJyPjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93 LGV2ZW50LHRoaXMpIiBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRsbW0iIHRhcmdldD0iX2JsYW5rIj4KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bG1tIDwvYT48L3NwYW4+PC9mb250PjwvcD48L2Rpdj4KPHA+PGZvbnQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZP TlQtU0laRTogMTJwdCI+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPkludGVybmV0IE1h bmFnZW1lbnQgVGVjaG5vbG9neSBMYWIsIFN1bmdreXVua3dhbiBVbml2ZXJzaXR5LiA8YnI+Sm9u Zy1IeW91ayBMZWUuPGJyPjxicj4jZW1haWw6IGpvbmdoeW91ayAoYXQpIGdtYWlsIChkb3QpIGNv bSAKPGJyPiN3ZWJwYWdlOiA8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdp bmRvdyxldmVudCx0aGlzKSIgaHJlZj0iaHR0cDovL3d3dy5odXJyeW9uLm9yZy8iIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3Lmh1cnJ5b24ub3JnPC9hPiA8L3NwYW4+PC9mb250PjwvcD48L3Nw YW4+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xl YXI9ImFsbCI+Cjxicj4tLSA8YnI+SW50ZXJuZXQgTWFuYWdlbWVudCBUZWNobm9sb2d5IExhYiwg U3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHkuIDxicj5Kb25nLUh5b3VrIExlZS48YnI+PGJyPiNlbWFp bDogam9uZ2h5b3VrIChhdCkgZ21haWwgKGRvdCkgY29tIDxicj4jd2VicGFnZTogPGEgb25jbGlj az0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Imh0 dHA6Ly93d3cuaHVycnlvbi5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+Cmh0dHA6Ly93d3cuaHVycnlv bi5vcmc8L2E+IDwvYmxvY2txdW90ZT48YnI+PC9zcGFuPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90 ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+SW50ZXJuZXQgTWFuYWdlbWVu dCBUZWNobm9sb2d5IExhYiwgU3VuZ2t5dW5rd2FuIFVuaXZlcnNpdHkuIDxicj5Kb25nLUh5b3Vr IExlZS48YnI+PGJyPiNlbWFpbDogam9uZ2h5b3VrIChhdCkgZ21haWwgKGRvdCkgY29tIAo8YnI+ I3dlYnBhZ2U6IDxhIGhyZWY9Imh0dHA6Ly93d3cuaHVycnlvbi5vcmciPmh0dHA6Ly93d3cuaHVy cnlvbi5vcmc8L2E+IAo= ------=_Part_717_6160440.1189781136353-- --===============2023387945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============2023387945==-- From netlmm-bounces@ietf.org Fri Sep 14 13:59:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFSL-0007VM-AX; Fri, 14 Sep 2007 13:59:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFSK-0007UW-00 for netlmm@ietf.org; Fri, 14 Sep 2007 13:59:52 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IWFSI-00057m-MQ for netlmm@ietf.org; Fri, 14 Sep 2007 13:59:51 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1189792789!19703960!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26706 invoked from network); 14 Sep 2007 17:59:49 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 14 Sep 2007 17:59:49 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8EHxnuD004153 for ; Fri, 14 Sep 2007 10:59:49 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l8EHxnI9021304 for ; Fri, 14 Sep 2007 12:59:49 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.152]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8EHxlU4021280 for ; Fri, 14 Sep 2007 12:59:48 -0500 (CDT) Message-ID: <46EACC13.3060904@gmail.com> Date: Fri, 14 Sep 2007 19:59:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: netlmm Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-6, 14/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [netlmm] Alternatives to RECOMMENDED timestamp X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I've had a nice chat with Ahmad on the phone. We agree on many things, but not all. I personally don't agree with the paragraph that says that PMIPv6 RECOMMENDS (SHOULD) timestamps. I would at most write that PMIPv6 RECOMMENDS: -timestamps or -seq numbers of IKEv2 or -seq numbers in policy profile. The problem the timestamps are trying to solve is not new to PMIPv6 and the problem was already there originally: how could the MAG learn the HNP of MN, or its MN-ID? Thus the seqno could be made part of that policy profile, as HNP and MN-ID are. Ahmad doesn't like this method a lot, because... well he can explain. Seqnumbers in AH, coming from IKEv2 initial exchanges, was probably discussed already.(?) These are at least two alternative methods to timestamps, and they have their advantages and their inconvenients, exactly as timestamps have advantages and inconvenients. I really don't see the timestamps should be the only RECOMMENDED (SHOULD). Alex PS: draft says: > For solving this [ordering] problem, this specification RECOMMENDS > the use of Timestamp option [Section 8.4]. The basic principle > behind the use of timestamps in binding registration messages is that > the node generating the message inserts the current time-of-day, and > the node receiving the message checks that this timestamp is greater > than all previously accepted timestamps. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 14:30:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFw5-0008DA-Ll; Fri, 14 Sep 2007 14:30:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWFw4-0008D4-W3 for netlmm@ietf.org; Fri, 14 Sep 2007 14:30:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWFw4-00080F-JR for netlmm@ietf.org; Fri, 14 Sep 2007 14:30:36 -0400 X-IronPort-AV: E=Sophos;i="4.20,256,1186383600"; d="scan'208";a="218323231" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 14 Sep 2007 11:30:36 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8EIUaRE029413 for ; Fri, 14 Sep 2007 11:30:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8EIUVW3013309 for ; Fri, 14 Sep 2007 18:30:35 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 11:30:32 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 11:30:32 -0700 From: "Sri Gundavelli" To: "'netlmm'" References: <46EACC13.3060904@gmail.com> Subject: RE: [netlmm] Alternatives to RECOMMENDED timestamp Date: Fri, 14 Sep 2007 11:30:30 -0700 Message-ID: <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46EACC13.3060904@gmail.com> Thread-Index: Acf2+RJwhjALmgzKQ6eWWJsaZ1HlWwAAdSxg X-OriginalArrivalTime: 14 Sep 2007 18:30:32.0799 (UTC) FILETIME=[55AE3EF0:01C7F6FD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1447; t=1189794636; x=1190658636; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Alternatives=20to=20RECOMMENDED=20timestam p |Sender:=20; bh=WZ9DKYg9abxsZZDHS49PnRpm9EzFj82MRtsKodDdqMw=; b=qPqKUM5kNYaRlKxSxh8ibpYWhw2PIjl5f9smvubAoOeY++s1g5yc1wJHfMopUKDbQvdEKe5D YIqO9EtJS3Nh603CJfSkE+HviyJLCT1zQ3rsLFhvcFUXD+MlKZCtpu2T; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I'm afraid, this thread is going out of control. I really do not think, we should go back to basics. After converging with Federico and Kilian, we agreed one the following: - The timestamp in the PBA is not intended for the MAG to syncup to the lMA clock, but should be used for diagnostics and additionally the MAG should sync up to an external clock. The draft never mandated that the MAG should sync up to the LMA clock. We will clarify this. - When TS is supported, it is mandatory requirement for the MAG clocks to sync up to a clock source. If this requirement is not met, the LMA will end up processing stale requests. We will add some text on the imporantance of this requirement. - We also highly recommend NTP protocol to be used for syncing the MAG clocks. Now, there is only one issue and that is Alex's issue. Other than this, we clearly have consensus on the approach and on the text. Lets stick to this. - Is it mandatory for the implementations to implement Timestamp based solution. [Y/N]. Just a YES or NO, will be more than sufficient. Please comment on this and avoid going back to basics. We need to complete this work. IMHO, for this entire race condition to occur, quite a few things have to fall in place, some dramatic affects and all the stars have to alligned in a pattern. Lets not kill ourselves on this useless issue. Please help me close this. Regards Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 16:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHLa-00056s-4C; Fri, 14 Sep 2007 16:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHLY-00056i-EI for netlmm@ietf.org; Fri, 14 Sep 2007 16:01:00 -0400 Received: from fk-out-0910.google.com ([209.85.128.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWHLX-0000ow-7O for netlmm@ietf.org; Fri, 14 Sep 2007 16:01:00 -0400 Received: by fk-out-0910.google.com with SMTP id z23so838088fkz for ; Fri, 14 Sep 2007 13:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ibbP+B0uO7fvQlCk8vRnV9x5aS6Q7dq81EfF5lK9TaA=; b=rzMjLrOvmpnoWl5icZKKxorCl8olOV3sRmBbr+/gPuA716r1EBViI6h4iSIM7kBry0+wXCXOsFpqhCYg7HlUAnCb74xy69qdrzQNNWenVcD5fIxkA0J7CX4CToyUNjD4e4a62NIDESGc8K1wNn2jpm4nR9Lpn5NLDChtiudBPn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DsVqP49wQigN7UYeQCdYdanqvO8rrrYOwwte5//3bjvBX/CNeu1laQ8cr3QueRI8t2Ku0RgMxZI4Lj1PaNVRXxy0Yj6LeezdY20UJ2dEoPU+KLVHrarXoNfd12/FSaYw/3zyesh7xppFKypLQ73SN2plJ3eHc0EKh13jUHp0Yk4= Received: by 10.82.119.17 with SMTP id r17mr3012121buc.1189800057884; Fri, 14 Sep 2007 13:00:57 -0700 (PDT) Received: by 10.82.150.16 with HTTP; Fri, 14 Sep 2007 13:00:57 -0700 (PDT) Message-ID: <840fa9b60709141300o2975d888i26a09b3ec23eb534@mail.gmail.com> Date: Fri, 14 Sep 2007 22:00:57 +0200 From: "Alexandru Petrescu" To: "Sri Gundavelli" Subject: Re: [netlmm] Alternatives to RECOMMENDED timestamp In-Reply-To: <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On 9/14/07, Sri Gundavelli wrote: [...] > - Is it mandatory for the implementations to implement Timestamp > based solution. [Y/N]. Just a YES or NO, will be more than > sufficient. Yes, together with mandating seqnos. Alex > > > > Please comment on this and avoid going back to basics. We need > to complete this work. IMHO, for this entire race condition to > occur, quite a few things have to fall in place, some dramatic > affects and all the stars have to alligned in a pattern. Lets not > kill ourselves on this useless issue. Please help me close this. > > > > Regards > Sri > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 16:50:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWI7O-0005mb-3U; Fri, 14 Sep 2007 16:50:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWI7M-0005ZZ-Oy for netlmm@ietf.org; Fri, 14 Sep 2007 16:50:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWI7M-000477-CV for netlmm@ietf.org; Fri, 14 Sep 2007 16:50:24 -0400 X-IronPort-AV: E=Sophos;i="4.20,257,1186383600"; d="scan'208";a="218392937" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Sep 2007 13:50:15 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8EKoFQs022512; Fri, 14 Sep 2007 13:50:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8EKoAef010471; Fri, 14 Sep 2007 20:50:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 13:50:12 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 13:50:12 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> <840fa9b60709141300o2975d888i26a09b3ec23eb534@mail.gmail.com> Subject: RE: [netlmm] Alternatives to RECOMMENDED timestamp Date: Fri, 14 Sep 2007 13:49:56 -0700 Message-ID: <017301c7f710$cf1fbe90$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <840fa9b60709141300o2975d888i26a09b3ec23eb534@mail.gmail.com> Thread-Index: Acf3CgPexDhjLFA4Q3yQf5PjY+SwoAABS0tA X-OriginalArrivalTime: 14 Sep 2007 20:50:12.0597 (UTC) FILETIME=[D86DF250:01C7F710] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1398; t=1189803015; x=1190667015; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Alternatives=20to=20RECOMMENDED=20timestam p |Sender:=20; bh=3RBKzIPQhjUUvGMIC8JhHT/+3ssrcSV8tWzRSRjJDzE=; b=JsD6o8nus+Ja09VkCMxatihdLwXFVs9KW4A9iHHXgkZ+0sgMu7xiw+c7Su0BSPEijsi17/Qq /5L7w6sjWO3wV0XrFEhYwN9i/4ZuRYsbt1sXU8NKpIvg+BEqU3Uaal3T; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Thanks Alex. Just one clarification. > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Friday, September 14, 2007 1:01 PM > To: Sri Gundavelli > Cc: netlmm > Subject: Re: [netlmm] Alternatives to RECOMMENDED timestamp > > On 9/14/07, Sri Gundavelli wrote: > [...] > > - Is it mandatory for the implementations to implement Timestamp > > based solution. [Y/N]. Just a YES or NO, will be more than > > sufficient. > > Yes, together with mandating seqnos. > Mandating both as a MUST implement is not an issue. Seq numbers is supported per 3775 any ways. But, we cannot force the MAG to learn the seq number from the old MAG. That we cant mandate. If you are ok with this, we can close this last issue. Thanks Sri > Alex > > > > > > > > > Please comment on this and avoid going back to basics. We need > > to complete this work. IMHO, for this entire race condition to > > occur, quite a few things have to fall in place, some dramatic > > affects and all the stars have to alligned in a pattern. Lets not > > kill ourselves on this useless issue. Please help me close this. > > > > > > > > Regards > > Sri > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 18:18:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJUz-0008HR-1z; Fri, 14 Sep 2007 18:18:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJUy-0008HJ-2a for netlmm@ietf.org; Fri, 14 Sep 2007 18:18:52 -0400 Received: from fk-out-0910.google.com ([209.85.128.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWJUw-0005Ko-Rz for netlmm@ietf.org; Fri, 14 Sep 2007 18:18:52 -0400 Received: by fk-out-0910.google.com with SMTP id z23so862901fkz for ; Fri, 14 Sep 2007 15:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=y7bgC5gCc3TJhJaD4BiKaPhsP/vC78n05mMB+rT4ad4=; b=Vh4UK5oBnRI94ZAu7ER0P7FiCq2Kt9w9g4NT3RHweXVnp/nhC4SJ1KKhmK8ImP53ITSEj9iHvrE8FUUUCcJ8gqL9ZY04xFiLVAB6aONuhNs1CBFkzs1GqzFWpOV1nxxY6YvA3J/UYv7rsldiAJ6Liq76URT81ZtIE+DOav6tqik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A+1zfp2YNI4OCGGAPXVTU1/2AljPtn2tnEeNe7KJ31QU2yptJhodrBkafTiCaCCz0AOfs/sN7A1I4S+0jMKATAIEPF1lHpyvv5o67YD72kXNhieyM/wh67egN7S/Jvu3HifbVPstQcCO85lhahZMi35N7ijOoxPVn97gx9qVCwg= Received: by 10.82.156.12 with SMTP id d12mr3150094bue.1189808329804; Fri, 14 Sep 2007 15:18:49 -0700 (PDT) Received: by 10.82.150.16 with HTTP; Fri, 14 Sep 2007 15:18:49 -0700 (PDT) Message-ID: <840fa9b60709141518i7a5d8c25i62d18cd5f9ed4165@mail.gmail.com> Date: Sat, 15 Sep 2007 00:18:49 +0200 From: "Alexandru Petrescu" To: "Sri Gundavelli" Subject: Re: [netlmm] Alternatives to RECOMMENDED timestamp In-Reply-To: <017301c7f710$cf1fbe90$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> <840fa9b60709141300o2975d888i26a09b3ec23eb534@mail.gmail.com> <017301c7f710$cf1fbe90$d5f6200a@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On 9/14/07, Sri Gundavelli wrote: [...] > > On 9/14/07, Sri Gundavelli wrote: > > [...] > > > - Is it mandatory for the implementations to implement Timestamp > > > based solution. [Y/N]. Just a YES or NO, will be more than > > > sufficient. > > > > Yes, together with mandating seqnos. > > > > Mandating both as a MUST implement is not an issue. Seq numbers is > supported per 3775 any ways. But, we cannot force the MAG to learn > the seq number from the old MAG. That we cant mandate. If you are > ok with this, we can close this last issue. As I said privately to Ahmad: I'm not trying to suggest bringing CTX in the picture. The seqno can be learnt by MAG2 from LMA, as part of profile. Not from MAG1. I think the issue can thus be closed. The disturbing text is the only occurence of the word RECOMMEND, which means SHOULD. How, or do you plan to modify that phrase? Alex > > Thanks > Sri > > > > Alex > > > > > > > > > > > > > > Please comment on this and avoid going back to basics. We need > > > to complete this work. IMHO, for this entire race condition to > > > occur, quite a few things have to fall in place, some dramatic > > > affects and all the stars have to alligned in a pattern. Lets not > > > kill ourselves on this useless issue. Please help me close this. > > > > > > > > > > > > Regards > > > Sri > > > > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 18:40:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJpm-00043K-GP; Fri, 14 Sep 2007 18:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJpl-00043B-8L for netlmm@ietf.org; Fri, 14 Sep 2007 18:40:21 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWJpk-000616-2D for netlmm@ietf.org; Fri, 14 Sep 2007 18:40:21 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8EMeCs06352; Fri, 14 Sep 2007 22:40:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Alternatives to RECOMMENDED timestamp Date: Fri, 14 Sep 2007 17:40:06 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116C2D157@zrc2hxm2.corp.nortel.com> In-Reply-To: <840fa9b60709141518i7a5d8c25i62d18cd5f9ed4165@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Alternatives to RECOMMENDED timestamp Thread-Index: Acf3HUEyrgA0xjxcRSWoUx9+pLQd5AAAl1gQ References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> <840fa9b60709141300o2975d888i26a09b3ec23eb534@mail.gmail.com> <017301c7f710$cf1fbe90$d5f6200a@amer.cisco.com> <840fa9b60709141518i7a5d8c25i62d18cd5f9ed4165@mail.gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" , "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Subject: Re: [netlmm] Alternatives to RECOMMENDED timestamp >=20 > On 9/14/07, Sri Gundavelli wrote: > [...] > > > On 9/14/07, Sri Gundavelli wrote: > > > [...] > > > > - Is it mandatory for the implementations to implement=20 > Timestamp=20 > > > > based solution. [Y/N]. Just a YES or NO, will be more than=20 > > > > sufficient. > > > > > > Yes, together with mandating seqnos. > > > > > > > Mandating both as a MUST implement is not an issue. Seq numbers is=20 > > supported per 3775 any ways. But, we cannot force the MAG=20 > to learn the=20 > > seq number from the old MAG. That we cant mandate. If you=20 > are ok with=20 > > this, we can close this last issue. >=20 > As I said privately to Ahmad: I'm not trying to suggest=20 > bringing CTX in the picture. >=20 > The seqno can be learnt by MAG2 from LMA, as part of profile.=20 > Not from MAG1. [Ahmad] Alex, In the case of CT, the draft is referring to that as out-of-scope since it is not defined yet. In the case of your proposal of MAG2 learns the latest per-MN SQN from the LMA as part of profile, is that mechanism documented anywhere so the draft can reference it? >=20 > I think the issue can thus be closed. The disturbing text is=20 > the only occurence of the word RECOMMEND, which means SHOULD.=20 > How, or do you plan to modify that phrase? >=20 > Alex >=20 > > > > Thanks > > Sri > > > > > > > Alex > > > > > > > > > > > > > > > > > > > Please comment on this and avoid going back to basics.=20 > We need to=20 > > > > complete this work. IMHO, for this entire race=20 > condition to occur,=20 > > > > quite a few things have to fall in place, some dramatic affects=20 > > > > and all the stars have to alligned in a pattern. Lets not kill=20 > > > > ourselves on this useless issue. Please help me close this. > > > > > > > > > > > > > > > > Regards > > > > Sri > > > > > > > > > > > > > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 18:46:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJw7-0003k3-I1; Fri, 14 Sep 2007 18:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJw6-0003jw-Cg for netlmm@ietf.org; Fri, 14 Sep 2007 18:46:54 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWJw5-0006CL-6P for netlmm@ietf.org; Fri, 14 Sep 2007 18:46:54 -0400 X-IronPort-AV: E=Sophos;i="4.20,257,1186383600"; d="scan'208";a="524211463" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Sep 2007 15:46:53 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8EMkqWR024534; Fri, 14 Sep 2007 15:46:52 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8EMkquE019606; Fri, 14 Sep 2007 22:46:52 GMT Date: Fri, 14 Sep 2007 15:46:52 -0700 (PDT) From: Sri Gundavelli To: Alexandru Petrescu Subject: Re: [netlmm] Alternatives to RECOMMENDED timestamp In-Reply-To: <840fa9b60709141518i7a5d8c25i62d18cd5f9ed4165@mail.gmail.com> Message-ID: References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> <840fa9b60709141300o2975d888i26a09b3ec23eb534@mail.gmail.com> <017301c7f710$cf1fbe90$d5f6200a@amer.cisco.com> <840fa9b60709141518i7a5d8c25i62d18cd5f9ed4165@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=721; t=1189810012; x=1190674012; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[netlmm]=20Alternatives=20to=20RECOMMENDED=20timestam p |Sender:=20; bh=CT28HMtgG9V4EPcvBxQsUzOMswQACRz11toajvubbTo=; b=PxpKHINUTX1JX67wyjLSbP2AoDTTsTRB+aDCJdyI2jcynRbyHfRmIpq/ASRofGCDXr3kcIUe btgnhovWikkWN1GiHBlF1GcJ0GCxZETiySu/clLtFtDpUQciUg9VvU/3; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, > > The seqno can be learnt by MAG2 from LMA, as part of profile. Not from MAG1. > How the MAG learns seq num is out of scope, for both the CT based approach or uploading it to a policy store. > I think the issue can thus be closed. The disturbing text is the only > occurence of the word RECOMMEND, which means SHOULD. How, or do you > plan to modify that phrase? > Ok. I will rephrase that and state that both are two alternative approaches and with out any preference for a given approach. If the MAG has the ability to learn the seq number, some how, it can use the Seq number scheme, else it can use the timestamp based approach. What ever suits the deployment. Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 18:50:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJzT-0006ey-Qh; Fri, 14 Sep 2007 18:50:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJzS-0006ei-76 for netlmm@ietf.org; Fri, 14 Sep 2007 18:50:22 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWJzR-0006HK-13 for netlmm@ietf.org; Fri, 14 Sep 2007 18:50:22 -0400 X-IronPort-AV: E=Sophos;i="4.20,257,1186383600"; d="scan'208";a="399280306" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 14 Sep 2007 15:50:20 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8EMoKHn006717; Fri, 14 Sep 2007 15:50:20 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8EMoKuE022176; Fri, 14 Sep 2007 22:50:20 GMT Date: Fri, 14 Sep 2007 15:50:20 -0700 (PDT) From: Sri Gundavelli To: Ahmad Muhanna Subject: RE: [netlmm] Alternatives to RECOMMENDED timestamp In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116C2D157@zrc2hxm2.corp.nortel.com> Message-ID: References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> <840fa9b60709141300o2975d888i26a09b3ec23eb534@mail.gmail.com> <017301c7f710$cf1fbe90$d5f6200a@amer.cisco.com> <840fa9b60709141518i7a5d8c25i62d18cd5f9ed4165@mail.gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116C2D157@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=401; t=1189810220; x=1190674220; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[netlmm]=20Alternatives=20to=20RECOMMENDED=20timestam p |Sender:=20; bh=aTcpTaOqYSK4/H2p8StF3QhmqP+bygwxgdh1u0FPikM=; b=njUm0uB/6H72dnP3MbvxcfHQow29is4WAIDxNIRBI7DJv93A8SZJLSvAFaqebLMCqxLQkOPa Pg//pAilS+8JorUWiHnk83E+FzjO+oiWAgSSkVx3C3835CRvSJrhY715Dr2ZvT8bbO4PfFoBCk +/6M6Tt1GclBvwKb2DIdhnel0=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, > > In the case of CT, the draft is referring to that as out-of-scope since > it is not defined yet. In the case of your proposal of MAG2 learns the > latest per-MN SQN from the LMA as part of profile, is that mechanism > documented anywhere so the draft can reference it? > No. I dont think, the draft should reference this. Its out of scope for the base draft. Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 14 18:51:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWK0Q-00074Z-NH; Fri, 14 Sep 2007 18:51:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWK0P-00074U-Tl for netlmm@ietf.org; Fri, 14 Sep 2007 18:51:21 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWK0P-0000MV-IM for netlmm@ietf.org; Fri, 14 Sep 2007 18:51:21 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8EMmxc00307; Fri, 14 Sep 2007 22:48:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Alternatives to RECOMMENDED timestamp Date: Fri, 14 Sep 2007 17:51:16 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116C2D17A@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Alternatives to RECOMMENDED timestamp Thread-Index: Acf3IaJti42WNaePQxKil5iKRVMCAwAAA3MA References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> <840fa9b60709141300o2975d888i26a09b3ec23eb534@mail.gmail.com> <017301c7f710$cf1fbe90$d5f6200a@amer.cisco.com> <840fa9b60709141518i7a5d8c25i62d18cd5f9ed4165@mail.gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437116C2D157@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, That is fine with me. Regards, Ahmad =20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Friday, September 14, 2007 5:50 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Alexandru Petrescu; netlmm > Subject: RE: [netlmm] Alternatives to RECOMMENDED timestamp >=20 > Hi Ahmad, >=20 > > > > In the case of CT, the draft is referring to that as out-of-scope=20 > > since it is not defined yet. In the case of your proposal of MAG2=20 > > learns the latest per-MN SQN from the LMA as part of=20 > profile, is that=20 > > mechanism documented anywhere so the draft can reference it? > > >=20 > No. I dont think, the draft should reference this. Its out of=20 > scope for the base draft. >=20 > Thanks > Sri >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 15 02:20:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWR19-0002t4-NO; Sat, 15 Sep 2007 02:20:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWR17-0002sg-2K; Sat, 15 Sep 2007 02:20:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWR16-0008Qd-L5; Sat, 15 Sep 2007 02:20:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4C22F175C0; Sat, 15 Sep 2007 06:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IWR0b-0008GX-RH; Sat, 15 Sep 2007 02:20:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 15 Sep 2007 02:20:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: netlmm@ietf.org Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-05.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF. Title : Proxy Mobile IPv6 Author(s) : S. Gundavelli, et al. Filename : draft-ietf-netlmm-proxymip6-05.txt Pages : 60 Date : 2007-09-15 This specification describes a network-based mobility management protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 [RFC-3775]. This protocol enables mobility support to a host without requiring its participation in any mobility related signaling. The design principle in the case of network-based mobility management protocol relies on the network being in control of the mobility management. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-netlmm-proxymip6-05.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-ietf-netlmm-proxymip6-05.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: <2007-09-15021410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netlmm-proxymip6-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netlmm-proxymip6-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-15021410.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --NextPart-- From netlmm-bounces@ietf.org Mon Sep 17 07:40:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXExZ-0007Nk-St; Mon, 17 Sep 2007 07:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXExZ-0007Nf-CY for netlmm@ietf.org; Mon, 17 Sep 2007 07:40:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXExY-0001e3-2Y for netlmm@ietf.org; Mon, 17 Sep 2007 07:40:13 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2130342uge for ; Mon, 17 Sep 2007 04:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Gslw3mZQV6VvA/ArXyppbmYluJto0glvzH85P3WW/Ww=; b=Z7aSRzWZ0VqnUXlQWgcsuLP+4jbsCRYNryoEZIPh19Gxy4Y242a/9UCFce5Hx5cG0cn6jS/9atZQ79jnxANrJow2WemAQ98p24eTM8GHXQYOSHs2gjOGFaMwUTjnyoUp/+4kgtAvn3D1hjGlSSaY9w9u73kIczRb96oGZbNHgmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=XuDzxvHSKWMHpw6JiALtMlj2Ter15/b5ezj+DRBrPj8mw3vA6wd/AG8zSLGWxpkljUA0fEBZqvZxAkFMV68b3ScWOm/H36kykW7u9Zy8+x/84ocHYJhaNPVMyMnwe8qS0TlcsfmOU0aC2OtyEvnAhHxOUkmmOqv1zg+qlFonOnc= Received: by 10.67.100.11 with SMTP id c11mr3723640ugm.1190029211101; Mon, 17 Sep 2007 04:40:11 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id m1sm8230861uge.2007.09.17.04.40.06 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2007 04:40:07 -0700 (PDT) From: Julien Laganier To: "Sri Gundavelli" Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Mon, 17 Sep 2007 13:40:03 +0200 User-Agent: KMail/1.9.6 References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <200709131010.48638.julien.IETF@laposte.net> <016f01c7f612$e36aa5d0$d5f6200a@amer.cisco.com> In-Reply-To: <016f01c7f612$e36aa5d0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200709171340.04321.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, On Thursday 13 September 2007, Sri Gundavelli wrote: > Hi Julien, > > > -----Original Message----- > > From: julien laganier [mailto:julien.laganier@gmail.com] On > > Behalf Of Julien Laganier > > Sent: Thursday, September 13, 2007 1:11 AM > > To: netlmm@ietf.org > > Cc: Premec, Domagoj; Sri Gundavelli > > Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt > > > > Hi Domagoj, > > > > I disagree with one of your comment below: > > > > On Wednesday 12 September 2007, Premec, Domagoj wrote: > > > >6.3. =A0Supported Access Link Types > > > > > > > > =A0 This specification supports only point-to-point access > > > > link types > > > > > > and thus it assumes that the mobile node and the mobile access > > > > gateway are the only two nodes on the access link. =A0The link is > > > > assumed to have multicast capability. > > > > > > I understand that the decision to use per-MN prefix model was > > > motivated by the need to emulate the point-to-point link at the > > > IP layer. > > > > Not true. > > > > Use of a per-MN prefix model has been motivated by the need to > > avoid multilink subnet issues [RFC4903]. > > > > Following that prefix model choice, we have discussed at > > length on that > > mailing list what are the implication of that model on the > > supported underlying link (i.e. below IP). The per-MN prefix on a > > pt-to-pt link has no issue. It is not clear however if it would > > work well on a shared > > link. The consensus of the WG has been that the current spec will > > be limited to support of pt-to-pt links. > > > > Support for shared link can be added later in another > > specification. > > > > > As the IP layer is configured in such a way that there are > > > exactly two nodes on the link, we're actually independet of the > > > underlaying link layer technology. > > > > No configuration of the IP layer can restrict the number of > > nodes on a > > link. The link properties are independent from those of the IP > > layer. > > > > > I think the intent of the spec is to support any access link > > > type, including for example 802.11. > > > > I think the intent of the spec is to support only pt-to-pt > > links for now > > since that's the only type of link where the per-MN prefix > > model has no > > known issues. > > May be I misunderstood what Domagoj comment. My point is that > we do allow access links such as 802.11, as long as the p2p > requirement is met from L3 perspective, implies, there are only > two nodes on the access link. A multicast RA sent by the MAG is > received just by one node, as long as the link meets this requirement > we are ok. That's fine with me. =2D-julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 17 07:40:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXEy5-0007RF-8T; Mon, 17 Sep 2007 07:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXEy4-0007QW-8g for netlmm@ietf.org; Mon, 17 Sep 2007 07:40:44 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXEy3-0001e3-2A for netlmm@ietf.org; Mon, 17 Sep 2007 07:40:44 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2130342uge for ; Mon, 17 Sep 2007 04:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Jv854nn9Ny/40zeSkk7+XTeAmFzNTRg0t3EDdutt2gg=; b=AIxcBY6dD/hCZMY1ZOcAaE30v4pcH8Fo/xTDPBGf9mw072ajjHizWtApWPlMYNN+IjLo9ce/GLPBpX5mWcB9tuqWEacjeKQn7glbuVnOb+f/kyBwhJbJtiigHEoDe9o93Yl8h3XEg+A0vVtP7YGlXstSxeymhQoOrLlm7Wxhxps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=CLifA/wSNgeMUTIxiC1JWa17k/8gWS6kggMxLGRfpCV3NriCV21/e6qjpMgkSDv/2nJWIY2Ns+47ncbmEYeZ/o9IZcn/lPGJW0yaXIoRJnzMvBG5/Ca58xqt0e+m7iPQZqGEWvnGZZBjYgB9wZeqwChCg5b5tz6HpoKovmX2ZWs= Received: by 10.67.20.3 with SMTP id x3mr5457373ugi.1190029242414; Mon, 17 Sep 2007 04:40:42 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 19sm8275354ugl.2007.09.17.04.40.40 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2007 04:40:41 -0700 (PDT) From: Julien Laganier To: "Premec, Domagoj" Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Mon, 17 Sep 2007 13:40:38 +0200 User-Agent: KMail/1.9.6 References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <016f01c7f612$e36aa5d0$d5f6200a@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD680296BA0A@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680296BA0A@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709171340.39310.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Domagoj, On Thursday 13 September 2007, Premec, Domagoj wrote: > Hi Julien, Sri, > > Julien's interpretation of my comment is right, but I don't want to > trigger the discussion about the link model type. I would be fine if > following clarification sentence could be added to section 6.3 > Supported Access Link Types: > > "This protocol may be used also with other access link types, such as > multi-access links, as long as the access link is configured in such > a way that it guarantees a point-to-point delivery between the MAG > and the MN for all types of traffic." > > Would that be acceptable? That would be fine with me. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 17 12:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJHY-0005JS-D7; Mon, 17 Sep 2007 12:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJHX-0005JM-Uh for netlmm@ietf.org; Mon, 17 Sep 2007 12:17:07 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXJHW-0007qf-Im for netlmm@ietf.org; Mon, 17 Sep 2007 12:17:07 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2280154uge for ; Mon, 17 Sep 2007 09:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=M9IF3X142SqcDnNfXYug9uu/FBugJdE9P98ftxKYQLk=; b=YOqHsw5vwBGFt2a89tLe+6/cKg5pYJDqznu1DCTM18pR3n8JIRYq71HRDGAoRM3VHMoC13M1XNfOFImoUWhSrtoQx5jDailoK8Cu0wq785DTHf14OG6ReNnx8a+tyJ8BDUtq/eMyIur1B5KfLyv3lI8U0HrhKAnaRaeVpmiQe3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=grdbBaJkx7fdOKa1K6ZUdMpHS2SwOx0EXYGglD42miaGdfsFMBuFG0vqx+BMrGZvQfe4LIfT5K/+41KMaSt15aTy/fV8rtvrXCzoLE6IEw4XVVJrH5ySY5mSt6+esch2o+d8X+mJ0tppxsSThGi+1rEXeRzhcv9BPaJh8szwPiQ= Received: by 10.78.122.16 with SMTP id u16mr1601922huc.1190045824687; Mon, 17 Sep 2007 09:17:04 -0700 (PDT) Received: by 10.78.158.5 with HTTP; Mon, 17 Sep 2007 09:17:04 -0700 (PDT) Message-ID: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> Date: Mon, 17 Sep 2007 20:47:04 +0430 From: "JinHyeock Choi" To: netlmm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Subject: [netlmm] Comments on draft-05 X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Dear Sri I went over the draft and it looks fine. Thanks for your trouble for the improvement. Here are a few concerns. 1. Prefix lifetime. As of RFC 2461, a default router advertises a prefix with Prefix Information Option (PIO) in Router Advertisement message. PIO has two prefix lifetime fields, 'Valid Lifetime' and 'Preferred Lifetime'. However, I found no lifetime field in Home Network Prefix Option (with which a MAG gets a Home Network Prefix from a LMA). So, when advertising a Home Network Prefix to an MN, with which value does the MAG configure the prefix lifetime? 2. Initial Binding Registration & Binding Re-Registration. I think the terms 'Initial Binding Registration' & 'Binding Re-Registration' are not clear enough. The draft describes 'Initial Binding Registration' & 'Binding Re-Registration' for LMA in 'Sec 5.3 Signaling Consideration' and for MAG in 'Sec 6.9.1. Binding Registrations'. o The local mobility anchor MUST use the identifier in the NAI option [RFC-4283] present in the Proxy Binding Update request for performing the Binding Cache entry existence test. If the entry does not exist, the local mobility MUST consider this request as an initial binding registration request. >From the above I assume that Definition 1. When a LMA receives a PBU from a MAG, if the LMA has no Binding Cache entry for the MN-Identifer in the PBU, this is Initial Binding Registration. On the other hand, When a LMA receive a PBU from a MAG, if the LMA has a Binding Cache entry for the MN-Identifer in the PBU, this is Binding Re-Registration, even though the Binding Cache entry is associated with an another MAG Am I right? If so, the above definition may not work with the MAG case in Sec 6.9.1. First, it's difficult to divide MAG operation into 'Initial Binding Registration' and 'Binding Re-Registraion'. When sending a PBU to a LMA for a newly attached MN, a MAG doesn't know whether the LMA has a Binding Cache entry for the MN or not. So the MAG has no way to know whether it performs 'Initial Binding Registration' or 'Binding Re-Registration' Moreover I got the impression that the terms 'Initial Binding Registration' and 'Binding Re-Registraion' mean different things for LMA (Sec 5.3) and MAG (Sec 6.9.1). For MAG, we may define 'Initial Binding Registraion' and 'Binding Re-Registraion' differently using the MAG's Binding Update List as below. Definition 2. When a MAG sends a PBU for an MN, if the MAG has no entry for the MN in its Binding Update List, this is 'Initial Binding Registraion'. On the other hand When a MAG sends a PBU for an MN, if the MAG has an entry for the MN in its Binding Update List, this is 'Binding Re-Registraion'. As you can see, Definition 1 and Definition 2 are not identical. I am afraid that it may cause confusion to use the same terms 'Initial Binding Registration' & 'Binding Re-Registraion' in two different meanings. I'll write more about these in the in-line comments below. In Sec 1. An undefined term 'proxy mobility agent' were used a few times. Does this mean 'MAG' or 'MAG + LMA'? sub This approach to supporting/ This approach to support In Sec 2.2. sub with the additional required capabilities for/ with the additional capabilities required for In Sec 3. sub The local mobility/ The local mobility anchor In Sec 5.3. o The local mobility anchor MUST use the identifier in the NAI option [RFC-4283] present in the Proxy Binding Update request for performing the Binding Cache entry existence test. If the entry does not exist, the local mobility MUST consider this request as an initial binding registration request. After the above, I recommend to add the below. If the entry exists, the local mobility anchor MUST consider this request as an Binding Re-Registration request Also sub local mobility/ local mobility anchor In Binding Re-Registraion part, I recommend to add a case for HNP Option with 0::/0 as below. o If the Home Network Prefix option present in the Proxy Binding Update request has the value 0::/0 but there is a Binding Cache entry for the MN, the local mobility anchor MUST use the Home Network Prefix associated with the entry and send a Proxy Binding Acknowledgement message with the Home Network Prefix. In Sec 6.6 sub be able/ be able to In Sec 6.9.1. 'Initial Binding Registraion' and 'Binding Re-Registraion' are not clearly defined for MAG. Binding Re-Registration: o For extending the lifetime of a currently existing binding at the local mobility, the mobile access gateway MUST send a Proxy Binding Update message to the local mobility anchor. How can the MAG know that, for a newly attached MN, there already exists a binding in an LMA? The prefix value in the Home Network Prefix option present in the request SHOULD be set to the currently registered home network prefix Even if there exists a binding, the MAG may not know the currently registered Home Network Prefix, unless there exists an entry for the Binding Update List. In that case, we'd better allow a Home Network Prefix Option with 0::/0 value. In Sec 7.2. As long as the attached access network is in the scope of that Proxy Mobile IPv6 domain, the mobile node will always detect the same link, where it obtained its initial address configuration. If the mobile node performs DHCP operation, it will always obtain the same address as before. This may be wrong. Performing DHCP operation in PMIPv6 domain, the MN will get the addresses with the same Home Network Prefix but may not always get the same address. I recommend to change the last part as If the mobile node performs DHCP operation, it will always obtain an address with the same Home Network Prefix. Thanks for your kind consideration. Best Regards JinHyeock _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 17 12:38:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJc8-0001SO-NW; Mon, 17 Sep 2007 12:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJc6-0001SI-PP for netlmm@ietf.org; Mon, 17 Sep 2007 12:38:22 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXJc5-0008Mj-Ha for netlmm@ietf.org; Mon, 17 Sep 2007 12:38:22 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1190047100!904020!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 4879 invoked from network); 17 Sep 2007 16:38:20 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-7.tower-128.messagelabs.com with SMTP; 17 Sep 2007 16:38:20 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l8HGcKuF010059; Mon, 17 Sep 2007 09:38:20 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8HGcJXH006810; Mon, 17 Sep 2007 11:38:19 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8HGcHt6006783; Mon, 17 Sep 2007 11:38:18 -0500 (CDT) Message-ID: <46EEAD78.4080504@gmail.com> Date: Mon, 17 Sep 2007 18:38:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [netlmm] Alternatives to RECOMMENDED timestamp References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> <840fa9b60709141300o2975d888i26a09b3ec23eb534@mail.gmail.com> <017301c7f710$cf1fbe90$d5f6200a@amer.cisco.com> <840fa9b60709141518i7a5d8c25i62d18cd5f9ed4165@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000774-7, 15/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri Gundavelli wrote: > Hi Alex, > > >> >> The seqno can be learnt by MAG2 from LMA, as part of profile. Not >> from MAG1. >> > > How the MAG learns seq num is out of scope, for both the CT based > approach or uploading it to a policy store. Right, and I can offer a third way on a separate thread, if need is (MAG builds a seqno from the MN's NA Target address and increments it from there, while LMA uses windows of acceptance). >> I think the issue can thus be closed. The disturbing text is the >> only occurence of the word RECOMMEND, which means SHOULD. How, or >> do you plan to modify that phrase? >> > > Ok. I will rephrase that and state that both are two alternative > approaches and with out any preference for a given approach. If the > MAG has the ability to learn the seq number, some how, it can use the > Seq number scheme, else it can use the timestamp based approach. What > ever suits the deployment. I agree. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 17 22:38:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXSxb-0003lm-6z; Mon, 17 Sep 2007 22:37:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXSxZ-0003Z2-Ic for netlmm@ietf.org; Mon, 17 Sep 2007 22:37:09 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXSxY-0001fC-5C for netlmm@ietf.org; Mon, 17 Sep 2007 22:37:09 -0400 X-IronPort-AV: E=Sophos;i="4.20,266,1186383600"; d="scan'208";a="524927719" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Sep 2007 19:37:07 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8I2b7op024365; Mon, 17 Sep 2007 19:37:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8I2b5fb013547; Tue, 18 Sep 2007 02:37:07 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 19:33:51 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 19:33:50 -0700 From: "Sri Gundavelli" To: "'JinHyeock Choi'" , References: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> Subject: RE: [netlmm] Comments on draft-05 Date: Mon, 17 Sep 2007 19:33:54 -0700 Message-ID: <00d701c7f99c$5b543c50$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf5RjelczVdXsddSHWsTpyi5JEGswASnw5Q In-Reply-To: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 18 Sep 2007 02:33:50.0574 (UTC) FILETIME=[58F0D0E0:01C7F99C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8439; t=1190083027; x=1190947027; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Comments=20on=20draft-05 |Sender:=20; bh=ybzbUU+DSY0+3lf5ZXbFmI2geu6xQ9bG+jDsncP40KI=; b=LcGBTWXDSDE8r/mGN8bHtWD3zXGD2F8vGZKFmyMYs3wB8NdwtmttL+XC/ufOA1xu+75C3Gdi CffgyFcqCohA+61ip86dKmKqvacolQa1f/MSahnfcu/padiNljV6aHu2; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi JinHyeock, > -----Original Message----- > From: JinHyeock Choi [mailto:jinchoe@gmail.com] > Sent: Monday, September 17, 2007 9:17 AM > To: netlmm@ietf.org > Subject: [netlmm] Comments on draft-05 > > Dear Sri > > I went over the draft and it looks fine. Thanks for your trouble for > the improvement. Here are a few concerns. > > 1. Prefix lifetime. > As of RFC 2461, a default router advertises a prefix with Prefix > Information Option (PIO) in Router Advertisement message. PIO has two > prefix lifetime fields, 'Valid Lifetime' and 'Preferred Lifetime'. > > However, I found no lifetime field in Home Network Prefix Option (with > which a MAG gets a Home Network Prefix from a LMA). So, when > advertising a Home Network Prefix to an MN, with which value does the > MAG configure the prefix lifetime? > The HNP is delated to the MAG and once the p2p link comes up, the MAG needs to host this prefix on the link and advertise the prefix. So, the considerations from 2461 apply. I thought about this in the past and did not see a need to provide guidance on the lifetime parameters. But, we can tie this to the accepted BU lifetime or specify some optional config params in the profile. But, its really about IPv6 prefix config on a link. > 2. Initial Binding Registration & Binding Re-Registration. > > I think the terms 'Initial Binding Registration' & 'Binding > Re-Registration' > are not clear enough. > I see your point. What is initial registration for a MAG is a re-registration for the LMA. I will try to differentiate and fix the title. > The draft describes 'Initial Binding Registration' & 'Binding > Re-Registration' > for LMA in 'Sec 5.3 Signaling Consideration' and > for MAG in 'Sec 6.9.1. Binding Registrations'. > > o The local mobility anchor MUST use the identifier in the NAI > option [RFC-4283] present in the Proxy Binding Update > request for > performing the Binding Cache entry existence test. If the entry > does not exist, the local mobility MUST consider this request as > an initial binding registration request. > > >From the above I assume that > > Definition 1. > When a LMA receives a PBU from a MAG, > if the LMA has no Binding Cache entry for the MN-Identifer in the PBU, > this is Initial Binding Registration. > > On the other hand, > > When a LMA receive a PBU from a MAG, > if the LMA has a Binding Cache entry for the MN-Identifer in the PBU, > this is Binding Re-Registration, > even though the Binding Cache entry is associated with an another MAG > > Am I right? If so, the above definition may not work with the MAG case > in Sec 6.9.1. > > First, it's difficult to divide MAG operation into > 'Initial Binding Registration' and 'Binding Re-Registraion'. > > When sending a PBU to a LMA for a newly attached MN, > a MAG doesn't know > whether the LMA has a Binding Cache entry for the MN or not. > > So the MAG has no way to know whether > it performs 'Initial Binding Registration' or 'Binding > Re-Registration' > > Moreover I got the impression that > the terms 'Initial Binding Registration' and 'Binding Re-Registraion' > mean different things for LMA (Sec 5.3) and MAG (Sec 6.9.1). > > For MAG, we may define 'Initial Binding Registraion' and 'Binding > Re-Registraion' > differently using the MAG's Binding Update List as below. > > Definition 2. > When a MAG sends a PBU for an MN, > if the MAG has no entry for the MN in its Binding Update List, > this is 'Initial Binding Registraion'. > > On the other hand > > When a MAG sends a PBU for an MN, > if the MAG has an entry for the MN in its Binding Update List, > this is 'Binding Re-Registraion'. > > As you can see, Definition 1 and Definition 2 are not identical. > I am afraid that it may cause confusion to use the same terms > 'Initial Binding Registration' & 'Binding Re-Registraion' in two > different meanings. > > I'll write more about these in the in-line comments below. > > In Sec 1. > An undefined term 'proxy mobility agent' were used a few times. > Does this mean 'MAG' or 'MAG + LMA'? > This is not a term. Its the core concept of PMIP. There is an entity that does proxy mip function and that we call it as a MAG. I removed the term PMA from the draft, after your comment some time back. But, I do not think, this line adds any ambiguity. > sub > This approach to supporting/ This approach to support > Ok > In Sec 2.2. > sub > with the additional required capabilities for/ with the additional > capabilities required for > ok > In Sec 3. > sub > The local mobility/ The local mobility anchor > Ok. > In Sec 5.3. > > o The local mobility anchor MUST use the identifier in the NAI > option [RFC-4283] present in the Proxy Binding Update > request for > performing the Binding Cache entry existence test. If the entry > does not exist, the local mobility MUST consider this request as > an initial binding registration request. > > After the above, I recommend to add the below. > > If the entry exists, the local mobility anchor MUST consider this > request as an Binding Re-Registration request > ok > Also sub > local mobility/ local mobility anchor > ok > In Binding Re-Registraion part, > I recommend to add a case for HNP Option with 0::/0 as below. > > o If the Home Network Prefix option present in the Proxy Binding > Update request has the value 0::/0 but there is a Binding Cache > entry for the MN, the local mobility anchor MUST use the Home > Network Prefix associated with the entry and send a Proxy Binding > Acknowledgement message with the Home Network Prefix. > ok > In Sec 6.6 > > sub > be able/ be able to > ok > In Sec 6.9.1. > > 'Initial Binding Registraion' and 'Binding Re-Registraion' are not > clearly defined for MAG. > As I commented above, I will fix the titles and differentiate the two cases. > Binding Re-Registration: > > o For extending the lifetime of a currently existing > binding at the > local mobility, the mobile access gateway MUST send a Proxy > Binding Update message to the local mobility anchor. > > How can the MAG know that, for a newly attached MN, > there already exists a binding in an LMA? > > The prefix > value in the Home Network Prefix option present in the request > SHOULD be set to the currently registered home network prefix > > Even if there exists a binding, the MAG may not know > the currently registered Home Network Prefix, > unless there exists an entry for the Binding Update List. > In that case, we'd better allow a Home Network Prefix Option > with 0::/0 value. > I will clarify this to indicate that when there is BUL entry for that MN, instead of saying, if there exists a binding on the LMA ... > In Sec 7.2. > > As long as the attached access > network is in the scope of that Proxy Mobile IPv6 domain, > the mobile > node will always detect the same link, where it obtained > its initial > address configuration. If the mobile node performs DHCP operation, > it will always obtain the same address as before. > > This may be wrong. Performing DHCP operation in PMIPv6 domain, > the MN will get the addresses with the same Home Network Prefix > but may not always get the same address. > No. This is correct. The client identifier in the DHCP request will remain the same. This is exactly as how, when your laptop does a dhcp lease extension, gets the same address. The identifier of the client is present in the request and the DHCP server would allocate the same address as before. It wont consider this request as a request from a different client. > I recommend to change the last part as > > If the mobile node performs DHCP operation, > it will always obtain an address with the same Home Network Prefix. > > Thanks for your kind consideration. > Thanks for your good comments. I will make the changes. Sri > Best Regards > > JinHyeock > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 01:22:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXVXD-0004rn-3l; Tue, 18 Sep 2007 01:22:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXVXB-0004r7-1Y for netlmm@ietf.org; Tue, 18 Sep 2007 01:22:05 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXVX4-0004iK-Oa for netlmm@ietf.org; Tue, 18 Sep 2007 01:22:05 -0400 Received: by nf-out-0910.google.com with SMTP id d21so1298181nfb for ; Mon, 17 Sep 2007 22:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pStSWaLFLBnhiwUExXSbniYu4g8XKc07Yi21k3soVfc=; b=S2YC1buo6V0Vfu+Sc5K4zDaa0dqMBruAtq4uyCr6pKX61Ut/9HyaEs1EmuUtHwl9Ra2n4qbNbz/1xhmjZJ9QaHqNyThx6je4AIUeE/jEXiaS3e/i4CH3ZVNFQUxytj//3RB4XnAYbjcBhWyvHJfmsSxFsLLb9ZbQUKveAhwodxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZudNQz8qhl/UaoYxm7iLQRXvgUPablH/cFyn00NAiyJ97hsKZZDHdaObDzK2f0OSzZoF7YJcVcCQQBlMOmj+tB+eNZwc3gpGlbYBLOASQVyzPmUo0Es9giLFEbE4T7doC6n7JoFMMH3ehtqZh6VadsFttfz5R7h7082yJjl/pgM= Received: by 10.78.185.15 with SMTP id i15mr2594414huf.1190092897452; Mon, 17 Sep 2007 22:21:37 -0700 (PDT) Received: by 10.78.158.5 with HTTP; Mon, 17 Sep 2007 22:21:32 -0700 (PDT) Message-ID: <92e919fb0709172221seee5394h9c99020111d87cf0@mail.gmail.com> Date: Tue, 18 Sep 2007 09:51:32 +0430 From: "JinHyeock Choi" To: "Sri Gundavelli" Subject: Re: [netlmm] Comments on draft-05 In-Reply-To: <00d701c7f99c$5b543c50$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> <00d701c7f99c$5b543c50$d5f6200a@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri thanks for your kind and prompt reply. please see my in-line comments. > > 1. Prefix lifetime. > > As of RFC 2461, a default router advertises a prefix with Prefix > > Information Option (PIO) in Router Advertisement message. PIO has two > > prefix lifetime fields, 'Valid Lifetime' and 'Preferred Lifetime'. > > > > However, I found no lifetime field in Home Network Prefix Option (with > > which a MAG gets a Home Network Prefix from a LMA). So, when > > advertising a Home Network Prefix to an MN, with which value does the > > MAG configure the prefix lifetime? > > The HNP is delated to the MAG and once the p2p link comes up, > the MAG needs to host this prefix on the link and advertise the > prefix. So, the considerations from 2461 apply. I thought about > this in the past and did not see a need to provide guidance on > the lifetime parameters. But, we can tie this to the accepted BU > lifetime or specify some optional config params in the profile. > But, its really about IPv6 prefix config on a link. ok. I understand that a MAG is entitled to configure prefix lifetime with its own discretion. Maybe we'd better explicitly write that down in Sec 6.7. Home Network Emulation. How about adding the below at the end of 6.7.? When advertising the home network prefix, the mobile access gateway can configure the prefix lifetime value with its own discretion. But an implementation can tie the prefix lifetime to the accepted PBU lifetime or specify some optional configuration parameters in the profile. > > 2. Initial Binding Registration & Binding Re-Registration. > > > > I think the terms 'Initial Binding Registration' & 'Binding > > Re-Registration' > > are not clear enough. > > > > I see your point. > What is initial registration for a MAG is a re-registration > for the LMA. I will try to differentiate and fix the title. ok. thanks. > > address configuration. If the mobile node performs DHCP operation, > > it will always obtain the same address as before. > > > > This may be wrong. Performing DHCP operation in PMIPv6 domain, > > the MN will get the addresses with the same Home Network Prefix > > but may not always get the same address. > > No. This is correct. The client identifier in the DHCP request will > remain the same. This is exactly as how, when your laptop does a dhcp > lease extension, gets the same address. The identifier of the client > is present in the request and the DHCP server would allocate the same > address as before. It wont consider this request as a request from a > different client. If a DHCP relay agent puts a whole IPv6 address in a DHCPv6 Request message as a hint to a DHCP server, the DHCP can allocate the same address as before. However, 1) the DHCP relay agent in a foreign network may not know the MN's existing IPv6 address (because HNP Option provides only HNP) and 2) it's written in the draft that the DHCP relay agent puts 'the mobile node's home network prefix' as below. 6.11. Interaction with DHCP Relay Agent When the mobile node sends a DHCPv6 Request message, the DHCP relay agent function on the access link will set the link-address field in the DHCPv6 message to the mobile node's home network prefix, so as to provide a prefix hint to the DHCP Server for the address pool selection. Am I missing something? If so, kindly let me know. Thanks for your kind consideration. Best Regards JinHyeock _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 01:40:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXVoU-0003k6-6V; Tue, 18 Sep 2007 01:39:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXVoS-0003ic-8R for netlmm@ietf.org; Tue, 18 Sep 2007 01:39:56 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXVoQ-0005Ll-Qp for netlmm@ietf.org; Tue, 18 Sep 2007 01:39:56 -0400 X-IronPort-AV: E=Sophos;i="4.20,266,1186383600"; d="scan'208";a="176507915" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 17 Sep 2007 22:39:54 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8I5dsj5005187; Mon, 17 Sep 2007 22:39:54 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8I5d5fN029557; Tue, 18 Sep 2007 05:39:54 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 22:39:05 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 22:39:05 -0700 From: "Sri Gundavelli" To: "'JinHyeock Choi'" References: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> <00d701c7f99c$5b543c50$d5f6200a@amer.cisco.com> <92e919fb0709172221seee5394h9c99020111d87cf0@mail.gmail.com> Subject: RE: [netlmm] Comments on draft-05 Date: Mon, 17 Sep 2007 22:39:04 -0700 Message-ID: <00f201c7f9b6$39560010$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf5s8rJ4QHIaS5hSD+v/sphVA3rmAAAOPpg In-Reply-To: <92e919fb0709172221seee5394h9c99020111d87cf0@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 18 Sep 2007 05:39:05.0327 (UTC) FILETIME=[39D987F0:01C7F9B6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4993; t=1190093994; x=1190957994; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Comments=20on=20draft-05 |Sender:=20; bh=HAR6GSCD/NrNhvKt8roQwCF0cPCbzKt9NG1OvCf3W14=; b=CoeUZfeUGfCxmCNdE2zWjebkUK9SneAWS/zdrD807iPt27B1XCTf0W05dEThCb4nh9sSk8Gd Ixnc1+2luh0N3qjKwgtXgwoIbYM+B5BYFxaL7UyEcxDB8EtAhkYGVK3e; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi JinHyeock, > -----Original Message----- > From: JinHyeock Choi [mailto:jinchoe@gmail.com] > Sent: Monday, September 17, 2007 10:22 PM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: Re: [netlmm] Comments on draft-05 > > Sri > > thanks for your kind and prompt reply. please see my in-line comments. > Actually, lot of your initial comments made into the draft. Thanks for some good comments. > > > 1. Prefix lifetime. > > > As of RFC 2461, a default router advertises a prefix with Prefix > > > Information Option (PIO) in Router Advertisement message. > PIO has two > > > prefix lifetime fields, 'Valid Lifetime' and 'Preferred Lifetime'. > > > > > > However, I found no lifetime field in Home Network Prefix > Option (with > > > which a MAG gets a Home Network Prefix from a LMA). So, when > > > advertising a Home Network Prefix to an MN, with which > value does the > > > MAG configure the prefix lifetime? > > > > The HNP is delated to the MAG and once the p2p link comes up, > > the MAG needs to host this prefix on the link and advertise the > > prefix. So, the considerations from 2461 apply. I thought about > > this in the past and did not see a need to provide guidance on > > the lifetime parameters. But, we can tie this to the accepted BU > > lifetime or specify some optional config params in the profile. > > But, its really about IPv6 prefix config on a link. > > ok. I understand that a MAG is entitled to configure prefix lifetime > with its own discretion. Maybe we'd better explicitly write that down > in Sec 6.7. Home Network Emulation. How about adding the below at the > end of 6.7.? > I will try add some text around this. Will provide some guidance. > When advertising the home network prefix, > the mobile access gateway can configure the prefix lifetime value > with its own discretion. > But an implementation can tie the prefix lifetime to the > accepted PBU lifetime > or specify some optional configuration parameters in the profile. > > > > 2. Initial Binding Registration & Binding Re-Registration. > > > > > > I think the terms 'Initial Binding Registration' & 'Binding > > > Re-Registration' > > > are not clear enough. > > > > > > > I see your point. > > What is initial registration for a MAG is a re-registration > > for the LMA. I will try to differentiate and fix the title. > > ok. thanks. > > > > address configuration. If the mobile node performs > DHCP operation, > > > it will always obtain the same address as before. > > > > > > This may be wrong. Performing DHCP operation in PMIPv6 domain, > > > the MN will get the addresses with the same Home Network Prefix > > > but may not always get the same address. > > > > No. This is correct. The client identifier in the DHCP request will > > remain the same. This is exactly as how, when your laptop > does a dhcp > > lease extension, gets the same address. The identifier of the client > > is present in the request and the DHCP server would > allocate the same > > address as before. It wont consider this request as a request from a > > different client. > > If a DHCP relay agent puts a whole IPv6 address > in a DHCPv6 Request message as a hint to a DHCP server, > the DHCP can allocate the same address as before. > > However, > 1) the DHCP relay agent in a foreign network may not know > the MN's existing IPv6 address (because HNP Option > provides only HNP) and > 2) it's written in the draft that > the DHCP relay agent puts 'the mobile node's home network > prefix' as below. > > 6.11. Interaction with DHCP Relay Agent > > When the mobile node sends a DHCPv6 Request message, the > DHCP relay > agent function on the access link will set the > link-address field in > the DHCPv6 message to the mobile node's home network > prefix, so as to > provide a prefix hint to the DHCP Server for the address pool > selection. > > Am I missing something? If so, kindly let me know. > The DHCP server keeps a binding between an address and a client id. If there is a valid lease for a client, any subsequent request from the client will still contain the same client id and the DHCP server will attempt to issue the same address. Also, the request is comming from the MN and if its knows its earlier address, it can request for the same. If it does not know its earlier address, but if there exists a lease on the DHCP server for that client, it will still end up with its earlier address, because the client id is still the same. This is per 3315, standard behavior. If you reboot your laptop today, you will still get the same address, unless the pool size is overloaded or some special settings are active. The server attempts to allocate an address, that the client is using earlier. Thanks Sri > Thanks for your kind consideration. > > Best Regards > > JinHyeock _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 02:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXWIL-00044s-0h; Tue, 18 Sep 2007 02:10:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXWIK-00043i-HX for netlmm@ietf.org; Tue, 18 Sep 2007 02:10:48 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXWIE-0005rM-Vz for netlmm@ietf.org; Tue, 18 Sep 2007 02:10:48 -0400 Received: by nf-out-0910.google.com with SMTP id d21so1304385nfb for ; Mon, 17 Sep 2007 23:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=fEKgxCOGk4oZ+S0UblfB8Jxp6qEaSxCoRu6gBy3pWS0=; b=OlWAl3vKabl5qVzK7ioI4D13URJUdFasRoi3V3ICeA50zdp1r+tmABkhGo1PwVhOslTlF9fNR6wxbgkhcY3Z6PK8ppZnTRhvUNCllBk8NmKP3jnZ6SminyKWJ1XsiSOSXHJ1w6kQNOD6Iz6B8TIpKJ/in4uqvdHtktmuc5VEYuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nlvQ4JsPBiSybVCfkPFFN3Jt0DvjdkEUnomD0MLtdOs5oJ2/IXtNjApSqJDc8R4uaNXzV4ojiB06ct/Rj40HKk7NtfSlZljxO7JPL7TfNK/cAkIwxrhxgsN3rsSXAFR0m0rLCALmrq//3t6pwSxBh4r4fy1I0y9p41n5+b+vcVg= Received: by 10.78.181.13 with SMTP id d13mr3274473huf.1190095831725; Mon, 17 Sep 2007 23:10:31 -0700 (PDT) Received: by 10.78.158.5 with HTTP; Mon, 17 Sep 2007 23:10:31 -0700 (PDT) Message-ID: <92e919fb0709172310i668bfe0ficafe09cb732f5c08@mail.gmail.com> Date: Tue, 18 Sep 2007 10:40:31 +0430 From: "JinHyeock Choi" To: "Sri Gundavelli" Subject: Re: [netlmm] Comments on draft-05 In-Reply-To: <00f201c7f9b6$39560010$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> <00d701c7f99c$5b543c50$d5f6200a@amer.cisco.com> <92e919fb0709172221seee5394h9c99020111d87cf0@mail.gmail.com> <00f201c7f9b6$39560010$d5f6200a@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > The DHCP server keeps a binding between an address and a client id. > If there is a valid lease for a client, any subsequent request from > the client will still contain the same client id and the DHCP server > will attempt to issue the same address. > > Also, the request is comming from the MN and if its knows its earlier > address, it can request for the same. If it does not know its earlier > address, but if there exists a lease on the DHCP server for that > client, it will still end up with its earlier address, because the > client id is still the same. This is per 3315, standard behavior. I am afraid that DHCP server may change. >From the above, I see that the MN will get the same address if it sends a DHCP request to the SAME DHCP server. However, after moving to a different network, the MN would send a DHCP request to a different DHCP server, which won't have a binding for the MN. Allow me an example. Assume an MN is attached to MAG 1 and allocated an address from DHCP server 1. Then the MN moves to another network and attaches itself to MAG2. After related pmipv6 procedure, the MN sends a DHCP request to a different DHCP server 2. How can we be sure that DHCP server 2 will always allocate the MN's existing address? Also IMO, we don't need to ensure that DHCP server always allocates the same address. PMIPv6 would work just fine even when DHCP server would allocate the different addresses (with the same HNP). Best Regards JinHyeock _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 02:45:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXWp0-00086o-Fk; Tue, 18 Sep 2007 02:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXWoy-000869-Mb for netlmm@ietf.org; Tue, 18 Sep 2007 02:44:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXWox-0006WT-FT for netlmm@ietf.org; Tue, 18 Sep 2007 02:44:32 -0400 X-IronPort-AV: E=Sophos;i="4.20,267,1186383600"; d="scan'208";a="18466880" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 17 Sep 2007 23:44:28 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8I6iSDZ012490; Mon, 17 Sep 2007 23:44:28 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8I6iSfB010738; Tue, 18 Sep 2007 06:44:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 23:44:28 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Sep 2007 23:44:28 -0700 From: "Sri Gundavelli" To: "'JinHyeock Choi'" References: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> <00d701c7f99c$5b543c50$d5f6200a@amer.cisco.com> <92e919fb0709172221seee5394h9c99020111d87cf0@mail.gmail.com> <00f201c7f9b6$39560010$d5f6200a@amer.cisco.com> <92e919fb0709172310i668bfe0ficafe09cb732f5c08@mail.gmail.com> Subject: RE: [netlmm] Comments on draft-05 Date: Mon, 17 Sep 2007 23:44:25 -0700 Message-ID: <010701c7f9bf$5a6644f0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf5up794E2vmRAFQZaHQryMpBwx+gAAEUqw In-Reply-To: <92e919fb0709172310i668bfe0ficafe09cb732f5c08@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 18 Sep 2007 06:44:28.0147 (UTC) FILETIME=[5C085C30:01C7F9BF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2153; t=1190097868; x=1190961868; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Comments=20on=20draft-05 |Sender:=20; bh=A+duB7In7idvOMBvm2BYLibqzewq32kgn2mOEfzm/8g=; b=aYhY8ZOltfmn90/YMtbC5qp+t7d0vk8fx7cv2FDobQ8t4r1euNjGp0X2vHGUrvFKV7HpXRCG U6EhN3aegCxGd708XwWzUzWf4LBvJ3uZUVYIurzTfNFumqWl8I9Vmg35; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: JinHyeock Choi [mailto:jinchoe@gmail.com] > Sent: Monday, September 17, 2007 11:11 PM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: Re: [netlmm] Comments on draft-05 > > > The DHCP server keeps a binding between an address and a client id. > > If there is a valid lease for a client, any subsequent request from > > the client will still contain the same client id and the DHCP server > > will attempt to issue the same address. > > > > Also, the request is comming from the MN and if its knows > its earlier > > address, it can request for the same. If it does not know > its earlier > > address, but if there exists a lease on the DHCP server for that > > client, it will still end up with its earlier address, because the > > client id is still the same. This is per 3315, standard behavior. > > I am afraid that DHCP server may change. > It wont do the DHCP discover for lease extension. The request will be unicasted as the client has the state. > From the above, I see that the MN will get the same address > if it sends a DHCP request to the SAME DHCP server. > > However, after moving to a different network, > the MN would send a DHCP request to a different DHCP server, > which won't have a binding for the MN. > > Allow me an example. > > Assume an MN is attached to MAG 1 and > allocated an address from DHCP server 1. > Then the MN moves to another network and > attaches itself to MAG2. > After related pmipv6 procedure, > the MN sends a DHCP request to > a different DHCP server 2. > > How can we be sure that DHCP server 2 > will always allocate the MN's existing address? > > Also IMO, we don't need to ensure that DHCP server > always allocates the same address. PMIPv6 would work just fine even > when DHCP server would allocate the different addresses (with the same > HNP). > Ok. I'm fine stating that it will get an address from its HNP, that's the key point. This is a normal access link and we dont have to specify further details. Ok. Thanks for the comments. Sri > Best Regards > > JinHyeock _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 06:46:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXaaV-0007qI-Kl; Tue, 18 Sep 2007 06:45:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXaaU-0007q9-GB for netlmm@ietf.org; Tue, 18 Sep 2007 06:45:50 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXaaO-0003YW-AF for netlmm@ietf.org; Tue, 18 Sep 2007 06:45:50 -0400 Received: by ug-out-1314.google.com with SMTP id u2so209762uge for ; Tue, 18 Sep 2007 03:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=dVg6jGeP0FJT+O+dN2+8fYDdIQS3masEBtfwzZb+II8=; b=NNsw6zEZTLbUnEuEgnrqIHv8Xc8xnAS+JeQ/hy1PXkzNeG4s3mhsVVgJ6znh9kDVMNlp8eyloxQAl+QcmI7g+n0BPMfotGB88NKcrIlE1xOke0OX6/4ZIhF5A3oT3Rav9S2dGPt27USdJsrDAsPR1aAPeA7rZbFHEyPHFb730hA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=fLvHbLEI6/gdro0I2N0FrzQ50haTb1uEwc0OmRRMdAWCJHIDCbJci1alOJ2d0tNv/6Xt1dIokJ1h/Mgxo0eGB/7TcFKndr5kFfLzv0nsehEoph4I0/tSI6Itaz3TpzBC2yIjzHJoI5ixEr0M/wX2DCeJ0Vyp108MMFB9VdWROOE= Received: by 10.66.250.18 with SMTP id x18mr581117ugh.1190112333428; Tue, 18 Sep 2007 03:45:33 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id q1sm1233548uge.2007.09.18.03.45.31 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2007 03:45:31 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] Alternatives to RECOMMENDED timestamp Date: Tue, 18 Sep 2007 12:45:27 +0200 User-Agent: KMail/1.9.6 References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> In-Reply-To: <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709181245.28146.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Friday 14 September 2007, Sri Gundavelli wrote: > > - Is it mandatory for the implementations to implement Timestamp > based solution. [Y/N]. Just a YES or NO, will be more than > sufficient. YES. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 08:43:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcPE-0000vu-Qh; Tue, 18 Sep 2007 08:42:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXcPE-0000vR-5r for netlmm@ietf.org; Tue, 18 Sep 2007 08:42:20 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXcP7-00060Q-Qd for netlmm@ietf.org; Tue, 18 Sep 2007 08:42:20 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id l8ICfsx5009445; Tue, 18 Sep 2007 14:41:54 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8ICfoto014074; Tue, 18 Sep 2007 14:41:53 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Sep 2007 14:41:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Comments on draft-05 Date: Tue, 18 Sep 2007 14:41:02 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68029C4D7F@zagh223a.ww300.siemens.net> In-Reply-To: <010701c7f9bf$5a6644f0$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Comments on draft-05 Thread-Index: Acf5up794E2vmRAFQZaHQryMpBwx+gAAEUqwAA0TBwA= References: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com><00d701c7f99c$5b543c50$d5f6200a@amer.cisco.com><92e919fb0709172221seee5394h9c99020111d87cf0@mail.gmail.com><00f201c7f9b6$39560010$d5f6200a@amer.cisco.com><92e919fb0709172310i668bfe0ficafe09cb732f5c08@mail.gmail.com> <010701c7f9bf$5a6644f0$d5f6200a@amer.cisco.com> From: "Premec, Domagoj" To: "Sri Gundavelli" , "JinHyeock Choi" X-OriginalArrivalTime: 18 Sep 2007 12:41:43.0596 (UTC) FILETIME=[448E4EC0:01C7F9F1] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070918144154-0B323BB0-2660A027/0-0/0-15 X-purgate-size: 3564/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi JinHyeock, Sri, > > Also IMO, we don't need to ensure that DHCP server always allocates=20 > > the same address. PMIPv6 would work just fine even when DHCP server=20 > > would allocate the different addresses (with the same HNP). > >=20 >=20 > Ok. I'm fine stating that it will get an address from its=20 > HNP, that's the key point. This is a normal access link and=20 > we dont have to specify further details.=20 IMO, if this is about lease extension, then the network should always = return the same address and not a different one based on the same HNP. = Otherwise there will be no IP session continuity thus defeating the = purpose of the PMIP. During the inital attachment to a PMIP domain, the network if free to = return any address, based on any HNP.=20 domagoj > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: 18. rujan 2007 08:44 > To: 'JinHyeock Choi' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Comments on draft-05 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: JinHyeock Choi [mailto:jinchoe@gmail.com] > > Sent: Monday, September 17, 2007 11:11 PM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: Re: [netlmm] Comments on draft-05 > >=20 > > > The DHCP server keeps a binding between an address and a=20 > client id. > > > If there is a valid lease for a client, any subsequent=20 > request from=20 > > > the client will still contain the same client id and the=20 > DHCP server=20 > > > will attempt to issue the same address. > > > > > > Also, the request is comming from the MN and if its knows > > its earlier > > > address, it can request for the same. If it does not know > > its earlier > > > address, but if there exists a lease on the DHCP server for that=20 > > > client, it will still end up with its earlier address,=20 > because the=20 > > > client id is still the same. This is per 3315, standard behavior. > >=20 > > I am afraid that DHCP server may change. > >=20 >=20 > It wont do the DHCP discover for lease extension. The request=20 > will be unicasted as the client has the state. >=20 >=20 > > From the above, I see that the MN will get the same address if it=20 > > sends a DHCP request to the SAME DHCP server. > >=20 > > However, after moving to a different network, the MN would=20 > send a DHCP=20 > > request to a different DHCP server, which won't have a=20 > binding for the=20 > > MN. > >=20 > > Allow me an example. > >=20 > > Assume an MN is attached to MAG 1 and > > allocated an address from DHCP server 1. > > Then the MN moves to another network and attaches itself to MAG2. > > After related pmipv6 procedure, > > the MN sends a DHCP request to > > a different DHCP server 2. > >=20 > > How can we be sure that DHCP server 2 > > will always allocate the MN's existing address? > >=20 > > Also IMO, we don't need to ensure that DHCP server always allocates=20 > > the same address. PMIPv6 would work just fine even when DHCP server=20 > > would allocate the different addresses (with the same HNP). > >=20 >=20 > Ok. I'm fine stating that it will get an address from its=20 > HNP, that's the key point. This is a normal access link and=20 > we dont have to specify further details.=20 >=20 > Ok. Thanks for the comments. >=20 > Sri >=20 > > Best Regards > >=20 > > JinHyeock >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 10:10:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXdlr-0006Lw-L7; Tue, 18 Sep 2007 10:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXdlq-0006Lr-Qy for netlmm@ietf.org; Tue, 18 Sep 2007 10:09:46 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXdlk-0007kC-HN for netlmm@ietf.org; Tue, 18 Sep 2007 10:09:46 -0400 Received: by ug-out-1314.google.com with SMTP id u2so289951uge for ; Tue, 18 Sep 2007 07:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=lISUCqqQfYEEm7+pp9Nq7XQvQxXoHZltr9i2ESL8ccg=; b=GjbW4nWCND7KoHGKIwhTIDRwfRkkKpPGyA/2KqzaTpWwouweQ27RTRFwA1OcTkxngweOJky7idnve0GHhMDWTH8D2RMRcxp/GYqcyEwYg7vRu62xXMm6Zzwp8+2BDqklPFy0wyJjn9+e96rm10nEni2qMCour6DkKcFG0njImwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=koPA1LKqvnr5KE1vsqwxYF+y4FF38cZ0KWl3un+8v72epJzajx0UmTKP8toFkRSTX3sUEx+tWTwLFoy4APlRhq0whkNAhX7Va6NBh4mLZm177pwObMIFQae0X3+Z+Ld9YaaSn2Kjrr5Docyb98fJiuhhuuDFieQhyXGHddzXrfU= Received: by 10.66.244.11 with SMTP id r11mr791103ugh.1190124571252; Tue, 18 Sep 2007 07:09:31 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k1sm1540372ugf.2007.09.18.07.09.28 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2007 07:09:29 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org, "Premec, Domagoj" Subject: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments on draft-05) Date: Tue, 18 Sep 2007 16:09:25 +0200 User-Agent: KMail/1.9.6 References: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> <00f201c7f9b6$39560010$d5f6200a@amer.cisco.com> <92e919fb0709172310i668bfe0ficafe09cb732f5c08@mail.gmail.com> In-Reply-To: <92e919fb0709172310i668bfe0ficafe09cb732f5c08@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709181609.25806.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi JinHyeock, Sri and Domagoj, On Tuesday 18 September 2007, Premec, Domagoj wrote: > > IMO, if this is about lease extension, then the network should always > return the same address and not a different one based on the same > HNP. Otherwise there will be no IP session continuity thus defeating > the purpose of the PMIP. > > During the inital attachment to a PMIP > domain, the network if free to return any address, based on any HNP. I agree completely with that statement of Domagoj. Thus, for the reasons JinHyeock explained well in his note copied below, I think that we should ensure that for a given MN, the DHCPv6 server remains the same. That would ensure the same address will be allocated by the DHCPv6 server. Since only one DHCPv6 server must handle address allocation for a MN attaching to different MAGs and access links, the following requirement we can derive one requirement on DHCPv6 deployments arise: - DHCPv6 relays must be deployed on each access link of the PMIPv6 domain. Also, since the link between MAG and MN is point-to-point, that translates into a requirement for a DHCPv6 relay to be collocated with the MAG. Noting that a DHCPv6 relays "places a global or site-scoped address with a prefix assigned to the link on which the client should be assigned an address in the link-address field. This address will be used by the server to determine the link from which the client should be assigned an address and other configuration information" [RFC3315], the following limitation arises: - the MAG/Relay has to know a global address with a prefix assigned to the link on which the client should be assigned an address. That means the MAG/Relay has to know the HNP for the MN before it (to derive the "global address with a prefix assigned to the link on which the client should be assigned an address") forward the DHCPv6 message. Thus, DHCPv6 cannot be used to retrieve the HNP at first attachment. HNP must be obtained via other means such as PMIPv6 HNP option, or out-of-band (e.g. AAA). Thoughts? --julien On Tuesday 18 September 2007, JinHyeock Choi wrote: > > The DHCP server keeps a binding between an address and a client id. > > If there is a valid lease for a client, any subsequent request from > > the client will still contain the same client id and the DHCP > > server will attempt to issue the same address. > > > > Also, the request is comming from the MN and if its knows its > > earlier address, it can request for the same. If it does not know > > its earlier address, but if there exists a lease on the DHCP server > > for that client, it will still end up with its earlier address, > > because the client id is still the same. This is per 3315, standard > > behavior. > > I am afraid that DHCP server may change. > > From the above, I see that the MN will get the same address > if it sends a DHCP request to the SAME DHCP server. > > However, after moving to a different network, > the MN would send a DHCP request to a different DHCP server, > which won't have a binding for the MN. > > Allow me an example. > > Assume an MN is attached to MAG 1 and > allocated an address from DHCP server 1. > Then the MN moves to another network and > attaches itself to MAG2. > After related pmipv6 procedure, > the MN sends a DHCP request to > a different DHCP server 2. > > How can we be sure that DHCP server 2 > will always allocate the MN's existing address? > > Also IMO, we don't need to ensure that DHCP server > always allocates the same address. PMIPv6 would work just fine even > when DHCP server would allocate the different addresses (with the > same HNP). > > Best Regards > > JinHyeock _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 10:38:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXeDD-0007Ub-3n; Tue, 18 Sep 2007 10:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXeDB-0007UV-RT for netlmm@ietf.org; Tue, 18 Sep 2007 10:38:01 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXeD5-0008KU-Tw for netlmm@ietf.org; Tue, 18 Sep 2007 10:38:01 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id l8IEbXV0026564; Tue, 18 Sep 2007 16:37:34 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.97]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8IEbMej019779; Tue, 18 Sep 2007 16:37:31 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Sep 2007 16:37:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments on draft-05) Date: Tue, 18 Sep 2007 16:37:29 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68029C508A@zagh223a.ww300.siemens.net> In-Reply-To: <200709181609.25806.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments on draft-05) Thread-Index: Acf5/ZmdmV10a/yNSXqc1OvkAd2hOgAARFuA References: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> <00f201c7f9b6$39560010$d5f6200a@amer.cisco.com> <92e919fb0709172310i668bfe0ficafe09cb732f5c08@mail.gmail.com> <200709181609.25806.julien.IETF@laposte.net> From: "Premec, Domagoj" To: "Julien Laganier" , X-OriginalArrivalTime: 18 Sep 2007 14:37:31.0227 (UTC) FILETIME=[71AAAAB0:01C7FA01] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070918163733-54E8FBB0-71EA32F9/0-0/0-15 X-purgate-size: 5955/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien, > Noting that a DHCPv6 relays "places a global or site-scoped=20 > address with a prefix assigned to the link on which the=20 > client should be assigned an address in the link-address=20 > field. This address will be used by the server to determine=20 > the link from which the client should be assigned an address=20 > and other configuration information" [RFC3315], the following=20 > limitation arises: >=20 > - the MAG/Relay has to know a global address with a prefix assigned > to the link on which the client should be assigned an=20 > address. That > means the MAG/Relay has to know the HNP for the MN before it > (to derive the "global address with a prefix assigned to the link > on which the client should be assigned an address") forward the > DHCPv6 message. >=20 > Thus, DHCPv6 cannot be used to retrieve the HNP at first=20 > attachment. HNP must be obtained via other means such as=20 > PMIPv6 HNP option, or out-of-band (e.g. AAA). In PMIP6, the choice for the allocation of a HNP is not related to a = location (link) where the MS attached to the network. From that = perspective, the link-address field does not seem to be useful for DHCP = server. Maybe we could relax the requirement on DHCPv6 relays and allow = them to relay a request without link-address field. DHCP server is free = to allocate any HNP in response to such request. Would that work? domagoj > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On=20 > Behalf Of Julien Laganier > Sent: 18. rujan 2007 16:09 > To: netlmm@ietf.org; Premec, Domagoj > Cc: JinHyeock Choi; Sri Gundavelli > Subject: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]=20 > Comments on draft-05) >=20 > Hi JinHyeock, Sri and Domagoj, >=20 > On Tuesday 18 September 2007, Premec, Domagoj wrote: > > > > IMO, if this is about lease extension, then the network=20 > should always=20 > > return the same address and not a different one based on=20 > the same HNP.=20 > > Otherwise there will be no IP session continuity thus defeating the=20 > > purpose of the PMIP. > > > > During the inital attachment to a PMIP domain, the network=20 > if free to=20 > > return any address, based on any HNP. >=20 > I agree completely with that statement of Domagoj. Thus, for=20 > the reasons JinHyeock explained well in his note copied=20 > below, I think that we should ensure that for a given MN, the=20 > DHCPv6 server remains the same.=20 > That would ensure the same address will be allocated by the=20 > DHCPv6 server. >=20 > Since only one DHCPv6 server must handle address allocation=20 > for a MN attaching to different MAGs and access links, the=20 > following requirement we can derive one requirement on DHCPv6=20 > deployments arise: >=20 > - DHCPv6 relays must be deployed on each access link of the PMIPv6 > domain. Also, since the link between MAG and MN is=20 > point-to-point, > that translates into a requirement for a DHCPv6 relay to be > collocated with the MAG. >=20 > Noting that a DHCPv6 relays "places a global or site-scoped=20 > address with a prefix assigned to the link on which the=20 > client should be assigned an address in the link-address=20 > field. This address will be used by the server to determine=20 > the link from which the client should be assigned an address=20 > and other configuration information" [RFC3315], the following=20 > limitation arises: >=20 > - the MAG/Relay has to know a global address with a prefix assigned > to the link on which the client should be assigned an=20 > address. That > means the MAG/Relay has to know the HNP for the MN before it > (to derive the "global address with a prefix assigned to the link > on which the client should be assigned an address") forward the > DHCPv6 message. >=20 > Thus, DHCPv6 cannot be used to retrieve the HNP at first=20 > attachment. HNP must be obtained via other means such as=20 > PMIPv6 HNP option, or out-of-band (e.g. AAA). >=20 > Thoughts? >=20 > --julien >=20 > On Tuesday 18 September 2007, JinHyeock Choi wrote: > > > The DHCP server keeps a binding between an address and a=20 > client id. > > > If there is a valid lease for a client, any subsequent=20 > request from=20 > > > the client will still contain the same client id and the=20 > DHCP server=20 > > > will attempt to issue the same address. > > > > > > Also, the request is comming from the MN and if its knows its=20 > > > earlier address, it can request for the same. If it does not know=20 > > > its earlier address, but if there exists a lease on the=20 > DHCP server=20 > > > for that client, it will still end up with its earlier address,=20 > > > because the client id is still the same. This is per=20 > 3315, standard=20 > > > behavior. > > > > I am afraid that DHCP server may change. > > > > From the above, I see that the MN will get the same address if it=20 > > sends a DHCP request to the SAME DHCP server. > > > > However, after moving to a different network, the MN would=20 > send a DHCP=20 > > request to a different DHCP server, which won't have a=20 > binding for the=20 > > MN. > > > > Allow me an example. > > > > Assume an MN is attached to MAG 1 and > > allocated an address from DHCP server 1. > > Then the MN moves to another network and attaches itself to MAG2. > > After related pmipv6 procedure, > > the MN sends a DHCP request to > > a different DHCP server 2. > > > > How can we be sure that DHCP server 2 > > will always allocate the MN's existing address? > > > > Also IMO, we don't need to ensure that DHCP server always allocates=20 > > the same address. PMIPv6 would work just fine even when DHCP server=20 > > would allocate the different addresses (with the same HNP). > > > > Best Regards > > > > JinHyeock >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 11:09:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXeh1-0003pS-VH; Tue, 18 Sep 2007 11:08:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXeh1-0003ot-0U for netlmm@ietf.org; Tue, 18 Sep 2007 11:08:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXegs-0000ms-IX for netlmm@ietf.org; Tue, 18 Sep 2007 11:08:50 -0400 Received: by ug-out-1314.google.com with SMTP id u2so330357uge for ; Tue, 18 Sep 2007 08:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=3Lck/s8S1Qq4KqtW8xKxlA53EXtI5Ft1lMcXBABjYZA=; b=LIDhgPBiZTrHrPLE9oRgizxLMb996POEpc2Fm8GKGE9r6jN0zJA+n0WVnmMIPQbXwBiCU420qZZPQcIGptgkm6uIJo/unqiTwtQG56oKlQvVBuwLbgPRZbePMTNJ0l/4zhRQ4tqemCh9XRrYUTJFs1gIsZ4syyr2qD4pc9baQcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=hnXfWuvLi2eQdnQoGFQIcRyX9QBK3NX5s/JKM/k3IFpHa7IhXYXg2CakHmRm2UdLYF25Dwc3kwDC08eZI5/tUVShvzN3WhwD4Ir1bj9+hv7jo9MD6XOkzLZBsgfv2Uq+Fb8ZScfFZTLa20KHr24wyGsIypGdvfmuGnUHiQ1oDL8= Received: by 10.66.220.17 with SMTP id s17mr855362ugg.1190128107537; Tue, 18 Sep 2007 08:08:27 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e1sm1646141ugf.2007.09.18.08.08.25 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2007 08:08:25 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments on draft-05) Date: Tue, 18 Sep 2007 17:08:21 +0200 User-Agent: KMail/1.9.6 References: <92e919fb0709170917r12629353qbf9d020169291105@mail.gmail.com> <200709181609.25806.julien.IETF@laposte.net> <3C31CDD06342EA4A8137716247B1CD68029C508A@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68029C508A@zagh223a.ww300.siemens.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709181708.21914.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Domagoj, On Tuesday 18 September 2007, Premec, Domagoj wrote: > > On Tuesday 18 September 2007, Julien Laganier wrote: > > > Noting that a DHCPv6 relays "places a global or site-scoped > > address with a prefix assigned to the link on which the > > client should be assigned an address in the link-address > > field. This address will be used by the server to determine > > the link from which the client should be assigned an address > > and other configuration information" [RFC3315], the following > > limitation arises: > > > > - the MAG/Relay has to know a global address with a prefix > > assigned to the link on which the client should be assigned an > > address. That means the MAG/Relay has to know the HNP for the > > MN before it (to derive the "global address with a prefix > > assigned to the link on which the client should be assigned an > > address") forward the DHCPv6 message. > > > > Thus, DHCPv6 cannot be used to retrieve the HNP at first > > attachment. HNP must be obtained via other means such as > > PMIPv6 HNP option, or out-of-band (e.g. AAA). > > In PMIP6, the choice for the allocation of a HNP is not related to a > location (link) where the MS attached to the network. I can agree that the allocation of a HNP is not related to the *location* where the MS is attached to the network. ALthough a PMIPv6 domain contains many different access links, from the MN point of view the PMIPv6 service model is that of a single emulated home link which follows the MN, and on which a home network prefix is advertized. I thus disagree that the allocation of HNP is not related to which home link the MS is attached to. There's a one-to-one correspondence between a home link and a HNP. More below... > From that perspective, the link-address field does not seem to be > useful for DHCP server. I disagree with this statement. The link-address field is the only piece of information that can be used by the DHCPv6 server to determine the home link from which the client should be assigned an address and other configuration information. What other piece of information could be used otherwise? > Maybe we could relax the requirement on DHCPv6 relays and allow them > to relay a request without link-address field. That would be a change to the DHCP specification and should be avoided IMHO. > DHCP server is free to allocate any HNP in response to such request. Exactly what I would not like to happen: In case where the HNP is chosen by LMA or via an out-of-band protocol (e.g. AAA) or by LMA, the DHCP server should allocate addresses in that same HNP. Thus, in the absence of the link-address field, the above would require the DHCP server to be interfaced with either the LMA or AAA infrastructure. Thoughts? --julien > > -----Original Message----- > > From: julien laganier [mailto:julien.laganier@gmail.com] On > > Behalf Of Julien Laganier > > Sent: 18. rujan 2007 16:09 > > To: netlmm@ietf.org; Premec, Domagoj > > Cc: JinHyeock Choi; Sri Gundavelli > > Subject: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] > > Comments on draft-05) > > > > Hi JinHyeock, Sri and Domagoj, > > > > On Tuesday 18 September 2007, Premec, Domagoj wrote: > > > IMO, if this is about lease extension, then the network > > > > should always > > > > > return the same address and not a different one based on > > > > the same HNP. > > > > > Otherwise there will be no IP session continuity thus defeating > > > the purpose of the PMIP. > > > > > > During the inital attachment to a PMIP domain, the network > > > > if free to > > > > > return any address, based on any HNP. > > > > I agree completely with that statement of Domagoj. Thus, for > > the reasons JinHyeock explained well in his note copied > > below, I think that we should ensure that for a given MN, the > > DHCPv6 server remains the same. > > That would ensure the same address will be allocated by the > > DHCPv6 server. > > > > Since only one DHCPv6 server must handle address allocation > > for a MN attaching to different MAGs and access links, the > > following requirement we can derive one requirement on DHCPv6 > > deployments arise: > > > > - DHCPv6 relays must be deployed on each access link of the > > PMIPv6 domain. Also, since the link between MAG and MN is > > point-to-point, > > that translates into a requirement for a DHCPv6 relay to be > > collocated with the MAG. > > > > Noting that a DHCPv6 relays "places a global or site-scoped > > address with a prefix assigned to the link on which the > > client should be assigned an address in the link-address > > field. This address will be used by the server to determine > > the link from which the client should be assigned an address > > and other configuration information" [RFC3315], the following > > limitation arises: > > > > - the MAG/Relay has to know a global address with a prefix > > assigned to the link on which the client should be assigned an > > address. That > > means the MAG/Relay has to know the HNP for the MN before it > > (to derive the "global address with a prefix assigned to the > > link on which the client should be assigned an address") forward > > the DHCPv6 message. > > > > Thus, DHCPv6 cannot be used to retrieve the HNP at first > > attachment. HNP must be obtained via other means such as > > PMIPv6 HNP option, or out-of-band (e.g. AAA). > > > > Thoughts? > > > > --julien > > > > On Tuesday 18 September 2007, JinHyeock Choi wrote: > > > > The DHCP server keeps a binding between an address and a > > > > client id. > > > > > > If there is a valid lease for a client, any subsequent > > > > request from > > > > > > the client will still contain the same client id and the > > > > DHCP server > > > > > > will attempt to issue the same address. > > > > > > > > Also, the request is comming from the MN and if its knows its > > > > earlier address, it can request for the same. If it does not > > > > know its earlier address, but if there exists a lease on the > > > > DHCP server > > > > > > for that client, it will still end up with its earlier address, > > > > because the client id is still the same. This is per > > > > 3315, standard > > > > > > behavior. > > > > > > I am afraid that DHCP server may change. > > > > > > From the above, I see that the MN will get the same address if it > > > sends a DHCP request to the SAME DHCP server. > > > > > > However, after moving to a different network, the MN would > > > > send a DHCP > > > > > request to a different DHCP server, which won't have a > > > > binding for the > > > > > MN. > > > > > > Allow me an example. > > > > > > Assume an MN is attached to MAG 1 and > > > allocated an address from DHCP server 1. > > > Then the MN moves to another network and attaches itself to MAG2. > > > After related pmipv6 procedure, > > > the MN sends a DHCP request to > > > a different DHCP server 2. > > > > > > How can we be sure that DHCP server 2 > > > will always allocate the MN's existing address? > > > > > > Also IMO, we don't need to ensure that DHCP server always > > > allocates the same address. PMIPv6 would work just fine even when > > > DHCP server would allocate the different addresses (with the same > > > HNP). > > > > > > Best Regards > > > > > > JinHyeock > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 20:43:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXnec-0004Fi-Ta; Tue, 18 Sep 2007 20:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXneb-0004FW-O9 for netlmm@ietf.org; Tue, 18 Sep 2007 20:42:57 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXneT-00010a-Eh for netlmm@ietf.org; Tue, 18 Sep 2007 20:42:57 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 17:42:46 -0700 Message-ID: <46F07084.7040209@azairenet.com> Date: Tue, 18 Sep 2007 17:42:44 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> <011501c7f5a1$7e873b40$d5f6200a@amer.cisco.com> In-Reply-To: <011501c7f5a1$7e873b40$d5f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 00:42:46.0541 (UTC) FILETIME=[FF47D3D0:01C7FA55] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri Gundavelli wrote: >> This sounds like the MAG looks only at MN's profile and >> policy to determine the mobility mode of the MN. Looking at >> the MN's profile only is too restrictive, the user can change >> his terminal or update it with a MIP implementation and might >> prefere to use client based MIP. So I think the language hier >> should keep the door open for deciding about the MN's >> mobility mode in a more dynamic manner. The MAG could learn >> about the MN's capabilities and preferences through >> link-layer or some future enhancements at the IP layer. Would >> it be possible to add following sentence at the end of the >> cited paragraph: >> "The MAG's decision can be influenced by the mobile node's >> MIP capabilities and preferences. The MAG may learn about the >> MN's capabilites and preferences through link-layer exchange >> or by some other means out of the scope of this specificaton." >> > Fine. I don't like this new text. We seemed to have added an explicit reference to an exchange of mobile node capabilities and preferences. We also seemed to have added some text that says if the mobile node implements Mobile IPv6, PMIPv6 can be turned off. For the base PMIPv6 document, it is assumed that we are providing network-based mobility for a mobile node without the mobile node being aware of PMIPv6 being used in the network. We should move all this text to the PMIPv6 - MIPv6 interactions document. Scenario B and C in that document try to capture this. Sri, can we please go back to the earlier text? The earlier text only said that the MAG should check if the mobile node is authorized for PMIPv6 before sending a proxy BU. Upon obtaining the mobile node's profile after a successful access authentication and after a policy consideration, the mobile access gateway MUST determine if the network based mobility service should be offered to that mobile node. If the mobile node is entitled for such service, then the mobile access gateway must ensure the mobile node believes it is on its home link, as explained in various sections of this specification. This check is needed anyway if the MAG sends a proxy BU on behalf of the mobile node. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 21:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXofj-0003IY-Gg; Tue, 18 Sep 2007 21:48:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXofi-0003Gr-9r for netlmm@ietf.org; Tue, 18 Sep 2007 21:48:10 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXofh-0007W0-TL for netlmm@ietf.org; Tue, 18 Sep 2007 21:48:10 -0400 X-IronPort-AV: E=Sophos;i="4.20,271,1186383600"; d="scan'208";a="220670889" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2007 18:48:09 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8J1m9tc028861; Tue, 18 Sep 2007 18:48:09 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8J1m9fB016589; Wed, 19 Sep 2007 01:48:09 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 18:48:08 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 18:48:08 -0700 From: "Sri Gundavelli" To: "'Vijay Devarapalli'" References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> <011501c7f5a1$7e873b40$d5f6200a@amer.cisco.com> <46F07084.7040209@azairenet.com> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Tue, 18 Sep 2007 18:48:08 -0700 Message-ID: <01cf01c7fa5f$2112b620$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf6VgHwUdLLtXAIQJSvVjhvkalFoAAB1gPw In-Reply-To: <46F07084.7040209@azairenet.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 19 Sep 2007 01:48:08.0569 (UTC) FILETIME=[20FDCE90:01C7FA5F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1443; t=1190166489; x=1191030489; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-proxymip6 -04.txt |Sender:=20; bh=8fnRc5U+7S0KxRFdzdA9i7g3XEtZPzFGVgldAGvG7K4=; b=JhtC0fHJKc73yRMhMc6eJbW653RK315oCkBnGn4jxlH0miKwo1uMujzCuCJSJ64nnuMofAg5 W+Ymy4EjWyWZhzeO3k7QXDfdQjeN2BKMXGhpkV22+LEosgIRPyxgKcMuJ7IHwd0KJ70KYNWt4/ ZKB86YAcJ4PuUV+WPVnMAgCg8=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay, > > >> "The MAG's decision can be influenced by the mobile node's > >> MIP capabilities and preferences. The MAG may learn about the > >> MN's capabilites and preferences through link-layer exchange > >> or by some other means out of the scope of this specificaton." > >> > > Fine. > > I don't like this new text. We seemed to have added an explicit > reference to an exchange of mobile node capabilities and > preferences. We > also seemed to have added some text that says if the mobile node > implements Mobile IPv6, PMIPv6 can be turned off. For the base PMIPv6 > document, it is assumed that we are providing network-based > mobility for > a mobile node without the mobile node being aware of PMIPv6 > being used > in the network. > We are not mandating any approach. Its just stating few possibilities, that can be the basis for the MAG's decision. Capability exchange in the ND messages is probably the most reasonable approach. The HA service flags or the "R" flag in the Home Agent info Option ..all fall in line with this approach. We are only listing possibilities and there is no way the draft is recommending that approach. I do know Domagoj and others have drafts on this approach, but this is not endorsing that approach, as there are other approaches as well. We can take this text out if any one else also thinks, this text goes into a solution space. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 22:21:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXpBr-0001aS-Lo; Tue, 18 Sep 2007 22:21:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXpBp-0001XI-RC for netlmm@ietf.org; Tue, 18 Sep 2007 22:21:21 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXpBo-0008FP-VK for netlmm@ietf.org; Tue, 18 Sep 2007 22:21:21 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL00CRQFUFS3@szxga03-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 10:20:39 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL009T1FUEIO@szxga03-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 10:20:39 +0800 (CST) Received: from z49950 ([10.121.32.154]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOL004EEFUB0J@szxml03-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 10:20:38 +0800 (CST) Date: Wed, 19 Sep 2007 10:20:26 +0800 From: "John.zhao" Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt In-reply-to: <01cf01c7fa5f$2112b620$d5f6200a@amer.cisco.com> To: 'Sri Gundavelli' , 'Vijay Devarapalli' Message-id: <004801c7fa63$a4142b40$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf6VgHwUdLLtXAIQJSvVjhvkalFoAAB1gPwAAFpQ5A= X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi,Sri and Vijay See my comments inline. Best Rgds, Thanks, John.zhao > > Vijay, > > > > >> "The MAG's decision can be influenced by the mobile node's > > >> MIP capabilities and preferences. The MAG may learn about the > > >> MN's capabilites and preferences through link-layer exchange > > >> or by some other means out of the scope of this specificaton." > > >> > > > Fine. > > > > I don't like this new text. We seemed to have added an explicit > > reference to an exchange of mobile node capabilities and > > preferences. We > > also seemed to have added some text that says if the mobile node > > implements Mobile IPv6, PMIPv6 can be turned off. For the base PMIPv6 > > document, it is assumed that we are providing network-based > > mobility for > > a mobile node without the mobile node being aware of PMIPv6 > > being used > > in the network. > > > > We are not mandating any approach. Its just stating few possibilities, > that can be the basis for the MAG's decision. Capability exchange in > the ND messages is probably the most reasonable approach. The HA > service flags or the "R" flag in the Home Agent info Option ..all fall > in line with this approach. We are only listing possibilities and there > is no way the draft is recommending that approach. I do know Domagoj > and others have drafts on this approach, but this is not endorsing that > approach, as there are other approaches as well. We can take this text > out if any one else also thinks, this text goes into a solution space. > > Sri > > [John.zhao] I support the new text. I also think this didn't mandating and introducing any approach. Only leaving the detail or specify approach for implementation or out of current scope, for example the DHCP or RD protocol. And as a basis document, it should can compatible with those important features. So in my opinion, the new version is better. My two cents. > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 22:21:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXpCN-0001on-Bz; Tue, 18 Sep 2007 22:21:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXpCM-0001of-Tb for netlmm@ietf.org; Tue, 18 Sep 2007 22:21:54 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXpCL-000393-Mz for netlmm@ietf.org; Tue, 18 Sep 2007 22:21:54 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 19:21:52 -0700 Message-ID: <46F087BF.1000809@azairenet.com> Date: Tue, 18 Sep 2007 19:21:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> <011501c7f5a1$7e873b40$d5f6200a@amer.cisco.com> <46F07084.7040209@azairenet.com> <01cf01c7fa5f$2112b620$d5f6200a@amer.cisco.com> In-Reply-To: <01cf01c7fa5f$2112b620$d5f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 02:21:52.0139 (UTC) FILETIME=[D72215B0:01C7FA63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org That is not the point Sri. The text that has been added has a lot of implications. A capability exchange becomes relevant only when you talk about co-existence of PMIPv6 and MIPv6. The problem is that we had some text earlier that said, the MAG may want to check if the MN is authorized for PMIPv6 service before sending a proxy BU. That text has been completely re-written to say that the MAG should provide PMIPv6 service only after figuring out MN capabilities. That is completely unacceptable. Sri Gundavelli wrote: > > We are not mandating any approach. Its just stating few possibilities, > that can be the basis for the MAG's decision. Capability exchange in > the ND messages is probably the most reasonable approach. That is irrelevant. > The HA > service flags or the "R" flag in the Home Agent info Option ..all fall > in line with this approach. We haven't even discussed that document. Vijay > We are only listing possibilities and there > is no way the draft is recommending that approach. I do know Domagoj > and others have drafts on this approach, but this is not endorsing that > approach, as there are other approaches as well. We can take this text > out if any one else also thinks, this text goes into a solution space. > > Sri > > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 22:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXplC-0005RC-8S; Tue, 18 Sep 2007 22:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXplB-0005R6-DC for netlmm@ietf.org; Tue, 18 Sep 2007 22:57:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXplA-0003ps-6r for netlmm@ietf.org; Tue, 18 Sep 2007 22:57:53 -0400 X-IronPort-AV: E=Sophos;i="4.20,271,1186383600"; d="scan'208";a="220700380" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2007 19:57:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8J2viHX027809; Tue, 18 Sep 2007 19:57:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8J2viDr027358; Wed, 19 Sep 2007 02:57:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 19:57:44 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 19:57:43 -0700 From: "Sri Gundavelli" To: , "'Vijay Devarapalli'" References: <01cf01c7fa5f$2112b620$d5f6200a@amer.cisco.com> <004801c7fa63$a4142b40$a864a8c0@china.huawei.com> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Tue, 18 Sep 2007 19:57:43 -0700 Message-ID: <01d001c7fa68$d9cecce0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf6VgHwUdLLtXAIQJSvVjhvkalFoAAB1gPwAAFpQ5AAATGiQA== In-Reply-To: <004801c7fa63$a4142b40$a864a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 19 Sep 2007 02:57:43.0957 (UTC) FILETIME=[D9B77450:01C7FA68] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=795; t=1190170664; x=1191034664; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-proxymip6 -04.txt |Sender:=20; bh=4dUt5ioaJxLrwjpCee7Xo2TdSa7lV55ohqT6Kz+W9zQ=; b=jIpeddAFA0EMfGDuN1q8EoV8fu6h03QyGgqKygnmhylOyndEUKZM1lCY8svd5I5FMk67dtuo 0SHbASp+vNaP2ELiDlFO6hBeZwGFThynHhoxM5cKNAhCZPD7Y4NdfFu4; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org John, > > > > > > [John.zhao] I support the new text. I also think this didn't > mandating and > introducing any approach. Only leaving the detail or specify > approach for > implementation or out of current scope, for example the DHCP > or RD protocol. > And as a basis document, it should can compatible with those important > features. So in my opinion, the new version is better. > It does not really matter, having that reference does not really enable or disable that approach. So, no worries, it wont hurt any of the drafts on this topic. We will review this carefully to make sure, it does not change the basic assumptions on the access link. If there are no implications, we will keep it, else we will have some very simple text, as before. Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 23:04:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXpql-0001Et-3N; Tue, 18 Sep 2007 23:03:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXpqk-0001Eo-Ax for netlmm@ietf.org; Tue, 18 Sep 2007 23:03:38 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXpqj-0000pV-G8 for netlmm@ietf.org; Tue, 18 Sep 2007 23:03:38 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL003B4HSU3D@szxga02-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 11:02:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL00L6BHSURU@szxga02-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 11:02:54 +0800 (CST) Received: from z49950 ([10.121.32.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOL00HAAHSQID@szxml04-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 11:02:54 +0800 (CST) Date: Wed, 19 Sep 2007 11:02:41 +0800 From: "John.zhao" Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt In-reply-to: <01d001c7fa68$d9cecce0$d5f6200a@amer.cisco.com> To: 'Sri Gundavelli' , 'Vijay Devarapalli' Message-id: <006b01c7fa69$8b849320$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf6VgHwUdLLtXAIQJSvVjhvkalFoAAB1gPwAAFpQ5AAATGiQAAAbOtA X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi, Sri > > John, [John.zhao] > > [John.zhao] I support the new text. I also think this didn't > > mandating and > > introducing any approach. Only leaving the detail or specify > > approach for > > implementation or out of current scope, for example the DHCP > > or RD protocol. > > And as a basis document, it should can compatible with those important > > features. So in my opinion, the new version is better. > > > > It does not really matter, having that reference does not really > enable or disable that approach. So, no worries, it wont hurt > any of the drafts on this topic. We will review this carefully > to make sure, it does not change the basic assumptions on the > access link. If there are no implications, we will keep it, else > we will have some very simple text, as before. > [John.zhao] OK. I'm fine. > Thanks > Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 23:25:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqBF-0006VZ-28; Tue, 18 Sep 2007 23:24:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqBD-0006UC-B2 for netlmm@ietf.org; Tue, 18 Sep 2007 23:24:47 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXqB6-0004Lx-4e for netlmm@ietf.org; Tue, 18 Sep 2007 23:24:47 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL0044MIRHX8@szxga01-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 11:23:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL00MN2IR7XI@szxga01-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 11:23:41 +0800 (CST) Received: from z49950 ([10.121.32.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOL00HWYIR3ID@szxml04-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 11:23:31 +0800 (CST) Date: Wed, 19 Sep 2007 11:23:18 +0800 From: "John.zhao" Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments ondraft-05) In-reply-to: <200709181708.21914.julien.IETF@laposte.net> To: 'Julien Laganier' , "'Premec, Domagoj'" Message-id: <006f01c7fa6c$6cb8f0a0$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf6BksYq5eWLwBVQMed//af5MqdrQAZYZqg X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > > Hi Domagoj, > > On Tuesday 18 September 2007, Premec, Domagoj wrote: > > > > On Tuesday 18 September 2007, Julien Laganier wrote: > > > > > Noting that a DHCPv6 relays "places a global or site-scoped > > > address with a prefix assigned to the link on which the > > > client should be assigned an address in the link-address > > > field. This address will be used by the server to determine > > > the link from which the client should be assigned an address > > > and other configuration information" [RFC3315], the following > > > limitation arises: > > > > > > - the MAG/Relay has to know a global address with a prefix > > > assigned to the link on which the client should be assigned an > > > address. That means the MAG/Relay has to know the HNP for the > > > MN before it (to derive the "global address with a prefix > > > assigned to the link on which the client should be assigned an > > > address") forward the DHCPv6 message. > > > > > > Thus, DHCPv6 cannot be used to retrieve the HNP at first > > > attachment. HNP must be obtained via other means such as > > > PMIPv6 HNP option, or out-of-band (e.g. AAA). > > > > In PMIP6, the choice for the allocation of a HNP is not related to a > > location (link) where the MS attached to the network. > > I can agree that the allocation of a HNP is not related to the > *location* where the MS is attached to the network. > > ALthough a PMIPv6 domain contains many different access links, from the > MN point of view the PMIPv6 service model is that of a single emulated > home link which follows the MN, and on which a home network prefix is > advertized. > > I thus disagree that the allocation of HNP is not related to which home > link the MS is attached to. There's a one-to-one correspondence between > a home link and a HNP. More below... > > > From that perspective, the link-address field does not seem to be > > useful for DHCP server. > > I disagree with this statement. The link-address field is the only piece > of information that can be used by the DHCPv6 server to determine the > home link from which the client should be assigned an address and other > configuration information. What other piece of information could be > used otherwise? > [John.zhao] I'm not sure if I missed something. If I'm wrong, please indicate kindly. If does the Client Identifier Option can also be used to achieved this goal? > > Maybe we could relax the requirement on DHCPv6 relays and allow them > > to relay a request without link-address field. > > That would be a change to the DHCP specification and should be avoided > IMHO. > > > DHCP server is free to allocate any HNP in response to such request. > > Exactly what I would not like to happen: In case where the HNP is chosen > by LMA or via an out-of-band protocol (e.g. AAA) or by LMA, the DHCP > server should allocate addresses in that same HNP. > > Thus, in the absence of the link-address field, the above would require > the DHCP server to be interfaced with either the LMA or AAA > infrastructure. > > Thoughts? > > --julien > > > > -----Original Message----- > > > From: julien laganier [mailto:julien.laganier@gmail.com] On > > > Behalf Of Julien Laganier > > > Sent: 18. rujan 2007 16:09 > > > To: netlmm@ietf.org; Premec, Domagoj > > > Cc: JinHyeock Choi; Sri Gundavelli > > > Subject: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] > > > Comments on draft-05) > > > > > > Hi JinHyeock, Sri and Domagoj, > > > > > > On Tuesday 18 September 2007, Premec, Domagoj wrote: > > > > IMO, if this is about lease extension, then the network > > > > > > should always > > > > > > > return the same address and not a different one based on > > > > > > the same HNP. > > > > > > > Otherwise there will be no IP session continuity thus defeating > > > > the purpose of the PMIP. > > > > > > > > During the inital attachment to a PMIP domain, the network > > > > > > if free to > > > > > > > return any address, based on any HNP. > > > > > > I agree completely with that statement of Domagoj. Thus, for > > > the reasons JinHyeock explained well in his note copied > > > below, I think that we should ensure that for a given MN, the > > > DHCPv6 server remains the same. > > > That would ensure the same address will be allocated by the > > > DHCPv6 server. > > > > > > Since only one DHCPv6 server must handle address allocation > > > for a MN attaching to different MAGs and access links, the > > > following requirement we can derive one requirement on DHCPv6 > > > deployments arise: > > > > > > - DHCPv6 relays must be deployed on each access link of the > > > PMIPv6 domain. Also, since the link between MAG and MN is > > > point-to-point, > > > that translates into a requirement for a DHCPv6 relay to be > > > collocated with the MAG. > > > > > > Noting that a DHCPv6 relays "places a global or site-scoped > > > address with a prefix assigned to the link on which the > > > client should be assigned an address in the link-address > > > field. This address will be used by the server to determine > > > the link from which the client should be assigned an address > > > and other configuration information" [RFC3315], the following > > > limitation arises: > > > > > > - the MAG/Relay has to know a global address with a prefix > > > assigned to the link on which the client should be assigned an > > > address. That > > > means the MAG/Relay has to know the HNP for the MN before it > > > (to derive the "global address with a prefix assigned to the > > > link on which the client should be assigned an address") forward > > > the DHCPv6 message. > > > > > > Thus, DHCPv6 cannot be used to retrieve the HNP at first > > > attachment. HNP must be obtained via other means such as > > > PMIPv6 HNP option, or out-of-band (e.g. AAA). > > > > > > Thoughts? > > > > > > --julien > > > > > > On Tuesday 18 September 2007, JinHyeock Choi wrote: > > > > > The DHCP server keeps a binding between an address and a > > > > > > client id. > > > > > > > > If there is a valid lease for a client, any subsequent > > > > > > request from > > > > > > > > the client will still contain the same client id and the > > > > > > DHCP server > > > > > > > > will attempt to issue the same address. > > > > > > > > > > Also, the request is comming from the MN and if its knows its > > > > > earlier address, it can request for the same. If it does not > > > > > know its earlier address, but if there exists a lease on the > > > > > > DHCP server > > > > > > > > for that client, it will still end up with its earlier address, > > > > > because the client id is still the same. This is per > > > > > > 3315, standard > > > > > > > > behavior. > > > > > > > > I am afraid that DHCP server may change. > > > > > > > > From the above, I see that the MN will get the same address if it > > > > sends a DHCP request to the SAME DHCP server. > > > > > > > > However, after moving to a different network, the MN would > > > > > > send a DHCP > > > > > > > request to a different DHCP server, which won't have a > > > > > > binding for the > > > > > > > MN. > > > > > > > > Allow me an example. > > > > > > > > Assume an MN is attached to MAG 1 and > > > > allocated an address from DHCP server 1. > > > > Then the MN moves to another network and attaches itself to MAG2. > > > > After related pmipv6 procedure, > > > > the MN sends a DHCP request to > > > > a different DHCP server 2. > > > > > > > > How can we be sure that DHCP server 2 > > > > will always allocate the MN's existing address? > > > > > > > > Also IMO, we don't need to ensure that DHCP server always > > > > allocates the same address. PMIPv6 would work just fine even when > > > > DHCP server would allocate the different addresses (with the same > > > > HNP). > > > > > > > > Best Regards > > > > > > > > JinHyeock > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 23:46:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqVf-0008NV-S1; Tue, 18 Sep 2007 23:45:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqVe-0008Lo-4g for netlmm@ietf.org; Tue, 18 Sep 2007 23:45:54 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXqVd-0001fV-G9 for netlmm@ietf.org; Tue, 18 Sep 2007 23:45:54 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8J3jW0A002505; Wed, 19 Sep 2007 06:45:44 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 06:45:35 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 22:45:33 -0500 Received: from 10.241.58.246 ([10.241.58.246]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Sep 2007 03:45:33 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 18 Sep 2007 22:46:11 -0500 Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt From: Basavaraj Patil To: Vijay Devarapalli , Sri Gundavelli Message-ID: Thread-Topic: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Thread-Index: Acf6b55z3ReCd2ZiEdyuUQARJNUNiA== In-Reply-To: <46F087BF.1000809@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 03:45:33.0032 (UTC) FILETIME=[87D18E80:01C7FA6F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay, I don't see a problem in indicating to the MN that the AR that it is attached to is a MAG and PMIP6 capable. This will allow the MN to determine which prefix to use sent in the RA. I agree that the MAG need not check MN capability, but it makes sense to provide AR capability information to the MN via the RA. This allows the MN to decide which prefix to use (assuming the home prefix from the LMA and the local prefix of the MAG are both included in the RA). -Raj On 9/18/07 9:21 PM, "ext Vijay Devarapalli" wrote: > That is not the point Sri. The text that has been added has a lot of > implications. A capability exchange becomes relevant only when you talk > about co-existence of PMIPv6 and MIPv6. > > The problem is that we had some text earlier that said, the MAG may want > to check if the MN is authorized for PMIPv6 service before sending a > proxy BU. That text has been completely re-written to say that the MAG > should provide PMIPv6 service only after figuring out MN capabilities. > That is completely unacceptable. > > Sri Gundavelli wrote: >> >> We are not mandating any approach. Its just stating few possibilities, >> that can be the basis for the MAG's decision. Capability exchange in >> the ND messages is probably the most reasonable approach. > > That is irrelevant. > >> The HA >> service flags or the "R" flag in the Home Agent info Option ..all fall >> in line with this approach. > > We haven't even discussed that document. > > Vijay > >> We are only listing possibilities and there >> is no way the draft is recommending that approach. I do know Domagoj >> and others have drafts on this approach, but this is not endorsing that >> approach, as there are other approaches as well. We can take this text >> out if any one else also thinks, this text goes into a solution space. >> >> Sri >> >> >> > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 18 23:59:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqhp-0004bp-K9; Tue, 18 Sep 2007 23:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqho-0004am-AJ for netlmm@ietf.org; Tue, 18 Sep 2007 23:58:28 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXqhi-0004zd-HL for netlmm@ietf.org; Tue, 18 Sep 2007 23:58:28 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL003G1KBRU8@szxga04-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 11:57:27 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL000I2KBQEO@szxga04-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 11:57:27 +0800 (CST) Received: from z49950 ([10.121.32.154]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOL00445KBN0J@szxml03-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 11:57:26 +0800 (CST) Date: Wed, 19 Sep 2007 11:57:14 +0800 From: "John.zhao" Subject: [netlmm] Comments on I-D Action:draft-ietf-netlmm-proxymip6-05.txt In-reply-to: To: 'Sri Gundavelli' Message-id: <007a01c7fa71$2a3f52f0$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf3YJo9hCu/BC+IRSydGEWSYEGoJQDDInZA X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi,Sri Some little comments: 1)In section 6.13, if the scope of this section is restricted the detachment detection within network based? Because some network based approachs is listed here but didn't include any methods indicated by mobile node. So I just want to make clarify about this. 2)In section 7.3, the definition of ' Lower Default-Router List Cache Time-out' seems will adjusted the RFC2461 to support a Netlmm specified MN . Although we require the MN only should play as a normal IPv6 node. So if this statement is valid, I means that this should be specified in RFC2461 and related document. When a machine deployed the IPv6 stack, it didn't sure if the netlmm is used, so why and when it adjust this timeout value in the mobile node? Maybe I missed some assumption. Something wrong please indicated. 3)And also in section 7.3, some context transfer is used to provide the support for new MAG know about the previous MAG. Here I suggest the policy store can be use to do this forward. Because the context transfer is option after all. So we can use the policy store this value and let new MAG retrieve these information during the same progress when MN enter into its network. 4) Related with above suggestion , the 'link-address option' defined in section 8.4 can be clarified to a option for use. If the SEND didn't be used, and a same link-local address is shared between MAG , such as the original link-local address or the link-local address of LMA etc, then the link-local address of MN is no need to be known by any new MAGs. Meanwhile the same link-local address can be transferred optionally via policy store or by the context transfer way. My two cents. Maybe something is missed before by me, so there is some little suggestion for your reference. Best Rgds, Thanks. John.zhao _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 00:13:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqwO-0003vR-J3; Wed, 19 Sep 2007 00:13:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXqwN-0003vC-Lc for netlmm@ietf.org; Wed, 19 Sep 2007 00:13:31 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXqwN-0002DQ-52 for netlmm@ietf.org; Wed, 19 Sep 2007 00:13:31 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 21:13:30 -0700 Message-ID: <46F0A1E7.9000508@azairenet.com> Date: Tue, 18 Sep 2007 21:13:27 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 04:13:30.0426 (UTC) FILETIME=[6F9F91A0:01C7FA73] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Basavaraj Patil wrote: > Vijay, > > I don't see a problem in indicating to the MN that the AR that it is > attached to is a MAG and PMIP6 capable. > This will allow the MN to determine which prefix to use sent in the RA. > > I agree that the MAG need not check MN capability, but it makes sense to > provide AR capability information to the MN via the RA. This allows the MN > to decide which prefix to use (assuming the home prefix from the LMA and the > local prefix of the MAG are both included in the RA). We need to discuss this in more detail. I guess you are now talking about Scenario B in the PMIPv6 - MIPv6 interactions document. In scenario B, the MAG/AR announces only one prefix to the mobile node. If PMIPv6 is being used to provide mobility for the mobile node, the MAG advertises the PMIPv6 home network prefix. If MIPv6 is being used by the mobile node for mobility, the AR advertises a visited link prefix for the mobile node to configure a care-of address. For the base PMIPv6 specification we have assumed that it is a regular IPv6 host that requires mobility management using PMIPv6. It has no capability to figure out which prefix to use as you described above. Vijay > > -Raj > > > On 9/18/07 9:21 PM, "ext Vijay Devarapalli" > wrote: > >> That is not the point Sri. The text that has been added has a lot of >> implications. A capability exchange becomes relevant only when you talk >> about co-existence of PMIPv6 and MIPv6. >> >> The problem is that we had some text earlier that said, the MAG may want >> to check if the MN is authorized for PMIPv6 service before sending a >> proxy BU. That text has been completely re-written to say that the MAG >> should provide PMIPv6 service only after figuring out MN capabilities. >> That is completely unacceptable. >> >> Sri Gundavelli wrote: >>> We are not mandating any approach. Its just stating few possibilities, >>> that can be the basis for the MAG's decision. Capability exchange in >>> the ND messages is probably the most reasonable approach. >> That is irrelevant. >> >>> The HA >>> service flags or the "R" flag in the Home Agent info Option ..all fall >>> in line with this approach. >> We haven't even discussed that document. >> >> Vijay >> >>> We are only listing possibilities and there >>> is no way the draft is recommending that approach. I do know Domagoj >>> and others have drafts on this approach, but this is not endorsing that >>> approach, as there are other approaches as well. We can take this text >>> out if any one else also thinks, this text goes into a solution space. >>> >>> Sri >>> >>> >>> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 00:44:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXrPi-0000tK-Rw; Wed, 19 Sep 2007 00:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXrPh-0000tF-HP for netlmm@ietf.org; Wed, 19 Sep 2007 00:43:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXrPg-0005oj-AP for netlmm@ietf.org; Wed, 19 Sep 2007 00:43:49 -0400 X-IronPort-AV: E=Sophos;i="4.20,271,1186383600"; d="scan'208";a="220735737" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Sep 2007 21:43:47 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8J4hlal017480; Tue, 18 Sep 2007 21:43:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8J4hlX1008105; Wed, 19 Sep 2007 04:43:47 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 21:43:47 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 21:43:47 -0700 From: "Sri Gundavelli" To: References: <007a01c7fa71$2a3f52f0$a864a8c0@china.huawei.com> Subject: RE: [netlmm] Comments on I-D Action:draft-ietf-netlmm-proxymip6-05.txt Date: Tue, 18 Sep 2007 21:43:47 -0700 Message-ID: <01d101c7fa77$aad8b6d0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf3YJo9hCu/BC+IRSydGEWSYEGoJQDDInZAAAFmAfA= In-Reply-To: <007a01c7fa71$2a3f52f0$a864a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 19 Sep 2007 04:43:47.0577 (UTC) FILETIME=[AABACE90:01C7FA77] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2705; t=1190177027; x=1191041027; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Comments=20on=20=20I-D=20Action=3Adraft-ie tf-netlmm-proxymip6-05.txt |Sender:=20; bh=i74M5eBdgYOUGeZCKKsSPLQZrb9za5XYrYl4lPbztMc=; b=svut5c2W2n9HJWAqnkwWxPKk7AjKBzqbX+ZbNbAcLraupxQSRQXAO7MHCAeAQDxVFnm53QaF 9YidaxI7qSFb30V0iMmsdRLemD7etaNlgwIIjgEBfhSBlV4BPrEKaLdm; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi John, Inline .. > -----Original Message----- > From: John.zhao [mailto:john.zhao@huawei.com] > Sent: Tuesday, September 18, 2007 8:57 PM > To: 'Sri Gundavelli' > Cc: netlmm@ietf.org > Subject: [netlmm] Comments on I-D > Action:draft-ietf-netlmm-proxymip6-05.txt > > Hi,Sri > > Some little comments: > 1)In section 6.13, if the scope of this section is > restricted the > detachment detection within network based? Because some network based > approachs is listed here but didn't include any methods > indicated by mobile > node. So I just want to make clarify about this. Its very specific to the access technology. It could be an L2 event or an L3 event. So, its not in scope for this document. That's intentional. > 2)In section 7.3, the definition of ' Lower Default-Router List > Cache Time-out' seems will adjusted the RFC2461 to support a Netlmm > specified MN . Although we require the MN only should play as > a normal IPv6 > node. So if this statement is valid, I means that this should > be specified > in RFC2461 and related document. When a machine deployed the > IPv6 stack, it > didn't sure if the netlmm is used, so why and when it adjust > this timeout > value in the mobile node? Maybe I missed some assumption. > Something wrong > please indicated. MN section is non-normative. We are not requiring any changes to the MN stack. The discussion is only for faster handoffs and general guidance. > 3)And also in section 7.3, some context transfer is > used to provide > the support for new MAG know about the previous MAG. Here I > suggest the > policy store can be use to do this forward. Because the > context transfer is > option after all. So we can use the policy store this value > and let new MAG > retrieve these information during the same progress when MN > enter into its > network. > 4) Related with above suggestion , the 'link-address > option' defined > in section 8.4 can be clarified to a option for use. If the > SEND didn't be > used, and a same link-local address is shared between MAG , > such as the > original link-local address or the link-local address of LMA > etc, then the > link-local address of MN is no need to be known by any new > MAGs. Meanwhile > the same link-local address can be transferred optionally via > policy store > or by the context transfer way. Ok. All of this can be defined in CT spec. We are not defining any specific mechanism. > My two cents. Maybe something is missed before by me, > so there is > some little suggestion for your reference. > Ok. Thanks for the review. > Best Rgds, > Thanks. > John.zhao _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 01:51:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXsT0-0007Yz-AR; Wed, 19 Sep 2007 01:51:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXsSy-0007YG-4K for netlmm@ietf.org; Wed, 19 Sep 2007 01:51:16 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXsSr-0007Si-Ov for netlmm@ietf.org; Wed, 19 Sep 2007 01:51:16 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8J5oSCx011187; Wed, 19 Sep 2007 08:50:58 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 08:50:46 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 00:50:44 -0500 Received: from 10.241.58.246 ([10.241.58.246]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Sep 2007 05:50:44 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 19 Sep 2007 00:51:19 -0500 Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt From: Basavaraj Patil To: Vijay Devarapalli Message-ID: Thread-Topic: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Thread-Index: Acf6gRmQWCSHemZ0EdyuUQARJNUNiA== In-Reply-To: <46F0A1E7.9000508@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 05:50:44.0720 (UTC) FILETIME=[05222F00:01C7FA81] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay, On 9/18/07 11:13 PM, "ext Vijay Devarapalli" wrote: > Basavaraj Patil wrote: >> Vijay, >> >> I don't see a problem in indicating to the MN that the AR that it is >> attached to is a MAG and PMIP6 capable. >> This will allow the MN to determine which prefix to use sent in the RA. >> >> I agree that the MAG need not check MN capability, but it makes sense to >> provide AR capability information to the MN via the RA. This allows the MN >> to decide which prefix to use (assuming the home prefix from the LMA and the >> local prefix of the MAG are both included in the RA). > > We need to discuss this in more detail. I guess you are now talking > about Scenario B in the PMIPv6 - MIPv6 interactions document. In > scenario B, the MAG/AR announces only one prefix to the mobile node. If > PMIPv6 is being used to provide mobility for the mobile node, the MAG > advertises the PMIPv6 home network prefix. If MIPv6 is being used by the > mobile node for mobility, the AR advertises a visited link prefix for > the mobile node to configure a care-of address. > > For the base PMIPv6 specification we have assumed that it is a regular > IPv6 host that requires mobility management using PMIPv6. It has no > capability to figure out which prefix to use as you described above. I-D draft-damic-netlmm-pmip6-ind-discover-01 proposes an extension to the Router advertisements by which you can indicate to the MN which is the prefix from an LMA and differentiate it from the local prefix. Given that the router advertisments options are being extended by the IPv6 WG, this is plausible and hence possible. In the context of the base PMIP6 I-D, I agree that an MS has no way of differentiating the prefixes contained in an RA. -Raj > > Vijay > >> >> -Raj >> >> >> On 9/18/07 9:21 PM, "ext Vijay Devarapalli" >> wrote: >> >>> That is not the point Sri. The text that has been added has a lot of >>> implications. A capability exchange becomes relevant only when you talk >>> about co-existence of PMIPv6 and MIPv6. >>> >>> The problem is that we had some text earlier that said, the MAG may want >>> to check if the MN is authorized for PMIPv6 service before sending a >>> proxy BU. That text has been completely re-written to say that the MAG >>> should provide PMIPv6 service only after figuring out MN capabilities. >>> That is completely unacceptable. >>> >>> Sri Gundavelli wrote: >>>> We are not mandating any approach. Its just stating few possibilities, >>>> that can be the basis for the MAG's decision. Capability exchange in >>>> the ND messages is probably the most reasonable approach. >>> That is irrelevant. >>> >>>> The HA >>>> service flags or the "R" flag in the Home Agent info Option ..all fall >>>> in line with this approach. >>> We haven't even discussed that document. >>> >>> Vijay >>> >>>> We are only listing possibilities and there >>>> is no way the draft is recommending that approach. I do know Domagoj >>>> and others have drafts on this approach, but this is not endorsing that >>>> approach, as there are other approaches as well. We can take this text >>>> out if any one else also thinks, this text goes into a solution space. >>>> >>>> Sri >>>> >>>> >>>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 01:53:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXsVM-0000oX-B2; Wed, 19 Sep 2007 01:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXsVL-0000oS-3G for netlmm@ietf.org; Wed, 19 Sep 2007 01:53:43 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXsVJ-0007WC-Rx for netlmm@ietf.org; Wed, 19 Sep 2007 01:53:43 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Sep 2007 22:53:41 -0700 Message-ID: <46F0B963.8080200@azairenet.com> Date: Tue, 18 Sep 2007 22:53:39 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2007 05:53:41.0324 (UTC) FILETIME=[6E65D0C0:01C7FA81] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Basavaraj Patil wrote: >>> I don't see a problem in indicating to the MN that the AR that it is >>> attached to is a MAG and PMIP6 capable. >>> This will allow the MN to determine which prefix to use sent in the RA. >>> >>> I agree that the MAG need not check MN capability, but it makes sense to >>> provide AR capability information to the MN via the RA. This allows the MN >>> to decide which prefix to use (assuming the home prefix from the LMA and the >>> local prefix of the MAG are both included in the RA). >> We need to discuss this in more detail. I guess you are now talking >> about Scenario B in the PMIPv6 - MIPv6 interactions document. In >> scenario B, the MAG/AR announces only one prefix to the mobile node. If >> PMIPv6 is being used to provide mobility for the mobile node, the MAG >> advertises the PMIPv6 home network prefix. If MIPv6 is being used by the >> mobile node for mobility, the AR advertises a visited link prefix for >> the mobile node to configure a care-of address. >> >> For the base PMIPv6 specification we have assumed that it is a regular >> IPv6 host that requires mobility management using PMIPv6. It has no >> capability to figure out which prefix to use as you described above. > > I-D draft-damic-netlmm-pmip6-ind-discover-01 proposes an extension to the > Router advertisements by which you can indicate to the MN which is the > prefix from an LMA and differentiate it from the local prefix. Given that > the router advertisments options are being extended by the IPv6 WG, this is > plausible and hence possible. > > In the context of the base PMIP6 I-D, I agree that an MS has no way of > differentiating the prefixes contained in an RA. IMO, this topic belongs in the PMIPv6 - MIPv6 interactions document and not in the base PMIPv6 spec. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 03:16:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXtnB-0003FL-FA; Wed, 19 Sep 2007 03:16:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXtnA-0003FE-5R for netlmm@ietf.org; Wed, 19 Sep 2007 03:16:12 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXtn3-0000xH-CM for netlmm@ietf.org; Wed, 19 Sep 2007 03:16:12 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL00CHLTHBS6@szxga02-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 15:15:11 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JOL00AROTHANU@szxga02-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 15:15:11 +0800 (CST) Received: from z49950 ([10.121.32.154]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JOL00D07TH6PC@szxml03-in.huawei.com> for netlmm@ietf.org; Wed, 19 Sep 2007 15:15:10 +0800 (CST) Date: Wed, 19 Sep 2007 15:14:57 +0800 From: "John.zhao" Subject: RE: [netlmm] Comments on I-D Action:draft-ietf-netlmm-proxymip6-05.txt In-reply-to: <01d101c7fa77$aad8b6d0$d5f6200a@amer.cisco.com> To: 'Sri Gundavelli' Message-id: <00c201c7fa8c$c9538d50$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf3YJo9hCu/BC+IRSydGEWSYEGoJQDDInZAAAFmAfAAAekZMA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi,Sri > > Hi John, > > Inline .. > > > -----Original Message----- > > From: John.zhao [mailto:john.zhao@huawei.com] > > > > Hi,Sri > > > > Some little comments: > > 1)In section 6.13, if the scope of this section is > > restricted the > > detachment detection within network based? Because some network based > > approachs is listed here but didn't include any methods > > indicated by mobile > > node. So I just want to make clarify about this. > > Its very specific to the access technology. It could be an L2 > event or an L3 event. So, its not in scope for this document. > That's intentional. > [John.zhao] Agree. But there are still some access related technologies is listed here for example the ppp and so on. so I think at least we can specify the MN detachment detection and resource cleanup can be initiated by MN. Right? We didn't need to specify any detail technology here. > > 2)In section 7.3, the definition of ' Lower Default-Router List > > Cache Time-out' seems will adjusted the RFC2461 to support a Netlmm > > specified MN . Although we require the MN only should play as > > a normal IPv6 > > node. So if this statement is valid, I means that this should > > be specified > > in RFC2461 and related document. When a machine deployed the > > IPv6 stack, it > > didn't sure if the netlmm is used, so why and when it adjust > > this timeout > > value in the mobile node? Maybe I missed some assumption. > > Something wrong > > please indicated. > > MN section is non-normative. We are not requiring any changes > to the MN stack. The discussion is only for faster handoffs > and general guidance. > [John.zhao] The general guidance in RFC2461 is timing out prefixes and default router. But in this version,it require MN must replace old default router with the newly learnt default router. And you mean that is for faster handoff.So, if do you mean that the MN will be care of the faster handoff? If thus, the lifetime indicate in RA is invalid. > > > 3)And also in section 7.3, some context transfer is > > used to provide > > the support for new MAG know about the previous MAG. Here I > > suggest the > > policy store can be use to do this forward. Because the > > context transfer is > > option after all. So we can use the policy store this value > > and let new MAG > > retrieve these information during the same progress when MN > > enter into its > > network. > > 4) Related with above suggestion , the 'link-address > > option' defined > > in section 8.4 can be clarified to a option for use. If the > > SEND didn't be > > used, and a same link-local address is shared between MAG , > > such as the > > original link-local address or the link-local address of LMA > > etc, then the > > link-local address of MN is no need to be known by any new > > MAGs. Meanwhile > > the same link-local address can be transferred optionally via > > policy store > > or by the context transfer way. > > Ok. All of this can be defined in CT spec. We are not defining any > specific mechanism. > [John.zhao] It fine define the related work in CT spec. But it seems not belong to the scope of CT that transfer via policy store. Meanwhile, the link-local option should be clarify as option,right? > > My two cents. Maybe something is missed before by me, > > so there is > > some little suggestion for your reference. > > > > Ok. Thanks for the review. > > > Best Rgds, > > Thanks. > > John.zhao _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 04:39:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXv5n-0000FL-JB; Wed, 19 Sep 2007 04:39:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXv5m-0000Ds-50 for netlmm@ietf.org; Wed, 19 Sep 2007 04:39:30 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXv5l-0000rM-Fr for netlmm@ietf.org; Wed, 19 Sep 2007 04:39:30 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs1.siemens.at with ESMTP id l8J8dNc0024697; Wed, 19 Sep 2007 10:39:23 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8J8dED3023480; Wed, 19 Sep 2007 10:39:22 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Sep 2007 10:39:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Wed, 19 Sep 2007 10:39:01 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68029C5561@zagh223a.ww300.siemens.net> In-Reply-To: <46F087BF.1000809@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Thread-Index: Acf6Y9kI7h1nzmWpR4Gv4RtgGwI9JwAMXRpQ References: <00b101c7f43f$1ce03080$37a36b80@amer.cisco.com> <3C31CDD06342EA4A8137716247B1CD6802941FC2@zagh223a.ww300.siemens.net> <011501c7f5a1$7e873b40$d5f6200a@amer.cisco.com> <46F07084.7040209@azairenet.com> <01cf01c7fa5f$2112b620$d5f6200a@amer.cisco.com> <46F087BF.1000809@azairenet.com> From: "Premec, Domagoj" To: "Vijay Devarapalli" , "Sri Gundavelli" X-OriginalArrivalTime: 19 Sep 2007 08:39:16.0612 (UTC) FILETIME=[904A7440:01C7FA98] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070919103923-0B32EBB0-7347C73D/0-0/0-15 X-purgate-size: 2795/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vijay, > A capability exchange becomes relevant=20 > only when you talk about co-existence of PMIPv6 and MIPv6. The section "6.14. Allowing network access to other IPv6 nodes", to = which the text was added, talks about MAG acting also as a regular AR. = Regular AR is used for both simple IP and CMIP so this section seems to = be the right place for the added text. =20 > That text has been=20 > completely re-written to say that the MAG should provide=20 > PMIPv6 service only after figuring out MN capabilities.=20 No, the new text says that the MAG _may_ take into account the MN's = preferences and capabilites when making decision about the mobility = mode. As Sri also points out, the added text does not go into solution = space.=20 I just wanted to have it explicitely stated that there may be other = factors influencing the decision of the mobility mode besides the AAA = profile. And that's what the added text does, nothing more. I don't see = how this is harmful to the base spec. domagoj > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com]=20 > Sent: 19. rujan 2007 04:22 > To: Sri Gundavelli > Cc: Premec, Domagoj; 'netlmm' > Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt >=20 > That is not the point Sri. The text that has been added has a=20 > lot of implications. A capability exchange becomes relevant=20 > only when you talk about co-existence of PMIPv6 and MIPv6. >=20 > The problem is that we had some text earlier that said, the=20 > MAG may want to check if the MN is authorized for PMIPv6=20 > service before sending a proxy BU. That text has been=20 > completely re-written to say that the MAG should provide=20 > PMIPv6 service only after figuring out MN capabilities.=20 > That is completely unacceptable. >=20 > Sri Gundavelli wrote: > >=20 > > We are not mandating any approach. Its just stating few=20 > possibilities,=20 > > that can be the basis for the MAG's decision. Capability=20 > exchange in=20 > > the ND messages is probably the most reasonable approach. >=20 > That is irrelevant. >=20 > > The HA > > service flags or the "R" flag in the Home Agent info Option=20 > ..all fall=20 > > in line with this approach. >=20 > We haven't even discussed that document. >=20 > Vijay >=20 > > We are only listing possibilities and there is no way the draft is=20 > > recommending that approach. I do know Domagoj and others=20 > have drafts=20 > > on this approach, but this is not endorsing that approach, as there=20 > > are other approaches as well. We can take this text out if any one=20 > > else also thinks, this text goes into a solution space. > >=20 > > Sri > >=20 > >=20 > > =20 >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 05:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXvpC-00007u-0E; Wed, 19 Sep 2007 05:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXvpA-00005g-T9 for netlmm@ietf.org; Wed, 19 Sep 2007 05:26:24 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXvp4-0004Vn-JK for netlmm@ietf.org; Wed, 19 Sep 2007 05:26:24 -0400 Received: by ug-out-1314.google.com with SMTP id u2so709737uge for ; Wed, 19 Sep 2007 02:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=zMpTgEFh8uFPwf84/h941S5haIwcFR1Z+ssXnzdZbQ4=; b=XauJL1jFFBmBm/GhOCkwtRDVCrL+LFhblI74B3qL8Yn520VKdkH0z7vRyfCiY/B5zrPKIbsIVa6PyBWgo7xexBUIwYQrTU9p95SeDpBC6TPEICv/JfH3Pfh+Fy70/IuR0dV+VEyxryw8336i9Unc06w3ALyDs/+1yVWvGvPh/FU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=gG95lY/1gRVv2lQzk19r9jVy0Te6FMrFfaoD0tEpMGIUPdTETG9Ucq35Nd2yPA+Q5MJmffEODXWd8K3MdmP7i79geXV4ispLiYBbUNI7EyfLi3S+J3ajUG5URxfC7qaTyPlragujjHExBcsMvPRh70j88ugUS1JXxtbYoWtSAvk= Received: by 10.66.249.11 with SMTP id w11mr1766875ugh.1190193967786; Wed, 19 Sep 2007 02:26:07 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id i39sm3129102ugd.2007.09.19.02.26.05 (version=SSLv3 cipher=OTHER); Wed, 19 Sep 2007 02:26:06 -0700 (PDT) From: Julien Laganier To: netlmm Date: Wed, 19 Sep 2007 11:26:00 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709191126.01398.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [netlmm] Comments on Section 6.8. Link-Local and Global Address Uniqueness X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Folks, I have the following inlined comments on Section 6.8., as well other paragraphs related to link-local addresses: > 6.8. Link-Local and Global Address Uniqueness > > A mobile node in the Proxy Mobile IPv6 domain, as it moves from > one mobile access gateway to the other, it will continue to detect > its home network and thus making it believe it is still on the same > link. Every time the mobile node attaches to a new link, the event > related to the interface state change, will trigger the mobile node > to perform DAD operation on the link-local and global addresses. > However, if the mobile node is DNAv6 enabled, as specified in [ID- > DNAV6], it may not detect the link change due to DNAv6 > optimizations and may not trigger the duplicate address detection > (DAD) procedure for establishing the link-local address uniqueness > on that new link. Further, if the mobile node uses an interface > identifier that is not based on EUI-64 identifier, such as > specified in IPv6 Stateless Autoconfiguration specification > [RFC-2462], there is a possibility, with the odds of 1 to billion, > of a link-local address collision between the two neighbors on that > access link. I don't think this specification is the right place to assess the odds of interface indentifier collisions. The reference to RFC2462 is not right. I think the last sentence should be reworded: Further, if the mobile node forms a link-local address using an interface identifier that does not have any guarantee of uniqueness as specified in, e.g., Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC3041] or Cryptographically Generated Addresses [RFC3972], there is a possibility of a link-local address collision between the two neighbors on that access link. > One of the workarounds for this issue is to set the DNAv6 > configuration parameter, DNASameLinkDADFlag to TRUE and that will > force the mobile node to redo DAD operation every time the > interface detects a handover, even when DNAv6 does not detect a > link change. Since the above workaround can't be used systematically, it has IMHO no value as a mechanism to avoid such collisions. I recommend the paragraph to be deleted. (FWIW, it also defeats DNAv6) > However, this issues will not impact point-to-point links based on > PPP session. Each time the mobile node moves and attaches to a > new mobile access gateway, either the PPP session [RFC-1661] is > reestablished or the PPP session may be moved as part of context > transfer procedures between the old and the new mobile access > gateway. > > When the mobile node tries to establish a PPP session with the > mobile access gateway, the PPP goes through the Network layer > Protocol phase and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets > triggered. Both the PPP peers negotiate a unique identifier using > Interface- Identifier option in IPV6CP and the negotiated > identifier is used for generating a unique link-local address on > that link. Now, if the mobile node moves to a new mobile access > gateway, the PPP session gets torn down with the old mobile access > gateway and a new PPP session gets established with the new mobile > access gateway, and the mobile node obtains a new link-local > address. So, even if the mobile node is DNAv6 capable, the mobile > node always configures a new link- local address when ever it moves > to a new link. > > If the PPP session state is moved to the new mobile access > gateway, as part of context transfer procedures that are in place, > there will not be any change to the interface identifiers of the > two nodes on that point-to-point change. The whole link is moved > to the new mobile access gateway and there will not be any need for > establishing link-local address uniqueness on that link. I think the above text is not specific to PPP. We could instead refer to 1) point-to-point link layers where interface identifiers are negotiated between the endpoints (such as PPP, or GPRS) and 2) point-to-point link layers where the MAG endpoint is "moved" to follow the MN's movements using context transfers, and thus where the MAG interface identifier and link local address follows the MN. > Alternatively, this specification allows the mobile access gateway > to upload the mobile node's link-local address to the local > mobility anchor using the Link-local Address option, exchanged in > the binding registration messages. The mobile access gateway can > learn the mobile node's link-local address, by snooping the DAD > messages sent by the mobile node for establishing the link-local > address uniqueness on the access link. Subsequently, at each > handoff, the mobile access gateway can obtain this address from the > local mobility anchor and can change its own link-local address, if > it detects an address collision. I'd like that the specification presents the above technique as the main address collision avoidance mechanism, rather than an alternative. Also, the text above implies that the MN has configured a single link-local address. It is however possible that the MN configures more than one link-local address. Thus I'd like the above paragraph and the rest of the specification to use plural where it refers to link-local address of a MN. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 07:39:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXxsy-0001em-BL; Wed, 19 Sep 2007 07:38:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXxsx-0001eV-7Q for netlmm@ietf.org; Wed, 19 Sep 2007 07:38:27 -0400 Received: from mout.perfora.net ([74.208.4.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXxsr-0005Ru-K9 for netlmm@ietf.org; Wed, 19 Sep 2007 07:38:22 -0400 Received: from [88.235.95.247] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IXxsj36H1-0008JZ; Wed, 19 Sep 2007 07:38:20 -0400 From: "Alper Yegin" To: "'Premec, Domagoj'" , "'Sri Gundavelli'" , "'JinHyeock Choi'" Subject: RE: [netlmm] Comments on draft-05 Date: Wed, 19 Sep 2007 14:38:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf5up794E2vmRAFQZaHQryMpBwx+gAAEUqwAA0TBwAAMIq00A== In-Reply-To: <3C31CDD06342EA4A8137716247B1CD68029C4D7F@zagh223a.ww300.siemens.net> Message-Id: <0MKp8S-1IXxsj36H1-0008JZ@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX193QA+3aO6csx9eHi+vvljw1D9KdXWxPlrXVEV qWVhLFRyU5LU/QaFT6axQLUjCwRVv7cEWbUyXhv+7Qbuoqo5ys oT7A/edtRurMvB4TFVOzw== X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Domagoj, > IMO, if this is about lease extension, then the network should always > return the same address and not a different one based on the same HNP. > Otherwise there will be no IP session continuity thus defeating the > purpose of the PMIP. > > During the inital attachment to a PMIP domain, the network if free to > return any address, based on any HNP. Unless dictated otherwise by the, for example, AAA. AAA can require the access network to assign a particular HNP and HoA to the MN even for the initial network entry. Alper > > domagoj > > > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: 18. rujan 2007 08:44 > > To: 'JinHyeock Choi' > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] Comments on draft-05 > > > > > > > > > > > -----Original Message----- > > > From: JinHyeock Choi [mailto:jinchoe@gmail.com] > > > Sent: Monday, September 17, 2007 11:11 PM > > > To: Sri Gundavelli > > > Cc: netlmm@ietf.org > > > Subject: Re: [netlmm] Comments on draft-05 > > > > > > > The DHCP server keeps a binding between an address and a > > client id. > > > > If there is a valid lease for a client, any subsequent > > request from > > > > the client will still contain the same client id and the > > DHCP server > > > > will attempt to issue the same address. > > > > > > > > Also, the request is comming from the MN and if its knows > > > its earlier > > > > address, it can request for the same. If it does not know > > > its earlier > > > > address, but if there exists a lease on the DHCP server for that > > > > client, it will still end up with its earlier address, > > because the > > > > client id is still the same. This is per 3315, standard behavior. > > > > > > I am afraid that DHCP server may change. > > > > > > > It wont do the DHCP discover for lease extension. The request > > will be unicasted as the client has the state. > > > > > > > From the above, I see that the MN will get the same address if it > > > sends a DHCP request to the SAME DHCP server. > > > > > > However, after moving to a different network, the MN would > > send a DHCP > > > request to a different DHCP server, which won't have a > > binding for the > > > MN. > > > > > > Allow me an example. > > > > > > Assume an MN is attached to MAG 1 and > > > allocated an address from DHCP server 1. > > > Then the MN moves to another network and attaches itself to MAG2. > > > After related pmipv6 procedure, > > > the MN sends a DHCP request to > > > a different DHCP server 2. > > > > > > How can we be sure that DHCP server 2 > > > will always allocate the MN's existing address? > > > > > > Also IMO, we don't need to ensure that DHCP server always allocates > > > the same address. PMIPv6 would work just fine even when DHCP server > > > would allocate the different addresses (with the same HNP). > > > > > > > Ok. I'm fine stating that it will get an address from its > > HNP, that's the key point. This is a normal access link and > > we dont have to specify further details. > > > > Ok. Thanks for the comments. > > > > Sri > > > > > Best Regards > > > > > > JinHyeock > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 07:50:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXy40-0007E7-2l; Wed, 19 Sep 2007 07:49:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXy3y-0007B9-CP for netlmm@ietf.org; Wed, 19 Sep 2007 07:49:50 -0400 Received: from mout.perfora.net ([74.208.4.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXy3x-0005mv-Q5 for netlmm@ietf.org; Wed, 19 Sep 2007 07:49:50 -0400 Received: from [88.235.95.247] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IXy2j2Jso-0007Kz; Wed, 19 Sep 2007 07:48:38 -0400 From: "Alper Yegin" To: "'Julien Laganier'" , , "'Premec, Domagoj'" Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments ondraft-05) Date: Wed, 19 Sep 2007 14:48:23 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf5/acqNP4EP8+jQfex3B3ch3XpdgAs/FrA In-Reply-To: <200709181609.25806.julien.IETF@laposte.net> Message-Id: <0MKpCa-1IXy2j2Jso-0007Kz@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/gzucEjE0IWxwSZa/+GPwi/G2CPO1mhtYrM+t Go4s2y3Wvyh+oNVHBlv1g4Av4jo+xo5CkScSvhEoTgIQy7O+5+ 3dhSmMo4VsbFXiw1JChPQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien, > Since only one DHCPv6 server must handle address allocation for a MN > attaching to different MAGs and access links, the following requirement > we can derive one requirement on DHCPv6 deployments arise: > > - DHCPv6 relays must be deployed on each access link of the PMIPv6 > domain. Also, since the link between MAG and MN is point-to-point, > that translates into a requirement for a DHCPv6 relay to be > collocated with the MAG. There are alternative approaches. Different DHCP servers (e.g., ones collocated with the MAGs) can be used as long as they can be dynamically-provisioned with the MN configuration parameters, for example, during network access authentication. A general comment: We shall avoid such "system-level requirements" in our protocol spec unless absolutely necessary. Alper > > Noting that a DHCPv6 relays "places a global or site-scoped address with > a prefix assigned to the link on which the client should be assigned an > address in the link-address field. This address will be used by the > server to determine the link from which the client should be assigned > an address and other configuration information" [RFC3315], the following > limitation arises: > > - the MAG/Relay has to know a global address with a prefix assigned > to the link on which the client should be assigned an address. That > means the MAG/Relay has to know the HNP for the MN before it > (to derive the "global address with a prefix assigned to the link > on which the client should be assigned an address") forward the > DHCPv6 message. > > Thus, DHCPv6 cannot be used to retrieve the HNP at first attachment. HNP > must be obtained via other means such as PMIPv6 HNP option, or > out-of-band (e.g. AAA). > > Thoughts? > > --julien > > On Tuesday 18 September 2007, JinHyeock Choi wrote: > > > The DHCP server keeps a binding between an address and a client id. > > > If there is a valid lease for a client, any subsequent request from > > > the client will still contain the same client id and the DHCP > > > server will attempt to issue the same address. > > > > > > Also, the request is comming from the MN and if its knows its > > > earlier address, it can request for the same. If it does not know > > > its earlier address, but if there exists a lease on the DHCP server > > > for that client, it will still end up with its earlier address, > > > because the client id is still the same. This is per 3315, standard > > > behavior. > > > > I am afraid that DHCP server may change. > > > > From the above, I see that the MN will get the same address > > if it sends a DHCP request to the SAME DHCP server. > > > > However, after moving to a different network, > > the MN would send a DHCP request to a different DHCP server, > > which won't have a binding for the MN. > > > > Allow me an example. > > > > Assume an MN is attached to MAG 1 and > > allocated an address from DHCP server 1. > > Then the MN moves to another network and > > attaches itself to MAG2. > > After related pmipv6 procedure, > > the MN sends a DHCP request to > > a different DHCP server 2. > > > > How can we be sure that DHCP server 2 > > will always allocate the MN's existing address? > > > > Also IMO, we don't need to ensure that DHCP server > > always allocates the same address. PMIPv6 would work just fine even > > when DHCP server would allocate the different addresses (with the > > same HNP). > > > > Best Regards > > > > JinHyeock > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 08:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXyPp-0007qj-5H; Wed, 19 Sep 2007 08:12:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXyPn-0007oa-CJ for netlmm@ietf.org; Wed, 19 Sep 2007 08:12:23 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IXyPm-0008Ic-7w for netlmm@ietf.org; Wed, 19 Sep 2007 08:12:23 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1190203936!22824820!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13103 invoked from network); 19 Sep 2007 12:12:16 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 19 Sep 2007 12:12:16 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8JCCBmv014293; Wed, 19 Sep 2007 05:12:11 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8JCCBZR002642; Wed, 19 Sep 2007 07:12:11 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8JCC9Up002568; Wed, 19 Sep 2007 07:12:09 -0500 (CDT) Message-ID: <46F11213.4020300@gmail.com> Date: Wed, 19 Sep 2007 14:12:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1IXy2j2Jso-0007Kz@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IXy2j2Jso-0007Kz@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-2, 18/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: netlmm@ietf.org, 'Julien Laganier' Subject: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Hi Julien, > >> Since only one DHCPv6 server must handle address allocation for a >> MN attaching to different MAGs and access links, the following >> requirement we can derive one requirement on DHCPv6 deployments >> arise: >> >> - DHCPv6 relays must be deployed on each access link of the PMIPv6 >> domain. Also, since the link between MAG and MN is point-to-point, >> that translates into a requirement for a DHCPv6 relay to be >> collocated with the MAG. I would agree. However, DHCP Relays with point-to-point links is not something widely used, is it? But I'd agree it can work. > There are alternative approaches. Different DHCP servers (e.g., ones > collocated with the MAGs) can be used as long as they can be > dynamically-provisioned with the MN configuration parameters, for > example, during network access authentication. What's 'dynamically-provisioned'? Is it a SDO-specific mechanism? I don't know how a deployer would like to deploy a DHCP Server in each MAG without mentioning how these pools of addresses are dynamically provisioned. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 08:32:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXyjP-0003LI-HF; Wed, 19 Sep 2007 08:32:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXyjN-0003LD-Lk for netlmm@ietf.org; Wed, 19 Sep 2007 08:32:37 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXyjN-0006vA-Bz for netlmm@ietf.org; Wed, 19 Sep 2007 08:32:37 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8JCWXW22182; Wed, 19 Sep 2007 12:32:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Alternatives to RECOMMENDED timestamp Date: Wed, 19 Sep 2007 07:32:23 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116D4B18B@zrc2hxm2.corp.nortel.com> In-Reply-To: <200709181245.28146.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Alternatives to RECOMMENDED timestamp Thread-Index: Acf54k7fB5yKMwopQE2td+pvR7fmwwA1qjHw References: <46EACC13.3060904@gmail.com> <013c01c7f6fd$54584be0$d5f6200a@amer.cisco.com> <200709181245.28146.julien.IETF@laposte.net> From: "Ahmad Muhanna" To: "Julien Laganier" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I am not sure if I answered this question earlier or not, just in case. YES. Regards, Ahmad =20 > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net]=20 > Sent: Tuesday, September 18, 2007 5:45 AM > To: netlmm@ietf.org > Subject: Re: [netlmm] Alternatives to RECOMMENDED timestamp >=20 > On Friday 14 September 2007, Sri Gundavelli wrote: > >=20 > > - Is it mandatory for the implementations to implement=20 > Timestamp based=20 > > solution. [Y/N]. Just a YES or NO, will be more than sufficient. >=20 > YES. >=20 > --julien >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 09:20:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXzTT-0005fd-3M; Wed, 19 Sep 2007 09:20:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXzTS-0005fW-5w for netlmm@ietf.org; Wed, 19 Sep 2007 09:20:14 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXzTR-00087p-CG for netlmm@ietf.org; Wed, 19 Sep 2007 09:20:14 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id l8JDKBLq015248; Wed, 19 Sep 2007 15:20:11 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8JDJuEZ010436; Wed, 19 Sep 2007 15:20:09 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Sep 2007 15:19:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Comments on draft-05 Date: Wed, 19 Sep 2007 15:19:57 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68029E91D5@zagh223a.ww300.siemens.net> In-Reply-To: <0MKp8S-1IXxsj36H1-0008JZ@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Comments on draft-05 Thread-Index: Acf5up794E2vmRAFQZaHQryMpBwx+gAAEUqwAA0TBwAAMIq00AADcSxw References: <3C31CDD06342EA4A8137716247B1CD68029C4D7F@zagh223a.ww300.siemens.net> <0MKp8S-1IXxsj36H1-0008JZ@mrelay.perfora.net> From: "Premec, Domagoj" To: "Alper Yegin" , "Sri Gundavelli" , "JinHyeock Choi" X-OriginalArrivalTime: 19 Sep 2007 13:19:59.0610 (UTC) FILETIME=[C77FFDA0:01C7FABF] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070919152011-54E81BB0-074B1F9F/0-0/0-15 X-purgate-size: 4419/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, =20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: 19. rujan 2007 13:38 > To: Premec, Domagoj; 'Sri Gundavelli'; 'JinHyeock Choi' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Comments on draft-05 >=20 > Hi Domagoj, > =20 > > IMO, if this is about lease extension, then the network=20 > should always=20 > > return the same address and not a different one based on=20 > the same HNP. > > Otherwise there will be no IP session continuity thus defeating the=20 > > purpose of the PMIP. > >=20 > > During the inital attachment to a PMIP domain, the network=20 > if free to=20 > > return any address, based on any HNP. >=20 > Unless dictated otherwise by the, for example, AAA. AAA can=20 > require the access network to assign a particular HNP and HoA=20 > to the MN even for the initial network entry. I agree. I also think this falls into category "network is free to = assign any address based on any HNP", it is purely network's decision. = You seem to be distinguishing access network from the (core?) network. = OK, I can agree to that. domagoj >=20 > Alper >=20 >=20 > >=20 > > domagoj > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: 18. rujan 2007 08:44 > > > To: 'JinHyeock Choi' > > > Cc: netlmm@ietf.org > > > Subject: RE: [netlmm] Comments on draft-05 > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: JinHyeock Choi [mailto:jinchoe@gmail.com] > > > > Sent: Monday, September 17, 2007 11:11 PM > > > > To: Sri Gundavelli > > > > Cc: netlmm@ietf.org > > > > Subject: Re: [netlmm] Comments on draft-05 > > > > > > > > > The DHCP server keeps a binding between an address and a > > > client id. > > > > > If there is a valid lease for a client, any subsequent > > > request from > > > > > the client will still contain the same client id and the > > > DHCP server > > > > > will attempt to issue the same address. > > > > > > > > > > Also, the request is comming from the MN and if its knows > > > > its earlier > > > > > address, it can request for the same. If it does not know > > > > its earlier > > > > > address, but if there exists a lease on the DHCP=20 > server for that=20 > > > > > client, it will still end up with its earlier address, > > > because the > > > > > client id is still the same. This is per 3315,=20 > standard behavior. > > > > > > > > I am afraid that DHCP server may change. > > > > > > > > > > It wont do the DHCP discover for lease extension. The=20 > request will=20 > > > be unicasted as the client has the state. > > > > > > > > > > From the above, I see that the MN will get the same=20 > address if it=20 > > > > sends a DHCP request to the SAME DHCP server. > > > > > > > > However, after moving to a different network, the MN would > > > send a DHCP > > > > request to a different DHCP server, which won't have a > > > binding for the > > > > MN. > > > > > > > > Allow me an example. > > > > > > > > Assume an MN is attached to MAG 1 and allocated an address from=20 > > > > DHCP server 1. > > > > Then the MN moves to another network and attaches=20 > itself to MAG2. > > > > After related pmipv6 procedure, > > > > the MN sends a DHCP request to > > > > a different DHCP server 2. > > > > > > > > How can we be sure that DHCP server 2 will always allocate the=20 > > > > MN's existing address? > > > > > > > > Also IMO, we don't need to ensure that DHCP server always=20 > > > > allocates the same address. PMIPv6 would work just fine=20 > even when=20 > > > > DHCP server would allocate the different addresses=20 > (with the same HNP). > > > > > > > > > > Ok. I'm fine stating that it will get an address from its HNP,=20 > > > that's the key point. This is a normal access link and we=20 > dont have=20 > > > to specify further details. > > > > > > Ok. Thanks for the comments. > > > > > > Sri > > > > > > > Best Regards > > > > > > > > JinHyeock > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 09:29:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXzcW-0005Ar-4o; Wed, 19 Sep 2007 09:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXzcU-000542-R1 for netlmm@ietf.org; Wed, 19 Sep 2007 09:29:34 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXzcK-0001lb-Jt for netlmm@ietf.org; Wed, 19 Sep 2007 09:29:30 -0400 Received: by ug-out-1314.google.com with SMTP id u2so773048uge for ; Wed, 19 Sep 2007 06:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=QcjcvnhvPTj4fSujae6WZ7LKy5yrEI1aZYnlN1jtxq8=; b=lMCEIhsAXgdOq2zdjMInT1b9ReQjJayofSKHvXSfD8OSNN5npDnCNigxhbnCGY43stB0Wd4iqIgktQx/G1gyICy8ZmYDgPp7YMVD6PAEyPFtxwWFI5+E1L51Q2RTjGCOUeTIV8rtB3+vTdrI7SNjnfGr91bPMymMRp+FuBeM/bg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=CJ3raIrPkvvE6Tw5VkmB1NlJu8Y+Yo33BFhoZ3eQJuIXqgzdVq0MeWNdC0gar4xAmfq8L5h6y9HgWv6DADgs4qcHa7pQWzI5BVsGcg5sSKlT2mjvQBC9oOTQNwhv3WqdgD1/hQNWSG6rzc/g08McRbov/OZSx1Uomg63jdZdqv0= Received: by 10.66.249.16 with SMTP id w16mr1954338ugh.1190208548815; Wed, 19 Sep 2007 06:29:08 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id s7sm3483856uge.2007.09.19.06.29.07 (version=SSLv3 cipher=OTHER); Wed, 19 Sep 2007 06:29:07 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments ondraft-05) Date: Wed, 19 Sep 2007 15:29:03 +0200 User-Agent: KMail/1.9.6 References: <0MKpCa-1IXy2j2Jso-0007Kz@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IXy2j2Jso-0007Kz@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709191529.03764.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Wednesday 19 September 2007, Alper Yegin wrote: > Hi Julien, Hi Alper, > > Since only one DHCPv6 server must handle address allocation for a > > MN attaching to different MAGs and access links, the following > > requirement we can derive one requirement on DHCPv6 deployments > > arise: > > > > - DHCPv6 relays must be deployed on each access link of the > > PMIPv6 domain. Also, since the link between MAG and MN is > > point-to-point, that translates into a requirement for a DHCPv6 > > relay to be collocated with the MAG. > > There are alternative approaches. Different DHCP servers (e.g., ones > collocated with the MAGs) can be used as long as they can be > dynamically-provisioned with the MN configuration parameters, for > example, during network access authentication. If the DHCPv6 server changes after handover, that implies that the new DHCPv6 server will not reply to a DHCPv6 renew message sent by the MN since the renew was to be handled by the previous DHCPv6 server. The new DHCPv6 server will not reply either to the DHCPV6 rebind message sent by the MN unless there's a mechanism to share DHCPv6 client bindings amongst the different DHCP servers. AFAIK we do not have such a mechanism. Thus, it seems like we can't have different DHCPv6 servers handle a single MN. Am I missing something? > A general comment: We shall avoid such "system-level requirements" in > our protocol spec unless absolutely necessary. Agree. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 09:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXzjV-0005Mr-BJ; Wed, 19 Sep 2007 09:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXzjU-0005Iv-6q for netlmm@ietf.org; Wed, 19 Sep 2007 09:36:48 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXzjJ-0001z4-QD for netlmm@ietf.org; Wed, 19 Sep 2007 09:36:48 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id l8JDaQYg030479; Wed, 19 Sep 2007 15:36:26 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8JDaN7T021747; Wed, 19 Sep 2007 15:36:23 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Sep 2007 15:36:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments ondraft-05) Date: Wed, 19 Sep 2007 15:35:58 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD68029E9227@zagh223a.ww300.siemens.net> In-Reply-To: <0MKpCa-1IXy2j2Jso-0007Kz@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments ondraft-05) Thread-Index: Acf5/acqNP4EP8+jQfex3B3ch3XpdgAs/FrAAAOScTA= References: <200709181609.25806.julien.IETF@laposte.net> <0MKpCa-1IXy2j2Jso-0007Kz@mrelay.perfora.net> From: "Premec, Domagoj" To: "Alper Yegin" , "Julien Laganier" , X-OriginalArrivalTime: 19 Sep 2007 13:36:22.0874 (UTC) FILETIME=[11922BA0:01C7FAC2] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070919153626-54E8FBB0-2A4B2E36/0-0/0-15 X-purgate-size: 5086/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, > Different DHCP servers=20 > (e.g., ones collocated with the MAGs) can be used as long as=20 > they can be dynamically-provisioned with the MN configuration=20 > parameters, for example, during network access authentication.=20 I think in this case we should be more specific how the address renewal = is supposed to work. The MN will remember the address of the first MAG = as the address of the DHCP server. How is renewal message delivered: = MN->current MAG->LMA->inital MAG/DHCP server? And the response, does it = go through the LMA or not? Without specifying the exact behaviour, IMO = this will work only in closed systems. domagoj > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: 19. rujan 2007 13:48 > To: 'Julien Laganier'; netlmm@ietf.org; Premec, Domagoj > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was:=20 > [netlmm] Comments ondraft-05) >=20 > Hi Julien, >=20 > > Since only one DHCPv6 server must handle address allocation=20 > for a MN=20 > > attaching to different MAGs and access links, the following=20 > > requirement we can derive one requirement on DHCPv6=20 > deployments arise: > >=20 > > - DHCPv6 relays must be deployed on each access link of=20 > the PMIPv6 > > domain. Also, since the link between MAG and MN is=20 > point-to-point, > > that translates into a requirement for a DHCPv6 relay to be > > collocated with the MAG. >=20 > There are alternative approaches. Different DHCP servers=20 > (e.g., ones collocated with the MAGs) can be used as long as=20 > they can be dynamically-provisioned with the MN configuration=20 > parameters, for example, during network access authentication. >=20 > A general comment: We shall avoid such "system-level=20 > requirements" in our protocol spec unless absolutely necessary. >=20 > Alper >=20 >=20 > >=20 > > Noting that a DHCPv6 relays "places a global or site-scoped address=20 > > with a prefix assigned to the link on which the client should be=20 > > assigned an address in the link-address field. This=20 > address will be=20 > > used by the server to determine the link from which the=20 > client should=20 > > be assigned an address and other configuration information"=20 > [RFC3315],=20 > > the following limitation arises: > >=20 > > - the MAG/Relay has to know a global address with a=20 > prefix assigned > > to the link on which the client should be assigned an=20 > address. That > > means the MAG/Relay has to know the HNP for the MN before it > > (to derive the "global address with a prefix assigned=20 > to the link > > on which the client should be assigned an address") forward the > > DHCPv6 message. > >=20 > > Thus, DHCPv6 cannot be used to retrieve the HNP at first=20 > attachment.=20 > > HNP must be obtained via other means such as PMIPv6 HNP option, or=20 > > out-of-band (e.g. AAA). > >=20 > > Thoughts? > >=20 > > --julien > >=20 > > On Tuesday 18 September 2007, JinHyeock Choi wrote: > > > > The DHCP server keeps a binding between an address and=20 > a client id. > > > > If there is a valid lease for a client, any subsequent request=20 > > > > from the client will still contain the same client id=20 > and the DHCP=20 > > > > server will attempt to issue the same address. > > > > > > > > Also, the request is comming from the MN and if its knows its=20 > > > > earlier address, it can request for the same. If it=20 > does not know=20 > > > > its earlier address, but if there exists a lease on the DHCP=20 > > > > server for that client, it will still end up with its earlier=20 > > > > address, because the client id is still the same. This is per=20 > > > > 3315, standard behavior. > > > > > > I am afraid that DHCP server may change. > > > > > > From the above, I see that the MN will get the same address if it=20 > > > sends a DHCP request to the SAME DHCP server. > > > > > > However, after moving to a different network, the MN would send a=20 > > > DHCP request to a different DHCP server, which won't have=20 > a binding=20 > > > for the MN. > > > > > > Allow me an example. > > > > > > Assume an MN is attached to MAG 1 and allocated an=20 > address from DHCP=20 > > > server 1. > > > Then the MN moves to another network and attaches itself to MAG2. > > > After related pmipv6 procedure, > > > the MN sends a DHCP request to > > > a different DHCP server 2. > > > > > > How can we be sure that DHCP server 2 will always=20 > allocate the MN's=20 > > > existing address? > > > > > > Also IMO, we don't need to ensure that DHCP server always=20 > allocates=20 > > > the same address. PMIPv6 would work just fine even when=20 > DHCP server=20 > > > would allocate the different addresses (with the same HNP). > > > > > > Best Regards > > > > > > JinHyeock > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 10:04:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY09f-0000l6-4i; Wed, 19 Sep 2007 10:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY09d-0000kx-Hj for netlmm@ietf.org; Wed, 19 Sep 2007 10:03:49 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY09W-0002cw-Rx for netlmm@ietf.org; Wed, 19 Sep 2007 10:03:49 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8JE2etN025867; Wed, 19 Sep 2007 16:02:42 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Sep 2007 16:03:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Date: Wed, 19 Sep 2007 16:03:18 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A88@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <46F0A1E7.9000508@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Thread-Index: Acf6c7KlKootYfLtRd2l/VUUoSSiaAANFdxw References: <46F0A1E7.9000508@azairenet.com> From: "DE JUAN HUARTE FEDERICO" To: "Vijay Devarapalli" X-OriginalArrivalTime: 19 Sep 2007 14:03:19.0679 (UTC) FILETIME=[D54308F0:01C7FAC5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vijay, Raj, while I can understand deployments where there's no interaction between = network based and client based mobility, I don't think the PMIP6 base = specification should ignore that these interactions exist Maybe what would be appropriate is to add a reference to the = interactions document So, based on the previous text (as forwarded by Vijay), I would propose = following modification: "Upon obtaining the mobile node's profile after a successful access = authentication and after a policy consideration, the mobile access = gateway MUST determine if the network based mobility service should be = offered to that mobile node. If the mobile node is entitled for such = service, then the mobile access gateway should also address interactions = with client based mobility solutions as described in = REF-Interactions-DOC. If the outcome of these interactions is network = based mobility, then the mobile access gateway must ensure the mobile = node believes it is on its home link, as explained in various sections = of this specification." Regards federico -----Message d'origine----- De : Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 Envoy=E9 : mercredi 19 septembre 2007 06:13 =C0 : Basavaraj Patil Cc : 'netlmm' Objet : Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt Basavaraj Patil wrote: > Vijay, >=20 > I don't see a problem in indicating to the MN that the AR that it is=20 > attached to is a MAG and PMIP6 capable. > This will allow the MN to determine which prefix to use sent in the = RA. >=20 > I agree that the MAG need not check MN capability, but it makes sense=20 > to provide AR capability information to the MN via the RA. This allows = > the MN to decide which prefix to use (assuming the home prefix from=20 > the LMA and the local prefix of the MAG are both included in the RA). We need to discuss this in more detail. I guess you are now talking = about Scenario B in the PMIPv6 - MIPv6 interactions document. In = scenario B, the MAG/AR announces only one prefix to the mobile node. If PMIPv6 is being used to provide mobility for the mobile node, the MAG = advertises the PMIPv6 home network prefix. If MIPv6 is being used by the = mobile node for mobility, the AR advertises a visited link prefix for = the mobile node to configure a care-of address. For the base PMIPv6 specification we have assumed that it is a regular IPv6 host that requires mobility management using PMIPv6. It has no = capability to figure out which prefix to use as you described above. Vijay >=20 > -Raj >=20 >=20 > On 9/18/07 9:21 PM, "ext Vijay Devarapalli" > wrote: >=20 >> That is not the point Sri. The text that has been added has a lot of=20 >> implications. A capability exchange becomes relevant only when you=20 >> talk about co-existence of PMIPv6 and MIPv6. >> >> The problem is that we had some text earlier that said, the MAG may=20 >> want to check if the MN is authorized for PMIPv6 service before=20 >> sending a proxy BU. That text has been completely re-written to say=20 >> that the MAG should provide PMIPv6 service only after figuring out MN = capabilities. >> That is completely unacceptable. >> >> Sri Gundavelli wrote: >>> We are not mandating any approach. Its just stating few=20 >>> possibilities, that can be the basis for the MAG's decision.=20 >>> Capability exchange in the ND messages is probably the most = reasonable approach. >> That is irrelevant. >> >>> The HA >>> service flags or the "R" flag in the Home Agent info Option ..all=20 >>> fall in line with this approach. >> We haven't even discussed that document. >> >> Vijay >> >>> We are only listing possibilities and there is no way the draft is=20 >>> recommending that approach. I do know Domagoj and others have=20 >>> drafts on this approach, but this is not endorsing that approach, as = >>> there are other approaches as well. We can take this text out if any = >>> one else also thinks, this text goes into a solution space. >>> >>> Sri >>> >>> >>> =20 >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 10:35:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY0dX-0003MA-2e; Wed, 19 Sep 2007 10:34:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY0dV-0003Jl-JR for netlmm@ietf.org; Wed, 19 Sep 2007 10:34:41 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY0dU-0001cu-VB for netlmm@ietf.org; Wed, 19 Sep 2007 10:34:41 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 07:34:40 -0700 Message-ID: <46F1337D.50601@azairenet.com> Date: Wed, 19 Sep 2007 07:34:37 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: DE JUAN HUARTE FEDERICO Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt References: <46F0A1E7.9000508@azairenet.com> <319D54578EAC3147BA8CC78DAB5467A501399A88@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A88@FRVELSMBS12.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Sep 2007 14:34:40.0161 (UTC) FILETIME=[361DD110:01C7FACA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, This text may fit in the PMIPv6 - MIPv6 interactions document. Not in the base PMIPv6 document. Vijay DE JUAN HUARTE FEDERICO wrote: > Hi Vijay, Raj, > > while I can understand deployments where there's no interaction between network based and client based mobility, I don't think the PMIP6 base specification should ignore that these interactions exist > Maybe what would be appropriate is to add a reference to the interactions document > > So, based on the previous text (as forwarded by Vijay), I would propose following modification: > "Upon obtaining the mobile node's profile after a successful access authentication and after a policy consideration, the mobile access gateway MUST determine if the network based mobility service should be offered to that mobile node. If the mobile node is entitled for such service, then the mobile access gateway should also address interactions with client based mobility solutions as described in REF-Interactions-DOC. If the outcome of these interactions is network based mobility, then the mobile access gateway must ensure the mobile node believes it is on its home link, as explained in various sections of this specification." > > Regards > > federico > > > -----Message d'origine----- > De : Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Envoyé : mercredi 19 septembre 2007 06:13 > À : Basavaraj Patil > Cc : 'netlmm' > Objet : Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt > > Basavaraj Patil wrote: >> Vijay, >> >> I don't see a problem in indicating to the MN that the AR that it is >> attached to is a MAG and PMIP6 capable. >> This will allow the MN to determine which prefix to use sent in the RA. >> >> I agree that the MAG need not check MN capability, but it makes sense >> to provide AR capability information to the MN via the RA. This allows >> the MN to decide which prefix to use (assuming the home prefix from >> the LMA and the local prefix of the MAG are both included in the RA). > > We need to discuss this in more detail. I guess you are now talking about Scenario B in the PMIPv6 - MIPv6 interactions document. In scenario B, the MAG/AR announces only one prefix to the mobile node. If > PMIPv6 is being used to provide mobility for the mobile node, the MAG advertises the PMIPv6 home network prefix. If MIPv6 is being used by the mobile node for mobility, the AR advertises a visited link prefix for the mobile node to configure a care-of address. > > For the base PMIPv6 specification we have assumed that it is a regular > IPv6 host that requires mobility management using PMIPv6. It has no capability to figure out which prefix to use as you described above. > > Vijay > >> -Raj >> >> >> On 9/18/07 9:21 PM, "ext Vijay Devarapalli" >> wrote: >> >>> That is not the point Sri. The text that has been added has a lot of >>> implications. A capability exchange becomes relevant only when you >>> talk about co-existence of PMIPv6 and MIPv6. >>> >>> The problem is that we had some text earlier that said, the MAG may >>> want to check if the MN is authorized for PMIPv6 service before >>> sending a proxy BU. That text has been completely re-written to say >>> that the MAG should provide PMIPv6 service only after figuring out MN capabilities. >>> That is completely unacceptable. >>> >>> Sri Gundavelli wrote: >>>> We are not mandating any approach. Its just stating few >>>> possibilities, that can be the basis for the MAG's decision. >>>> Capability exchange in the ND messages is probably the most reasonable approach. >>> That is irrelevant. >>> >>>> The HA >>>> service flags or the "R" flag in the Home Agent info Option ..all >>>> fall in line with this approach. >>> We haven't even discussed that document. >>> >>> Vijay >>> >>>> We are only listing possibilities and there is no way the draft is >>>> recommending that approach. I do know Domagoj and others have >>>> drafts on this approach, but this is not endorsing that approach, as >>>> there are other approaches as well. We can take this text out if any >>>> one else also thinks, this text goes into a solution space. >>>> >>>> Sri >>>> >>>> >>>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 10:49:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY0qz-0006sT-Vt; Wed, 19 Sep 2007 10:48:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY0qw-0006qV-2I for netlmm@ietf.org; Wed, 19 Sep 2007 10:48:34 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY0qu-0003r0-QC for netlmm@ietf.org; Wed, 19 Sep 2007 10:48:34 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IY0qi3Fw9-0007Ui; Wed, 19 Sep 2007 10:48:27 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" Date: Wed, 19 Sep 2007 17:48:09 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf6tlWSlkHP7Eo9SuCIC2pQ9yscnwAFSn7A In-Reply-To: <46F11213.4020300@gmail.com> Message-Id: <0MKpCa-1IY0qi3Fw9-0007Ui@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+HKHcSneeyd0g9JVeFztd4qcc7hS2TWsoEUIE veb9gfLA2cN1dZHzEfsMyUJhc4picOwv5LWNWfIbllwYOMzjeJ KfzDGOgG30bqSh9TWmQ3w== X-Spam-Score: -0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: netlmm@ietf.org, 'Julien Laganier' Subject: [netlmm] RE: DHCPv6 deployment in PMIPv6 domain and SDO X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > > There are alternative approaches. Different DHCP servers (e.g., ones > > collocated with the MAGs) can be used as long as they can be > > dynamically-provisioned with the MN configuration parameters, for > > example, during network access authentication. > > What's 'dynamically-provisioned'? Is it a SDO-specific mechanism? I > don't know how a deployer would like to deploy a DHCP Server in each MAG > without mentioning how these pools of addresses are dynamically > provisioned. It's typically done via AAA. For example, sending Framed-IP-Address via RADIUS is for configuring that IP address via DHCP (or PPP). Alper > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 11:00:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY12B-00019A-BR; Wed, 19 Sep 2007 11:00:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY129-00018L-JB for netlmm@ietf.org; Wed, 19 Sep 2007 11:00:09 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY128-00049V-Bx for netlmm@ietf.org; Wed, 19 Sep 2007 11:00:09 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IY123071X-0007Nt; Wed, 19 Sep 2007 11:00:08 -0400 From: "Alper Yegin" To: "'Julien Laganier'" , Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments ondraft-05) Date: Wed, 19 Sep 2007 17:59:53 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf6wQ+OsEJjnDeqTpeZmYuQ/lBXqgADIKDA In-Reply-To: <200709191529.03764.julien.IETF@laposte.net> Message-Id: <0MKpCa-1IY123071X-0007Nt@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19FWBp1TNC/ry5oQxq5B4eTnoT5Gojo921qbi7 b6ZTB2HA6YMM5oNkHymrmBQj5kkwMjh9SlUcku25PXCvOqTw91 ThcTBLORYPli7jgEfiOWQ== X-Spam-Score: -0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien, > > There are alternative approaches. Different DHCP servers (e.g., ones > > collocated with the MAGs) can be used as long as they can be > > dynamically-provisioned with the MN configuration parameters, for > > example, during network access authentication. > > If the DHCPv6 server changes after handover, that implies that the new > DHCPv6 server will not reply to a DHCPv6 renew message sent by the MN > since the renew was to be handled by the previous DHCPv6 server. The > new DHCPv6 server will not reply either to the DHCPV6 rebind message > sent by the MN unless there's a mechanism to share DHCPv6 client > bindings amongst the different DHCP servers. > > AFAIK we do not have such a mechanism. Thus, it seems like we can't have > different DHCPv6 servers handle a single MN. You mean "we haven't defined how to do that in IETF?" I agree. But that does not mean it is not doable, especially outside the scope of IETF. Alper > > Am I missing something? > > > A general comment: We shall avoid such "system-level requirements" in > > our protocol spec unless absolutely necessary. > > Agree. > > --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 11:02:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY14H-0002tQ-Q2; Wed, 19 Sep 2007 11:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY14G-0002ko-7c for netlmm@ietf.org; Wed, 19 Sep 2007 11:02:20 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IY14A-0004D1-0K for netlmm@ietf.org; Wed, 19 Sep 2007 11:02:20 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1190214091!21340025!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 13419 invoked from network); 19 Sep 2007 15:01:31 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-4.tower-128.messagelabs.com with SMTP; 19 Sep 2007 15:01:31 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l8JF1Qdg017745; Wed, 19 Sep 2007 08:01:26 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8JF1P2n029125; Wed, 19 Sep 2007 10:01:26 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8JF1NGV029005; Wed, 19 Sep 2007 10:01:23 -0500 (CDT) Message-ID: <46F139BD.3050002@gmail.com> Date: Wed, 19 Sep 2007 17:01:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1IY0qi3Fw9-0007Ui@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IY0qi3Fw9-0007Ui@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-2, 18/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: netlmm@ietf.org, 'Julien Laganier' Subject: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: >>> There are alternative approaches. Different DHCP servers (e.g., >>> ones collocated with the MAGs) can be used as long as they can be >>> dynamically-provisioned with the MN configuration parameters, >>> for example, during network access authentication. >> What's 'dynamically-provisioned'? Is it a SDO-specific mechanism? >> I don't know how a deployer would like to deploy a DHCP Server in >> each MAG without mentioning how these pools of addresses are >> dynamically provisioned. > > It's typically done via AAA. For example, sending Framed-IP-Address > via RADIUS is for configuring that IP address via DHCP (or PPP). Any deployed system today with wireless point-to-point links using Framed-IP-Address via RADIUS gives that IP address to mobile with DHCP? I thought all are PPP. I've framed my mind to think that if wireless access link is point-to-point then it's PPP, and if it's shared medium wifi then it's DHCP; never otherwise. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 11:31:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY1Vu-00086R-Be; Wed, 19 Sep 2007 11:30:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY1Vs-00084w-U5 for netlmm@ietf.org; Wed, 19 Sep 2007 11:30:52 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY1Vi-000508-3d for netlmm@ietf.org; Wed, 19 Sep 2007 11:30:52 -0400 Received: by ug-out-1314.google.com with SMTP id u2so849446uge for ; Wed, 19 Sep 2007 08:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Te458sx6hzmwyY5JIQeKk6R0F0ZN6hV8gKUo9mnJsFU=; b=uPACyAdg8HC32UwTfMULozo2rNKf7Xh4TP4NUk0zDJm8GsDFpGowy0rUY3mx59k9prrGjDopWScs+2e/X6lR20LsiScgYcepkVIzxCWsu2pHMPt+WCvXsB6cgF70AVo/QvtBouBNT0MB67EB5BelW6EMEcMmED9yIwLY4xe61bk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=ZJAMrOz+cK3kK29zP8MfLgsyllk16F6/KJBCc0lAKs2C9yo4JyNSgNgNetZmaEuOJLj9+b1+TUr2vLunu3u3okwVNrISZhZ2RT/RxXoVSlDWkRilpVcMHco/+eX+VJtDEBYQ+8JSbXM4Y/QaFa9Mdb+fAr03ohUD+7w2n6AnBf0= Received: by 10.66.240.12 with SMTP id n12mr2082874ugh.1190215824031; Wed, 19 Sep 2007 08:30:24 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id b39sm3659059ugf.2007.09.19.08.30.22 (version=SSLv3 cipher=OTHER); Wed, 19 Sep 2007 08:30:23 -0700 (PDT) From: Julien Laganier To: "Alper Yegin" Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments ondraft-05) Date: Wed, 19 Sep 2007 17:30:17 +0200 User-Agent: KMail/1.9.6 References: <0MKpCa-1IY123071X-0007Nt@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IY123071X-0007Nt@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709191730.18120.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, On Wednesday 19 September 2007, Alper Yegin wrote: > > > > There are alternative approaches. Different DHCP servers (e.g., > > > ones collocated with the MAGs) can be used as long as they can be > > > dynamically-provisioned with the MN configuration parameters, for > > > example, during network access authentication. > > > > If the DHCPv6 server changes after handover, that implies that the > > new DHCPv6 server will not reply to a DHCPv6 renew message sent by > > the MN since the renew was to be handled by the previous DHCPv6 > > server. The new DHCPv6 server will not reply either to the DHCPV6 > > rebind message sent by the MN unless there's a mechanism to share > > DHCPv6 client bindings amongst the different DHCP servers. > > > > AFAIK we do not have such a mechanism. Thus, it seems like we can't > > have different DHCPv6 servers handle a single MN. > > You mean "we haven't defined how to do that in IETF?" I agree. Good. > But that does not mean it is not doable, especially outside the scope > of IETF. Then shouldn't we add some guidance text to DHCPv6 deployers explaining that unless such out-of-scope mechanism is present some limitations are placed on DHCPv6 deployments: DHCPv6 relays have to be present at each MAG, and configured to forward DHCPv6 messages to the same group of DHCPv6 servers (and implicitly that the group of DHCPv6 servers should be reachable from every relay). What do you think? --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 12:56:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2qp-0004L4-FY; Wed, 19 Sep 2007 12:56:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY2qn-0004EQ-Pe for netlmm@ietf.org; Wed, 19 Sep 2007 12:56:33 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY2qm-0005zu-OE for netlmm@ietf.org; Wed, 19 Sep 2007 12:56:33 -0400 X-IronPort-AV: E=Sophos;i="4.20,274,1186383600"; d="scan'208";a="525741522" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Sep 2007 09:56:31 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8JGuVaM023284; Wed, 19 Sep 2007 09:56:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8JGuVX3004499; Wed, 19 Sep 2007 16:56:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 09:56:29 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 09:56:28 -0700 From: "Sri Gundavelli" To: "'Julien Laganier'" , "'netlmm'" References: <200709191126.01398.julien.IETF@laposte.net> Subject: RE: [netlmm] Comments on Section 6.8. Link-Local and Global AddressUniqueness Date: Wed, 19 Sep 2007 09:56:28 -0700 Message-ID: <024601c7fade$05a32490$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf6oAF8xm34DjstSAKgoijS+2JoSgAPEC1w In-Reply-To: <200709191126.01398.julien.IETF@laposte.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 19 Sep 2007 16:56:28.0963 (UTC) FILETIME=[05C1F730:01C7FADE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6952; t=1190220991; x=1191084991; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Comments=20on=20Section=206.8.=20Link-Loca l=20and=20Global=20AddressUniqueness |Sender:=20; bh=1Zh6g2iThepi8KictOp+A8zkfb4bmcl22EzEb1UiF1s=; b=IqtOUCuPzxVCkyJNGlDpBnkZW8VDA6TrCLWClgsh6zhb+7fWaqBWGF2z8ymEZwU+FHEyvAIk CX3ts6+U1Wx1r4fs0lidL65mHyJ/mzEKqOmewNC18UD20elgoUHekkXN52070xeWsweowX2oFt /QujPaOs2E7q9nCTA1U1075Y8=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien, inline .. > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net] > Sent: Wednesday, September 19, 2007 2:26 AM > To: netlmm > Subject: [netlmm] Comments on Section 6.8. Link-Local and > Global AddressUniqueness > > Folks, > > I have the following inlined comments on Section 6.8., as well other > paragraphs related to link-local addresses: > > > 6.8. Link-Local and Global Address Uniqueness > > > > A mobile node in the Proxy Mobile IPv6 domain, as it moves from > > one mobile access gateway to the other, it will continue > to detect > > its home network and thus making it believe it is still > on the same > > link. Every time the mobile node attaches to a new link, > the event > > related to the interface state change, will trigger the > mobile node > > to perform DAD operation on the link-local and global addresses. > > However, if the mobile node is DNAv6 enabled, as > specified in [ID- > > DNAV6], it may not detect the link change due to DNAv6 > > optimizations and may not trigger the duplicate address detection > > (DAD) procedure for establishing the link-local address > uniqueness > > on that new link. Further, if the mobile node uses an interface > > identifier that is not based on EUI-64 identifier, such as > > specified in IPv6 Stateless Autoconfiguration specification > > [RFC-2462], there is a possibility, with the odds of 1 > to billion, > > of a link-local address collision between the two > neighbors on that > > access link. > > I don't think this specification is the right place to assess > the odds > of interface indentifier collisions. The reference to RFC2462 is not > right. I think the last sentence should be reworded: > Ok. I will rephrase the last line. > Further, if the mobile node forms a link-local address using an > interface identifier that does not have any guarantee of > uniqueness > as specified in, e.g., Privacy Extensions for Stateless Address > Autoconfiguration in IPv6 [RFC3041] or Cryptographically Generated > Addresses [RFC3972], there is a possibility of a > link-local address > collision between the two neighbors on that access link. > > > One of the workarounds for this issue is to set the DNAv6 > > configuration parameter, DNASameLinkDADFlag to TRUE and that will > > force the mobile node to redo DAD operation every time the > > interface detects a handover, even when DNAv6 does not detect a > > link change. > > Since the above workaround can't be used systematically, it > has IMHO no > value as a mechanism to avoid such collisions. I recommend the > paragraph to be deleted. (FWIW, it also defeats DNAv6) > I'd like to see DNAv6 being adopted and used. At the same time, we we should point to the required knobs on how to enable/disable it. These are the knobs from the DNAv6 spec. Useful for diagnostics. Just a one line reference, IMO, offers reasonable guidance. > > However, this issues will not impact point-to-point > links based on > > PPP session. Each time the mobile node moves and attaches to a > > new mobile access gateway, either the PPP session [RFC-1661] is > > reestablished or the PPP session may be moved as part of context > > transfer procedures between the old and the new mobile access > > gateway. > > > > When the mobile node tries to establish a PPP session with the > > mobile access gateway, the PPP goes through the Network layer > > Protocol phase and the IPv6 Control Protocol, IPCP6 > [RFC-2472] gets > > triggered. Both the PPP peers negotiate a unique > identifier using > > Interface- Identifier option in IPV6CP and the negotiated > > identifier is used for generating a unique link-local address on > > that link. Now, if the mobile node moves to a new mobile access > > gateway, the PPP session gets torn down with the old > mobile access > > gateway and a new PPP session gets established with the > new mobile > > access gateway, and the mobile node obtains a new link-local > > address. So, even if the mobile node is DNAv6 capable, > the mobile > > node always configures a new link- local address when > ever it moves > > to a new link. > > > > If the PPP session state is moved to the new mobile access > > gateway, as part of context transfer procedures that are > in place, > > there will not be any change to the interface identifiers of the > > two nodes on that point-to-point change. The whole link is moved > > to the new mobile access gateway and there will not be > any need for > > establishing link-local address uniqueness on that link. > > I think the above text is not specific to PPP. We could > instead refer to > 1) point-to-point link layers where interface identifiers are > negotiated between the endpoints (such as PPP, or GPRS) and 2) > point-to-point link layers where the MAG endpoint is "moved" > to follow > the MN's movements using context transfers, and thus where the MAG > interface identifier and link local address follows the MN. > PPP is the most obvious example, we can refer to too in analyzing the impact of MN movement and upon the link restablishment. Probably, what you explained above is exactly being mentioned using the PPP example. > > Alternatively, this specification allows the mobile > access gateway > > to upload the mobile node's link-local address to the local > > mobility anchor using the Link-local Address option, exchanged in > > the binding registration messages. The mobile access gateway can > > learn the mobile node's link-local address, by snooping the DAD > > messages sent by the mobile node for establishing the link-local > > address uniqueness on the access link. Subsequently, at each > > handoff, the mobile access gateway can obtain this > address from the > > local mobility anchor and can change its own link-local > address, if > > it detects an address collision. > > I'd like that the specification presents the above technique > as the main > address collision avoidance mechanism, rather than an alternative. > Ok. I will propose this as the default approach. > Also, the text above implies that the MN has configured a single > link-local address. It is however possible that the MN > configures more > than one link-local address. Thus I'd like the above > paragraph and the > rest of the specification to use plural where it refers to link-local > address of a MN. > Sure. Good point. Thanks Sri > --julien > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 13:10:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY33q-0007jH-BO; Wed, 19 Sep 2007 13:10:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY33p-0007im-3C for netlmm@ietf.org; Wed, 19 Sep 2007 13:10:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY33i-0007hI-K4 for netlmm@ietf.org; Wed, 19 Sep 2007 13:10:01 -0400 X-IronPort-AV: E=Sophos;i="4.20,274,1186383600"; d="scan'208";a="400261134" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 19 Sep 2007 10:09:54 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8JH9sL5020187; Wed, 19 Sep 2007 10:09:54 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8JH9rit027665; Wed, 19 Sep 2007 17:09:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 10:09:52 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 10:09:52 -0700 From: "Sri Gundavelli" To: References: <01d101c7fa77$aad8b6d0$d5f6200a@amer.cisco.com> <00c201c7fa8c$c9538d50$a864a8c0@china.huawei.com> Subject: RE: [netlmm] Comments on I-D Action:draft-ietf-netlmm-proxymip6-05.txt Date: Wed, 19 Sep 2007 10:09:51 -0700 Message-ID: <024701c7fadf$e48e98f0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acf3YJo9hCu/BC+IRSydGEWSYEGoJQDDInZAAAFmAfAAAekZMAAY6n1Q In-Reply-To: <00c201c7fa8c$c9538d50$a864a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 19 Sep 2007 17:09:52.0489 (UTC) FILETIME=[E4B24D90:01C7FADF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4846; t=1190221794; x=1191085794; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Comments=20on=20=20I-D=20Action=3Adraft-ie tf-netlmm-proxymip6-05.txt |Sender:=20; bh=kMJIWKdzEb5LwqR+50ZNgSSXNlVqj5eN0Ncfw455mIk=; b=psUYgZCJHUzMzDqhVDk7+7JU4sBhAbeaJEynHou8lvC9bgKPkHksi17RGloumPhV2h6CWike PvTQv9xAAw4rNixuEs42YxFJfAOlULCq3TdotdcmrPpG25aHt/h7QM8d; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi John, > -----Original Message----- > From: John.zhao [mailto:john.zhao@huawei.com] > Sent: Wednesday, September 19, 2007 12:15 AM > To: 'Sri Gundavelli' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Comments on I-D > Action:draft-ietf-netlmm-proxymip6-05.txt > > Hi,Sri > > > > > Hi John, > > > > Inline .. > > > > > -----Original Message----- > > > From: John.zhao [mailto:john.zhao@huawei.com] > > > > > > Hi,Sri > > > > > > Some little comments: > > > 1)In section 6.13, if the scope of this section is > > > restricted the > > > detachment detection within network based? Because some > network based > > > approachs is listed here but didn't include any methods > > > indicated by mobile > > > node. So I just want to make clarify about this. > > > > Its very specific to the access technology. It could be an L2 > > event or an L3 event. So, its not in scope for this document. > > That's intentional. > > > [John.zhao] Agree. But there are still some access related > technologies is > listed here for example the ppp and so on. so I think at least we can > specify the MN detachment detection and resource cleanup can > be initiated by > MN. Right? We didn't need to specify any detail technology here. May be I dont follow this. How would the MN's detachment detection will be triggered by the MN ? Again, MN section is non-normative. We are not requiring changes to the MN behaviour. The MAG should have the ability to detect the MN's detachment based on L2/L3 approaches and outside the scope. > > > 2)In section 7.3, the definition of ' Lower Default-Router List > > > Cache Time-out' seems will adjusted the RFC2461 to > support a Netlmm > > > specified MN . Although we require the MN only should play as > > > a normal IPv6 > > > node. So if this statement is valid, I means that this should > > > be specified > > > in RFC2461 and related document. When a machine deployed the > > > IPv6 stack, it > > > didn't sure if the netlmm is used, so why and when it adjust > > > this timeout > > > value in the mobile node? Maybe I missed some assumption. > > > Something wrong > > > please indicated. > > > > MN section is non-normative. We are not requiring any changes > > to the MN stack. The discussion is only for faster handoffs > > and general guidance. > > > [John.zhao] The general guidance in RFC2461 is timing out prefixes and > default router. But in this version,it require MN must > replace old default > router with the newly learnt default router. And you mean > that is for faster > handoff.So, if do you mean that the MN will be care of the > faster handoff? > If thus, the lifetime indicate in RA is invalid. > > No. We are not mandating changes to host stack. We are only suggesting to keep the flush timers values low. These are perfectly tunable parameters as per 2461. This entire section explains the PMIP operation as see from the MN perspective. When it sends a RS, the MAG may send initial RA after completing the signaling. So, this explains the MN operation in a PMIP6 domain, with out having any implications on stack changes. > > > 3)And also in section 7.3, some context transfer is > > > used to provide > > > the support for new MAG know about the previous MAG. Here I > > > suggest the > > > policy store can be use to do this forward. Because the > > > context transfer is > > > option after all. So we can use the policy store this value > > > and let new MAG > > > retrieve these information during the same progress when MN > > > enter into its > > > network. > > > 4) Related with above suggestion , the 'link-address > > > option' defined > > > in section 8.4 can be clarified to a option for use. If the > > > SEND didn't be > > > used, and a same link-local address is shared between MAG , > > > such as the > > > original link-local address or the link-local address of LMA > > > etc, then the > > > link-local address of MN is no need to be known by any new > > > MAGs. Meanwhile > > > the same link-local address can be transferred optionally via > > > policy store > > > or by the context transfer way. > > > > Ok. All of this can be defined in CT spec. We are not defining any > > specific mechanism. > > > [John.zhao] It fine define the related work in CT spec. But > it seems not > belong to the scope of CT that transfer via policy store. > Meanwhile, the > link-local option should be clarify as option,right? We already have the messages between LMA and MAG for exchanging this. Dont see a need to provide multiple solutions for this link-local address collision. > > > My two cents. Maybe something is missed before by me, > > > so there is > > > some little suggestion for your reference. > > > Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 16:23:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY65B-0007q2-EW; Wed, 19 Sep 2007 16:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY659-0007pv-KH for netlmm@ietf.org; Wed, 19 Sep 2007 16:23:35 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY654-0005LE-Bu for netlmm@ietf.org; Wed, 19 Sep 2007 16:23:35 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id CB30998008 for ; Wed, 19 Sep 2007 16:23:03 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05917-20 for ; Wed, 19 Sep 2007 16:23:03 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 19 Sep 2007 16:23:03 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 16:20:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Wed, 19 Sep 2007 16:20:35 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA615@exchtewks2.starentnetworks.com> In-Reply-To: <46F139BD.3050002@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Thread-Index: Acf6zeo3oixDj88XRtmNFbSrAAnQdAALHjYw From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" , "Alper Yegin" X-OriginalArrivalTime: 19 Sep 2007 20:20:35.0357 (UTC) FILETIME=[892D64D0:01C7FAFA] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Wednesday, September 19, 2007 10:01 AM > To: Alper Yegin > Cc: netlmm@ietf.org; 'Julien Laganier' > Subject: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO >=20 > Alper Yegin wrote: > >>> There are alternative approaches. Different DHCP servers (e.g., > >>> ones collocated with the MAGs) can be used as long as they can be > >>> dynamically-provisioned with the MN configuration parameters, > >>> for example, during network access authentication. > >> What's 'dynamically-provisioned'? Is it a SDO-specific mechanism? > >> I don't know how a deployer would like to deploy a DHCP Server in > >> each MAG without mentioning how these pools of addresses are > >> dynamically provisioned. > > > > It's typically done via AAA. For example, sending Framed-IP-Address > > via RADIUS is for configuring that IP address via DHCP (or PPP). >=20 > Any deployed system today with wireless point-to-point links using > Framed-IP-Address via RADIUS gives that IP address to mobile with DHCP? > I thought all are PPP. >=20 > I've framed my mind to think that if wireless access link is > point-to-point then it's PPP, and if it's shared medium wifi then it's > DHCP; never otherwise. >=20 [KC>] Nope...there are p2p wireless access links (3GPP, WiMAX) out there where PPP is not used. > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 17:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6tV-0007ZU-0c; Wed, 19 Sep 2007 17:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6tT-0007Z1-8i for netlmm@ietf.org; Wed, 19 Sep 2007 17:15:35 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IY6tN-0006oE-10 for netlmm@ietf.org; Wed, 19 Sep 2007 17:15:35 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1190236514!21374355!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 18268 invoked from network); 19 Sep 2007 21:15:14 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-4.tower-128.messagelabs.com with SMTP; 19 Sep 2007 21:15:14 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8JLFAZM026629; Wed, 19 Sep 2007 14:15:10 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8JLF9Me013965; Wed, 19 Sep 2007 16:15:09 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-19-253-67.corp.mot.com [10.19.253.67]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8JLF5Xv013913; Wed, 19 Sep 2007 16:15:06 -0500 (CDT) Message-ID: <46F19159.7080903@gmail.com> Date: Wed, 19 Sep 2007 23:15:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <7CCD07160348804497EF29E9EA5560D7024DA615$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA615$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Chowdhury, Kuntal wrote: > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Wednesday, September 19, 2007 10:01 AM >> To: Alper Yegin >> Cc: netlmm@ietf.org; 'Julien Laganier' >> Subject: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO >> >> Alper Yegin wrote: >>>>> There are alternative approaches. Different DHCP servers (e.g., >>>>> ones collocated with the MAGs) can be used as long as they can be >>>>> dynamically-provisioned with the MN configuration parameters, >>>>> for example, during network access authentication. >>>> What's 'dynamically-provisioned'? Is it a SDO-specific mechanism? >>>> I don't know how a deployer would like to deploy a DHCP Server in >>>> each MAG without mentioning how these pools of addresses are >>>> dynamically provisioned. >>> It's typically done via AAA. For example, sending Framed-IP-Address >>> via RADIUS is for configuring that IP address via DHCP (or PPP). >> Any deployed system today with wireless point-to-point links using >> Framed-IP-Address via RADIUS gives that IP address to mobile with > DHCP? >> I thought all are PPP. >> >> I've framed my mind to think that if wireless access link is >> point-to-point then it's PPP, and if it's shared medium wifi then it's >> DHCP; never otherwise. >> > [KC>] Nope...there are p2p wireless access links (3GPP, WiMAX) out there > where PPP is not used. Ok. And on these links (3GPP, WiMAX) is DHCP used by the mobile? Because on GPRS and UMTS the mobile doesn't use DHCP. Alex > >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm > > > "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 19 23:31:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYCkj-0006sD-Kf; Wed, 19 Sep 2007 23:30:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYCkj-0006s6-2v for netlmm@ietf.org; Wed, 19 Sep 2007 23:30:57 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYCkh-0007YQ-4A for netlmm@ietf.org; Wed, 19 Sep 2007 23:30:57 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JON00IE6DQA4G@szxga01-in.huawei.com> for netlmm@ietf.org; Thu, 20 Sep 2007 11:30:11 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JON00BCSDQ9CQ@szxga01-in.huawei.com> for netlmm@ietf.org; Thu, 20 Sep 2007 11:30:10 +0800 (CST) Received: from z49950 ([10.121.32.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JON00GJTDQ5WL@szxml04-in.huawei.com> for netlmm@ietf.org; Thu, 20 Sep 2007 11:30:09 +0800 (CST) Date: Thu, 20 Sep 2007 11:29:56 +0800 From: "John.zhao" Subject: RE: [netlmm] Comments on I-D Action:draft-ietf-netlmm-proxymip6-05.txt In-reply-to: <024701c7fadf$e48e98f0$d5f6200a@amer.cisco.com> To: 'Sri Gundavelli' Message-id: <003e01c7fb36$83ebe870$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acf3YJo9hCu/BC+IRSydGEWSYEGoJQDDInZAAAFmAfAAAekZMAAY6n1QABNoxeA= X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi,Sri Thanks.See inline. > Hi John, > > > -----Original Message----- > > From: John.zhao [mailto:john.zhao@huawei.com] > > Hi,Sri > > > Hi John, > > > Inline .. > > > > -----Original Message----- > > > > From: John.zhao [mailto:john.zhao@huawei.com] > > > > Hi,Sri > > > > Some little comments: > > > > 1)In section 6.13, if the scope of this section is restricted the detachment detection within network based? Because some > > > > network based approachs is listed here but didn't include any methods indicated by mobile node. So I just want to make clarify > > > > about this. > > > > > > Its very specific to the access technology. It could be an L2 event or an L3 event. So, its not in scope for this document. > > > That's intentional. > > > > > [John.zhao] Agree. But there are still some access related technologies is listed here for example the ppp and so on. so I think > > at least we can specify the MN detachment detection and resource cleanup can be initiated by MN. Right? We didn't need to specify > > any detail technology here. > > May be I dont follow this. How would the MN's detachment detection will be triggered by the MN ? Again, MN section is non-normative. > We are not requiring changes to the MN behaviour. The MAG should have the ability to detect the MN's detachment based on L2/L3 approaches > and outside the scope. [John.zhao] Yes it is true. But the MN initiated termination can provide a rapid trigger and event to MAG in time. Without the involved of MN, any others is passive. So I sugget modify the following text : 'In general, the mobile access gateway can depend on one or more of the following methods for the detection presence of the mobile node on the connected link: o Link-layer event specific to the access technology o PPP Session termination event on point-to-point link types o IPv6 Neighbor Unreachability Detection event from IPv6 stack o Notification event from the local mobility anchor o Absence of data traffic from the mobile node on the link for a certain duration of time' We can append a sentence as following at the end of the above list: o Notification event from the mobile node Here we didn't need to involve any new method, but some existed method can be utilized,such as DHCP release and so on. > > > > > 2)In section 7.3, the definition of ' Lower Default-Router List Cache Time-out' seems will adjusted the RFC2461 to support > > > > a Netlmm specified MN . Although we require the MN only should play as a normal IPv6 node. So if this statement is valid, I > > > > means that this should be specified in RFC2461 and related document. When a machine deployed the IPv6 stack, it didn't sure > > > > if the netlmm is used, so why and when it adjust this timeout value in the mobile node? Maybe I missed some assumption. > > > > Something wrong please indicated. > > > > > > MN section is non-normative. We are not requiring any changes to the MN stack. The discussion is only for faster handoffs > > > and general guidance. > > > > > [John.zhao] The general guidance in RFC2461 is timing out prefixes and default router. But in this version,it require MN must > > replace old default router with the newly learnt default router. And you mean that is for faster handoff.So, if do you mean that > > the MN will be care of the faster handoff? If thus, the lifetime indicate in RA is invalid. > > No. We are not mandating changes to host stack. We are only suggesting to keep the flush timers values low. These are perfectly > tunable parameters as per 2461. This entire section explains the PMIP operation as see from the MN perspective. When it sends a RS, > the MAG may send initial RA after completing the signaling. So, this explains the MN operation in a PMIP6 domain, with out having > any implications on stack changes. > [John.zhao] I see. When I search in RFC2461.The definition of prefix list and default list as the following: ' Prefix List - A list of the prefixes that define a set of addresses that are on-link. Prefix List entries are created from information received in Router Advertisements. Each entry has an associated invalidation timer value (extracted from the advertisement) used to expire prefixes when they become invalid. A special "infinity" timer value specifies that a prefix remains valid forever, unless a new (finite) value is received in a subsequent advertisement. Default Router List - A list of routers to which packets may be sent.Router list entries point to entries in the Neighbor Cache; the algorithm for selecting a default router favors routers known to be reachable over those whose reachability is suspect. Each entry also has an associated invalidation timer value (extracted from Router Advertisements) used to delete entries that are no longer advertised.' Meanwhile there is the following sentences description the modification of lifetime as the following: ' However, when received information for a specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a specific Prefix) differs from information received earlier, and the parameter/option can only have one value, the most recently-received information is considered authoritative.' But this will depend on the receive of a new RA message. That seems is no relate to what we just said that the ' Lower Default-Router List Cache Time-out'. So I mean that what is the description of tunable?How to tune this timer? Maybe this is a stupid question. Hope didn't make you trouble.Could you help me explain that? > > > > 3)And also in section 7.3, some context transfer is used to provide the support for new MAG know about the previous MAG. Here > > > > I suggest the policy store can be use to do this forward. Because the context transfer is option after all. So we can use the > > > > policy store this value and let new MAG retrieve these information during the same progress when MN enter into its network. > > > > 4) Related with above suggestion , the 'link-address option' defined in section 8.4 can be clarified to a option for use. If > > > > the SEND didn't be used, and a same link-local address is shared between MAG ,such as the original link-local address or the > > > > link-local address of LMA etc, then the link-local address of MN is no need to be known by any new MAGs. Meanwhile > > > > the same link-local address can be transferred optionally via policy store or by the context transfer way. > > > > > > Ok. All of this can be defined in CT spec. We are not defining any specific mechanism. > > > > > [John.zhao] It fine define the related work in CT spec. But it seems not belong to the scope of CT that transfer via policy store. > > Meanwhile, the link-local option should be clarify as option,right? > > We already have the messages between LMA and MAG for exchanging this. Dont see a need to provide multiple solutions for this link-local > address collision. [John.zhao] If the MAG can use the same link-local address in non-SEND environment. Why do we need exchange the link-local of MN between LMA and MAG again? If we can use the same link-local address to be used by difference MAG faced to a MN, then how we can inform MAGs to know about this link-local address if without the use of context transfer? > > > > > > My two cents. Maybe something is missed before by me,so there is some little suggestion for your reference. > > > > > > Thanks > Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 01:16:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYEOG-0005Jw-Vp; Thu, 20 Sep 2007 01:15:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYEOG-0005Ja-Bs for netlmm@ietf.org; Thu, 20 Sep 2007 01:15:52 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYEOE-0001Yu-Rm for netlmm@ietf.org; Thu, 20 Sep 2007 01:15:52 -0400 X-IronPort-AV: E=Sophos;i="4.20,276,1186383600"; d="scan'208";a="221552322" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Sep 2007 22:15:40 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8K5Fef0004062; Wed, 19 Sep 2007 22:15:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8K5Fein013083; Thu, 20 Sep 2007 05:15:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 22:15:39 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 22:15:39 -0700 From: "Sri Gundavelli" To: References: <024701c7fadf$e48e98f0$d5f6200a@amer.cisco.com> <003e01c7fb36$83ebe870$a864a8c0@china.huawei.com> Subject: RE: [netlmm] Comments on I-D Action:draft-ietf-netlmm-proxymip6-05.txt Date: Wed, 19 Sep 2007 22:15:38 -0700 Message-ID: <001201c7fb45$48806e00$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <003e01c7fb36$83ebe870$a864a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf3YJo9hCu/BC+IRSydGEWSYEGoJQDDInZAAAFmAfAAAekZMAAY6n1QABNoxeAABfyN0A== X-OriginalArrivalTime: 20 Sep 2007 05:15:39.0532 (UTC) FILETIME=[48C1BCC0:01C7FB45] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8176; t=1190265340; x=1191129340; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Comments=20on=20=20I-D=20Action=3Adraft-ie tf-netlmm-proxymip6-05.txt |Sender:=20; bh=tw9hQSiiaiuaLza48Y1Zi52jdIr2/WYvIvll/b0Psgw=; b=MWmqkbYZnLgSNXMN7biGnBtc+0azVqrAVnJFYEmb+I5n4cSiTWmlyjd27Pox16qnx9R235XQ iuoWrafaQ2nGuq/lVzfg1dQzEfGsoUVI0xmRcCLrDRlWLoqPK+PQJSNW; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org John, > -----Original Message----- > > > [John.zhao] Agree. But there are still some access > related technologies > is listed here for example the ppp and so on. so I think > > > at least we can > specify the MN detachment detection and resource cleanup can > be initiated by > MN. Right? We didn't need to specify > > any detail technology here. > > > > May be I dont follow this. How would the MN's detachment > detection will be > triggered by the MN ? Again, MN section is non-normative. > We are not > requiring changes to the MN behaviour. The MAG should have > the ability to > detect the MN's detachment based on L2/L3 approaches > > and outside the scope. > [John.zhao] Yes it is true. But the MN initiated termination > can provide a > rapid trigger and event to MAG in time. Without the involved > of MN, any > others is passive. So I sugget modify the following text : > 'In general, the mobile access gateway can depend on > one or more of > the following methods for the detection presence of the > mobile node on the > connected link: > o Link-layer event specific to the access technology > o PPP Session termination event on point-to-point link types > o IPv6 Neighbor Unreachability Detection event from IPv6 stack > o Notification event from the local mobility anchor > o Absence of data traffic from the mobile node on the > link for a certain > duration of time' > > We can append a sentence as following at the end of the > above list: > o Notification event from the mobile node > Here we didn't need to involve any new method, but some existed > method can be utilized,such as DHCP release and so on. If the mobile does a DHCP release, it does not require the MAG to release the prefix. MAG ensures the mobile node believes its on its home link, as long as the node is attached to the link. The MN may have released the DHCP address, but may have chosen to use an autoconfigured address. So, we cant depend on this event. I've already listed some possibilities in a generic way and I think, the above points are sufficient. I cant think of any other event that a normal 2461 compatible IPv6 host can send and that the MAG can use for detachment detection. So, I dont see the point. > > > > > > > 2)In section 7.3, the definition of ' Lower > Default-Router > List Cache Time-out' seems will adjusted the RFC2461 to > support > > > > a > Netlmm specified MN . Although we require the MN only should play as a > normal IPv6 node. So if this statement is valid, I > > > > > means that this > should be specified in RFC2461 and related document. When a > machine deployed > the IPv6 stack, it didn't sure > > > > if the netlmm is used, > so why and > when it adjust this timeout value in the mobile node? Maybe I > missed some > assumption. > > > > > Something wrong please indicated. > > > > > > > > MN section is non-normative. We are not requiring any > changes to the > MN stack. The discussion is only for faster handoffs > > > > and general guidance. > > > > > > > [John.zhao] The general guidance in RFC2461 is timing out > prefixes and > default router. But in this version,it require MN must > > > replace old default router with the newly learnt default > router. And you > mean that is for faster handoff.So, if do you mean that > > > the MN will be > care of the faster handoff? If thus, the lifetime indicate in > RA is invalid. > > > > No. We are not mandating changes to host stack. We are only > suggesting to > keep the flush timers values low. These are perfectly > > tunable parameters as per 2461. This entire section > explains the PMIP > operation as see from the MN perspective. When it sends a RS, > > the MAG may send initial RA after completing the signaling. So, this > explains the MN operation in a PMIP6 domain, with out having > > any implications on stack changes. > > > [John.zhao] I see. When I search in RFC2461.The definition of > prefix list > and default list as the following: > ' Prefix List - A list of the prefixes that define a set of > addresses that > are on-link. Prefix List entries are created from > information received in > Router Advertisements. Each entry has an associated > invalidation timer > value (extracted from the advertisement) used to expire > prefixes when they > become invalid. A special "infinity" timer value specifies > that a prefix > remains valid forever, unless a new (finite) value is received in a > subsequent advertisement. > Default Router List - A list of routers to which packets may > be sent.Router > list entries point to entries in the Neighbor Cache; the algorithm for > selecting a default router favors routers known to be > reachable over those > whose reachability is suspect. Each entry also has an associated > invalidation timer value (extracted from Router > Advertisements) used to > delete entries that are no longer advertised.' > Meanwhile there is the following sentences description the > modification of lifetime as the following: > ' However, when received information for a specific parameter > (e.g., Link > MTU) or option (e.g., Lifetime on a specific Prefix) differs from > information received earlier, and the parameter/option can > only have one > value, the most recently-received information is considered > authoritative.' > But this will depend on the receive of a new RA > message. That seems > is no relate to what we just said that the ' Lower > Default-Router List Cache > Time-out'. > So I mean that what is the description of tunable?How > to tune this > timer? Maybe this is a stupid question. Hope didn't make you > trouble.Could > you help me explain that? I see your point. I will look into this and will fix the text, if required. > > > > > > 3)And also in section 7.3, some context > transfer is used to > provide the support for new MAG know about the previous MAG. > Here > > > > I > suggest the policy store can be use to do this forward. > Because the context > transfer is option after all. So we can use the > > > > > policy store this > value and let new MAG retrieve these information during the > same progress > when MN enter into its network. > > > > > 4) Related with above suggestion , the > 'link-address option' > defined in section 8.4 can be clarified to a option for use. > If > > > > the > SEND didn't be used, and a same link-local address is shared > between MAG > ,such as the original link-local address or the > > > > > link-local address > of LMA etc, then the link-local address of MN is no need to > be known by any > new MAGs. Meanwhile > > > > > the same link-local address can be transferred > optionally via policy > store or by the context transfer way. > > > > > > > > Ok. All of this can be defined in CT spec. We are not > defining any > specific mechanism. > > > > > > > [John.zhao] It fine define the related work in CT spec. > But it seems not > belong to the scope of CT that transfer via policy store. > > > Meanwhile, the link-local option should be clarify as > option,right? > > > > We already have the messages between LMA and MAG for > exchanging this. Dont > see a need to provide multiple solutions for this link-local > > address collision. > [John.zhao] If the MAG can use the same link-local address in non-SEND > environment. Why do we need exchange the link-local of MN > between LMA and > MAG again? Ok. If the MAG's are configured with the same link-local address, its not required to send the address to the LMA. Its optional. > If we can use the same link-local address to be used by > difference > MAG faced to a MN, then how we can inform MAGs to know about > this link-local > address if without the use of context transfer? > All the MAG's are provisioned with that address. > > > > > > > > > My two cents. Maybe something is missed before by me,so > there is some little suggestion for your reference. > > > > > > > > > Thanks > > Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 02:25:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYFTN-0007XK-AX; Thu, 20 Sep 2007 02:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYFTL-0007XF-LW for netlmm@ietf.org; Thu, 20 Sep 2007 02:25:11 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYFTE-0003Ir-VR for netlmm@ietf.org; Thu, 20 Sep 2007 02:25:11 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JON00FS4LSD5Y@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 20 Sep 2007 14:24:14 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JON002ABLSAWJ@szxga04-in.huawei.com> for netlmm@ietf.org; Thu, 20 Sep 2007 14:24:13 +0800 (CST) Received: from z49950 ([10.121.32.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JON00G0KLS6JH@szxml04-in.huawei.com> for netlmm@ietf.org; Thu, 20 Sep 2007 14:24:10 +0800 (CST) Date: Thu, 20 Sep 2007 14:23:58 +0800 From: "John.zhao" Subject: RE: [netlmm] Comments on I-D Action:draft-ietf-netlmm-proxymip6-05.txt In-reply-to: <001201c7fb45$48806e00$d5f6200a@amer.cisco.com> To: 'Sri Gundavelli' Message-id: <006101c7fb4e$d44e2360$a864a8c0@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acf3YJo9hCu/BC+IRSydGEWSYEGoJQDDInZAAAFmAfAAAekZMAAY6n1QABNoxeAABfyN0AACLofQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi,Sri > =B7=A2=BC=FE=C8=CB: Sri Gundavelli [mailto:sgundave@cisco.com] > John, > > -----Original Message----- > > > > 1) About the resource cleanup problem . > If the mobile does a DHCP release, it does not require the MAG > to release the prefix. MAG ensures the mobile node believes its > on its home link, as long as the node is attached to the link. > The MN may have released the DHCP address, but may have chosen > to use an autoconfigured address. So, we cant depend on this > event. I've already listed some possibilities in a generic way > and I think, the above points are sufficient. I cant think of any > other event that a normal 2461 compatible IPv6 host can send and > that the MAG can use for detachment detection. So, I dont see the > point. >=20 [John.zhao] Exactly, we can't depend on this event if a MS use an autoconfigured address. That is the current situation. But if we need is = the first problem If thus, then we can design some patch for this problem Otherwise, it can't be use even we have some new method. So I only = suggest we can open this door at here for the consideration in the future. After = all , that is useful for network resource cleanup. And I won't involve the discussion of new method. The requirement is enough. How do you think? > > > > > > > > > 2)In section 7.3, the definition of ' Lower Default-Router > > List Cache Time-out' ...... >=20 > I see your point. I will look into this and will fix the text, > if required. >=20 [John.zhao] OK. > > > > > > > > 3)And also in section 7.3, some context transfer is used to > > > > provide the support for new MAG know about the previous MAG. > > > > > > 4) Related with above suggestion , the 'link-address = option' > > > > defined in section 8.4 can be clarified to a option for use. >=20 > Ok. If the MAG's are configured with the same link-local address, > its not required to send the address to the LMA. Its optional. >=20 [John.zhao] OK.I'm fine. > > If we can use the same link-local address to be used by difference > > MAG faced to a MN, then how we can inform MAGs to know about this link-local > > address if without the use of context transfer? > >=20 > All the MAG's are provisioned with that address. >=20 [John.zhao] OK.I'm fine. So that maybe need to be reported by the = original MAG to policy store during the initial network entry progress. > > > > > > > > > My two cents. Maybe something is missed before by me,so > > there is some little suggestion for your reference. > > > Best Rgds, Thanks, John.zhao _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 02:34:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYFbs-0008VS-5U; Thu, 20 Sep 2007 02:34:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYFbr-0008VN-Kv for netlmm@ietf.org; Thu, 20 Sep 2007 02:33:59 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYFbq-0004Ep-Vj for netlmm@ietf.org; Thu, 20 Sep 2007 02:33:59 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 58891212C52; Thu, 20 Sep 2007 09:33:57 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 62F33212C4C; Thu, 20 Sep 2007 09:33:56 +0300 (EEST) Message-ID: <46F21452.4070208@nomadiclab.com> Date: Thu, 20 Sep 2007 09:33:54 +0300 From: Christian Vogt User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: NetLMM Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Basavaraj Patil Subject: [netlmm] Resolving Remaining Issues X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hello folks, below is a summary of the issues that are still in our tracker for [draft-ietf-netlmm-proxymip6]. The removal of these issues requires working group consensus. So it would be great if those of you who did not do this yet could take another look at the document with the issues in mind, and comment on the mailing list on whether or not you think they have been resolved. Thank you, - Christian -------------------------------------------------------------------------- #167: Support for Authentication Option Monday, August 06, 2007, 4:35:37 PM | christian.vogt@nomadiclab.com Should IPSec be the only mechanism for securing the P-MIP6 signaling messages? Should we allow room for other mechanisms? There are some currently active discussion threads in the ML. -------------------------------------------------------------------------- #157: Editorial Quality Monday, August 06, 2007, 4:26:24 PM | christian.vogt@ericsson.com Improve editorial quality of document. This issue was raised by Behcet Sarikaya on 2007/04/18. -------------------------------------------------------------------------- #165: Responsibility of Home Prefix Assignment Monday, June 18, 2007, 9:35:44 AM | chvogt@tm.uka.de Should the base PMIPv6 spec leave MN-HNP assignment exclusively to the LMA, or should it provide an option for the MAG to assign/retrieve the MN-HNP before it contacts the LMA? This issue affects both v6 and v4 support. It was raised by Jouni Korhonen on 2007/06/09. -------------------------------------------------------------------------- #159: Application Abort upon PPP Re-establishment Tuesday, April 24, 2007, 9:00:40 AM | christian.vogt@ericsson.com Could re-establishment of PPP session upon handover break running applications? This issue was brought up by Jean-Mickael Guerin on 2007/07/23: Jean-Mickael Guerin: As mentioned in the draft the ppp session is torn down then re-established. So I would suspect that some application on the mobile station could break. Do people have some feedback of their implementation for this case? Sri Gundavelli: The link that is assumed on the MN-AR link is point to point link, PPP is just an example. We need to get some data on this for different SDO architectures, how the host handles the handoff scenario for this specific case. -------------------------------------------------------------------------- #155: Ordering of RA and PBU Thursday, April 19, 2007, 2:26:25 PM | christian.vogt@ericsson.com Clarify whether there should there be a pre-defined order in which a MAG sends (i) a Router Advertisement message to a mobile node after link attachment, and (ii) the Proxy Binding Update message to the LMA. This issue was raised by JinHyeock Choi on 2007/04/16. -------------------------------------------------------------------------- #152: Initial Attachment vs. Handover Procedures Thursday, April 19, 2007, 2:20:05 PM | christian.vogt@ericsson.com The procedures of initial network attachment and intra-PMIP6-domain handover should be described separately in section 3 of the draft. This issue was raised by JinHyeock Choi on 2007/04/16. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 02:54:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYFum-0003hS-17; Thu, 20 Sep 2007 02:53:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYFuk-0003gd-Hw for netlmm@ietf.org; Thu, 20 Sep 2007 02:53:30 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYFuj-000429-9u for netlmm@ietf.org; Thu, 20 Sep 2007 02:53:30 -0400 X-IronPort-AV: E=Sophos;i="4.20,277,1186383600"; d="scan'208";a="19016741" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 19 Sep 2007 23:53:28 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8K6rSl3027607; Wed, 19 Sep 2007 23:53:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8K6rOir021933; Thu, 20 Sep 2007 06:53:28 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 23:53:28 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Sep 2007 23:53:28 -0700 From: "Sri Gundavelli" To: References: <001201c7fb45$48806e00$d5f6200a@amer.cisco.com> <006101c7fb4e$d44e2360$a864a8c0@china.huawei.com> Subject: RE: [netlmm] Comments on I-D Action:draft-ietf-netlmm-proxymip6-05.txt Date: Wed, 19 Sep 2007 23:53:27 -0700 Message-ID: <002b01c7fb52$f2b55a90$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <006101c7fb4e$d44e2360$a864a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf7TuKJMXDnX9wVSM29PosSQhyaVgAAMWFA X-OriginalArrivalTime: 20 Sep 2007 06:53:28.0478 (UTC) FILETIME=[F2EBD3E0:01C7FB52] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2238; t=1190271208; x=1191135208; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Comments=20on=20=20I-D=20Action=3Adraft-ie tf-netlmm-proxymip6-05.txt |Sender:=20; bh=NkpkKagAvtb6YsxZFDQ4D3n690m64kcJ0WgE+V1tAUk=; b=Ut/S2EyU3dqBXfe+ZY6C4S6yeZ3mJfTBtxpjYyLBcr4rcHwnnqbQ8ha8/h98QVYC67GWjtV7 QUlkll3OJNfxA3LSyvC5ZFS7SIAvIicaA9I9BTfZ4/KvpUFEMYj9r6BV; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi John, > > > -----Original Message----- > > > > > 1) About the resource cleanup problem . > > If the mobile does a DHCP release, it does not require the MAG > > to release the prefix. MAG ensures the mobile node believes its > > on its home link, as long as the node is attached to the link. > > The MN may have released the DHCP address, but may have chosen > > to use an autoconfigured address. So, we cant depend on this > > event. I've already listed some possibilities in a generic way > > and I think, the above points are sufficient. I cant think of any > > other event that a normal 2461 compatible IPv6 host can send and > > that the MAG can use for detachment detection. So, I dont see the > > point. > > > [John.zhao] Exactly, we can't depend on this event if a MS use an > autoconfigured address. That is the current situation. But if > we need is the > first problem If thus, then we can design some patch for this problem > Otherwise, it can't be use even we have some new method. So I > only suggest > we can open this door at here for the consideration in the > future. After all > , that is useful for network resource cleanup. And I won't involve the > discussion of new method. The requirement is enough. How do you think? > > > > No. It may be extended in the future, currently there is no such event. I dont think, its that simple to rely on such event. The host may die and the stack may not even generatet that event. Also, I dont think we need to open doors in this draft to allow some future work. Having that text does not mean any thing to the future work. If the use case is valid, you can justify it any day. The draft may generally point to some very obvious approaches, such as CT, ..etc that are out of scope for this document, but when such support is there in a given system architecture, Ex: R4 interface, it may be worth pointing it out, but its not for enabling some future work. In this case, we dont even know a solution that works and so we dont need to refer to that approach. But, I agree with you, such an event will be very useful, if that exists. Thanks for reviewing the draft. I will look into your other comments. Regards Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 04:56:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYHp6-00065y-92; Thu, 20 Sep 2007 04:55:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYHp4-00062j-R2 for netlmm@ietf.org; Thu, 20 Sep 2007 04:55:46 -0400 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYHp4-0007ti-9F for netlmm@ietf.org; Thu, 20 Sep 2007 04:55:46 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IYHov2jH5-0007IH; Thu, 20 Sep 2007 04:55:43 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" , "'Chowdhury, Kuntal'" Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 11:55:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf7AiyX2hrcxSfHTeyI8yT2X4ZknQAYcI4w In-Reply-To: <46F19159.7080903@gmail.com> Message-Id: <0MKpCa-1IYHov2jH5-0007IH@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19Qv90sEGuLPJkwqJHQ/7DlC5vhQmJZroJHvgk AIhZaSajOrkwUci47rXulRyAyX45N/2Zazkzp4lp086cEYWrxo n3Uf2cAt5WJ9mU4YX54UQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex, In WiMAX, MS uses DHCP. Alper > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, September 20, 2007 12:15 AM > To: Chowdhury, Kuntal > Cc: Alper Yegin; netlmm@ietf.org; Julien Laganier > Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO > > Chowdhury, Kuntal wrote: > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Wednesday, September 19, 2007 10:01 AM > >> To: Alper Yegin > >> Cc: netlmm@ietf.org; 'Julien Laganier' > >> Subject: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO > >> > >> Alper Yegin wrote: > >>>>> There are alternative approaches. Different DHCP servers (e.g., > >>>>> ones collocated with the MAGs) can be used as long as they can be > >>>>> dynamically-provisioned with the MN configuration parameters, > >>>>> for example, during network access authentication. > >>>> What's 'dynamically-provisioned'? Is it a SDO-specific mechanism? > >>>> I don't know how a deployer would like to deploy a DHCP Server in > >>>> each MAG without mentioning how these pools of addresses are > >>>> dynamically provisioned. > >>> It's typically done via AAA. For example, sending Framed-IP-Address > >>> via RADIUS is for configuring that IP address via DHCP (or PPP). > >> Any deployed system today with wireless point-to-point links using > >> Framed-IP-Address via RADIUS gives that IP address to mobile with > > DHCP? > >> I thought all are PPP. > >> > >> I've framed my mind to think that if wireless access link is > >> point-to-point then it's PPP, and if it's shared medium wifi then it's > >> DHCP; never otherwise. > >> > > [KC>] Nope...there are p2p wireless access links (3GPP, WiMAX) out there > > where PPP is not used. > > Ok. And on these links (3GPP, WiMAX) is DHCP used by the mobile? > Because on GPRS and UMTS the mobile doesn't use DHCP. > > Alex > > > > >> Alex > >> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. > Any review, retransmission, dissemination or other use of, or taking of > any action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not > the intended recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this message > and any attachments without reading or disclosing their contents. Thank > you." > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 05:12:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYI4o-0001OL-Q5; Thu, 20 Sep 2007 05:12:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYI4n-0001Nt-52 for netlmm@ietf.org; Thu, 20 Sep 2007 05:12:01 -0400 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYI4g-00079o-To for netlmm@ietf.org; Thu, 20 Sep 2007 05:12:01 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IYI3l1CUU-0008Rk; Thu, 20 Sep 2007 05:11:02 -0400 From: "Alper Yegin" To: "'Julien Laganier'" Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Comments ondraft-05) Date: Thu, 20 Sep 2007 12:10:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/Sdg In-Reply-To: <200709191730.18120.julien.IETF@laposte.net> Message-Id: <0MKp8S-1IYI3l1CUU-0008Rk@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/MP4Ev2PbWvC4J23qnnQfVnsAa5SPOWBASUtT rfvgFhGAZLK4w1J5gto9x6DzQVntLKGH1YK1REfTEYkqW/EufZ 5fArotMhZULBVxUiq+uSg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien, > > You mean "we haven't defined how to do that in IETF?" I agree. > > Good. > > > But that does not mean it is not doable, especially outside the scope > > of IETF. > > Then shouldn't we add some guidance text to DHCPv6 deployers explaining > that unless such out-of-scope mechanism is present some limitations are > placed on DHCPv6 deployments: DHCPv6 relays have to be present at each > MAG, and configured to forward DHCPv6 messages to the same group of > DHCPv6 servers (and implicitly that the group of DHCPv6 servers should > be reachable from every relay). > > What do you think? As long as we present such text as "informational", that's fine (no MUST/SHOULD/etc.). And yes, that text is useful. Alper _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 05:28:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIKD-0001kv-Mp; Thu, 20 Sep 2007 05:27:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIKC-0001kq-VW for netlmm@ietf.org; Thu, 20 Sep 2007 05:27:56 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYIK7-0007Th-Mz for netlmm@ietf.org; Thu, 20 Sep 2007 05:27:56 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1190280445!19102378!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5958 invoked from network); 20 Sep 2007 09:27:25 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 20 Sep 2007 09:27:25 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8K9RPBm004179; Thu, 20 Sep 2007 02:27:25 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l8K9RO0m021152; Thu, 20 Sep 2007 04:27:24 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8K9RMkJ021079; Thu, 20 Sep 2007 04:27:23 -0500 (CDT) Message-ID: <46F23CF5.2090209@gmail.com> Date: Thu, 20 Sep 2007 11:27:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <0MKpCa-1IYHov2jH5-0007IH@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IYHov2jH5-0007IH@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Alex, > > In WiMAX, MS uses DHCP. If so, I'm afraid it's the only one using DHCP over ptp links(?), because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and don't use DHCP over them. Or otherwise if WiMax MS uses DHCP then it is over ETHCS and not over the ptp IPCS link, right? Alex > > Alper > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, September 20, >> 2007 12:15 AM To: Chowdhury, Kuntal Cc: Alper Yegin; >> netlmm@ietf.org; Julien Laganier Subject: Re: [netlmm] Re: DHCPv6 >> deployment in PMIPv6 domain and SDO >> >> Chowdhury, Kuntal wrote: >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, >>>> September 19, 2007 10:01 AM To: Alper Yegin Cc: >>>> netlmm@ietf.org; 'Julien Laganier' Subject: [netlmm] Re: DHCPv6 >>>> deployment in PMIPv6 domain and SDO >>>> >>>> Alper Yegin wrote: >>>>>>> There are alternative approaches. Different DHCP servers >>>>>>> (e.g., ones collocated with the MAGs) can be used as long >>>>>>> as they can be dynamically-provisioned with the MN >>>>>>> configuration parameters, for example, during network >>>>>>> access authentication. >>>>>> What's 'dynamically-provisioned'? Is it a SDO-specific >>>>>> mechanism? I don't know how a deployer would like to deploy >>>>>> a DHCP Server in each MAG without mentioning how these >>>>>> pools of addresses are dynamically provisioned. >>>>> It's typically done via AAA. For example, sending >>>>> Framed-IP-Address via RADIUS is for configuring that IP >>>>> address via DHCP (or PPP). >>>> Any deployed system today with wireless point-to-point links >>>> using Framed-IP-Address via RADIUS gives that IP address to >>>> mobile with >>> DHCP? >>>> I thought all are PPP. >>>> >>>> I've framed my mind to think that if wireless access link is >>>> point-to-point then it's PPP, and if it's shared medium wifi >>>> then it's DHCP; never otherwise. >>>> >>> [KC>] Nope...there are p2p wireless access links (3GPP, WiMAX) >>> out there where PPP is not used. >> Ok. And on these links (3GPP, WiMAX) is DHCP used by the mobile? >> Because on GPRS and UMTS the mobile doesn't use DHCP. >> >> Alex >> >>>> Alex >>>> >>>> >>>> ______________________________________________________________________ >>>> This email has been scanned by the MessageLabs Email Security >>>> System. For more information please visit >>>> http://www.messagelabs.com/email >>>> ______________________________________________________________________ >>>> >>>> >>>> _______________________________________________ netlmm mailing >>>> list netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >>> "This email message and any attachments are confidential >>> information of >> Starent Networks, Corp. The information transmitted may not be used >> to create or change any contractual obligations of Starent >> Networks, Corp. Any review, retransmission, dissemination or other >> use of, or taking of any action in reliance upon this e-mail and >> its attachments by persons or entities other than the intended >> recipient is prohibited. If you are not the intended recipient, >> please notify the sender immediately -- by replying to this message >> or by sending an email to postmaster@starentnetworks.com -- and >> destroy all copies of this message and any attachments without >> reading or disclosing their contents. Thank you." >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 05:49:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIfJ-0004fE-4u; Thu, 20 Sep 2007 05:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIfI-0004ez-2d for netlmm@ietf.org; Thu, 20 Sep 2007 05:49:44 -0400 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYIfF-0007ui-Na for netlmm@ietf.org; Thu, 20 Sep 2007 05:49:44 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IYIf02HBx-0008Qe; Thu, 20 Sep 2007 05:49:33 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 12:49:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf7aHTpEmc3JywLRIeHXAxkv/9WcwAAsqjQ In-Reply-To: <46F23CF5.2090209@gmail.com> Message-Id: <0MKp8S-1IYIf02HBx-0008Qe@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/esKR6leX7std3gBi66AICysTYtmakwdI57Mz Myf557wZwNYXZ1Z4Dg4bfQ3057LQSQoeBEgFPSEFLA4/AcNSmk /SpJhlag7/aakUwQKQbGg== X-Spam-Score: -0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > If so, I'm afraid it's the only one using DHCP over ptp links(?), > because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and don't use DHCP > over them. Sorry I lost track of why this matters, even if that were the case. > Or otherwise if WiMax MS uses DHCP then it is over ETHCS and not over > the ptp IPCS link, right? No. WiMAX architecture also supports DHCP over IPCS. Alper > > Alex > > > > > Alper > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, September 20, > >> 2007 12:15 AM To: Chowdhury, Kuntal Cc: Alper Yegin; > >> netlmm@ietf.org; Julien Laganier Subject: Re: [netlmm] Re: DHCPv6 > >> deployment in PMIPv6 domain and SDO > >> > >> Chowdhury, Kuntal wrote: > >>>> -----Original Message----- From: Alexandru Petrescu > >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, > >>>> September 19, 2007 10:01 AM To: Alper Yegin Cc: > >>>> netlmm@ietf.org; 'Julien Laganier' Subject: [netlmm] Re: DHCPv6 > >>>> deployment in PMIPv6 domain and SDO > >>>> > >>>> Alper Yegin wrote: > >>>>>>> There are alternative approaches. Different DHCP servers > >>>>>>> (e.g., ones collocated with the MAGs) can be used as long > >>>>>>> as they can be dynamically-provisioned with the MN > >>>>>>> configuration parameters, for example, during network > >>>>>>> access authentication. > >>>>>> What's 'dynamically-provisioned'? Is it a SDO-specific > >>>>>> mechanism? I don't know how a deployer would like to deploy > >>>>>> a DHCP Server in each MAG without mentioning how these > >>>>>> pools of addresses are dynamically provisioned. > >>>>> It's typically done via AAA. For example, sending > >>>>> Framed-IP-Address via RADIUS is for configuring that IP > >>>>> address via DHCP (or PPP). > >>>> Any deployed system today with wireless point-to-point links > >>>> using Framed-IP-Address via RADIUS gives that IP address to > >>>> mobile with > >>> DHCP? > >>>> I thought all are PPP. > >>>> > >>>> I've framed my mind to think that if wireless access link is > >>>> point-to-point then it's PPP, and if it's shared medium wifi > >>>> then it's DHCP; never otherwise. > >>>> > >>> [KC>] Nope...there are p2p wireless access links (3GPP, WiMAX) > >>> out there where PPP is not used. > >> Ok. And on these links (3GPP, WiMAX) is DHCP used by the mobile? > >> Because on GPRS and UMTS the mobile doesn't use DHCP. > >> > >> Alex > >> > >>>> Alex > >>>> > >>>> > >>>> > ______________________________________________________________________ > >>>> This email has been scanned by the MessageLabs Email Security > >>>> System. For more information please visit > >>>> http://www.messagelabs.com/email > >>>> > ______________________________________________________________________ > >>>> > >>>> > >>>> _______________________________________________ netlmm mailing > >>>> list netlmm@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > >>> "This email message and any attachments are confidential > >>> information of > >> Starent Networks, Corp. The information transmitted may not be used > >> to create or change any contractual obligations of Starent > >> Networks, Corp. Any review, retransmission, dissemination or other > >> use of, or taking of any action in reliance upon this e-mail and > >> its attachments by persons or entities other than the intended > >> recipient is prohibited. If you are not the intended recipient, > >> please notify the sender immediately -- by replying to this message > >> or by sending an email to postmaster@starentnetworks.com -- and > >> destroy all copies of this message and any attachments without > >> reading or disclosing their contents. Thank you." > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security > >> System. For more information please visit > >> http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 06:09:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIxk-0001jp-HK; Thu, 20 Sep 2007 06:08:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIxi-0001hC-Je for netlmm@ietf.org; Thu, 20 Sep 2007 06:08:46 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYIxi-00010F-4q for netlmm@ietf.org; Thu, 20 Sep 2007 06:08:46 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1190282924!9046826!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 21934 invoked from network); 20 Sep 2007 10:08:44 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-14.tower-153.messagelabs.com with SMTP; 20 Sep 2007 10:08:44 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l8KA8ejQ007202; Thu, 20 Sep 2007 03:08:40 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l8KA8crl025583; Thu, 20 Sep 2007 05:08:39 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8KA8ZGg025491; Thu, 20 Sep 2007 05:08:36 -0500 (CDT) Message-ID: <46F2469E.1010405@gmail.com> Date: Thu, 20 Sep 2007 12:08:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <0MKp8S-1IYIf02HBx-0008Qe@mrelay.perfora.net> In-Reply-To: <0MKp8S-1IYIf02HBx-0008Qe@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: >> If so, I'm afraid it's the only one using DHCP over ptp links(?), >> because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and don't use >> DHCP over them. > > Sorry I lost track of why this matters, even if that were the case. Doing DHCP support for P-MIPv6 without knowing why we do it, and without requirements - is senseless. The original topic is whether to suggest that MAG should be a DHCPv6 Relay or not suggest so. But does the MN need DHCPv6? Other than WiMax will any other MN run DHCPv6 over a ptp wireless access link? Is this PMIPv6 only for WiMax? >> Or otherwise if WiMax MS uses DHCP then it is over ETHCS and not >> over the ptp IPCS link, right? > > No. WiMAX architecture also supports DHCP over IPCS. This is nonsense. I keep asking for requirements: why do we need DHCP support for P-MIPv6? And you keep telling me a certain SDO can support everything, this is deceiving. I know many other SDOs who'll also support everything. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 06:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJ2g-0002X4-3U; Thu, 20 Sep 2007 06:13:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJ2e-0002UU-Bg for netlmm@ietf.org; Thu, 20 Sep 2007 06:13:52 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYJ2d-00016N-9Y for netlmm@ietf.org; Thu, 20 Sep 2007 06:13:52 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8KAD6dV002109; Thu, 20 Sep 2007 12:13:06 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 20 Sep 2007 12:13:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 12:13:39 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A8F@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <0MKp8S-1IYIf02HBx-0008Qe@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Thread-Index: Acf7aHTpEmc3JywLRIeHXAxkv/9WcwAAsqjQAACiqjA= References: <46F23CF5.2090209@gmail.com> <0MKp8S-1IYIf02HBx-0008Qe@mrelay.perfora.net> From: "DE JUAN HUARTE FEDERICO" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Sep 2007 10:13:45.0445 (UTC) FILETIME=[ED977950:01C7FB6E] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, I would add that also wireline access (a point-point access link by = definition, e.g. DSL) supports DHCP as an alternative to PPP Regarding 3GPP family, it can also be envisaged that they'll move to = DHCP What matters is that we can not assume PPP only in point-to-point access = links (wireless or not) The protocol used for address assignment and IP hootstrapping is a = deployment choice DHCP is (arguably) the best choice if you don't want to put this = functionality in L2 Regards federico -----Message d'origine----- De : Alper Yegin [mailto:alper.yegin@yegin.org]=20 Envoy=E9 : jeudi 20 septembre 2007 11:49 =C0 : 'Alexandru Petrescu' Cc : netlmm@ietf.org; 'Julien Laganier' Objet : RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO > If so, I'm afraid it's the only one using DHCP over ptp links(?),=20 > because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and don't use DHCP=20 > over them. Sorry I lost track of why this matters, even if that were the case. > Or otherwise if WiMax MS uses DHCP then it is over ETHCS and not over=20 > the ptp IPCS link, right? No. WiMAX architecture also supports DHCP over IPCS.=20 Alper >=20 > Alex >=20 > > > > Alper > > > >> -----Original Message----- From: Alexandru Petrescu=20 > >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, September 20, > >> 2007 12:15 AM To: Chowdhury, Kuntal Cc: Alper Yegin;=20 > >> netlmm@ietf.org; Julien Laganier Subject: Re: [netlmm] Re: DHCPv6=20 > >> deployment in PMIPv6 domain and SDO > >> > >> Chowdhury, Kuntal wrote: > >>>> -----Original Message----- From: Alexandru Petrescu=20 > >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, September=20 > >>>> 19, 2007 10:01 AM To: Alper Yegin Cc: > >>>> netlmm@ietf.org; 'Julien Laganier' Subject: [netlmm] Re: DHCPv6=20 > >>>> deployment in PMIPv6 domain and SDO > >>>> > >>>> Alper Yegin wrote: > >>>>>>> There are alternative approaches. Different DHCP servers=20 > >>>>>>> (e.g., ones collocated with the MAGs) can be used as long as=20 > >>>>>>> they can be dynamically-provisioned with the MN configuration=20 > >>>>>>> parameters, for example, during network access authentication. > >>>>>> What's 'dynamically-provisioned'? Is it a SDO-specific=20 > >>>>>> mechanism? I don't know how a deployer would like to deploy a=20 > >>>>>> DHCP Server in each MAG without mentioning how these pools of=20 > >>>>>> addresses are dynamically provisioned. > >>>>> It's typically done via AAA. For example, sending=20 > >>>>> Framed-IP-Address via RADIUS is for configuring that IP address=20 > >>>>> via DHCP (or PPP). > >>>> Any deployed system today with wireless point-to-point links=20 > >>>> using Framed-IP-Address via RADIUS gives that IP address to=20 > >>>> mobile with > >>> DHCP? > >>>> I thought all are PPP. > >>>> > >>>> I've framed my mind to think that if wireless access link is=20 > >>>> point-to-point then it's PPP, and if it's shared medium wifi then = > >>>> it's DHCP; never otherwise. > >>>> > >>> [KC>] Nope...there are p2p wireless access links (3GPP, WiMAX) out = > >>> there where PPP is not used. > >> Ok. And on these links (3GPP, WiMAX) is DHCP used by the mobile? > >> Because on GPRS and UMTS the mobile doesn't use DHCP. > >> > >> Alex > >> > >>>> Alex > >>>> > >>>> > >>>> > ______________________________________________________________________ > >>>> This email has been scanned by the MessageLabs Email Security=20 > >>>> System. For more information please visit=20 > >>>> http://www.messagelabs.com/email > >>>> > ______________________________________________________________________ > >>>> > >>>> > >>>> _______________________________________________ netlmm mailing=20 > >>>> list netlmm@ietf.org=20 > >>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > >>> "This email message and any attachments are confidential=20 > >>> information of > >> Starent Networks, Corp. The information transmitted may not be used = > >> to create or change any contractual obligations of Starent=20 > >> Networks, Corp. Any review, retransmission, dissemination or other=20 > >> use of, or taking of any action in reliance upon this e-mail and=20 > >> its attachments by persons or entities other than the intended=20 > >> recipient is prohibited. If you are not the intended recipient,=20 > >> please notify the sender immediately -- by replying to this message = > >> or by sending an email to postmaster@starentnetworks.com -- and=20 > >> destroy all copies of this message and any attachments without=20 > >> reading or disclosing their contents. Thank you." > >> > >> ___________________________________________________________________ > >> ___ This email has been scanned by the MessageLabs Email Security=20 > >> System. For more information please visit=20 > >> http://www.messagelabs.com/email=20 > >> ___________________________________________________________________ > >> ___ > >> > > > > >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 06:29:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJHb-0003Ec-U3; Thu, 20 Sep 2007 06:29:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJHa-0003DR-JK for netlmm@ietf.org; Thu, 20 Sep 2007 06:29:18 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYJHZ-0000U1-BH for netlmm@ietf.org; Thu, 20 Sep 2007 06:29:18 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IYJHG03Hn-0007IL; Thu, 20 Sep 2007 06:29:04 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 13:28:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf7bjsbHxopYYvxTEy/sv+Pckvp/QAAif5A In-Reply-To: <46F2469E.1010405@gmail.com> Message-Id: <0MKpCa-1IYJHG03Hn-0007IL@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19r7a88iFcV2mnbiPJ77Uk15j1FmYD/oFff0BS mPlx9uWc7uAB42z2hyjQhacCJuj0NIY+r0xHbaBqQ3clSHFhy0 rzMsScQVcyN8nxL482Unw== X-Spam-Score: -0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex, > >> If so, I'm afraid it's the only one using DHCP over ptp links(?), > >> because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and don't use > >> DHCP over them. > > > > Sorry I lost track of why this matters, even if that were the case. > > Doing DHCP support for P-MIPv6 without knowing why we do it, and without > requirements - is senseless. WiFi uses it. WiMAX uses it. I've been told UMTS and LTE are also using DHCP. 3GPP2 evolution is dumping PPP, and will be using DHCP. DSL evolution is doing the same. > The original topic is whether to suggest that MAG should be a DHCPv6 > Relay or not suggest so. But does the MN need DHCPv6? Other than WiMax > will any other MN run DHCPv6 over a ptp wireless access link? Is this > PMIPv6 only for WiMax? > > >> Or otherwise if WiMax MS uses DHCP then it is over ETHCS and not > >> over the ptp IPCS link, right? > > > > No. WiMAX architecture also supports DHCP over IPCS. > > This is nonsense. What is nonsense? > I keep asking for requirements: why do we need DHCP support for P-MIPv6? See above for where DHCP is/will be used. > > And you keep telling me a certain SDO can support everything, this is > deceiving. I know many other SDOs who'll also support everything. What is the problem? What is your proposal? I'm lost..... Alper > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 06:41:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJT5-0003aD-Jw; Thu, 20 Sep 2007 06:41:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJT4-0003a6-AS for netlmm@ietf.org; Thu, 20 Sep 2007 06:41:10 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYJSy-0000sn-4s for netlmm@ietf.org; Thu, 20 Sep 2007 06:41:10 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1190284852!20214411!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24313 invoked from network); 20 Sep 2007 10:40:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 20 Sep 2007 10:40:52 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8KAeq7F021063; Thu, 20 Sep 2007 03:40:52 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l8KAepgr000218; Thu, 20 Sep 2007 05:40:51 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8KAen8h000138; Thu, 20 Sep 2007 05:40:50 -0500 (CDT) Message-ID: <46F24E2C.2030208@gmail.com> Date: Thu, 20 Sep 2007 12:40:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: DE JUAN HUARTE FEDERICO Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <46F23CF5.2090209@gmail.com> <0MKp8S-1IYIf02HBx-0008Qe@mrelay.perfora.net> <319D54578EAC3147BA8CC78DAB5467A501399A8F@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A8F@FRVELSMBS12.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org DE JUAN HUARTE FEDERICO wrote: > Hi Alex, > > I would add that also wireline access (a point-point access link by > definition, e.g. DSL) supports DHCP as an alternative to PPP > Regarding 3GPP family, it can also be envisaged that they'll move to > DHCP Ok, that's about DSL SDO, but that doesn't use PMIPv6, right? Because that doesn't need mobility, houses don't move, right? > What matters is that we can not assume PPP only in point-to-point > access links (wireless or not) The protocol used for address > assignment and IP hootstrapping is a deployment choice DHCP is > (arguably) the best choice if you don't want to put this > functionality in L2 In other discussions, people say that we can't assume PPP because 3GPP doesn't use PPP and it uses a link-layer protocol instead. Not because it uses DHCP, it's because it uses a link-layer protocol. Why do you think this address assignment functionality will move from the widely deployed L2 (be it ppp or other link-layer protocol)? Why do you call it 'best' choice? What mobile device can I buy today (wimax, 3g, cdma2000) that does wireless ptp link and runs dhcp over it? There isn't any AFAIK, all do ptp protocol (PPP or 3G or other) to assign addresses. That's why I'm thinking that speculating on the tendency to move to DHCP over the wireless ptp access is probably early. Alex > > Regards > > federico > > -----Message d'origine----- De : Alper Yegin > [mailto:alper.yegin@yegin.org] Envoyé : jeudi 20 septembre 2007 11:49 > À : 'Alexandru Petrescu' Cc : netlmm@ietf.org; 'Julien Laganier' > Objet : RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO > >> If so, I'm afraid it's the only one using DHCP over ptp links(?), >> because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and don't use >> DHCP over them. > > Sorry I lost track of why this matters, even if that were the case. > >> Or otherwise if WiMax MS uses DHCP then it is over ETHCS and not >> over the ptp IPCS link, right? > > No. WiMAX architecture also supports DHCP over IPCS. > > > Alper > > > >> Alex >> >>> Alper >>> >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, September >>>> 20, 2007 12:15 AM To: Chowdhury, Kuntal Cc: Alper Yegin; >>>> netlmm@ietf.org; Julien Laganier Subject: Re: [netlmm] Re: >>>> DHCPv6 deployment in PMIPv6 domain and SDO >>>> >>>> Chowdhury, Kuntal wrote: >>>>>> -----Original Message----- From: Alexandru Petrescu >>>>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, >>>>>> September 19, 2007 10:01 AM To: Alper Yegin Cc: >>>>>> netlmm@ietf.org; 'Julien Laganier' Subject: [netlmm] Re: >>>>>> DHCPv6 deployment in PMIPv6 domain and SDO >>>>>> >>>>>> Alper Yegin wrote: >>>>>>>>> There are alternative approaches. Different DHCP >>>>>>>>> servers (e.g., ones collocated with the MAGs) can be >>>>>>>>> used as long as they can be dynamically-provisioned >>>>>>>>> with the MN configuration parameters, for example, >>>>>>>>> during network access authentication. >>>>>>>> What's 'dynamically-provisioned'? Is it a SDO-specific >>>>>>>> mechanism? I don't know how a deployer would like to >>>>>>>> deploy a DHCP Server in each MAG without mentioning how >>>>>>>> these pools of addresses are dynamically provisioned. >>>>>>> It's typically done via AAA. For example, sending >>>>>>> Framed-IP-Address via RADIUS is for configuring that IP >>>>>>> address via DHCP (or PPP). >>>>>> Any deployed system today with wireless point-to-point >>>>>> links using Framed-IP-Address via RADIUS gives that IP >>>>>> address to mobile with >>>>> DHCP? >>>>>> I thought all are PPP. >>>>>> >>>>>> I've framed my mind to think that if wireless access link >>>>>> is point-to-point then it's PPP, and if it's shared medium >>>>>> wifi then it's DHCP; never otherwise. >>>>>> >>>>> [KC>] Nope...there are p2p wireless access links (3GPP, >>>>> WiMAX) out there where PPP is not used. >>>> Ok. And on these links (3GPP, WiMAX) is DHCP used by the >>>> mobile? Because on GPRS and UMTS the mobile doesn't use DHCP. >>>> >>>> Alex >>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> >> ______________________________________________________________________ >> >> >>>>>> This email has been scanned by the MessageLabs Email >>>>>> Security System. For more information please visit >>>>>> http://www.messagelabs.com/email >>>>>> >> ______________________________________________________________________ >> >> >>>>>> >>>>>> _______________________________________________ netlmm >>>>>> mailing list netlmm@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>> "This email message and any attachments are confidential >>>>> information of >>>> Starent Networks, Corp. The information transmitted may not be >>>> used to create or change any contractual obligations of Starent >>>> Networks, Corp. Any review, retransmission, dissemination or >>>> other use of, or taking of any action in reliance upon this >>>> e-mail and its attachments by persons or entities other than >>>> the intended recipient is prohibited. If you are not the >>>> intended recipient, please notify the sender immediately -- by >>>> replying to this message or by sending an email to >>>> postmaster@starentnetworks.com -- and destroy all copies of >>>> this message and any attachments without reading or disclosing >>>> their contents. Thank you." >>>> >>>> ___________________________________________________________________ >>>> ___ This email has been scanned by the MessageLabs Email >>>> Security System. For more information please visit >>>> http://www.messagelabs.com/email >>>> ___________________________________________________________________ >>>> ___ >>>> >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > > > _______________________________________________ netlmm mailing list > netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 06:46:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJXe-0006Zw-Nw; Thu, 20 Sep 2007 06:45:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYJXe-0006Zp-34 for netlmm@ietf.org; Thu, 20 Sep 2007 06:45:54 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYJXd-0001wZ-IE for netlmm@ietf.org; Thu, 20 Sep 2007 06:45:53 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1190285152!4160145!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 6678 invoked from network); 20 Sep 2007 10:45:52 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-12.tower-153.messagelabs.com with SMTP; 20 Sep 2007 10:45:52 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l8KAjlfv013084; Thu, 20 Sep 2007 03:45:47 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8KAjkU0018203; Thu, 20 Sep 2007 05:45:46 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8KAjhdx018133; Thu, 20 Sep 2007 05:45:44 -0500 (CDT) Message-ID: <46F24F51.4040500@gmail.com> Date: Thu, 20 Sep 2007 12:45:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <0MKpCa-1IYJHG03Hn-0007IL@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IYJHG03Hn-0007IL@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Alex, > >>>> If so, I'm afraid it's the only one using DHCP over ptp >>>> links(?), because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and >>>> don't use DHCP over them. >>> Sorry I lost track of why this matters, even if that were the >>> case. >> Doing DHCP support for P-MIPv6 without knowing why we do it, and >> without requirements - is senseless. > > WiFi uses it. WiFi hotspots - yes. That's PMIPv6 for wireless shared access. > WiMAX uses it. HAven't seen it, but you may have. > I've been told UMTS and LTE are also using DHCP. Well let me tell you UMTS doesn't. Who told you UMTS uses DHCP on the mobile? > 3GPP2 evolution is dumping PPP, and will be using DHCP. That's surprising... so you mean my next mobile phone will use DHCP? BEcause the current 3G and UMTS phones I'm using don't run DHCP on the wireless ptp access (they do on wifi). Do you realize how much change in the infrastructure that assumes? Isn't this another speculation just like the one of a few years ago saying that 3G will run IPv6? > DSL evolution is doing the same. DSL is not relevant here because DSL doesn't need PMIPv6 because nothing moves with DSL deployments. To me all this list boils down to doing DHCPv6 in PMIPv6 only for wireless shared access (and not for ptp links). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 07:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYK3A-0000pp-PY; Thu, 20 Sep 2007 07:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYK39-0000dA-Ev for netlmm@ietf.org; Thu, 20 Sep 2007 07:18:27 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYK2z-0001rU-8V for netlmm@ietf.org; Thu, 20 Sep 2007 07:18:23 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1216996uge for ; Thu, 20 Sep 2007 04:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=dFbCH/oONJtAWRIe+FS9Ot1anecf0/TgDJoopRlUIfQ=; b=VHU9zsCyGPolmqPUo2u9VdvSmVO/MUGf113mf8VIehfmFIr17SB/14JM7i+ArOoN5+FpetgAPnWbG/sqO8HQY7QnqBBTMTIWdJ205dirKtE3XX75OUTYEvQD1LO0Xl347Hfc+0YfxPz+Fr46Pyzsc6/ZsoUuacY1DAzi4ENdTPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=p/reM3eQQhmeVyQTouJuiTu5KfawER4xV4kYsjHROck3HNo24h51Fw2rZ3il4LmGuo8y2o4w3Yk7K2vl2vwnxbKD0IZikoxK9e7nbxRED46Tpm192JJU+gb5HJVsAcRHZde/OTjHYVPVJAypn48uXEzuqGf0506dthrJDgOwpeQ= Received: by 10.66.248.5 with SMTP id v5mr3108947ugh.1190287076388; Thu, 20 Sep 2007 04:17:56 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id e33sm5318609ugd.2007.09.20.04.17.54 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2007 04:17:55 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Date: Thu, 20 Sep 2007 13:17:51 +0200 User-Agent: KMail/1.9.6 References: <0MKpCa-1IY0qi3Fw9-0007Ui@mrelay.perfora.net> <46F139BD.3050002@gmail.com> In-Reply-To: <46F139BD.3050002@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709201317.51298.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: netlmm@ietf.org Subject: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex, On Wednesday 19 September 2007, Alexandru Petrescu wrote: > Alper Yegin wrote: > >>> There are alternative approaches. Different DHCP servers (e.g., > >>> ones collocated with the MAGs) can be used as long as they can be > >>> dynamically-provisioned with the MN configuration parameters, > >>> for example, during network access authentication. > >> > >> What's 'dynamically-provisioned'? Is it a SDO-specific mechanism? > >> I don't know how a deployer would like to deploy a DHCP Server in > >> each MAG without mentioning how these pools of addresses are > >> dynamically provisioned. > > > > It's typically done via AAA. For example, sending Framed-IP-Address > > via RADIUS is for configuring that IP address via DHCP (or PPP). > > Any deployed system today with wireless point-to-point links using > Framed-IP-Address via RADIUS gives that IP address to mobile with > DHCP? I thought all are PPP. First of all, this question relates to system architecture. This list does not discuss specification of system architecture. Second, but that is only peripheral to the point above, if all of our needs were satisfied with what we have *today*, we would not need to be here arguing about specification of *future* systems. > I've framed my mind to think that if wireless access link is > point-to-point then it's PPP, and if it's shared medium wifi then > it's DHCP; never otherwise. Then unframe your mind :) More seriously, it is irrelevant to this forum what your tastes and beliefs about system architecture are since this forum is not specifying any system architecture. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 07:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYK2y-0000Tg-ES; Thu, 20 Sep 2007 07:18:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYK2v-0000LF-OA for netlmm@ietf.org; Thu, 20 Sep 2007 07:18:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYK2o-0003XS-Vb for netlmm@ietf.org; Thu, 20 Sep 2007 07:18:07 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1217041uge for ; Thu, 20 Sep 2007 04:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=is6I20DQas3DjpbeSMUsmHRtX48/TjmTCtR7kE+jeFM=; b=El3m/Fi5S1RW4BGekCir0RZSLyCHvzy6xcfc5uR9a6A79dAwvB4g2G9iBnenhMujc8LRXShMvBY2g2cjt/zjTj4Ux8K925SbVw424IZhYMYrAj7v+FN06C4IzJgKWuTt35kVvZ7mmtHVmw23CTFSdl4s2qxUcqVMAoqW+MaCdZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=XJo+CfOcgvYTCHnWY5gbQlX+N3cVhqAREwMt3qStlnMYfYQEHQJMHzqN2qnu7VlHUV/3qlcNEBP+K1vsspypEY6Pt7KY8Uj4x3EBx2FtHNx+lKdRrJqRlqRs4wvoP2tAMmncpbBPz73kb+gH0p3FH+BZzEiGnxpwhWyrhod4kN4= Received: by 10.66.221.6 with SMTP id t6mr3089759ugg.1190287085948; Thu, 20 Sep 2007 04:18:05 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id a1sm28950ugf.2007.09.20.04.18.04 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2007 04:18:05 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 13:18:02 +0200 User-Agent: KMail/1.9.6 References: <0MKp8S-1IYIf02HBx-0008Qe@mrelay.perfora.net> <46F2469E.1010405@gmail.com> In-Reply-To: <46F2469E.1010405@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709201318.02924.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Thursday 20 September 2007, Alexandru Petrescu wrote: > Alper Yegin wrote: > >> If so, I'm afraid it's the only one using DHCP over ptp links(?), > >> because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and don't use > >> DHCP over them. > > > > Sorry I lost track of why this matters, even if that were the case. > > Doing DHCP support for P-MIPv6 without knowing why we do it, and > without requirements - is senseless. It is none of our business to decide whether it makes sense or not for a MN in a PMIPv6 domain to use DHCP. We are specifying the PMIPv6 protocol. We are not specifying a MN software stack or a system architecture. What is senseless IMHO is the way that *thread* went. > The original topic is whether to suggest that MAG should be a DHCPv6 > Relay or not suggest so. The original topic was whether a PMIPv6 topic constrains DHCPv6 deployments, and whether that should be documented. > But does the MN need DHCPv6? That is none of our business. > Other than WiMax will any other MN run DHCPv6 over a ptp wireless > access link? It is irrelevant to this forum. > Is this PMIPv6 only for WiMax? Where did you get that from?! OTOH, your line of arguments seems to imply that DCHP is not needed for PMIPv6, thus that PMIPv6 is only for non-DHCP systems. This discussion is irrelevant to this forum, we should stop it. > >> Or otherwise if WiMax MS uses DHCP then it is over ETHCS and not > >> over the ptp IPCS link, right? > > > > No. WiMAX architecture also supports DHCP over IPCS. > > This is nonsense. Then go to the WiMAX forum and tell them. It's none of our business to judge what WiMAX decided. I am also concerned that such judgment can be seen as lack of respect for WiMAX. > I keep asking for requirements: why do we need DHCP support for > P-MIPv6? Again, it is not to NETLMM to decide how a MN will configure its addresses. DHCP is a standard track IETF specification, as such we in this working group should ensure that we do nothing that would prevent use of that standard track IETF specification. > And you keep telling me a certain SDO can support everything, this is > deceiving. I know many other SDOs who'll also support everything. Sigh, SDOs are none of our business. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 07:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYK4W-0001vq-PG; Thu, 20 Sep 2007 07:19:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYK4V-0001vX-Me for netlmm@ietf.org; Thu, 20 Sep 2007 07:19:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYK4T-0001tr-Jc for netlmm@ietf.org; Thu, 20 Sep 2007 07:19:51 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1217439uge for ; Thu, 20 Sep 2007 04:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=BJPf2kV78ts/LtoB6ETHt1/HRil/5AEx8mtHErq2kAg=; b=H5Cq1NDVnBiRsJkge3QPMmK/uE8w2Gsu0xbaH6pjiJnj9DOshdKRoLmf1PTr3KVR2jGdohDYy9FckO0D002RyCaebvtrBbmOzFuVj2rb/9uFrne6WkGIBuYvwjUdb4kyp5bSGI6o2OSpSQ7c9LDI9Kmoz8MDYVjI7ss3taR8UGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=a3Mn7H2iwX7o1pS17E7WJxI5eANe9CLh2VukiTAoErr6NR3ciuoILq1cQn0gLk+D/pQUgtmoFvfxKUXkX7DdqJnODFxQVh92B6svmHmST0p/UkGsprk4SPgPHM1wPDPTiy8OrxqXhYnfPYzQQDJLZC/VOqpGAVk2x2aB3wzjFjA= Received: by 10.67.15.17 with SMTP id s17mr940413ugi.1190287173727; Thu, 20 Sep 2007 04:19:33 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id k30sm11904ugc.2007.09.20.04.19.31 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2007 04:19:32 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 13:19:30 +0200 User-Agent: KMail/1.9.6 References: <46F23CF5.2090209@gmail.com> <319D54578EAC3147BA8CC78DAB5467A501399A8F@FRVELSMBS12.ad2.ad.alcatel.com> <46F24E2C.2030208@gmail.com> In-Reply-To: <46F24E2C.2030208@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709201319.30236.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Thursday 20 September 2007, Alexandru Petrescu wrote: > DE JUAN HUARTE FEDERICO wrote: > > Hi Alex, > > > > I would add that also wireline access (a point-point access link by > > definition, e.g. DSL) supports DHCP as an alternative to PPP > > Regarding 3GPP family, it can also be envisaged that they'll move > > to DHCP > > Ok, that's about DSL SDO, but that doesn't use PMIPv6, right? > Because that doesn't need mobility, houses don't move, right? > > > What matters is that we can not assume PPP only in point-to-point > > access links (wireless or not) The protocol used for address > > assignment and IP hootstrapping is a deployment choice DHCP is > > (arguably) the best choice if you don't want to put this > > functionality in L2 > > In other discussions, people say that we can't assume PPP because > 3GPP doesn't use PPP and it uses a link-layer protocol instead. Not > because it uses DHCP, it's because it uses a link-layer protocol. 3GPP will use DHCP, and that's not our business. As per our charter, the NETLMM protocol should be independent of specific link layers. > Why do you think this address assignment functionality will move from > the widely deployed L2 (be it ppp or other link-layer protocol)? Why > do you call it 'best' choice? That is out-of-scope for this list. > What mobile device can I buy today (wimax, 3g, cdma2000) that does > wireless ptp link and runs dhcp over it? There isn't any AFAIK, all > do ptp protocol (PPP or 3G or other) to assign addresses. That is out-of-scope for this list. > That's why I'm thinking that speculating on the tendency to move to > DHCP over the wireless ptp access is probably early. That is out-of-scope for this list. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 07:38:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKLg-0000QO-9d; Thu, 20 Sep 2007 07:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKLf-0000PZ-77 for netlmm@ietf.org; Thu, 20 Sep 2007 07:37:35 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYKLU-0002Dq-2H for netlmm@ietf.org; Thu, 20 Sep 2007 07:37:31 -0400 Received: by nf-out-0910.google.com with SMTP id d21so409297nfb for ; Thu, 20 Sep 2007 04:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=jJpMl2ikc83nOEbbm+6lABgJ+TlS38BfzQ/NIrAsmV8=; b=hFbFUj4yvhndCzevWKarZZjRDHx0uqB4NSrNu1IWbyOKZEvt8pG5UlAe+Vl3auSv29166dmf1Z8SuRirO8GPG1goG4r9LYXjMGSa7YvRuyq5smqyjBmT59MbqJxojRyEq4unAgskfF6oK2MQBJu0L1YtNo3CCnCwAt5lP+vdjAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FddJNxA1pMQlltGtQL3mbouu1lQQqHoyPgjL8BwJJymp1qP+DG5RpkLoOyxXfKLfVSrdom7t1xTUZnbwpmAAe/x9k2UDDuocW/VnLBvE1UUdidLTsF+nldLcFdJntCkLuLVg3Dy/g4FbmV55exMNUo3ylYDzo8B2fCmpGwVwijY= Received: by 10.78.37.7 with SMTP id k7mr1047321huk.1190288208615; Thu, 20 Sep 2007 04:36:48 -0700 (PDT) Received: by 10.78.158.5 with HTTP; Thu, 20 Sep 2007 04:36:48 -0700 (PDT) Message-ID: <92e919fb0709200436p5f5ead0bn8afde7fc616886a0@mail.gmail.com> Date: Thu, 20 Sep 2007 16:06:48 +0430 From: "JinHyeock Choi" To: "Christian Vogt" Subject: Re: [netlmm] Resolving Remaining Issues In-Reply-To: <46F21452.4070208@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46F21452.4070208@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: NetLMM Mailing List , Basavaraj Patil X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -------------------------------------------------------------------------- > > #155: Ordering of RA and PBU > > Thursday, April 19, 2007, 2:26:25 PM | christian.vogt@ericsson.com > > Clarify whether there should there be a pre-defined order in which a MAG > sends (i) a Router Advertisement message to a mobile node after link > attachment, and (ii) the Proxy Binding Update message to the LMA. > > This issue was raised by JinHyeock Choi on 2007/04/16. IMO, the issue has been resolved in Sec 6.7. > -------------------------------------------------------------------------- > > #152: Initial Attachment vs. Handover Procedures > > Thursday, April 19, 2007, 2:20:05 PM | christian.vogt@ericsson.com > > The procedures of initial network attachment and intra-PMIP6-domain > handover should be described separately in section 3 of the draft. > > This issue was raised by JinHyeock Choi on 2007/04/16. IMO, the issue has been resolved. PMIPv6 procedure is adequately described in Sec 3. Best Regards JinHyeock _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 08:15:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKw6-0001NK-68; Thu, 20 Sep 2007 08:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKw5-0001My-2B for netlmm@ietf.org; Thu, 20 Sep 2007 08:15:13 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYKvz-00037H-GA for netlmm@ietf.org; Thu, 20 Sep 2007 08:15:13 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1190290486!23786970!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 9647 invoked from network); 20 Sep 2007 12:14:46 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-15.tower-119.messagelabs.com with SMTP; 20 Sep 2007 12:14:46 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8KCEfLH019337; Thu, 20 Sep 2007 05:14:46 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8KCEeIm001498; Thu, 20 Sep 2007 07:14:40 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8KCEbEL001392; Thu, 20 Sep 2007 07:14:38 -0500 (CDT) Message-ID: <46F26427.8060007@gmail.com> Date: Thu, 20 Sep 2007 14:14:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier References: <0MKpCa-1IY0qi3Fw9-0007Ui@mrelay.perfora.net> <46F139BD.3050002@gmail.com> <200709201317.51298.julien.IETF@laposte.net> In-Reply-To: <200709201317.51298.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: netlmm@ietf.org Subject: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > Alex, > > On Wednesday 19 September 2007, Alexandru Petrescu wrote: >> Alper Yegin wrote: >>>>> There are alternative approaches. Different DHCP servers (e.g., >>>>> ones collocated with the MAGs) can be used as long as they can be >>>>> dynamically-provisioned with the MN configuration parameters, >>>>> for example, during network access authentication. >>>> What's 'dynamically-provisioned'? Is it a SDO-specific mechanism? >>>> I don't know how a deployer would like to deploy a DHCP Server in >>>> each MAG without mentioning how these pools of addresses are >>>> dynamically provisioned. >>> It's typically done via AAA. For example, sending Framed-IP-Address >>> via RADIUS is for configuring that IP address via DHCP (or PPP). >> Any deployed system today with wireless point-to-point links using >> Framed-IP-Address via RADIUS gives that IP address to mobile with >> DHCP? I thought all are PPP. > > First of all, this question relates to system architecture. This list > does not discuss specification of system architecture. I'm trying to deduce from the various deployed system architectures how the DHCP Relay can come into picture. You use the argument that we should use DHCP Relay on MAG because only one DHCP Server can allocate addresses. To which Alper says that 'pre-provisioning' can alleviate that restriction. I'd like to use other arguments in favor of your suggestion, but I can't seem to find one. If I wanted to stay in the SDO line of suggestion, I could very well say that a certain SDO _requires_ DHCP Relay on the access router, and a DHCP Proxy too. But that doesn't make much sense to say, even less to frame one's mind around. Because I'd like to see the DHCP Client running on a mobile's wman ptp link, before making claims about the future. You seem to have already seen this? > Second, but that is only peripheral to the point above, if all of our > needs were satisfied with what we have *today*, we would not need to be > here arguing about specification of *future* systems. Yes, but relying on the past to predict the future is also good. (Do you remember when people claimed that 3G will use IPv6? It's not long ago. Now 3G is here and w/o IPv6, except some test deployments.) >> I've framed my mind to think that if wireless access link is >> point-to-point then it's PPP, and if it's shared medium wifi then >> it's DHCP; never otherwise. > > Then unframe your mind :) I'd very much like to unframe half of my mind and play right now with a deployed mobile that uses DHCP on a ptp wireless access link. To avoid risking to look ridiculous to the other half :-) > More seriously, it is irrelevant to this forum what your tastes and > beliefs about system architecture are since this forum is not > specifying any system architecture. I think once we request DHCP presence on a PMIP entity we talk architecture. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 08:24:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYL4R-0007Xm-Kz; Thu, 20 Sep 2007 08:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYL4P-0007Vp-Vx for netlmm@ietf.org; Thu, 20 Sep 2007 08:23:49 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYL4O-0003KR-Of for netlmm@ietf.org; Thu, 20 Sep 2007 08:23:49 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1190291022!7357916!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 27337 invoked from network); 20 Sep 2007 12:23:42 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-7.tower-153.messagelabs.com with SMTP; 20 Sep 2007 12:23:42 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l8KCNgxA018782; Thu, 20 Sep 2007 05:23:42 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l8KCNfLh019358; Thu, 20 Sep 2007 07:23:41 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8KCNZ2n019238; Thu, 20 Sep 2007 07:23:37 -0500 (CDT) Message-ID: <46F26640.2090300@gmail.com> Date: Thu, 20 Sep 2007 14:23:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <0MKpCa-1IYJHG03Hn-0007IL@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IYJHG03Hn-0007IL@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: [...] >> And you keep telling me a certain SDO can support everything, this >> is deceiving. I know many other SDOs who'll also support >> everything. > > What is the problem? What is your proposal? I'm lost..... The problem is that you guys talk DHCP for PMIPv6 because you think a certain SDO might require it in the future. The problem is also that you guys don't rely on prototyping or deployment experience when you request/reject DHCP presence; you only rely your claims on what other SDOs want or might want. The proposal is to talk a little more implementation and/or prototyping and see from these experiences how DHCP can fit in. Is there a prototyping or full deployment experience with a MS using DHCP over a ptp wireless access link? (not DSL, not wifi hotspot). Because if there isn't, then I don't think we can mandate DHCP in any way in PMIPv6. Alex > > Alper > > > > > >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 08:34:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLEb-0000SS-KH; Thu, 20 Sep 2007 08:34:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLEb-0000SM-0K for netlmm@ietf.org; Thu, 20 Sep 2007 08:34:21 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYLEZ-0003Zy-Rn for netlmm@ietf.org; Thu, 20 Sep 2007 08:34:20 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1190291654!33847088!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13661 invoked from network); 20 Sep 2007 12:34:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 20 Sep 2007 12:34:14 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8KCY9Bh018060; Thu, 20 Sep 2007 05:34:09 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l8KCY8i5008976; Thu, 20 Sep 2007 07:34:08 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8KCY6DT008930; Thu, 20 Sep 2007 07:34:06 -0500 (CDT) Message-ID: <46F268B8.7050809@gmail.com> Date: Thu, 20 Sep 2007 14:34:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <46F23CF5.2090209@gmail.com> <319D54578EAC3147BA8CC78DAB5467A501399A8F@FRVELSMBS12.ad2.ad.alcatel.com> <46F24E2C.2030208@gmail.com> <200709201319.30236.julien.IETF@laposte.net> In-Reply-To: <200709201319.30236.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > On Thursday 20 September 2007, Alexandru Petrescu wrote: >> DE JUAN HUARTE FEDERICO wrote: >>> Hi Alex, >>> >>> I would add that also wireline access (a point-point access link by >>> definition, e.g. DSL) supports DHCP as an alternative to PPP >>> Regarding 3GPP family, it can also be envisaged that they'll move >>> to DHCP >> Ok, that's about DSL SDO, but that doesn't use PMIPv6, right? >> Because that doesn't need mobility, houses don't move, right? >> >>> What matters is that we can not assume PPP only in point-to-point >>> access links (wireless or not) The protocol used for address >>> assignment and IP hootstrapping is a deployment choice DHCP is >>> (arguably) the best choice if you don't want to put this >>> functionality in L2 >> In other discussions, people say that we can't assume PPP because >> 3GPP doesn't use PPP and it uses a link-layer protocol instead. Not >> because it uses DHCP, it's because it uses a link-layer protocol. > > 3GPP will use DHCP, and that's not our business. Because you think 3GPP will no longer use PDP-Context setup? What happens to all mobiles who set up PDP-contexts? > As per our charter, the NETLMM protocol should be independent of > specific link layers. I think that's good. But I also think the current P-MIPv6 draft v05 says this: > 6.3. Supported Access Link Types > > This specification supports only point-to-point access link types and > thus it assumes that the mobile node and the mobile access gateway > are the only two nodes on the access link. So we have two problems here: (1) P-MIPv6 is not agreeing with the Charter and (2) absent experience of DHCP over a MS's wireless ptp link we can't request DHCP Relay on the MAG, it's too far-fetched, too much speculation IMHO. >> Why do you think this address assignment functionality will move from >> the widely deployed L2 (be it ppp or other link-layer protocol)? Why >> do you call it 'best' choice? > > That is out-of-scope for this list. > >> What mobile device can I buy today (wimax, 3g, cdma2000) that does >> wireless ptp link and runs dhcp over it? There isn't any AFAIK, all >> do ptp protocol (PPP or 3G or other) to assign addresses. > > That is out-of-scope for this list. > >> That's why I'm thinking that speculating on the tendency to move to >> DHCP over the wireless ptp access is probably early. > > That is out-of-scope for this list. Rather ok for all three, let's focus on how can we require DHCP in the PMIPv6 protocol. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 08:40:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLKF-0000nl-VM; Thu, 20 Sep 2007 08:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLKE-0000nD-6u for netlmm@ietf.org; Thu, 20 Sep 2007 08:40:10 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYLK7-0003hK-2P for netlmm@ietf.org; Thu, 20 Sep 2007 08:40:10 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1244793uge for ; Thu, 20 Sep 2007 05:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=Lavvk9q+EOoy6soICLdT3Szo35vmACS82mQYW+NoXKo=; b=qFF3vpp68ijwa+lUwkU73gXpO20ec/fOzEqZHnUgWDT/tPHmgxswjBBd1NbJPwUU4o3zCKYH2risOo2v1Lgx+2SSW4QkpSe9iiOWpuyRJzpTTCPPSVFUVVlMLKSn0HmkwVlckBBpo36jVconjLuGGCu9FqodMwOyQ+xtus1ROVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=nsQO05d8s/asYgV3KYGpvvT7zW5b/LKfmajgpGQY7Nw3qK0y61j30gExdOy6Y3nW/j4pcKjhtCG5GnFKDWmgWAMY45JYKUPaEYlmS9smWVzCk7KKPvVvNdB9NHF7Fu1NPariiOR+e8eNqjKlxHWFBtuN3I4Ojo3K99skEcBoPhQ= Received: by 10.67.19.9 with SMTP id w9mr1216696ugi.1190291985083; Thu, 20 Sep 2007 05:39:45 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id q1sm167904uge.2007.09.20.05.39.42 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2007 05:39:43 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 14:39:40 +0200 User-Agent: KMail/1.9.6 References: <0MKpCa-1IY0qi3Fw9-0007Ui@mrelay.perfora.net> <200709201317.51298.julien.IETF@laposte.net> <46F26427.8060007@gmail.com> In-Reply-To: <46F26427.8060007@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709201439.40172.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex, On Thursday 20 September 2007, Alexandru Petrescu wrote: > [...] > You use the argument that we should use DHCP Relay on MAG because > only one DHCP Server can allocate addresses. To which Alper says > that 'pre-provisioning' can alleviate that restriction. Just to make sure: *if* DHCP is used in a PMIP domain then client bindings for a given MN have to be dealt with by a single DHCP server, and thus a DHCP relay connecting to that server has to be present on each MAG (since the access link is pt-to-pt). Alper and I then agreed that it can be made to work with multiple DHCP servers dealing with client bindings for a single MN provided it exists an out-of-scope mechanism allows to distribute client bindings amongst many DHCP servers. We also agreed that the spec could give some guidance to DHCP deployers in PMIP domain: *if* DHCP is used in a PMIP domain, unless an out-of-scope mechanism allows to distribute client bindings amongst many DHCP servers, then client bindings for a given MN have to be dealt with by a single DHCP server, and thus a DHCP relay connecting to that server has to be present on each MAG. >[...] > I think once we request DHCP presence on a PMIP entity we talk > architecture. We do not "request DHCP presence on a PMIP entity", as you put it. We are discussing, and maybe documenting what limitations on DHCP deployments exists *when* DHCP is deployed. This is not architecture. --julien > architecture. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 09:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLjB-0007eT-DP; Thu, 20 Sep 2007 09:05:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLjA-0007eM-Hs for netlmm@ietf.org; Thu, 20 Sep 2007 09:05:56 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYLj9-0005yj-U0 for netlmm@ietf.org; Thu, 20 Sep 2007 09:05:56 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1190293554!22848359!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12614 invoked from network); 20 Sep 2007 13:05:55 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 20 Sep 2007 13:05:55 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8KD5obW027663; Thu, 20 Sep 2007 06:05:54 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l8KD5nHC021441; Thu, 20 Sep 2007 08:05:50 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l8KD5lIG021338; Thu, 20 Sep 2007 08:05:49 -0500 (CDT) Message-ID: <46F27026.7020809@gmail.com> Date: Thu, 20 Sep 2007 15:05:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <0MKpCa-1IY0qi3Fw9-0007Ui@mrelay.perfora.net> <200709201317.51298.julien.IETF@laposte.net> <46F26427.8060007@gmail.com> <200709201439.40172.julien.IETF@laposte.net> In-Reply-To: <200709201439.40172.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > Alex, > > On Thursday 20 September 2007, Alexandru Petrescu wrote: >> [...] You use the argument that we should use DHCP Relay on MAG >> because only one DHCP Server can allocate addresses. To which >> Alper says that 'pre-provisioning' can alleviate that restriction. > > Just to make sure: *if* DHCP is used in a PMIP domain then client > bindings for a given MN have to be dealt with by a single DHCP > server, I get this part. > and thus a DHCP relay connecting to that server has to be present on > each MAG (since the access link is pt-to-pt). I don't get this part. What ptp has to do with it? Maybe I'm missing something... > Alper and I then agreed that it can be made to work with multiple > DHCP servers dealing with client bindings for a single MN provided it > exists an out-of-scope mechanism allows to distribute client > bindings amongst many DHCP servers. What do you mean by 'out-of-scope'? The basic dhcp rfc allows for multiple servers, then there's rfc3074 for Load Balancing among Servers and a Failover protocol in a (expired) draft-ietf-dhc-failover-12.txt. All implemented in the ISC's DHCP implementation, and deployed at the IETF meetings; it runs in my lab too. Why 'out-of-scope'? 'Out-of-scope' for whom? > We also agreed that the spec could give some guidance to DHCP > deployers in PMIP domain: *if* DHCP is used in a PMIP domain, unless > an Are you sure here you don't give an advice out in the dark? Who are the DHCP deployers for ptp wireless access for mobile? I don't know any, do you? Or are you giving an advice to an SDO and not a deployer? > out-of-scope mechanism allows to distribute client bindings amongst > many DHCP servers, Why out of scope? > then client bindings for a given MN have to be dealt with by a single > DHCP server, Right. > and thus a DHCP relay connecting to that server has to be present on > each MAG. I don't get this part. One can put a DHCP Proxy on a MAG and a DHCP Relay on another MAG and the central DHCP Server will still be able to maintain addresses ok, provided the DHCP Proxy is allocated a pool of addresses by the DHCP Server 'by an out-of-scope mechanism'. >> [...] I think once we request DHCP presence on a PMIP entity we >> talk architecture. > > We do not "request DHCP presence on a PMIP entity", as you put it. We > are discussing, and maybe documenting what limitations on DHCP > deployments exists *when* DHCP is deployed. This is not architecture. Ok, I think it is good to document it perhaps. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:13:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYMlZ-0001pJ-R7; Thu, 20 Sep 2007 10:12:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYMlY-0001nE-Bn for netlmm@ietf.org; Thu, 20 Sep 2007 10:12:28 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYMlX-0007lB-DI for netlmm@ietf.org; Thu, 20 Sep 2007 10:12:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id EC4D5A80EE for ; Thu, 20 Sep 2007 10:12:21 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31100-19 for ; Thu, 20 Sep 2007 10:12:20 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 20 Sep 2007 10:12:20 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:09:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 10:09:51 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA627@exchtewks2.starentnetworks.com> In-Reply-To: <46F19159.7080903@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Thread-Index: Acf7Add1QwSnb5YjRNS4oqg68fyJYQAjc1xA From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Sep 2007 14:09:52.0102 (UTC) FILETIME=[E993C860:01C7FB8F] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Wednesday, September 19, 2007 4:15 PM > To: Chowdhury, Kuntal > Cc: Alper Yegin; netlmm@ietf.org; Julien Laganier > Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO >=20 > Chowdhury, Kuntal wrote: > > > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Wednesday, September 19, 2007 10:01 AM > >> To: Alper Yegin > >> Cc: netlmm@ietf.org; 'Julien Laganier' > >> Subject: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO > >> > >> Alper Yegin wrote: > >>>>> There are alternative approaches. Different DHCP servers (e.g., > >>>>> ones collocated with the MAGs) can be used as long as they can be > >>>>> dynamically-provisioned with the MN configuration parameters, > >>>>> for example, during network access authentication. > >>>> What's 'dynamically-provisioned'? Is it a SDO-specific mechanism? > >>>> I don't know how a deployer would like to deploy a DHCP Server in > >>>> each MAG without mentioning how these pools of addresses are > >>>> dynamically provisioned. > >>> It's typically done via AAA. For example, sending Framed-IP-Address > >>> via RADIUS is for configuring that IP address via DHCP (or PPP). > >> Any deployed system today with wireless point-to-point links using > >> Framed-IP-Address via RADIUS gives that IP address to mobile with > > DHCP? > >> I thought all are PPP. > >> > >> I've framed my mind to think that if wireless access link is > >> point-to-point then it's PPP, and if it's shared medium wifi then it's > >> DHCP; never otherwise. > >> > > [KC>] Nope...there are p2p wireless access links (3GPP, WiMAX) out there > > where PPP is not used. >=20 > Ok. And on these links (3GPP, WiMAX) is DHCP used by the mobile? > Because on GPRS and UMTS the mobile doesn't use DHCP. >=20 [KC>]=20 3GPP: not in Rel7. In Rel8, DHCP may be used.=20 WiMAX: yes for IPv4. For IPv6, SLAAC is used to configure the IPv6 global address. > Alex >=20 > > > >> Alex > >> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. > Any review, retransmission, dissemination or other use of, or taking of > any action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not > the intended recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this message > and any attachments without reading or disclosing their contents. Thank > you." > > >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:17:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYMpy-0006JY-7P; Thu, 20 Sep 2007 10:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYMpw-0006GP-U2 for netlmm@ietf.org; Thu, 20 Sep 2007 10:17:00 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYMpq-0006AL-Ku for netlmm@ietf.org; Thu, 20 Sep 2007 10:17:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 248C2A80CD for ; Thu, 20 Sep 2007 10:16:36 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29933-20 for ; Thu, 20 Sep 2007 10:16:34 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 20 Sep 2007 10:16:34 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:14:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Commentsondraft-05) Date: Thu, 20 Sep 2007 10:14:05 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA628@exchtewks2.starentnetworks.com> In-Reply-To: <0MKp8S-1IYI3l1CUU-0008Rk@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] Commentsondraft-05) Thread-Index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtA= From: "Chowdhury, Kuntal" To: "Alper Yegin" , "Julien Laganier" X-OriginalArrivalTime: 20 Sep 2007 14:14:05.0732 (UTC) FILETIME=[80C0A640:01C7FB90] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Question for clarification: Is DHCPv6 used for IPv6 address config for a host? If yes, could you please point out which DHCPv6 option is used for that?=20 AFAIK, DHCPv6 is used for prefix delegation. Is prefix delegation =3D=3D IPv6 address config? BR, Kuntal > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Thursday, September 20, 2007 4:11 AM > To: 'Julien Laganier' > Cc: netlmm@ietf.org > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm] > Commentsondraft-05) >=20 > Julien, >=20 >=20 > > > You mean "we haven't defined how to do that in IETF?" I agree. > > > > Good. > > > > > But that does not mean it is not doable, especially outside the scope > > > of IETF. > > > > Then shouldn't we add some guidance text to DHCPv6 deployers explaining > > that unless such out-of-scope mechanism is present some limitations are > > placed on DHCPv6 deployments: DHCPv6 relays have to be present at each > > MAG, and configured to forward DHCPv6 messages to the same group of > > DHCPv6 servers (and implicitly that the group of DHCPv6 servers should > > be reachable from every relay). > > > > What do you think? >=20 > As long as we present such text as "informational", that's fine (no > MUST/SHOULD/etc.). And yes, that text is useful. >=20 > Alper >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:25:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYMxl-0004bO-IU; Thu, 20 Sep 2007 10:25:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYMxl-0004au-2N for netlmm@ietf.org; Thu, 20 Sep 2007 10:25:05 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYMxY-0006Ln-PH for netlmm@ietf.org; Thu, 20 Sep 2007 10:24:59 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1190298251!6765920!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31387 invoked from network); 20 Sep 2007 14:24:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 20 Sep 2007 14:24:11 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8KEO6cH024185; Thu, 20 Sep 2007 07:24:06 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l8KEO6VL006292; Thu, 20 Sep 2007 09:24:06 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l8KEO4T9006116; Thu, 20 Sep 2007 09:24:04 -0500 (CDT) Message-ID: <46F2827E.5090609@gmail.com> Date: Thu, 20 Sep 2007 16:23:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <7CCD07160348804497EF29E9EA5560D7024DA627$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA627$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Chowdhury, Kuntal wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, September >> 19, 2007 4:15 PM To: Chowdhury, Kuntal Cc: Alper Yegin; >> netlmm@ietf.org; Julien Laganier Subject: Re: [netlmm] Re: DHCPv6 >> deployment in PMIPv6 domain and SDO >> >> Chowdhury, Kuntal wrote: >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, >>>> September 19, 2007 10:01 AM To: Alper Yegin Cc: >>>> netlmm@ietf.org; 'Julien Laganier' Subject: [netlmm] Re: DHCPv6 >>>> deployment in PMIPv6 domain and SDO >>>> >>>> Alper Yegin wrote: >>>>>>> There are alternative approaches. Different DHCP servers >>>>>>> (e.g., ones collocated with the MAGs) can be used as long >>>>>>> as they can > be >>>>>>> dynamically-provisioned with the MN configuration >>>>>>> parameters, for example, during network access >>>>>>> authentication. >>>>>> What's 'dynamically-provisioned'? Is it a SDO-specific > mechanism? >>>>>> I don't know how a deployer would like to deploy a DHCP >>>>>> Server in each MAG without mentioning how these pools of >>>>>> addresses are dynamically provisioned. >>>>> It's typically done via AAA. For example, sending > Framed-IP-Address >>>>> via RADIUS is for configuring that IP address via DHCP (or >>>>> PPP). >>>> Any deployed system today with wireless point-to-point links >>>> using Framed-IP-Address via RADIUS gives that IP address to >>>> mobile with >>> DHCP? >>>> I thought all are PPP. >>>> >>>> I've framed my mind to think that if wireless access link is >>>> point-to-point then it's PPP, and if it's shared medium wifi >>>> then > it's >>>> DHCP; never otherwise. >>>> >>> [KC>] Nope...there are p2p wireless access links (3GPP, WiMAX) >>> out there where PPP is not used. >> >> Ok. And on these links (3GPP, WiMAX) is DHCP used by the mobile? >> Because on GPRS and UMTS the mobile doesn't use DHCP. >> > [KC>] > > 3GPP: not in Rel7. In Rel8, DHCP may be used. When? > WiMAX: yes for IPv4. For IPv6, SLAAC is used to configure the IPv6 > global address. (Ok, so here we have a distinction from WiMAX for IPv6 vs IPv4 on the access link. Our discussion can be different whether when we talk DHCP for PMIP6 draft or DHCP for v4-for-PMIP6 draft.) For IPv6: IETF's 16ng wg specifies IPv6-over-IPCS to be either SLAAC or DHCPv6. IEEE 802.16 too. WiMax apparently requires only SLAAC, and not DHCP. WiMax uses 802.16. Should we advise WiMax to use DHCPv6 in addition to SLAAC? Or should we advise 16ng WG to not use DHCPv6 for IPv6-over-IPCS? Or should we advise IEEE 802.16 to not use DHCPv6 in the network-entry procedure? Then what should we implement? Alex > > >> Alex >> >>>> Alex >>>> >>>> >>>> > ______________________________________________________________________ > >>>> This email has been scanned by the MessageLabs Email Security > System. >>>> For more information please visit >>>> http://www.messagelabs.com/email >>>> > ______________________________________________________________________ > >>>> _______________________________________________ netlmm mailing >>>> list netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >>> "This email message and any attachments are confidential >>> information > of >> Starent Networks, Corp. The information transmitted may not be used >> to create or change any contractual obligations of Starent >> Networks, > Corp. >> Any review, retransmission, dissemination or other use of, or >> taking > of >> any action in reliance upon this e-mail and its attachments by >> persons > or >> entities other than the intended recipient is prohibited. If you >> are > not >> the intended recipient, please notify the sender immediately -- by >> replying to this message or by sending an email to >> postmaster@starentnetworks.com -- and destroy all copies of this > message >> and any attachments without reading or disclosing their contents. > Thank >> you." >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:29:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYN1n-0007fS-Gs; Thu, 20 Sep 2007 10:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYN1m-0007f1-Bc for netlmm@ietf.org; Thu, 20 Sep 2007 10:29:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYN1l-0006SV-54 for netlmm@ietf.org; Thu, 20 Sep 2007 10:29:14 -0400 X-IronPort-AV: E=Sophos;i="4.20,278,1186383600"; d="scan'208";a="221822367" Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-6.cisco.com with ESMTP; 20 Sep 2007 07:29:12 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l8KETCot000455; Thu, 20 Sep 2007 07:29:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8KETBin020930; Thu, 20 Sep 2007 14:29:11 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 07:29:11 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 07:29:11 -0700 From: "Sri Gundavelli" To: "'Chowdhury, Kuntal'" , "'Alper Yegin'" , "'Julien Laganier'" References: <0MKp8S-1IYI3l1CUU-0008Rk@mrelay.perfora.net> <7CCD07160348804497EF29E9EA5560D7024DA628@exchtewks2.starentnetworks.com> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 07:29:10 -0700 Message-ID: <009101c7fb92$9c665e60$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <7CCD07160348804497EF29E9EA5560D7024DA628@exchtewks2.starentnetworks.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcA== X-OriginalArrivalTime: 20 Sep 2007 14:29:11.0451 (UTC) FILETIME=[9C9A66B0:01C7FB92] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=620; t=1190298552; x=1191162552; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20DHCPv6=20deployment=20in=20PMIPv6=20domain=20(Was=3A= 20[netlmm]Commentsondraft-05) |Sender:=20; bh=pa/56Z8nOaQkwYLePZWo6/i0UxM759RqpWVaiwLVHB0=; b=oOx0rTUUJnUqZ0OJfGxYmBcEOuv8jNYwhe4SlFv6xnxIaj7lgqehq29b/ED8lHN+dLQO7b0W 8/B8+C62IiJq8VtJBY7EaUqbonMEcrtGC20yvduQsXxxBs7JGJip0RL4; Authentication-Results: sj-dkim-6; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Thursday, September 20, 2007 7:14 AM > To: Alper Yegin; Julien Laganier > Cc: netlmm@ietf.org > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > [netlmm]Commentsondraft-05) > > Question for clarification: > > Is DHCPv6 used for IPv6 address config for a host? If yes, could you > please point out which DHCPv6 option is used for that? > RFC-3315. > AFAIK, DHCPv6 is used for prefix delegation. Is prefix delegation == > IPv6 address config? > No. Its the IPv4 DHCP equivalent. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYN3t-0001P6-4H; Thu, 20 Sep 2007 10:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYN3r-0001NJ-D8 for netlmm@ietf.org; Thu, 20 Sep 2007 10:31:23 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYN3o-0006Wb-8i for netlmm@ietf.org; Thu, 20 Sep 2007 10:31:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id A39FFA80CD for ; Thu, 20 Sep 2007 10:30:57 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32291-01 for ; Thu, 20 Sep 2007 10:30:57 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 20 Sep 2007 10:30:57 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:28:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 10:28:27 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA629@exchtewks2.starentnetworks.com> In-Reply-To: <009101c7fb92$9c665e60$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Thread-Index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcAAAAs9g From: "Chowdhury, Kuntal" To: "Sri Gundavelli" , "Alper Yegin" , "Julien Laganier" X-OriginalArrivalTime: 20 Sep 2007 14:28:28.0265 (UTC) FILETIME=[82DCBD90:01C7FB92] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Thursday, September 20, 2007 9:29 AM > To: Chowdhury, Kuntal; 'Alper Yegin'; 'Julien Laganier' > Cc: netlmm@ietf.org > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > [netlmm]Commentsondraft-05) >=20 >=20 > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: Thursday, September 20, 2007 7:14 AM > > To: Alper Yegin; Julien Laganier > > Cc: netlmm@ietf.org > > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > > [netlmm]Commentsondraft-05) > > > > Question for clarification: > > > > Is DHCPv6 used for IPv6 address config for a host? If yes, could you > > please point out which DHCPv6 option is used for that? > > >=20 > RFC-3315. >=20 [KC>] I know that for sure. But, could you point out which option is used to configure IPv6 address in the host? > > AFAIK, DHCPv6 is used for prefix delegation. Is prefix delegation = =3D=3D > > IPv6 address config? > > >=20 > No. Its the IPv4 DHCP equivalent. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:31:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYN4J-0001iD-Tt; Thu, 20 Sep 2007 10:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYN4I-0001fz-Re for netlmm@ietf.org; Thu, 20 Sep 2007 10:31:50 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYN4H-0006Yc-J0 for netlmm@ietf.org; Thu, 20 Sep 2007 10:31:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 30684A80ED for ; Thu, 20 Sep 2007 10:31:46 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30362-15 for ; Thu, 20 Sep 2007 10:31:45 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 20 Sep 2007 10:31:45 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:29:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 10:29:16 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA62A@exchtewks2.starentnetworks.com> In-Reply-To: <46F2469E.1010405@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Thread-Index: Acf7beWFlcMoHoycRCC579yAmrzUjAAIscew From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" , "Alper Yegin" X-OriginalArrivalTime: 20 Sep 2007 14:29:16.0717 (UTC) FILETIME=[9FBDEDD0:01C7FB92] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, September 20, 2007 5:09 AM > To: Alper Yegin > Cc: Chowdhury, Kuntal; netlmm@ietf.org; 'Julien Laganier' > Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO >=20 > Alper Yegin wrote: > >> If so, I'm afraid it's the only one using DHCP over ptp links(?), > >> because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and don't use > >> DHCP over them. > > > > Sorry I lost track of why this matters, even if that were the case. >=20 > Doing DHCP support for P-MIPv6 without knowing why we do it, and without > requirements - is senseless. >=20 [KC>] I agree. > The original topic is whether to suggest that MAG should be a DHCPv6 > Relay or not suggest so. But does the MN need DHCPv6? Other than WiMax > will any other MN run DHCPv6 over a ptp wireless access link? Is this > PMIPv6 only for WiMax? >=20 [KC>] IPv6 SLAAC is the predominant address config mechanism used over p2p wireless links. There are some hand wavy text in WiMAX NWG spec and the 16ng I-D about stateful address config. But, nothing is clearly defined, IMHO. > >> Or otherwise if WiMax MS uses DHCP then it is over ETHCS and not > >> over the ptp IPCS link, right? > > > > No. WiMAX architecture also supports DHCP over IPCS. >=20 > This is nonsense. >=20 > I keep asking for requirements: why do we need DHCP support for P-MIPv6? >=20 > And you keep telling me a certain SDO can support everything, this is > deceiving. I know many other SDOs who'll also support everything. >=20 [KC>] use of DHCPv6 for address config over foo_bar wireless links is not clearly defined/used as per my understanding. So, there is no slid use case for such a thing. > Alex >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:37:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYN9c-000782-Iq; Thu, 20 Sep 2007 10:37:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYN9b-00073B-4z for netlmm@ietf.org; Thu, 20 Sep 2007 10:37:19 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYN9a-0008PT-Gh for netlmm@ietf.org; Thu, 20 Sep 2007 10:37:18 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1190299036!4177089!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22561 invoked from network); 20 Sep 2007 14:37:17 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 20 Sep 2007 14:37:17 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8KEbGL6028330; Thu, 20 Sep 2007 07:37:16 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l8KEbF58018471; Thu, 20 Sep 2007 09:37:16 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l8KEbDZC018384; Thu, 20 Sep 2007 09:37:14 -0500 (CDT) Message-ID: <46F28594.6020600@gmail.com> Date: Thu, 20 Sep 2007 16:37:08 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) References: <0MKp8S-1IYI3l1CUU-0008Rk@mrelay.perfora.net> <7CCD07160348804497EF29E9EA5560D7024DA628@exchtewks2.starentnetworks.com> <009101c7fb92$9c665e60$d5f6200a@amer.cisco.com> In-Reply-To: <009101c7fb92$9c665e60$d5f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri Gundavelli wrote: >> -----Original Message----- >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >> Sent: Thursday, September 20, 2007 7:14 AM >> To: Alper Yegin; Julien Laganier >> Cc: netlmm@ietf.org >> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: >> [netlmm]Commentsondraft-05) >> >> Question for clarification: >> >> Is DHCPv6 used for IPv6 address config for a host? If yes, could you >> please point out which DHCPv6 option is used for that? >> > > RFC-3315. Like at least for example how is the DHCP CONFIRM message used? How or is REBIND used or not? Do they happen before or after the P-BU/P-BAck? Not clear in the pictures of draft-05. >> AFAIK, DHCPv6 is used for prefix delegation. Is prefix delegation == >> IPv6 address config? >> > > No. Its the IPv4 DHCP equivalent. I agree it should, except that in details at least the message exchanges are different. Alex > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:40:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNC3-0005Dp-AJ; Thu, 20 Sep 2007 10:39:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNC1-0004vm-Es for netlmm@ietf.org; Thu, 20 Sep 2007 10:39:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYNC0-00008F-Qe for netlmm@ietf.org; Thu, 20 Sep 2007 10:39:49 -0400 X-IronPort-AV: E=Sophos;i="4.20,278,1186383600"; d="scan'208";a="221827743" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Sep 2007 07:39:48 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8KEdmKw021011; Thu, 20 Sep 2007 07:39:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8KEdXjD004006; Thu, 20 Sep 2007 14:39:39 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 07:38:07 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 07:38:07 -0700 From: "Sri Gundavelli" To: "'Chowdhury, Kuntal'" , "'Alper Yegin'" , "'Julien Laganier'" References: <009101c7fb92$9c665e60$d5f6200a@amer.cisco.com> <7CCD07160348804497EF29E9EA5560D7024DA629$0001@exchtewks2.starentnetworks.com> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 07:38:06 -0700 Message-ID: <009501c7fb93$dbbfc190$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <7CCD07160348804497EF29E9EA5560D7024DA629$0001@exchtewks2.starentnetworks.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcAAAAs9gAABRKeA= X-OriginalArrivalTime: 20 Sep 2007 14:38:07.0281 (UTC) FILETIME=[DBFB9210:01C7FB93] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2287; t=1190299188; x=1191163188; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20DHCPv6=20deployment=20in=20PMIPv6=20domain=20(Was=3A= 20[netlmm]Commentsondraft-05) |Sender:=20; bh=HXKqrIn+CY3MkWsMwXiEjGcWJuRzef4uV7bNvGzLJ+0=; b=GjK6bq24aNUqwN80OGsggeOOK0C7u5NhJ+GZXLtvRQsaA6UzfqL/3fAlsqeURWJsTWzOrGQr r80rNJ6cMsGhShi+JT+aGIp+o/BmD3HJXhr0JkS6QC58DyPqXUJjJqS8; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Thursday, September 20, 2007 7:28 AM > To: Sri Gundavelli; Alper Yegin; Julien Laganier > Cc: netlmm@ietf.org > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > [netlmm]Commentsondraft-05) > > > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Thursday, September 20, 2007 9:29 AM > > To: Chowdhury, Kuntal; 'Alper Yegin'; 'Julien Laganier' > > Cc: netlmm@ietf.org > > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > > [netlmm]Commentsondraft-05) > > > > > > > -----Original Message----- > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > Sent: Thursday, September 20, 2007 7:14 AM > > > To: Alper Yegin; Julien Laganier > > > Cc: netlmm@ietf.org > > > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > > > [netlmm]Commentsondraft-05) > > > > > > Question for clarification: > > > > > > Is DHCPv6 used for IPv6 address config for a host? If > yes, could you > > > please point out which DHCPv6 option is used for that? > > > > > > > RFC-3315. > > > [KC>] I know that for sure. But, could you point out which option is > used to configure IPv6 address in the host? > I think its the IA Address Option. Sri > > > AFAIK, DHCPv6 is used for prefix delegation. Is prefix > delegation == > > > IPv6 address config? > > > > > > > No. Its the IPv4 DHCP equivalent. > > > "This email message and any attachments are confidential > information of Starent Networks, Corp. The information > transmitted may not be used to create or change any > contractual obligations of Starent Networks, Corp. Any > review, retransmission, dissemination or other use of, or > taking of any action in reliance upon this e-mail and its > attachments by persons or entities other than the intended > recipient is prohibited. If you are not the intended > recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of > this message and any attachments without reading or > disclosing their contents. Thank you." _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:46:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNIP-0004Kq-PM; Thu, 20 Sep 2007 10:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNIP-0004Kg-5V for netlmm@ietf.org; Thu, 20 Sep 2007 10:46:25 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYNII-0006yy-U4 for netlmm@ietf.org; Thu, 20 Sep 2007 10:46:25 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1190299536!17296640!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26461 invoked from network); 20 Sep 2007 14:45:36 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 20 Sep 2007 14:45:36 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8KEjaiU001010; Thu, 20 Sep 2007 07:45:36 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l8KEjZsg026170; Thu, 20 Sep 2007 09:45:35 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l8KEjXug026093; Thu, 20 Sep 2007 09:45:34 -0500 (CDT) Message-ID: <46F28787.6080609@gmail.com> Date: Thu, 20 Sep 2007 16:45:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <7CCD07160348804497EF29E9EA5560D7024DA62A$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA62A$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Chowdhury, Kuntal wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, September 20, >> 2007 5:09 AM To: Alper Yegin Cc: Chowdhury, Kuntal; >> netlmm@ietf.org; 'Julien Laganier' Subject: Re: [netlmm] Re: DHCPv6 >> deployment in PMIPv6 domain and SDO >> >> Alper Yegin wrote: >>>> If so, I'm afraid it's the only one using DHCP over ptp >>>> links(?), because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and >>>> don't use DHCP over them. >>> Sorry I lost track of why this matters, even if that were the >>> case. >> Doing DHCP support for P-MIPv6 without knowing why we do it, and > without >> requirements - is senseless. >> > [KC>] I agree. > >> The original topic is whether to suggest that MAG should be a >> DHCPv6 Relay or not suggest so. But does the MN need DHCPv6? Other >> than > WiMax >> will any other MN run DHCPv6 over a ptp wireless access link? Is >> this PMIPv6 only for WiMax? >> > [KC>] IPv6 SLAAC is the predominant address config mechanism used > over p2p wireless links. > > There are some hand wavy text in WiMAX NWG spec and the 16ng I-D > about stateful address config. But, nothing is clearly defined, IMHO. This doubt is very strong here too... >>>> Or otherwise if WiMax MS uses DHCP then it is over ETHCS and >>>> not over the ptp IPCS link, right? >>> No. WiMAX architecture also supports DHCP over IPCS. >> This is nonsense. >> >> I keep asking for requirements: why do we need DHCP support for > P-MIPv6? >> And you keep telling me a certain SDO can support everything, this >> is deceiving. I know many other SDOs who'll also support >> everything. >> > [KC>] use of DHCPv6 for address config over foo_bar wireless links is > not clearly defined/used as per my understanding. You mean ptp right? Because dhcpv6 over foobar wireless _shared_ link like wifi and bluetooth pan-profile is. > So, there is no slid use case for such a thing. I hope you mean dhcpv6 over ptp wireless access links, right? If yes, then I tend to agree with you. Alex > >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > > > "This email message and any attachments are confidential information > of Starent Networks, Corp. The information transmitted may not be > used to create or change any contractual obligations of Starent > Networks, Corp. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this e-mail and its > attachments by persons or entities other than the intended recipient > is prohibited. If you are not the intended recipient, please notify > the sender immediately -- by replying to this message or by sending > an email to postmaster@starentnetworks.com -- and destroy all copies > of this message and any attachments without reading or disclosing > their contents. Thank you." > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:51:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNNU-0006gZ-Uf; Thu, 20 Sep 2007 10:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNNS-0006dg-NU for netlmm@ietf.org; Thu, 20 Sep 2007 10:51:38 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYNNR-00079h-HU for netlmm@ietf.org; Thu, 20 Sep 2007 10:51:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 20075A80EE for ; Thu, 20 Sep 2007 10:51:28 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31886-19 for ; Thu, 20 Sep 2007 10:51:27 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 20 Sep 2007 10:51:27 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:48:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 10:48:58 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA62B@exchtewks2.starentnetworks.com> In-Reply-To: <009501c7fb93$dbbfc190$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Thread-Index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcAAAAs9gAABRKeAAAA1LoA== From: "Chowdhury, Kuntal" To: "Sri Gundavelli" , "Alper Yegin" , "Julien Laganier" X-OriginalArrivalTime: 20 Sep 2007 14:48:58.0529 (UTC) FILETIME=[60282110:01C7FB95] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Thursday, September 20, 2007 9:38 AM > To: Chowdhury, Kuntal; 'Alper Yegin'; 'Julien Laganier' > Cc: netlmm@ietf.org > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > [netlmm]Commentsondraft-05) >=20 >=20 >=20 > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: Thursday, September 20, 2007 7:28 AM > > To: Sri Gundavelli; Alper Yegin; Julien Laganier > > Cc: netlmm@ietf.org > > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > > [netlmm]Commentsondraft-05) > > > > > > > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Thursday, September 20, 2007 9:29 AM > > > To: Chowdhury, Kuntal; 'Alper Yegin'; 'Julien Laganier' > > > Cc: netlmm@ietf.org > > > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > > > [netlmm]Commentsondraft-05) > > > > > > > > > > -----Original Message----- > > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > > Sent: Thursday, September 20, 2007 7:14 AM > > > > To: Alper Yegin; Julien Laganier > > > > Cc: netlmm@ietf.org > > > > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > > > > [netlmm]Commentsondraft-05) > > > > > > > > Question for clarification: > > > > > > > > Is DHCPv6 used for IPv6 address config for a host? If > > yes, could you > > > > please point out which DHCPv6 option is used for that? > > > > > > > > > > RFC-3315. > > > > > [KC>] I know that for sure. But, could you point out which option is > > used to configure IPv6 address in the host? > > >=20 > I think its the IA Address Option. >=20 [KC>] I also thought so, until someone told me that DHCPv6 is primarily used for prefix delegation and NOT address assignment to a host. If you read IA definition carefully, it actually talks about assigning a group of addresses to an interface on a host. Anyway, the point is that SLAAC is the predominant IPv6 address config mechanism. It is widely adopted and implemented. Use of DHCPv6 for address configuration is not that popular and I am not sure whether it is even used anywhere or not. > Sri >=20 >=20 > > > > AFAIK, DHCPv6 is used for prefix delegation. Is prefix > > delegation =3D=3D > > > > IPv6 address config? > > > > > > > > > > No. Its the IPv4 DHCP equivalent. > > > > > > "This email message and any attachments are confidential > > information of Starent Networks, Corp. The information > > transmitted may not be used to create or change any > > contractual obligations of Starent Networks, Corp. Any > > review, retransmission, dissemination or other use of, or > > taking of any action in reliance upon this e-mail and its > > attachments by persons or entities other than the intended > > recipient is prohibited. If you are not the intended > > recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of > > this message and any attachments without reading or > > disclosing their contents. Thank you." _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 10:54:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNPs-0008Tr-Cr; Thu, 20 Sep 2007 10:54:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNPr-0008Tm-3y for netlmm@ietf.org; Thu, 20 Sep 2007 10:54:07 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYNPq-0000XS-18 for netlmm@ietf.org; Thu, 20 Sep 2007 10:54:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 78518A80EE for ; Thu, 20 Sep 2007 10:54:02 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32660-12 for ; Thu, 20 Sep 2007 10:54:01 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 20 Sep 2007 10:54:01 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:51:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 10:51:32 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA62C@exchtewks2.starentnetworks.com> In-Reply-To: <46F28787.6080609@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Thread-Index: Acf7lJQHE6mC0JdnRGCWyffs7NpWKQAANwTw From: "Chowdhury, Kuntal" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Sep 2007 14:51:32.0965 (UTC) FILETIME=[BC353150:01C7FB95] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > > [KC>] use of DHCPv6 for address config over foo_bar wireless links is > > not clearly defined/used as per my understanding. >=20 > You mean ptp right? Because dhcpv6 over foobar wireless _shared_ link > like wifi and bluetooth pan-profile is. >=20 Yes, I meant p2p wireless links. Most of the SDO specific wireless links are p2p as we have mentioned before. > > So, there is no slid use case for such a thing. >=20 > I hope you mean dhcpv6 over ptp wireless access links, right? If yes, > then I tend to agree with you. Yes. > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, September 20, 2007 9:45 AM > To: Chowdhury, Kuntal > Cc: Alper Yegin; netlmm@ietf.org; Julien Laganier > Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO >=20 > Chowdhury, Kuntal wrote: > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, September 20, > >> 2007 5:09 AM To: Alper Yegin Cc: Chowdhury, Kuntal; > >> netlmm@ietf.org; 'Julien Laganier' Subject: Re: [netlmm] Re: DHCPv6 > >> deployment in PMIPv6 domain and SDO > >> > >> Alper Yegin wrote: > >>>> If so, I'm afraid it's the only one using DHCP over ptp > >>>> links(?), because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and > >>>> don't use DHCP over them. > >>> Sorry I lost track of why this matters, even if that were the > >>> case. > >> Doing DHCP support for P-MIPv6 without knowing why we do it, and > > without > >> requirements - is senseless. > >> > > [KC>] I agree. > > > >> The original topic is whether to suggest that MAG should be a > >> DHCPv6 Relay or not suggest so. But does the MN need DHCPv6? Other > >> than > > WiMax > >> will any other MN run DHCPv6 over a ptp wireless access link? Is > >> this PMIPv6 only for WiMax? > >> > > [KC>] IPv6 SLAAC is the predominant address config mechanism used > > over p2p wireless links. > > > > There are some hand wavy text in WiMAX NWG spec and the 16ng I-D > > about stateful address config. But, nothing is clearly defined, IMHO. >=20 > This doubt is very strong here too... >=20 > >>>> Or otherwise if WiMax MS uses DHCP then it is over ETHCS and > >>>> not over the ptp IPCS link, right? > >>> No. WiMAX architecture also supports DHCP over IPCS. > >> This is nonsense. > >> > >> I keep asking for requirements: why do we need DHCP support for > > P-MIPv6? > >> And you keep telling me a certain SDO can support everything, this > >> is deceiving. I know many other SDOs who'll also support > >> everything. > >> > > [KC>] use of DHCPv6 for address config over foo_bar wireless links is > > not clearly defined/used as per my understanding. >=20 > You mean ptp right? Because dhcpv6 over foobar wireless _shared_ link > like wifi and bluetooth pan-profile is. >=20 > > So, there is no slid use case for such a thing. >=20 > I hope you mean dhcpv6 over ptp wireless access links, right? If yes, > then I tend to agree with you. >=20 > Alex >=20 > > > >> Alex > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security > >> System. For more information please visit > >> http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> > > > > > > "This email message and any attachments are confidential information > > of Starent Networks, Corp. The information transmitted may not be > > used to create or change any contractual obligations of Starent > > Networks, Corp. Any review, retransmission, dissemination or other > > use of, or taking of any action in reliance upon this e-mail and its > > attachments by persons or entities other than the intended recipient > > is prohibited. If you are not the intended recipient, please notify > > the sender immediately -- by replying to this message or by sending > > an email to postmaster@starentnetworks.com -- and destroy all copies > > of this message and any attachments without reading or disclosing > > their contents. Thank you." > > >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 11:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNYx-0001ES-Lh; Thu, 20 Sep 2007 11:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYNYv-0001Df-Lj for netlmm@ietf.org; Thu, 20 Sep 2007 11:03:29 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYNYu-0007UI-DH for netlmm@ietf.org; Thu, 20 Sep 2007 11:03:29 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1190300589!18665046!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23797 invoked from network); 20 Sep 2007 15:03:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 20 Sep 2007 15:03:09 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8KF38rX006802; Thu, 20 Sep 2007 08:03:08 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8KF38pn001272; Thu, 20 Sep 2007 10:03:08 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8KF350l001136; Thu, 20 Sep 2007 10:03:05 -0500 (CDT) Message-ID: <46F28BA3.3010708@gmail.com> Date: Thu, 20 Sep 2007 17:02:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) References: <7CCD07160348804497EF29E9EA5560D7024DA62B@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA62B@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-3, 19/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Julien Laganier , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Chowdhury, Kuntal wrote: [...] > Anyway, the point is that SLAAC is the predominant IPv6 address config > mechanism. It is widely adopted and implemented. Use of DHCPv6 for > address configuration is not that popular and I am not sure whether it > is even used anywhere or not. Kuntal, thanks, but I'd be careful with this message. Because talking deployment of DHCPv6 vs SLAAC is not that straightforward, in the case of shared links. Indeed SLAAC is first thing seen by anybody moving from IPv4 to IPv6; but DHCPv6 clients exist in Windows Vista (to not name it) and even DHCPv4 _Servers_ exist in Windows Mobile PDA/Smartphones. I wouldn't be surprised to see DHCPv6 _Servers_ in a Windows PDA soon. They're for shared links, though. I would avoid saying that DHCPv6 is not that popular. But I agree with you SLAAC is the first thing that must work, and parts of it must work before any DHCPv6 exchange can take place. Alex > > >> Sri >> >> >>>>> AFAIK, DHCPv6 is used for prefix delegation. Is prefix >>> delegation == >>>>> IPv6 address config? >>>>> >>>> No. Its the IPv4 DHCP equivalent. >>> >>> "This email message and any attachments are confidential >>> information of Starent Networks, Corp. The information >>> transmitted may not be used to create or change any >>> contractual obligations of Starent Networks, Corp. Any >>> review, retransmission, dissemination or other use of, or >>> taking of any action in reliance upon this e-mail and its >>> attachments by persons or entities other than the intended >>> recipient is prohibited. If you are not the intended >>> recipient, please notify the sender immediately -- by >>> replying to this message or by sending an email to >>> postmaster@starentnetworks.com -- and destroy all copies of >>> this message and any attachments without reading or >>> disclosing their contents. Thank you." > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 11:37:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYO5S-0005LE-Nr; Thu, 20 Sep 2007 11:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYO5R-0005L2-Pu for netlmm@ietf.org; Thu, 20 Sep 2007 11:37:05 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYO5H-0000AK-Ip for netlmm@ietf.org; Thu, 20 Sep 2007 11:37:05 -0400 X-IronPort-AV: E=Sophos;i="4.20,279,1186383600"; d="scan'208";a="19096291" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2007 08:36:50 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8KFaoSp026558; Thu, 20 Sep 2007 08:36:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8KFanX1007224; Thu, 20 Sep 2007 15:36:49 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 08:36:49 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 08:36:49 -0700 From: "Sri Gundavelli" To: "'Chowdhury, Kuntal'" , "'Alper Yegin'" , "'Julien Laganier'" References: <009501c7fb93$dbbfc190$d5f6200a@amer.cisco.com> <7CCD07160348804497EF29E9EA5560D7024DA62B$0001@exchtewks2.starentnetworks.com> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 08:36:48 -0700 Message-ID: <00a201c7fb9c$0eed6f60$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <7CCD07160348804497EF29E9EA5560D7024DA62B$0001@exchtewks2.starentnetworks.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcAAAAs9gAABRKeAAAA1LoAAB80YA X-OriginalArrivalTime: 20 Sep 2007 15:36:49.0307 (UTC) FILETIME=[0F4616B0:01C7FB9C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=761; t=1190302610; x=1191166610; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20DHCPv6=20deployment=20in=20PMIPv6=20domain=20(Was=3A= 20[netlmm]Commentsondraft-05) |Sender:=20; bh=6+Q6LP89qU4pYC3oAXUwYOOKUdiPEFNr3iea7pwjlaU=; b=pn9quEf/4UcheTePdad0DEH/TPu83HWcsSbSiIPp+2DSA7vkRxdp4IZ7WbiIg7wW3PYKfmES ZfjkGxcf0AUlqVV/n4Hbtieh+0CsVhtNLeB/rdJ2lura9ToMnSiVT4hB; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > > > [KC>] I also thought so, until someone told me that DHCPv6 is > primarily > used for prefix delegation and NOT address assignment to a > host. If you Kuntal, Not sure, what the confusion is. 3315 is the basic IPv6 DHCP Protocol 3633 is for DHCP IPv6 Prefix Delegation. So, the host addressing is in the base spec and the PD is in 3633. Sri > read IA definition carefully, it actually talks about > assigning a group > of addresses to an interface on a host. > > Anyway, the point is that SLAAC is the predominant IPv6 address config > mechanism. It is widely adopted and implemented. Use of DHCPv6 for > address configuration is not that popular and I am not sure whether it > is even used anywhere or not. > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 11:44:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOCi-0002Ny-4M; Thu, 20 Sep 2007 11:44:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOCg-0002Kq-LX for netlmm@ietf.org; Thu, 20 Sep 2007 11:44:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYOCf-0000Lv-Ct for netlmm@ietf.org; Thu, 20 Sep 2007 11:44:34 -0400 X-IronPort-AV: E=Sophos;i="4.20,279,1186383600"; d="scan'208";a="19099298" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2007 08:44:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8KFiWAb007576; Thu, 20 Sep 2007 08:44:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8KFiJDv005311; Thu, 20 Sep 2007 15:44:24 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 08:44:23 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 08:44:23 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" References: <0MKp8S-1IYI3l1CUU-0008Rk@mrelay.perfora.net> <7CCD07160348804497EF29E9EA5560D7024DA628@exchtewks2.starentnetworks.com> <009101c7fb92$9c665e60$d5f6200a@amer.cisco.com> <46F28594.6020600@gmail.com> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 08:44:22 -0700 Message-ID: <00a901c7fb9d$1d8b1580$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <46F28594.6020600@gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf7lXJR1RKBIcz5QCqlMbDsUDEYCQABtXHw X-OriginalArrivalTime: 20 Sep 2007 15:44:23.0419 (UTC) FILETIME=[1DF214B0:01C7FB9D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2347; t=1190303072; x=1191167072; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20DHCPv6=20deployment=20in=20PMIPv6=20domain=20(Was=3A= 09[netlmm]Commentsondraft-05) |Sender:=20; bh=Xqtje8ZqeYpVIfdIq2pnOm+U1kVjfq0yyauu3aOAOow=; b=mF/VeQSDQGCvVTa+HwGXvIRoZnS2mJamEk4P85uSpqECO+jZK7Vmkzjb40PymWwdtrikinxS GxO1I8WIHg/JuFoT2NH7W1QITUxZe/62yV6rr22Fm4dLZS2cR2NqGyGz; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, September 20, 2007 7:37 AM > To: Sri Gundavelli > Cc: 'Chowdhury, Kuntal'; 'Alper Yegin'; 'Julien Laganier'; > netlmm@ietf.org > Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: > [netlmm]Commentsondraft-05) > > Sri Gundavelli wrote: > >> -----Original Message----- > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > >> Sent: Thursday, September 20, 2007 7:14 AM > >> To: Alper Yegin; Julien Laganier > >> Cc: netlmm@ietf.org > >> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > >> [netlmm]Commentsondraft-05) > >> > >> Question for clarification: > >> > >> Is DHCPv6 used for IPv6 address config for a host? If yes, > could you > >> please point out which DHCPv6 option is used for that? > >> > > > > RFC-3315. > > Like at least for example how is the DHCP CONFIRM message > used? How or > is REBIND used or not? > > Do they happen before or after the P-BU/P-BAck? Not clear in the > pictures of draft-05. > If you see Fig 2, Section 3. the "Address Configuration" is after the MN receives the RA. This is specified in other places as well. The draft did not go into the details of the DHCP signaling. Once, the PMIP signaling is complete and MAG advertises the prefix on the MN-AR link, after that point its a normal IPv6 link and the regular DHCP6 messages can flow through. Its like in fixed infrastructures. Let me know, if there is any ambiguity in the text. Thanks Sri > >> AFAIK, DHCPv6 is used for prefix delegation. Is prefix > delegation == > >> IPv6 address config? > >> > > > > No. Its the IPv4 DHCP equivalent. > > I agree it should, except that in details at least the > message exchanges > are different. > > Alex > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________ > ________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 12:02:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOUK-0007b6-KT; Thu, 20 Sep 2007 12:02:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOUI-0007YX-Kq for netlmm@ietf.org; Thu, 20 Sep 2007 12:02:46 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYOUC-0000v1-FC for netlmm@ietf.org; Thu, 20 Sep 2007 12:02:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id D49A3A80CD for ; Thu, 20 Sep 2007 12:02:13 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02360-08 for ; Thu, 20 Sep 2007 12:02:13 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 20 Sep 2007 12:02:13 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 11:59:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 11:59:44 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA635@exchtewks2.starentnetworks.com> In-Reply-To: <00a201c7fb9c$0eed6f60$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Thread-Index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcAAAAs9gAABRKeAAAA1LoAAB80YAAADS2xA= From: "Chowdhury, Kuntal" To: "Sri Gundavelli" , "Alper Yegin" , "Julien Laganier" X-OriginalArrivalTime: 20 Sep 2007 15:59:44.0340 (UTC) FILETIME=[42DB7940:01C7FB9F] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Thursday, September 20, 2007 10:37 AM > To: Chowdhury, Kuntal; 'Alper Yegin'; 'Julien Laganier' > Cc: netlmm@ietf.org > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > [netlmm]Commentsondraft-05) >=20 >=20 > > > > > [KC>] I also thought so, until someone told me that DHCPv6 is > > primarily > > used for prefix delegation and NOT address assignment to a > > host. If you >=20 > Kuntal, >=20 > Not sure, what the confusion is. >=20 > 3315 is the basic IPv6 DHCP Protocol > 3633 is for DHCP IPv6 Prefix Delegation. >=20 > So, the host addressing is in the base spec and the PD is > in 3633. >=20 [KC>] OK Sri. I get your point and thanks for the clarification. I am yet to see wide scale use of DHCPv6 for address config in the wireless/SDO world. That's why; perhaps my opinion is skewed towards SLAAC :-) > Sri >=20 >=20 >=20 > > read IA definition carefully, it actually talks about > > assigning a group > > of addresses to an interface on a host. > > > > Anyway, the point is that SLAAC is the predominant IPv6 address config > > mechanism. It is widely adopted and implemented. Use of DHCPv6 for > > address configuration is not that popular and I am not sure whether it > > is even used anywhere or not. > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 12:07:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOYx-0002Qi-D5; Thu, 20 Sep 2007 12:07:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOYv-0002En-PW for netlmm@ietf.org; Thu, 20 Sep 2007 12:07:33 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYOYv-0002vL-78 for netlmm@ietf.org; Thu, 20 Sep 2007 12:07:33 -0400 X-IronPort-AV: E=Sophos;i="4.20,279,1186383600"; d="scan'208";a="19108366" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2007 09:07:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8KG7WPc010638; Thu, 20 Sep 2007 09:07:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8KG7PEB001118; Thu, 20 Sep 2007 16:07:32 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 09:07:25 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 09:07:25 -0700 From: "Sri Gundavelli" To: "'Chowdhury, Kuntal'" , "'Alper Yegin'" , "'Julien Laganier'" References: <00a201c7fb9c$0eed6f60$d5f6200a@amer.cisco.com> <7CCD07160348804497EF29E9EA5560D7024DA635$0001@exchtewks2.starentnetworks.com> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 09:07:24 -0700 Message-ID: <00b101c7fba0$5545ded0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <7CCD07160348804497EF29E9EA5560D7024DA635$0001@exchtewks2.starentnetworks.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcAAAAs9gAABRKeAAAA1LoAAB80YAAADS2xAAAD53sA== X-OriginalArrivalTime: 20 Sep 2007 16:07:25.0518 (UTC) FILETIME=[55BDA6E0:01C7FBA0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1350; t=1190304452; x=1191168452; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20DHCPv6=20deployment=20in=20PMIPv6=20domain=20(Was=3A= 20[netlmm]Commentsondraft-05) |Sender:=20; bh=TK6+l9lA8YDpk+uxLZXxwyA2gRusCRa4ahyRDQWVMtM=; b=lcyN/cmVbvYEFpuVWfwdbpCyF4nxn8CCCVKHc4STtVA3wzx6QpATr9le7Q97AnNMmU4UIRoO FLvORrq/EK9NNE9XzJyV0x4lxQ9wZkbtiTfaihHn7Mpz+p/IEPfrAzVP; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Thursday, September 20, 2007 9:00 AM > To: Sri Gundavelli; Alper Yegin; Julien Laganier > Cc: netlmm@ietf.org > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > [netlmm]Commentsondraft-05) > > > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Thursday, September 20, 2007 10:37 AM > > To: Chowdhury, Kuntal; 'Alper Yegin'; 'Julien Laganier' > > Cc: netlmm@ietf.org > > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > > [netlmm]Commentsondraft-05) > > > > > > > > > > > [KC>] I also thought so, until someone told me that DHCPv6 is > > > primarily > > > used for prefix delegation and NOT address assignment to a > > > host. If you > > > > Kuntal, > > > > Not sure, what the confusion is. > > > > 3315 is the basic IPv6 DHCP Protocol > > 3633 is for DHCP IPv6 Prefix Delegation. > > > > So, the host addressing is in the base spec and the PD is > > in 3633. > > > [KC>] OK Sri. I get your point and thanks for the clarification. I am > yet to see wide scale use of DHCPv6 for address config in the > wireless/SDO world. That's why; perhaps my opinion is skewed towards > SLAAC :-) > I agree. SLAAC is the way to go. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 12:44:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYP7Q-0005yC-Fj; Thu, 20 Sep 2007 12:43:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYP7P-0005y6-T5 for netlmm@ietf.org; Thu, 20 Sep 2007 12:43:11 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYP7J-0002jP-NH for netlmm@ietf.org; Thu, 20 Sep 2007 12:43:11 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1397092uge for ; Thu, 20 Sep 2007 09:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=diHD4Bjpm0ShUVdPQ8s1YiiPu7fSYBUvZjvg59qIRHc=; b=PAaYe3iW85gLGeSsAnh33n73PgfHZfIfV/YI5cdAySzCSwBR0nadBulO3EoE18zkr8wcfU+bnX5DaNqY9mK1ILTZxbYRMac67rw8Y1Z229IMMyNqQvjjoQbuB4Q1UUkBeNjsoA9MJDfHCMOkxXo7mUdrsIeGucE4XMvCHU6MwBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=hvtN1F8w8j+sjUG4oEacCeGipcelMEmOA3+xqUxXXvlw1CWFK/j30VgTsXAeJoXOpG0jq4RfZcO1Q4SXbD1jnBGGD1xlQaeL6YIhw/WvLQViCWZ5ibRIRT1vYy+A52W45Ezu20CTEc0D+YE++zaCFlFdRNiPLc++i56CkgoAHhU= Received: by 10.67.28.4 with SMTP id f4mr3367991ugj.1190306559444; Thu, 20 Sep 2007 09:42:39 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id o30sm553847ugd.2007.09.20.09.42.37 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2007 09:42:38 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 18:42:34 +0200 User-Agent: KMail/1.9.6 References: <46F23CF5.2090209@gmail.com> <200709201319.30236.julien.IETF@laposte.net> <46F268B8.7050809@gmail.com> In-Reply-To: <46F268B8.7050809@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709201842.35033.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Thursday 20 September 2007, Alexandru Petrescu wrote: > [...] let's focus on how can we require DHCP in the PMIPv6 protocol. ?! Nobody wants to "require DHCP in the PMIPv6 protocol", whatever that means. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 12:44:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYP8y-0006pH-2W; Thu, 20 Sep 2007 12:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYP8w-0006dY-OZ for netlmm@ietf.org; Thu, 20 Sep 2007 12:44:46 -0400 Received: from hu-out-0506.google.com ([72.14.214.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYP8X-0002lU-A1 for netlmm@ietf.org; Thu, 20 Sep 2007 12:44:27 -0400 Received: by hu-out-0506.google.com with SMTP id 31so213607huc for ; Thu, 20 Sep 2007 09:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=z9f3tjw84j9UTi+tdTSMfOBzTUgt72ZkuTpDku/mInw=; b=Wqn5azycmhyde7VJMX4yL2RUln8XtBy8OtIHs7O2gIIyX8UhmrDxYAf6g9He1+pEdIOFbQtEumTQ96KkkKThnTshI0o7dLbwXfkyBzqMJul5REmeUJ0LLoM+o4CYaivanbPeDd2u8us9Cb0Bt4cXRM3RMp0+M0U+IS/ttpjvIoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=qzVlW5mcfpA6aF0QQ0wV/U2o79lOy9b728u7Bk03RnPVhPkCKv/s+qVL5mLDqs71gWX5akn8QMryF2DLqRplTSZZVAdNMhUe8a/JcXp1SNwIUMQ/juQgqztVmUvfao/2ehYl5AYYg7qj2lyfURJAVWUN7SHlRbntUI0uKY3Ogr0= Received: by 10.67.28.3 with SMTP id f3mr256893ugj.1190306632799; Thu, 20 Sep 2007 09:43:52 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id m1sm591228uge.2007.09.20.09.43.51 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2007 09:43:52 -0700 (PDT) From: Julien Laganier To: Alexandru Petrescu Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Thu, 20 Sep 2007 18:43:49 +0200 User-Agent: KMail/1.9.6 References: <0MKpCa-1IYJHG03Hn-0007IL@mrelay.perfora.net> <46F26640.2090300@gmail.com> In-Reply-To: <46F26640.2090300@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709201843.49470.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex: I write my messages with great care, and I try to be as articulate as I can. You seem to think that is a problem "we guys" (whoever that includes) "talk DHCP", "don't rely on prototyping or deployment experience", etc. I don't want to argue with you about what I do. Let me just suggest that the main problem could be that *you* do not read carefully enough messages -- for example you are saying below "I don't think we can mandate DHCP in any way in PMIPv6". This is irrelevant since nobody ever said that DHCP should be *mandated*. Hence I think this discussion it unproductive at best and I will not continue it. --julien problem On Thursday 20 September 2007, Alexandru Petrescu wrote: > Alper Yegin wrote: > [...] > > >> And you keep telling me a certain SDO can support everything, this > >> is deceiving. I know many other SDOs who'll also support > >> everything. > > > > What is the problem? What is your proposal? I'm lost..... > > The problem is that you guys talk DHCP for PMIPv6 because you think a > certain SDO might require it in the future. The problem is also that > you guys don't rely on prototyping or deployment experience when you > request/reject DHCP presence; you only rely your claims on what other > SDOs want or might want. > > The proposal is to talk a little more implementation and/or > prototyping and see from these experiences how DHCP can fit in. Is > there a prototyping or full deployment experience with a MS using > DHCP over a ptp wireless access link? (not DSL, not wifi hotspot). > > Because if there isn't, then I don't think we can mandate DHCP in any > way in PMIPv6. > > Alex > > > Alper > > > >> Alex > >> > >> __________________________________________________________________ > >>____ This email has been scanned by the MessageLabs Email Security > >> System. For more information please visit > >> http://www.messagelabs.com/email > >> __________________________________________________________________ > >>____ > > _____________________________________________________________________ >_ This email has been scanned by the MessageLabs Email Security > System. For more information please visit > http://www.messagelabs.com/email > _____________________________________________________________________ >_ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 12:45:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYP9i-0007EE-Nm; Thu, 20 Sep 2007 12:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYP9h-0007E9-Iz for netlmm@ietf.org; Thu, 20 Sep 2007 12:45:33 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYP9g-0002oV-Cs for netlmm@ietf.org; Thu, 20 Sep 2007 12:45:33 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1399069uge for ; Thu, 20 Sep 2007 09:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=aLun/X8s/2+WsyaJPyb7h0HnMznEMBPyru0P2clcOao=; b=h6GMu0JAIcmuN2WiCRF0suRQhNdKRdJ64kfYUfZzrgSL2CSG/OtVHVJt0rkK3UICZuc23A3LJV6+dO+B7+3NvwWE2vt4aAL25gy39ZgJqwqPNz0XMwxWae2b6/JoXw8t8VMrrrycYZIKJ6VMfPgBVDY/paY7OWPDHcbanQJMZpk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=n9OJijlL5Kg4T0QTDvg7xloArze82YYOjKhYqX8uV9wah/eo+Gc8VLEas6Q299FHxptqOsUbA2P/wDc1/mt9ifn2G4PbjRMtQKGdeK9K7Y7Stjy3RdWanaVeI4FNqYjMtEjA2sqDj/3l58/ox7YK9npL9IKICdZAHSvWeVXzJBg= Received: by 10.66.224.3 with SMTP id w3mr3360948ugg.1190306727061; Thu, 20 Sep 2007 09:45:27 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id o30sm558730ugd.2007.09.20.09.45.25 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2007 09:45:26 -0700 (PDT) From: Julien Laganier To: "Chowdhury, Kuntal" Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 18:45:23 +0200 User-Agent: KMail/1.9.6 References: <7CCD07160348804497EF29E9EA5560D7024DA62B$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA62B$0001@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709201845.23964.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Kuntal, On Thursday 20 September 2007, Chowdhury, Kuntal wrote: > [..] > > Anyway, the point is that SLAAC is the predominant IPv6 address > config mechanism. It is widely adopted and implemented. Use of DHCPv6 > for address configuration is not that popular and I am not sure > whether it is even used anywhere or not. I do not think this mailing list and working group are the right places to debate about merits and popularity of DHCP and SLAAC. Both are standard track IETF specification for address allocation, hence we should not prevent use of either. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 12:50:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPE2-0001fX-Vg; Thu, 20 Sep 2007 12:50:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPE1-0001ak-M6 for netlmm@ietf.org; Thu, 20 Sep 2007 12:50:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYPE1-0004rR-02 for netlmm@ietf.org; Thu, 20 Sep 2007 12:50:01 -0400 X-IronPort-AV: E=Sophos;i="4.20,279,1186383600"; d="scan'208";a="400597685" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 20 Sep 2007 09:49:17 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8KGnGis018255; Thu, 20 Sep 2007 09:49:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8KGnGX1002011; Thu, 20 Sep 2007 16:49:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 09:49:15 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 09:49:15 -0700 From: "Sri Gundavelli" To: "'Julien Laganier'" , "'Chowdhury, Kuntal'" References: <7CCD07160348804497EF29E9EA5560D7024DA62B$0001@exchtewks2.starentnetworks.com> <200709201845.23964.julien.IETF@laposte.net> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 09:49:14 -0700 Message-ID: <00b801c7fba6$2d6e3a50$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <200709201845.23964.julien.IETF@laposte.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf7pabN7Ba1+UaWS/SW8Q7QY+z8zAAAFwtg X-OriginalArrivalTime: 20 Sep 2007 16:49:15.0831 (UTC) FILETIME=[2E010470:01C7FBA6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1145; t=1190306956; x=1191170956; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20DHCPv6=20deployment=20in=20PMIPv6=20domain=20(Was=3A= 20[netlmm]Commentsondraft-05) |Sender:=20; bh=wKmzFw1P6ODTiQrglcvDy5WzQyJufz/ewJeqeUe0GSc=; b=l7e3kQJtwz1zXzc8+Oow9daLcu6v9ah865O4p7Fb2maB2+mzH6cWTW51li1Wp+yoaMcrlJjj Xoh3LhuxbVMd4iPO6xpWkMEb1KhUlQO5DY92YtOxjODwLfc/mt16i/CC; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On > Behalf Of Julien Laganier > Sent: Thursday, September 20, 2007 9:45 AM > To: Chowdhury, Kuntal > Cc: Sri Gundavelli; Alper Yegin; netlmm@ietf.org > Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: > [netlmm]Commentsondraft-05) > > Kuntal, > > On Thursday 20 September 2007, Chowdhury, Kuntal wrote: > > [..] > > > > Anyway, the point is that SLAAC is the predominant IPv6 address > > config mechanism. It is widely adopted and implemented. Use > of DHCPv6 > > for address configuration is not that popular and I am not sure > > whether it is even used anywhere or not. > > I do not think this mailing list and working group are the > right places > to debate about merits and popularity of DHCP and SLAAC. > > Both are standard track IETF specification for address > allocation, hence > we should not prevent use of either. > I agree with this. The point is that the PMIP6 spec will interoperate with other standard specs. If a given deployment chooses SLAAC or DHCPv6 is not our business. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 12:51:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPFV-0002m0-TZ; Thu, 20 Sep 2007 12:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPFQ-0002iJ-Ra for netlmm@ietf.org; Thu, 20 Sep 2007 12:51:28 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYPFP-0002zq-1C for netlmm@ietf.org; Thu, 20 Sep 2007 12:51:28 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1190307071!4778779!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 3489 invoked from network); 20 Sep 2007 16:51:11 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-8.tower-153.messagelabs.com with SMTP; 20 Sep 2007 16:51:11 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l8KGpBjA014547; Thu, 20 Sep 2007 09:51:11 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8KGpAAl019554; Thu, 20 Sep 2007 11:51:10 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-94.corp.mot.com [10.169.4.94]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8KGp5D5019485; Thu, 20 Sep 2007 11:51:06 -0500 (CDT) Message-ID: <46F2A4F8.5070404@gmail.com> Date: Thu, 20 Sep 2007 18:51:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) References: <0MKp8S-1IYI3l1CUU-0008Rk@mrelay.perfora.net> <7CCD07160348804497EF29E9EA5560D7024DA628@exchtewks2.starentnetworks.com> <009101c7fb92$9c665e60$d5f6200a@amer.cisco.com> <46F28594.6020600@gmail.com> <00a901c7fb9d$1d8b1580$d5f6200a@amer.cisco.com> In-Reply-To: <00a901c7fb9d$1d8b1580$d5f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, Sri Gundavelli wrote: >> Sri Gundavelli wrote: >>>> -----Original Message----- From: Chowdhury, Kuntal >>>> [mailto:kchowdhury@starentnetworks.com] Sent: Thursday, >>>> September 20, 2007 7:14 AM To: Alper Yegin; Julien Laganier Cc: >>>> netlmm@ietf.org Subject: RE: DHCPv6 deployment in PMIPv6 >>>> domain (Was: [netlmm]Commentsondraft-05) >>>> >>>> Question for clarification: >>>> >>>> Is DHCPv6 used for IPv6 address config for a host? If yes, >>>> could you please point out which DHCPv6 option is used for >>>> that? >>>> >>> RFC-3315. >> >> Like at least for example how is the DHCP CONFIRM message used? How >> or is REBIND used or not? >> >> Do they happen before or after the P-BU/P-BAck? Not clear in the >> pictures of draft-05. >> > > If you see Fig 2, Section 3. the "Address Configuration" is after the > MN receives the RA. This is specified in other places as well. The > draft did not go into the details of the DHCP signaling. Once, the > PMIP signaling is complete and MAG advertises the prefix on the MN-AR > link, after that point its a normal IPv6 link and the regular DHCP6 > messages can flow through. Its like in fixed infrastructures. Let me > know, if there is any ambiguity in the text. Right... regular. But still. For example, draft v5: > When stateful address autoconfiguration is supported on the link, the > mobile node can obtain the address configuration from the DHCPv6 > server using DHCPv6 client protocol, as specified in DHCPv6 > specification [RFC-3315]. When DHCPv6 is used and the mobile does a handover by disconnecting from the old link and connecting to the new link then the mobile doesn't auto-configure a new address, or going from standby to live mode - it reuses the old one. So it does not 'obtain' a new address instead it tells the Server to use the old one, with the CONFIRM message. It can be rejected by the Server, but our intent here is of course to use same address on every MAG. This is what happens on shared links now. In a PMIP6 system one wouldn't like mobile to use RENEW, also because mobile would keep same address. Then for all DHCPv6 message we can make thoughts about which are more appropriated to a PMIP6 domain where the mobile doesn't change its address. All this for PMIPv6 on systems with wireless access as shared links, not point-to-point. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 12:53:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPHZ-0006qo-QV; Thu, 20 Sep 2007 12:53:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPHY-0006lO-EN for netlmm@ietf.org; Thu, 20 Sep 2007 12:53:40 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYPHX-00033n-74 for netlmm@ietf.org; Thu, 20 Sep 2007 12:53:40 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1190307217!7538601!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 17135 invoked from network); 20 Sep 2007 16:53:38 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-13.tower-153.messagelabs.com with SMTP; 20 Sep 2007 16:53:38 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l8KGrb4e015065; Thu, 20 Sep 2007 09:53:37 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8KGramO021514; Thu, 20 Sep 2007 11:53:36 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-94.corp.mot.com [10.169.4.94]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8KGrVHx021437; Thu, 20 Sep 2007 11:53:33 -0500 (CDT) Message-ID: <46F2A589.40401@gmail.com> Date: Thu, 20 Sep 2007 18:53:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <46F23CF5.2090209@gmail.com> <200709201319.30236.julien.IETF@laposte.net> <46F268B8.7050809@gmail.com> <200709201842.35033.julien.IETF@laposte.net> In-Reply-To: <200709201842.35033.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > On Thursday 20 September 2007, Alexandru Petrescu wrote: >> [...] let's focus on how can we require DHCP in the PMIPv6 protocol. > > ?! > > Nobody wants to "require DHCP in the PMIPv6 protocol", whatever that > means. Sorry, but I would like to see PMIPv6 interact ok with DHCP, in implementation. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 12:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPLF-0004hV-Es; Thu, 20 Sep 2007 12:57:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPLD-0004Zz-8l for netlmm@ietf.org; Thu, 20 Sep 2007 12:57:27 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYPL3-00054O-Hh for netlmm@ietf.org; Thu, 20 Sep 2007 12:57:18 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1190307435!12597909!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 11768 invoked from network); 20 Sep 2007 16:57:16 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-128.messagelabs.com with SMTP; 20 Sep 2007 16:57:15 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l8KGvFr0015788; Thu, 20 Sep 2007 09:57:15 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l8KGvEQC018922; Thu, 20 Sep 2007 11:57:14 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-94.corp.mot.com [10.169.4.94]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8KGv5JE018794; Thu, 20 Sep 2007 11:57:09 -0500 (CDT) Message-ID: <46F2A65F.9040101@gmail.com> Date: Thu, 20 Sep 2007 18:57:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <0MKpCa-1IYJHG03Hn-0007IL@mrelay.perfora.net> <46F26640.2090300@gmail.com> <200709201843.49470.julien.IETF@laposte.net> In-Reply-To: <200709201843.49470.julien.IETF@laposte.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > Alex: > > I write my messages with great care, and I try to be as articulate as I > can. > > You seem to think that is a problem "we guys" (whoever that > includes) "talk DHCP", "don't rely on prototyping or deployment > experience", etc. I don't want to argue with you about what I do. > > Let me just suggest that the main problem could be that *you* do not > read carefully enough messages -- for example you are saying below "I > don't think we can mandate DHCP in any way in PMIPv6". This is > irrelevant since nobody ever said that DHCP should be *mandated*. > > Hence I think this discussion it unproductive at best and I will not > continue it. Sorry Julien, I may not read carefully all messages - my fault. Continuing to debate on whether we should have DHCP working ok with PMIPv6 is a good thing IMHO. I think DHCP over ptp links doesn't make much sense, I think you don't either. If you did you could have said at least that you've seen it. Sorry if any of my phrases look disrespectful about what you do. Alex > > --julien > > problem On Thursday 20 September 2007, Alexandru Petrescu wrote: >> Alper Yegin wrote: >> [...] >> >>>> And you keep telling me a certain SDO can support everything, this >>>> is deceiving. I know many other SDOs who'll also support >>>> everything. >>> What is the problem? What is your proposal? I'm lost..... >> The problem is that you guys talk DHCP for PMIPv6 because you think a >> certain SDO might require it in the future. The problem is also that >> you guys don't rely on prototyping or deployment experience when you >> request/reject DHCP presence; you only rely your claims on what other >> SDOs want or might want. >> >> The proposal is to talk a little more implementation and/or >> prototyping and see from these experiences how DHCP can fit in. Is >> there a prototyping or full deployment experience with a MS using >> DHCP over a ptp wireless access link? (not DSL, not wifi hotspot). >> >> Because if there isn't, then I don't think we can mandate DHCP in any >> way in PMIPv6. >> >> Alex >> >>> Alper >>> >>>> Alex >>>> >>>> __________________________________________________________________ >>>> ____ This email has been scanned by the MessageLabs Email Security >>>> System. For more information please visit >>>> http://www.messagelabs.com/email >>>> __________________________________________________________________ >>>> ____ >> _____________________________________________________________________ >> _ This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> _____________________________________________________________________ >> _ > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 13:19:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPgG-0001RK-GL; Thu, 20 Sep 2007 13:19:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPgE-0001Oc-KE for netlmm@ietf.org; Thu, 20 Sep 2007 13:19:10 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYPgD-0005pc-R4 for netlmm@ietf.org; Thu, 20 Sep 2007 13:19:10 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8KHISbW020720; Thu, 20 Sep 2007 19:18:28 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 20 Sep 2007 19:19:07 +0200 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: DHCPv6 deployment in PMIPv6 domain (Was:[netlmm]Commentsondraft-05) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 20 Sep 2007 19:18:49 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A9C@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <00b101c7fba0$5545ded0$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 deployment in PMIPv6 domain (Was:[netlmm]Commentsondraft-05) thread-index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcAAAAs9gAABRKeAAAA1LoAAB80YAAADS2xAAAD53sAACYTQQ References: <00a201c7fb9c$0eed6f60$d5f6200a@amer.cisco.com><7CCD07160348804497EF29E9EA5560D7024DA635$0001@exchtewks2.starentnetworks.com> <00b101c7fba0$5545ded0$d5f6200a@amer.cisco.com> From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" X-OriginalArrivalTime: 20 Sep 2007 17:19:07.0248 (UTC) FILETIME=[59C58F00:01C7FBAA] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi, the conclusion in this thread is a bit surprising to me. There is nothing wrong with SLAAC AFAIK, but whether addresses are = managed or not, I guess it's the decision of the network administrator After all, the hiopt draft is defined to provide the HoA via DHCPv6, = isn't it? =20 Anyway, I presume that this discussion is out of scope Regards federico -----Message d'origine----- De : Sri Gundavelli [mailto:sgundave@cisco.com]=20 Envoy=E9 : jeudi 20 septembre 2007 18:07 =C0 : 'Chowdhury, Kuntal'; 'Alper Yegin'; 'Julien Laganier' Cc : netlmm@ietf.org Objet : RE: DHCPv6 deployment in PMIPv6 domain = (Was:[netlmm]Commentsondraft-05) =20 > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Thursday, September 20, 2007 9:00 AM > To: Sri Gundavelli; Alper Yegin; Julien Laganier > Cc: netlmm@ietf.org > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was:=20 > [netlmm]Commentsondraft-05) >=20 >=20 >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Thursday, September 20, 2007 10:37 AM > > To: Chowdhury, Kuntal; 'Alper Yegin'; 'Julien Laganier' > > Cc: netlmm@ietf.org > > Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: > > [netlmm]Commentsondraft-05) > >=20 > >=20 > > > > > > > [KC>] I also thought so, until someone told me that DHCPv6 is=20 > > > primarily used for prefix delegation and NOT address assignment to = > > > a host. If you > >=20 > > Kuntal, > >=20 > > Not sure, what the confusion is. > >=20 > > 3315 is the basic IPv6 DHCP Protocol > > 3633 is for DHCP IPv6 Prefix Delegation. > >=20 > > So, the host addressing is in the base spec and the PD is in 3633. > >=20 > [KC>] OK Sri. I get your point and thanks for the clarification. I am=20 > yet to see wide scale use of DHCPv6 for address config in the=20 > wireless/SDO world. That's why; perhaps my opinion is skewed towards=20 > SLAAC :-) >=20 I agree. SLAAC is the way to go.=20 Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 13:19:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPgT-0001u9-R3; Thu, 20 Sep 2007 13:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPgS-0001pg-9i for netlmm@ietf.org; Thu, 20 Sep 2007 13:19:24 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYPgI-0003rD-6W for netlmm@ietf.org; Thu, 20 Sep 2007 13:19:24 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8KHISbY020720; Thu, 20 Sep 2007 19:18:28 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.32]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 20 Sep 2007 19:19:07 +0200 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: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 20 Sep 2007 19:19:07 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399A9E@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <46F26640.2090300@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO thread-index: Acf7gcR45oo0O3WcRCyGt4y1Pvby2AAI9zFA References: <0MKpCa-1IYJHG03Hn-0007IL@mrelay.perfora.net> <46F26640.2090300@gmail.com> From: "DE JUAN HUARTE FEDERICO" To: "Alexandru Petrescu" X-OriginalArrivalTime: 20 Sep 2007 17:19:07.0685 (UTC) FILETIME=[5A083D50:01C7FBAA] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, nobody asked to mandate DHCP I heard a request to consider potential constraints to be taken into = account when using DHCP in the context of PMIP To be honest, I have not really understood why such constraints would be = PMIP specific, but if they were it would be fair to add them You seem to consider PPP as a MUST for point-to-point links. More = specifically for wireless point-to-point links We can agree to disagree and move on as this will not make a difference = in the specification What the specification concerns, I think that it should be enough to = just mention that the serving MAG can learn the IP@ assigned to the MN = via several mechanisms which are out of scope Regards federico -----Message d'origine----- De : Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Envoy=E9 : jeudi 20 septembre 2007 14:23 =C0 : Alper Yegin Cc : netlmm@ietf.org; 'Julien Laganier' Objet : Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Alper Yegin wrote: [...] >> And you keep telling me a certain SDO can support everything, this is = >> deceiving. I know many other SDOs who'll also support everything. >=20 > What is the problem? What is your proposal? I'm lost..... The problem is that you guys talk DHCP for PMIPv6 because you think a = certain SDO might require it in the future. The problem is also that = you guys don't rely on prototyping or deployment experience when you = request/reject DHCP presence; you only rely your claims on what other = SDOs want or might want. The proposal is to talk a little more implementation and/or prototyping = and see from these experiences how DHCP can fit in. Is there a = prototyping or full deployment experience with a MS using DHCP over a = ptp wireless access link? (not DSL, not wifi hotspot). Because if there isn't, then I don't think we can mandate DHCP in any = way in PMIPv6. Alex >=20 > Alper >=20 >=20 >=20 >=20 >=20 >> Alex >>=20 >> _____________________________________________________________________ >> _ This email has been scanned by the MessageLabs Email Security=20 >> System. For more information please visit=20 >> http://www.messagelabs.com/email=20 >> _____________________________________________________________________ >> _ >>=20 >=20 >=20 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email = ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 13:23:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPkK-0006i6-Gw; Thu, 20 Sep 2007 13:23:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPkJ-0006h4-5z for netlmm@ietf.org; Thu, 20 Sep 2007 13:23:23 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYPkC-0003yM-T3 for netlmm@ietf.org; Thu, 20 Sep 2007 13:23:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 4579FA8065 for ; Thu, 20 Sep 2007 13:23:03 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04237-10 for ; Thu, 20 Sep 2007 13:23:02 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 20 Sep 2007 13:23:02 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 13:20:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 13:20:33 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA63A@exchtewks2.starentnetworks.com> In-Reply-To: <200709201845.23964.julien.IETF@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05) Thread-Index: Acf7pVR7G2iC2FaySKGex4qH71TipAABHc7A From: "Chowdhury, Kuntal" To: "Julien Laganier" X-OriginalArrivalTime: 20 Sep 2007 17:20:33.0701 (UTC) FILETIME=[8D4D3D50:01C7FBAA] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: julien laganier [mailto:julien.laganier@gmail.com] On Behalf Of > Julien Laganier > Sent: Thursday, September 20, 2007 11:45 AM > To: Chowdhury, Kuntal > Cc: Sri Gundavelli; Alper Yegin; netlmm@ietf.org > Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was: > [netlmm]Commentsondraft-05) >=20 > Kuntal, >=20 > On Thursday 20 September 2007, Chowdhury, Kuntal wrote: > > [..] > > > > Anyway, the point is that SLAAC is the predominant IPv6 address > > config mechanism. It is widely adopted and implemented. Use of DHCPv6 > > for address configuration is not that popular and I am not sure > > whether it is even used anywhere or not. >=20 > I do not think this mailing list and working group are the right places > to debate about merits and popularity of DHCP and SLAAC. >=20 [KC>] I totally disagree. Continuing to debate over things that are unlikely to be used is not a meaningful way to use this list either. > Both are standard track IETF specification for address allocation, hence > we should not prevent use of either. >=20 [KC>] I don't think the debate is about preventing the use of DHCPv6 with PMIP6. The debate is more on practicality and the use case. So, far the use cases are heavily skewed towards SLAAC. > --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 13:24:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPlm-0007zX-BZ; Thu, 20 Sep 2007 13:24:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPll-0007zC-12 for netlmm@ietf.org; Thu, 20 Sep 2007 13:24:53 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYPlk-00063Q-FT for netlmm@ietf.org; Thu, 20 Sep 2007 13:24:52 -0400 X-IronPort-AV: E=Sophos;i="4.20,279,1186383600"; d="scan'208";a="400612175" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 20 Sep 2007 10:24:52 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8KHOpvw030423; Thu, 20 Sep 2007 10:24:51 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l8KHOpNd003712; Thu, 20 Sep 2007 17:24:51 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:24:50 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:24:50 -0700 From: "Sri Gundavelli" To: "'DE JUAN HUARTE FEDERICO'" References: <00a201c7fb9c$0eed6f60$d5f6200a@amer.cisco.com><7CCD07160348804497EF29E9EA5560D7024DA635$0001@exchtewks2.starentnetworks.com> <00b101c7fba0$5545ded0$d5f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A501399A9C@FRVELSMBS12.ad2.ad.alcatel.com> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was:[netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 10:24:49 -0700 Message-ID: <00c301c7fbab$25e3e460$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <319D54578EAC3147BA8CC78DAB5467A501399A9C@FRVELSMBS12.ad2.ad.alcatel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcAAAAs9gAABRKeAAAA1LoAAB80YAAADS2xAAAD53sAACYTQQAABHOLA= X-OriginalArrivalTime: 20 Sep 2007 17:24:50.0829 (UTC) FILETIME=[268FDBD0:01C7FBAB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1220; t=1190309091; x=1191173091; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20DHCPv6=20deployment=20in=20PMIPv6=20domain=20(Was=3A[ netlmm]Commentsondraft-05) |Sender:=20; bh=GdT0NS3dpKQ+ToSyh6f+a+6OjHrFp8gSG4UzogbkNp0=; b=nzcAVgvw1Th0UonmfAiQfKAxYouLeFZ3S3xhxRhVzcPUqI8f8CSTwMVqFTGefdIBtuG5jr62 3Lu/iKFUgl8RJcNHwrPvyutCeHfingbpJZhm59plXmMWQQxFisVrLF+H6TN/0rmA3DER58gFOs qbCHQ5SzMetwWFV8/2EEZBg2s=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, > -----Original Message----- > From: DE JUAN HUARTE FEDERICO > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > Sent: Thursday, September 20, 2007 10:19 AM > To: Sri Gundavelli > Cc: netlmm@ietf.org; Chowdhury, Kuntal; Alper Yegin; Julien Laganier > Subject: RE: DHCPv6 deployment in PMIPv6 domain > (Was:[netlmm]Commentsondraft-05) > > Hi, > > the conclusion in this thread is a bit surprising to me. > There is nothing wrong with SLAAC AFAIK, but whether > addresses are managed or not, I guess it's the decision of > the network administrator > > After all, the hiopt draft is defined to provide the HoA via > DHCPv6, isn't it? > > Anyway, I presume that this discussion is out of scope > :) More confusion. There is no conclusion here. I only expressed my preference for address configuration based on SLAAC. No way, that implies, we are not supporting DHCP based addressing. Both, are equally supported with out any preference. Sorry for the confusion. Lets close this thread. Just to conclude, Julien's point was that we may have to add one or two points on the use of DHCPv6 in PMIP6. We will do that. We should close this thread now. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 13:34:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPuf-0006fO-JU; Thu, 20 Sep 2007 13:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPud-0006Z7-DC for netlmm@ietf.org; Thu, 20 Sep 2007 13:34:03 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYPuc-0004Ok-4V for netlmm@ietf.org; Thu, 20 Sep 2007 13:34:03 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1190309614!16136085!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 25528 invoked from network); 20 Sep 2007 17:33:35 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-12.tower-128.messagelabs.com with SMTP; 20 Sep 2007 17:33:35 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l8KHXYWg023361; Thu, 20 Sep 2007 10:33:34 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l8KHXXrU020352; Thu, 20 Sep 2007 12:33:33 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-68.corp.mot.com [10.169.4.68]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8KHXTcu020295; Thu, 20 Sep 2007 12:33:30 -0500 (CDT) Message-ID: <46F2AEE7.3080706@gmail.com> Date: Thu, 20 Sep 2007 19:33:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: DE JUAN HUARTE FEDERICO Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <0MKpCa-1IYJHG03Hn-0007IL@mrelay.perfora.net> <46F26640.2090300@gmail.com> <319D54578EAC3147BA8CC78DAB5467A501399A9E@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A9E@FRVELSMBS12.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org DE JUAN HUARTE FEDERICO wrote: > Hi Alex, > > nobody asked to mandate DHCP Right... sorry if any confusion. I'm looking at DHCPv6 and PMIPv6. > I heard a request to consider potential constraints to be taken into > account when using DHCP in the context of PMIP What does this mean? What's that request? Where did you hear it? > To be honest, I have not really understood why such constraints would > be PMIP specific, but if they were it would be fair to add them I think requirements for PMIP are that the mobile doesn't change its address upon handoverer. Only a subset of DHCP features can make that possible. I think there's no other mobility WG that has such a requirement, that's why it makes it specific to PMIP. > You seem to consider PPP as a MUST for point-to-point links. More > specifically for wireless point-to-point links We can agree to > disagree and move on as this will not make a difference in the > specification That was another discussion I recently had on the 16ng WG. In this netlmm discussion I'm not saying PPP is a MUST for ptp links: instead of PPP one could use PDP-Context setup in 3G. In this netlmm discussion I'm saying that DHCP is not used on deployed ptp links. And if you disagree with this please point me to a prototype/implementation/demo that shows DHCP over a wireless ptp link for a mobile handset. Let's clarify this. > What the specification concerns, I think that it should be enough to > just mention that the serving MAG can learn the IP@ assigned to the > MN via several mechanisms which are out of scope No, I think this is too easy. It leaves open the door to interpretations like the previous that means that DHCP is on wireless ptp access links for mobile handsets - it's not. In some scenarios the serving MAG doesn't even learn the IP address assigned to the MN. I don't even know why the MAG should learn the IP address of the mobile at all, not even in the SLAAC case. Maybe you meant the prefix? Sorry, I don't know what you meant, trying to find out, not discarding. Alex > > Regards > > federico > > > > -----Message d'origine----- De : Alexandru Petrescu > [mailto:alexandru.petrescu@gmail.com] Envoyé : jeudi 20 septembre > 2007 14:23 À : Alper Yegin Cc : netlmm@ietf.org; 'Julien Laganier' > Objet : Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO > > Alper Yegin wrote: [...] >>> And you keep telling me a certain SDO can support everything, >>> this is deceiving. I know many other SDOs who'll also support >>> everything. >> What is the problem? What is your proposal? I'm lost..... > > The problem is that you guys talk DHCP for PMIPv6 because you think a > certain SDO might require it in the future. The problem is also > that you guys don't rely on prototyping or deployment experience when > you request/reject DHCP presence; you only rely your claims on what > other SDOs want or might want. > > The proposal is to talk a little more implementation and/or > prototyping and see from these experiences how DHCP can fit in. Is > there a prototyping or full deployment experience with a MS using > DHCP over a ptp wireless access link? (not DSL, not wifi hotspot). > > Because if there isn't, then I don't think we can mandate DHCP in any > way in PMIPv6. > > Alex > >> Alper >> >> >> >> >> >>> Alex >>> >>> _____________________________________________________________________ >>> _ This email has been scanned by the MessageLabs Email Security >>> System. For more information please visit >>> http://www.messagelabs.com/email >>> _____________________________________________________________________ >>> _ >>> >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security > System. For more information please visit > http://www.messagelabs.com/email > ______________________________________________________________________ > > > > > > _______________________________________________ netlmm mailing list > netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 13:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPxu-0002Ez-Av; Thu, 20 Sep 2007 13:37:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPxs-0002Ed-Vt for netlmm@ietf.org; Thu, 20 Sep 2007 13:37:25 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYPxs-0006Vh-AE for netlmm@ietf.org; Thu, 20 Sep 2007 13:37:24 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1190309842!8549520!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 25379 invoked from network); 20 Sep 2007 17:37:23 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-153.messagelabs.com with SMTP; 20 Sep 2007 17:37:23 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l8KHbMau024101; Thu, 20 Sep 2007 10:37:22 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l8KHbLTq023395; Thu, 20 Sep 2007 12:37:21 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-68.corp.mot.com [10.169.4.68]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8KHbH1p023336; Thu, 20 Sep 2007 12:37:18 -0500 (CDT) Message-ID: <46F2AFCB.2020609@gmail.com> Date: Thu, 20 Sep 2007 19:37:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was:[netlmm]Commentsondraft-05) References: <00a201c7fb9c$0eed6f60$d5f6200a@amer.cisco.com><7CCD07160348804497EF29E9EA5560D7024DA635$0001@exchtewks2.starentnetworks.com> <00b101c7fba0$5545ded0$d5f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A501399A9C@FRVELSMBS12.ad2.ad.alcatel.com> <00c301c7fbab$25e3e460$d5f6200a@amer.cisco.com> In-Reply-To: <00c301c7fbab$25e3e460$d5f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 'DE JUAN HUARTE FEDERICO' , netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri Gundavelli wrote: > Hi Federico, > > >> -----Original Message----- >> From: DE JUAN HUARTE FEDERICO >> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] >> Sent: Thursday, September 20, 2007 10:19 AM >> To: Sri Gundavelli >> Cc: netlmm@ietf.org; Chowdhury, Kuntal; Alper Yegin; Julien Laganier >> Subject: RE: DHCPv6 deployment in PMIPv6 domain >> (Was:[netlmm]Commentsondraft-05) >> >> Hi, >> >> the conclusion in this thread is a bit surprising to me. >> There is nothing wrong with SLAAC AFAIK, but whether >> addresses are managed or not, I guess it's the decision of >> the network administrator >> >> After all, the hiopt draft is defined to provide the HoA via >> DHCPv6, isn't it? >> >> Anyway, I presume that this discussion is out of scope >> > > :) > More confusion. There is no conclusion here. I only expressed > my preference for address configuration based on SLAAC. No way, > that implies, we are not supporting DHCP based addressing. Both, > are equally supported with out any preference. Sorry for the > confusion. Lets close this thread. > > Just to conclude, Julien's point was that we may have to add > one or two points on the use of DHCPv6 in PMIP6. We will do > that. We should close this thread now. Please don't close threads so quickly. Please let it develop and clarify. I agree on the intent of Julien's point to add one or two points on the use of DHCPv6 in PMIPv6. Alex > > > Sri > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 13:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPzX-0004O0-CU; Thu, 20 Sep 2007 13:39:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPzV-0004N6-Vw for netlmm@ietf.org; Thu, 20 Sep 2007 13:39:06 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYPzV-0006Yc-5Y for netlmm@ietf.org; Thu, 20 Sep 2007 13:39:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8KHcvBW026913; Thu, 20 Sep 2007 20:38:58 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 20:38:49 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 12:38:41 -0500 Received: from 172.19.244.179 ([172.19.244.179]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 20 Sep 2007 17:38:41 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 20 Sep 2007 12:38:40 -0500 Subject: Re: DHCPv6 deployment in PMIPv6 domain (Was:[netlmm]Commentsondraft-05) From: Basavaraj Patil To: federico de juan , Sri Gundavelli Message-ID: Thread-Topic: DHCPv6 deployment in PMIPv6 domain (Was:[netlmm]Commentsondraft-05) Thread-Index: Acf60f/Lrgw9hRvtQrK3IVbQTyZhJQAk/SdgAAqIXtAAAJEQcAAAAs9gAABRKeAAAA1LoAAB80YAAADS2xAAAD53sAACYTQQAADnm2A= In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399A9C@FRVELSMBS12.ad2.ad.alcatel.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Sep 2007 17:38:41.0497 (UTC) FILETIME=[15ADBC90:01C7FBAD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Federico, Just as an FYI: The Hiopt I-D ( draft-ietf-mip6-hiopt-06.txt) does not provide the HoA. -Raj On 9/20/07 12:18 PM, "ext DE JUAN HUARTE FEDERICO" wrote: > Hi, >=20 > the conclusion in this thread is a bit surprising to me. > There is nothing wrong with SLAAC AFAIK, but whether addresses are manage= d or > not, I guess it's the decision of the network administrator >=20 > After all, the hiopt draft is defined to provide the HoA via DHCPv6, isn'= t it? > =20 > Anyway, I presume that this discussion is out of scope >=20 > Regards >=20 > federico >=20 > -----Message d'origine----- > De : Sri Gundavelli [mailto:sgundave@cisco.com] > Envoy=E9 : jeudi 20 septembre 2007 18:07 > =C0 : 'Chowdhury, Kuntal'; 'Alper Yegin'; 'Julien Laganier' > Cc : netlmm@ietf.org > Objet : RE: DHCPv6 deployment in PMIPv6 domain > (Was:[netlmm]Commentsondraft-05) >=20 >=20 > =20 >=20 >> -----Original Message----- >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >> Sent: Thursday, September 20, 2007 9:00 AM >> To: Sri Gundavelli; Alper Yegin; Julien Laganier >> Cc: netlmm@ietf.org >> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: >> [netlmm]Commentsondraft-05) >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>> Sent: Thursday, September 20, 2007 10:37 AM >>> To: Chowdhury, Kuntal; 'Alper Yegin'; 'Julien Laganier' >>> Cc: netlmm@ietf.org >>> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was: >>> [netlmm]Commentsondraft-05) >>>=20 >>>=20 >>>>>=20 >>>> [KC>] I also thought so, until someone told me that DHCPv6 is >>>> primarily used for prefix delegation and NOT address assignment to >>>> a host. If you >>>=20 >>> Kuntal, >>>=20 >>> Not sure, what the confusion is. >>>=20 >>> 3315 is the basic IPv6 DHCP Protocol >>> 3633 is for DHCP IPv6 Prefix Delegation. >>>=20 >>> So, the host addressing is in the base spec and the PD is in 3633. >>>=20 >> [KC>] OK Sri. I get your point and thanks for the clarification. I am >> yet to see wide scale use of DHCPv6 for address config in the >> wireless/SDO world. That's why; perhaps my opinion is skewed towards >> SLAAC :-) >>=20 >=20 > I agree. SLAAC is the way to go. >=20 >=20 > Sri >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 20 13:50:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQAQ-000377-2l; Thu, 20 Sep 2007 13:50:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQAP-00034O-3m for netlmm@ietf.org; Thu, 20 Sep 2007 13:50:21 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYQAN-0004uM-Tq for netlmm@ietf.org; Thu, 20 Sep 2007 13:50:21 -0400 X-IronPort-AV: E=Sophos;i="4.20,279,1186383600"; d="scan'208";a="221959476" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Sep 2007 10:50:19 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8KHoJDx008914; Thu, 20 Sep 2007 10:50:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8KHnnEF022507; Thu, 20 Sep 2007 17:50:10 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:50:05 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 10:50:04 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" References: <00a201c7fb9c$0eed6f60$d5f6200a@amer.cisco.com><7CCD07160348804497EF29E9EA5560D7024DA635$0001@exchtewks2.starentnetworks.com> <00b101c7fba0$5545ded0$d5f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A501399A9C@FRVELSMBS12.ad2.ad.alcatel.com> <00c301c7fbab$25e3e460$d5f6200a@amer.cisco.com> <46F2AFCB.2020609@gmail.com> Subject: RE: DHCPv6 deployment in PMIPv6 domain (Was:[netlmm]Commentsondraft-05) Date: Thu, 20 Sep 2007 10:50:03 -0700 Message-ID: <00c501c7fbae$ac3cb750$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <46F2AFCB.2020609@gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf7rOp3sNknjHA+RluoCaPwY8+ShAAAZ6WQ X-OriginalArrivalTime: 20 Sep 2007 17:50:04.0743 (UTC) FILETIME=[ACECCD70:01C7FBAE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=395; t=1190310619; x=1191174619; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20DHCPv6=20deployment=20in=20PMIPv6=20domain=09(Was=3A[ netlmm]Commentsondraft-05) |Sender:=20; bh=QGtLE2RweOaLCUUdTaiHkvkzF3lN9mf92BWmh7+lamI=; b=nJ/lf0FXBZYcyaTEwIGdFRG4wvCj20LQPAt5ujTUr+MgmxBGA9k4Saizb8eU8l+044hsv3mf 4WhquP1uOIqPPXjWVIhWq3wHSrK/ez4YC7trRQ/WPv8dvYWCjNIc/jnN; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'DE JUAN HUARTE FEDERICO' , netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > > > > Just to conclude, Julien's point was that we may have to add > > one or two points on the use of DHCPv6 in PMIP6. We will do > > that. We should close this thread now. > > Please don't close threads so quickly. Please let it develop > and clarify. > Ok. > I agree on the intent of Julien's point to add one or two > points on the > use of DHCPv6 in PMIPv6. > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 01:37:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYbCL-0004JQ-QY; Fri, 21 Sep 2007 01:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYbCK-0004JH-P1 for netlmm@ietf.org; Fri, 21 Sep 2007 01:37:04 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYbCE-00053y-IP for netlmm@ietf.org; Fri, 21 Sep 2007 01:37:04 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 07:36:41 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Resolving Remaining Issues Date: Fri, 21 Sep 2007 07:36:41 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222CFD4@SEHAN021MB.tcad.telia.se> In-Reply-To: <46F21452.4070208@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Resolving Remaining Issues Thread-Index: Acf7UMG5KziCo78/QiS++BbORqStggAv8IzQ References: <46F21452.4070208@nomadiclab.com> From: To: , , X-OriginalArrivalTime: 21 Sep 2007 05:36:42.0179 (UTC) FILETIME=[63C42130:01C7FC11] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: basavaraj.patil@nokia.com X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I reviewed the -05 version of the document and what concerns issue #165 I am OK with the current text. This issue can be considered closed now. Cheers, Jouni > -------------------------------------------------------------- > ------------ >=20 > #165: Responsibility of Home Prefix Assignment >=20 > Monday, June 18, 2007, 9:35:44 AM | chvogt@tm.uka.de >=20 > Should the base PMIPv6 spec leave MN-HNP assignment=20 > exclusively to the LMA, or should it provide an option for=20 > the MAG to assign/retrieve the MN-HNP before it contacts the LMA? >=20 > This issue affects both v6 and v4 support. It was raised by=20 > Jouni Korhonen on 2007/06/09. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 05:23:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYeie-0004E4-9T; Fri, 21 Sep 2007 05:22:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYeid-0004C6-20 for netlmm@ietf.org; Fri, 21 Sep 2007 05:22:39 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYeic-0005Q8-Bx for netlmm@ietf.org; Fri, 21 Sep 2007 05:22:38 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id l8L9MW5H005095; Fri, 21 Sep 2007 11:22:32 +0200 Received: from nets138a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8L9MTOs018890; Fri, 21 Sep 2007 11:22:29 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets138a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Sep 2007 11:22:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: DHCPv6 deployment in PMIPv6domain (Was:[netlmm]Commentsondraft-05) Date: Fri, 21 Sep 2007 11:22:28 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6802A0CBA0@zagh223a.ww300.siemens.net> In-Reply-To: <00c501c7fbae$ac3cb750$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 deployment in PMIPv6domain (Was:[netlmm]Commentsondraft-05) Thread-Index: Acf7rOp3sNknjHA+RluoCaPwY8+ShAAAZ6WQACBcpIA= References: <00a201c7fb9c$0eed6f60$d5f6200a@amer.cisco.com><7CCD07160348804497EF29E9EA5560D7024DA635$0001@exchtewks2.starentnetworks.com> <00b101c7fba0$5545ded0$d5f6200a@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A501399A9C@FRVELSMBS12.ad2.ad.alcatel.com><00c301c7fbab$25e3e460$d5f6200a@amer.cisco.com><46F2AFCB.2020609@gmail.com> <00c501c7fbae$ac3cb750$d5f6200a@amer.cisco.com> From: "Premec, Domagoj" To: "Sri Gundavelli" , "Alexandru Petrescu" X-OriginalArrivalTime: 21 Sep 2007 09:22:29.0236 (UTC) FILETIME=[EE70FB40:01C7FC30] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070921112232-54E8FBB0-3916A70E/0-0/0-15 X-purgate-size: 1137/999999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org We should not prevent DHCPv6 to be used with PMIP6, it is up to a = network deployment to make this decision. If there are specific = deployment concerns, they should be documented in the draft. domagoj > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: 20. rujan 2007 19:50 > To: 'Alexandru Petrescu' > Cc: 'DE JUAN HUARTE FEDERICO'; netlmm@ietf.org; 'Julien Laganier' > Subject: RE: DHCPv6 deployment in PMIPv6domain=20 > (Was:[netlmm]Commentsondraft-05) >=20 >=20 > =20 > > >=20 > > > Just to conclude, Julien's point was that we may have to=20 > add one or=20 > > > two points on the use of DHCPv6 in PMIP6. We will do=20 > that. We should=20 > > > close this thread now. > >=20 > > Please don't close threads so quickly. Please let it develop and=20 > > clarify. > >=20 >=20 > Ok. >=20 > > I agree on the intent of Julien's point to add one or two points on=20 > > the use of DHCPv6 in PMIPv6. > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 05:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYeub-0000fq-PM; Fri, 21 Sep 2007 05:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYeub-0000VF-E2 for netlmm@ietf.org; Fri, 21 Sep 2007 05:35:01 -0400 Received: from cluster-g.mailcontrol.com ([85.115.41.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYeuP-0001vT-2k for netlmm@ietf.org; Fri, 21 Sep 2007 05:34:56 -0400 Received: from rly14g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly14g.srv.mailcontrol.com (MailControl) with ESMTP id l8L9YRr3018114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Sep 2007 10:34:29 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly14g.srv.mailcontrol.com (MailControl) id l8L9YLHM017753 for netlmm@ietf.org; Fri, 21 Sep 2007 10:34:21 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly14g-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8L9YFSm017536; Fri, 21 Sep 2007 10:34:20 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 407d_1bd7038a_6825_11dc_84db_0030482aac25; Fri, 21 Sep 2007 11:29:09 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092111341002-16274 ; Fri, 21 Sep 2007 11:34:10 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.097,BAYES_00: -1.665,TOTAL_SCORE: -1.568 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 21 Sep 2007 11:34:14 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-netlmm-proxymip6-05.txt Thread-Index: Acf8Mf/s6Vq1PtL7TIOvDsZjpXW1+Q== To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> Date: Fri, 21 Sep 2007 11:33:54 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.71.1.124 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: netlmm@ietf.org Subject: [netlmm] More comments on draft-ietf-netlmm-proxymip6-05.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri,=20 I quickly went through the new draft. Good work, it has improved a lot. However, I have some more comments: - According to section 5.3, the LMA is allowed to accept a de-registration PBU even if the PBU comes from an address different than the current Proxy-CoA in the BCE. I think this should not be be allowed - or only if the access link technology is able to detect the event that the MN leaves the MAG very quickly. The reason is that if the access link technology needs long time to detect the absence of the MN after a handover, the de-registration may be sent by the old MAG after the PBU from the new MAG is sent, which would delete the BCE and result in lack of session continuity. - Let's assume that the PBU from the new MAG after a handover is received at the LMA more than MinDelayBeforeBCEDelete (default: 1s) after the de-registration of the old MAG (e.g., due to long handover or network auth time or PBU delay). In this case, the LMA would delete the BCE for the MN before it receives the new PBU. I guess according the LMA would handle this PBU as initial registration and, i.e., allocate a new prefix to the MN, which means the session breaks. I think this scenario is not unlikely to occur with the current default value of only 1s for MinDelayBeforeBCEDelete. To be on the save side, I would propose a much higher default value, e.g., 30s. - The current text in section 5.3 may allow unauthorized nodes to find out whether a MN has a BCE at a specific LMA as well as the link-local address of the MN. "The Link-local Address option MUST be present in the Proxy Binding Acknowledgement message, if the same option was present in the corresponding Proxy Binding Update request message. If there is an existing Binding Cache entry for that mobile node with the link-local address value of ALL_ZERO (value not set), or if there was no existing Binding Cache entry, then the link-local address MUST be copied from the received Link-local Address option in the received Proxy Binding Update request. For all other cases, it MUST be copied from the Binding Cache entry. It should be clarified that the LMA may only copy the link-local address from the BCE in the PBA, if the PBU was valid (i.e., status code in PBA < 128).=20 - section 5.4 says=20 "Upon receipt of a Proxy Binding Update message with the Timestamp option, the local mobility anchor MUST check the timestamp field for validity. In order for it to be considered valid, the timestamp value contained in the Timestamp option MUST be close enough to the local mobility anchor's time-of-day clock and the timestamp MUST be greater than all previously accepted timestamps in the Proxy Binding Update messages sent for that mobile node." =20 "If the timestamp value in the received Proxy Binding Update is not valid, the local mobility anchor MUST reject the Proxy Binding Update and send a Proxy Binding Acknowledgement message with Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch). " According to this text, the TIMESTAMP_MISMATCH is sent everytime a PBU overtakes another PBU, even if MAGs and LMA are in sync. Any reason for this? I think the last paragraph should say=20 "if the timestamp value contained in the Timestamp option is not close enough to the local mobility anchor's time-of-day clock, the local mobility anchor MUST reject the Proxy Binding Update and send a Proxy Binding Acknowledgement message with Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch)." - There may be a problem if the host happens to activate more than one network interface (e.g., two WLAN interfaces) and as a result is attached to more than one MAG simultaneously. In this "error" case multiple MAGs would send PBUs for the same host and the BCE at the LMA would constantly change even though the host is not moving. Since the draft assumes unmodified hosts, I guess we can't mandate that the MN only activates one interface. However, it might be helpful for implementors to add some text that the base draft assumes only one active interface and that multiple interface support is future work. - Section 6.9.2 begins with "The mobile node sends a Router Solicitation message on the access link when ever the link-layer detects a media change.". I think this is only the case if the MN implements DNA. If MN doesn't implement DNA, it doesn't need to send RS when it changes links. - section 5.3 seems to be a bit underspecified: What should LMA do if it receives binding de-registration or re-registration with prefix 0::0? What should LMA do with incoming data packets after valid de-registration was received, but BCE still exists due to MinDelayBeforeBCEDelete? - The use of IPsec is not mandated according to section 4, but some "MUST"s in the text still rely on Ipsec (see section 5.3, 6.9.1, 11). E.g., "..It MUST use the SPI in the IPSec header [RFC-4306] of the received packet for locating the security association needed for authenticating the Proxy Binding Update request....The message MUST be protected by using IPsec," - Section 6.14 talks about PMIP-MIP interactions scenario B and hence should have an informative reference to draft-giaretta-netlmm-mip-interactions-01. BR, Kilian -------------------------------------------- Dr. Kilian Weniger Panasonic R&D Center Germany Monzastr. 4c, 63225 Langen, Germany phone: +49 (0)6103 766 137 fax: +49 (0)6103 766 166 e-mail: kilian.weniger@eu.panasonic.com -------------------------------------------- Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 05:39:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYeye-0000Ut-Ga; Fri, 21 Sep 2007 05:39:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYeyc-0000Kw-HE for netlmm@ietf.org; Fri, 21 Sep 2007 05:39:10 -0400 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYeyW-0001zL-8O for netlmm@ietf.org; Fri, 21 Sep 2007 05:39:10 -0400 Received: by rv-out-0910.google.com with SMTP id l15so729669rvb for ; Fri, 21 Sep 2007 02:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=e1OFJy3X7uBD3YnsQxAdtKvxWgIZFbXia4I8i0207jQ=; b=qeYi48uHaNcxlx0rW26A1n8MNw8N+eq2ksVHmKuaCzHWsjV1AkonySqGdcmmTz7IP8v04EDnpjVubckdZZFDAXHEELpteP49dKZLz33zf33rf4Vg9xHUa4a/2Iqocm7cHi1oR0s8iInGSX7xmgObpbQvJF1exzq7DYggyLolbQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=lRWiDjjKIZrvdTtpumRntyxplievKkVary0PX/HTbkbjPYC6GAhYghslJDv5Zhicfzs5+gMJy4QFdgl6wzOaFhWatRFDRxZNKjj6sAIIjNaoOGoPVSPDHt4EgHf45r6M8D9En4Ha7FZ+3H//0VbvUTGkRArnrk9kk+ry2Q9/pa4= Received: by 10.141.195.18 with SMTP id x18mr739454rvp.1190367526603; Fri, 21 Sep 2007 02:38:46 -0700 (PDT) Received: by 10.141.159.1 with HTTP; Fri, 21 Sep 2007 02:38:46 -0700 (PDT) Message-ID: <13e7c8c50709210238j1195b6a0y82bef0b7195da3c7@mail.gmail.com> Date: Fri, 21 Sep 2007 11:38:46 +0200 From: "Julien Laganier" To: netlmm@ietf.org, "Alexandru Petrescu" Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 60952d31821796d1 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Thursday 20 September 2007, Alexandru Petrescu wrote: > Julien Laganier wrote: > > Alex: > > > > I write my messages with great care, and I try to be as articulate > > as I can. > > > > You seem to think that is a problem "we guys" (whoever that > > includes) "talk DHCP", "don't rely on prototyping or deployment > > experience", etc. I don't want to argue with you about what I do. > > > > Let me just suggest that the main problem could be that *you* do > > not read carefully enough messages -- for example you are saying > > below "I don't think we can mandate DHCP in any way in PMIPv6". > > This is irrelevant since nobody ever said that DHCP should be > > *mandated*. > > > > Hence I think this discussion it unproductive at best and I will > > not continue it. > > Sorry Julien, I may not read carefully all messages - my fault. Alex, yesterday you posted 17 messages with that subject on the netlmmm mailing list, which were carefully read by at least some subscribers to the list. IMHO it would be fair that you take the necessary time to read carefully messages of your interlocutors. Further, let me suggest that if you would do so you might not need to post as many messages on the topic, and the discussion would be far more productive. I do not intend to follow-up anymore on that thread so there's no need to reply to me. --julien > Continuing to debate on whether we should have DHCP working ok with > PMIPv6 is a good thing IMHO. > > I think DHCP over ptp links doesn't make much sense, I think you > don't either. If you did you could have said at least that you've > seen it. > > Sorry if any of my phrases look disrespectful about what you do. > > Alex > > > --julien > > > > problem On Thursday 20 September 2007, Alexandru Petrescu wrote: > >> Alper Yegin wrote: > >> [...] > >> > >>>> And you keep telling me a certain SDO can support everything, > >>>> this is deceiving. I know many other SDOs who'll also support > >>>> everything. > >>> > >>> What is the problem? What is your proposal? I'm lost..... > >> > >> The problem is that you guys talk DHCP for PMIPv6 because you > >> think a certain SDO might require it in the future. The problem > >> is also that you guys don't rely on prototyping or deployment > >> experience when you request/reject DHCP presence; you only rely > >> your claims on what other SDOs want or might want. > >> > >> The proposal is to talk a little more implementation and/or > >> prototyping and see from these experiences how DHCP can fit in. > >> Is there a prototyping or full deployment experience with a MS > >> using DHCP over a ptp wireless access link? (not DSL, not wifi > >> hotspot). > >> > >> Because if there isn't, then I don't think we can mandate DHCP in > >> any way in PMIPv6. > >> > >> Alex > >> > >>> Alper > >>> > >>>> Alex _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 06:09:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYfRN-0000Mh-MM; Fri, 21 Sep 2007 06:08:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYfRM-0008Nz-1F for netlmm@ietf.org; Fri, 21 Sep 2007 06:08:52 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYfR4-0006G3-L9 for netlmm@ietf.org; Fri, 21 Sep 2007 06:08:35 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1190369313!29405952!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 26864 invoked from network); 21 Sep 2007 10:08:33 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-14.tower-119.messagelabs.com with SMTP; 21 Sep 2007 10:08:33 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8LA8W9c018368; Fri, 21 Sep 2007 03:08:33 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8LA8W9X000914; Fri, 21 Sep 2007 05:08:32 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8LA8TaU000816; Fri, 21 Sep 2007 05:08:30 -0500 (CDT) Message-ID: <46F39813.7080207@gmail.com> Date: Fri, 21 Sep 2007 12:08:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julien Laganier Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <13e7c8c50709210238j1195b6a0y82bef0b7195da3c7@mail.gmail.com> In-Reply-To: <13e7c8c50709210238j1195b6a0y82bef0b7195da3c7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Julien Laganier wrote: > On Thursday 20 September 2007, Alexandru Petrescu wrote: >> Julien Laganier wrote: >>> Alex: >>> >>> I write my messages with great care, and I try to be as >>> articulate as I can. >>> >>> You seem to think that is a problem "we guys" (whoever that >>> includes) "talk DHCP", "don't rely on prototyping or deployment >>> experience", etc. I don't want to argue with you about what I do. >>> >>> >>> >>> Let me just suggest that the main problem could be that *you* do >>> not read carefully enough messages -- for example you are saying >>> below "I don't think we can mandate DHCP in any way in PMIPv6". >>> This is irrelevant since nobody ever said that DHCP should be >>> *mandated*. >>> >>> Hence I think this discussion it unproductive at best and I will >>> not continue it. >> Sorry Julien, I may not read carefully all messages - my fault. > > Alex, yesterday you posted 17 messages with that subject on the > netlmmm mailing list, which were carefully read by at least some > subscribers to the list. > > IMHO it would be fair that you take the necessary time to read > carefully messages of your interlocutors. > > Further, let me suggest that if you would do so you might not need to > post as many messages on the topic, and the discussion would be far > more productive. > > I do not intend to follow-up anymore on that thread so there's no > need to reply to me. Julien if you have a problem with too many messages on the mailing list then please use filters, that's why I adapted the subject and keep it unchanged. Or you could count them and report and complain, but don't try to stop me saying that putting a DHCP Relay on the MAG for the sake of just doing it makes little sense. If we were to seriosuly deal with shared links in the PMIP6 spec then having a DHCP Relay in the MAG would make sense. And DNA and SeND and probably more. But PMIPv6 is not concerned at all about shared links, as the current spec reads. It makes no sense to put a DHCP Relay on the MAG as long as PMIPv6 deals only with point to point wireless access links. You said previously that DHCP is a std tracks IETF spec and as such in this WG we should not prevent it. This is not enough and too evasive: Have we checked all stds track documents are not prevented by PMIPv6? For example, L2TP is a nice tunnelling protocol for point to point links, used sometimes in DSL-like environments: does PMIPv6 support or prevent its use? The fact is that nobody tried to use L2TP on a wireless access link for mobiles, thus it makes no sense to suggest that MAG would need to run L2TP. Thanks for your mail, Alex > > --julien > >> Continuing to debate on whether we should have DHCP working ok with >> PMIPv6 is a good thing IMHO. >> >> I think DHCP over ptp links doesn't make much sense, I think you >> don't either. If you did you could have said at least that you've >> seen it. >> >> Sorry if any of my phrases look disrespectful about what you do. >> >> Alex >> >>> --julien >>> >>> problem On Thursday 20 September 2007, Alexandru Petrescu wrote: >>>> Alper Yegin wrote: [...] >>>> >>>>>> And you keep telling me a certain SDO can support >>>>>> everything, this is deceiving. I know many other SDOs >>>>>> who'll also support everything. >>>>> What is the problem? What is your proposal? I'm lost..... >>>> The problem is that you guys talk DHCP for PMIPv6 because you >>>> think a certain SDO might require it in the future. The >>>> problem is also that you guys don't rely on prototyping or >>>> deployment experience when you request/reject DHCP presence; >>>> you only rely your claims on what other SDOs want or might >>>> want. >>>> >>>> The proposal is to talk a little more implementation and/or >>>> prototyping and see from these experiences how DHCP can fit in. >>>> Is there a prototyping or full deployment experience with a MS >>>> using DHCP over a ptp wireless access link? (not DSL, not >>>> wifi hotspot). >>>> >>>> Because if there isn't, then I don't think we can mandate DHCP >>>> in any way in PMIPv6. >>>> >>>> Alex >>>> >>>>> Alper >>>>> >>>>>> Alex > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 08:08:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYhIZ-0007q0-Nt; Fri, 21 Sep 2007 08:07:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYhIZ-0007pn-Fo for netlmm@ietf.org; Fri, 21 Sep 2007 08:07:55 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYhIS-0005PP-Ak for netlmm@ietf.org; Fri, 21 Sep 2007 08:07:55 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1IYhI03bNo-0007Xa; Fri, 21 Sep 2007 08:07:28 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Fri, 21 Sep 2007 15:07:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf7c2xKH+OBvYtNQBur3IfURDjDjgA0nWdQ In-Reply-To: <46F24F51.4040500@gmail.com> Message-Id: <0MKpCa-1IYhI03bNo-0007Xa@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19+DDyKWKCrdBGP/JUHwepRxxgXZfhG3mP0EgC UgH4L5DH9oF/Ea3HujKSBj0HKeqUZt4jLSiK0BTYyUHmNmGEuz 8ZXc0GjO/NrcvB06fGkAg== X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex, > The problem is that you guys talk DHCP for PMIPv6 because you think a > certain SDO might require it in the future. The problem is also that > you guys don't rely on prototyping or deployment experience when you > request/reject DHCP presence; you only rely your claims on what other > SDOs want or might want. It is just unfortunate that you are making random assumptions about people, and trying to derive technical conclusions out of it. I don't think anyone appreciates that. > The proposal is to talk a little more implementation and/or prototyping > and see from these experiences how DHCP can fit in. Is there a > prototyping or full deployment experience with a MS using DHCP over a > ptp wireless access link? (not DSL, not wifi hotspot). Commercial WiBro deployment in Korea. Do you have any commercial deployment, or even theoretical technical point that suggests DHCP may have issues running over ptp wireless links? If not, what's more to say?!? Let both DHCP and SLAAC be acknowledged as possible ways to configure hosts in PMIP6 deployments. Some people (including myself) may have preference towards one or the other. But we'll take that up in other forums, not in IETF. > > WiMAX uses it. > > HAven't seen it, but you may have. Just read the WiMAX Forum NWG Release 1.0 Stage 3 spec. > > > I've been told UMTS and LTE are also using DHCP. > > Well let me tell you UMTS doesn't. Who told you UMTS uses DHCP on the > mobile? Read TS 23.401 v1.2.1 and TS 23.060 v7.3.0. > > > 3GPP2 evolution is dumping PPP, and will be using DHCP. > > That's surprising... so you mean my next mobile phone will use DHCP? I cannot tell you what "your next mobile" will do. I'm telling you what other SDOs are doing. If this means nothing to you, I cannot do much about it. > BEcause the current 3G and UMTS phones I'm using don't run DHCP on the > wireless ptp access (they do on wifi). > > Do you realize how much change in the infrastructure that assumes? I'm not going to discuss this here. This goes all the way to business discussions. Nothing to do with IETF NETLMM WG. > Isn't this another speculation just like the one of a few years ago > saying that 3G will run IPv6? Same as my previous response. > > > DSL evolution is doing the same. > > DSL is not relevant here because DSL doesn't need PMIPv6 because nothing > moves with DSL deployments. There are various wireless and DSL interworking scenarios. So don't discount DSL relevance. > > To me all this list boils down to doing DHCPv6 in PMIPv6 only for > wireless shared access (and not for ptp links). Just wrong. Alper > > Alex > ... Alper > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Thursday, September 20, 2007 1:46 PM > To: Alper Yegin > Cc: 'Chowdhury, Kuntal'; netlmm@ietf.org; 'Julien Laganier' > Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO > > Alper Yegin wrote: > > Alex, > > > >>>> If so, I'm afraid it's the only one using DHCP over ptp > >>>> links(?), because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links and > >>>> don't use DHCP over them. > >>> Sorry I lost track of why this matters, even if that were the > >>> case. > >> Doing DHCP support for P-MIPv6 without knowing why we do it, and > >> without requirements - is senseless. > > > > WiFi uses it. > > WiFi hotspots - yes. That's PMIPv6 for wireless shared access. > > > WiMAX uses it. > > HAven't seen it, but you may have. > > > I've been told UMTS and LTE are also using DHCP. > > Well let me tell you UMTS doesn't. Who told you UMTS uses DHCP on the > mobile? > > > 3GPP2 evolution is dumping PPP, and will be using DHCP. > > That's surprising... so you mean my next mobile phone will use DHCP? > BEcause the current 3G and UMTS phones I'm using don't run DHCP on the > wireless ptp access (they do on wifi). > > Do you realize how much change in the infrastructure that assumes? > > Isn't this another speculation just like the one of a few years ago > saying that 3G will run IPv6? > > > DSL evolution is doing the same. > > DSL is not relevant here because DSL doesn't need PMIPv6 because nothing > moves with DSL deployments. > > To me all this list boils down to doing DHCPv6 in PMIPv6 only for > wireless shared access (and not for ptp links). > > Alex > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 08:30:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYhdg-0007GI-Ie; Fri, 21 Sep 2007 08:29:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYhde-0007Cb-WE for netlmm@ietf.org; Fri, 21 Sep 2007 08:29:43 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYhdd-0001jp-Ur for netlmm@ietf.org; Fri, 21 Sep 2007 08:29:42 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1190377781!23027032!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30302 invoked from network); 21 Sep 2007 12:29:41 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 21 Sep 2007 12:29:41 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8LCTf62001470; Fri, 21 Sep 2007 05:29:41 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l8LCTeEc007386; Fri, 21 Sep 2007 07:29:40 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8LCTcxS007326; Fri, 21 Sep 2007 07:29:39 -0500 (CDT) Message-ID: <46F3B92C.6000402@gmail.com> Date: Fri, 21 Sep 2007 14:29:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <0MKpCa-1IYhI03bNo-0007Xa@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IYhI03bNo-0007Xa@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: [...] >> The proposal is to talk a little more implementation and/or >> prototyping and see from these experiences how DHCP can fit in. Is >> there a prototyping or full deployment experience with a MS using >> DHCP over a ptp wireless access link? (not DSL, not wifi hotspot). >> >> > > Commercial WiBro deployment in Korea. Does the Commercial WiBro deployment in Korea use DHCP over the wibro wireless ptp access link? What is the protocol used to put the interface up? Does that protocol obtain/negotiate addresses and default route and DNS server address? Or only some? Which of those 3 are obtained by DHCP? Please give details (you do realize Korea systems aren't within everyone's reach.) > Do you have any commercial deployment, or even theoretical technical > point that suggests DHCP may have issues running over ptp wireless > links? If not, what's more to say?!? Well, here is the reasoning. I'll use 'GPRS' to stand for EDGE, UMTS and HSDPA links, I've tried them all. Several operators giving GPRS in EU and in the US offer the possibility to the mobile to dial up using ppp (I can name about 5 such operators). When that ppp puts the interface up the IPv4 address is already negotiated by LCP. There is no point to run DHCP over the ppp0 interface because it already has an address, a default route and the DNS server's address. I think it _is_ possible to tell ppp to not negotiate the IPv4 addresses and then run DHCP over the ppp0 interface. However, the networks I have tried have the AAA 'backend' like Radius plugged into PPP's LCP, not into DHCP. I think it _is_ possible to plug Radius on the DHCP, but at that point there is no need for DHCP Relay on MAG, because MAG would do DHCP Server. DHCP over ppp0 is probably possible, but why would one do it? What are the advantages over letting LCP (or PDP-Context setup) negotiate these addresses? > Let both DHCP and SLAAC be acknowledged as possible ways to configure > hosts in PMIP6 deployments. I agree with this. But I really don't see why would anybody put a DHCP Relay on the MAG running PMIPv6, because PMIPv6 only cares about ptp links and I haven't seen DHCP run on commercial ptp deployments on mobiles. You have cited one above (WiBro), could you please clarify it above thanks? > Some people (including myself) may have preference towards one or the > other. But we'll take that up in other forums, not in IETF. Outside forums let's talk here practical matters and deployment. Alex > >>> WiMAX uses it. >> HAven't seen it, but you may have. > > Just read the WiMAX Forum NWG Release 1.0 Stage 3 spec. > >>> I've been told UMTS and LTE are also using DHCP. >> Well let me tell you UMTS doesn't. Who told you UMTS uses DHCP on >> the mobile? > > Read TS 23.401 v1.2.1 and TS 23.060 v7.3.0. > >>> 3GPP2 evolution is dumping PPP, and will be using DHCP. >> That's surprising... so you mean my next mobile phone will use >> DHCP? > > I cannot tell you what "your next mobile" will do. I'm telling you > what other SDOs are doing. If this means nothing to you, I cannot do > much about it. > >> BEcause the current 3G and UMTS phones I'm using don't run DHCP on >> the wireless ptp access (they do on wifi). >> >> Do you realize how much change in the infrastructure that assumes? > > I'm not going to discuss this here. This goes all the way to business > discussions. Nothing to do with IETF NETLMM WG. > > >> Isn't this another speculation just like the one of a few years ago >> saying that 3G will run IPv6? > > Same as my previous response. > >>> DSL evolution is doing the same. >> DSL is not relevant here because DSL doesn't need PMIPv6 because >> nothing moves with DSL deployments. > > There are various wireless and DSL interworking scenarios. So don't > discount DSL relevance. > >> To me all this list boils down to doing DHCPv6 in PMIPv6 only for >> wireless shared access (and not for ptp links). > > Just wrong. > > Alper > > >> Alex >> > ... > > > > > > Alper > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, September 20, >> 2007 1:46 PM To: Alper Yegin Cc: 'Chowdhury, Kuntal'; >> netlmm@ietf.org; 'Julien Laganier' Subject: Re: [netlmm] Re: DHCPv6 >> deployment in PMIPv6 domain and SDO >> >> Alper Yegin wrote: >>> Alex, >>> >>>>>> If so, I'm afraid it's the only one using DHCP over ptp >>>>>> links(?), because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links >>>>>> and don't use DHCP over them. >>>>> Sorry I lost track of why this matters, even if that were the >>>>> case. >>>> Doing DHCP support for P-MIPv6 without knowing why we do it, >>>> and without requirements - is senseless. >>> WiFi uses it. >> WiFi hotspots - yes. That's PMIPv6 for wireless shared access. >> >>> WiMAX uses it. >> HAven't seen it, but you may have. >> >>> I've been told UMTS and LTE are also using DHCP. >> Well let me tell you UMTS doesn't. Who told you UMTS uses DHCP on >> the mobile? >> >>> 3GPP2 evolution is dumping PPP, and will be using DHCP. >> That's surprising... so you mean my next mobile phone will use >> DHCP? BEcause the current 3G and UMTS phones I'm using don't run >> DHCP on the wireless ptp access (they do on wifi). >> >> Do you realize how much change in the infrastructure that assumes? >> >> Isn't this another speculation just like the one of a few years ago >> saying that 3G will run IPv6? >> >>> DSL evolution is doing the same. >> DSL is not relevant here because DSL doesn't need PMIPv6 because >> nothing moves with DSL deployments. >> >> To me all this list boils down to doing DHCPv6 in PMIPv6 only for >> wireless shared access (and not for ptp links). >> >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 08:44:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYhrc-0007mx-2i; Fri, 21 Sep 2007 08:44:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYhra-0007Y5-Sr for netlmm@ietf.org; Fri, 21 Sep 2007 08:44:07 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYhrK-00027K-2d for netlmm@ietf.org; Fri, 21 Sep 2007 08:43:50 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1190378626!29415643!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30854 invoked from network); 21 Sep 2007 12:43:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 21 Sep 2007 12:43:46 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8LChbdc004939; Fri, 21 Sep 2007 05:43:37 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8LChawO004716; Fri, 21 Sep 2007 07:43:37 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8LChZ5g004672; Fri, 21 Sep 2007 07:43:35 -0500 (CDT) Message-ID: <46F3BC71.3010307@gmail.com> Date: Fri, 21 Sep 2007 14:43:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1IYhI03bNo-0007Xa@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IYhI03bNo-0007Xa@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: netlmm@ietf.org, 'Julien Laganier' Subject: [netlmm] Re: SDO X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: [...] >>> I've been told UMTS and LTE are also using DHCP. >> >> Well let me tell you UMTS doesn't. Who told you UMTS uses DHCP on >> the mobile? > > Read TS 23.401 v1.2.1 and TS 23.060 v7.3.0. After you provide some pointers to it, of course, because I can't click on the above. (I think that not _all_ that these TS's say is required to be implemented and deployers choose some stuff before deploying). >>> 3GPP2 evolution is dumping PPP, and will be using DHCP. >> That's surprising... so you mean my next mobile phone will use >> DHCP? > > I cannot tell you what "your next mobile" will do. I'm telling you > what other SDOs are doing. If this means nothing to you, I cannot do > much about it. As I said previously, SDOs do many things on paper. >> BEcause the current 3G and UMTS phones I'm using don't run DHCP on >> the wireless ptp access (they do on wifi). >> >> Do you realize how much change in the infrastructure that assumes? > > I'm not going to discuss this here. This goes all the way to business > discussions. Nothing to do with IETF NETLMM WG. I don't understand. NETLMM is mostly about infrastructure, do you assume there is no infrastructure deployed? >> Isn't this another speculation just like the one of a few years ago >> saying that 3G will run IPv6? > > Same as my previous response. > >>> DSL evolution is doing the same. >> DSL is not relevant here because DSL doesn't need PMIPv6 because >> nothing moves with DSL deployments. > > There are various wireless and DSL interworking scenarios. So don't > discount DSL relevance. That's new to me. Do you mean ADSL forum may be interested in PMIPv6 and NETLMM WG? We've always discussed here PMIPv6 for mobiles, like handheld talking to basestation+infrastructure, not networks deployed in houses. >> To me all this list boils down to doing DHCPv6 in PMIPv6 only for >> wireless shared access (and not for ptp links). > > Just wrong. Let's see. Alex > > Alper > > >> Alex >> > ... > > > > > > Alper > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Thursday, September 20, >> 2007 1:46 PM To: Alper Yegin Cc: 'Chowdhury, Kuntal'; >> netlmm@ietf.org; 'Julien Laganier' Subject: Re: [netlmm] Re: DHCPv6 >> deployment in PMIPv6 domain and SDO >> >> Alper Yegin wrote: >>> Alex, >>> >>>>>> If so, I'm afraid it's the only one using DHCP over ptp >>>>>> links(?), because GPRS/EDGE/UMTS/HSDPA/3G all use ptp links >>>>>> and don't use DHCP over them. >>>>> Sorry I lost track of why this matters, even if that were the >>>>> case. >>>> Doing DHCP support for P-MIPv6 without knowing why we do it, >>>> and without requirements - is senseless. >>> WiFi uses it. >> WiFi hotspots - yes. That's PMIPv6 for wireless shared access. >> >>> WiMAX uses it. >> HAven't seen it, but you may have. >> >>> I've been told UMTS and LTE are also using DHCP. >> Well let me tell you UMTS doesn't. Who told you UMTS uses DHCP on >> the mobile? >> >>> 3GPP2 evolution is dumping PPP, and will be using DHCP. >> That's surprising... so you mean my next mobile phone will use >> DHCP? BEcause the current 3G and UMTS phones I'm using don't run >> DHCP on the wireless ptp access (they do on wifi). >> >> Do you realize how much change in the infrastructure that assumes? >> >> Isn't this another speculation just like the one of a few years ago >> saying that 3G will run IPv6? >> >>> DSL evolution is doing the same. >> DSL is not relevant here because DSL doesn't need PMIPv6 because >> nothing moves with DSL deployments. >> >> To me all this list boils down to doing DHCPv6 in PMIPv6 only for >> wireless shared access (and not for ptp links). >> >> Alex >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 10:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjRC-0004LS-QI; Fri, 21 Sep 2007 10:24:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjRB-0004LL-KV for netlmm@ietf.org; Fri, 21 Sep 2007 10:24:57 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYjRB-0005Br-2a for netlmm@ietf.org; Fri, 21 Sep 2007 10:24:57 -0400 X-IronPort-AV: E=Sophos;i="4.20,284,1186351200"; d="scan'208";a="153811743" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Sep 2007 16:24:56 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8LEOuZD017417; Fri, 21 Sep 2007 16:24:56 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8LEOYtx012491; Fri, 21 Sep 2007 14:24:51 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 16:24:34 +0200 Received: from sgundavewxp ([10.32.246.213]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 16:24:33 +0200 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" , "'Julien Laganier'" References: <13e7c8c50709210238j1195b6a0y82bef0b7195da3c7@mail.gmail.com> <46F39813.7080207@gmail.com> Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Fri, 21 Sep 2007 07:24:31 -0700 Message-ID: <015001c7fc5b$21c858b0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <46F39813.7080207@gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: Acf8OBORfJL1ZUFxT0ecZaS+Ll6UBgAIQlkw X-OriginalArrivalTime: 21 Sep 2007 14:24:34.0122 (UTC) FILETIME=[21B71AA0:01C7FC5B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=995; t=1190384696; x=1191248696; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Re=3A=20DHCPv6=20deployment=20in=20PMIPv6= 20domain=20and=20SDO |Sender:=20; bh=RgyVFXJH8V7Pz9T8HpBi7q+Xxi3irBTj/8a8W6v09fU=; b=fiA5X5ibkjXw8TDgc688VqzobWW6uARXtkmj50Q5umWjgHzIJ4oTWotUUdwoVhMWbWNlso78 xIUBloVeAptk4XUxP9i6f/O/DE64zugVUgzuLbBB5O+eoq3FcARBIFfb; Authentication-Results: ams-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > > It makes no sense to put a DHCP Relay on the MAG as long as PMIPv6 > deals only with point to point wireless access links. > Hi Alex, Its important to note that in PMIP6, we are mostly changing the topology of the network, by moving the HNP between different MAG's. Once the prefix is hosted on a given MAG, the DHCP related flows are consistent with the flows on fixed networks. So, we dont have any control on mandating not to enable DHCP relay on a given MN-AR link. Sure, its a p2p link, but its a regular IPv6 link and DHCP relay can be configured on that link. We are not defining any extensions are putting any hacks to make this work. It works naturally, the text is there for offering some minimum guidance. So, if this configuration maken sense or not, is really upto the deployment. Some operator may choose to use DHCP for downloading the address configuration and ther options, and I dont think, we can disallow that configuration. Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 10:56:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjva-0007x8-SN; Fri, 21 Sep 2007 10:56:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjvZ-0007un-VS for netlmm@ietf.org; Fri, 21 Sep 2007 10:56:22 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYjvZ-0005ys-5c for netlmm@ietf.org; Fri, 21 Sep 2007 10:56:21 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1190386579!12694508!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17535 invoked from network); 21 Sep 2007 14:56:20 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 21 Sep 2007 14:56:20 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8LEuF1v013642; Fri, 21 Sep 2007 07:56:15 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l8LEuE6K008786; Fri, 21 Sep 2007 09:56:14 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8LEuCab008737; Fri, 21 Sep 2007 09:56:13 -0500 (CDT) Message-ID: <46F3DB86.7080309@gmail.com> Date: Fri, 21 Sep 2007 16:56:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <13e7c8c50709210238j1195b6a0y82bef0b7195da3c7@mail.gmail.com> <46F39813.7080207@gmail.com> <015001c7fc5b$21c858b0$d5f6200a@amer.cisco.com> In-Reply-To: <015001c7fc5b$21c858b0$d5f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-4, 20/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri Gundavelli wrote: > > >> It makes no sense to put a DHCP Relay on the MAG as long as PMIPv6 >> deals only with point to point wireless access links. >> > > Hi Alex, > > Its important to note that in PMIP6, we are mostly changing the > topology of the network, by moving the HNP between different MAG's. > Once the prefix is hosted on a given MAG, the DHCP related flows are > consistent with the flows on fixed networks. So, we dont have any > control on mandating not to enable DHCP relay on a given MN-AR link. > Sure, its a p2p link, but its a regular IPv6 link and DHCP relay can > be configured on that link. We are not defining any extensions are > putting any hacks to make this work. It works naturally, the text is > there for offering some minimum guidance. So, if this configuration > maken sense or not, is really upto the deployment. Some operator may > choose to use DHCP for downloading the address configuration and ther > options, and I dont think, we can disallow that configuration. Sri, I mainly agree with you and with the intention you describe above. I do support having DHCP Relay functionality on MAG. But your text has a restiction on which I don't agree. It says: > 6.11. Interaction with DHCP Relay Agent > > If Stateful Address Configuration using DHCP is supported on the link > where the mobile node is attached, the DHCP relay agent [RFC-3315] > needs to be configured on that access link. Why Relay and not Server too? I mean why silent about Server? I think there may be a case for DHCP Server on the MAG. And then it has a description which I don't understand: > When the mobile node sends a DHCPv6 Request message, the DHCP relay > agent function on the access link will set the link-address field in > the DHCPv6 message to the mobile node's home network prefix, so as > to provide a prefix hint to the DHCP Server for the address pool > selection. You seem to assume DHCP Relay can use the HNP it received in P-BAck to put it into the DHCP Request, right? But I think usually the prefix of a relay is configured statically at MAG in a configuration file, or in its routing table. At DHCP Server that prefix is also configured statically in the DHCP Server's configuration file. I don't understand how you assume the HNP can come dynamically to MAG in the profile and then inserted by MAG as a hint in the DHCP Request and then delivered back by DHCP Server in the address allocation? I'm afraid it may be a vicious circle (chicken and egg problem) especially when the MAG-to-MN interfaces are ptp (each its own prefix) and ephemeral up/down and possibly one prefix is valid on different MAG at different times. Or do you propose to _modify_ the DHCP Relay and Server implementations? I would like to clarify this, thanks. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 21 15:11:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYnuI-0008Vf-Se; Fri, 21 Sep 2007 15:11:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYnuH-0008JF-Kh for netlmm@ietf.org; Fri, 21 Sep 2007 15:11:17 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYnu8-0006qR-6W for netlmm@ietf.org; Fri, 21 Sep 2007 15:11:10 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1190401866!6894869!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 18637 invoked from network); 21 Sep 2007 19:11:06 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-6.tower-153.messagelabs.com with SMTP; 21 Sep 2007 19:11:06 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8LJB6I0016212 for ; Fri, 21 Sep 2007 12:11:06 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l8LJB5Bb004157 for ; Fri, 21 Sep 2007 14:11:05 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8LJB30t004126 for ; Fri, 21 Sep 2007 14:11:03 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Sep 2007 14:14:01 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of Proxy Mobile IPv6 (draft-ietf-netlmm-proxymip6-05.txt) thread-index: Acf8dMaJPfCpPwEvTMeG0YtCrUU/wQ== From: "McCann Peter-A001034" To: X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 Cc: Subject: [netlmm] Review of Proxy Mobile IPv6 (draft-ietf-netlmm-proxymip6-05.txt) X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Technical Issues 4.2 Security Policy Database Entries mobile access gateway SPD-S: - IF local_address =3D mag_address_1 & remote_address =3D lma_address_1 & proto =3D MH & local_mh_type =3D BU & remote_mh_type =3D BA Then use SA ESP transport mode Initiate using IDi =3D mag_1 to address lma_1 Should that last line read "Initiate using IDi =3D mag_1 to address lma_address_1"? 5.1 Extensions to Binding Cache Entry Data Structure o A flag indicating whether or not this Binding Cache entry is created due to a proxy registration. This flag is enabled for Binding Cache entries that are proxy registrations and is turned off for all other entries that are created due to the registrations directly sent by the mobile node. This point seems to be related to the interaction of proxy MIP and client MIP using the same home agent. I think it would be best to leave this sort of detail to a separate document describing such interaction. There are many issues that must be dealt with in that case, such as how to put BUs in the right order. o The identifier of the registered mobile node, MN-Identifier. This identifier is obtained from the NAI Option [RFC-4283] present in the received Proxy Binding Update request. Isn't it intended that the MN-Identfier can be something other than NAI? For example, an L2 address? 5.3. Signaling Considerations o The local mobility anchor MUST identify the mobile node from the identifier present in the NAI option [RFC-4283] of the Proxy Here again the NAI is mandated. Binding De-Registration: ... o Upon accepting the request, the local mobility anchor MUST delete the mobile node's Binding Cache entry and remove the Routing state for the mobile node's home network prefix. This bullet seems to contradict the first bulllet in this sub-section, which states that the LMA must implement a hang timer. Maybe just=20 delete this bullet. Constructing the Proxy Binding Acknowledgement Message: ... o If the Status field is set to a value greater less than 128, i.e. if the binding request was rejected,=20 Does this mean to say "a value different from 128"? 5.4. Timestamp Option for Message Ordering and the node receiving the message checks that this timestamp is greater than all previously accepted timestamps. Shouldn't there be a check that the timestamp is somewhere close to the current time of day, to prevent a misconfigured MAG from blocking all registrations for a period fo time, by sending a message stamped sometime in the far future? I think what is needed here is something like: and the node receiving the message checks that this timestamp is within some delta of the current time of day and is greater than all previously accepted timestamps. I also share the concerns raised by Kilian Weniger in his e-mail to the list today. I hope you can address these as well. 5.5.2. Forwarding Considerations o When the local mobility anchor is serving a mobile node, it MUST be able to receive packets that are sent to the mobile node's home network. In order for it to receive those packets, it MUST advertise a connected route in to the Routing Infrastructure for the mobile node's home network prefix or for an aggregated prefix with a larger scope. This essentially enables IPv6 routers in that network to detect the local mobility anchor as the last-hop router for that prefix. This is a change from the behavior in RFC 3775 that allowed for proxy ND. Will this create issues when co-locating an LMA with an HA? 6.10.2. Tunneling & Encapsulation Modes Should GRE be mentioned here? 11. Security Considerations To eliminate the threats on the interface between the mobile access gateway and the mobile node, this specification requires an established trust between the mobile access gateway and the mobile node and to authenticate and authorize the mobile node before it is allowed to access the network. I think you should talk here not only about trust but also about a secure binding between the MN-Identifier and the traffic arriving at the MAG. This means that whatever scheme is used to authenticate the MN must provide keys that will be used to protect traffic, indexed by the MAC Address or MN-Identifier as appropriate. Editorial Issues Abstract:=20 in the case of network-based mobility management protocol=20 Should be: in the case of a network-based mobility management protocol=20 1. Introduction IP mobility for nodes which have mobile IP client functionality in the IPv6 stack as well as those hosts which do not, would be supported by enabling Proxy Mobile IPv6 protocol functionality in the network.=20 Get rid of the comma in the above sentence. 2.2 Terminology=20 management of a mobile node is handled using Proxy Mobile IPv6 protocol Should be: management of a mobile node is handled using the Proxy Mobile IPv6 protocol Through out this document, Should be: Throughout this document, 3. Proxy Mobile IPv6 Protocol Overview The core functional entities in the NETLMM infrastructure are the Local Mobility Anchor and the Mobile Access Gateway. The local mobility is responsible for maintaining the mobile node's reachability state and is the topological anchor point for the mobile node's home network prefix. While the mobile access gateway is the entity that performs the mobility management on behalf of a mobile node and it resides on the access link where the mobile node is anchored. The mobile access gateway is responsible for detecting the mobile node's movements on its access link and for sending binding registrations to the mobile node's local mobility anchor. Should be: The core functional entities in the NETLMM infrastructure are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The LMA is responsible for maintaining the mobile node's reachability state and is the topological anchor point for the mobile node's home network prefix. The MAG is the entity that performs the mobility management on behalf of a mobile node and it resides on the access link where the mobile node is anchored. The MAG is responsible for detecting the mobile node's movements on its access link and for sending binding registrations to the mobile node's LMA. The architecture of a Proxy Mobile IPv6 domain is shown in Figure 1. Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access network, the mobile access gateway on that access network after identifying the mobile node and acquiring its identifier, will determine if the mobile node is authorized for network-based mobility management service. Should be: Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access network, the mobile access gateway on that access network, after identifying the mobile node and acquiring its identifier, will determine if the mobile node is authorized for network-based mobility management service. valid address from its home network prefix, at the current point of Should be: valid address from its home network prefix at the current point of by any corresponding node to the mobile node. Should be: by any correspondent node to the mobile node. Any packet that the mobile node sends to any corresponding node will be received by the mobile access gateway and Should be: Any packet that the mobile node sends to any correspondent node will be received by the mobile access gateway and The local mobility anchor on the other end of the tunnel, after receiving the packet removes the outer header and routes the packet to the destination. Should be: The local mobility anchor on the other end of the tunnel, after receiving the packet, removes the outer header and routes the packet to the destination. mobile access gateway on the new access link, will signal the local Should be: mobile access gateway on the new access link will signal the local making it believe its still on the same link=20 Should be: making it believe it's still on the same link=20 4. Proxy Mobile IPv6 Protocol Security The signaling messages, Proxy Binding Update and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor MUST be protected using end-to-end security Should be: The signaling messages Proxy Binding Update and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor, MUST be protected using end-to-end security Mobile IPv6 specification [RFC-3775] requires the home agent to Should be: The Mobile IPv6 specification [RFC-3775] requires the home agent to 5. Local Mobility Anchor Operation The section describes the operational details of the local mobility anchor. Should be: This section describes the operational details of the local mobility anchor. 5.3. Signaling Considerations the local mobility MUST consider this request as an initial binding registration request. Should be: the local mobility anchor MUST consider this request as an initial binding registration request. However, the local mobile anchor MUST send the Proxy Should be: However, the local mobility anchor MUST send the Proxy o The Type 2 Routing header, MUST NOT be present in the IPv6 header of the packet. Should be: o The Type 2 Routing header MUST NOT be present in the IPv6 header of the packet. 5.4. Timestamp Option for Message Ordering Hence, the sequence number scheme as specified in [RFC-3775], will be insufficient for Proxy Mobile IPv6. Should be: Hence, the sequence number scheme, as specified in [RFC-3775], will be insufficient for Proxy Mobile IPv6. it may potentially process an older message sent by a mobile access gateway, where the mobile node was previously anchored, resulting in an incorrect Binding Cache entry. Should be: it may potentially process an older message sent by the mobile access gateway where the mobile node was previously anchored, resulting in an incorrect Binding Cache entry. For solving this problem, this specification adopts two alternative solutions, one is based on timestamps and the other based on sequence numbers, as defined in [RFC-3775]. Should be: For solving this problem, this specification adopts two alternative solutions. One is based on timestamps and the other based on sequence numbers, as defined in [RFC-3775]. o All the mobility entities in a Proxy Mobile IPv6 domain, exchanging binding registration messages using Timestamp option must have adequately synchronized time-of-day clocks. Should be: o All the mobility entities in a Proxy Mobile IPv6 domain that are exchanging binding registration messages using the Timestamp option must have adequately synchronized time-of-day clocks. 5.5.1. Bi-Directional Tunnel Management will be updated after each periodic registrations for extending the lifetime. Should be: will be updated after each periodic re-registration for extending the lifetime. 5.5.2. Forwarding Considerations o On receiving a packet from a corresponding node with the Should be: o On receiving a packet from a correspondent node with the 5.7. Mobile Prefix Discovery Considerations In Proxy Mobile IPv6, the mobile node's home network prefix is hosted on the access link connected to the mobile access gateway. but it is Should be: In Proxy Mobile IPv6, the mobile node's home network prefix is hosted on the access link connected to the mobile access gateway, but it is Since, there is Should be: Since there is 5.8. Route Optimizations Considerations The Route Optimization in Mobile IPv6, as defined in [RFC-3775], enables a mobile node to communicate with a corresponding node Should be: The Route Optimization in Mobile IPv6, as defined in [RFC-3775], enables a mobile node to communicate with a correspondent node 6. Mobile Access Gateway Operation The Proxy Mobile IPv6 protocol described in this document, introduces a new functional entity, the Mobile Access Gateway (MAG).=20 Should be: The Proxy Mobile IPv6 protocol described in this document introduces a new functional entity, the Mobile Access Gateway (MAG). The specifics on how that is achieved or the signaling interactions between those functional entities is beyond the scope of this document. Should be: The specifics on how that is achieved or the signaling interactions between those functional entities are beyond the scope of this document.=20 6.2. Mobile Node's Policy Profile A mobile node's policy profile contains the essential operational parameters that are required by the network entities for managing the mobile node's mobility service. These policy profiles are stored in a local or a remote policy store, the mobile access gateway and the local mobility anchor MUST be able to obtain a mobile node's policy profile. Should be: A mobile node's policy profile contains the essential operational parameters that are required by the network entities for managing the mobile node's mobility service. These policy profiles are stored in a local or a remote policy store. The mobile access gateway and the local mobility anchor MUST be able to obtain a mobile node's policy profile. 6.4. Supported Address Configuration Models The Router Advertisement messages sent on the access link, specify the address configuration methods permitted on that access link for that mobile node.=20 Should be: The Router Advertisement messages sent on the access link specify the address configuration methods permitted on that access link for that mobile node.=20 6.8. Link-Local and Global Address Uniqueness A mobile node in the Proxy Mobile IPv6 domain, as it moves from one mobile access gateway to the other, it will continue to detect its Should be: A mobile node in the Proxy Mobile IPv6 domain, as it moves from one mobile access gateway to the other, will continue to detect its Every time the mobile node attaches to a new link, the event related to the interface state change, will trigger the mobile node to perform DAD operation on the link-local and global addresses. Should be: Every time the mobile node attaches to a new link, the event related to the interface state change will trigger the mobile node to perform DAD operation on the link-local and global addresses. However, this issues will not impact point-to-point links based on PPP session. Should be: However, this issues will not impact point-to-point links based on a PPP session. and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets triggered. Should be: and the IPv6 Control Protocol, IPV6CP [RFC-2472] gets triggered. If the PPP session state is moved to the new mobile access gateway, as part of context transfer procedures that are in place, there will Should be: If the PPP session state is moved to the new mobile access gateway as part of context transfer procedures that are in place, there will Since, there is a unique home network prefix for each mobile node, Should be: Since there is a unique home network prefix for each mobile node, 6.9.1. Binding Registrations management service needs to offered to the mobile node, it MUST Should be: management service needs to be offered to the mobile node, it MUST o The mobile access gateway MUST apply the considerations specified in Section 5.4, for processing the Sequence Number field and the Timestamp option, in the message. Should be: o The mobile access gateway MUST apply the considerations specified in Section 5.4 for processing the Sequence Number field and the Timestamp option, in the message. the mobile access gateway SHOULD try to register again only after it synchronized its clock to a common time source that is used by Should be: the mobile access gateway SHOULD try to register again only after it has synchronized its clock to a common time source that is used by mobile access gateway MUST create Binding Update List entry for Should be: mobile access gateway MUST create a Binding Update List entry for o For extending the lifetime of a currently existing binding at the local mobility, the mobile access gateway MUST send a Proxy Should be: o For extending the lifetime of a currently existing binding at the local mobility anchor, the mobile access gateway MUST send a Proxy o At any point, the mobile access gateway detects that the mobile node has moved away from its access link, it MUST send a Proxy Should be: o At any point, if the mobile access gateway detects that the mobile node has moved away from its access link, it MUST send a Proxy Bottom of page 34 and top of page 35: the message format is split across the two pages. It is confusing and looks like there is a dangling "Proxy Binding Update message format". Please try to keep the message on a single page. 6.10.1. Transport Network The transport network between the local mobility anchor and the mobile access can be either an IPv6 or IPv4 network.=20 Should be: The transport network between the local mobility anchor and the mobile access gateway can be either an IPv6 or IPv4 network.=20 negotiating IPv4 transport and the corresponding encapsulation mode, for supporting this protocol operation. Should be: negotiating IPv4 transport and the corresponding encapsulation mode for supporting this protocol operation. 6.10.2. Tunneling & Encapsulation Modes IPv6 datagrams to be encapsulated as a payload of another IPv6 packet and be routed between the local mobility anchor and the mobile access Should be: IPv6 datagrams to be encapsulated as a payload of another IPv6 packet and to be routed between the local mobility anchor and the mobile access Any packet that is routed over this interface, get encapsulated with the Should be: Any packet that is routed over this interface gets encapsulated with the 6.10.4. Local Routing If there is data traffic between a visiting mobile node and a corresponding node that is locally attached to an access link Should be: If there is data traffic between a visiting mobile node and a correspondent node that is locally attached to an access link This decision of path optimization SHOULD be based on the configured policy configured on the mobile access gateway, but enforced by the Should be: This decision of path optimization SHOULD be based on the policy configured on the mobile access gateway, but enforced by the The specific details on how this is achieved is beyond of the scope of this document. Should be: The specific details on how this is achieved are beyond of the scope of this document. 6.10.5. Tunnel Management All the considerations mentioned in Section 5.5.1, for the tunnel management on the local mobility anchor apply for the mobile access gateway as well. Should be: All the considerations mentioned in Section 5.5.1 for the tunnel management on the local mobility anchor apply for the mobile access gateway as well. 6.10.6. Forwarding Rules For reporting an error in such scenario,=20 Should be: For reporting an error in such a scenario,=20 in the form of ICMP control message, Should be: in the form of an ICMP control message, o On receiving a packet from a corresponding node that is locally connected, to the mobile node that is on the access link, the Should be: o On receiving a packet from a correspondent node that is locally connected and which is destined to a mobile node that is on=20 another locally connected access link, the 6.12. Home Network Prefix Renumbering However, the specific details on how the local mobility anchor notifies the mobile access gateway about the mobile node's home network prefix renumbering is outside the scope of this document. Should be: However, the specific details on how the local mobility anchor notifies the mobile access gateway about the mobile node's home network prefix renumbering are outside the scope of this document. 6.14. Allowing network access to other IPv6 nodes This essentially ensures, the mobile access gateway Should be: This essentially ensures that the mobile access gateway 9. Protocol Configuration Variables allowed to enable local routing of the traffic exchanged between a visiting mobile node and a corresponding node that is locally Should be: allowed to enable local routing of the traffic exchanged between a visiting mobile node and a correspondent node that is locally 11. Security Considerations to hijack a mobile node's session or may do a denial-of-service attacks.=20 Should be: to hijack a mobile node's session or may carry out a denial-of-service attack.=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 04:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiua-0004nk-0K; Mon, 24 Sep 2007 04:03:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiuY-0004m2-BC for netlmm@ietf.org; Mon, 24 Sep 2007 04:03:22 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZiuV-0000XA-KX for netlmm@ietf.org; Mon, 24 Sep 2007 04:03:22 -0400 X-IronPort-AV: E=Sophos;i="4.20,290,1186383600"; d="scan'208";a="10561592" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 24 Sep 2007 01:03:19 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8O83IXF030829; Mon, 24 Sep 2007 01:03:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8O83Hin017506; Mon, 24 Sep 2007 08:03:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:16 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:15 -0700 From: "Sri Gundavelli" To: "'McCann Peter-A001034'" , References: Subject: RE: [netlmm] Review of Proxy Mobile IPv6(draft-ietf-netlmm-proxymip6-05.txt) Date: Mon, 24 Sep 2007 01:03:15 -0700 Message-ID: <004001c7fe81$5c6815f0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Acf8dMaJPfCpPwEvTMeG0YtCrUU/wQB9MQqw X-OriginalArrivalTime: 24 Sep 2007 08:03:15.0935 (UTC) FILETIME=[5C7E0EF0:01C7FE81] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=25270; t=1190620998; x=1191484998; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Review=20of=20Proxy=20Mobile=20IPv6(draft- ietf-netlmm-proxymip6-05.txt) |Sender:=20; bh=j9OHZT9MEhCibgdP8w+EitrVysa36rDXmPBIi4s1r/A=; b=CCipWjieK6JaPcKnDRPLp39+Ub0d47mLCptW9qfZpruqrr9UqI8+u9byyLjqwrC0dVYbjg2z tvmdCpVNQhytkTWFa1i99jKNtWPcNqCJbSsYUJg8jpVRblOdy3+6rOd3; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1d30a527351d82e25c9159ea5f4b10e8 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Pete, Thanks for the review. I've updated the draft based on your inputs. Please see inline. > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Friday, September 21, 2007 11:14 AM > To: netlmm@ietf.org > Subject: [netlmm] Review of Proxy Mobile > IPv6(draft-ietf-netlmm-proxymip6-05.txt) > > Technical Issues > > 4.2 Security Policy Database Entries > > mobile access gateway SPD-S: > - IF local_address = mag_addreFrom netlmm-bounces@ietf.org Mon Sep 24 04:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiua-0004nk-0K; Mon, 24 Sep 2007 04:03:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiuY-0004m2-BC for netlmm@ietf.org; Mon, 24 Sep 2007 04:03:22 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZiuV-0000XA-KX for netlmm@ietf.org; Mon, 24 Sep 2007 04:03:22 -0400 X-IronPort-AV: E=Sophos;i="4.20,290,1186383600"; d="scan'208";a="10561592" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 24 Sep 2007 01:03:19 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8O83IXF030829; Mon, 24 Sep 2007 01:03:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8O83Hin017506; Mon, 24 Sep 2007 08:03:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:16 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:15 -0700 From: "Sri Gundavelli" To: "'McCann Peter-A001034'" , References: Subject: RE: [netlmm] Review of Proxy Mobile IPv6(draft-ietf-netlmm-proxymip6-05.txt) Date: Mon, 24 Sep 2007 01:03:15 -0700 Message-ID: <004001c7fe81$5c6815f0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Acf8dMaJPfCpPwEvTMeG0YtCrUU/wQB9MQqw X-OriginalArrivalTime: 24 Sep 2007 08:03:15.0935 (UTC) FILETIME=[5C7E0EF0:01C7FE81] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=25270; t=1190620998; x=1191484998; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Review=20of=20Proxy=20Mobile=20IPv6(draft- ietf-netlmm-proxymip6-05.txt) |Sender:=20; bh=j9OHZT9MEhCibgdP8w+EitrVysa36rDXmPBIi4s1r/A=; b=CCipWjieK6JaPcKnDRPLp39+Ub0d47mLCptW9qfZpruqrr9UqI8+u9byyLjqwrC0dVYbjg2z tvmdCpVNQhytkTWFa1i99jKNtWPcNqCJbSsYUJg8jpVRblOdy3+6rOd3; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1d30a527351d82e25c9159ea5f4b10e8 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Pete, Thanks for the review. I've updated the draft based on your inputs. Please see inline. > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Friday, September 21, 2007 11:14 AM > To: netlmm@ietf.org > Subject: [netlmm] Review of Proxy Mobile > IPv6(draft-ietf-netlmm-proxymip6-05.txt) > > Technical Issues > > 4.2 Security Policy Database Entries > > mobile access gateway SPD-S: > - IF local_address = mag_address_1 & > remote_address = lma_address_1 & > proto = MH & local_mh_type = BU & remote_mh_type = BA > Then use SA ESP transport mode > Initiate using IDi = mag_1 to address lma_1 > > Should that last line read "Initiate using IDi = mag_1 to address > lma_address_1"? > Ok. > > 5.1 Extensions to Binding Cache Entry Data Structure > > o A flag indicating whether or not this Binding Cache entry is > created due to a proxy registration. This flag is enabled for > Binding Cache entries that are proxy registrations and is turned > off for all other entries that are created due to the > registrations directly sent by the mobile node. > > This point seems to be related to the interaction of proxy MIP and > client MIP using the same home agent. I think it would be best to > leave this sort of detail to a separate document describing such > interaction. There are many issues that must be dealt with in that > case, such as how to put BUs in the right order. > We are only marking that this is a PMIP BCE, with out discussing the details of CMIP and PMIP integration. Since, we are extending the 3775 BCE structure that is defined for CMIP, we have added extra fields that are relevant to PMIP6 and also flagged the BCE entry. > > o The identifier of the registered mobile node, > MN-Identifier. This > identifier is obtained from the NAI Option [RFC-4283] present in > the received Proxy Binding Update request. > > Isn't it intended that the MN-Identfier can be something other than > NAI? For example, an L2 address? > The identifier is exchanged using the NAI Option (4282). The identifier that is allowed in 4283 is based on the 4282 definition. We are bound to that definition. In a proxy model, when a third entity is sending binding request, the identifier of the MN needs to be present and that is the only stable field. The HNP is allocated dynamically. > > 5.3. Signaling Considerations > > o The local mobility anchor MUST identify the mobile node from the > identifier present in the NAI option [RFC-4283] of the Proxy > Here again the NAI is mandated. > > > Binding De-Registration: > ... > o Upon accepting the request, the local mobility anchor > MUST delete > the mobile node's Binding Cache entry and remove the > Routing state > for the mobile node's home network prefix. > This bullet seems to contradict the first bulllet in this sub-section, > which states that the LMA must implement a hang timer. Maybe just > delete this bullet. > Ok. Will fix it. > Constructing the Proxy Binding Acknowledgement Message: > ... > o If the Status field is set to a value greater less than > 128, i.e. > if the binding request was rejected, > Does this mean to say "a value different from 128"? > Typo. Fixed it. > > 5.4. Timestamp Option for Message Ordering > > and the node receiving the message checks > that this timestamp is greater than all previously accepted > timestamps. > Shouldn't there be a check that the timestamp is somewhere close > to the current time of day, to prevent a misconfigured MAG from > blocking all registrations for a period fo time, > by sending a message stamped sometime in the far future? > I think what is needed here is something like: > and the node receiving the message checks > that this timestamp is within some delta of the current time of day > and is greater than all previously accepted timestamps. > > I also share the concerns raised by Kilian Weniger in his e-mail > to the list today. I hope you can address these as well. > I will take care of this. > > 5.5.2. Forwarding Considerations > > o When the local mobility anchor is serving a mobile node, it MUST > be able to receive packets that are sent to the mobile > node's home > network. In order for it to receive those packets, it MUST > advertise a connected route in to the Routing Infrastructure for > the mobile node's home network prefix or for an >ss_1 & > remote_address = lma_address_1 & > proto = MH & local_mh_type = BU & remote_mh_type = BA > Then use SA ESP transport mode > Initiate using IDi = mag_1 to address lma_1 > > Should that last line read "Initiate using IDi = mag_1 to address > lma_address_1"? > Ok. > > 5.1 Extensions to Binding Cache Entry Data Structure > > o A flag indicating whether or not this Binding Cache entry is > created due to a proxy registration. This flag is enabled for > Binding Cache entries that are proxy registrations and is turned > off for all other entries that are created due to the > registrations directly sent by the mobile node. > > This point seems to be related to the interaction of proxy MIP and > client MIP using the same home agent. I think it would be best to > leave this sort of detail to a separate document describing such > interaction. There are many issues that must be dealt with in that > case, such as how to put BUs in the right order. > We are only marking that this is a PMIP BCE, with out discussing the details of CMIP and PMIP integration. Since, we are extending the 3775 BCE structure that is defined for CMIP, we have added extra fields that are relevant to PMIP6 and also flagged the BCE entry. > > o The identifier of the registered mobile node, > MN-Identifier. This > identifier is obtained from the NAI Option [RFC-4283] present in > the received Proxy Binding Update request. > > Isn't it intended that the MN-Identfier can be something other than > NAI? For example, an L2 address? > The identifier is exchanged using the NAI Option (4282). The identifier that is allowed in 4283 is based on the 4282 definition. We are bound to that definition. In a proxy model, when a third entity is sending binding request, the identifier of the MN needs to be present and that is the only stable field. The HNP is allocated dynamically. > > 5.3. Signaling Considerations > > o The local mobility anchor MUST identify the mobile node from the > identifier present in the NAI option [RFC-4283] of the Proxy > Here again the NAI is mandated. > > > Binding De-Registration: > ... > o Upon accepting the request, the local mobility anchor > MUST delete > the mobile node's Binding Cache entry and remove the > Routing state > for the mobile node's home network prefix. > This bullet seems to contradict the first bulllet in this sub-section, > which states that the LMA must implement a hang timer. Maybe just > delete this bullet. > Ok. Will fix it. > Constructing the Proxy Binding Acknowledgement Message: > ... > o If the Status field is set to a value greater less than > 128, i.e. > if the binding request was rejected, > Does this mean to say "a value different from 128"? > Typo. Fixed it. > > 5.4. Timestamp Option for Message Ordering > > and the node receiving the message checks > that this timestamp is greater than all previously accepted > timestamps. > Shouldn't there be a check that the timestamp is somewhere close > to the current time of day, to prevent a misconfigured MAG from > blocking all registrations for a period fo time, > by sending a message stamped sometime in the far future? > I think what is needed here is something like: > and the node receiving the message checks > that this timestamp is within some delta of the current time of day > and is greater than all previously accepted timestamps. > > I also share the concerns raised by Kilian Weniger in his e-mail > to the list today. I hope you can address these as well. > I will take care of this. > > 5.5.2. Forwarding Considerations > > o When the local mobility anchor is serving a mobile node, it MUST > be able to receive packets that are sent to the mobile > node's home > network. In order for it to receive those packets, it MUST > advertise a connected route in to the Routing Infrastructure for > the mobile node's home network prefix or for an > aggregated prefix > with a larger scope. This essentially enables IPv6 routers in > that network to detect the local mobility anchor as the last-hop > router for that prefix. > This is a change from the behavior in RFC 3775 that allowed for > proxy ND. Will this create issues when co-locating an LMA with an HA? > No, its just stating that the LMA should be able to receive traffic that is sent to the mobile node's home network. Also, 3775 does not prevent the configuration MN's home network on a virtual interface and there is no Proxy ND there. Proxy ND is required if the HA has to defend the address on a physical interface. > > 6.10.2. Tunneling & Encapsulation Modes > > Should GRE be mentioned here? > Thought about this. But, I've a draft on GRE for PMIP6 and I dont want to show any references to that from this draft. > > 11. Security Considerations > > To eliminate the threats on the interface between the mobile access > gateway and the mobile node, this specification requires an > established trust between the mobile access gateway and the mobile > node and to authenticate and authorize the mobile node before it is > allowed to access the network. > I think you should talk here not only about trust but also about > a secure binding between the MN-Identifier and the traffic arriving > at the MAG. This means that whatever scheme is used to authenticate > the MN must provide keys that will be used to protect traffic, indexed > by the MAC Address or MN-Identifier as appropriate. > I have addes some text around this. > > Editorial Issues > I've fixed all the below editorial issues. Thanks a lot for pointing them to me. Regards Sri > Abstract: > > in the case of network-based mobility management > protocol > Should be: > in the case of a network-based mobility management > protocol > > > 1. Introduction > > IP mobility for nodes which have mobile IP client > functionality in the IPv6 stack as well as those hosts > which do not, > would be supported by enabling Proxy Mobile IPv6 protocol > functionality in the network. > Get rid of the comma in the above sentence. > > > 2.2 Terminology > > management of a mobile node is handled using Proxy Mobile IPv6 > protocol > Should be: > management of a mobile node is handled using the Proxy > Mobile IPv6 > protocol > > Through out this document, > Should be: > Throughout this document, > > > 3. Proxy Mobile IPv6 Protocol Overview > > The core functional entities in the NETLMM infrastructure are the > Local Mobility Anchor and the Mobile Access Gateway. The local > mobility is responsible for maintaining the mobile node's > reachability state and is the topological anchor point for > the mobile > node's home network prefix. While the mobile access gateway is the > entity that performs the mobility management on behalf of a mobile > node and it resides on the access link where the mobile node is > anchored. The mobile access gateway is responsible for > detecting the > mobile node's movements on its access link and for sending binding > registrations to the mobile node's local mobility anchor. > Should be: > The core functional entities in the NETLMM infrastructure are the > Local Mobility Anchor (LMA) and the Mobile Access Gateway > (MAG). The > LMA > is responsible for maintaining the mobile node's > reachability state and is the topological anchor point for > the mobile > node's home network prefix. The MAG is the > entity that performs the mobility management on behalf of a mobile > node and it resides on the access link where the mobile node is > anchored. The MAG is responsible for detecting the > mobile node's movements on its access link and for sending binding > registrations to the mobile node's LMA. The architecture of > a Proxy Mobile IPv6 domain is shown in Figure 1. > > > Once a mobile node enters a Proxy Mobile IPv6 domain and > attaches to > an access n aggregated prefix > with a larger scope. This essentially enables IPv6 routers in > that network to detect the local mobility anchor as the last-hop > router for that prefix. > This is a change from the behavior in RFC 3775 that allowed for > proxy ND. Will this create issues when co-locating an LMA with an HA? > No, its just stating that the LMA should be able to receive traffic that is sent to the mobile node's home network. Also, 3775 does not prevent the configuration MN's home network on a virtual interface and there is no Proxy ND there. Proxy ND is required if the HA has to defend the address on a physical interface. > > 6.10.2. Tunneling & Encapsulation Modes > > Should GRE be mentioned here? > Thought about this. But, I've a draft on GRE for PMIP6 and I dont want to show any references to that from this draft. > > 11. Security Considerations > > To eliminate the threats on the interface between the mobile access > gateway and the mobile node, this specification requires an > established trust between the mobile access gateway and the mobile > node and to authenticate and authorize the mobile node before it is > allowed to access the network. > I think you should talk here not only about trust but also about > a secure binding between the MN-Identifier and the traffic arriving > at the MAG. This means that whatever scheme is used to authenticate > the MN must provide keys that will be used to protect traffic, indexed > by the MAC Address or MN-Identifier as appropriate. > I have addes some text around this. > > Editorial Issues > I've fixed all the below editorial issues. Thanks a lot for pointing them to me. Regards Sri > Abstract: > > in the case of network-based mobility management > protocol > Should be: > in the case of a network-based mobility management > protocol > > > 1. Introduction > > IP mobility for nodes which have mobile IP client > functionality in the IPv6 stack as well as those hosts > which do not, > would be supported by enabling Proxy Mobile IPv6 protocol > functionality in the network. > Get rid of the comma in the above sentence. > > > 2.2 Terminology > > management of a mobile node is handled using Proxy Mobile IPv6 > protocol > Should be: > management of a mobile node is handled using the Proxy > Mobile IPv6 > protocol > > Through out this document, > Should be: > Throughout this document, > > > 3. Proxy Mobile IPv6 Protocol Overview > > The core functional entities in the NETLMM infrastructure are the > Local Mobility Anchor and the Mobile Access Gateway. The local > mobility is responsible for maintaining the mobile node's > reachability state and is the topological anchor point for > the mobile > node's home network prefix. While the mobile access gateway is the > entity that performs the mobility management on behalf of a mobile > node and it resides on the access link where the mobile node is > anchored. The mobile access gateway is responsible for > detecting the > mobile node's movements on its access link and for sending binding > registrations to the mobile node's local mobility anchor. > Should be: > The core functional entities in the NETLMM infrastructure are the > Local Mobility Anchor (LMA) and the Mobile Access Gateway > (MAG). The > LMA > is responsible for maintaining the mobile node's > reachability state and is the topological anchor point for > the mobile > node's home network prefix. The MAG is the > entity that performs the mobility management on behalf of a mobile > node and it resides on the access link where the mobile node is > anchored. The MAG is responsible for detecting the > mobile node's movements on its access link and for sending binding > registrations to the mobile node's LMA. The architecture of > a Proxy Mobile IPv6 domain is shown in Figure 1. > > > Once a mobile node enters a Proxy Mobile IPv6 domain and > attaches to > an access network, the mobile access gateway on that access network > after identifying the mobile node and acquiring its > identifier, will > determine if the mobile node is authorized for > network-based mobility > management service. > Should be: > Once a mobile node enters a Proxy Mobile IPv6 domain and > attaches to > an access network, the mobile access gateway on that > access network, > after identifying the mobile node and acquiring its > identifier, will > determine if the mobile node is authorized for > network-based mobility > management service. > > valid address from its home network prefix, at the current point of > Should be: > valid address from its home network prefix at the current point of > > by any corresponding node to the mobile node. > Should be: > by any correspondent node to the mobile node. > > Any packet that the mobile node sends to any > corresponding node will be received by the mobile access > gateway and > Should be: > Any packet that the mobile node sends to any > correspondent node will be received by the mobile access > gateway and > > The local mobility anchor on the other end of the tunnel, > after receiving the packet removes the outer header and routes the > packet to the destination. > Should be: > The local mobility anchor on the other end of the tunnel, > after receiving the packet, removes the outer header and routes the > packet to the destination. > > mobile access gateway on the new access link, will signal the local > Should be: > mobile access gateway on the new access link will signal the local > > making it believe its still on > the same link > Should be: > making it believe it's still on > the same link > > > 4. Proxy Mobile IPv6 Protocol Security > > The signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access > gateway and the > local mobility anchor MUST be protected using end-to-end security > Should be: > The signaling messages Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access > gateway and the > local mobility anchor, MUST be protected using end-to-end security > > Mobile IPv6 specification [RFC-3775] requires the home agent to > Should be: > The Mobile IPv6 specification [RFC-3775] requires the home agent to > > > 5. Local Mobility Anchor Operation > > The section describes the operational details of the local mobility > anchor. > Should be: > This section describes the operational details of the > local mobility > anchor. > > > 5.3. Signaling Considerations > > the local mobility MUST consider this request as > an initial binding registration request. > Should be: > the local mobility anchor MUST consider this request as > an initial binding registration request. > > However, the local mobile anchor MUST send the Proxy > Should be: > However, the local mobility anchor MUST send the Proxy > > o The Type 2 Routing header, MUST NOT be present in the > IPv6 header > of the packet. > Should be: > o The Type 2 Routing header MUST NOT be present in the IPv6 header > of the packet. > > > 5.4. Timestamp Option for Message Ordering > > Hence, the sequence > number scheme as specified in [RFC-3775], will be insufficient for > Proxy Mobile IPv6. > Should be: > Hence, the sequence > number scheme, as specified in [RFC-3775], will be insufficient for > Proxy Mobile IPv6. > > > it may potentially > process an older message sent by a mobile access gateway, where the > mobile node was previously anchored, resulting in an incorrect > Binding Cache entry. > Should be: > it may potentially > process an older message sent by the mobile access gateway > where the > mobile node was previously anchored, resulting in an incorrect > Binding Cache entry. > > For solving this problem, this specification adopts two alternative > solutions, one is based on etwork, the mobile access gateway on that access network > after identifying the mobile node and acquiring its > identifier, will > determine if the mobile node is authorized for > network-based mobility > management service. > Should be: > Once a mobile node enters a Proxy Mobile IPv6 domain and > attaches to > an access network, the mobile access gateway on that > access network, > after identifying the mobile node and acquiring its > identifier, will > determine if the mobile node is authorized for > network-based mobility > management service. > > valid address from its home network prefix, at the current point of > Should be: > valid address from its home network prefix at the current point of > > by any corresponding node to the mobile node. > Should be: > by any correspondent node to the mobile node. > > Any packet that the mobile node sends to any > corresponding node will be received by the mobile access > gateway and > Should be: > Any packet that the mobile node sends to any > correspondent node will be received by the mobile access > gateway and > > The local mobility anchor on the other end of the tunnel, > after receiving the packet removes the outer header and routes the > packet to the destination. > Should be: > The local mobility anchor on the other end of the tunnel, > after receiving the packet, removes the outer header and routes the > packet to the destination. > > mobile access gateway on the new access link, will signal the local > Should be: > mobile access gateway on the new access link will signal the local > > making it believe its still on > the same link > Should be: > making it believe it's still on > the same link > > > 4. Proxy Mobile IPv6 Protocol Security > > The signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access > gateway and the > local mobility anchor MUST be protected using end-to-end security > Should be: > The signaling messages Proxy Binding Update and Proxy Binding > Acknowledgement, exchanged between the mobile access > gateway and the > local mobility anchor, MUST be protected using end-to-end security > > Mobile IPv6 specification [RFC-3775] requires the home agent to > Should be: > The Mobile IPv6 specification [RFC-3775] requires the home agent to > > > 5. Local Mobility Anchor Operation > > The section describes the operational details of the local mobility > anchor. > Should be: > This section describes the operational details of the > local mobility > anchor. > > > 5.3. Signaling Considerations > > the local mobility MUST consider this request as > an initial binding registration request. > Should be: > the local mobility anchor MUST consider this request as > an initial binding registration request. > > However, the local mobile anchor MUST send the Proxy > Should be: > However, the local mobility anchor MUST send the Proxy > > o The Type 2 Routing header, MUST NOT be present in the > IPv6 header > of the packet. > Should be: > o The Type 2 Routing header MUST NOT be present in the IPv6 header > of the packet. > > > 5.4. Timestamp Option for Message Ordering > > Hence, the sequence > number scheme as specified in [RFC-3775], will be insufficient for > Proxy Mobile IPv6. > Should be: > Hence, the sequence > number scheme, as specified in [RFC-3775], will be insufficient for > Proxy Mobile IPv6. > > > it may potentially > process an older message sent by a mobile access gateway, where the > mobile node was previously anchored, resulting in an incorrect > Binding Cache entry. > Should be: > it may potentially > process an older message sent by the mobile access gateway > where the > mobile node was previously anchored, resulting in an incorrect > Binding Cache entry. > > For solving this problem, this specification adopts two alternative > solutions, one is based on timestamps and the other based > on sequence > numbers, as defined in [RFC-3775]. > Should be: > For solving this problem, this specification adopts two alternative > solutions. One is based on timestamps and the other based on > sequence > numbers, as defined in [RFC-3775]. > > o All the mobility entities in a Proxy Mobile IPv6 domain, > exchanging binding registration messages using Timestamp option > must have adequately synchronized time-of-day clocks. > Should be: > o All the mobility entities in a Proxy Mobile IPv6 domain that are > exchanging binding registration messages using the Timestamp > option > must have adequately synchronized time-of-day clocks. > > > 5.5.1. Bi-Directional Tunnel Management > > will be updated after > each periodic registrations for extending the lifetime. > Should be: > will be updated after > each periodic re-registration for extending the lifetime. > > > 5.5.2. Forwarding Considerations > > o On receiving a packet from a corresponding node with the > Should be: > o On receiving a packet from a correspondent node with the > > > 5.7. Mobile Prefix Discovery Considerations > > In Proxy Mobile IPv6, the mobile node's home network > prefix is hosted > on the access link connected to the mobile access gateway. > but it is > Should be: > In Proxy Mobile IPv6, the mobile node's home network > prefix is hosted > on the access link connected to the mobile access gateway, > but it is > > Since, there is > Should be: > Since there is > > 5.8. Route Optimizations Considerations > > The Route Optimization in Mobile IPv6, as defined in [RFC-3775], > enables a mobile node to communicate with a corresponding node > Should be: > The Route Optimization in Mobile IPv6, as defined in [RFC-3775], > enables a mobile node to communicate with a correspondent node > > 6. Mobile Access Gateway Operation > > The Proxy Mobile IPv6 protocol described in this document, > introduces > a new functional entity, the Mobile Access Gateway (MAG). > Should be: > The Proxy Mobile IPv6 protocol described in this document > introduces > a new functional entity, the Mobile Access Gateway (MAG). > > The specifics on how > that is achieved or the signaling interactions between those > functional entities is beyond the scope of this document. > Should be: > The specifics on how > that is achieved or the signaling interactions between those > functional entities are beyond the scope of this document. > > 6.2. Mobile Node's Policy Profile > > A mobile node's policy profile contains the essential operational > parameters that are required by the network entities for > managing the > mobile node's mobility service. These policy profiles are > stored in > a local or a remote policy store, the mobile access gateway and the > local mobility anchor MUST be able to obtain a mobile node's policy > profile. > Should be: > A mobile node's policy profile contains the essential operational > parameters that are required by the network entities for > managing the > mobile node's mobility service. These policy profiles are > stored in > a local or a remote policy store. The mobile access > gateway and the > local mobility anchor MUST be able to obtain a mobile node's policy > profile. > > 6.4. Supported Address Configuration Models > > The Router Advertisement > messages sent on the access link, specify the address configuration > methods permitted on that access link for that mobile node. > Should be: > The Router Advertisement > messages sent on the access link specify the address configuration > methods permitted on that access link for that mobile node. > > 6.8. Link-Local and Global Address Uniqueness > > A mobile node in the Proxy Mobile IPv6 domain, as it moves from one > mobile access gateway to the other, it will continue to detect its > Should be: > A mobile node in the Proxy Mobile IPv6 domain, as it timestamps and the other based > on sequence > numbers, as defined in [RFC-3775]. > Should be: > For solving this problem, this specification adopts two alternative > solutions. One is based on timestamps and the other based on > sequence > numbers, as defined in [RFC-3775]. > > o All the mobility entities in a Proxy Mobile IPv6 domain, > exchanging binding registration messages using Timestamp option > must have adequately synchronized time-of-day clocks. > Should be: > o All the mobility entities in a Proxy Mobile IPv6 domain that are > exchanging binding registration messages using the Timestamp > option > must have adequately synchronized time-of-day clocks. > > > 5.5.1. Bi-Directional Tunnel Management > > will be updated after > each periodic registrations for extending the lifetime. > Should be: > will be updated after > each periodic re-registration for extending the lifetime. > > > 5.5.2. Forwarding Considerations > > o On receiving a packet from a corresponding node with the > Should be: > o On receiving a packet from a correspondent node with the > > > 5.7. Mobile Prefix Discovery Considerations > > In Proxy Mobile IPv6, the mobile node's home network > prefix is hosted > on the access link connected to the mobile access gateway. > but it is > Should be: > In Proxy Mobile IPv6, the mobile node's home network > prefix is hosted > on the access link connected to the mobile access gateway, > but it is > > Since, there is > Should be: > Since there is > > 5.8. Route Optimizations Considerations > > The Route Optimization in Mobile IPv6, as defined in [RFC-3775], > enables a mobile node to communicate with a corresponding node > Should be: > The Route Optimization in Mobile IPv6, as defined in [RFC-3775], > enables a mobile node to communicate with a correspondent node > > 6. Mobile Access Gateway Operation > > The Proxy Mobile IPv6 protocol described in this document, > introduces > a new functional entity, the Mobile Access Gateway (MAG). > Should be: > The Proxy Mobile IPv6 protocol described in this document > introduces > a new functional entity, the Mobile Access Gateway (MAG). > > The specifics on how > that is achieved or the signaling interactions between those > functional entities is beyond the scope of this document. > Should be: > The specifics on how > that is achieved or the signaling interactions between those > functional entities are beyond the scope of this document. > > 6.2. Mobile Node's Policy Profile > > A mobile node's policy profile contains the essential operational > parameters that are required by the network entities for > managing the > mobile node's mobility service. These policy profiles are > stored in > a local or a remote policy store, the mobile access gateway and the > local mobility anchor MUST be able to obtain a mobile node's policy > profile. > Should be: > A mobile node's policy profile contains the essential operational > parameters that are required by the network entities for > managing the > mobile node's mobility service. These policy profiles are > stored in > a local or a remote policy store. The mobile access > gateway and the > local mobility anchor MUST be able to obtain a mobile node's policy > profile. > > 6.4. Supported Address Configuration Models > > The Router Advertisement > messages sent on the access link, specify the address configuration > methods permitted on that access link for that mobile node. > Should be: > The Router Advertisement > messages sent on the access link specify the address configuration > methods permitted on that access link for that mobile node. > > 6.8. Link-Local and Global Address Uniqueness > > A mobile node in the Proxy Mobile IPv6 domain, as it moves from one > mobile access gateway to the other, it will continue to detect its > Should be: > A mobile node in the Proxy Mobile IPv6 domain, as it moves from one > mobile access gateway to the other, will continue to detect its > > Every time the mobile node attaches to a new link, the > event related > to the interface state change, will trigger the mobile node to > perform DAD operation on the link-local and global addresses. > Should be: > Every time the mobile node attaches to a new link, the > event related > to the interface state change will trigger the mobile node to > perform DAD operation on the link-local and global addresses. > > However, this issues will not impact point-to-point links based on > PPP session. > Should be: > However, this issues will not impact point-to-point links based on > a PPP session. > > and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets triggered. > Should be: > and the IPv6 Control Protocol, IPV6CP [RFC-2472] gets triggered. > > If the PPP session state is moved to the new mobile access gateway, > as part of context transfer procedures that are in place, > there will > Should be: > If the PPP session state is moved to the new mobile access gateway > as part of context transfer procedures that are in place, > there will > > Since, there is a unique home network prefix for each mobile node, > Should be: > Since there is a unique home network prefix for each mobile node, > > 6.9.1. Binding Registrations > > management service needs to offered to the mobile node, it MUST > Should be: > management service needs to be offered to the mobile > node, it MUST > > o The mobile access gateway MUST apply the considerations > specified > in Section 5.4, for processing the Sequence Number field and the > Timestamp option, in the message. > Should be: > o The mobile access gateway MUST apply the considerations > specified > in Section 5.4 for processing the Sequence Number field and the > Timestamp option, in the message. > > the mobile access gateway SHOULD try to register again > only after > it synchronized its clock to a common time source that > is used by > Should be: > the mobile access gateway SHOULD try to register again > only after > it has synchronized its clock to a common time source > that is used > by > > mobile access gateway MUST create Binding Update List entry for > Should be: > mobile access gateway MUST create a Binding Update List > entry for > > o For extending the lifetime of a currently existing > binding at the > local mobility, the mobile access gateway MUST send a Proxy > Should be: > o For extending the lifetime of a currently existing > binding at the > local mobility anchor, the mobile access gateway MUST > send a Proxy > > o At any point, the mobile access gateway detects that the mobile > node has moved away from its access link, it MUST send a Proxy > Should be: > o At any point, if the mobile access gateway detects that > the mobile > node has moved away from its access link, it MUST send a Proxy > > Bottom of page 34 and top of page 35: the message format is split > across the two pages. It is confusing and looks like there is a > dangling "Proxy Binding Update message format". Please try to > keep the message on a single page. > > > 6.10.1. Transport Network > > The transport network between the local mobility anchor and the > mobile access can be either an IPv6 or IPv4 network. > Should be: > The transport network between the local mobility anchor and the > mobile access gateway can be either an IPv6 or IPv4 network. > > negotiating IPv4 transport and the corresponding > encapsulation mode, > for supporting this protocol operation. > Should be: > negotiating IPv4 transport and the corresponding encapsulation mode > for supporting this protocol operation. > > > 6.10.2. Tunneling & Encapsulation Modes > > IPv6 datagrams to be encapsulated as a payload of another > IPv6 packet > and be routed between the local mobility anchor and the > mobile access > Shouldmoves from one > mobile access gateway to the other, will continue to detect its > > Every time the mobile node attaches to a new link, the > event related > to the interface state change, will trigger the mobile node to > perform DAD operation on the link-local and global addresses. > Should be: > Every time the mobile node attaches to a new link, the > event related > to the interface state change will trigger the mobile node to > perform DAD operation on the link-local and global addresses. > > However, this issues will not impact point-to-point links based on > PPP session. > Should be: > However, this issues will not impact point-to-point links based on > a PPP session. > > and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets triggered. > Should be: > and the IPv6 Control Protocol, IPV6CP [RFC-2472] gets triggered. > > If the PPP session state is moved to the new mobile access gateway, > as part of context transfer procedures that are in place, > there will > Should be: > If the PPP session state is moved to the new mobile access gateway > as part of context transfer procedures that are in place, > there will > > Since, there is a unique home network prefix for each mobile node, > Should be: > Since there is a unique home network prefix for each mobile node, > > 6.9.1. Binding Registrations > > management service needs to offered to the mobile node, it MUST > Should be: > management service needs to be offered to the mobile > node, it MUST > > o The mobile access gateway MUST apply the considerations > specified > in Section 5.4, for processing the Sequence Number field and the > Timestamp option, in the message. > Should be: > o The mobile access gateway MUST apply the considerations > specified > in Section 5.4 for processing the Sequence Number field and the > Timestamp option, in the message. > > the mobile access gateway SHOULD try to register again > only after > it synchronized its clock to a common time source that > is used by > Should be: > the mobile access gateway SHOULD try to register again > only after > it has synchronized its clock to a common time source > that is used > by > > mobile access gateway MUST create Binding Update List entry for > Should be: > mobile access gateway MUST create a Binding Update List > entry for > > o For extending the lifetime of a currently existing > binding at the > local mobility, the mobile access gateway MUST send a Proxy > Should be: > o For extending the lifetime of a currently existing > binding at the > local mobility anchor, the mobile access gateway MUST > send a Proxy > > o At any point, the mobile access gateway detects that the mobile > node has moved away from its access link, it MUST send a Proxy > Should be: > o At any point, if the mobile access gateway detects that > the mobile > node has moved away from its access link, it MUST send a Proxy > > Bottom of page 34 and top of page 35: the message format is split > across the two pages. It is confusing and looks like there is a > dangling "Proxy Binding Update message format". Please try to > keep the message on a single page. > > > 6.10.1. Transport Network > > The transport network between the local mobility anchor and the > mobile access can be either an IPv6 or IPv4 network. > Should be: > The transport network between the local mobility anchor and the > mobile access gateway can be either an IPv6 or IPv4 network. > > negotiating IPv4 transport and the corresponding > encapsulation mode, > for supporting this protocol operation. > Should be: > negotiating IPv4 transport and the corresponding encapsulation mode > for supporting this protocol operation. > > > 6.10.2. Tunneling & Encapsulation Modes > > IPv6 datagrams to be encapsulated as a payload of another > IPv6 packet > and be routed between the local mobility anchor and the > mobile access > Should be: > IPv6 datagrams to be encapsulated as a payload of another > IPv6 packet > and to be routed between the local mobility anchor and the mobile > access > > Any > packet that is routed over this interface, get > encapsulated with the > Should be: > Any > packet that is routed over this interface gets > encapsulated with the > > > 6.10.4. Local Routing > > If there is data traffic between a visiting mobile node and a > corresponding node that is locally attached to an access link > Should be: > If there is data traffic between a visiting mobile node and a > correspondent node that is locally attached to an access link > > This decision of path optimization SHOULD be based on the > configured > policy configured on the mobile access gateway, but enforced by the > Should be: > This decision of path optimization SHOULD be based on the > policy configured on the mobile access gateway, but enforced by the > > The specific details on how > this is achieved is beyond of the scope of this document. > Should be: > The specific details on how > this is achieved are beyond of the scope of this document. > > > 6.10.5. Tunnel Management > > All the considerations mentioned in Section 5.5.1, for the tunnel > management on the local mobility anchor apply for the mobile access > gateway as well. > Should be: > All the considerations mentioned in Section 5.5.1 for the tunnel > management on the local mobility anchor apply for the mobile access > gateway as well. > > > 6.10.6. Forwarding Rules > > For reporting an error in such > scenario, > Should be: > For reporting an error in such a > scenario, > > in the form of ICMP control message, > Should be: > in the form of an ICMP control message, > > o On receiving a packet from a corresponding node that is locally > connected, to the mobile node that is on the access link, the > Should be: > o On receiving a packet from a correspondent node that is locally > connected and which is destined to a mobile node that is on > another locally connected access link, the > > > 6.12. Home Network Prefix Renumbering > > However, the specific details on how the local mobility anchor > notifies the mobile access gateway about the mobile node's home > network prefix renumbering is outside the scope of this document. > Should be: > However, the specific details on how the local mobility anchor > notifies the mobile access gateway about the mobile node's home > network prefix renumbering are outside the scope of this document. > > > 6.14. Allowing network access to other IPv6 nodes > > This essentially ensures, the mobile access gateway > Should be: > This essentially ensures that the mobile access gateway > > > 9. Protocol Configuration Variables > > allowed to enable local routing of the traffic > exchanged between a > visiting mobile node and a corresponding node that is locally > Should be: > allowed to enable local routing of the traffic > exchanged between a > visiting mobile node and a correspondent node that is locally > > > 11. Security Considerations > > to hijack a mobile node's session or may do a denial-of-service > attacks. > Should be: > to hijack a mobile node's session or may carry out a > denial-of-service > attack. > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 04:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiuc-0004sV-R0; Mon, 24 Sep 2007 04:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiub-0004sQ-Dp for netlmm@iet be: > IPv6 datagrams to be encapsulated as a payload of another > IPv6 packet > and to be routed between the local mobility anchor and the mobile > access > > Any > packet that is routed over this interface, get > encapsulated with the > Should be: > Any > packet that is routed over this interface gets > encapsulated with the > > > 6.10.4. Local Routing > > If there is data traffic between a visiting mobile node and a > corresponding node that is locally attached to an access link > Should be: > If there is data traffic between a visiting mobile node and a > correspondent node that is locally attached to an access link > > This decision of path optimization SHOULD be based on the > configured > policy configured on the mobile access gateway, but enforced by the > Should be: > This decision of path optimization SHOULD be based on the > policy configured on the mobile access gateway, but enforced by the > > The specific details on how > this is achieved is beyond of the scope of this document. > Should be: > The specific details on how > this is achieved are beyond of the scope of this document. > > > 6.10.5. Tunnel Management > > All the considerations mentioned in Section 5.5.1, for the tunnel > management on the local mobility anchor apply for the mobile access > gateway as well. > Should be: > All the considerations mentioned in Section 5.5.1 for the tunnel > management on the local mobility anchor apply for the mobile access > gateway as well. > > > 6.10.6. Forwarding Rules > > For reporting an error in such > scenario, > Should be: > For reporting an error in such a > scenario, > > in the form of ICMP control message, > Should be: > in the form of an ICMP control message, > > o On receiving a packet from a corresponding node that is locally > connected, to the mobile node that is on the access link, the > Should be: > o On receiving a packet from a correspondent node that is locally > connected and which is destined to a mobile node that is on > another locally connected access link, the > > > 6.12. Home Network Prefix Renumbering > > However, the specific details on how the local mobility anchor > notifies the mobile access gateway about the mobile node's home > network prefix renumbering is outside the scope of this document. > Should be: > However, the specific details on how the local mobility anchor > notifies the mobile access gateway about the mobile node's home > network prefix renumbering are outside the scope of this document. > > > 6.14. Allowing network access to other IPv6 nodes > > This essentially ensures, the mobile access gateway > Should be: > This essentially ensures that the mobile access gateway > > > 9. Protocol Configuration Variables > > allowed to enable local routing of the traffic > exchanged between a > visiting mobile node and a corresponding node that is locally > Should be: > allowed to enable local routing of the traffic > exchanged between a > visiting mobile node and a correspondent node that is locally > > > 11. Security Considerations > > to hijack a mobile node's session or may do a denial-of-service > attacks. > Should be: > to hijack a mobile node's session or may carry out a > denial-of-service > attack. > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 04:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiuc-0004sV-R0; Mon, 24 Sep 2007 04:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiub-0004sQ-Dp for netlmm@ietf.org; Mon, 24 Sep 2007 04:03:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZiuV-0007Mj-22 for netlmm@ietf.org; Mon, 24 Sep 2007 04:03:25 -0400 X-IronPort-AV: E=Sophos;i="4.20,290,1186383600"; d="scan'208";a="223830158" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Sep 2007 01:03:06 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8O8355j028816; Mon, 24 Sep 2007 01:03:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8O835in017309; Mon, 24 Sep 2007 08:03:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:04 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:04 -0700 From: "Sri Gundavelli" To: "'Kilian Weniger'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> Date: Mon, 24 Sep 2007 01:03:03 -0700 Message-ID: <003f01c7fe81$555e2ce0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> Thread-Index: Acf8Mf/s6Vq1PtL7TIOvDsZjpXW1+QBxWpjQ X-OriginalArrivalTime: 24 Sep 2007 08:03:04.0125 (UTC) FILETIME=[5573FED0:01C7FE81] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9540; t=1190620985; x=1191484985; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20More=20comments=20on=20draft-ietf-netlmm-proxymip6-05 .txt |Sender:=20; bh=swBTcnPb/5y3fgcpQNFcS4LY/R3fnJp/qfrTP1XbaQM=; b=X0eX7Y+KlSn0lekflrHwkI9lOA38tv2gLHwdiEnseawgcrcRGxpzOMA+pzwQTqbLo/qYgiUL MXtguNF3L9GqWq3EAHLmct61SndvGpnRQlIrTo9WMm+BmndK8DT2WuXMHqjPc0qrv3n5/5UgcT UJhzbujG2Ne09SB/d2S6imW+w=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: netlmm@ietf.org Subject: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Thanks for your review. Please see inline. > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: Friday, September 21, 2007 2:34 AM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: More comments on draft-ietf-netlmm-proxymip6-05.txt > > Hi Sri, > > I quickly went through the new draft. Good work, it has > improved a lot. > However, I have some more comments: > > - According to section 5.3, the LMA is allowed to accept a > de-registration PBU even if the PBU comes from an address > different than > the current Proxy-CoA in the BCE. I think this should not be > be allowed > - or only if the access link technology is able to detect the > event that > the MN leaves the MAG very quickly. The reason is that if the access > link technology needs long time to detect the absence of the > MN after af.org; Mon, 24 Sep 2007 04:03:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZiuV-0007Mj-22 for netlmm@ietf.org; Mon, 24 Sep 2007 04:03:25 -0400 X-IronPort-AV: E=Sophos;i="4.20,290,1186383600"; d="scan'208";a="223830158" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 24 Sep 2007 01:03:06 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8O8355j028816; Mon, 24 Sep 2007 01:03:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8O835in017309; Mon, 24 Sep 2007 08:03:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:04 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:04 -0700 From: "Sri Gundavelli" To: "'Kilian Weniger'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> Date: Mon, 24 Sep 2007 01:03:03 -0700 Message-ID: <003f01c7fe81$555e2ce0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> Thread-Index: Acf8Mf/s6Vq1PtL7TIOvDsZjpXW1+QBxWpjQ X-OriginalArrivalTime: 24 Sep 2007 08:03:04.0125 (UTC) FILETIME=[5573FED0:01C7FE81] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9540; t=1190620985; x=1191484985; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20More=20comments=20on=20draft-ietf-netlmm-proxymip6-05 .txt |Sender:=20; bh=swBTcnPb/5y3fgcpQNFcS4LY/R3fnJp/qfrTP1XbaQM=; b=X0eX7Y+KlSn0lekflrHwkI9lOA38tv2gLHwdiEnseawgcrcRGxpzOMA+pzwQTqbLo/qYgiUL MXtguNF3L9GqWq3EAHLmct61SndvGpnRQlIrTo9WMm+BmndK8DT2WuXMHqjPc0qrv3n5/5UgcT UJhzbujG2Ne09SB/d2S6imW+w=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: netlmm@ietf.org Subject: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Thanks for your review. Please see inline. > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: Friday, September 21, 2007 2:34 AM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: More comments on draft-ietf-netlmm-proxymip6-05.txt > > Hi Sri, > > I quickly went through the new draft. Good work, it has > improved a lot. > However, I have some more comments: > > - According to section 5.3, the LMA is allowed to accept a > de-registration PBU even if the PBU comes from an address > different than > the current Proxy-CoA in the BCE. I think this should not be > be allowed > - or only if the access link technology is able to detect the > event that > the MN leaves the MAG very quickly. The reason is that if the access > link technology needs long time to detect the absence of the > MN after a > handover, the de-registration may be sent by the old MAG after the PBU > from the new MAG is sent, which would delete the BCE and > result in lack > of session continuity. > The LMA should not delete the BCE for that request. It should only ACK the request. There is an explicit note now. > - Let's assume that the PBU from the new MAG after a handover is > received at the LMA more than MinDelayBeforeBCEDelete (default: 1s) > after the de-registration of the old MAG (e.g., due to long > handover or > network auth time or PBU delay). In this case, the LMA would > delete the > BCE for the MN before it receives the new PBU. I guess > according the LMA > would handle this PBU as initial registration and, i.e., > allocate a new > prefix to the MN, which means the session breaks. I think > this scenario > is not unlikely to occur with the current default value of only 1s for > MinDelayBeforeBCEDelete. To be on the save side, I would > propose a much > higher default value, e.g., 30s. > Ok. I can increase the def value. Its a configurable parameter and upto the deployment. Typically, the address manager component should always attempt to give the same prefix to the same mobile node. The prefix recycling should happen only when there are no prefixes to allocate. This is generally a design goal of any address manager components, used by DHCP or MIP. I will increase the def value slightly. > - The current text in section 5.3 may allow unauthorized nodes to find > out whether a MN has a BCE at a specific LMA as well as the link-local > address of the MN. > > "The Link-local Address option MUST be present in the > Proxy Binding > Acknowledgement message, if the same option was present in the > corresponding Proxy Binding Update request message. If there is > an existing Binding Cache entry for that mobile node with the > link-local address value of ALL_ZERO (value not set), > or if there > was no existing Binding Cache entry, then the link-local address > MUST be copied from the received Link-local Address > option in the > received Proxy Binding Update request. For all other cases, it > MUST be copied from the Binding Cache entry. > > It should be clarified that the LMA may only copy the > link-local address > from the BCE in the PBA, if the PBU was valid (i.e., status > code in PBA > < 128). > Ok. > - section 5.4 says > > "Upon receipt of a Proxy Binding Update message with the > Timestamp > option, the local mobility anchor MUST check the timestamp field > for validity. In order for it to be considered valid, the > timestamp value contained in the Timestamp option MUST be close > enough to the local mobility anchor's time-of-day clock and the > timestamp MUST be greater than all previously accepted > timestamps > in the Proxy Binding Update messages sent for that mobile node." > > "If the timestamp value in the received Proxy Binding > Update is not > valid, the local mobility anchor MUST reject the Proxy Binding > Update and send a Proxy Binding Acknowledgement message with > Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch). " > > According to this text, the TIMESTAMP_MISMATCH is sent everytime a PBU > overtakes another PBU, even if MAGs and LMA are in sync. Any > reason for > this? I think the last paragraph should say > > "if the timestamp value contained in the Timestamp option is not > close enough to the local mobility anchor's time-of-day > clock, the local > mobility anchor MUST reject the Proxy Binding Update and send a Proxy > Binding Acknowledgement message with > Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch)." > I slightly modified the order of messages. But, there is a flow here and the rules for timestamp validity determination are mentioned here. If the LMA and MAG clocks are in sync, TIMESTAMP_MISMATCH is not sent. Please let me know, if you are ok with this. o Upon receipt of a Proxy Binding Update message > handover, the de-registration may be sent by the old MAG after the PBU > from the new MAG is sent, which would delete the BCE and > result in lack > of session continuity. > The LMA should not delete the BCE for that request. It should only ACK the request. There is an explicit note now. > - Let's assume that the PBU from the new MAG after a handover is > received at the LMA more than MinDelayBeforeBCEDelete (default: 1s) > after the de-registration of the old MAG (e.g., due to long > handover or > network auth time or PBU delay). In this case, the LMA would > delete the > BCE for the MN before it receives the new PBU. I guess > according the LMA > would handle this PBU as initial registration and, i.e., > allocate a new > prefix to the MN, which means the session breaks. I think > this scenario > is not unlikely to occur with the current default value of only 1s for > MinDelayBeforeBCEDelete. To be on the save side, I would > propose a much > higher default value, e.g., 30s. > Ok. I can increase the def value. Its a configurable parameter and upto the deployment. Typically, the address manager component should always attempt to give the same prefix to the same mobile node. The prefix recycling should happen only when there are no prefixes to allocate. This is generally a design goal of any address manager components, used by DHCP or MIP. I will increase the def value slightly. > - The current text in section 5.3 may allow unauthorized nodes to find > out whether a MN has a BCE at a specific LMA as well as the link-local > address of the MN. > > "The Link-local Address option MUST be present in the > Proxy Binding > Acknowledgement message, if the same option was present in the > corresponding Proxy Binding Update request message. If there is > an existing Binding Cache entry for that mobile node with the > link-local address value of ALL_ZERO (value not set), > or if there > was no existing Binding Cache entry, then the link-local address > MUST be copied from the received Link-local Address > option in the > received Proxy Binding Update request. For all other cases, it > MUST be copied from the Binding Cache entry. > > It should be clarified that the LMA may only copy the > link-local address > from the BCE in the PBA, if the PBU was valid (i.e., status > code in PBA > < 128). > Ok. > - section 5.4 says > > "Upon receipt of a Proxy Binding Update message with the > Timestamp > option, the local mobility anchor MUST check the timestamp field > for validity. In order for it to be considered valid, the > timestamp value contained in the Timestamp option MUST be close > enough to the local mobility anchor's time-of-day clock and the > timestamp MUST be greater than all previously accepted > timestamps > in the Proxy Binding Update messages sent for that mobile node." > > "If the timestamp value in the received Proxy Binding > Update is not > valid, the local mobility anchor MUST reject the Proxy Binding > Update and send a Proxy Binding Acknowledgement message with > Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch). " > > According to this text, the TIMESTAMP_MISMATCH is sent everytime a PBU > overtakes another PBU, even if MAGs and LMA are in sync. Any > reason for > this? I think the last paragraph should say > > "if the timestamp value contained in the Timestamp option is not > close enough to the local mobility anchor's time-of-day > clock, the local > mobility anchor MUST reject the Proxy Binding Update and send a Proxy > Binding Acknowledgement message with > Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch)." > I slightly modified the order of messages. But, there is a flow here and the rules for timestamp validity determination are mentioned here. If the LMA and MAG clocks are in sync, TIMESTAMP_MISMATCH is not sent. Please let me know, if you are ok with this. o Upon receipt of a Proxy Binding Update message with the Timestamp option, the local mobility anchor MUST check the timestamp field for validity. In order for it to be considered valid, the timestamp value contained in the Timestamp option MUST be close enough to the local mobility anchor's time-of-day clock and the timestamp MUST be greater than all previously accepted timestamps in the Proxy Binding Update messages sent for that mobile node. o If the timestamp value in the received Proxy Binding Update is valid (validity as specified in the above considerations), the local mobility anchor MUST return the same timestamp value in the Timestamp option included in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway. o If the timestamp value in the received Proxy Binding Update is not valid (validity as specified in the above considerations), the local mobility anchor MUST reject the Proxy Binding Update and send a Proxy Binding Acknowledgement message with Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The message MUST also include the Timestamp option with the value set to the current time-of-day on the local mobility anchor. > - There may be a problem if the host happens to activate more than one > network interface (e.g., two WLAN interfaces) and as a result is > attached to more than one MAG simultaneously. In this "error" case > multiple MAGs would send PBUs for the same host and the BCE at the LMA > would constantly change even though the host is not moving. Since the > draft assumes unmodified hosts, I guess we can't mandate that the MN > only activates one interface. However, it might be helpful for > implementors to add some text that the base draft assumes only one > active interface and that multiple interface support is future work. > Ok. > - Section 6.9.2 begins with "The mobile node sends a Router > Solicitation > message on the access link when ever the link-layer detects a media > change.". I think this is only the case if the MN implements > DNA. If MN > doesn't implement DNA, it doesn't need to send RS when it > changes links. > It should send RS any time it detects a media change. I will look into this. > - section 5.3 seems to be a bit underspecified: What should > LMA do if it > receives binding de-registration or re-registration with prefix 0::0? > What should LMA do with incoming data packets after valid > de-registration was received, but BCE still exists due to > MinDelayBeforeBCEDelete? > I thought this is covered. I will look into this. > - The use of IPsec is not mandated according to section 4, but some > "MUST"s in the text still rely on Ipsec (see section 5.3, 6.9.1, 11). > E.g., "..It MUST use the SPI in the IPSec header [RFC-4306] of the > received packet for locating the security association needed for > authenticating the Proxy Binding Update request....The message MUST be > protected by using IPsec," > This was discussed in the ML and as many pointed out, this is ok. I had the same concern. The draft assumes IPsec as the default security mechanism and the mandate of securing the messages is when IPsec is in place. If IPsec is not used, this text is not relevant, the messages have to protected using the semantics offered by the chosen security mechanism. We cannot remove the "MUST" clause, the security directorate wont allow this. > - Section 6.14 talks about PMIP-MIP interactions scenario B and hence > should have an informative reference to > draft-giaretta-netlmm-mip-interactions-01. > The draft does not talk any thing about CMIP/PMIP interactions. There is no text related to this on the LMA. On the MAG, it only says, if the MAG is not allowed for PMIP service, it can allow simple IPv6 address configuration to the MN, a normal access router property. > BR, > > Kilian > > -------------------------------------------- > Dr. Kilian Weniger > Panasonic R&D Center Germany > Monzastr. 4c, 63225 Langen, Germany > phone: +49 (0)6103 766 137 > fax: +49 (0)6103 76with the Timestamp option, the local mobility anchor MUST check the timestamp field for validity. In order for it to be considered valid, the timestamp value contained in the Timestamp option MUST be close enough to the local mobility anchor's time-of-day clock and the timestamp MUST be greater than all previously accepted timestamps in the Proxy Binding Update messages sent for that mobile node. o If the timestamp value in the received Proxy Binding Update is valid (validity as specified in the above considerations), the local mobility anchor MUST return the same timestamp value in the Timestamp option included in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway. o If the timestamp value in the received Proxy Binding Update is not valid (validity as specified in the above considerations), the local mobility anchor MUST reject the Proxy Binding Update and send a Proxy Binding Acknowledgement message with Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The message MUST also include the Timestamp option with the value set to the current time-of-day on the local mobility anchor. > - There may be a problem if the host happens to activate more than one > network interface (e.g., two WLAN interfaces) and as a result is > attached to more than one MAG simultaneously. In this "error" case > multiple MAGs would send PBUs for the same host and the BCE at the LMA > would constantly change even though the host is not moving. Since the > draft assumes unmodified hosts, I guess we can't mandate that the MN > only activates one interface. However, it might be helpful for > implementors to add some text that the base draft assumes only one > active interface and that multiple interface support is future work. > Ok. > - Section 6.9.2 begins with "The mobile node sends a Router > Solicitation > message on the access link when ever the link-layer detects a media > change.". I think this is only the case if the MN implements > DNA. If MN > doesn't implement DNA, it doesn't need to send RS when it > changes links. > It should send RS any time it detects a media change. I will look into this. > - section 5.3 seems to be a bit underspecified: What should > LMA do if it > receives binding de-registration or re-registration with prefix 0::0? > What should LMA do with incoming data packets after valid > de-registration was received, but BCE still exists due to > MinDelayBeforeBCEDelete? > I thought this is covered. I will look into this. > - The use of IPsec is not mandated according to section 4, but some > "MUST"s in the text still rely on Ipsec (see section 5.3, 6.9.1, 11). > E.g., "..It MUST use the SPI in the IPSec header [RFC-4306] of the > received packet for locating the security association needed for > authenticating the Proxy Binding Update request....The message MUST be > protected by using IPsec," > This was discussed in the ML and as many pointed out, this is ok. I had the same concern. The draft assumes IPsec as the default security mechanism and the mandate of securing the messages is when IPsec is in place. If IPsec is not used, this text is not relevant, the messages have to protected using the semantics offered by the chosen security mechanism. We cannot remove the "MUST" clause, the security directorate wont allow this. > - Section 6.14 talks about PMIP-MIP interactions scenario B and hence > should have an informative reference to > draft-giaretta-netlmm-mip-interactions-01. > The draft does not talk any thing about CMIP/PMIP interactions. There is no text related to this on the LMA. On the MAG, it only says, if the MAG is not allowed for PMIP service, it can allow simple IPv6 address configuration to the MN, a normal access router property. > BR, > > Kilian > > -------------------------------------------- > Dr. Kilian Weniger > Panasonic R&D Center Germany > Monzastr. 4c, 63225 Langen, Germany > phone: +49 (0)6103 766 137 > fax: +49 (0)6103 766 166 > e-mail: kilian.weniger@eu.panasonic.com > -------------------------------------------- > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm 6 166 > e-mail: kilian.weniger@eu.panasonic.com > -------------------------------------------- > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 04:03:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiuu-0005KF-8C; Mon, 24 Sep 2007 04:03:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZiut-0005K2-Bt for netlmm@ietf.org; Mon, 24 Sep 2007 04:03:43 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZius-0000Xq-Bt for netlmm@ietf.org; Mon, 24 Sep 2007 04:03:43 -0400 X-IronPort-AV: E=Sophos;i="4.20,290,1186383600"; d="scan'208";a="10561656" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 24 Sep 2007 01:03:42 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8O83fl8031414; Mon, 24 Sep 2007 01:03:41 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8O83VX1000671; Mon, 24 Sep 2007 08:03:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:31 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:03:31 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" References: <13e7c8c50709210238j1195b6a0y82bef0b7195da3c7@mail.gmail.com> <46F39813.7080207@gmail.com> <015001c7fc5b$21c858b0$d5f6200a@amer.cisco.com> <46F3DB86.7080309@gmail.com> Subject: RE: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO Date: Mon, 24 Sep 2007 01:03:30 -0700 Message-ID: <004101c7fe81$659665a0$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46F3DB86.7080309@gmail.com> Thread-Index: Acf8X5oNWlFIxR3BQnyxEXIbkL2TawCDChpw X-OriginalArrivalTime: 24 Sep 2007 08:03:31.0354 (UTC) FILETIME=[65AECFA0:01C7FE81] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4494; t=1190621021; x=1191485021; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Re=3A=20DHCPv6=20deployment=20in=20PMIPv6= 20domain=20and=20SDO |Sender:=20; bh=ZlMGkAXrQrUACpfM63tvYvxkxyE4tsvu/MTpVLjUlQ4=; b=n+rHA7bY1iAR7y0GxHTdGNrtta60bvZI134LVqwgZXqvVUAFTPsPSrjWN5c0p/lp4C1FdsIN zxGIfwgilim1g1Upe0Nf37iHMD7bMAA1d1LRnD8Lec24ChQCZ/DJGQHL; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, > > > > Its important to note that in PMIP6, we are mostly changing the > > topology of the network, by moving the HNP between different MAG's. > > Once the prefix is hosted on a given MAG, the DHCP related > flows are > > consistent with the flows on fixed networks. So, we dont have any > > control on mandating not to enable DHCP relay on a given > MN-AR link. > > Sure, its a p2p link, but its a regular IPv6 link and DHCP > relay can > > be configured on that link. We are not defining any extensions are > > putting any hacks to make this work. It works naturally, > the text is > > there for offering some minimum guidance. So, if this configuration > > maken sense or not, is really upto the deployment. Some > operator may > > choose to use DHCP for downloading the address > configuration and ther > > options, and I dont think, we can disallow that configuration. > > Sri, I mainly agree with you and with the intention you > describe above. > I do support having DHCP Relay functionality on MAG. > Ok. Thanks > But your text has a restiction on which I don't agree. It says: > > 6.11. Interaction with DHCP Relay Agent > > > > If Stateful Address Configuration using DHCP is supported > on the link > > where the mobile node is attached, the DHCP relay agent [RFC-3315] > > needs to be configured on that access link. > > Why Relay and not Server too? I mean why silent about > Server? I think > there may be a case for DHCP Server on the MAG. > True, that is another possibility. There are two points here: - There is a DHCP server in the network. Where, we dont know. One of the MAG can be a DHCP server. A mobile on any link goes to the DHCP server on that specific MAG. - There is a DHCP server on each MAG and the mobile always goes to the local DHCP server on the link. The draft covers the general case of a DHCP server in the network. This is the most common case. It maps to the flows in fixed networks, where a node always goes to the same DHCP server. The second case is some what a special case and the draft does not deal with it. > And then it has a description which I don't understand: > > When the mobile node sends a DHCPv6 Request message, the DHCP relay > > agent function on the access link will set the link-address field in > > the DHCPv6 message to the mobile node's home network prefix, so as > > to provide a prefix hint to the DHCP Server for the address pool > > selection. > > You seem to assume DHCP Relay can use the HNP it received in P-BAck to > put it into the DHCP Request, right? But I think usually the > prefix of > a relay is configured statically at MAG in a configuration file, or in > its routing table. At DHCP Server that prefix is also configured > statically in the DHCP Server's configuration file. > > I don't understand how you assume the HNP can come dynamically to MAG > in the profile and then inserted by MAG as a hint in the DHCP Request > and then delivered back by DHCP Server in the address allocation? > > I'm afraid it may be a vicious circle (chicken and egg problem) > especially when the MAG-to-MN interfaces are ptp (each its own prefix) > and ephemeral up/down and possibly one prefix is valid on > different MAG > at different times. > Once a link is configured with an IPv6 prefix, any service can be enabled on the link. The OS/stack that provides the semantics for the link/prefix creation will also provide the semantics for the applications to query this information. This info can be in sysctl, queried using netlink, associated with the net_device interface entry or could be in runtime files. The applications, will have the ability to iterate prefixes on a given interface. This is true with Linux 2.6, Win32, NETBSD or IOS. Its the basic required programming interface. Now, when a DHCP relay agent is configured on the interface where the mobile node's home network prefix is hosted, the DHCP relay agent must set the prefix hint when forwarding the DHCP requests. How, it obtains that info is upto the implementation. Even 3315, does not specify how to obtain that prefix information. Not sure, if every implementation queries this from static files. It depends on how that UI is for that package. I can check how the WIDE's wide-dhcpv6-relay obtains the same. But, in any case, the requirement is as per 3315. Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 04:10:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZj0i-0002Iy-RM; Mon, 24 Sep 2007 04:09:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZj0h-0002Hz-Jg for netlmm@ietf.org; Mon, 24 Sep 2007 04:09:43 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZj0b-0007WV-7M for netlmm@ietf.org; Mon, 24 Sep 2007 04:09:43 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8O8907H026538 for ; Mon, 24 Sep 2007 11:09:25 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 11:09:11 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 11:08:58 +0300 Received: from fi-sateri023123.emea.nsn-net.net ([10.144.23.123]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 11:08:57 +0300 Message-ID: <46F77090.3050303@nsn.com> Date: Mon, 24 Sep 2007 11:08:48 +0300 From: "Soininen Jonne (NSN - FI/Espoo)" User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: netlmm@ietf.org Subject: Attempt to conclude this thread (Re: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05)) References: <7CCD07160348804497EF29E9EA5560D7024DA63A@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA63A@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Sep 2007 08:08:57.0328 (UTC) FILETIME=[27FA7F00:01C7FE82] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hello everybody, I think this discussion has gone long enough now. I can see most of the support for *allowing* (not mandating, requiring, etc) DHCPv6 on PMIP. This question is independent of the link model in use of the access network. I can see Kuntal and Alex disagreeing with this, but I cannot see anybody else supporting their opinion. Though, Alex has written quite big number of mails on the list. If there is a disagreement on this conclusion, I'm attempted to put this under a consensus call. Obviously, I have to discuss it with my co-chair first. For the usage of DHCP, PPP, and so on in different systems, I would hope people would do some studying before starting wars about the different models. I have put here some references, which I hope would help in this work: 1) 3GPP - the main spec for GPRS is 23.060 - you can find the IPv6 address allocation procedures under (The version number of the spec tells the release, version 3xx is release 99, 4xx is release 4, 5xx release five, etc.) http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/ 2) 3GPP - System Architecture Evolution (SAE) - the future stuff (23.401 and 23.402): http://www.3gpp.org/ftp/Specs/html-info/23401.htm http://www.3gpp.org/ftp/Specs/html-info/23402.htm 2) 3GPP2 - I don't know in which specs everything is in 3GPP2. However, at least pre EV-DO the packet core specs are in http://www.3gpp2.org/Public_html/specs/tsgp.cfm. Maybe somebody with more 3GPP2 knowledge can point to the right ones. 3) WiMax technical documents can be found at http://www.wimaxforum.org/technology/documents/ And especially for Alex, the PPP you are seeing in GPRS is most probably the PPP between your PC and the phone. The phone has a PPP server for PC connectivity. However, it does not run PPP over the radio interface to the GGSN (though there is this option in 23.060). I at least don't know anybody that would do that, and the only options my phone has are PDP Type IPv4 and IPv6. I hope this helps. Cheers, Jonne. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 04:17:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZj8J-00031F-LF; Mon, 24 Sep 2007 04:17:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZj8I-00031A-Q9 for netlmm@ietf.org; Mon, 24 Sep 2007 04:17:34 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZj8C-0007hV-Dh for netlmm@ietf.org; Mon, 24 Sep 2007 04:17:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8O8HBdD013723 for ; Mon, 24 Sep 2007 11:17:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 11:17:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 11:17:04 +0300 Received: from fi-sateri023123.emea.nsn-net.net ([10.144.23.123]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 11:17:04 +0300 Message-ID: <46F77278.5010405@nsn.com> Date: Mon, 24 Sep 2007 11:16:56 +0300 From: "Soininen Jonne (NSN - FI/Espoo)" User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: netlmm@ietf.org Subject: Re: Attempt to conclude this thread (Re: DHCPv6 deployment in PMIPv6 domain (Was: [netlmm]Commentsondraft-05)) References: <7CCD07160348804497EF29E9EA5560D7024DA63A@exchtewks2.starentnetworks.com> <46F77090.3050303@nsn.com> In-Reply-To: <46F77090.3050303@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Sep 2007 08:17:04.0206 (UTC) FILETIME=[4A2E2EE0:01C7FE83] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org ext Soininen Jonne (NSN - FI/Espoo) wrote: > Hello everybody, > > > I think this discussion has gone long enough now. I can see most of > the support for *allowing* (not mandating, requiring, etc) DHCPv6 on > PMIP. This question is independent of the link model in use of the > access network. I can see Kuntal and Alex disagreeing with this, but I > cannot see anybody else supporting their opinion. Though, Alex has > written quite big number of mails on the list. > > If there is a disagreement on this conclusion, I'm attempted to put > this under a consensus call. Obviously, I have to discuss it with my > co-chair first. > > > For the usage of DHCP, PPP, and so on in different systems, I would > hope people would do some studying before starting wars about the > different models. I have put here some references, which I hope would > help in this work: > > 1) 3GPP - the main spec for GPRS is 23.060 - you can find the IPv6 > address allocation procedures under I forgot to fill this in: "Dynamic IPv6 Address Allocation" is the string to search. > > (The version number of the spec tells the release, version 3xx is > release 99, 4xx is release 4, 5xx release five, etc.) > http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/ > > 2) 3GPP - System Architecture Evolution (SAE) - the future stuff > (23.401 and 23.402): > http://www.3gpp.org/ftp/Specs/html-info/23401.htm > http://www.3gpp.org/ftp/Specs/html-info/23402.htm > > 2) 3GPP2 - I don't know in which specs everything is in 3GPP2. > However, at least pre EV-DO the packet core specs are in > http://www.3gpp2.org/Public_html/specs/tsgp.cfm. Maybe somebody with > more 3GPP2 knowledge can point to the right ones. > > 3) WiMax technical documents can be found at > http://www.wimaxforum.org/technology/documents/ > > And especially for Alex, the PPP you are seeing in GPRS is most > probably the PPP between your PC and the phone. The phone has a PPP > server for PC connectivity. However, it does not run PPP over the > radio interface to the GGSN (though there is this option in 23.060). I > at least don't know anybody that would do that, and the only options > my phone has are PDP Type IPv4 and IPv6. > > I hope this helps. > > Cheers, > > Jonne. > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 04:20:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjBF-0007Ut-Ic; Mon, 24 Sep 2007 04:20:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjBC-0007UM-4v; Mon, 24 Sep 2007 04:20:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZjBB-0000zQ-J3; Mon, 24 Sep 2007 04:20:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 25A56175C6; Mon, 24 Sep 2007 08:20:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IZjAg-00021y-AE; Mon, 24 Sep 2007 04:20:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Sep 2007 04:20:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: netlmm@ietf.org Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-06.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF. Title : Proxy Mobile IPv6 Author(s) : S. Gundavelli, et al. Filename : draft-ietf-netlmm-proxymip6-06.txt Pages : 62 Date : 2007-09-24 This specification describes a network-based mobility management protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 [RFC-3775]. This protocol enables mobility support to a host without requiring its participation in any mobility related signaling. The design principle in the case of a network-based mobility management protocol relies on the network being in control of the mobility management. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-netlmm-proxymip6-06.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-ietf-netlmm-proxymip6-06.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: <2007-09-24041351.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-netlmm-proxymip6-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-netlmm-proxymip6-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-24041351.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --NextPart-- From netlmm-bounces@ietf.org Mon Sep 24 04:24:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjEm-00013o-5g; Mon, 24 Sep 2007 04:24:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjEg-0000yy-OL for netlmm@ietf.org; Mon, 24 Sep 2007 04:24:10 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZjEa-0007pk-Gl for netlmm@ietf.org; Mon, 24 Sep 2007 04:24:10 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1190622237!3424802!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 21704 invoked from network); 24 Sep 2007 08:23:57 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-13.tower-128.messagelabs.com with SMTP; 24 Sep 2007 08:23:57 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l8O8NYHO022961; Mon, 24 Sep 2007 01:23:34 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8O8NXUc024011; Mon, 24 Sep 2007 03:23:33 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8O8NU6f023967; Mon, 24 Sep 2007 03:23:31 -0500 (CDT) Message-ID: <46F77401.4070300@gmail.com> Date: Mon, 24 Sep 2007 10:23:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [netlmm] Re: DHCPv6 deployment in PMIPv6 domain and SDO References: <13e7c8c50709210238j1195b6a0y82bef0b7195da3c7@mail.gmail.com> <46F39813.7080207@gmail.com> <015001c7fc5b$21c858b0$d5f6200a@amer.cisco.com> <46F3DB86.7080309@gmail.com> <004101c7fe81$659665a0$d5f6200a@amer.cisco.com> In-Reply-To: <004101c7fe81$659665a0$d5f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-6, 22/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: netlmm@ietf.org, 'Julien Laganier' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri Gundavelli wrote: [...] >>> But your text has a restiction on which I don't agree. It says: >>> 6.11. Interaction with DHCP Relay Agent >>> >>> If Stateful Address Configuration using DHCP is supported >> on the link >>> where the mobile node is attached, the DHCP relay agent >>> [RFC-3315] needs to be configured on that access link. >> >> Why Relay and not Server too? I mean why silent about Server? I >> think there may be a case for DHCP Server on the MAG. >> > > True, that is another possibility. There are two points here: > > - There is a DHCP server in the network. Where, we dont know. One of > the MAG can be a DHCP server. A mobile on any link goes to the DHCP > server on that specific MAG. > > - There is a DHCP server on each MAG and the mobile always goes to > the local DHCP server on the link. > > The draft covers the general case of a DHCP server in the network. > This is the most common case. It maps to the flows in fixed networks, > where a node always goes to the same DHCP server. The second case is > some what a special case and the draft does not deal with it. Sri, I agree there are two cases as you describe. I think in your first case the assumption is that only one MAG is Server and other each runs Relay. I think there is a third case where all MAGs are Servers and they share their pools with Load Balancing, and there is no Relay. ISC DHCP can do this, I think, and there are specs for this. I also think there is a fourth case where each MAG is a DHCP Client simultaneously with being a Server and/or a Relay; Client requests a prefix with Prefix Delegation protocol. I think none of these 4 cases is more general than the others, and none should be prevented by the draft. >>> And then it has a description which I don't understand: When the >>> mobile node sends a DHCPv6 Request message, the DHCP relay agent >>> function on the access link will set the link-address field in >>> the DHCPv6 message to the mobile node's home network prefix, so >>> as to provide a prefix hint to the DHCP Server for the address >>> pool selection. >> >> You seem to assume DHCP Relay can use the HNP it received in P-BAck >> to put it into the DHCP Request, right? But I think usually the >> prefix of a relay is configured statically at MAG in a >> configuration file, or in its routing table. At DHCP Server that >> prefix is also configured statically in the DHCP Server's >> configuration file. >> >> I don't understand how you assume the HNP can come dynamically to >> MAG in the profile and then inserted by MAG as a hint in the DHCP >> Request and then delivered back by DHCP Server in the address >> allocation? >> >> I'm afraid it may be a vicious circle (chicken and egg problem) >> especially when the MAG-to-MN interfaces are ptp (each its own >> prefix) and ephemeral up/down and possibly one prefix is valid on >> different MAG at different times. >> > > Once a link is configured with an IPv6 prefix, any service can be > enabled on the link. The OS/stack that provides the semantics for the > link/prefix creation will also provide the semantics for the > applications to query this information. This info can be in sysctl, > queried using netlink, associated with the net_device interface entry > or could be in runtime files. The applications, will have the > ability to iterate prefixes on a given interface. This is true with > Linux 2.6, Win32, NETBSD or IOS. Its the basic required programming > interface. Right, this is in general. > Now, when a DHCP relay agent is configured on the interface where the > mobile node's home network prefix is hosted, the DHCP relay agent > must set the prefix hint when forwarding the DHCP requests. How, it > obtains that info is upto the implementation. Even 3315, does not > specify how to obtain that prefix information. > > Not sure, if every implementation queries this from static files. It > depends on how that UI is for that package. I can check how the > WIDE's wide-dhcpv6-relay obtains the same. But, in any case, the > requirement is as per 3315. Sri, when I'm trying to make this DHCP behaviour work for PMIPv6 I must modify the DHCP implementation on the MAG and LMA; I can't do it otherwise than modifying it. I'm not sure whether we're on the same wavelength here. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 04:25:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjFp-0001iz-OS; Mon, 24 Sep 2007 04:25:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjFo-0001is-56 for netlmm@ietf.org; Mon, 24 Sep 2007 04:25:20 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZjFm-0007sD-UN for netlmm@ietf.org; Mon, 24 Sep 2007 04:25:20 -0400 X-IronPort-AV: E=Sophos;i="4.20,290,1186383600"; d="scan'208";a="223839058" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Sep 2007 01:25:18 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8O8PIfS001222 for ; Mon, 24 Sep 2007 01:25:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8O8PIX1015773 for ; Mon, 24 Sep 2007 08:25:18 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:25:18 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 01:25:18 -0700 From: "Sri Gundavelli" To: Subject: FW: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-06.txt Date: Mon, 24 Sep 2007 01:25:17 -0700 Message-ID: <004b01c7fe84$70839c00$d5f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf+g+1fFlLesU0YTf6gbaOQlf9jvAAAAUyQ X-OriginalArrivalTime: 24 Sep 2007 08:25:18.0186 (UTC) FILETIME=[709D8CA0:01C7FE84] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3481; t=1190622318; x=1191486318; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20FW=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-proxymip6 -06.txt=20 |Sender:=20; bh=1EeP5XvZBBPltN0Fu/1rA72NrWEGTG+5FwOF8bvJdr4=; b=NVz1394ZwwhwS0ls56N/3jd4Zj5XFw7md9s/eQ4YJTIZJUWomPl2o+fxR4y9vnFPWOWpv2lm FPfxTU3jobiX3IeGNrDlTla4VjD+P1QuZ6BAmhAEb2TH8lPjBi5ESmF+; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I've updated the PMIP6 document based on the review comments I've received recently. I really want to speed up the LC process and so I've updated the document. I do not plan to spin any more versions before LC is initiated and complete. Any comments I missed or I may receive as part of the LC will be addressed only in the final version. This update is based on the discussions threads with JinHyeock, Julien, Alex, Pete, Kilian and many others ... Thanks Sri > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, September 24, 2007 1:20 AM > To: i-d-announce@ietf.org > Cc: netlmm@ietf.org > Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-06.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Network-based Localized > Mobility Management Working Group of the IETF. > > > Title : Proxy Mobile IPv6 > Author(s) : S. Gundavelli, et al. > Filename : draft-ietf-netlmm-proxymip6-06.txt > Pages : 62 > Date : 2007-09-24 > > This specification describes a network-based mobility management > protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 > [RFC-3775]. This protocol enables mobility support to a host without > requiring its participation in any mobility related signaling. The > design principle in the case of a network-based mobility management > protocol relies on the network being in control of the mobility > management. The mobility entities in the network are responsible for > tracking the movements of the host and initiating the required > mobility signaling on its behalf. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-06.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-ietf-netlmm-proxymip6-06.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-ietf-netlmm-proxymip6-06.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. > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 05:15:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZk1i-0001ex-8Z; Mon, 24 Sep 2007 05:14:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZk1g-0001dz-8y for netlmm@ietf.org; Mon, 24 Sep 2007 05:14:48 -0400 Received: from cluster-g.mailcontrol.com ([85.115.41.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZk1e-0002dg-Es for netlmm@ietf.org; Mon, 24 Sep 2007 05:14:48 -0400 Received: from rly14g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly14g.srv.mailcontrol.com (MailControl) with ESMTP id l8O9EfT5016690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Sep 2007 10:14:41 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly14g.srv.mailcontrol.com (MailControl) id l8O9EWZt016133 for netlmm@ietf.org; Mon, 24 Sep 2007 10:14:32 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly14g-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8O9ERUR015971; Mon, 24 Sep 2007 10:14:31 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 6e4a_dfcc3e72_6a7d_11dc_83f9_0030482aac25; Mon, 24 Sep 2007 11:09:36 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092411142008-92454 ; Mon, 24 Sep 2007 11:14:20 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.099,BAYES_00: -1.665,TOTAL_SCORE: -1.566 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Mon, 24 Sep 2007 11:14:14 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <003f01c7fe81$555e2ce0$d5f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-netlmm-proxymip6-05.txt Thread-Index: Acf8Mf/s6Vq1PtL7TIOvDsZjpXW1+QBxWpjQACLttvA= References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> <003f01c7fe81$555e2ce0$d5f6200a@amer.cisco.com> To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8BA3@lan-ex-02.panasonic.de> Date: Mon, 24 Sep 2007 11:11:40 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.71.1.124 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Cc: netlmm@ietf.org Subject: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, please see inline.=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Montag, 24. September 2007 10:03 > To: 'Kilian Weniger' > Cc: netlmm@ietf.org > Subject: RE: More comments on draft-ietf-netlmm-proxymip6-05.txt >=20 > Hi Kilian, >=20 > Thanks for your review. Please see inline.=20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > > Sent: Friday, September 21, 2007 2:34 AM > > To: Sri Gundavelli > > Cc: netlmm@ietf.org > > Subject: More comments on draft-ietf-netlmm-proxymip6-05.txt > >=20 > > Hi Sri,=20 > >=20 > > I quickly went through the new draft. Good work, it has=20 > > improved a lot. > > However, I have some more comments: > >=20 > > - According to section 5.3, the LMA is allowed to accept a > > de-registration PBU even if the PBU comes from an address=20 > > different than > > the current Proxy-CoA in the BCE. I think this should not be=20 > > be allowed > > - or only if the access link technology is able to detect the=20 > > event that > > the MN leaves the MAG very quickly. The reason is that if the access > > link technology needs long time to detect the absence of the=20 > > MN after a > > handover, the de-registration may be sent by the old MAG=20 > after the PBU > > from the new MAG is sent, which would delete the BCE and=20 > > result in lack > > of session continuity. > >=20 >=20 > The LMA should not delete the BCE for that request. It should only > ACK the request. There is an explicit note now. ok, I've seen the new note in draft-06: "If the received Proxy Binding Update request with the lifetime value of zero, has a Source Address in the IPv6 header, different from what is present in the Proxy-CoA address field in the Binding Cache entry existing for that mobile node, the local mobility anchor MAY either choose to ignore the request or send a valid Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted). However, it MUST NOT delete the mobile node's Binding Cache entry or modify the routing state created for that mobile node. That's fine with me (although I would prefer an explicit "only accept de-reg PBU if source address =3D=3D Proxy-CoA address in BCE"...) >=20 >=20 > > - Let's assume that the PBU from the new MAG after a handover is > > received at the LMA more than MinDelayBeforeBCEDelete (default: 1s) > > after the de-registration of the old MAG (e.g., due to long=20 > > handover or > > network auth time or PBU delay). In this case, the LMA would=20 > > delete the > > BCE for the MN before it receives the new PBU. I guess=20 > > according the LMA > > would handle this PBU as initial registration and, i.e.,=20 > > allocate a new > > prefix to the MN, which means the session breaks. I think=20 > > this scenario > > is not unlikely to occur with the current default value of=20 > only 1s for > > MinDelayBeforeBCEDelete. To be on the save side, I would=20 > > propose a much > > higher default value, e.g., 30s. > >=20 >=20 > Ok. I can increase the def value. Its a configurable parameter and > upto the deployment. Typically, the address manager component should > always attempt to give the same prefix to the same mobile node. The > prefix recycling should happen only when there are no prefixes to > allocate. This is generally a design goal of any address manager Even if the address manager component gives the same prefix to the MN when a new BCE is created, there would be no BCE and hence packet loss until the next PBU arrives at the LMA. The point is: what's the benefit of a small value for MinDelayBeforeBCEDelete, except for marginally reducing the memory consumption on the LMA? Is this worth the risk of significant packet loss due to erroneously deleted BCE?=20 > components, used by DHCP or MIP. I will increase the def=20 > value slightly. My comment still applies in draft-06: The default value for MinDelayBeforeBCEDelete is still 1s in draft-06. I think it should be much higher. Also, it would be good to have some text about too low values for MinDelayBeforeBCEDelete to raise awareness to the implementor... >=20 >=20 > > - The current text in section 5.3 may allow unauthorized=20 > nodes to find > > out whether a MN has a BCE at a specific LMA as well as the=20 > link-local > > address of the MN. > >=20 > > "The Link-local Address option MUST be present in the=20 > > Proxy Binding > > Acknowledgement message, if the same option was present in the > > corresponding Proxy Binding Update request message. =20 > If there is > > an existing Binding Cache entry for that mobile node with the > > link-local address value of ALL_ZERO (value not set),=20 > > or if there > > was no existing Binding Cache entry, then the=20 > link-local address > > MUST be copied from the received Link-local Address=20 > > option in the > > received Proxy Binding Update request. For all other=20 > cases, it > > MUST be copied from the Binding Cache entry. > >=20 > > It should be clarified that the LMA may only copy the=20 > > link-local address > > from the BCE in the PBA, if the PBU was valid (i.e., status=20 > > code in PBA > > < 128).=20 > >=20 >=20 >=20 > Ok. >=20 >=20 > > - section 5.4 says=20 > >=20 > > "Upon receipt of a Proxy Binding Update message with the=20 > > Timestamp > > option, the local mobility anchor MUST check the=20 > timestamp field > > for validity. In order for it to be considered valid, the > > timestamp value contained in the Timestamp option=20 > MUST be close > > enough to the local mobility anchor's time-of-day=20 > clock and the > > timestamp MUST be greater than all previously accepted=20 > > timestamps > > in the Proxy Binding Update messages sent for that=20 > mobile node." > > =20 > > "If the timestamp value in the received Proxy Binding=20 > > Update is not > > valid, the local mobility anchor MUST reject the Proxy Binding > > Update and send a Proxy Binding Acknowledgement message with > > Status field set to TIMESTAMP_MISMATCH (Timestamp=20 > mismatch). " > >=20 > > According to this text, the TIMESTAMP_MISMATCH is sent=20 > everytime a PBU > > overtakes another PBU, even if MAGs and LMA are in sync. Any=20 > > reason for > > this? I think the last paragraph should say=20 > >=20 > > "if the timestamp value contained in the Timestamp=20 > option is not > > close enough to the local mobility anchor's time-of-day=20 > > clock, the local > > mobility anchor MUST reject the Proxy Binding Update and=20 > send a Proxy > > Binding Acknowledgement message with > > Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch)." > >=20 >=20 > I slightly modified the order of messages. But, there is a flow here > and the rules for timestamp validity determination are mentioned here. > If the LMA and MAG clocks are in sync, TIMESTAMP_MISMATCH is not sent. > Please let me know, if you are ok with this. >=20 > o Upon receipt of a Proxy Binding Update message with the Timestamp > option, the local mobility anchor MUST check the timestamp field > for validity. In order for it to be considered valid, the > timestamp value contained in the Timestamp option MUST be close > enough to the local mobility anchor's time-of-day clock and the > timestamp MUST be greater than all previously accepted=20 > timestamps > in the Proxy Binding Update messages sent for that mobile node. >=20 > o If the timestamp value in the received Proxy Binding Update is > valid (validity as specified in the above considerations), the > local mobility anchor MUST return the same timestamp=20 > value in the > Timestamp option included in the Proxy Binding Acknowledgement > message that it sends to the mobile access gateway. >=20 > o If the timestamp value in the received Proxy Binding=20 > Update is not > valid (validity as specified in the above considerations), the > local mobility anchor MUST reject the Proxy Binding Update and > send a Proxy Binding Acknowledgement message with=20 > Status field set > to TIMESTAMP_MISMATCH (Timestamp mismatch). The=20 > message MUST also > include the Timestamp option with the value set to the current > time-of-day on the local mobility anchor. >=20 My comment still applies in draft-06, since the first paragraph still says "In order for it to be considered valid,... the timestamp MUST be greater than all previously accepted timestamps." So a TIMESTAMP_MISMATCH may be returned even if the clocks are in sync. Assuming MAG1 and MAG2 are in sync. MAG1 sends PBU1 at time t1 and MAG2 sends PBU2 at time t2 with t2>t1. If now PBU2 overtakes PBU1, i.e., PBU1 arrives at LMA after PBU2, the LMA would send a PBA with TIMESTAMP_MISMATCH, even though MAG1 and MAG2 are in sync.=20 I assumed so far that a TIMESTAMP_MISMATCH code shall tell the MAG that its clock is out of sync for diagnostics purposes and potentially for triggering the necessary actions to synchronize clocks again (e.g., using NTP). This is not really the case with the above text. Maybe it is better to have two different status codes: 1. if the timestamp is not close enough to the local mobility anchor's time-of-day clock 2. if the timestamp is lower than previously accepted timestamps Only in the first case, the MAG should trigger necessary actions to synchronize clocks... >=20 > > - There may be a problem if the host happens to activate=20 > more than one > > network interface (e.g., two WLAN interfaces) and as a result is > > attached to more than one MAG simultaneously. In this "error" case > > multiple MAGs would send PBUs for the same host and the BCE=20 > at the LMA > > would constantly change even though the host is not moving.=20 > Since the > > draft assumes unmodified hosts, I guess we can't mandate that the MN > > only activates one interface. However, it might be helpful for > > implementors to add some text that the base draft assumes only one > > active interface and that multiple interface support is future work. > >=20 >=20 > Ok. >=20 > > - Section 6.9.2 begins with "The mobile node sends a Router=20 > > Solicitation > > message on the access link when ever the link-layer detects a media > > change.". I think this is only the case if the MN implements=20 > > DNA. If MN > > doesn't implement DNA, it doesn't need to send RS when it=20 > > changes links. > >=20 >=20 > It should send RS any time it detects a media change. I will look > into this. My comment still applies in draft-06. Sending RS is only a "may" according to RFC2461 and RFC2461bis: "When an interface becomes enabled, a host may be unwilling to wait for the next unsolicited Router Advertisement to locate default routers or learn prefixes. To obtain Router Advertisements quickly, a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. - The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management. - The host attaches to a link for the first time. - The host re-attaches to a link after being detached for some time." >=20 > > - section 5.3 seems to be a bit underspecified: What should=20 > > LMA do if it > > receives binding de-registration or re-registration with=20 > prefix 0::0? > > What should LMA do with incoming data packets after valid > > de-registration was received, but BCE still exists due to > > MinDelayBeforeBCEDelete? > >=20 >=20 > I thought this is covered. I will look into this. I didn't see any related changes in draft-06. To be covered in draft-07? >=20 >=20 > > - The use of IPsec is not mandated according to section 4, but some > > "MUST"s in the text still rely on Ipsec (see section 5.3,=20 > 6.9.1, 11). > > E.g., "..It MUST use the SPI in the IPSec header [RFC-4306] of the > > received packet for locating the security association needed for > > authenticating the Proxy Binding Update request....The=20 > message MUST be > > protected by using IPsec," > >=20 >=20 > This was discussed in the ML and as many pointed out, this is=20 > ok. I had > the same concern. The draft assumes IPsec as the default security > mechanism and the mandate of securing the messages is when IPsec is in > place. If IPsec is not used, this text is not relevant, the=20 > messages have > to protected using the semantics offered by the chosen=20 > security mechanism. > We cannot remove the "MUST" clause, the security directorate=20 > wont allow > this. ok >=20 > > - Section 6.14 talks about PMIP-MIP interactions scenario B=20 > and hence > > should have an informative reference to > > draft-giaretta-netlmm-mip-interactions-01. > >=20 >=20 > The draft does not talk any thing about CMIP/PMIP interactions. There > is no text related to this on the LMA. On the MAG, it only says, if > the MAG is not allowed for PMIP service, it can allow simple IPv6 > address configuration to the MN, a normal access router property. Well, it doesn't say "CMIP", but it says host-based mobility protocol ;) If the host-based mobility protocol is MIPv6, then this is exactly scenario B in draft-giaretta-netlmm-mip-interactions-01. So why not add an informative reference? There is also a reference to the IPv4-PMIP extension draft draft-ietf-netlmm-pmip6-ipv4-support-01.txt... BR, Kilian >=20 > > BR, > >=20 > > Kilian > >=20 > > -------------------------------------------- > > Dr. Kilian Weniger > > Panasonic R&D Center Germany > > Monzastr. 4c, 63225 Langen, Germany > > phone: +49 (0)6103 766 137 > > fax: +49 (0)6103 766 166 > > e-mail: kilian.weniger@eu.panasonic.com > > -------------------------------------------- > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 07:43:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZmL8-00033v-TA; Mon, 24 Sep 2007 07:43:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZmL6-00031x-UV for netlmm@ietf.org; Mon, 24 Sep 2007 07:43:00 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZmL1-0004Tx-PX for netlmm@ietf.org; Mon, 24 Sep 2007 07:43:00 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1190634152!20524629!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 1590 invoked from network); 24 Sep 2007 11:42:32 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-2.tower-119.messagelabs.com with SMTP; 24 Sep 2007 11:42:32 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8OBgVLS003608; Mon, 24 Sep 2007 04:42:31 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l8OBgU1B009263; Mon, 24 Sep 2007 06:42:31 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8OBgSjn009244; Mon, 24 Sep 2007 06:42:29 -0500 (CDT) Message-ID: <46F7A2A4.7010602@gmail.com> Date: Mon, 24 Sep 2007 13:42:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: FW: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-06.txt References: <004b01c7fe84$70839c00$d5f6200a@amer.cisco.com> In-Reply-To: <004b01c7fe84$70839c00$d5f6200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-6, 22/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri Gundavelli wrote: > > I've updated the PMIP6 document based on the review comments I've > received recently. I really want to speed up the LC process and so > I've updated the document. I do not plan to spin any more versions > before LC is initiated and complete. Any comments I missed or I may > receive as part of the LC will be addressed only in the final > version. > > This update is based on the discussions threads with JinHyeock, > Julien, Alex, Pete, Kilian and many others ... Thanks for the update, I've checked it fits my understanding of timestamp-vs-seqno. I don't know when you spin more versions, but here are more comments. > 6.11. Supporting DHCPv6 based Address Configuration on the Access > Link > > This non-normative section explains how Stateful Address > Configuration using DHCPv6 can be enabled on the access link attached > to a mobile access gateway and how a mobile node attached to that > link can obtain an address from its home network prefix using DHCPv6. Basically I agree that the DHCP behaviour described in this section is non-normative (==informative?). Would it be better placed as an Appendix? > If the received Router Advertisement has the Managed Address > Configuration flag set, the mobile node, as it would normally do, > will send a DHCPv6 Request [RFC-3315]. I think it will first send a Solicit, to discover DHCP Server's address. 'Request' would come after the 'Advertise' the Server sends. Moreover, if/when we're to discuss DHCP behaviour we risk important disagreements on how it should work. (1) how prefix delegation is integrated, (2) how PMIP6 handover influences DHCP exchanges, (3) how and what the MAG DHCP Relay inserts in the client messages, (4) how the server identifies the client. I have some doubts about MAG DHCP Relay inserting the HNP into the link-address field of RELAY-FORW. I don't think that field was designed with ephemeral ptp interfaces in mind, but with fixed shared non-dynamic interfaces in mind. And I don't think the HNP is the right identifier for that ephemeral link. I think a better tool for this need could be to insert the Subscriber-ID option (rfc4580) by the MAG DHCP Relay in the RELAY-FORW message, to contain the MAC address of the mobile; or the Remote-ID (rfc4649). I think at least these two are better adapted for ephemeral ptp links, better than the link-address field. Or a variant thereof. Nits: > In this format, the integer number of seconds is contained in the > first 48 bits of the field, and the remaining 16 bits indicate the > number of 1/64K fractions of a second. 1/64000 fractions of a second? Or 1/65536 fractions of a second. I propose to specifically say 1/65536 fractions because 64k means 65536 only if we talk bits (not seconds), in my understanding. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 10:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZonA-0002GL-Lh; Mon, 24 Sep 2007 10:20:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZonA-0002GG-35 for netlmm@ietf.org; Mon, 24 Sep 2007 10:20:08 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZon9-0002Oq-7W for netlmm@ietf.org; Mon, 24 Sep 2007 10:20:07 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1190643604!21786835!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4041 invoked from network); 24 Sep 2007 14:20:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 24 Sep 2007 14:20:05 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8OEK4mD010492; Mon, 24 Sep 2007 07:20:04 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l8OEK3D1004084; Mon, 24 Sep 2007 09:20:03 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l8OEK198004044; Mon, 24 Sep 2007 09:20:01 -0500 (CDT) Message-ID: <46F7C790.4040006@gmail.com> Date: Mon, 24 Sep 2007 16:20:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> <003f01c7fe81$555e2ce0$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8BA3@lan-ex-02.panasonic.de> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8BA3@lan-ex-02.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000775-6, 22/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Kilian Weniger wrote: [...] >>> - Section 6.9.2 begins with "The mobile node sends a Router >>> Solicitation message on the access link when ever the link-layer >>> detects a media change.". I think this is only the case if the >>> MN implements DNA. If MN doesn't implement DNA, it doesn't need >>> to send RS when it changes links. >>> >> It should send RS any time it detects a media change. I will look >> into this. > > My comment still applies in draft-06. Sending RS is only a "may" > according to RFC2461 and RFC2461bis: > > "When an interface becomes enabled, a host may be unwilling to wait > for the next unsolicited Router Advertisement to locate default > routers or learn prefixes. To obtain Router Advertisements quickly, > a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router > Solicitation messages each separated by at least > RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent > after any of the following events: > > - The interface is initialized at system startup time. > > - The interface is reinitialized after a temporary interface failure > or after being temporarily disabled by system management. > > - The system changes from being a router to being a host, by having > its IP forwarding capability turned off by system management. > > - The host attaches to a link for the first time. > > - The host re-attaches to a link after being detached for some time." > > On this particular topic. For one, I think the mobile will do whatever it already does when attaching to a new link: MLD REPORT first, RS first, NS first, optimistic DAD, or DNA. Our requirement is to not modify the mobile, so we can't demand the mobile what to do first. We thus can't assume that the mobile will do a RS first when it attaches. The MAG should be able to react on any one of the following: linkup trigger, NS, RS and even on MLD JOIN. Nit: > Further, if the mobile node uses an interface identifier that is not > based on EUI-64 identifier, such as specified in IPv6 Stateless > Autoconfiguration specification [RFC-2462], there is a very low > possibility of a link-local address collision between the two > neighbors on that access link. I think you meant "id that _is_ based on EUI-64 identifier", right? Or you meant "for mobiles which negotiate addresses with a ptp lower layer protocol the probability of collision is low? And also maybe we should refer to draft-ietf-ipv6-rfc2462bis-08.txt and/or rfc4862 instead of rfc2462? I think for 802.16 access we can assume the address is formed from the 48bit MAC address. Nit: > > o The mobile access gateway on receiving the Router Solicitation > message SHOULD send a Router Advertisement containing the mobile > node's home network prefix as the on-link prefix. However, before > sending the Router Advertisement message containing the mobile node's > home network prefix, it SHOULD complete the binding registration > process with the mobile node's local mobility anchor. I think it should say that the MAG should _have_ completed the binding registration process; because the paragraph interpreted on itself means the order of operations is like this: RS, PBU/PBAck, RA. Or, figure 2 says it's: PBU/PBAck, RS, RA. I think figure 2 is correct and the paragraph above is incorrect, should contain the 'have completed'. Nit: > The mobile access gateway can learn the mobile node's link-local > address, by snooping the DAD messages sent by the mobile node for I think a better term than 'snooping' here is to require MAG to read the Target Address from the NS sent by the mobile with a src address field unspecified. That's surely a DAD'ing NS. Alternatively, the MAG could read the dst address of that NS and convert it from multicast to link-local unicast format. An even faster way for MAG to learn that address is to read and interpret the MLD Report message sent by the mobile _before_ that NS was sent. > establishing the link-local address uniqueness on the access link. > Subsequently, at each handoff, the mobile access gateway can obtain > this address from the local mobility anchor to ensure link-local > address uniqueness and may change its own link-local address, if it > detects a collision. This I really don't understand. A MAG will see only one attachment of a mobile, not any subsequent 'handovers'. A handover involves two MAGs. This is really unclear to me, sorry. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 13:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrJs-0000gD-M9; Mon, 24 Sep 2007 13:02:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrJq-0000fa-LS for netlmm@ietf.org; Mon, 24 Sep 2007 13:02:02 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZrJp-0008A0-Rh for netlmm@ietf.org; Mon, 24 Sep 2007 13:02:02 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8OH1vh27526; Mon, 24 Sep 2007 17:01:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt Date: Mon, 24 Sep 2007 12:01:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116E961F8@zrc2hxm2.corp.nortel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8BA3@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt Thread-Index: Acf8Mf/s6Vq1PtL7TIOvDsZjpXW1+QBxWpjQACLttvAAEWtH8A== References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> <003f01c7fe81$555e2ce0$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8BA3@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" , "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Please see one comment below. Regards, > >=20 > > o If the timestamp value in the received Proxy Binding Update is > > valid (validity as specified in the above considerations), the > > local mobility anchor MUST return the same timestamp value in=20 > > the > > Timestamp option included in the Proxy Binding Acknowledgement > > message that it sends to the mobile access gateway. > >=20 > > o If the timestamp value in the received Proxy Binding=20 > Update is=20 > > not > > valid (validity as specified in the above considerations), the > > local mobility anchor MUST reject the Proxy Binding Update and > > send a Proxy Binding Acknowledgement message with=20 > Status field=20 > > set > > to TIMESTAMP_MISMATCH (Timestamp mismatch). The message MUST=20 > > also > > include the Timestamp option with the value set to the current > > time-of-day on the local mobility anchor. > >=20 >=20 > My comment still applies in draft-06, since the first=20 > paragraph still says "In order for it to be considered=20 > valid,... the timestamp MUST be greater than all previously=20 > accepted timestamps." So a TIMESTAMP_MISMATCH may be returned=20 > even if the clocks are in sync. >=20 > Assuming MAG1 and MAG2 are in sync. MAG1 sends PBU1 at time=20 > t1 and MAG2 sends PBU2 at time t2 with t2>t1. If now PBU2=20 > overtakes PBU1, i.e., PBU1 arrives at LMA after PBU2, the LMA=20 > would send a PBA with TIMESTAMP_MISMATCH, even though MAG1=20 > and MAG2 are in sync.=20 >=20 > I assumed so far that a TIMESTAMP_MISMATCH code shall tell=20 > the MAG that its clock is out of sync for diagnostics=20 > purposes and potentially for triggering the necessary actions=20 > to synchronize clocks again (e.g., using NTP). This is not=20 > really the case with the above text. >=20 > Maybe it is better to have two different status codes: > 1. if the timestamp is not close enough to the local mobility=20 > anchor's time-of-day clock 2. if the timestamp is lower than=20 > previously accepted timestamps Only in the first case, the=20 > MAG should trigger necessary actions to synchronize clocks... [Ahmad] Just one clarification. In the case that the P-BU coming from the same MAG or P-CoA, LMA SHALL discard the P-BU. Otherwise, it is a race condition during a handoff scenario and the LMA can send MN-Handoff-in-Progress or LMA SHOULD ignore the P-BU. In case we are concerned about MAG1 retransmitting the P-BU, LMA should send a revocation message to MAG1. Thanks. >=20 > >=20 > > > - There may be a problem if the host happens to activate > > more than one > > > network interface (e.g., two WLAN interfaces) and as a result is=20 > > > attached to more than one MAG simultaneously. In this=20 > "error" case=20 > > > multiple MAGs would send PBUs for the same host and the BCE > > at the LMA > > > would constantly change even though the host is not moving.=20 > > Since the > > > draft assumes unmodified hosts, I guess we can't mandate=20 > that the MN=20 > > > only activates one interface. However, it might be helpful for=20 > > > implementors to add some text that the base draft assumes=20 > only one=20 > > > active interface and that multiple interface support is=20 > future work. > > >=20 > >=20 > > Ok. > >=20 > > > - Section 6.9.2 begins with "The mobile node sends a Router=20 > > > Solicitation message on the access link when ever the link-layer=20 > > > detects a media change.". I think this is only the case if the MN=20 > > > implements DNA. If MN doesn't implement DNA, it doesn't=20 > need to send=20 > > > RS when it changes links. > > >=20 > >=20 > > It should send RS any time it detects a media change. I=20 > will look into=20 > > this. >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 13:24:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrft-0000J8-B0; Mon, 24 Sep 2007 13:24:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrfr-0000Iy-Jn for netlmm@ietf.org; Mon, 24 Sep 2007 13:24:47 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZrfl-0006sK-3l for netlmm@ietf.org; Mon, 24 Sep 2007 13:24:47 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8OHO9wu032438; Mon, 24 Sep 2007 20:24:19 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 20:24:11 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 12:24:09 -0500 Received: from 172.19.244.176 ([172.19.244.176]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 24 Sep 2007 17:24:09 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 24 Sep 2007 12:24:11 -0500 Subject: Re: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt From: Basavaraj Patil To: ext Ahmad Muhanna , Kilian Weniger , Sri Gundavelli Message-ID: Thread-Topic: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt Thread-Index: Acf8Mf/s6Vq1PtL7TIOvDsZjpXW1+QBxWpjQACLttvAAEWtH8AABuo7L In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116E961F8@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Sep 2007 17:24:09.0132 (UTC) FILETIME=[B75C66C0:01C7FECF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, On 9/24/07 12:01 PM, "ext Ahmad Muhanna" wrote: > > [Ahmad] > > Just one clarification. > In the case that the P-BU coming from the same MAG or P-CoA, LMA SHALL > discard the P-BU. Otherwise, it is a race condition during a handoff > scenario and the LMA can send MN-Handoff-in-Progress or LMA SHOULD > ignore the P-BU. In case we are concerned about MAG1 retransmitting the > P-BU, LMA should send a revocation message to MAG1. Is this MN-Handoff-in-progress a new message that you are considering as a solution to the problem? I don't think we should be considering adding more signaling messages to the base protocol. -Raj > > > Thanks. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 13:31:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrmX-0008OQ-Gi; Mon, 24 Sep 2007 13:31:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrmW-0008IA-AA for netlmm@ietf.org; Mon, 24 Sep 2007 13:31:40 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZrmQ-00077v-3N for netlmm@ietf.org; Mon, 24 Sep 2007 13:31:40 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8OHVFq24878; Mon, 24 Sep 2007 17:31:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt Date: Mon, 24 Sep 2007 12:31:10 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116E962A9@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt Thread-Index: Acf8Mf/s6Vq1PtL7TIOvDsZjpXW1+QBxWpjQACLttvAAEWtH8AABuo7LAAAi2QA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116E961F8@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Basavaraj Patil" , "Kilian Weniger" , "Sri Gundavelli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Raj, Good catch.=20 Since Kilian was proposing a new code I felt that probably understood. My mistake. I am proposing a new code "MN-Handoff-in-Progress" in the P-BA. 2 other proposals are included too. Any one should work. Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Monday, September 24, 2007 12:24 PM > To: Muhanna, Ahmad (RICH1:2H10); Kilian Weniger; Sri Gundavelli > Cc: netlmm@ietf.org > Subject: Re: [netlmm] RE: More comments on=20 > draft-ietf-netlmm-proxymip6-05.txt >=20 >=20 > Hi Ahmad, >=20 >=20 > On 9/24/07 12:01 PM, "ext Ahmad Muhanna" wrote: >=20 > >=20 > > [Ahmad] > >=20 > > Just one clarification. > > In the case that the P-BU coming from the same MAG or=20 > P-CoA, LMA SHALL=20 > > discard the P-BU. Otherwise, it is a race condition during=20 > a handoff=20 > > scenario and the LMA can send MN-Handoff-in-Progress or LMA SHOULD=20 > > ignore the P-BU. In case we are concerned about MAG1 retransmitting=20 > > the P-BU, LMA should send a revocation message to MAG1. >=20 > Is this MN-Handoff-in-progress a new message that you are=20 > considering as a solution to the problem? I don't think we=20 > should be considering adding more signaling messages to the=20 > base protocol. >=20 > -Raj >=20 > >=20 > >=20 > > Thanks. >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 19:32:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZxPp-0008Kg-UB; Mon, 24 Sep 2007 19:32:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZxPp-0008Gf-By for netlmm@ietf.org; Mon, 24 Sep 2007 19:32:37 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZxPj-0003hN-1c for netlmm@ietf.org; Mon, 24 Sep 2007 19:32:32 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l8ONWUuT029213 for ; Mon, 24 Sep 2007 18:32:30 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 18:32:30 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 18:32:29 -0500 Message-ID: <46F848E2.40904@ericsson.com> Date: Mon, 24 Sep 2007 19:31:46 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: netlmm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Sep 2007 23:32:30.0023 (UTC) FILETIME=[2C84BD70:01C7FF03] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Subject: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Authors, I have tried to do a complete review of the PMIP document. If any of these comments have been fixed in -06 please feel free to ignore them. Thanks Suresh Major ===== Overall ======= Link Local address of MAG ========================= When an MN moves from one link to another how does it switch default routers to the new MAG. The link local addresses of the old MAG and the new MAG will most likely be different and hence unless nud removes the old mag the mn will try to reach it even after handover. Or it is assumed that all the MAGs will have the same LL address? Is this is an assumption, it needs to be stated. Timestamp synchronization ========================= I read through the timestamp approach for synchronization and it is unclear why the MAG and the LMA need to sync their clocks. I think it is sufficient for MAGs to sync between themselves. Why does the LMA need to check if the MAGs timestamp is different from its timestamp? LMA Address acquisition ======================= Why is the LMA address a mandatory part of the MN profile? And why is it the ONLY allowed method for acquiring an LMA address? Can't the MAG use some other method to acquire the LMA address (static config, DNS...). I think this is overly restrictive. Section 4 ========= "IKEv2 [RFC-4306] SHOULD be used to setup security associations between the mobile access gateway and the local mobility anchor to protect the Proxy Binding Update and Proxy Binding Acknowledgement messages." This is a significant departure from RFC3775 where this was a MAY. What is the reasoning behind making this a SHOULD? I believe manual config should be a MUST and automatic key mgmt should be a MAY. P flag ====== I do not see any text in the expected LMA behavior to CHECK for the presence of the P flag in the received BU. I think this should be added. Section 5.3: Binding De-registration ==================================== "Upon accepting the Proxy Binding Update request for a mobile node, with the lifetime value of zero, the local mobility anchor MUST wait for MinDelayBeforeBCEDelete amount of time, before it deletes the mobile node's Binding Cache entry." What is the purpose for having a timer to delete a BCE? I see no reason at all in waiting. If this is being done to prevent considering a following BU as an initial registration ( I suspect this is the case) please extend the conceptual data structure to add a deleted flag instead of using a timer. The following step directly contradicts this step as well. Make sure that they are consistent. Section 5.3: PBA formation ========================== " If the Status field is set to a value greater less than 128, i.e. if the binding request was rejected, then the prefix value in the Home Network Prefix option MUST be set to the prefix value from the received Home Network Prefix option." This does not cover the case where the PBU did not contain a HNP option (rejection with error 129). So the text needs to be extended in order to clarify the behavior in such case. I would suggest the following text " If the Status field is set to a value greater less than 128, i.e. if the binding request was rejected, then the prefix value in the Home Network Prefix option MUST be set to the prefix value from the received Home Network Prefix option. If the received PBU did not contain a Home Network Prefix option, then the HNP option MUST NOT be included. " This also implies that the HNP field becomes optional in the PBA. Section 6.8 =========== I am not sure how the odds of collision are arrived at. If there is a reference please put it in here. However I look at it, the number does not look too good to me. Anyway, this feels totally out of place in the PMIP spec. Thus, as an alternative, you can remove the whole text without losing anything. Section 6.9.1 ============= "o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Not authorized for that prefix), the mobile access gateway SHOULD try to request for that prefix in the binding registration request, only after it learned the validity of that prefix." I am not sure why the MAG SHOULD try again. If this error case occurs, I think that the MAG SHOULD do one of the following 1) Deny mobility service to the MN 2) Send a PBU with the null hnp to request a new prefix allocation Section 6.9.3 ============= " o If Timestamp based scheme is in use, the retransmitted Proxy Binding Update messages MUST use the latest timestamp. If Sequence number scheme is in use, the retransmitted Proxy Binding Update messages MUST use a Sequence Number value greater than that used for the previous transmission of this Proxy Binding Update message, just as specified in [RFC-3775]." I completely disagree with this. I think if a PBU is retransmitted it MUST use the same timestamp as the first time around. Otherwise we will run into ordering problems. Section 6.11 ============ I am not sure how the MAG can send the HNP of the MN in the link-address field of the DHCP relay message since the link-address field does not contain a prefix length. Is there an implicit assumption that the prefix will be 64 bits in length? IANA Considerations =================== Don't forget to request the assignment of the P bit in the BU and BA messages in the IANA considerations section. Minor ===== Section 3 ========= Figure 3: The detach flow is not explained at all. If the detach flow needs to stay in the figure, it needs to be elaborated in the following text. It is probably not relevant in this figure either, since the BCE gets replaced by the new PBU anyway. Section 5.3 =========== The following two bullets refer to section 4.0 that does not exist. Can you insert the reference to the right section here. (I am assuming it is section 4 but I am not sure) o The local mobility anchor MUST authenticate the Proxy Binding Update request as described in Section 4.0. It MUST use the SPI in the IPSec header [RFC-4306] of the received packet for locating the security association needed for authenticating the Proxy Binding Update request. o The local mobility anchor MUST apply the required policy checks, as explained in Section 4.0, to verify the sender is a trusted mobile access gateway, authorized to send proxy binding registration requests on behalf of this mobile node Section 5.3: Binding De-registration ==================================== "the local mobility anchor MAY either choose to ignore the request or send a valid Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update Accepted" as opposed to doing what else? I think this whole point is redundant. Recommend one of these options or remove the whole paragraph. Section 5.5.2 : Forwarding considerations ========================================= Point 1 (Intercepting packets ...) This point explains plain IP routing. I am not sure what it has to do with PMIP. Is there any reason this point needs to be explicitly mentioned? Section 6.8 =========== The last paragraph states " This issue is not relevant to the mobile node's global address. Since, there is a unique home network prefix for each mobile node, the uniqueness for the mobile node's global address is assured on the access link" By turning on the DNASameLinkDADFlag the MN will do DAD on the global address as well. The flag is not exclusive to LL addresses.I think this should be clarified. Section 6.10.4 ============== The config variable EnableMAGLocalRouting is not mentioned here. Can you add it here as it is very relevant here. Section 8.1 =========== Add references to HMIP and nemo for the M and R flags as they are not defined in RFC3775 as implied by the text. Editorial ========= Section 2.2 =========== LMA: "It is the topological anchor point for the mobile node's home network prefix and is the entity that manages the mobile node's reachability state." I am not sure what the phrase "manages the MN's reachability state" means. Can you please clarify or remove this phrase. Section 3 ========= paragraph 3 line 2 Replace "The local mobility is" with "The local mobility anchor is" Section 5.5.1 ============= There is redundant text regarding shared tunnels between MNs. point 3: "The created tunnel may be shared with other mobile nodes attached to the same mobile access gateway and with the local mobility anchor having a Binding Cache entry for those mobile nodes." point 4: "The tunnel between the local mobility anchor and the mobile access gateway is typically a shared tunnel and can be used for routing traffic streams for different mobile nodes attached to the same mobile access gateway." I think point 4 can safely be removed Section 6.9.1 ============= Binding Re-Registration: "the value in the Link-local Address option may be set to ALL_ZERO or to the link-local address of the mobile node." This has to be a normative MAY. Section 6.9.2 ============= Router Solicitations: "However, it MAY choose to advertise a local visitor network prefix to enable the mobile node for simple IPv6 access." Replace "visitor" with "visited" References ========== Please update references for all the bis RFCs 2461,2462,3041 etc. so that the RFC editor will replace them with the latest RFCs (4861,4862,4941...) _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 20:13:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZy3L-0002gq-Ja; Mon, 24 Sep 2007 20:13:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZy3K-0002bl-4L for netlmm@ietf.org; Mon, 24 Sep 2007 20:13:26 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZy3J-0004WQ-D1 for netlmm@ietf.org; Mon, 24 Sep 2007 20:13:25 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 17:13:24 -0700 Message-ID: <46F852A3.1040401@azairenet.com> Date: Mon, 24 Sep 2007 17:13:23 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan Subject: Re: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 References: <46F848E2.40904@ericsson.com> In-Reply-To: <46F848E2.40904@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2007 00:13:24.0494 (UTC) FILETIME=[E37F4AE0:01C7FF08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Suresh, A few random replies. Assume Sri will respond in detail :) Suresh Krishnan wrote: > Link Local address of MAG > ========================= > When an MN moves from one link to another how does it switch default > routers to the new MAG. The link local addresses of the old MAG and the > new MAG will most likely be different and hence unless nud removes the > old mag the mn will try to reach it even after handover. Or it is > assumed that all the MAGs will have the same LL address? Is this is an > assumption, it needs to be stated. It is assumed that the same link local address is used for a particular mobile node across all MAGs. This is stored at the LMA and retrieved by the new MAG. This is described in the document. > Section 4 > ========= > "IKEv2 [RFC-4306] SHOULD be used to setup security associations > between the mobile access gateway and the local mobility anchor to > protect the Proxy Binding Update and Proxy Binding Acknowledgement > messages." > > This is a significant departure from RFC3775 where this was a MAY. What > is the reasoning behind making this a SHOULD? I believe manual config > should be a MUST and automatic key mgmt should be a MAY. At the time RFC 3775 was written, IKEv1 was on the "way out". Currently IKEv2 seems to be the default for setting up IPsec security associations. > P flag > ====== > > I do not see any text in the expected LMA behavior to CHECK for the > presence of the P flag in the received BU. I think this should be added. hmmm.... the LMA uses the 'P' flag to recognize that it is a proxy binding update from a MAG. Otherwise the LMA assumes it is a MIPv6 binding update from a MIPv6 mobile node. So the LMA checks for the 'P' flag all the time. > Section 5.3: Binding De-registration > ==================================== > "Upon accepting the Proxy Binding Update request for a mobile node, > with the lifetime value of zero, the local mobility anchor MUST > wait for MinDelayBeforeBCEDelete amount of time, before it deletes > the mobile node's Binding Cache entry." > > What is the purpose for having a timer to delete a BCE? I see no reason > at all in waiting. If this is being done to prevent considering a > following BU as an initial registration ( I suspect this is the case) > please extend the conceptual data structure to add a deleted flag > instead of using a timer. This is to make sure you don't release the home address/home network prefix as soon as a MAG de-registers. The proxy binding update from the new MAG may have been delayed. > Section 6.9.3 > ============= > " o If Timestamp based scheme is in use, the retransmitted Proxy > Binding Update messages MUST use the latest timestamp. If > Sequence number scheme is in use, the retransmitted Proxy Binding > Update messages MUST use a Sequence Number value greater than that > used for the previous transmission of this Proxy Binding Update > message, just as specified in [RFC-3775]." > > I completely disagree with this. I think if a PBU is retransmitted it > MUST use the same timestamp as the first time around. Otherwise we will > run into ordering problems. No. It should always use the latest timestamp value. Otherwise the LMA would not be able to distinguish between a lost Proxy BU being re-transmitted from a replayed proxy BU. > IANA Considerations > =================== > > Don't forget to request the assignment of the P bit in the BU and BA > messages in the IANA considerations section. The binding update flags are not maintained by the IANA. The respective documents define the flags and their positions. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 20:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZyAl-0005LA-45; Mon, 24 Sep 2007 20:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZyAj-0005Kt-07 for netlmm@ietf.org; Mon, 24 Sep 2007 20:21:05 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZyAe-0002iy-3y for netlmm@ietf.org; Mon, 24 Sep 2007 20:21:04 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 17:20:59 -0700 Message-ID: <46F8546A.7070605@azairenet.com> Date: Mon, 24 Sep 2007 17:20:58 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [netlmm] Review of Proxy Mobile IPv6 (draft-ietf-netlmm-proxymip6-05.txt) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2007 00:20:59.0188 (UTC) FILETIME=[F2841740:01C7FF09] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Pete, McCann Peter-A001034 wrote: > 5.1 Extensions to Binding Cache Entry Data Structure > > o A flag indicating whether or not this Binding Cache entry is > created due to a proxy registration. This flag is enabled for > Binding Cache entries that are proxy registrations and is turned > off for all other entries that are created due to the > registrations directly sent by the mobile node. > > This point seems to be related to the interaction of proxy MIP and > client MIP using the same home agent. I think it would be best to > leave this sort of detail to a separate document describing such > interaction. There are many issues that must be dealt with in that > case, such as how to put BUs in the right order. The 'P' flag is essential since we are re-using much of the Mobile IPv6 home agent functionality for the description of the LMA functionality. The LMA needs to be able to distinguish that it is a proxy binding update. And the 'P' flag is the only way to do this. > 5.5.2. Forwarding Considerations > > o When the local mobility anchor is serving a mobile node, it MUST > be able to receive packets that are sent to the mobile node's home > network. In order for it to receive those packets, it MUST > advertise a connected route in to the Routing Infrastructure for > the mobile node's home network prefix or for an aggregated prefix > with a larger scope. This essentially enables IPv6 routers in > that network to detect the local mobility anchor as the last-hop > router for that prefix. > This is a change from the behavior in RFC 3775 that allowed for > proxy ND. Will this create issues when co-locating an LMA with an HA? In RFC 3963 (NEMO) we already extended the home agent functionality to advertise reachability to a aggregated network prefix in addition to the home address of the mobile router. This would be similar to that functionality. I don't see any issues when co-locating an LMA with a HA. > 11. Security Considerations > > To eliminate the threats on the interface between the mobile access > gateway and the mobile node, this specification requires an > established trust between the mobile access gateway and the mobile > node and to authenticate and authorize the mobile node before it is > allowed to access the network. > I think you should talk here not only about trust but also about > a secure binding between the MN-Identifier and the traffic arriving > at the MAG. This means that whatever scheme is used to authenticate > the MN must provide keys that will be used to protect traffic, indexed > by the MAC Address or MN-Identifier as appropriate. This should be link-specific. More ever it would be better to capture this in the MN-AR interface document. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 23:50:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1Qx-0007sk-3F; Mon, 24 Sep 2007 23:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1Qv-0007sV-I0 for netlmm@ietf.org; Mon, 24 Sep 2007 23:50:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia1Qu-0007U2-8e for netlmm@ietf.org; Mon, 24 Sep 2007 23:50:01 -0400 X-IronPort-AV: E=Sophos;i="4.20,293,1186383600"; d="scan'208";a="177469633" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 24 Sep 2007 20:49:59 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8P3nxQq006794; Mon, 24 Sep 2007 20:49:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8P3nx0c018204; Tue, 25 Sep 2007 03:49:59 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 20:49:59 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 20:49:58 -0700 From: "Sri Gundavelli" To: "'Kilian Weniger'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> <003f01c7fe81$555e2ce0$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8BA3@lan-ex-02.panasonic.de> Date: Mon, 24 Sep 2007 20:49:58 -0700 Message-ID: <001a01c7ff27$24e73c90$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf8Mf/s6Vq1PtL7TIOvDsZjpXW1+QBxWpjQACLttvAAKE//4A== In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8BA3@lan-ex-02.panasonic.de> X-OriginalArrivalTime: 25 Sep 2007 03:49:59.0185 (UTC) FILETIME=[24EFC810:01C7FF27] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3808; t=1190692199; x=1191556199; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20More=20comments=20on=20draft-ietf-netlmm-proxymip6-05 .txt |Sender:=20; bh=iJI2Y1GgaFCv7vnbGFt2rhnheBCYLoFVv94YwBR0jio=; b=uS6CGq5FZX4dcdIGKYUq+43N9NoAd2O4BCRHXCkfFOwjdtcY5OaD0uFDSEIZscuoBrKyvJyS A6DqJHD5SWi6/FZ01xn7MiWdYLbItpPgoUSBHqe8FaiNfL2QhVXlKJnSX9bIS+Qx6m92Yc2IUg ERyWPLPclTBQN8DtFCUrzkcGo=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: netlmm@ietf.org Subject: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Please see inline. Thanks Sri > > > > Ok. I can increase the def value. Its a configurable parameter and > > upto the deployment. Typically, the address manager component should > > always attempt to give the same prefix to the same mobile node. The > > prefix recycling should happen only when there are no prefixes to > > allocate. This is generally a design goal of any address manager > > Even if the address manager component gives the same prefix to the MN > when a new BCE is created, there would be no BCE and hence packet loss > until the next PBU arrives at the LMA. > > The point is: what's the benefit of a small value for > MinDelayBeforeBCEDelete, except for marginally reducing the memory > consumption on the LMA? Is this worth the risk of significant packet > loss due to erroneously deleted BCE? > Ok. I will change the default value. > > My comment still applies in draft-06, since the first paragraph still > says "In order for it to be considered valid,... the timestamp MUST be > greater than all previously accepted timestamps." So a > TIMESTAMP_MISMATCH may be returned even if the clocks are in sync. > > Assuming MAG1 and MAG2 are in sync. MAG1 sends PBU1 at time > t1 and MAG2 > sends PBU2 at time t2 with t2>t1. If now PBU2 overtakes PBU1, > i.e., PBU1 > arrives at LMA after PBU2, the LMA would send a PBA with > TIMESTAMP_MISMATCH, even though MAG1 and MAG2 are in sync. > > I assumed so far that a TIMESTAMP_MISMATCH code shall tell > the MAG that > its clock is out of sync for diagnostics purposes and potentially for > triggering the necessary actions to synchronize clocks again (e.g., > using NTP). This is not really the case with the above text. > > Maybe it is better to have two different status codes: > 1. if the timestamp is not close enough to the local mobility anchor's > time-of-day clock > 2. if the timestamp is lower than previously accepted timestamps > Only in the first case, the MAG should trigger necessary actions to > synchronize clocks... > > > I see your point, I missed this case. We will discuss this offline and I will update the text to cover this case. > - The interface is initialized at system startup time. > > - The interface is reinitialized after a temporary interface > failure or after being temporarily disabled by system > management. > > - The system changes from being a router to being a host, by > having its IP forwarding capability turned off by system > management. > > - The host attaches to a link for the first time. > > - The host re-attaches to a link after being detached for some > time." > Ok. I will update the text on this. > > > > > - section 5.3 seems to be a bit underspecified: What should > > > LMA do if it > > > receives binding de-registration or re-registration with > > prefix 0::0? > > > What should LMA do with incoming data packets after valid > > > de-registration was received, but BCE still exists due to > > > MinDelayBeforeBCEDelete? > > > > > Its not fixed in -06. I will cover this case and also on the routing considerations during the MinDelayBeforeBCEDelete timer. > If the host-based mobility protocol is MIPv6, then this is exactly > scenario B in draft-giaretta-netlmm-mip-interactions-01. So > why not add > an informative reference? There is also a reference to the IPv4-PMIP > extension draft draft-ietf-netlmm-pmip6-ipv4-support-01.txt... > :) My point is that its a simple IP case and nothing specific to CMIP-PMIP interaction. I can add a reference to the doc, hopefully the draft will be a WG doc before the LC is complete for this doc. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 23:50:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1RG-0008Fy-6x; Mon, 24 Sep 2007 23:50:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1RE-0008FI-QV for netlmm@ietf.org; Mon, 24 Sep 2007 23:50:20 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia1RE-0001EX-6J for netlmm@ietf.org; Mon, 24 Sep 2007 23:50:20 -0400 X-IronPort-AV: E=Sophos;i="4.20,293,1186383600"; d="scan'208";a="527651563" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2007 20:50:20 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8P3oJgM001730; Mon, 24 Sep 2007 20:50:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8P3oJ0c018327; Tue, 25 Sep 2007 03:50:19 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 20:50:19 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 20:50:19 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" References: <004b01c7fe84$70839c00$d5f6200a@amer.cisco.com> <46F7A2A4.7010602@gmail.com> Subject: RE: FW: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-06.txt Date: Mon, 24 Sep 2007 20:50:18 -0700 Message-ID: <001b01c7ff27$30d373c0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf+n//oc1jNpQ1xT0CTQiRzjzeZ8QAgbmuA In-Reply-To: <46F7A2A4.7010602@gmail.com> X-OriginalArrivalTime: 25 Sep 2007 03:50:19.0154 (UTC) FILETIME=[30D6CF20:01C7FF27] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1987; t=1190692219; x=1191556219; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20FW=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-p roxymip6-06.txt |Sender:=20; bh=/1gELKRxHEbVECsoHD8N2RhDCejxfuc1f3ibyJCjGOo=; b=g8CPjOeSlp94z+bTo+srSb4ydokp+d3WpAAEmruk1QBjR22ImcaS6gwFnCLkVxi6LQuBd7B8 1/rP9GhqiEbTs4AizctN0LuyhK2Cb/mAMgLhBwJ4XeVN4FDhpas7vJw6; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, > > 6.11. Supporting DHCPv6 based Address Configuration on the Access > > Link > > > > This non-normative section explains how Stateful Address > > Configuration using DHCPv6 can be enabled on the access > link attached > > to a mobile access gateway and how a mobile node attached to that > > link can obtain an address from its home network prefix > using DHCPv6. > > Basically I agree that the DHCP behaviour described in this section is > non-normative (==informative?). Would it be better placed as > an Appendix? > This text provides the basic guidance on how to enable DHCP based addressing. This guidance is important for deployments. I should rephrase this slightly to explicitly state the spec does not mandate on having DHCP relay on the MAG. Its an optional configuration. That was the intent, I should remove this line on non-normative part. > > If the received Router Advertisement has the Managed Address > > Configuration flag set, the mobile node, as it would normally do, > > will send a DHCPv6 Request [RFC-3315]. > > I think it will first send a Solicit, to discover DHCP > Server's address. > 'Request' would come after the 'Advertise' the Server sends. > > Moreover, if/when we're to discuss DHCP behaviour we risk important > disagreements on how it should work. (1) how prefix delegation is > integrated, (2) how PMIP6 handover influences DHCP exchanges, (3) how > and what the MAG DHCP Relay inserts in the client messages, > (4) how the > server identifies the client. Prefix assignment is done by the LMA and it can use DHCP PD for that. The draft does not cover the details on how the LMA does the prefix allocation. > 1/64000 fractions of a second? Or 1/65536 fractions of a second. I > propose to specifically say 1/65536 fractions because 64k means 65536 > only if we talk bits (not seconds), in my understanding. > Ok. Will fix it. Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 23:50:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1Qx-0007sk-3F; Mon, 24 Sep 2007 23:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1Qv-0007sV-I0 for netlmm@ietf.org; Mon, 24 Sep 2007 23:50:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia1Qu-0007U2-8e for netlmm@ietf.org; Mon, 24 Sep 2007 23:50:01 -0400 X-IronPort-AV: E=Sophos;i="4.20,293,1186383600"; d="scan'208";a="177469633" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 24 Sep 2007 20:49:59 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8P3nxQq006794; Mon, 24 Sep 2007 20:49:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8P3nx0c018204; Tue, 25 Sep 2007 03:49:59 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 20:49:59 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 20:49:58 -0700 From: "Sri Gundavelli" To: "'Kilian Weniger'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8AFC@lan-ex-02.panasonic.de> <003f01c7fe81$555e2ce0$d5f6200a@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8BA3@lan-ex-02.panasonic.de> Date: Mon, 24 Sep 2007 20:49:58 -0700 Message-ID: <001a01c7ff27$24e73c90$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf8Mf/s6Vq1PtL7TIOvDsZjpXW1+QBxWpjQACLttvAAKE//4A== In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8BA3@lan-ex-02.panasonic.de> X-OriginalArrivalTime: 25 Sep 2007 03:49:59.0185 (UTC) FILETIME=[24EFC810:01C7FF27] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3808; t=1190692199; x=1191556199; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20More=20comments=20on=20draft-ietf-netlmm-proxymip6-05 .txt |Sender:=20; bh=iJI2Y1GgaFCv7vnbGFt2rhnheBCYLoFVv94YwBR0jio=; b=uS6CGq5FZX4dcdIGKYUq+43N9NoAd2O4BCRHXCkfFOwjdtcY5OaD0uFDSEIZscuoBrKyvJyS A6DqJHD5SWi6/FZ01xn7MiWdYLbItpPgoUSBHqe8FaiNfL2QhVXlKJnSX9bIS+Qx6m92Yc2IUg ERyWPLPclTBQN8DtFCUrzkcGo=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: netlmm@ietf.org Subject: [netlmm] RE: More comments on draft-ietf-netlmm-proxymip6-05.txt X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Please see inline. Thanks Sri > > > > Ok. I can increase the def value. Its a configurable parameter and > > upto the deployment. Typically, the address manager component should > > always attempt to give the same prefix to the same mobile node. The > > prefix recycling should happen only when there are no prefixes to > > allocate. This is generally a design goal of any address manager > > Even if the address manager component gives the same prefix to the MN > when a new BCE is created, there would be no BCE and hence packet loss > until the next PBU arrives at the LMA. > > The point is: what's the benefit of a small value for > MinDelayBeforeBCEDelete, except for marginally reducing the memory > consumption on the LMA? Is this worth the risk of significant packet > loss due to erroneously deleted BCE? > Ok. I will change the default value. > > My comment still applies in draft-06, since the first paragraph still > says "In order for it to be considered valid,... the timestamp MUST be > greater than all previously accepted timestamps." So a > TIMESTAMP_MISMATCH may be returned even if the clocks are in sync. > > Assuming MAG1 and MAG2 are in sync. MAG1 sends PBU1 at time > t1 and MAG2 > sends PBU2 at time t2 with t2>t1. If now PBU2 overtakes PBU1, > i.e., PBU1 > arrives at LMA after PBU2, the LMA would send a PBA with > TIMESTAMP_MISMATCH, even though MAG1 and MAG2 are in sync. > > I assumed so far that a TIMESTAMP_MISMATCH code shall tell > the MAG that > its clock is out of sync for diagnostics purposes and potentially for > triggering the necessary actions to synchronize clocks again (e.g., > using NTP). This is not really the case with the above text. > > Maybe it is better to have two different status codes: > 1. if the timestamp is not close enough to the local mobility anchor's > time-of-day clock > 2. if the timestamp is lower than previously accepted timestamps > Only in the first case, the MAG should trigger necessary actions to > synchronize clocks... > > > I see your point, I missed this case. We will discuss this offline and I will update the text to cover this case. > - The interface is initialized at system startup time. > > - The interface is reinitialized after a temporary interface > failure or after being temporarily disabled by system > management. > > - The system changes from being a router to being a host, by > having its IP forwarding capability turned off by system > management. > > - The host attaches to a link for the first time. > > - The host re-attaches to a link after being detached for some > time." > Ok. I will update the text on this. > > > > > - section 5.3 seems to be a bit underspecified: What should > > > LMA do if it > > > receives binding de-registration or re-registration with > > prefix 0::0? > > > What should LMA do with incoming data packets after valid > > > de-registration was received, but BCE still exists due to > > > MinDelayBeforeBCEDelete? > > > > > Its not fixed in -06. I will cover this case and also on the routing considerations during the MinDelayBeforeBCEDelete timer. > If the host-based mobility protocol is MIPv6, then this is exactly > scenario B in draft-giaretta-netlmm-mip-interactions-01. So > why not add > an informative reference? There is also a reference to the IPv4-PMIP > extension draft draft-ietf-netlmm-pmip6-ipv4-support-01.txt... > :) My point is that its a simple IP case and nothing specific to CMIP-PMIP interaction. I can add a reference to the doc, hopefully the draft will be a WG doc before the LC is complete for this doc. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Mon Sep 24 23:50:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1RG-0008Fy-6x; Mon, 24 Sep 2007 23:50:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia1RE-0008FI-QV for netlmm@ietf.org; Mon, 24 Sep 2007 23:50:20 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia1RE-0001EX-6J for netlmm@ietf.org; Mon, 24 Sep 2007 23:50:20 -0400 X-IronPort-AV: E=Sophos;i="4.20,293,1186383600"; d="scan'208";a="527651563" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2007 20:50:20 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8P3oJgM001730; Mon, 24 Sep 2007 20:50:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8P3oJ0c018327; Tue, 25 Sep 2007 03:50:19 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 20:50:19 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 20:50:19 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" References: <004b01c7fe84$70839c00$d5f6200a@amer.cisco.com> <46F7A2A4.7010602@gmail.com> Subject: RE: FW: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-06.txt Date: Mon, 24 Sep 2007 20:50:18 -0700 Message-ID: <001b01c7ff27$30d373c0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf+n//oc1jNpQ1xT0CTQiRzjzeZ8QAgbmuA In-Reply-To: <46F7A2A4.7010602@gmail.com> X-OriginalArrivalTime: 25 Sep 2007 03:50:19.0154 (UTC) FILETIME=[30D6CF20:01C7FF27] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1987; t=1190692219; x=1191556219; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20FW=3A=20[netlmm]=20I-D=20Action=3Adraft-ietf-netlmm-p roxymip6-06.txt |Sender:=20; bh=/1gELKRxHEbVECsoHD8N2RhDCejxfuc1f3ibyJCjGOo=; b=g8CPjOeSlp94z+bTo+srSb4ydokp+d3WpAAEmruk1QBjR22ImcaS6gwFnCLkVxi6LQuBd7B8 1/rP9GhqiEbTs4AizctN0LuyhK2Cb/mAMgLhBwJ4XeVN4FDhpas7vJw6; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, > > 6.11. Supporting DHCPv6 based Address Configuration on the Access > > Link > > > > This non-normative section explains how Stateful Address > > Configuration using DHCPv6 can be enabled on the access > link attached > > to a mobile access gateway and how a mobile node attached to that > > link can obtain an address from its home network prefix > using DHCPv6. > > Basically I agree that the DHCP behaviour described in this section is > non-normative (==informative?). Would it be better placed as > an Appendix? > This text provides the basic guidance on how to enable DHCP based addressing. This guidance is important for deployments. I should rephrase this slightly to explicitly state the spec does not mandate on having DHCP relay on the MAG. Its an optional configuration. That was the intent, I should remove this line on non-normative part. > > If the received Router Advertisement has the Managed Address > > Configuration flag set, the mobile node, as it would normally do, > > will send a DHCPv6 Request [RFC-3315]. > > I think it will first send a Solicit, to discover DHCP > Server's address. > 'Request' would come after the 'Advertise' the Server sends. > > Moreover, if/when we're to discuss DHCP behaviour we risk important > disagreements on how it should work. (1) how prefix delegation is > integrated, (2) how PMIP6 handover influences DHCP exchanges, (3) how > and what the MAG DHCP Relay inserts in the client messages, > (4) how the > server identifies the client. Prefix assignment is done by the LMA and it can use DHCP PD for that. The draft does not cover the details on how the LMA does the prefix allocation. > 1/64000 fractions of a second? Or 1/65536 fractions of a second. I > propose to specifically say 1/65536 fractions because 64k means 65536 > only if we talk bits (not seconds), in my understanding. > Ok. Will fix it. Thanks Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 01:01:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia2Y0-0002VF-2I; Tue, 25 Sep 2007 01:01:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia2Xy-0002PX-St for netlmm@ietf.org; Tue, 25 Sep 2007 01:01:22 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia2Xx-0002Ni-Ep for netlmm@ietf.org; Tue, 25 Sep 2007 01:01:22 -0400 X-IronPort-AV: E=Sophos;i="4.20,293,1186383600"; d="scan'208";a="527664744" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 24 Sep 2007 22:01:16 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8P51K3P002181; Mon, 24 Sep 2007 22:01:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8P51KX1021518; Tue, 25 Sep 2007 05:01:20 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 22:01:20 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 22:01:19 -0700 From: "Sri Gundavelli" To: "'Suresh Krishnan'" , References: <46F848E2.40904@ericsson.com> Subject: RE: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 Date: Mon, 24 Sep 2007 22:01:20 -0700 Message-ID: <001f01c7ff31$1cf18860$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf/BCnT0bzCpjofRySh0sxraTn6xAAIxCcQ In-Reply-To: <46F848E2.40904@ericsson.com> X-OriginalArrivalTime: 25 Sep 2007 05:01:20.0127 (UTC) FILETIME=[1C93B0F0:01C7FF31] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12025; t=1190696480; x=1191560480; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Suresh's=20review=20of=20draft-ietf-netlmm -proxymip6-05 |Sender:=20; bh=rHKKAPwsdGWyjxdy3mTbgi2M+0UFGr88xlOD7ClhlJs=; b=BhVf2GDblRmFkMl801VTaM+K325h/P0wQPyA5COFRVxuVH62diRnp0OCSWHK56+f+qqDQB2v HZlxiOV4DW2/neBx5WzUTAG5j0c8b89KWb7btPYian6q8E6eRlhuWWl2; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Suresh, Thanks for the review. Please see inline. Sri > > Link Local address of MAG > ========================= > When an MN moves from one link to another how does it switch default > routers to the new MAG. The link local addresses of the old > MAG and the > new MAG will most likely be different and hence unless nud removes the > old mag the mn will try to reach it even after handover. Or it is > assumed that all the MAGs will have the same LL address? Is this is an > assumption, it needs to be stated. > The MN section has the text on this. The DR needs to be timeout or in links where SEND is not deployed, a fixed linkeed-local address can be configured on all MAG interfaces. One or more ways to deal with it. MAG can also withdraw the prev AR. > Timestamp synchronization > ========================= > I read through the timestamp approach for synchronization and it is > unclear why the MAG and the LMA need to sync their clocks. I > think it is > sufficient for MAGs to sync between themselves. Why does the > LMA need to > check if the MAGs timestamp is different from its timestamp? > This is for convering the case, where the MN boots on a bad MAG where the time is like 5 hours ahead. If LMA does not do the basic sanity check and accepts the PBU, all subsequent PBU's from the other MAG's where the MN moves to will have older TS. We have discussed this thread to death. No worries on this logic. > LMA Address acquisition > ======================= > Why is the LMA address a mandatory part of the MN profile? > And why is it > the ONLY allowed method for acquiring an LMA address? Can't > the MAG use > some other method to acquire the LMA address (static config, > DNS...). I > think this is overly restrictive. > Hmm ... I can move the LMAA to the optional section. Fine, if we think there are other methods of LMA discovery. > > Section 4 > ========= > "IKEv2 [RFC-4306] SHOULD be used to setup security associations > between the mobile access gateway and the local mobility anchor to > protect the Proxy Binding Update and Proxy Binding Acknowledgement > messages." > > This is a significant departure from RFC3775 where this was a > MAY. What > is the reasoning behind making this a SHOULD? I believe manual config > should be a MUST and automatic key mgmt should be a MAY. > The thought was that the SA is protecting multiple MN flows and its important that the SA's are setup dynamically using IKEv2 and with the proper rekeying properties. Also, as Vijay says, when 3775 came out not many mobile stacks have IPsec support and that could be the reason for not mandating IKE. > P flag > ====== > > I do not see any text in the expected LMA behavior to CHECK for the > presence of the P flag in the received BU. I think this > should be added. > The message with the "P" flag is the PBU. The whole signaling logic is tied to this message. > Section 5.3: Binding De-registration > ==================================== > "Upon accepting the Proxy Binding Update request for a mobile node, > with the lifetime value of zero, the local mobility anchor MUST > wait for MinDelayBeforeBCEDelete amount of time, before it deletes > the mobile node's Binding Cache entry." > > What is the purpose for having a timer to delete a BCE? I see > no reason > at all in waiting. If this is being done to prevent considering a > following BU as an initial registration ( I suspect this is the case) > please extend the conceptual data structure to add a deleted flag > instead of using a timer. For covering the make-before-break case. It cant be just a flag, its a time sensitive operation. > > The following step directly contradicts this step as well. Make sure > that they are consistent. > > Section 5.3: PBA formation > ========================== > " If the Status field is set to a value greater less than 128, i.e. > if the binding request was rejected, then the prefix value in the > Home Network Prefix option MUST be set to the prefix value from > the received Home Network Prefix option." > > This does not cover the case where the PBU did not contain a > HNP option > (rejection with error 129). So the text needs to be extended > in order to > clarify the behavior in such case. I would suggest the following text > > " If the Status field is set to a value greater less than 128, i.e. > if the binding request was rejected, then the prefix value in the > Home Network Prefix option MUST be set to the prefix value from > the received Home Network Prefix option. If the received PBU did > not contain a Home Network Prefix option, then the HNP option MUST > NOT be included. " > > This also implies that the HNP field becomes optional in the PBA. Ok. This is a good point. The idea of rejecting a message because it does not have a specific option, conflicts with the mandatory option requirement. I think, the LMA should simply ignore a message if a specific required option is not present. I will fix it. > > Section 6.8 > =========== > I am not sure how the odds of collision are arrived at. If there is a > reference please put it in here. However I look at it, the number does > not look too good to me. Anyway, this feels totally out of > place in the > PMIP spec. Thus, as an alternative, you can remove the whole text > without losing anything. > Ok. I rephrased it. > Section 6.9.1 > ============= > "o If the received Proxy Binding Acknowledgement message has the > Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX > (Not authorized for that prefix), the mobile access > gateway SHOULD > try to request for that prefix in the binding registration > request, only after it learned the validity of that prefix." > > I am not sure why the MAG SHOULD try again. If this error > case occurs, I > think that the MAG SHOULD do one of the following > > 1) Deny mobility service to the MN > 2) Send a PBU with the null hnp to request a new prefix allocation > It can be upto the implementation. We are just saying, the MAG should not keep trying and trying requesting the same prefix, while the LMA keeps rejecting the request. > Section 6.9.3 > ============= > " o If Timestamp based scheme is in use, the retransmitted Proxy > Binding Update messages MUST use the latest timestamp. If > Sequence number scheme is in use, the retransmitted > Proxy Binding > Update messages MUST use a Sequence Number value > greater than that > used for the previous transmission of this Proxy Binding Update > message, just as specified in [RFC-3775]." > > I completely disagree with this. I think if a PBU is retransmitted it > MUST use the same timestamp as the first time around. > Otherwise we will > run into ordering problems. > I dont think it will create any ordering problems. The message is generated at a different time. If it uses old timestamp, it breaks the LMA sanity check rule. > Section 6.11 > ============ > > I am not sure how the MAG can send the HNP of the MN in the > link-address > field of the DHCP relay message since the link-address field does not > contain a prefix length. Is there an implicit assumption that > the prefix > will be 64 bits in length? > This is per 3315. I will look into the format. > IANA Considerations > =================== > > Don't forget to request the assignment of the P bit in the BU and BA > messages in the IANA considerations section. > As Vijay pointed out, IANA does not manage this part. > Minor > ===== > > Section 3 > ========= > > Figure 3: The detach flow is not explained at all. If the detach flow > needs to stay in the figure, it needs to be elaborated in the > following > text. It is probably not relevant in this figure either, since the BCE > gets replaced by the new PBU anyway. > Ok > Section 5.3 > =========== > > The following two bullets refer to section 4.0 that does not > exist. Can > you insert the reference to the right section here. (I am > assuming it is > section 4 but I am not sure) > > It points to the PMIP6 security model, described in Sec 4. > > Section 5.3: Binding De-registration > ==================================== > "the local mobility anchor MAY either choose to ignore > the request or send a valid Proxy Binding Acknowledgement message > with the Status field set to 0 (Proxy Binding Update Accepted" > > as opposed to doing what else? I think this whole point is redundant. > Recommend one of these options or remove the whole paragraph. > Ignore the request or Send the reply Will rephrase it. > Section 5.5.2 : Forwarding considerations > ========================================= > > Point 1 (Intercepting packets ...) > > This point explains plain IP routing. I am not sure what it has to do > with PMIP. Is there any reason this point needs to be > explicitly mentioned? > Well, some basic guidance. Not every one is an expert in forwarding :) > Section 6.8 > =========== > The last paragraph states > " This issue is not relevant to the mobile node's global address. > Since, there is a unique home network prefix for each mobile node, > the uniqueness for the mobile node's global address is > assured on the > access link" > > By turning on the DNASameLinkDADFlag the MN will do DAD on the global > address as well. The flag is not exclusive to LL addresses.I > think this > should be clarified. > Ok > Section 6.10.4 > ============== > > The config variable EnableMAGLocalRouting is not mentioned > here. Can you > add it here as it is very relevant here. > Ok > Section 8.1 > =========== > > Add references to HMIP and nemo for the M and R flags as they are not > defined in RFC3775 as implied by the text. > ok > > Editorial > ========= > > Section 2.2 > =========== > LMA: > "It is the topological anchor point for > the mobile node's home network prefix and is the entity that > manages the mobile node's reachability state." > > I am not sure what the phrase "manages the MN's reachability state" > means. Can you please clarify or remove this phrase. > ok > > Section 3 > ========= > paragraph 3 line 2 > > Replace "The local mobility is" with "The local mobility anchor is" > fixed > Section 5.5.1 > ============= > There is redundant text regarding shared tunnels between MNs. > > point 3: "The created tunnel may be shared > with other mobile nodes attached to the same mobile > access gateway > and with the local mobility anchor having a Binding Cache entry > for those mobile nodes." > > point 4: "The tunnel between the local mobility anchor and > the mobile access > gateway is typically a shared tunnel and can be used > for routing > traffic streams for different mobile nodes attached to the same > mobile access gateway." > > I think point 4 can safely be removed > ok > Section 6.9.1 > ============= > Binding Re-Registration: > "the value in the Link-local Address option may be set to ALL_ZERO > or to the link-local address of the mobile node." > > This has to be a normative MAY. > ok > Section 6.9.2 > ============= > Router Solicitations: > "However, it MAY choose to advertise a local visitor > network prefix to enable the mobile node for simple IPv6 access." > > Replace "visitor" with "visited" > ok > References > ========== > > Please update references for all the bis RFCs 2461,2462,3041 etc. so > that the RFC editor will replace them with the latest RFCs > (4861,4862,4941...) > > ok Thanks for the review. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 04:42:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia600-00074R-JP; Tue, 25 Sep 2007 04:42:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia5zz-000716-M7 for netlmm@ietf.org; Tue, 25 Sep 2007 04:42:31 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia5zy-0008N2-0u for netlmm@ietf.org; Tue, 25 Sep 2007 04:42:31 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8P8gS63012143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Sep 2007 01:42:29 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8P8g70P005177 for ; Tue, 25 Sep 2007 01:42:28 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 01:42:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Sep 2007 01:42:07 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/T/RrZEqQFEePT3u9QfI2QIenQA== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 25 Sep 2007 08:42:08.0432 (UTC) FILETIME=[F52E9B00:01C7FF4F] X-Spam-Score: -4.0 (----) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Subject: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org All, The following is a review of version 05 of the base draft. Please let me know if any of this has been addressed in 06 and I'll take a look. Also, if some of these are duplicates from other reviws, please feel free to point me to a response you have provided earlier on this. I tried filtering out some of the duplicate comments, but, it is likely that there are some.=20 There are a number of comments below. I've tried categorizing the comments into "Technical - Major" (for those that are definitely going to need some discussion), "Technical - Minor" (for those that may need some discussion, but, aren't generally show-stoppers) and "Editorial" (don't need discussion). Hope that helps to some extent.=20 Thanks, Vidya Technical - Major:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Terminology: Proxy-CoA and MN-HoA:=20 As I've mentioned before, this terminology continues to be confusing, especially, when we talk about PMIP6 and MIP6 together. Given that an MN is called an MN in the MIP6 case, tagging "MN" before the HoA is not making it any more descriptive to the PMIP6 use. I've stated my concerns with these terms before and I know the authors had a strong preference to keeping this terminology, but, I'd strongly urge some re-thinking here to avoid confusion to the end users of the protocol. =20 - MN Identifier:=20 Page 15 (and other parts of the document) talks about getting the MN ID from the NAI option. Isn't NAI just one allowed type of identity? A particular deployment may use other types of identities, the only requirement being a unique identity that can be stable within the PMIP domain. =20 - Unauthorized PBUs:=20 What is the purpose of sending an error code in a PBA for an unauthorized PBU? I would imagine that unauthorized PBUs are better silently discarded.=20 - Prefix allocation and multihomed MNs:=20 The first bullet on page 18 states that the LMA "MUST ensure the allocated prefix is not in use by any other mobile node". In the context of regular IP nodes that are multihomed, we discussed how it is problematic when the same prefix/address is allocated to multiple interfaces of the same node. To prevent that problem, are we assuming that every distinct interface of an MN attached to the PMIP domain has a different unique identity? If so, that needs to be stated. IMO, that may not be practical, especially, if an NAI is used as the MN ID. So, in those cases, we really need to ensure that the LMA is not allocating the same prefix to multiple interfaces of a multihomed MN. I think an appropriate rewording of this sentence may be something like "the LMA MUST ensure the allocated prefix is not already in use, i.e., there is no existing BCE for that prefix on the LMA".=20 I also recall that the document is supposed to state that the protocol does not support multihomed MNs more generically, but, I couldn't find such text. Did I miss it?=20 - Page 18, Binding De-registration:=20 If the LMA may accept or ignore a PBU sent with a source address different from the Proxy-CoA, what is that test needed for? Are there any examples of cases where the LMA behavior would be one or the other? And, why is the source address relevant for a de-registration alone and not for other PBUs?=20 - MinDelayBeforeBCEDelete Timer:=20 I understand where this timer is coming from, but, I'm not sure I understand the behavior of the LMA fully when that timer is running. For instance, when that timer is active, what happens to any data received by the LMA for that MN? If that is sent to the CoA in the BCE, that is of no use. If that data is dropped, then, it is equivalent to not having a BCE for that MN. So, I'm not exactly sure what that timer is achieving, other than avoiding giving up the HNP too soon. If that is the only intent, then, I'd word it as such and not say that the BCE is active. Otherwise, the processing of data packets during that interval needs to be better defined.=20 - NAI option in the PBA:=20 Why is it needed?=20 - Section 6.2, MN Policy Profile: I'm not sure why this is mandatory. For e.g., if a network has a policy to dynamically acquire an identity for the MN and assign an available HNP to that MN, it is not tied to "policy" in any way. Also, when a policy profile is present, why is the LMA address a mandatory field in it? That seems to be one way of obtaining the LMA address, but, there can be other ways.=20 - Creating RAs at the MAG:=20 How does the MAG obtain the parameters other than the prefix needed for the RA? For instance, the flags or other options that need to be sent? Section 6.4 vaguely mentions based on policy, but, I don't think that is good enough. I think we need to have at least one mode of obtaining that information specified as normative for implementation purposes.=20 - Section 6.6, first bullet:=20 I don't understand what it means for the MAG to authenticate the MN based on an identifier. It is not the role of the MAG to authenticate the MN and it is really irrelevant to the PMIP6 protocol. If the MAG acquires the identity of an MN that has been allowed to access the system (presumably with or without some access authentication), it must use that identity for PMIP6. Other than that, I don't quite understand the MUSTs in this bullet.=20 - Page 35, Timestamp values in retransmitted PBUs:=20 As Suresh said, I don't think the timestamp needs to be updated in a retransmitted PBU. The timestamps are used for ordering, not replay protection here. Replay protection is provided by the IPsec SA (and must be provided by any other authentication mechanism in use). Having said that, it is typically easier for retransmissions to not have to alter the packet being sent. Plus, that will help the LMA be idempotent and just respond with the previously sent PBA (if there was one). In general, this is better to handle DoS attacks too.=20 - Section 6.11, DHCP Relay Agent:=20 This section seems weak. Based on list discussions, there probably is already a plan to elaborate on the role of the MAG as a relay agent. =20 - Section 6.13, last bullet:=20 I'm not sure if absence of data from the MN is an adequate enough indication of MN detachment. If we were to say that, it should read "absence of data to/from the MN", since the MN may just be receiving data and not sending anything. But, also, it is not clear what a "certain duration of time" is, since we don't want the MN to be deregistered while it is in idle mode, for instance.=20 - Security considerations: Authorization of MAGs:=20 It is fine to have the method of authorizing a MAG be out of scope for the specification itself, but, I think we need to give some hints on what that means in the security considerations section. For instance, it could be about that particular MAG just having an IPsec SA with that LMA or it could be something more like that MAG being part of the defined PMIPv6 domain and the corresponding MN-HoA belonging to that domain, etc. =20 - Security considerations: MAG Compromise:=20 Similar comment to the one above. I think we need a bit more detail on ensuring the MN is "definitively attached" to the MAG that sent the PBU. For instance, it could be a AAA check upon reception of a PBU (the document alludes to this somewhere), it could be a CGA signature of the MN carried from an secure RS, in the PBU (this needs more thinking), etc. Again, it is fine that this document doesn't define anything normative here, but, the security considerations as written is hand waving this point.=20 Technical - Minor:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Page 5: PMIPv6 Domain definition:=20 Isn't a PMIP domain also the topological boundary within which the MN doesn't need to change its IP address? It would make sense to state that as part of the definition in my view.=20 - General:=20 Parts of the document contains text on IPv4. I suggest leaving the IPv4 text to the IPv4 document.=20 - Terminology: MN's Home Link:=20 The use of the term "link" in this paragraph seems a bit confusing. The first use of it gives the impression that it is referring to an interface on the MN, but, then, goes to say something about conceptually following the MN. Could we try to reword this for clarity?=20 This is also the case in certain other parts of the document. For instance, the document refers to the PMIPv6 domain appearing as a "single link" to the MN - this is a bit misleading. "Link", for instance, could be an L2 aspect, where the MN actually realizes that a change in it's link has occurred at L2 - it is the IP point of attachment that is being kept constant here in the PMIP6 domain. I think some more clarity there will be helpful. =20 - Section 5.2:=20 Shouldn't the first point be that the LMA should recognize the incoming packet as a PBU, based on the P flag?=20 - Section 5.2, bullet 6:=20 Given that we only have a SHOULD on the use of IPsec, the second sentence there should probably read something like "When IPsec is used for message authentication, the SPI in the IPsec header of the received packet MUST be used for locating..." - Page 17, last bullet:=20 Does this imply that the MN ID must always be present in the PBU? Once an HNP is allocated, isn't that sufficient to indicate the binding that needs to be refreshed? In that case, we don't need the MN ID to be present in subsequent BUs. - Timestamp values:=20 In the 4th bullet from the bottom on page 22, it says "MUST be close enough" of the LMA's clock - I don't think "close enough" is sufficient here. For interoperability, I believe we should specify the range for closeness.=20 - "SHOULD" for access authentication:=20 I'm not sure why this is a SHOULD for this specification. Just because access authentication is likely to be done on systems that are looking at adopting PMIP6 today doesn't make it a requirement for the protocol. In my view, there is no depedency between having acces control versus not from a PMIP perspective.=20 - Section 6.6, MN identity:=20 We should mention that this could be a link layer address or pretty much any identifier that uniquely identifies the MN in that domain.=20 - Page 33, Timestamp synchronization:=20 Why do we prevent the MAG from using the LMA's timestamp value in the PBA to synchronize its clock? If we specify the acceptable drift correctly and if the MAG has an idea about average transmission delays of the network, it should be feasible. Or, am I missing something?=20 - Page 34, Binding De-registration:=20 Why is this a MUST? If another MAG sends a PBU for the MN, the existing entry will be overwritten anyway. If not, the binding will eventually time out. It seems like a SHOULD for de-registration is sufficient.=20 - Section 7, MN behavior:=20 Given that this section is non-normative, I think phrases like "it is recommended" or "it is important/critical" should be changed. It sends the impression that those are really important for the protocol even though an IP node implementation is not expected to change. I think phrasing those as "the protocol would benefit from X" or "lower latency can be achieved by doing Y" would be more appropriate. =20 Editorial:=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Page 2: Abstract:=20 s/network being in control of the mobility management/network being responsible for IP mobility management of mobile nodes.=20 - Page 4: Intro:=20 s/The proxy mobility agent/A mobility agent=20 "proxy mobility agent" sounds like a new term, while mobility agent has been used before in the context of home and foreign agents. We are referring to one such agent here.=20 - Page 5: LMA definition:=20 s/and with the additional/with the additional=20 - Page 6: MN definition:=20 s/Through out/ Throughout - Page 7: s/The local mobility is responsible/The local mobility agent is responsible - Page 12: s/making it believe its still on/ making it believe it is still on - Section 5.1:=20 It would be good to add a sentence on the significance of the MN's link local address in the BCE of the LMA. This isn't stated until section 6.8 and even there, it is a bit buried.=20 - Section 5.2: The first sentence reads as if there is only one exception to the processing rules of RFC3775, but, there is a long list of additional considerations. I suggest wording it to say that additional considerations apply and leaving the "one exception" part out of the sentence. =20 - s/IPSec/IPsec for all instances - Page 20, last bullet:=20 The use of MUST/SHOULD with IPsec should be made consistent - for e.g., here, it should read that the message MUST be authenticated and IPsec SHOULD be used for that.=20 - Page 21, first bullet: s/header, /header - Page 21, Section 5.4:=20 s/absence of context transfer mechanism/absence of mechanisms such as context transfer between MAGs - Page 21, last paragraph:=20 I think we should avoid normative language for the sequence number case, given that we don't define that here. So, all the "MUSTs" should be changed to read as what needs to happen in the case of sequence number use in regular expression. Please note that "must" is equivalent to "MUST" per RFC2119 :)=20 - Page 25, last sentence of section 5.6 Reword to "This may be obtained through mechanisms outside the scope of this document, e.g., configuration as part of the mobile node's policy profile."=20 - Section 5.8:=20 It would be good to clearly state that RO is out of scope for this document. The section currently only says RR cannot be used.=20 - Page 27, first bullet:=20 s/access link or through/access link through - Page 27:=20 s/This address is acquired from/This address may be acquired from=20 A preconfigured LMA address as part of MN's policy profile is only one possibility.=20 - RFC2461/2462 references should change to 2461bis and 2462bis - Page 33: s/SHOULD not/SHOULD NOT - Page 34/35: The "MUST construct" seems to be at odds with the SHOULDs that follow. =20 - Page 35: s/when ever/whenever - Page 35: s/what ever reasons/whatever reason - Page 39, Section 6.10.4:=20 s/this has an implication on the mobile node's accounting/in some systems, this may have an implication on the mobile node's accounting - Page 43, 3rd para: s/access link, receives/access link receives - Page 54: s/a denial-of-service attacks/a denial-of-service attack - Page 55: s/different domains/different administrative domains _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 08:30:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9YE-0000gD-Hq; Tue, 25 Sep 2007 08:30:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9YC-00085F-HS for netlmm@ietf.org; Tue, 25 Sep 2007 08:30:04 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ia9Xn-0006XY-Ay for netlmm@ietf.org; Tue, 25 Sep 2007 08:29:39 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1190723377!8755339!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32273 invoked from network); 25 Sep 2007 12:29:37 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with SMTP; 25 Sep 2007 12:29:37 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8PCTXGr017547; Tue, 25 Sep 2007 05:29:33 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8PCTW6I015772; Tue, 25 Sep 2007 07:29:32 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8PCTV33015747; Tue, 25 Sep 2007 07:29:31 -0500 (CDT) Message-ID: <46F8FF2A.2010701@gmail.com> Date: Tue, 25 Sep 2007 14:29:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: DHCP Relay link-address use is probably inapppropriate (was: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05) References: <46F848E2.40904@ericsson.com> <001f01c7ff31$1cf18860$1220fea9@amer.cisco.com> In-Reply-To: <001f01c7ff31$1cf18860$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000776-0, 24/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri Gundavelli wrote: [...] >> Section 6.11 ============ >> >> I am not sure how the MAG can send the HNP of the MN in the >> link-address field of the DHCP relay message since the link-address >> field does not contain a prefix length. Is there an implicit >> assumption that the prefix will be 64 bits in length? >> > > This is per 3315. I will look into the format. I think here may be an error of interpretation or of specification. RFC3315: > If the relay agent received the message to be relayed from a client, > the relay agent places a global or site-scoped address with a prefix > assigned to the link on which the client should be assigned an > address in the link-address field. I think it wrongly says "with a prefix". Because: (1) it makes people think there is a prefix length in that field, (2) the DHCP RELAY-FORWARD doesn't encode a prefix length (3315 pp 18) (3) wireshark doesn't show a prefix length field, (4) Dibbler implementation doesn't encode a prefix length but a full /128 address in that field, it's the address of the Relay interface on which a mobile attaches. This is why I suggest we discuss this use of DHCP separately. Let's define first the problem: why does the MAG DHCP Relay need to insert the prefix of the mobile in the RELAY-FORWARD message? How can we do it (other than link-address field)? If you don't think we should discuss it and continue keeping the use of link-address field as you suggest then I suggest to move it into an appendix. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 08:34:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9cK-0000MX-Sx; Tue, 25 Sep 2007 08:34:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9cJ-0000M0-P4 for netlmm@ietf.org; Tue, 25 Sep 2007 08:34:19 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ia9cJ-0006cs-6m for netlmm@ietf.org; Tue, 25 Sep 2007 08:34:19 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1190723657!7199092!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9031 invoked from network); 25 Sep 2007 12:34:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 25 Sep 2007 12:34:18 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8PCYHFS018686; Tue, 25 Sep 2007 05:34:17 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8PCYH8r018651; Tue, 25 Sep 2007 07:34:17 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8PCYFBE018629; Tue, 25 Sep 2007 07:34:16 -0500 (CDT) Message-ID: <46F90047.8050409@gmail.com> Date: Tue, 25 Sep 2007 14:34:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: FW: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-06.txt References: <004b01c7fe84$70839c00$d5f6200a@amer.cisco.com> <46F7A2A4.7010602@gmail.com> <001b01c7ff27$30d373c0$1220fea9@amer.cisco.com> In-Reply-To: <001b01c7ff27$30d373c0$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000776-0, 24/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, Sri Gundavelli wrote: >>> 6.11. Supporting DHCPv6 based Address Configuration on the >>> Access Link >>> >>> This non-normative section explains how Stateful Address >>> Configuration using DHCPv6 can be enabled on the access link >>> attached to a mobile access gateway and how a mobile node >>> attached to that link can obtain an address from its home network >>> prefix using DHCPv6. >> >> Basically I agree that the DHCP behaviour described in this section >> is non-normative (==informative?). Would it be better placed as >> an Appendix? >> > > This text provides the basic guidance on how to enable DHCP based > addressing. This guidance is important for deployments. Sri, I'm sorry to say so and please don't take it personal, as usual. This guidance is simply wrong. It wrongly interprets rfc 3315 which is itself not according to implementations, in this respect. > I should rephrase this slightly to explicitly state the spec does not > mandate on having DHCP relay on the MAG. Its an optional > configuration. That was the intent, I should remove this line on > non-normative part. I think this is another matter. If you want to make it a normative suggestion and keep it in the main body of the spec I think you should remove the use of link address for a prefix and use something else. I could suggest something to use, but I feel like you have overlooked my previous suggestions, I'll wait when we can discuss this openly. (maybe I"m writing too many messages too, sorry about that). >> Moreover, if/when we're to discuss DHCP behaviour we risk important >> disagreements on how it should work. (1) how prefix delegation is >> integrated, (2) how PMIP6 handover influences DHCP exchanges, (3) >> how and what the MAG DHCP Relay inserts in the client messages, >> (4) how the server identifies the client. > > > Prefix assignment is done by the LMA and it can use DHCP PD for that. > The draft does not cover the details on how the LMA does the prefix > allocation. It doesn't even say that the LMA could use DHCP PD for that. >> 1/64000 fractions of a second? Or 1/65536 fractions of a second. I >> propose to specifically say 1/65536 fractions because 64k means >> 65536 only if we talk bits (not seconds), in my understanding. >> > > Ok. Will fix it. Thank you. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 09:11:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaABv-0008KR-Al; Tue, 25 Sep 2007 09:11:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaABt-0008Jo-9q for netlmm@ietf.org; Tue, 25 Sep 2007 09:11:05 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IaABs-0007TJ-8D for netlmm@ietf.org; Tue, 25 Sep 2007 09:11:05 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1190725863!23252358!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24710 invoked from network); 25 Sep 2007 13:11:03 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 25 Sep 2007 13:11:03 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8PDB2rO029884; Tue, 25 Sep 2007 06:11:02 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l8PDB2Dg011042; Tue, 25 Sep 2007 08:11:02 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l8PDB1XL011009; Tue, 25 Sep 2007 08:11:01 -0500 (CDT) Message-ID: <46F908E4.30609@gmail.com> Date: Tue, 25 Sep 2007 15:11:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan Subject: Re: time and BoF (was: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05) References: <46F848E2.40904@ericsson.com> In-Reply-To: <46F848E2.40904@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000776-0, 24/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Suresh Krishnan wrote: [...] > Timestamp synchronization > ========================= > I read through the timestamp approach for synchronization and it is > unclear why the MAG and the LMA need to sync their clocks. I think it is > sufficient for MAGs to sync between themselves. Why does the LMA need to > check if the MAGs timestamp is different from its timestamp? This is a tough question, but I believe they should have their times synchronized unless a method like the one proposed by Ahmad previously, or maybe mixing a uniqid (MAC) in the timestamp - are used. I think this is a good topic to ponder over, and apparently at IETF there may even be a place to discuss these aspects related to time. http://www.ietf.org/internet-drafts/draft-bryant-tictoc-probstat-01.txt Alex > > LMA Address acquisition > ======================= > Why is the LMA address a mandatory part of the MN profile? And why is it > the ONLY allowed method for acquiring an LMA address? Can't the MAG use > some other method to acquire the LMA address (static config, DNS...). I > think this is overly restrictive. > > > Section 4 > ========= > "IKEv2 [RFC-4306] SHOULD be used to setup security associations > between the mobile access gateway and the local mobility anchor to > protect the Proxy Binding Update and Proxy Binding Acknowledgement > messages." > > This is a significant departure from RFC3775 where this was a MAY. What > is the reasoning behind making this a SHOULD? I believe manual config > should be a MUST and automatic key mgmt should be a MAY. > > P flag > ====== > > I do not see any text in the expected LMA behavior to CHECK for the > presence of the P flag in the received BU. I think this should be added. > > Section 5.3: Binding De-registration > ==================================== > "Upon accepting the Proxy Binding Update request for a mobile node, > with the lifetime value of zero, the local mobility anchor MUST > wait for MinDelayBeforeBCEDelete amount of time, before it deletes > the mobile node's Binding Cache entry." > > What is the purpose for having a timer to delete a BCE? I see no reason > at all in waiting. If this is being done to prevent considering a > following BU as an initial registration ( I suspect this is the case) > please extend the conceptual data structure to add a deleted flag > instead of using a timer. > > The following step directly contradicts this step as well. Make sure > that they are consistent. > > Section 5.3: PBA formation > ========================== > " If the Status field is set to a value greater less than 128, i.e. > if the binding request was rejected, then the prefix value in the > Home Network Prefix option MUST be set to the prefix value from > the received Home Network Prefix option." > > This does not cover the case where the PBU did not contain a HNP option > (rejection with error 129). So the text needs to be extended in order to > clarify the behavior in such case. I would suggest the following text > > " If the Status field is set to a value greater less than 128, i.e. > if the binding request was rejected, then the prefix value in the > Home Network Prefix option MUST be set to the prefix value from > the received Home Network Prefix option. If the received PBU did > not contain a Home Network Prefix option, then the HNP option MUST > NOT be included. " > > This also implies that the HNP field becomes optional in the PBA. > > Section 6.8 > =========== > I am not sure how the odds of collision are arrived at. If there is a > reference please put it in here. However I look at it, the number does > not look too good to me. Anyway, this feels totally out of place in the > PMIP spec. Thus, as an alternative, you can remove the whole text > without losing anything. > > Section 6.9.1 > ============= > "o If the received Proxy Binding Acknowledgement message has the > Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX > (Not authorized for that prefix), the mobile access gateway SHOULD > try to request for that prefix in the binding registration > request, only after it learned the validity of that prefix." > > I am not sure why the MAG SHOULD try again. If this error case occurs, I > think that the MAG SHOULD do one of the following > > 1) Deny mobility service to the MN > 2) Send a PBU with the null hnp to request a new prefix allocation > > Section 6.9.3 > ============= > " o If Timestamp based scheme is in use, the retransmitted Proxy > Binding Update messages MUST use the latest timestamp. If > Sequence number scheme is in use, the retransmitted Proxy Binding > Update messages MUST use a Sequence Number value greater than that > used for the previous transmission of this Proxy Binding Update > message, just as specified in [RFC-3775]." > > I completely disagree with this. I think if a PBU is retransmitted it > MUST use the same timestamp as the first time around. Otherwise we will > run into ordering problems. > > Section 6.11 > ============ > > I am not sure how the MAG can send the HNP of the MN in the link-address > field of the DHCP relay message since the link-address field does not > contain a prefix length. Is there an implicit assumption that the prefix > will be 64 bits in length? > > IANA Considerations > =================== > > Don't forget to request the assignment of the P bit in the BU and BA > messages in the IANA considerations section. > > > Minor > ===== > > Section 3 > ========= > > Figure 3: The detach flow is not explained at all. If the detach flow > needs to stay in the figure, it needs to be elaborated in the following > text. It is probably not relevant in this figure either, since the BCE > gets replaced by the new PBU anyway. > > Section 5.3 > =========== > > The following two bullets refer to section 4.0 that does not exist. Can > you insert the reference to the right section here. (I am assuming it is > section 4 but I am not sure) > > o The local mobility anchor MUST authenticate the Proxy Binding > Update request as described in Section 4.0. It MUST use the SPI > in the IPSec header [RFC-4306] of the received packet for locating > the security association needed for authenticating the Proxy > Binding Update request. > > o The local mobility anchor MUST apply the required policy checks, > as explained in Section 4.0, to verify the sender is a trusted > mobile access gateway, authorized to send proxy binding > registration requests on behalf of this mobile node > > Section 5.3: Binding De-registration > ==================================== > "the local mobility anchor MAY either choose to ignore > the request or send a valid Proxy Binding Acknowledgement message > with the Status field set to 0 (Proxy Binding Update Accepted" > > as opposed to doing what else? I think this whole point is redundant. > Recommend one of these options or remove the whole paragraph. > > Section 5.5.2 : Forwarding considerations > ========================================= > > Point 1 (Intercepting packets ...) > > This point explains plain IP routing. I am not sure what it has to do > with PMIP. Is there any reason this point needs to be explicitly mentioned? > > Section 6.8 > =========== > The last paragraph states > " This issue is not relevant to the mobile node's global address. > Since, there is a unique home network prefix for each mobile node, > the uniqueness for the mobile node's global address is assured on the > access link" > > By turning on the DNASameLinkDADFlag the MN will do DAD on the global > address as well. The flag is not exclusive to LL addresses.I think this > should be clarified. > > Section 6.10.4 > ============== > > The config variable EnableMAGLocalRouting is not mentioned here. Can you > add it here as it is very relevant here. > > Section 8.1 > =========== > > Add references to HMIP and nemo for the M and R flags as they are not > defined in RFC3775 as implied by the text. > > > Editorial > ========= > > Section 2.2 > =========== > LMA: > "It is the topological anchor point for > the mobile node's home network prefix and is the entity that > manages the mobile node's reachability state." > > I am not sure what the phrase "manages the MN's reachability state" > means. Can you please clarify or remove this phrase. > > > Section 3 > ========= > paragraph 3 line 2 > > Replace "The local mobility is" with "The local mobility anchor is" > > Section 5.5.1 > ============= > There is redundant text regarding shared tunnels between MNs. > > point 3: "The created tunnel may be shared > with other mobile nodes attached to the same mobile access gateway > and with the local mobility anchor having a Binding Cache entry > for those mobile nodes." > > point 4: "The tunnel between the local mobility anchor and the mobile > access > gateway is typically a shared tunnel and can be used for routing > traffic streams for different mobile nodes attached to the same > mobile access gateway." > > I think point 4 can safely be removed > > Section 6.9.1 > ============= > Binding Re-Registration: > "the value in the Link-local Address option may be set to ALL_ZERO > or to the link-local address of the mobile node." > > This has to be a normative MAY. > > Section 6.9.2 > ============= > Router Solicitations: > "However, it MAY choose to advertise a local visitor > network prefix to enable the mobile node for simple IPv6 access." > > Replace "visitor" with "visited" > > References > ========== > > Please update references for all the bis RFCs 2461,2462,3041 etc. so > that the RFC editor will replace them with the latest RFCs > (4861,4862,4941...) > > > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 10:10:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaB6i-0006mL-AN; Tue, 25 Sep 2007 10:09:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaB6X-0006He-Fa for netlmm@ietf.org; Tue, 25 Sep 2007 10:09:38 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaB6R-0006OS-8R for netlmm@ietf.org; Tue, 25 Sep 2007 10:09:37 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l8PE9D0p000422; Tue, 25 Sep 2007 09:09:14 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 09:09:13 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 09:09:13 -0500 Message-ID: <46F91662.6030200@ericsson.com> Date: Tue, 25 Sep 2007 10:08:34 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 References: <46F848E2.40904@ericsson.com> <46F852A3.1040401@azairenet.com> In-Reply-To: <46F852A3.1040401@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2007 14:09:13.0298 (UTC) FILETIME=[A6838320:01C7FF7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vijay, Thanks for the quick response. My comments inline. Cheers Suresh Vijay Devarapalli wrote: > Hi Suresh, > > A few random replies. Assume Sri will respond in detail :) > > Suresh Krishnan wrote: >> Link Local address of MAG >> ========================= >> When an MN moves from one link to another how does it switch default >> routers to the new MAG. The link local addresses of the old MAG and the >> new MAG will most likely be different and hence unless nud removes the >> old mag the mn will try to reach it even after handover. Or it is >> assumed that all the MAGs will have the same LL address? Is this is an >> assumption, it needs to be stated. > > It is assumed that the same link local address is used for a particular > mobile node across all MAGs. This is stored at the LMA and retrieved by > the new MAG. This is described in the document. I was talking about the LL address of the MAG (not the MN). > >> Section 4 >> ========= >> "IKEv2 [RFC-4306] SHOULD be used to setup security associations >> between the mobile access gateway and the local mobility anchor to >> protect the Proxy Binding Update and Proxy Binding Acknowledgement >> messages." >> >> This is a significant departure from RFC3775 where this was a MAY. What >> is the reasoning behind making this a SHOULD? I believe manual config >> should be a MUST and automatic key mgmt should be a MAY. > > At the time RFC 3775 was written, IKEv1 was on the "way out". Currently > IKEv2 seems to be the default for setting up IPsec security associations. OK. > >> P flag >> ====== >> >> I do not see any text in the expected LMA behavior to CHECK for the >> presence of the P flag in the received BU. I think this should be added. > > hmmm.... the LMA uses the 'P' flag to recognize that it is a proxy > binding update from a MAG. Otherwise the LMA assumes it is a MIPv6 > binding update from a MIPv6 mobile node. So the LMA checks for the 'P' > flag all the time. I know it. You know it. But it is not in the document :-). A simple note in section 5.3 would do. "o If the P flag is not set in the Proxy Binding Update request, the local mobility anchor MUST discard the Proxy Binding Update and log an error. " Also note that the definition of a PBU DOES NOT mention the P flag either. > >> Section 5.3: Binding De-registration >> ==================================== >> "Upon accepting the Proxy Binding Update request for a mobile node, >> with the lifetime value of zero, the local mobility anchor MUST >> wait for MinDelayBeforeBCEDelete amount of time, before it deletes >> the mobile node's Binding Cache entry." >> >> What is the purpose for having a timer to delete a BCE? I see no reason >> at all in waiting. If this is being done to prevent considering a >> following BU as an initial registration ( I suspect this is the case) >> please extend the conceptual data structure to add a deleted flag >> instead of using a timer. > > This is to make sure you don't release the home address/home network > prefix as soon as a MAG de-registers. The proxy binding update from the > new MAG may have been delayed. What happens to the data that is received in this time period? Why will this be unnecessarily carried to the MAG before being dropped? That is my concern. That is why I suggested marking it as deleted (which will stop the data flow) and do a cleaning sweep periodically. > >> Section 6.9.3 >> ============= >> " o If Timestamp based scheme is in use, the retransmitted Proxy >> Binding Update messages MUST use the latest timestamp. If >> Sequence number scheme is in use, the retransmitted Proxy Binding >> Update messages MUST use a Sequence Number value greater than that >> used for the previous transmission of this Proxy Binding Update >> message, just as specified in [RFC-3775]." >> >> I completely disagree with this. I think if a PBU is retransmitted it >> MUST use the same timestamp as the first time around. Otherwise we will >> run into ordering problems. > > No. It should always use the latest timestamp value. Otherwise the LMA > would not be able to distinguish between a lost Proxy BU being > re-transmitted from a replayed proxy BU. I cannot see how this works. Consider this scenario. MN moves from MAG1 to MAG2 and then to MAG3. M1: MAG2 sends PBU with Timestamp T (This is lost) M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA and updates the binding cache on the LMA) M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at LMA. LMA sees that the timestamp is later than the current one and then replaces the current entry in the Binding Cache) MN loses connectivity. > >> IANA Considerations >> =================== >> >> Don't forget to request the assignment of the P bit in the BU and BA >> messages in the IANA considerations section. > > The binding update flags are not maintained by the IANA. The respective > documents define the flags and their positions. OK. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 10:19:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBG2-0002zE-Nz; Tue, 25 Sep 2007 10:19:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBG1-0002yM-Ia for netlmm@ietf.org; Tue, 25 Sep 2007 10:19:25 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaBFv-0006eH-8t for netlmm@ietf.org; Tue, 25 Sep 2007 10:19:20 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l8PEJCFC003247; Tue, 25 Sep 2007 09:19:13 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 09:19:12 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 09:19:12 -0500 Message-ID: <46F918B9.3000709@ericsson.com> Date: Tue, 25 Sep 2007 10:18:33 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Sri Gundavelli Subject: Re: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 References: <46F848E2.40904@ericsson.com> <001f01c7ff31$1cf18860$1220fea9@amer.cisco.com> In-Reply-To: <001f01c7ff31$1cf18860$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2007 14:19:12.0333 (UTC) FILETIME=[0B90FFD0:01C7FF7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, I am removing things that we agreed on. Cheers Suresh Sri Gundavelli wrote: > Hi Suresh, > > Thanks for the review. Please see inline. > > Sri > > > >> Link Local address of MAG >> ========================= >> When an MN moves from one link to another how does it switch default >> routers to the new MAG. The link local addresses of the old >> MAG and the >> new MAG will most likely be different and hence unless nud removes the >> old mag the mn will try to reach it even after handover. Or it is >> assumed that all the MAGs will have the same LL address? Is this is an >> assumption, it needs to be stated. >> > > The MN section has the text on this. The DR needs to be timeout > or in links where SEND is not deployed, a fixed linkeed-local > address can be configured on all MAG interfaces. One or more > ways to deal with it. MAG can also withdraw the prev AR. OK. > > >> Timestamp synchronization >> ========================= >> I read through the timestamp approach for synchronization and it is >> unclear why the MAG and the LMA need to sync their clocks. I >> think it is >> sufficient for MAGs to sync between themselves. Why does the >> LMA need to >> check if the MAGs timestamp is different from its timestamp? >> > > This is for convering the case, where the MN boots on a bad MAG > where the time is like 5 hours ahead. If LMA does not do the > basic sanity check and accepts the PBU, all subsequent PBU's > from the other MAG's where the MN moves to will have older TS. > We have discussed this thread to death. No worries on this logic. But isn't this still the case where the MAGs have to be synced and not the LMAs. I am thinking about roaming scenarios where the MAGs can and will be connected to multiple and keeping the time in sync between the MAGs and the LMAs becomes a big issue. > > >> LMA Address acquisition >> ======================= >> Why is the LMA address a mandatory part of the MN profile? >> And why is it >> the ONLY allowed method for acquiring an LMA address? Can't >> the MAG use >> some other method to acquire the LMA address (static config, >> DNS...). I >> think this is overly restrictive. >> > > Hmm ... I can move the LMAA to the optional section. Fine, if > we think there are other methods of LMA discovery. OK. > > >> Section 4 >> ========= >> "IKEv2 [RFC-4306] SHOULD be used to setup security associations >> between the mobile access gateway and the local mobility anchor to >> protect the Proxy Binding Update and Proxy Binding Acknowledgement >> messages." >> >> This is a significant departure from RFC3775 where this was a >> MAY. What >> is the reasoning behind making this a SHOULD? I believe manual config >> should be a MUST and automatic key mgmt should be a MAY. >> > > The thought was that the SA is protecting multiple MN flows and its > important that the SA's are setup dynamically using IKEv2 and with > the proper rekeying properties. Also, as Vijay says, when 3775 came > out not many mobile stacks have IPsec support and that could be > the reason for not mandating IKE. > OK. > >> P flag >> ====== >> >> I do not see any text in the expected LMA behavior to CHECK for the >> presence of the P flag in the received BU. I think this >> should be added. >> > > The message with the "P" flag is the PBU. The whole signaling logic > is tied to this message. As I said in my mail to Vijay, I know this is the case, but it is not mentioned anywhere in the document. Explaining this in either the terminology for the PBU ("a PBU will have the P flag set...") or adding a checking step in the LMA operation will do. > > >> Section 5.3: Binding De-registration >> ==================================== >> "Upon accepting the Proxy Binding Update request for a mobile node, >> with the lifetime value of zero, the local mobility anchor MUST >> wait for MinDelayBeforeBCEDelete amount of time, before it deletes >> the mobile node's Binding Cache entry." >> >> What is the purpose for having a timer to delete a BCE? I see >> no reason >> at all in waiting. If this is being done to prevent considering a >> following BU as an initial registration ( I suspect this is the case) >> please extend the conceptual data structure to add a deleted flag >> instead of using a timer. > > > For covering the make-before-break case. It cant be just a flag, > its a time sensitive operation. In a make-before-break case, the new PBU will arrive BEFORE the deregistration PBU will arrive. I am not sure I see the applicability of the timer to this case. Can you please clarify. > > >> The following step directly contradicts this step as well. Make sure >> that they are consistent. >> >> Section 5.3: PBA formation >> ========================== >> " If the Status field is set to a value greater less than 128, i.e. >> if the binding request was rejected, then the prefix value in the >> Home Network Prefix option MUST be set to the prefix value from >> the received Home Network Prefix option." >> >> This does not cover the case where the PBU did not contain a >> HNP option >> (rejection with error 129). So the text needs to be extended >> in order to >> clarify the behavior in such case. I would suggest the following text >> >> " If the Status field is set to a value greater less than 128, i.e. >> if the binding request was rejected, then the prefix value in the >> Home Network Prefix option MUST be set to the prefix value from >> the received Home Network Prefix option. If the received PBU did >> not contain a Home Network Prefix option, then the HNP option MUST >> NOT be included. " >> >> This also implies that the HNP field becomes optional in the PBA. > > Ok. This is a good point. The idea of rejecting a message because > it does not have a specific option, conflicts with the mandatory > option requirement. I think, the LMA should simply ignore a message > if a specific required option is not present. I will fix it. OK. >> Section 6.9.3 >> ============= >> " o If Timestamp based scheme is in use, the retransmitted Proxy >> Binding Update messages MUST use the latest timestamp. If >> Sequence number scheme is in use, the retransmitted >> Proxy Binding >> Update messages MUST use a Sequence Number value >> greater than that >> used for the previous transmission of this Proxy Binding Update >> message, just as specified in [RFC-3775]." >> >> I completely disagree with this. I think if a PBU is retransmitted it >> MUST use the same timestamp as the first time around. >> Otherwise we will >> run into ordering problems. >> > > I dont think it will create any ordering problems. The message is > generated at a different time. If it uses old timestamp, it breaks > the LMA sanity check rule. Please see my mail to Vijay on this subject where I explained a scenario. > > >> Section 6.11 >> ============ >> >> I am not sure how the MAG can send the HNP of the MN in the >> link-address >> field of the DHCP relay message since the link-address field does not >> contain a prefix length. Is there an implicit assumption that >> the prefix >> will be 64 bits in length? >> > > This is per 3315. I will look into the format. OK. > > >> IANA Considerations >> =================== >> >> Don't forget to request the assignment of the P bit in the BU and BA >> messages in the IANA considerations section. >> > > As Vijay pointed out, IANA does not manage this part. OK. >> Section 5.5.2 : Forwarding considerations >> ========================================= >> >> Point 1 (Intercepting packets ...) >> >> This point explains plain IP routing. I am not sure what it has to do >> with PMIP. Is there any reason this point needs to be >> explicitly mentioned? >> > > Well, some basic guidance. Not every one is an expert > in forwarding :) OK. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 13:44:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaES7-0005xU-7t; Tue, 25 Sep 2007 13:44:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaES6-0005rS-9n for netlmm@ietf.org; Tue, 25 Sep 2007 13:44:06 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaES5-00070p-LO for netlmm@ietf.org; Tue, 25 Sep 2007 13:44:06 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8PHhvt05663; Tue, 25 Sep 2007 17:43:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 12:43:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116F660AB@zrc2hxm2.corp.nortel.com> In-Reply-To: <46F91662.6030200@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/fizRwDvVx1BJT++YXmwpogi4YQAEVVbw References: <46F848E2.40904@ericsson.com> <46F852A3.1040401@azairenet.com> <46F91662.6030200@ericsson.com> From: "Ahmad Muhanna" To: "Suresh Krishnan" , "Vijay Devarapalli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > >=20 > >> Section 6.9.3 > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> " o If Timestamp based scheme is in use, the retransmitted Proxy > >> Binding Update messages MUST use the latest timestamp. If > >> Sequence number scheme is in use, the retransmitted=20 > Proxy Binding > >> Update messages MUST use a Sequence Number value=20 > greater than that > >> used for the previous transmission of this Proxy=20 > Binding Update > >> message, just as specified in [RFC-3775]." > >> > >> I completely disagree with this. I think if a PBU is=20 > retransmitted it > >> MUST use the same timestamp as the first time around.=20 > Otherwise we will > >> run into ordering problems. > >=20 > > No. It should always use the latest timestamp value.=20 > Otherwise the LMA=20 > > would not be able to distinguish between a lost Proxy BU being=20 > > re-transmitted from a replayed proxy BU. >=20 > I cannot see how this works. Consider this scenario. >=20 > MN moves from MAG1 to MAG2 and then to MAG3. >=20 > M1: MAG2 sends PBU with Timestamp T (This is lost) > M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA=20 > and updates=20 > the binding cache on the LMA) > M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at=20 > LMA. LMA=20 > sees that the timestamp is later than the current one and=20 > then replaces=20 > the current entry in the Binding Cache) >=20 > MN loses connectivity. [Ahmad] Hi Suresh, The scenario you just mentioned is not very much different than what has been discussed before on this mailing list and offline. Please let me summarize this as follows: 1. This scenario is related to a race condition that has been identified a long time ago and a solution has been proposed and identified for it but for a reason or another some people does not like to document the solution in PMIPv6 draft. 2. Having said the above, the scenario at hand as you mentioned can happen due to a combination of more than two events that accidentally happens at the same time: 2.1. A MN1 is attached to MAG1 and has a PMIP session with a BCE (P-CoA1 <-> P-HoA1) at LMA1. 2.2. MN1 PMIP session is about to expire and MAG1 sends a re-registration P-BU2 to extends the MN1 PMIP session lifetime. 2.2.1. Currently: PMIPv6 draft requires the MAG to make sure the MN is attached before sending a re-registration P-BU. 2.3. At almost the same time or soon after MAG1 sends the re-registration P-BU2, MN moves to MAG3 and does all access authentication and all the good stuff that enables MAG2 to send an initial P-BU3 to update the MN BCE with (P-CoA2 <-> P-HoA1) at LMA1. 2.4. Not only that, but this scenario requires one of the followings (P-BU2 is either delayed or lost) and P-BU3 arrives first. 2.5. I am not saying that this scenario is impossible but it rarely could happen. But that is fine. 2.6. When LMA receives P-BU3, LMA clearly can identify that the MN is moving from MAG1 to MAG2. The details of the solution starts here and it will address all scenarios: 3. LMA creates a tentative BCE for MN1 (P-CoA2 <-> P-HoA1) and starts sending traffic to the new P-CoA2. 4. If LMA receive the P-BU2 (the one delayed or the retransmitted after the first lost) within the lifetime of the tentative BCE, LMA does the following: 4.1. LMA rejects the P-BU2 with P-BA2 and code "MN-Handoff-in-Progress" for example, or we can call it whatever. 4.2. LMA keeps the traffic pointing to (P-CoA2 <-> P-HoA1) 4.3. When MAG receives the P-BA2, MAG cancel the MN current re-registration states and verifies if the MN is still attached before sending any new P-BU. 4.4. When the BCE timer expires, LMA replace the old BCE with the tentative BCE. Tentative BCE can be as simple as having a simple timer running. The funny thing is that I heard some people are ok to leave such a scenario out-of-scope and not document the solution in PMIPv6 draft. I am not sure why people think that way but it is an opinion. :-( This solution should address the race condition that you just highlighted. Best Regards, Ahmad >=20 > >=20 > >> IANA Considerations > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> Don't forget to request the assignment of the P bit in the=20 > BU and BA > >> messages in the IANA considerations section. > >=20 > > The binding update flags are not maintained by the IANA.=20 > The respective=20 > > documents define the flags and their positions. >=20 > OK. >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 15:25:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaG2D-0000Wb-C0; Tue, 25 Sep 2007 15:25:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaG2C-0000Vc-6X for netlmm@ietf.org; Tue, 25 Sep 2007 15:25:28 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaG2B-0002OF-Fs for netlmm@ietf.org; Tue, 25 Sep 2007 15:25:28 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l8PJWqEN008594; Tue, 25 Sep 2007 14:32:52 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 14:25:24 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 14:25:24 -0500 Message-ID: <46F9607E.5030504@ericsson.com> Date: Tue, 25 Sep 2007 15:24:46 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 References: <46F848E2.40904@ericsson.com> <46F852A3.1040401@azairenet.com> <46F91662.6030200@ericsson.com> <6FC4416DDE56C44DA0AEE67BC7CA437116F660AB@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116F660AB@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2007 19:25:24.0105 (UTC) FILETIME=[D1FEEF90:01C7FFA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, I see the problem you are mentioning and is very valid and I think your solution is a reasonable one for the problem that you mentioned. But unfortunately the problem is not the one that I raised in my comments. The main differences between the scenarios are * In my scenario, only one event needs to occur for problems to occur (Lost PBU only, no re-ordering necessary) * No BCE was ever created for the MAG whose PBU arrives second(MAG2). In your scenario MAG1 ONCE HAD a valid BCE. * In your scenario the problem causing PBU is a refresh PBU (after lifetime expires) and in mine it is just a retransmission. Note that there is no requirement for the MAG to check for MN's attachment before RETRANSMITTING a PBU. I think the scenarios are both race conditions, but that is where the similarity ends. I do not think the same solution applies to both. Do you agree? Cheers Suresh Ahmad Muhanna wrote: >>>> Section 6.9.3 >>>> ============= >>>> " o If Timestamp based scheme is in use, the retransmitted Proxy >>>> Binding Update messages MUST use the latest timestamp. If >>>> Sequence number scheme is in use, the retransmitted >> Proxy Binding >>>> Update messages MUST use a Sequence Number value >> greater than that >>>> used for the previous transmission of this Proxy >> Binding Update >>>> message, just as specified in [RFC-3775]." >>>> >>>> I completely disagree with this. I think if a PBU is >> retransmitted it >>>> MUST use the same timestamp as the first time around. >> Otherwise we will >>>> run into ordering problems. >>> No. It should always use the latest timestamp value. >> Otherwise the LMA >>> would not be able to distinguish between a lost Proxy BU being >>> re-transmitted from a replayed proxy BU. >> I cannot see how this works. Consider this scenario. >> >> MN moves from MAG1 to MAG2 and then to MAG3. >> >> M1: MAG2 sends PBU with Timestamp T (This is lost) >> M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA >> and updates >> the binding cache on the LMA) >> M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at >> LMA. LMA >> sees that the timestamp is later than the current one and >> then replaces >> the current entry in the Binding Cache) >> >> MN loses connectivity. > > [Ahmad] > Hi Suresh, > > The scenario you just mentioned is not very much different than what has > been discussed before on this mailing list and offline. Please let me > summarize this as follows: > > 1. This scenario is related to a race condition that has been identified > a long time ago and a solution has been proposed and identified for it > but for a reason or another some people does not like to document the > solution in PMIPv6 draft. > > 2. Having said the above, the scenario at hand as you mentioned can > happen due to a combination of more than two events that accidentally > happens at the same time: > > 2.1. A MN1 is attached to MAG1 and has a PMIP session with a BCE (P-CoA1 > <-> P-HoA1) at LMA1. > 2.2. MN1 PMIP session is about to expire and MAG1 sends a > re-registration P-BU2 to extends the MN1 PMIP session lifetime. > 2.2.1. Currently: PMIPv6 draft requires the MAG to make sure the MN is > attached before sending a re-registration P-BU. > 2.3. At almost the same time or soon after MAG1 sends the > re-registration P-BU2, MN moves to MAG3 and does all access > authentication and all the good stuff that enables MAG2 to send an > initial P-BU3 to update the MN BCE with (P-CoA2 <-> P-HoA1) at LMA1. > 2.4. Not only that, but this scenario requires one of the followings > (P-BU2 is either delayed or lost) and P-BU3 arrives first. > 2.5. I am not saying that this scenario is impossible but it rarely > could happen. But that is fine. > 2.6. When LMA receives P-BU3, LMA clearly can identify that the MN is > moving from MAG1 to MAG2. > > The details of the solution starts here and it will address all > scenarios: > > 3. LMA creates a tentative BCE for MN1 (P-CoA2 <-> P-HoA1) and starts > sending traffic to the new P-CoA2. > 4. If LMA receive the P-BU2 (the one delayed or the retransmitted after > the first lost) within the lifetime of the tentative BCE, LMA does the > following: > > 4.1. LMA rejects the P-BU2 with P-BA2 and code "MN-Handoff-in-Progress" > for example, or we can call it whatever. > 4.2. LMA keeps the traffic pointing to (P-CoA2 <-> P-HoA1) > 4.3. When MAG receives the P-BA2, MAG cancel the MN current > re-registration states and verifies if the MN is still attached before > sending any new P-BU. > 4.4. When the BCE timer expires, LMA replace the old BCE with the > tentative BCE. > > Tentative BCE can be as simple as having a simple timer running. > > > The funny thing is that I heard some people are ok to leave such a > scenario out-of-scope and not document the solution in PMIPv6 draft. I > am not sure why people think that way but it is an opinion. :-( > > This solution should address the race condition that you just > highlighted. > > Best Regards, > Ahmad > >>>> IANA Considerations >>>> =================== >>>> >>>> Don't forget to request the assignment of the P bit in the >> BU and BA >>>> messages in the IANA considerations section. >>> The binding update flags are not maintained by the IANA. >> The respective >>> documents define the flags and their positions. >> OK. >> >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 15:45:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGLD-0006ij-Iu; Tue, 25 Sep 2007 15:45:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGLC-0006NF-7F for netlmm@ietf.org; Tue, 25 Sep 2007 15:45:06 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaGKu-0003F5-3S for netlmm@ietf.org; Tue, 25 Sep 2007 15:44:48 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8PJiht09074; Tue, 25 Sep 2007 19:44:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 14:44:20 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116F66480@zrc2hxm2.corp.nortel.com> In-Reply-To: <46F9607E.5030504@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/qdkuEazVFD2CTXWv0gghtAr1BwAAFJ1A References: <46F848E2.40904@ericsson.com> <46F852A3.1040401@azairenet.com> <46F91662.6030200@ericsson.com> <6FC4416DDE56C44DA0AEE67BC7CA437116F660AB@zrc2hxm2.corp.nortel.com> <46F9607E.5030504@ericsson.com> From: "Ahmad Muhanna" To: "Suresh Krishnan" X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Suresh, I still believe it is the same problem and the same solution is applicable as follows: **** I cut and pasted your scenario and added my comments. ****** At the LMA, as per your scenario, MN has a BCE with the following (P-CoA1 (belongs to MAG1) <-> P-HoA1) 1. M1: MAG2 sends PBU with Timestamp T (This is lost) [Ahmad] Ok. 2. M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA and updates the binding cache on the LMA) [Ahmad] i. Since LMA did not receive M1, M2 is considered a handoff from MAG1 to MAG3. right? ii. LMA will create a tentative BCE with (P-CoA3 <-> P-HoA1). Right? 3. M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at LMA.=20 LMA sees that the timestamp is later than the current one and then replaces the current entry in the Binding Cache) [Ahmad] Ok,=20 i. LMA receive M3 with P-CoA2 and P-HoA1, let us remember that is the content of the P-BU, while tentative BCE is valid. Right? ii. Since tentative BCE for this MN at LMA is still valid with (P-CoA3 <-> P-HoA1), i.e. timer did not expire, LMA recognizes that M3 is happening possibly due to race condition during handoff. =20 iii. LMA rejects M3 with P-BA3 and code "MN-handoff-in-progress". iv. MAG2 receives P-BA3 with code "MN-handoff-in-progress" and realizes that the MN is possibly no longer attached to it. v. MAG2 cancels registration and verifies if the MN is still attached before sending another P-BU. So far, I do not see any problem and it should work just fine.=20 Do you see any problem in the above? Best Regards, Ahmad > >> > >> MN loses connectivity. Regards, Ahmad =20 > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20 > Sent: Tuesday, September 25, 2007 2:25 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Vijay Devarapalli; netlmm@ietf.org > Subject: Re: [netlmm] Suresh's review of=20 > draft-ietf-netlmm-proxymip6-05 >=20 > Hi Ahmad, > I see the problem you are mentioning and is very valid and=20 > I think your solution is a reasonable one for the problem=20 > that you mentioned.=20 > But unfortunately the problem is not the one that I raised in=20 > my comments. The main differences between the scenarios are >=20 > * In my scenario, only one event needs to occur for problems=20 > to occur (Lost PBU only, no re-ordering necessary) > * No BCE was ever created for the MAG whose PBU arrives=20 > second(MAG2). In your scenario MAG1 ONCE HAD a valid BCE. > * In your scenario the problem causing PBU is a refresh PBU=20 > (after lifetime expires) and in mine it is just a=20 > retransmission. Note that there is no requirement for the MAG=20 > to check for MN's attachment before RETRANSMITTING a PBU. >=20 > I think the scenarios are both race conditions, but that is=20 > where the similarity ends. I do not think the same solution=20 > applies to both. Do you agree? >=20 > Cheers > Suresh >=20 > Ahmad Muhanna wrote: > >>>> Section 6.9.3 > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>> " o If Timestamp based scheme is in use, the retransmitted Proxy > >>>> Binding Update messages MUST use the latest timestamp. If > >>>> Sequence number scheme is in use, the retransmitted > >> Proxy Binding > >>>> Update messages MUST use a Sequence Number value > >> greater than that > >>>> used for the previous transmission of this Proxy > >> Binding Update > >>>> message, just as specified in [RFC-3775]." > >>>> > >>>> I completely disagree with this. I think if a PBU is > >> retransmitted it > >>>> MUST use the same timestamp as the first time around.=20 > >> Otherwise we will > >>>> run into ordering problems. > >>> No. It should always use the latest timestamp value.=20 > >> Otherwise the LMA > >>> would not be able to distinguish between a lost Proxy BU being=20 > >>> re-transmitted from a replayed proxy BU. > >> I cannot see how this works. Consider this scenario. > >> > >> MN moves from MAG1 to MAG2 and then to MAG3. > >> > >> M1: MAG2 sends PBU with Timestamp T (This is lost) > >> M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA and=20 > >> updates the binding cache on the LMA) > >> M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at LMA.=20 > >> LMA sees that the timestamp is later than the current one and then=20 > >> replaces the current entry in the Binding Cache) > >> > >> MN loses connectivity. > >=20 > > [Ahmad] > > Hi Suresh, > >=20 > > The scenario you just mentioned is not very much different=20 > than what=20 > > has been discussed before on this mailing list and offline.=20 > Please let=20 > > me summarize this as follows: > >=20 > > 1. This scenario is related to a race condition that has been=20 > > identified a long time ago and a solution has been proposed and=20 > > identified for it but for a reason or another some people does not=20 > > like to document the solution in PMIPv6 draft. > >=20 > > 2. Having said the above, the scenario at hand as you mentioned can=20 > > happen due to a combination of more than two events that=20 > accidentally=20 > > happens at the same time: > >=20 > > 2.1. A MN1 is attached to MAG1 and has a PMIP session with a BCE=20 > > (P-CoA1 <-> P-HoA1) at LMA1. > > 2.2. MN1 PMIP session is about to expire and MAG1 sends a=20 > > re-registration P-BU2 to extends the MN1 PMIP session lifetime. > > 2.2.1. Currently: PMIPv6 draft requires the MAG to make=20 > sure the MN is=20 > > attached before sending a re-registration P-BU. > > 2.3. At almost the same time or soon after MAG1 sends the=20 > > re-registration P-BU2, MN moves to MAG3 and does all access=20 > > authentication and all the good stuff that enables MAG2 to send an=20 > > initial P-BU3 to update the MN BCE with (P-CoA2 <-> P-HoA1) at LMA1. > > 2.4. Not only that, but this scenario requires one of the followings > > (P-BU2 is either delayed or lost) and P-BU3 arrives first. > > 2.5. I am not saying that this scenario is impossible but it rarely=20 > > could happen. But that is fine. > > 2.6. When LMA receives P-BU3, LMA clearly can identify that=20 > the MN is=20 > > moving from MAG1 to MAG2. > >=20 > > The details of the solution starts here and it will address all > > scenarios: > >=20 > > 3. LMA creates a tentative BCE for MN1 (P-CoA2 <-> P-HoA1)=20 > and starts=20 > > sending traffic to the new P-CoA2. > > 4. If LMA receive the P-BU2 (the one delayed or the retransmitted=20 > > after the first lost) within the lifetime of the tentative BCE, LMA=20 > > does the > > following: > >=20 > > 4.1. LMA rejects the P-BU2 with P-BA2 and code=20 > "MN-Handoff-in-Progress" > > for example, or we can call it whatever. > > 4.2. LMA keeps the traffic pointing to (P-CoA2 <-> P-HoA1)=20 > 4.3. When=20 > > MAG receives the P-BA2, MAG cancel the MN current re-registration=20 > > states and verifies if the MN is still attached before=20 > sending any new=20 > > P-BU. > > 4.4. When the BCE timer expires, LMA replace the old BCE with the=20 > > tentative BCE. > >=20 > > Tentative BCE can be as simple as having a simple timer running. > >=20 > >=20 > > The funny thing is that I heard some people are ok to leave such a=20 > > scenario out-of-scope and not document the solution in=20 > PMIPv6 draft. I=20 > > am not sure why people think that way but it is an opinion. :-( > >=20 > > This solution should address the race condition that you just=20 > > highlighted. > >=20 > > Best Regards, > > Ahmad > >=20 > >>>> IANA Considerations > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>> > >>>> Don't forget to request the assignment of the P bit in the > >> BU and BA > >>>> messages in the IANA considerations section. > >>> The binding update flags are not maintained by the IANA.=20 > >> The respective > >>> documents define the flags and their positions. > >> OK. > >> > >> > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 15:53:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGSz-00037h-EJ; Tue, 25 Sep 2007 15:53:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGSy-000376-Cl for netlmm@ietf.org; Tue, 25 Sep 2007 15:53:08 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaGSx-0003Sr-TP for netlmm@ietf.org; Tue, 25 Sep 2007 15:53:08 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l8PK0WKx017672; Tue, 25 Sep 2007 15:00:32 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 14:53:04 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 14:53:04 -0500 Message-ID: <46F966FA.2020609@ericsson.com> Date: Tue, 25 Sep 2007 15:52:26 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 References: <46F848E2.40904@ericsson.com> <46F852A3.1040401@azairenet.com> <46F91662.6030200@ericsson.com> <6FC4416DDE56C44DA0AEE67BC7CA437116F660AB@zrc2hxm2.corp.nortel.com> <46F9607E.5030504@ericsson.com> <6FC4416DDE56C44DA0AEE67BC7CA437116F66480@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116F66480@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2007 19:53:04.0177 (UTC) FILETIME=[AF79D210:01C7FFAD] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, Ahmad Muhanna wrote: > Hi Suresh, > > I still believe it is the same problem and the same solution is > applicable as follows: > > **** I cut and pasted your scenario and added my comments. ****** Thanks a lot for doing this. It makes the discussion easier and more productive. > > At the LMA, as per your scenario, MN has a BCE with the following > (P-CoA1 (belongs to MAG1) <-> P-HoA1) > > 1. M1: MAG2 sends PBU with Timestamp T (This is lost) > [Ahmad] > Ok. > > 2. M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA and > updates the binding cache on the LMA) > [Ahmad] > i. Since LMA did not receive M1, M2 is considered a handoff from MAG1 to > MAG3. right? > ii. LMA will create a tentative BCE with (P-CoA3 <-> P-HoA1). Right? > > 3. M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at LMA. > LMA sees that the timestamp is later than the current one and then > replaces the current entry in the Binding Cache) > > [Ahmad] > Ok, > i. LMA receive M3 with P-CoA2 and P-HoA1, let us remember that is the > content of the P-BU, while tentative BCE is valid. Right? > > ii. Since tentative BCE for this MN at LMA is still valid with (P-CoA3 > <-> P-HoA1), i.e. timer did not expire, LMA recognizes that M3 is > happening possibly due to race condition during handoff. > > iii. LMA rejects M3 with P-BA3 and code "MN-handoff-in-progress". > iv. MAG2 receives P-BA3 with code "MN-handoff-in-progress" and realizes > that the MN is possibly no longer attached to it. > > v. MAG2 cancels registration and verifies if the MN is still attached > before sending another P-BU. > > So far, I do not see any problem and it should work just fine. > > Do you see any problem in the above? Yes, I do see a problem. How do you differentiate the two following cases with the solution you proposed MAG1->MAG2->MAG3 (with MAG2 PBU lost, retransmitted and arriving after MAG3 PBU) -> Your solution detects this correctly and rejects MAG2 PBU and MAG1->MAG3->MAG2 (very quick movement from MAG3->MAG2 all PBUs arrive in order) -> Your solution detects this incorrectly and rejects the valid MAG2 PBU Thanks Suresh _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 16:23:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGvN-0003B3-Jt; Tue, 25 Sep 2007 16:22:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaGvM-0003Aq-39 for netlmm@ietf.org; Tue, 25 Sep 2007 16:22:28 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaGvF-0000lu-Nb for netlmm@ietf.org; Tue, 25 Sep 2007 16:22:28 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 13:22:15 -0700 Message-ID: <46F96DF7.1000702@azairenet.com> Date: Tue, 25 Sep 2007 13:22:15 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2007 20:22:15.0313 (UTC) FILETIME=[C33BF810:01C7FFB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, I am responding to the major comments you have. Narayanan, Vidya wrote: > Technical - Major: > ================== > > - Terminology: Proxy-CoA and MN-HoA: > > As I've mentioned before, this terminology continues to be confusing, > especially, when we talk about PMIP6 and MIP6 together. Given that an > MN is called an MN in the MIP6 case, tagging "MN" before the HoA is not > making it any more descriptive to the PMIP6 use. I've stated my > concerns with these terms before and I know the authors had a strong > preference to keeping this terminology, but, I'd strongly urge some > re-thinking here to avoid confusion to the end users of the protocol. I don't think we should open the terminology issue again. We had extensive discussions on this in the past and concluded on the current terms. As long as the terminology section clearly describes what each term means, it should be fine. > - MN Identifier: > > Page 15 (and other parts of the document) talks about getting the MN ID > from the NAI option. Isn't NAI just one allowed type of identity? A > particular deployment may use other types of identities, the only > requirement being a unique identity that can be stable within the PMIP > domain. That is correct. We do all allow other forms of the identities. We are using the option defined in RFC 4283. In this option, the sub-type when set to 1, indicates that it is the NAI. Other sub-types would be used to identify other identities. > - Unauthorized PBUs: > > What is the purpose of sending an error code in a PBA for an > unauthorized PBU? I would imagine that unauthorized PBUs are better > silently discarded. Are you talking about the "MAG_NOT_AUTHORIZED_FOR_PROXY_REG" error code? It can be argued that sending error codes is better than silently dropping messages for debugging purposes. > - Prefix allocation and multihomed MNs: > > The first bullet on page 18 states that the LMA "MUST ensure the > allocated prefix is not in use by any other mobile node". In the > context of regular IP nodes that are multihomed, we discussed how it is > problematic when the same prefix/address is allocated to multiple > interfaces of the same node. To prevent that problem, are we assuming > that every distinct interface of an MN attached to the PMIP domain has a > different unique identity? If so, that needs to be stated. IMO, that > may not be practical, especially, if an NAI is used as the MN ID. So, > in those cases, we really need to ensure that the LMA is not allocating > the same prefix to multiple interfaces of a multihomed MN. I think an > appropriate rewording of this sentence may be something like "the LMA > MUST ensure the allocated prefix is not already in use, i.e., there is > no existing BCE for that prefix on the LMA". > > I also recall that the document is supposed to state that the protocol > does not support multihomed MNs more generically, but, I couldn't find > such text. Did I miss it? The conclusion from that thread was the multi-homing is out of scope for the base PMIPv6 spec and not supported in the base PMIPv6 document. I had proposed some text at that time. We never concluded on that. > - Page 18, Binding De-registration: > > If the LMA may accept or ignore a PBU sent with a source address > different from the Proxy-CoA, what is that test needed for? Are there > any examples of cases where the LMA behavior would be one or the other? > And, why is the source address relevant for a de-registration alone and > not for other PBUs? The emphasis is on ignore the de-registration proxy BU or responding to the old MAG with status 0. It was added to address one specific case - if the de-registration proxy BU from the old MAG is received after the proxy BU from the new MAG, the LMA is supposed to ignore the de-registration BU (but still respond to the old MAG with status 0). I read the text, perhaps it would better to say the LMA always responds to the deregistration proxy BU (without deleting the binding cache entry). Not ignore it. If the LMA ignores it, the old MAG would only re-transmit the deregistration proxy BU. > - MinDelayBeforeBCEDelete Timer: > > I understand where this timer is coming from, but, I'm not sure I > understand the behavior of the LMA fully when that timer is running. > For instance, when that timer is active, what happens to any data > received by the LMA for that MN? If that is sent to the CoA in the BCE, > that is of no use. If that data is dropped, then, it is equivalent to > not having a BCE for that MN. So, I'm not exactly sure what that timer > is achieving, other than avoiding giving up the HNP too soon. If that > is the only intent, then, I'd word it as such and not say that the BCE > is active. Otherwise, the processing of data packets during that > interval needs to be better defined. This was added to make sure the LMA does not release the home address/home network prefix for the mobile node during handovers. Lets say the old MAG has already de-registered, but the Proxy BU from the new MAG has not reached the LMA yet. If the LMA deletes the binding cache entry it might result in release of the home address/home network prefix. This was discussed on the mailing list. > - NAI option in the PBA: > > Why is it needed? To match the proxy Binding Ack to the proxy BU. The MAG could be sending proxy BUs for quite a few mobile nodes. > - Section 6.2, MN Policy Profile: > > I'm not sure why this is mandatory. For e.g., if a network has a policy > to dynamically acquire an identity for the MN and assign an available > HNP to that MN, it is not tied to "policy" in any way. Also, when a > policy profile is present, why is the LMA address a mandatory field in > it? That seems to be one way of obtaining the LMA address, but, there > can be other ways. We don't mandate a policy profile. If a policy profile is used, then we say what needs to go into it and mandate that the MAG and the LMA should have access to it. > - Creating RAs at the MAG: > > How does the MAG obtain the parameters other than the prefix needed for > the RA? For instance, the flags or other options that need to be sent? > Section 6.4 vaguely mentions based on policy, but, I don't think that is > good enough. I think we need to have at least one mode of obtaining > that information specified as normative for implementation purposes. There are two pieces of information that the MAG needs to figure out. Prefix lifetime and the flags that indicate auto-configuration/DHCPv6. For the prefix lifetime, it would be MAG implementation specific. The MAG would know whether auto-configuration or DHCPv6 is being used. So it can set the flags accordingly. Sri, please correct me if I am wrong. > - Section 6.6, first bullet: > > I don't understand what it means for the MAG to authenticate the MN > based on an identifier. It is not the role of the MAG to authenticate > the MN and it is really irrelevant to the PMIP6 protocol. If the MAG > acquires the identity of an MN that has been allowed to access the > system (presumably with or without some access authentication), it must > use that identity for PMIP6. Other than that, I don't quite understand > the MUSTs in this bullet. I agree, we need to fix the text here. The intention was not to mandate the MAG to authenticate the MN all the time. But the MAG must acquire the identifier somehow. It needs to include the identifier in the proxy BU. > - Page 35, Timestamp values in retransmitted PBUs: > > As Suresh said, I don't think the timestamp needs to be updated in a > retransmitted PBU. The timestamps are used for ordering, not replay > protection here. Replay protection is provided by the IPsec SA (and > must be provided by any other authentication mechanism in use). Having > said that, it is typically easier for retransmissions to not have to > alter the packet being sent. Plus, that will help the LMA be idempotent > and just respond with the previously sent PBA (if there was one). In > general, this is better to handle DoS attacks too. Lets follow up on that thread for this issue. > - Section 6.11, DHCP Relay Agent: > > This section seems weak. Based on list discussions, there probably is > already a plan to elaborate on the role of the MAG as a relay agent. Any suggestions on improving it? :) I thought it is quite detailed. It was based on the discussions we have had so far on the use of DHCPv6. > - Section 6.13, last bullet: > > I'm not sure if absence of data from the MN is an adequate enough > indication of MN detachment. If we were to say that, it should read > "absence of data to/from the MN", since the MN may just be receiving > data and not sending anything. But, also, it is not clear what a > "certain duration of time" is, since we don't want the MN to be > deregistered while it is in idle mode, for instance. I agree. The last bullet should be removed. > - Security considerations: Authorization of MAGs: > > It is fine to have the method of authorizing a MAG be out of scope for > the specification itself, but, I think we need to give some hints on > what that means in the security considerations section. For instance, > it could be about that particular MAG just having an IPsec SA with that > LMA or it could be something more like that MAG being part of the > defined PMIPv6 domain and the corresponding MN-HoA belonging to that > domain, etc. Agreed. Any text? Otherwise I will come up with some text. > - Security considerations: MAG Compromise: > > Similar comment to the one above. I think we need a bit more detail on > ensuring the MN is "definitively attached" to the MAG that sent the PBU. > For instance, it could be a AAA check upon reception of a PBU (the > document alludes to this somewhere), it could be a CGA signature of the > MN carried from an secure RS, in the PBU (this needs more thinking), > etc. Again, it is fine that this document doesn't define anything > normative here, but, the security considerations as written is hand > waving this point. We went back and forth on this. Some folks wanted to add hints to specific mechanisms and others wanted to leave this out of scope. The LMA checking with the AAA to see if the MN is attached to the MAG is a solution. But this relies on the AAA infrastructure being used. I think this is best left for other documents. Any suggestions on what "detail" we can add? Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 16:35:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaH81-00034y-8g; Tue, 25 Sep 2007 16:35:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaH7y-0002zF-MF for netlmm@ietf.org; Tue, 25 Sep 2007 16:35:31 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaH7m-0004eo-3Z for netlmm@ietf.org; Tue, 25 Sep 2007 16:35:18 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8PKZCt26124; Tue, 25 Sep 2007 20:35:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 15:34:28 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116F6666D@zrc2hxm2.corp.nortel.com> In-Reply-To: <46F96DF7.1000702@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/sqYa/mYIQM/cRGmTv0sTxkKSVwAAAwGw References: <46F96DF7.1000702@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Narayanan, Vidya" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org One comment below. > Subject: Re: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 >=20 > Hi Vidya, >=20 > I am responding to the major comments you have. >=20 > Narayanan, Vidya wrote: >=20 > > Technical - Major:=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > - Terminology: Proxy-CoA and MN-HoA:=20 > >=20 > > As I've mentioned before, this terminology continues to be=20 > confusing,=20 > > especially, when we talk about PMIP6 and MIP6 together. =20 > Given that an=20 > > MN is called an MN in the MIP6 case, tagging "MN" before the HoA is=20 > > not making it any more descriptive to the PMIP6 use. I've=20 > stated my=20 > > concerns with these terms before and I know the authors had=20 > a strong=20 > > preference to keeping this terminology, but, I'd strongly urge some=20 > > re-thinking here to avoid confusion to the end users of the=20 > protocol. >=20 > I don't think we should open the terminology issue again. We=20 > had extensive discussions on this in the past and concluded=20 > on the current terms. As long as the terminology section=20 > clearly describes what each term means, it should be fine. [Ahmad] I second this.=20 I may also add that people already got used to these terminology and we should not try to open this again. Regards, Ahmad >=20 > > - MN Identifier:=20 > >=20 > > Page 15 (and other parts of the document) talks about=20 > getting the MN=20 > > ID from the NAI option. Isn't NAI just one allowed type of=20 > identity? =20 > > A particular deployment may use other types of identities, the only=20 > > requirement being a unique identity that can be stable=20 > within the PMIP=20 > > domain. >=20 > That is correct. We do all allow other forms of the=20 > identities. We are using the option defined in RFC 4283. In=20 > this option, the sub-type when set to 1, indicates that it is=20 > the NAI. Other sub-types would be used to identify other identities. >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 18:03:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIVN-0001kl-Iw; Tue, 25 Sep 2007 18:03:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIVM-0001kg-Jf for netlmm@ietf.org; Tue, 25 Sep 2007 18:03:44 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaIVL-0003kV-Cq for netlmm@ietf.org; Tue, 25 Sep 2007 18:03:44 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 15:03:42 -0700 Message-ID: <46F985BE.3030108@azairenet.com> Date: Tue, 25 Sep 2007 15:03:42 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan Subject: Re: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 References: <46F848E2.40904@ericsson.com> <46F852A3.1040401@azairenet.com> <46F91662.6030200@ericsson.com> In-Reply-To: <46F91662.6030200@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Sep 2007 22:03:42.0165 (UTC) FILETIME=[EF47E050:01C7FFBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Suresh Krishnan wrote: >>> Link Local address of MAG >>> ========================= >>> When an MN moves from one link to another how does it switch default >>> routers to the new MAG. The link local addresses of the old MAG and the >>> new MAG will most likely be different and hence unless nud removes the >>> old mag the mn will try to reach it even after handover. Or it is >>> assumed that all the MAGs will have the same LL address? Is this is an >>> assumption, it needs to be stated. >> >> It is assumed that the same link local address is used for a >> particular mobile node across all MAGs. This is stored at the LMA and >> retrieved by the new MAG. This is described in the document. > > I was talking about the LL address of the MAG (not the MN). I was talking about that too. :) But I guess my earlier reply was a bit confusing. I was trying to say that the same link local address for the MAGs is used as the MN moves across the PMIPv6 domain. >>> P flag >>> ====== >>> >>> I do not see any text in the expected LMA behavior to CHECK for the >>> presence of the P flag in the received BU. I think this should be added. >> >> hmmm.... the LMA uses the 'P' flag to recognize that it is a proxy >> binding update from a MAG. Otherwise the LMA assumes it is a MIPv6 >> binding update from a MIPv6 mobile node. So the LMA checks for the 'P' >> flag all the time. > > I know it. You know it. But it is not in the document :-). A simple note > in section 5.3 would do. > > "o If the P flag is not set in the Proxy Binding Update request, > the local mobility anchor MUST discard the Proxy Binding Update > and log an error. " No. If you have a MIPv6 HA/LMA functionalities co-located, the MIPv6 HA would still process the BU assuming it is a regular BU. >>> Section 5.3: Binding De-registration >>> ==================================== >>> "Upon accepting the Proxy Binding Update request for a mobile node, >>> with the lifetime value of zero, the local mobility anchor MUST >>> wait for MinDelayBeforeBCEDelete amount of time, before it deletes >>> the mobile node's Binding Cache entry." >>> >>> What is the purpose for having a timer to delete a BCE? I see no reason >>> at all in waiting. If this is being done to prevent considering a >>> following BU as an initial registration ( I suspect this is the case) >>> please extend the conceptual data structure to add a deleted flag >>> instead of using a timer. >> >> This is to make sure you don't release the home address/home network >> prefix as soon as a MAG de-registers. The proxy binding update from >> the new MAG may have been delayed. > > What happens to the data that is received in this time period? Dropped or buffered. It would depend on the LMA implementation. >>> Section 6.9.3 >>> ============= >>> " o If Timestamp based scheme is in use, the retransmitted Proxy >>> Binding Update messages MUST use the latest timestamp. If >>> Sequence number scheme is in use, the retransmitted Proxy Binding >>> Update messages MUST use a Sequence Number value greater than that >>> used for the previous transmission of this Proxy Binding Update >>> message, just as specified in [RFC-3775]." >>> >>> I completely disagree with this. I think if a PBU is retransmitted it >>> MUST use the same timestamp as the first time around. Otherwise we will >>> run into ordering problems. >> >> No. It should always use the latest timestamp value. Otherwise the LMA >> would not be able to distinguish between a lost Proxy BU being >> re-transmitted from a replayed proxy BU. > > I cannot see how this works. Consider this scenario. > > MN moves from MAG1 to MAG2 and then to MAG3. > > M1: MAG2 sends PBU with Timestamp T (This is lost) > M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA and updates > the binding cache on the LMA) > M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives at LMA. LMA > sees that the timestamp is later than the current one and then replaces > the current entry in the Binding Cache) MAG2 is supposed to check if the MN is still attached to it before re-transmitting the Proxy BU. IMO, using the registration revocation mechanism for PMIPv6 might be the cleanest approach. Any loss of connectivity is likely to be temporary once we have the registration revocation mechanism for PMIPv6. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 18:22:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaInS-0006qX-O0; Tue, 25 Sep 2007 18:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaInR-0006nb-8n for netlmm@ietf.org; Tue, 25 Sep 2007 18:22:25 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaInL-0004DM-3b for netlmm@ietf.org; Tue, 25 Sep 2007 18:22:25 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8PMM1A16561; Tue, 25 Sep 2007 22:22:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 17:21:34 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116F669B2@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/T/RrZEqQFEePT3u9QfI2QIenQAAcXPfQ References: From: "Ahmad Muhanna" To: "Narayanan, Vidya" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, Please find one comment below. Regards, Ahmad =20 >=20 > - NAI option in the PBA:=20 >=20 > Why is it needed? [Ahmad] There is a very good reason to have NAI in the P-BA. In case that we have SQN used for ordering the P-BU/P-BA, there is a great possibility of SQN collision. In this case, MAG needs the NAI to match the P-BA to the outstanding P-BU. Regards, Ahmad >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 18:49:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJDs-0002F4-SZ; Tue, 25 Sep 2007 18:49:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJDr-0002Dc-Dx for netlmm@ietf.org; Tue, 25 Sep 2007 18:49:43 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaJDm-0004rx-7Y for netlmm@ietf.org; Tue, 25 Sep 2007 18:49:43 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8PMnJt26877; Tue, 25 Sep 2007 22:49:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 17:48:05 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116F66A21@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/T/RrZEqQFEePT3u9QfI2QIenQAAcoxsQ References: From: "Ahmad Muhanna" To: "Narayanan, Vidya" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, Please find one more comment below. Regards, Ahmad =20 >=20 > - Security considerations: Authorization of MAGs:=20 >=20 > It is fine to have the method of authorizing a MAG be out of=20 > scope for the specification itself, but, I think we need to=20 > give some hints on what that means in the security=20 > considerations section. For instance, it could be about that=20 > particular MAG just having an IPsec SA with that LMA or it=20 > could be something more like that MAG being part of the=20 > defined PMIPv6 domain and the corresponding MN-HoA belonging=20 > to that domain, etc. =20 >=20 > - Security considerations: MAG Compromise:=20 >=20 > Similar comment to the one above. I think we need a bit more=20 > detail on ensuring the MN is "definitively attached" to the=20 > MAG that sent the PBU. > For instance, it could be a AAA check upon reception of a PBU=20 > (the document alludes to this somewhere), it could be a CGA=20 > signature of the MN carried from an secure RS, in the PBU=20 > (this needs more thinking), etc. Again, it is fine that this=20 > document doesn't define anything normative here, but, the=20 > security considerations as written is hand waving this point.=20 >=20 [Ahmad] As long as this is already documented out-of-scope, I do not see a need to go into the details of any solution.=20 The issue here is how much is too much vs. too little. If the functionality is out-of-scope, then there is no point of getting into unnecessary details that does not describe a full deployable solution anyway. IMO, it is more destructive, for example, to document a very high level idea as a solution. I am under the impression that all of us are for getting this base PMIPv6 protocol moves to IESG as soon as possible. In order to spend our time in defining out-of-scope functionalities, I would guess the authors will still be busy publishing new revisions a year from today:-( =20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 21:35:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaLoH-0001e5-5J; Tue, 25 Sep 2007 21:35:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaLoG-0001dy-3o for netlmm@ietf.org; Tue, 25 Sep 2007 21:35:28 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaLoE-0004dY-Fl for netlmm@ietf.org; Tue, 25 Sep 2007 21:35:28 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8Q1ZN4n030611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Sep 2007 18:35:23 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8Q1ZMSQ008506; Tue, 25 Sep 2007 18:35:22 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 18:35:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 18:35:21 -0700 Message-ID: In-Reply-To: <46F96DF7.1000702@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/sdrXSWxVJRmzQ6G5BsvD3b9qQQAKS7Sg References: <46F96DF7.1000702@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 26 Sep 2007 01:35:22.0594 (UTC) FILETIME=[81538C20:01C7FFDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vijay,=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com]=20 > Sent: Tuesday, September 25, 2007 1:22 PM > To: Narayanan, Vidya > Cc: netlmm@ietf.org > Subject: Re: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 >=20 > Hi Vidya, >=20 > I am responding to the major comments you have. >=20 > Narayanan, Vidya wrote: >=20 > > Technical - Major:=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > - Terminology: Proxy-CoA and MN-HoA:=20 > >=20 > > As I've mentioned before, this terminology continues to be=20 > confusing,=20 > > especially, when we talk about PMIP6 and MIP6 together. =20 > Given that an=20 > > MN is called an MN in the MIP6 case, tagging "MN" before the HoA is=20 > > not making it any more descriptive to the PMIP6 use. I've=20 > stated my=20 > > concerns with these terms before and I know the authors had=20 > a strong=20 > > preference to keeping this terminology, but, I'd strongly urge some=20 > > re-thinking here to avoid confusion to the end users of the=20 > protocol. >=20 > I don't think we should open the terminology issue again. We=20 > had extensive discussions on this in the past and concluded=20 > on the current terms. As long as the terminology section=20 > clearly describes what each term means, it should be fine. >=20 I don't really want a prolonged discussion on this topic again. All the points have been made. The only point I'll note is that we never really had a conclusion or clear consensus. There were several logical points made on why the current terms are not appropriate or clear, but, no conclusions.=20 > > - MN Identifier:=20 > >=20 > > Page 15 (and other parts of the document) talks about=20 > getting the MN=20 > > ID from the NAI option. Isn't NAI just one allowed type of=20 > identity? =20 > > A particular deployment may use other types of identities, the only=20 > > requirement being a unique identity that can be stable=20 > within the PMIP=20 > > domain. >=20 > That is correct. We do all allow other forms of the=20 > identities. We are using the option defined in RFC 4283. In=20 > this option, the sub-type when set to 1, indicates that it is=20 > the NAI. Other sub-types would be used to identify other identities. >=20 I think the document just needs to be cleaned up on where it refers to the NAI. At the moment, it is misleading, since it uses the term "NAI option" in multiple places and gives the impression that we are referring to only an NAI as an MN ID. =20 > > - Unauthorized PBUs:=20 > >=20 > > What is the purpose of sending an error code in a PBA for an=20 > > unauthorized PBU? I would imagine that unauthorized PBUs=20 > are better=20 > > silently discarded. >=20 > Are you talking about the "MAG_NOT_AUTHORIZED_FOR_PROXY_REG"=20 > error code?=20 > It can be argued that sending error codes is better than=20 > silently dropping messages for debugging purposes. >=20 It is true that error messages aid debugging. However, the errors could be locally logged for debugging purposes. The problem with sending these messages that you make the LMA an oracle for DoS attacks.=20 > > - Prefix allocation and multihomed MNs:=20 > >=20 > > The first bullet on page 18 states that the LMA "MUST ensure the=20 > > allocated prefix is not in use by any other mobile node". In the=20 > > context of regular IP nodes that are multihomed, we=20 > discussed how it=20 > > is problematic when the same prefix/address is allocated to=20 > multiple=20 > > interfaces of the same node. To prevent that problem, are=20 > we assuming=20 > > that every distinct interface of an MN attached to the PMIP=20 > domain has=20 > > a different unique identity? If so, that needs to be stated. IMO,=20 > > that may not be practical, especially, if an NAI is used as=20 > the MN ID. =20 > > So, in those cases, we really need to ensure that the LMA is not=20 > > allocating the same prefix to multiple interfaces of a=20 > multihomed MN. =20 > > I think an appropriate rewording of this sentence may be something=20 > > like "the LMA MUST ensure the allocated prefix is not=20 > already in use,=20 > > i.e., there is no existing BCE for that prefix on the LMA". > >=20 > > I also recall that the document is supposed to state that=20 > the protocol=20 > > does not support multihomed MNs more generically, but, I=20 > couldn't find=20 > > such text. Did I miss it? >=20 > The conclusion from that thread was the multi-homing is out=20 > of scope for the base PMIPv6 spec and not supported in the=20 > base PMIPv6 document. I had proposed some text at that time.=20 > We never concluded on that. >=20 This needs a conclusion. I'll start a separate thread on this topic.=20 > > - Page 18, Binding De-registration:=20 > >=20 > > If the LMA may accept or ignore a PBU sent with a source address=20 > > different from the Proxy-CoA, what is that test needed for?=20 > Are there=20 > > any examples of cases where the LMA behavior would be one=20 > or the other? > > And, why is the source address relevant for a de-registration alone=20 > > and not for other PBUs? >=20 > The emphasis is on ignore the de-registration proxy BU or=20 > responding to the old MAG with status 0. It was added to=20 > address one specific case - if the de-registration proxy BU=20 > from the old MAG is received after the proxy BU from the new=20 > MAG, the LMA is supposed to ignore the de-registration BU=20 > (but still respond to the old MAG with status 0). >=20 > I read the text, perhaps it would better to say the LMA=20 > always responds to the deregistration proxy BU (without=20 > deleting the binding cache entry). Not ignore it. If the LMA=20 > ignores it, the old MAG would only re-transmit the=20 > deregistration proxy BU. >=20 Okay. That revision sounds more appropriate.=20 > > - MinDelayBeforeBCEDelete Timer:=20 > >=20 > > I understand where this timer is coming from, but, I'm not sure I=20 > > understand the behavior of the LMA fully when that timer is running. > > For instance, when that timer is active, what happens to any data=20 > > received by the LMA for that MN? If that is sent to the CoA in the=20 > > BCE, that is of no use. If that data is dropped, then, it is=20 > > equivalent to not having a BCE for that MN. So, I'm not=20 > exactly sure=20 > > what that timer is achieving, other than avoiding giving up the HNP=20 > > too soon. If that is the only intent, then, I'd word it as=20 > such and=20 > > not say that the BCE is active. Otherwise, the processing of data=20 > > packets during that interval needs to be better defined. >=20 > This was added to make sure the LMA does not release the home=20 > address/home network prefix for the mobile node during=20 > handovers. Lets say the old MAG has already de-registered,=20 > but the Proxy BU from the new MAG has not reached the LMA=20 > yet. If the LMA deletes the binding cache entry it might=20 > result in release of the home address/home network prefix.=20 > This was discussed on the mailing list. >=20 Yes, I think my paragraph captured this part. The point I'm making is that you are really trying to avoid releasing the HNP and not really keeping the binding active when this timer is running. If the binding was active, you'd need to describe what happens to data packets sent/received from/to the MN during that time interval. I'd say that the binding isn't available and hence, data will be dropped, but, the HNP is not immediately released. =20 > > - NAI option in the PBA:=20 > >=20 > > Why is it needed?=20 >=20 > To match the proxy Binding Ack to the proxy BU. The MAG could=20 > be sending proxy BUs for quite a few mobile nodes. >=20 The sequence number and timestamp are both indicated as providing this matching capability. I don't think we need a third mechanism. In fact, I was going to include a comment that says we need to pick one to match requests and responses - and that could easily be the sequence number (treated as a message ID in this case).=20 > > - Section 6.2, MN Policy Profile: > >=20 > > I'm not sure why this is mandatory. For e.g., if a network has a=20 > > policy to dynamically acquire an identity for the MN and assign an=20 > > available HNP to that MN, it is not tied to "policy" in any way. =20 > > Also, when a policy profile is present, why is the LMA address a=20 > > mandatory field in it? That seems to be one way of=20 > obtaining the LMA=20 > > address, but, there can be other ways. >=20 > We don't mandate a policy profile. If a policy profile is=20 > used, then we say what needs to go into it and mandate that=20 > the MAG and the LMA should have access to it. >=20 The text doesn't seem to read that way, at least to me.=20 > > - Creating RAs at the MAG:=20 > >=20 > > How does the MAG obtain the parameters other than the prefix needed=20 > > for the RA? For instance, the flags or other options that=20 > need to be sent? > > Section 6.4 vaguely mentions based on policy, but, I don't=20 > think that=20 > > is good enough. I think we need to have at least one mode of=20 > > obtaining that information specified as normative for=20 > implementation purposes. >=20 > There are two pieces of information that the MAG needs to figure out.=20 > Prefix lifetime and the flags that indicate=20 > auto-configuration/DHCPv6.=20 > For the prefix lifetime, it would be MAG implementation=20 > specific. The MAG would know whether auto-configuration or=20 > DHCPv6 is being used. So it can set the flags accordingly. >=20 Yes, the M and O flags are part of the information and so is the prefix lifetime. But, is there a default router lifetime option? Any other option that may need to be sent in the RA? In general, I think it would be good to describe how the MAG knows this stuff.=20 > Sri, please correct me if I am wrong. >=20 > > - Section 6.6, first bullet:=20 > >=20 > > I don't understand what it means for the MAG to authenticate the MN=20 > > based on an identifier. It is not the role of the MAG to=20 > authenticate=20 > > the MN and it is really irrelevant to the PMIP6 protocol. =20 > If the MAG=20 > > acquires the identity of an MN that has been allowed to access the=20 > > system (presumably with or without some access authentication), it=20 > > must use that identity for PMIP6. Other than that, I don't quite=20 > > understand the MUSTs in this bullet. >=20 > I agree, we need to fix the text here. The intention was not=20 > to mandate the MAG to authenticate the MN all the time. But=20 > the MAG must acquire the identifier somehow. It needs to=20 > include the identifier in the proxy BU. >=20 Okay.=20 > > - Page 35, Timestamp values in retransmitted PBUs:=20 > >=20 > > As Suresh said, I don't think the timestamp needs to be=20 > updated in a=20 > > retransmitted PBU. The timestamps are used for ordering,=20 > not replay=20 > > protection here. Replay protection is provided by the=20 > IPsec SA (and=20 > > must be provided by any other authentication mechanism in use). =20 > > Having said that, it is typically easier for retransmissions to not=20 > > have to alter the packet being sent. Plus, that will help=20 > the LMA be=20 > > idempotent and just respond with the previously sent PBA=20 > (if there was=20 > > one). In general, this is better to handle DoS attacks too. >=20 > Lets follow up on that thread for this issue. >=20 > > - Section 6.11, DHCP Relay Agent:=20 > >=20 > > This section seems weak. Based on list discussions, there=20 > probably is=20 > > already a plan to elaborate on the role of the MAG as a relay agent. >=20 > Any suggestions on improving it? :) I thought it is quite=20 > detailed. It was based on the discussions we have had so far=20 > on the use of DHCPv6. >=20 At least the 05 version of the draft had 2 sentences on DHCP Relay Agents and made no mention of the MAG's role in it. Perhaps the 06 version has more detail? =20 > > - Section 6.13, last bullet:=20 > >=20 > > I'm not sure if absence of data from the MN is an adequate enough=20 > > indication of MN detachment. If we were to say that, it=20 > should read=20 > > "absence of data to/from the MN", since the MN may just be=20 > receiving=20 > > data and not sending anything. But, also, it is not clear what a=20 > > "certain duration of time" is, since we don't want the MN to be=20 > > deregistered while it is in idle mode, for instance. >=20 > I agree. The last bullet should be removed. >=20 Okay.=20 > > - Security considerations: Authorization of MAGs:=20 > >=20 > > It is fine to have the method of authorizing a MAG be out=20 > of scope for=20 > > the specification itself, but, I think we need to give some=20 > hints on=20 > > what that means in the security considerations section. =20 > For instance,=20 > > it could be about that particular MAG just having an IPsec SA with=20 > > that LMA or it could be something more like that MAG being=20 > part of the=20 > > defined PMIPv6 domain and the corresponding MN-HoA=20 > belonging to that=20 > > domain, etc. >=20 > Agreed. Any text? Otherwise I will come up with some text. >=20 Please suggest text :)=20 > > - Security considerations: MAG Compromise:=20 > >=20 > > Similar comment to the one above. I think we need a bit=20 > more detail=20 > > on ensuring the MN is "definitively attached" to the MAG=20 > that sent the PBU. > > For instance, it could be a AAA check upon reception of a PBU (the=20 > > document alludes to this somewhere), it could be a CGA signature of=20 > > the MN carried from an secure RS, in the PBU (this needs more=20 > > thinking), etc. Again, it is fine that this document=20 > doesn't define=20 > > anything normative here, but, the security considerations=20 > as written=20 > > is hand waving this point. >=20 > We went back and forth on this. Some folks wanted to add=20 > hints to specific mechanisms and others wanted to leave this=20 > out of scope. The LMA checking with the AAA to see if the MN=20 > is attached to the MAG is a solution. But this relies on the=20 > AAA infrastructure being used. I think this is best left for=20 > other documents. Any suggestions on what "detail"=20 > we can add? >=20 If we claim this is an issue in the security considerations section and claim that the fix to it is for the LMA to ensure the MN is actually attached to the MAG, we can't quite hand wave on some possible ways to do that. Those are just hints for deployments that are concerned about MAG compromise. But, those hints need to be captured in the security considerations section. The threats document captures this threat and it is a valid one - so, I believe we need some text here. The type of "detail" is what I tried to provide with the examples on AAA checks or CGA signatures - and, I don't think we need a lot of detail here; a few sentences would be good.=20 Thanks, Vidya > Vijay >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 21:38:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaLrQ-0006lY-GC; Tue, 25 Sep 2007 21:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaLrP-0006lM-Kb for netlmm@ietf.org; Tue, 25 Sep 2007 21:38:43 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaLrK-0000ru-92 for netlmm@ietf.org; Tue, 25 Sep 2007 21:38:43 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8Q1cRoc030767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Sep 2007 18:38:27 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8Q1cQnu000767; Tue, 25 Sep 2007 18:38:26 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 18:38:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 18:38:25 -0700 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116F669B2@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/T/RrZEqQFEePT3u9QfI2QIenQAAcXPfQAAcW7+A= References: <6FC4416DDE56C44DA0AEE67BC7CA437116F669B2@zrc2hxm2.corp.nortel.com> From: "Narayanan, Vidya" To: "Ahmad Muhanna" , X-OriginalArrivalTime: 26 Sep 2007 01:38:26.0002 (UTC) FILETIME=[EEA56320:01C7FFDD] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad,=20 > > - NAI option in the PBA:=20 > >=20 > > Why is it needed? >=20 > [Ahmad] > There is a very good reason to have NAI in the P-BA. >=20 > In case that we have SQN used for ordering the P-BU/P-BA,=20 > there is a great possibility of SQN collision. In this case,=20 > MAG needs the NAI to match the P-BA to the outstanding P-BU. >=20 Hmmm.. In this case, I can see the use in including the MN ID in the first PBA, but, subsequently, the HNP should be sufficient to match it to the MN in the PBU and PBA, right?=20 Vidya > Regards, > Ahmad >=20 > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 21:50:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaM2r-00019J-DC; Tue, 25 Sep 2007 21:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaM2p-000145-PG for netlmm@ietf.org; Tue, 25 Sep 2007 21:50:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaM2j-00016s-GY for netlmm@ietf.org; Tue, 25 Sep 2007 21:50:26 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8Q1oFsE031464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Sep 2007 18:50:15 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8Q1oEMm000712 for ; Tue, 25 Sep 2007 18:50:14 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 18:50:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Sep 2007 18:50:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpw== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 26 Sep 2007 01:50:14.0689 (UTC) FILETIME=[950E7110:01C7FFDF] X-Spam-Score: -4.0 (----) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [netlmm] Issue: Prefix allocation and multihomed MNs X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Just taking this one up on a separate thread. Here is the discussion from me and Vijay:=20 "Vidya:=20 > - Prefix allocation and multihomed MNs:=20 >=20 > The first bullet on page 18 states that the LMA "MUST ensure the=20 > allocated prefix is not in use by any other mobile node". In the=20 > context of regular IP nodes that are multihomed, we discussed how it=20 > is problematic when the same prefix/address is allocated to multiple=20 > interfaces of the same node. To prevent that problem, are we assuming > that every distinct interface of an MN attached to the PMIP domain has > a different unique identity? If so, that needs to be stated. IMO,=20 > that may not be practical, especially, if an NAI is used as the MN ID. > So, in those cases, we really need to ensure that the LMA is not=20 > allocating the same prefix to multiple interfaces of a multihomed MN. > I think an appropriate rewording of this sentence may be something=20 > like "the LMA MUST ensure the allocated prefix is not already in use,=20 > i.e., there is no existing BCE for that prefix on the LMA". >=20 > I also recall that the document is supposed to state that the protocol > does not support multihomed MNs more generically, but, I couldn't find > such text. Did I miss it? Vijay:=20 The conclusion from that thread was the multi-homing is out of scope for the base PMIPv6 spec and not supported in the base PMIPv6 document. I had proposed some text at that time. We never concluded on that." We need to conclude this issue. The tracker somehow shows this issue as "closed" (issue #166 on the tracker) and I'm not sure why. Other than stating that multihoming is out of scope, we need to state one of the following two things:=20 - that PMIP is only intended for networks that have control over the types of IP devices attaching to their networks and the burden is on the administrators/network designers to ensure that multihomed IP devices are not attaching using more than one interface to the same PMIP6 domain (this is not the option I recommend) (OR) - define LMA behavior such that regular multihomed IP devices don't run into issues of connectivity or shutting down interfaces. This is much more logical in my view and it is not a big change in the document.=20 Thanks, Vidya=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 21:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaM7E-0007lp-Ap; Tue, 25 Sep 2007 21:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaM7D-0007fE-Cz for netlmm@ietf.org; Tue, 25 Sep 2007 21:55:03 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaM77-0001Ct-4Z for netlmm@ietf.org; Tue, 25 Sep 2007 21:55:03 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8Q1scYa014860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Sep 2007 18:54:39 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8Q1sbwx011741; Tue, 25 Sep 2007 18:54:38 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 18:54:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Sep 2007 18:54:37 -0700 Message-ID: In-Reply-To: <46F985BE.3030108@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue: Retransmissions and timestamps Thread-Index: Acf/wl8f1YfuWj3kSVuieUs1PtuEowAHToKA References: <46F848E2.40904@ericsson.com> <46F852A3.1040401@azairenet.com><46F91662.6030200@ericsson.com> <46F985BE.3030108@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Suresh Krishnan" X-OriginalArrivalTime: 26 Sep 2007 01:54:37.0970 (UTC) FILETIME=[31FBEF20:01C7FFE0] X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: netlmm@ietf.org Subject: [netlmm] Issue: Retransmissions and timestamps X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I think this one is worth taking up on its own thread as well. Suresh and I both raised this issue in our reviews and the excerpts below are from the ongoing discussions based on Suresh's review.=20 I have a meta question here. Replay protection is provided using IPsec, not using timestamps. Timestamps are meant for ordering the PBUs and for that purpose, it really appears to me that retransmitted PBUs need not change the timestamps. As I mentioned in my review, that is desirable from a security perspective. Even from an ordering perspective, based on the discussions I've seen here, that seems to be better. =20 What is the problem with retransmissions going out with the same timestamp value? Vijay pointed to replay protection and I claim that is not needed. Were there other points?=20 Thanks, Vidya > >>> Section 6.9.3 > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> " o If Timestamp based scheme is in use, the retransmitted Proxy > >>> Binding Update messages MUST use the latest timestamp. If > >>> Sequence number scheme is in use, the retransmitted=20 > Proxy Binding > >>> Update messages MUST use a Sequence Number value=20 > greater than that > >>> used for the previous transmission of this Proxy=20 > Binding Update > >>> message, just as specified in [RFC-3775]." > >>> > >>> I completely disagree with this. I think if a PBU is=20 > retransmitted=20 > >>> it MUST use the same timestamp as the first time around.=20 > Otherwise=20 > >>> we will run into ordering problems. > >> > >> No. It should always use the latest timestamp value. Otherwise the=20 > >> LMA would not be able to distinguish between a lost Proxy BU being=20 > >> re-transmitted from a replayed proxy BU. > >=20 > > I cannot see how this works. Consider this scenario. > >=20 > > MN moves from MAG1 to MAG2 and then to MAG3. > >=20 > > M1: MAG2 sends PBU with Timestamp T (This is lost) > > M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA=20 > and updates=20 > > the binding cache on the LMA) > > M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives=20 > at LMA. LMA=20 > > sees that the timestamp is later than the current one and then=20 > > replaces the current entry in the Binding Cache) >=20 > MAG2 is supposed to check if the MN is still attached to it=20 > before re-transmitting the Proxy BU. >=20 > IMO, using the registration revocation mechanism for PMIPv6=20 > might be the cleanest approach. Any loss of connectivity is=20 > likely to be temporary once we have the registration=20 > revocation mechanism for PMIPv6. >=20 > Vijay >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 22:12:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaMNS-0002Zx-Pg; Tue, 25 Sep 2007 22:11:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaMNR-0002Zs-Vd for netlmm@ietf.org; Tue, 25 Sep 2007 22:11:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaMNQ-0001a8-Fw for netlmm@ietf.org; Tue, 25 Sep 2007 22:11:49 -0400 X-IronPort-AV: E=Sophos;i="4.20,297,1186383600"; d="scan'208";a="225115844" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Sep 2007 19:11:48 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8Q2BmfO024442; Tue, 25 Sep 2007 19:11:48 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8Q2Bhal008740; Wed, 26 Sep 2007 02:11:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 19:11:43 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 19:11:42 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" , "'Vijay Devarapalli'" References: <46F96DF7.1000702@azairenet.com> Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 19:11:44 -0700 Message-ID: <00cb01c7ffe2$9643dc70$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf/sdrXSWxVJRmzQ6G5BsvD3b9qQQAKS7SgAAD0ZAA= In-Reply-To: X-OriginalArrivalTime: 26 Sep 2007 02:11:42.0830 (UTC) FILETIME=[94D928E0:01C7FFE2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12258; t=1190772708; x=1191636708; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Review=20of=20draft-ietf-netlmm-proxymip6- 05 |Sender:=20; bh=VOj7N/vixETIpnBmC9sIY6HaihbTudaOQ6bbZHed+kk=; b=JbUtTCk2WLJoFQP3QRhiS0qLHaCcUeAjOZo7QPxCRl6t75XWNAZl7fSGdJpseIs5MYRQYf51 pNdNXAZ3iWFpERlNSumdRL98y9lD8ehGYzmVyF50+26+T01t8ZIFQ+tb; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, Please see inline ... Sri > > > > I don't think we should open the terminology issue again. We > > had extensive discussions on this in the past and concluded > > on the current terms. As long as the terminology section > > clearly describes what each term means, it should be fine. > > > > I don't really want a prolonged discussion on this topic > again. All the > points have been made. The only point I'll note is that we > never really > had a conclusion or clear consensus. There were several > logical points > made on why the current terms are not appropriate or clear, but, no > conclusions. > This terminology is there since -00 version of the WG doc. There are no open issues on this topic and there are zero comments on this. The same terminology is adopted by the other documents as well, including the IPv4 support document. I think, we will never converge on this, if we reopen this discussion. > > > - MN Identifier: > > > > > > Page 15 (and other parts of the document) talks about > > getting the MN > > > ID from the NAI option. Isn't NAI just one allowed type of > > identity? > > > A particular deployment may use other types of > identities, the only > > > requirement being a unique identity that can be stable > > within the PMIP > > > domain. > > > > That is correct. We do all allow other forms of the > > identities. We are using the option defined in RFC 4283. In > > this option, the sub-type when set to 1, indicates that it is > > the NAI. Other sub-types would be used to identify other identities. > > > > I think the document just needs to be cleaned up on where it refers to > the NAI. At the moment, it is misleading, since it uses the term "NAI > option" in multiple places and gives the impression that we are > referring to only an NAI as an MN ID. > Document refers to MN-Identifier in all places. However, the semantics for carrying this identifier is based on NAI Option [4283]. This option uses the identity construct from 4282. So, in the signaling considerations, the spec talks about NAI option, from where the MN-Identifier is derived. How else, we carry the MN-Identity across the mobility entities ? > > > - Unauthorized PBUs: > > > > > > What is the purpose of sending an error code in a PBA for an > > > unauthorized PBU? I would imagine that unauthorized PBUs > > are better > > > silently discarded. > > > > Are you talking about the "MAG_NOT_AUTHORIZED_FOR_PROXY_REG" > > error code? > > It can be argued that sending error codes is better than > > silently dropping messages for debugging purposes. > > > > It is true that error messages aid debugging. However, the > errors could > be locally logged for debugging purposes. The problem with sending > these messages that you make the LMA an oracle for DoS attacks. > MAG_NOT_AUTHORIZED_FOR_PROXY_REG: This is not just for debugging. If a given MAG is not authorized to send PBU's, the LMA has to gracefully notify that. This cannot lead to dos attack. Not that there is a security relation between this node and the LMA. Else, the PBU will be ignored. > > > - Prefix allocation and multihomed MNs: > > > > > > The first bullet on page 18 states that the LMA "MUST ensure the > > > allocated prefix is not in use by any other mobile node". In the > > > context of regular IP nodes that are multihomed, we > > discussed how it > > > is problematic when the same prefix/address is allocated to > > multiple > > > interfaces of the same node. To prevent that problem, are > > we assuming > > > that every distinct interface of an MN attached to the PMIP > > domain has > > > a different unique identity? If so, that needs to be > stated. IMO, > > > that may not be practical, especially, if an NAI is used as > > the MN ID. > > > So, in those cases, we really need to ensure that the LMA is not > > > allocating the same prefix to multiple interfaces of a > > multihomed MN. > > > I think an appropriate rewording of this sentence may be > something > > > like "the LMA MUST ensure the allocated prefix is not > > already in use, > > > i.e., there is no existing BCE for that prefix on the LMA". > > > > > > I also recall that the document is supposed to state that > > the protocol > > > does not support multihomed MNs more generically, but, I > > couldn't find > > > such text. Did I miss it? > > > > The conclusion from that thread was the multi-homing is out > > of scope for the base PMIPv6 spec and not supported in the > > base PMIPv6 document. I had proposed some text at that time. > > We never concluded on that. > > > > This needs a conclusion. I'll start a separate thread on this topic. I think the conclusion was to disallow this. But, if you think there are folks in the WG who are not happy with this conclusion, you can start a thread, but, I'm not sure, if thats the case. > > > > - MinDelayBeforeBCEDelete Timer: > > > > > > I understand where this timer is coming from, but, I'm not sure I > > > understand the behavior of the LMA fully when that timer > is running. > > > For instance, when that timer is active, what happens to any data > > > received by the LMA for that MN? If that is sent to the > CoA in the > > > BCE, that is of no use. If that data is dropped, then, it is > > > equivalent to not having a BCE for that MN. So, I'm not > > exactly sure > > > what that timer is achieving, other than avoiding giving > up the HNP > > > too soon. If that is the only intent, then, I'd word it as > > such and > > > not say that the BCE is active. Otherwise, the > processing of data > > > packets during that interval needs to be better defined. > > > > This was added to make sure the LMA does not release the home > > address/home network prefix for the mobile node during > > handovers. Lets say the old MAG has already de-registered, > > but the Proxy BU from the new MAG has not reached the LMA > > yet. If the LMA deletes the binding cache entry it might > > result in release of the home address/home network prefix. > > This was discussed on the mailing list. > > > > Yes, I think my paragraph captured this part. The point I'm making is > that you are really trying to avoid releasing the HNP and not really > keeping the binding active when this timer is running. If the binding > was active, you'd need to describe what happens to data packets > sent/received from/to the MN during that time interval. I'd say that > the binding isn't available and hence, data will be dropped, but, the > HNP is not immediately released. > Sure. As Pete pointed out, I need to provide guidance related to routing during that wait period. This is a good comment. > > > - NAI option in the PBA: > > > > > > Why is it needed? > > > > To match the proxy Binding Ack to the proxy BU. The MAG could > > be sending proxy BUs for quite a few mobile nodes. > > Adding to Ahmad's comment. Additionally, in a proxy model where the third party node is a sender, the identity of the mobile is required in the messages. > > The sequence number and timestamp are both indicated as providing this > matching capability. I don't think we need a third > mechanism. In fact, > I was going to include a comment that says we need to pick > one to match > requests and responses - and that could easily be the sequence number > (treated as a message ID in this case). > No. We still allow 3775 based sequence number support, which is per mobile node basis. So, there could be a collision in seq numbers at the MAG and so its not the definitive identifier. So, we need to carry the NAI in PBA as well. > > > - Section 6.2, MN Policy Profile: > > > > > > I'm not sure why this is mandatory. For e.g., if a network has a > > > policy to dynamically acquire an identity for the MN and > assign an > > > available HNP to that MN, it is not tied to "policy" in any way. > > > Also, when a policy profile is present, why is the LMA address a > > > mandatory field in it? That seems to be one way of > > obtaining the LMA > > > address, but, there can be other ways. > > > > We don't mandate a policy profile. If a policy profile is > > used, then we say what needs to go into it and mandate that > > the MAG and the LMA should have access to it. > > > > The text doesn't seem to read that way, at least to me. > Ok. Will clarify if it, if that's the case. > > > - Creating RAs at the MAG: > > > > > > How does the MAG obtain the parameters other than the > prefix needed > > > for the RA? For instance, the flags or other options that > > need to be sent? > > > Section 6.4 vaguely mentions based on policy, but, I don't > > think that > > > is good enough. I think we need to have at least one mode of > > > obtaining that information specified as normative for > > implementation purposes. > > > > There are two pieces of information that the MAG needs to > figure out. > > Prefix lifetime and the flags that indicate > > auto-configuration/DHCPv6. > > For the prefix lifetime, it would be MAG implementation > > specific. The MAG would know whether auto-configuration or > > DHCPv6 is being used. So it can set the flags accordingly. > > > > Yes, the M and O flags are part of the information and so is > the prefix > lifetime. But, is there a default router lifetime option? Any other > option that may need to be sent in the RA? In general, I > think it would > be good to describe how the MAG knows this stuff. > This is captured in Home Network Emulation section. See -06.txt and let me know if it does not reflect that. I will make it more clear. > > > > - Page 35, Timestamp values in retransmitted PBUs: > > > > > > As Suresh said, I don't think the timestamp needs to be > > updated in a > > > retransmitted PBU. The timestamps are used for ordering, > > not replay > > > protection here. Replay protection is provided by the > > IPsec SA (and > > > must be provided by any other authentication mechanism in use). > > > Having said that, it is typically easier for > retransmissions to not > > > have to alter the packet being sent. Plus, that will help > > the LMA be > > > idempotent and just respond with the previously sent PBA > > (if there was > > > one). In general, this is better to handle DoS attacks too. > > > > Lets follow up on that thread for this issue. > > > > > - Section 6.11, DHCP Relay Agent: > > > > > > This section seems weak. Based on list discussions, there > > probably is > > > already a plan to elaborate on the role of the MAG as a > relay agent. > > > > Any suggestions on improving it? :) I thought it is quite > > detailed. It was based on the discussions we have had so far > > on the use of DHCPv6. > > > > At least the 05 version of the draft had 2 sentences on DHCP Relay > Agents and made no mention of the MAG's role in it. Perhaps the 06 > version has more detail? Please see -06.txt > > If we claim this is an issue in the security considerations > section and > claim that the fix to it is for the LMA to ensure the MN is actually > attached to the MAG, we can't quite hand wave on some possible ways to > do that. Those are just hints for deployments that are > concerned about > MAG compromise. But, those hints need to be captured in the security > considerations section. The threats document captures this threat and > it is a valid one - so, I believe we need some text here. The type of > "detail" is what I tried to provide with the examples on AAA checks or > CGA signatures - and, I don't think we need a lot of detail > here; a few > sentences would be good. > The threats document should cover this. I do not think, we can mandate a specific method. I'm not sure, if this document will add any value if we venture into this aspect. Thanks for the review. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 22:13:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaMPW-0003Xg-Gu; Tue, 25 Sep 2007 22:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaMPW-0003XX-4R for netlmm@ietf.org; Tue, 25 Sep 2007 22:13:58 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaMPP-0001cf-OA for netlmm@ietf.org; Tue, 25 Sep 2007 22:13:58 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 19:13:50 -0700 Message-ID: <46F9C05E.8060208@azairenet.com> Date: Tue, 25 Sep 2007 19:13:50 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 References: <46F96DF7.1000702@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 02:13:50.0570 (UTC) FILETIME=[E0FCBCA0:01C7FFE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Narayanan, Vidya wrote: >> >>> Technical - Major: >>> ================== >>> >>> - Terminology: Proxy-CoA and MN-HoA: >>> >>> As I've mentioned before, this terminology continues to be >> confusing, >>> especially, when we talk about PMIP6 and MIP6 together. >> Given that an >>> MN is called an MN in the MIP6 case, tagging "MN" before the HoA is >>> not making it any more descriptive to the PMIP6 use. I've >> stated my >>> concerns with these terms before and I know the authors had >> a strong >>> preference to keeping this terminology, but, I'd strongly urge some >>> re-thinking here to avoid confusion to the end users of the >> protocol. >> >> I don't think we should open the terminology issue again. We >> had extensive discussions on this in the past and concluded >> on the current terms. As long as the terminology section >> clearly describes what each term means, it should be fine. >> > > I don't really want a prolonged discussion on this topic again. All the > points have been made. The only point I'll note is that we never really > had a conclusion or clear consensus. There were several logical points > made on why the current terms are not appropriate or clear, but, no > conclusions. I suggest we don't open up that discussion again then. > >>> - MN Identifier: >>> >>> Page 15 (and other parts of the document) talks about >> getting the MN >>> ID from the NAI option. Isn't NAI just one allowed type of >> identity? >>> A particular deployment may use other types of identities, the only >>> requirement being a unique identity that can be stable >> within the PMIP >>> domain. >> That is correct. We do all allow other forms of the >> identities. We are using the option defined in RFC 4283. In >> this option, the sub-type when set to 1, indicates that it is >> the NAI. Other sub-types would be used to identify other identities. >> > > I think the document just needs to be cleaned up on where it refers to > the NAI. At the moment, it is misleading, since it uses the term "NAI > option" in multiple places and gives the impression that we are > referring to only an NAI as an MN ID. True, we need to call it the MN-identifier option. Not the NAI option. Needs to be fixed throughout. >>> - Unauthorized PBUs: >>> >>> What is the purpose of sending an error code in a PBA for an >>> unauthorized PBU? I would imagine that unauthorized PBUs >> are better >>> silently discarded. >> Are you talking about the "MAG_NOT_AUTHORIZED_FOR_PROXY_REG" >> error code? >> It can be argued that sending error codes is better than >> silently dropping messages for debugging purposes. >> > > It is true that error messages aid debugging. However, the errors could > be locally logged for debugging purposes. The problem with sending > these messages that you make the LMA an oracle for DoS attacks. I don't see any state being created. At any rate, the LMA could implement rate-limiting for the number of proxy BUs it handles from a particular IP address/domain/MAG/etc... Sending the error message I believe is beneficial. >>> - Page 18, Binding De-registration: >>> >>> If the LMA may accept or ignore a PBU sent with a source address >>> different from the Proxy-CoA, what is that test needed for? >> Are there >>> any examples of cases where the LMA behavior would be one >> or the other? >>> And, why is the source address relevant for a de-registration alone >>> and not for other PBUs? >> The emphasis is on ignore the de-registration proxy BU or >> responding to the old MAG with status 0. It was added to >> address one specific case - if the de-registration proxy BU >> from the old MAG is received after the proxy BU from the new >> MAG, the LMA is supposed to ignore the de-registration BU >> (but still respond to the old MAG with status 0). >> >> I read the text, perhaps it would better to say the LMA >> always responds to the deregistration proxy BU (without >> deleting the binding cache entry). Not ignore it. If the LMA >> ignores it, the old MAG would only re-transmit the >> deregistration proxy BU. >> > > Okay. That revision sounds more appropriate. Ok, will fix this. >>> - MinDelayBeforeBCEDelete Timer: >>> >>> I understand where this timer is coming from, but, I'm not sure I >>> understand the behavior of the LMA fully when that timer is running. >>> For instance, when that timer is active, what happens to any data >>> received by the LMA for that MN? If that is sent to the CoA in the >>> BCE, that is of no use. If that data is dropped, then, it is >>> equivalent to not having a BCE for that MN. So, I'm not >> exactly sure >>> what that timer is achieving, other than avoiding giving up the HNP >>> too soon. If that is the only intent, then, I'd word it as >> such and >>> not say that the BCE is active. Otherwise, the processing of data >>> packets during that interval needs to be better defined. >> This was added to make sure the LMA does not release the home >> address/home network prefix for the mobile node during >> handovers. Lets say the old MAG has already de-registered, >> but the Proxy BU from the new MAG has not reached the LMA >> yet. If the LMA deletes the binding cache entry it might >> result in release of the home address/home network prefix. >> This was discussed on the mailing list. >> > > Yes, I think my paragraph captured this part. The point I'm making is > that you are really trying to avoid releasing the HNP and not really > keeping the binding active when this timer is running. If the binding > was active, you'd need to describe what happens to data packets > sent/received from/to the MN during that time interval. I'd say that > the binding isn't available and hence, data will be dropped, but, the > HNP is not immediately released. Agreed. >>> - NAI option in the PBA: >>> >>> Why is it needed? >> To match the proxy Binding Ack to the proxy BU. The MAG could >> be sending proxy BUs for quite a few mobile nodes. >> > > The sequence number and timestamp are both indicated as providing this > matching capability. The sequence number does not have to be included. If there is no context transfer mechanism between MAGs to transfer the correct sequence number to be used, it won't work. Timestamps are not sufficient, since the MAG could send more than one proxy BU for different mobile nodes in the same second. > I don't think we need a third mechanism. You need the MN-identifier to match the proxy BAck to the proxy BU. >>> - Section 6.2, MN Policy Profile: >>> >>> I'm not sure why this is mandatory. For e.g., if a network has a >>> policy to dynamically acquire an identity for the MN and assign an >>> available HNP to that MN, it is not tied to "policy" in any way. >>> Also, when a policy profile is present, why is the LMA address a >>> mandatory field in it? That seems to be one way of >> obtaining the LMA >>> address, but, there can be other ways. >> We don't mandate a policy profile. If a policy profile is >> used, then we say what needs to go into it and mandate that >> the MAG and the LMA should have access to it. >> > > The text doesn't seem to read that way, at least to me. Which text? >>> - Creating RAs at the MAG: >>> >>> How does the MAG obtain the parameters other than the prefix needed >>> for the RA? For instance, the flags or other options that >> need to be sent? >>> Section 6.4 vaguely mentions based on policy, but, I don't >> think that >>> is good enough. I think we need to have at least one mode of >>> obtaining that information specified as normative for >> implementation purposes. >> >> There are two pieces of information that the MAG needs to figure out. >> Prefix lifetime and the flags that indicate >> auto-configuration/DHCPv6. >> For the prefix lifetime, it would be MAG implementation >> specific. The MAG would know whether auto-configuration or >> DHCPv6 is being used. So it can set the flags accordingly. >> > > Yes, the M and O flags are part of the information and so is the prefix > lifetime. But, is there a default router lifetime option? MAG is the default router. So MAGs sets this value. > Any other > option that may need to be sent in the RA? In general, I think it would > be good to describe how the MAG knows this stuff. What are we missing? >>> - Section 6.11, DHCP Relay Agent: >>> >>> This section seems weak. Based on list discussions, there >> probably is >>> already a plan to elaborate on the role of the MAG as a relay agent. >> Any suggestions on improving it? :) I thought it is quite >> detailed. It was based on the discussions we have had so far >> on the use of DHCPv6. >> > > At least the 05 version of the draft had 2 sentences on DHCP Relay > Agents and made no mention of the MAG's role in it. Perhaps the 06 > version has more detail? See version 06, section 6.11 >>> - Security considerations: Authorization of MAGs: >>> >>> It is fine to have the method of authorizing a MAG be out >> of scope for >>> the specification itself, but, I think we need to give some >> hints on >>> what that means in the security considerations section. >> For instance, >>> it could be about that particular MAG just having an IPsec SA with >>> that LMA or it could be something more like that MAG being >> part of the >>> defined PMIPv6 domain and the corresponding MN-HoA >> belonging to that >>> domain, etc. >> Agreed. Any text? Otherwise I will come up with some text. >> > > Please suggest text :) > >>> - Security considerations: MAG Compromise: >>> >>> Similar comment to the one above. I think we need a bit >> more detail >>> on ensuring the MN is "definitively attached" to the MAG >> that sent the PBU. >>> For instance, it could be a AAA check upon reception of a PBU (the >>> document alludes to this somewhere), it could be a CGA signature of >>> the MN carried from an secure RS, in the PBU (this needs more >>> thinking), etc. Again, it is fine that this document >> doesn't define >>> anything normative here, but, the security considerations >> as written >>> is hand waving this point. >> We went back and forth on this. Some folks wanted to add >> hints to specific mechanisms and others wanted to leave this >> out of scope. The LMA checking with the AAA to see if the MN >> is attached to the MAG is a solution. But this relies on the >> AAA infrastructure being used. I think this is best left for >> other documents. Any suggestions on what "detail" >> we can add? >> > > If we claim this is an issue in the security considerations section and > claim that the fix to it is for the LMA to ensure the MN is actually > attached to the MAG, we can't quite hand wave on some possible ways to > do that. Those are just hints for deployments that are concerned about > MAG compromise. But, those hints need to be captured in the security > considerations section. The threats document captures this threat and > it is a valid one - so, I believe we need some text here. The type of > "detail" is what I tried to provide with the examples on AAA checks or > CGA signatures - and, I don't think we need a lot of detail here; a few > sentences would be good. Please provide text. :) Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 22:17:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaMT0-00066M-GO; Tue, 25 Sep 2007 22:17:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaMSz-00066H-Bw for netlmm@ietf.org; Tue, 25 Sep 2007 22:17:33 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaMSy-0005ak-O0 for netlmm@ietf.org; Tue, 25 Sep 2007 22:17:33 -0400 X-IronPort-AV: E=Sophos;i="4.20,298,1186383600"; d="scan'208";a="401805594" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 25 Sep 2007 19:17:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8Q2HWV3016155; Tue, 25 Sep 2007 19:17:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8Q2Gr87020589; Wed, 26 Sep 2007 02:17:31 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 19:17:31 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 19:17:31 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" , "'Vijay Devarapalli'" , "'Suresh Krishnan'" References: <46F848E2.40904@ericsson.com><46F852A3.1040401@azairenet.com><46F91662.6030200@ericsson.com><46F985BE.3030108@azairenet.com> Subject: RE: [netlmm] Issue: Retransmissions and timestamps Date: Tue, 25 Sep 2007 19:17:31 -0700 Message-ID: <00cf01c7ffe3$64cd6570$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf/wl8f1YfuWj3kSVuieUs1PtuEowAHToKAAADRULA= In-Reply-To: X-OriginalArrivalTime: 26 Sep 2007 02:17:31.0464 (UTC) FILETIME=[64A67C80:01C7FFE3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3872; t=1190773052; x=1191637052; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Retransmissions=20and=20timesta mps |Sender:=20; bh=e+YtN/H/tHsLTuVp1A+KNmFh3SLeWGEApQCiafTzK20=; b=dQiJeM2H2OtrAL08LTZRujmRr1d/wzC3SNezHkMoXzrkU8G6yfOicdkJPS3KKR0gASyvOb+q jE9Kp8nrNp43TNtrw69sUzCrluqP2nFX4YyU9EvyPfS5msh9w3+NUZC9rEBOTjKzqSIT3jRQOm V/pPNk2gIbLHq2ZiIyRlz6iI8=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org We are not using timestamps for replay protection. When a message is retransmitted, the entity that is sending the message is claiming the presence of the node at that instance of time and the timestamp in the message should reflect that. If the nodes keep retransmitting for a longer and longer times, we need to consider lot more cases to handle this correctly. I do not know, what issues you are Suresh are foreseeing, when a message is retransmitted with a new timestamp. If there is an issue that you see, then we can try to fix this logic. Sri > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Tuesday, September 25, 2007 6:55 PM > To: Vijay Devarapalli; Suresh Krishnan > Cc: netlmm@ietf.org > Subject: [netlmm] Issue: Retransmissions and timestamps > > I think this one is worth taking up on its own thread as well. Suresh > and I both raised this issue in our reviews and the excerpts below are > from the ongoing discussions based on Suresh's review. > > I have a meta question here. Replay protection is provided > using IPsec, > not using timestamps. Timestamps are meant for ordering the PBUs and > for that purpose, it really appears to me that retransmitted PBUs need > not change the timestamps. As I mentioned in my review, that is > desirable from a security perspective. Even from an ordering > perspective, based on the discussions I've seen here, that seems to be > better. > > What is the problem with retransmissions going out with the same > timestamp value? Vijay pointed to replay protection and I > claim that is > not needed. Were there other points? > > Thanks, > Vidya > > > >>> Section 6.9.3 > > >>> ============= > > >>> " o If Timestamp based scheme is in use, the > retransmitted Proxy > > >>> Binding Update messages MUST use the latest timestamp. If > > >>> Sequence number scheme is in use, the retransmitted > > Proxy Binding > > >>> Update messages MUST use a Sequence Number value > > greater than that > > >>> used for the previous transmission of this Proxy > > Binding Update > > >>> message, just as specified in [RFC-3775]." > > >>> > > >>> I completely disagree with this. I think if a PBU is > > retransmitted > > >>> it MUST use the same timestamp as the first time around. > > Otherwise > > >>> we will run into ordering problems. > > >> > > >> No. It should always use the latest timestamp value. > Otherwise the > > >> LMA would not be able to distinguish between a lost > Proxy BU being > > >> re-transmitted from a replayed proxy BU. > > > > > > I cannot see how this works. Consider this scenario. > > > > > > MN moves from MAG1 to MAG2 and then to MAG3. > > > > > > M1: MAG2 sends PBU with Timestamp T (This is lost) > > > M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA > > and updates > > > the binding cache on the LMA) > > > M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives > > at LMA. LMA > > > sees that the timestamp is later than the current one and then > > > replaces the current entry in the Binding Cache) > > > > MAG2 is supposed to check if the MN is still attached to it > > before re-transmitting the Proxy BU. > > > > IMO, using the registration revocation mechanism for PMIPv6 > > might be the cleanest approach. Any loss of connectivity is > > likely to be temporary once we have the registration > > revocation mechanism for PMIPv6. > > > > Vijay > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 22:31:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaMfJ-0001o9-Dx; Tue, 25 Sep 2007 22:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaMfI-0001mW-8h for netlmm@ietf.org; Tue, 25 Sep 2007 22:30:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaMfC-0001yo-2b for netlmm@ietf.org; Tue, 25 Sep 2007 22:30:16 -0400 X-IronPort-AV: E=Sophos;i="4.20,298,1186383600"; d="scan'208";a="528092258" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 25 Sep 2007 19:30:04 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8Q2U4Tn030684; Tue, 25 Sep 2007 19:30:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8Q2U48p016774; Wed, 26 Sep 2007 02:30:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 19:30:04 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 19:30:03 -0700 From: "Sri Gundavelli" To: "'Sri Gundavelli'" , "'Narayanan, Vidya'" , "'Vijay Devarapalli'" References: <46F96DF7.1000702@azairenet.com> <00cb01c7ffe2$9643dc70$1220fea9@amer.cisco.com> Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 19:30:01 -0700 Message-ID: <00d101c7ffe5$242d4a10$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf/sdrXSWxVJRmzQ6G5BsvD3b9qQQAKS7SgAAD0ZAAAAXYv0A== In-Reply-To: <00cb01c7ffe2$9643dc70$1220fea9@amer.cisco.com> X-OriginalArrivalTime: 26 Sep 2007 02:30:03.0848 (UTC) FILETIME=[251B2C80:01C7FFE5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=741; t=1190773804; x=1191637804; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Review=20of=20draft-ietf-netlmm-proxymip6- 05 |Sender:=20; bh=Vnc3DavHdqgdp98NxgQGkwBdrM0yw3KgTHlAUhrvQLs=; b=mKT9mi3PgMfbWiEWnuixojJ27drf4R0At5iNBz7exVznYkhJ5ekKD4z/LSEG27klxFO+fuG6 IYd9T+M+lPXv3CSk5zKVd/Ps9V4bjhPubiwYvnYne2QFDdpo4aVAph1O; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > > Document refers to MN-Identifier in all places. However, the semantics > for carrying this identifier is based on NAI Option [4283]. > This option > uses the identity construct from 4282. So, in the signaling > considerations, > the spec talks about NAI option, from where the MN-Identifier > is derived. > How else, we carry the MN-Identity across the mobility entities ? > > > There is a mistake on my part. I referred to the MN-Identifier Option in 4283 as "NAI Option". Vijay pointed this out offline. That is the cause for the confusion. Will change this. But, the identifier carried in this option is still a construct as per 4282 and the option is still from 4283. My mistake. Will fix this. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Tue Sep 25 23:36:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaNh1-0008EO-NA; Tue, 25 Sep 2007 23:36:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaNh0-0008Db-2f for netlmm@ietf.org; Tue, 25 Sep 2007 23:36:06 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaNgy-00079j-OK for netlmm@ietf.org; Tue, 25 Sep 2007 23:36:05 -0400 X-IronPort-AV: E=Sophos;i="4.20,298,1186383600"; d="scan'208";a="528106099" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 25 Sep 2007 20:36:04 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8Q3a4IV029360; Tue, 25 Sep 2007 20:36:04 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8Q3a48p027392; Wed, 26 Sep 2007 03:36:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 20:36:03 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 20:36:03 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" , References: Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 20:36:00 -0700 Message-ID: <00d401c7ffee$5b6f5230$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf/T/RrZEqQFEePT3u9QfI2QIenQAAmSnpg In-Reply-To: X-OriginalArrivalTime: 26 Sep 2007 03:36:03.0396 (UTC) FILETIME=[5D2E4040:01C7FFEE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10473; t=1190777764; x=1191641764; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Review=20of=20draft-ietf-netlmm-proxymip6- 05 |Sender:=20; bh=Syp2O118TfvyXPGt9AmEEhqMyBBPF+2pGv06vJnBiY8=; b=rYMfPEsczb5OHRTnwZt1obmtpDpaf0vOp4B88TbpborAQtQmeAnbrTu8DaTRTgDvDwBhEMLP BWDAiJYEjLPdikB0eSLcFjTpxR1QpqWHdn2MkNWyxllDiWJ2SWTDkzKc; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vidya, Responding to your other comments.. > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Tuesday, September 25, 2007 1:42 AM > To: netlmm@ietf.org > Subject: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 > > All, > The following is a review of version 05 of the base draft. Please let > me know if any of this has been addressed in 06 and I'll take a look. > Also, if some of these are duplicates from other reviws, please feel > free to point me to a response you have provided earlier on this. I > tried filtering out some of the duplicate comments, but, it is likely > that there are some. > > There are a number of comments below. I've tried categorizing the > comments into "Technical - Major" (for those that are definitely going > to need some discussion), "Technical - Minor" (for those that may need > some discussion, but, aren't generally show-stoppers) and "Editorial" > (don't need discussion). Hope that helps to some extent. > > Thanks, > Vidya > > > - Page 5: PMIPv6 Domain definition: > > Isn't a PMIP domain also the topological boundary within which the MN > doesn't need to change its IP address? It would make sense to state > that as part of the definition in my view. > This was discussed in the thread http://www1.ietf.org/mail-archive/web/netlmm/current/msg02383.html The definition was discussed in the WG and adopted from there. I can try to add the IP address part. > - General: > > Parts of the document contains text on IPv4. I suggest > leaving the IPv4 > text to the IPv4 document. > This document does not explain how IPv4 transport or addressing is achieved. It just points to the other document, to specify the scope of this work. The references to IPv4 are only for completeness. The IPv4 support doc is an extension to this work. > - Terminology: MN's Home Link: > > The use of the term "link" in this paragraph seems a bit > confusing. The > first use of it gives the impression that it is referring to an > interface on the MN, but, then, goes to say something about > conceptually > following the MN. Could we try to reword this for clarity? > > This is also the case in certain other parts of the document. For > instance, the document refers to the PMIPv6 domain appearing as a > "single link" to the MN - this is a bit misleading. "Link", for > instance, could be an L2 aspect, where the MN actually realizes that a > change in it's link has occurred at L2 - it is the IP point of > attachment that is being kept constant here in the PMIP6 domain. I > think some more clarity there will be helpful. > Will slightly reword it. > - Section 5.2: > > Shouldn't the first point be that the LMA should recognize > the incoming > packet as a PBU, based on the P flag? > It starts with, "Upon receiving a Proxy Binding Update request ...", so the scope of that section is for that BU's with the "P" flag. Any case, I will add a comment. > - Section 5.2, bullet 6: > > Given that we only have a SHOULD on the use of IPsec, the second > sentence there should probably read something like "When IPsec is used > for message authentication, the SPI in the IPsec header of > the received > packet MUST be used for locating..." > ok > - Page 17, last bullet: > > Does this imply that the MN ID must always be present in the > PBU? Once > an HNP is allocated, isn't that sufficient to indicate the > binding that > needs to be refreshed? In that case, we don't need the MN ID to be > present in subsequent BUs. > Discussion on MN-Id is in the other thread. > > - Timestamp values: > > In the 4th bullet from the bottom on page 22, it says "MUST be close > enough" of the LMA's clock - I don't think "close enough" is > sufficient > here. For interoperability, I believe we should specify the range for > closeness. > This was the comment from Shyam. It really depends on the mechanism that is used for time synchronization and the accuracy provided by that mechanism. Its better we leave this to deployments. > - "SHOULD" for access authentication: > > I'm not sure why this is a SHOULD for this specification. > Just because > access authentication is likely to be done on systems that are looking > at adopting PMIP6 today doesn't make it a requirement for the > protocol. > In my view, there is no depedency between having acces control versus > not from a PMIP perspective. > Is that inline with IETF security requirements for protocols ? We put a MUST for network node security and a MAY for access security ? I understand, in some networks this may not be enabled. But, the spec should require it. > - Section 6.6, MN identity: > > We should mention that this could be a link layer address or > pretty much > any identifier that uniquely identifies the MN in that domain. > This is per 4282. What we carry is the MN-Identifier option and we are bound to that definition in that option. > - Page 33, Timestamp synchronization: > > Why do we prevent the MAG from using the LMA's timestamp value in the > PBA to synchronize its clock? If we specify the acceptable drift > correctly and if the MAG has an idea about average transmission delays > of the network, it should be feasible. Or, am I missing something? > There were like million emails on this and that was the conclusion. Kilian and Federico can explain it. You can look for the email threads over the last 1 month. > - Page 34, Binding De-registration: > > Why is this a MUST? If another MAG sends a PBU for the MN, > the existing > entry will be overwritten anyway. If not, the binding will eventually > time out. It seems like a SHOULD for de-registration is sufficient. > What if the lifetime is very high and the mobile roams out of the PMIP domain. It needs to clean up the visitor state. > - Section 7, MN behavior: > > Given that this section is non-normative, I think phrases like "it is > recommended" or "it is important/critical" should be changed. > It sends > the impression that those are really important for the protocol even > though an IP node implementation is not expected to change. I think > phrasing those as "the protocol would benefit from X" or > "lower latency > can be achieved by doing Y" would be more appropriate. > hmm .. ok > > Editorial: > ========== > Will fix the editorial comments. After Pete's thorough review, not sure, how many are still there. > - Page 2: Abstract: > > s/network being in control of the mobility management/network being > responsible for IP mobility management of mobile nodes. > > - Page 4: Intro: > > s/The proxy mobility agent/A mobility agent > > "proxy mobility agent" sounds like a new term, while mobility > agent has > been used before in the context of home and foreign agents. We are > referring to one such agent here. The protocol is a "proxy" based protocol. > > - Page 5: LMA definition: > > s/and with the additional/with the additional > > - Page 6: MN definition: > > s/Through out/ Throughout > > - Page 7: s/The local mobility is responsible/The local mobility agent > is responsible > > - Page 12: s/making it believe its still on/ making it believe it is > still on > > - Section 5.1: > > It would be good to add a sentence on the significance of the > MN's link > local address in the BCE of the LMA. This isn't stated until section > 6.8 and even there, it is a bit buried. > ok > - Section 5.2: The first sentence reads as if there is only one > exception to the processing rules of RFC3775, but, there is a > long list > of additional considerations. I suggest wording it to say that > additional considerations apply and leaving the "one > exception" part out > of the sentence. > ok > - s/IPSec/IPsec for all instances > > - Page 20, last bullet: > > The use of MUST/SHOULD with IPsec should be made consistent - > for e.g., > here, it should read that the message MUST be authenticated and IPsec > SHOULD be used for that. > > - Page 21, first bullet: s/header, /header > > - Page 21, Section 5.4: > > s/absence of context transfer mechanism/absence of mechanisms such as > context transfer between MAGs > > - Page 21, last paragraph: > > I think we should avoid normative language for the sequence > number case, > given that we don't define that here. So, all the "MUSTs" should be > changed to read as what needs to happen in the case of sequence number > use in regular expression. Please note that "must" is equivalent to > "MUST" per RFC2119 :) > Good point. > - Page 25, last sentence of section 5.6 > > Reword to "This may be obtained through mechanisms outside > the scope of > this document, e.g., configuration as part of the mobile node's policy > profile." > > - Section 5.8: > > It would be good to clearly state that RO is out of scope for this > document. The section currently only says RR cannot be used. > But, we support local routing on the MAG. So, we strictly cant say we dont support RO. We dont support RR as per 3775. RO is a overloaded term. > - Page 27, first bullet: > > s/access link or through/access link through > > - Page 27: > > s/This address is acquired from/This address may be acquired from > > A preconfigured LMA address as part of MN's policy profile is only one > possibility. > > - RFC2461/2462 references should change to 2461bis and 2462bis > yep .. as Suresh pointed out. > - Page 33: s/SHOULD not/SHOULD NOT > > - Page 34/35: The "MUST construct" seems to be at odds with > the SHOULDs > that follow. > > - Page 35: s/when ever/whenever > > - Page 35: s/what ever reasons/whatever reason > > - Page 39, Section 6.10.4: > > s/this has an implication on the mobile node's accounting/in some > systems, this may have an implication on the mobile node's accounting > > - Page 43, 3rd para: s/access link, receives/access link receives > > - Page 54: s/a denial-of-service attacks/a denial-of-service attack > > - Page 55: s/different domains/different administrative domains > Thanks for the review Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 00:00:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaO4C-0005l7-As; Wed, 26 Sep 2007 00:00:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaO4A-0005hq-9k for netlmm@ietf.org; Wed, 26 Sep 2007 00:00:02 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaO49-00081K-Rd for netlmm@ietf.org; Wed, 26 Sep 2007 00:00:02 -0400 X-IronPort-AV: E=Sophos;i="4.20,298,1186383600"; d="scan'208";a="20004815" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 25 Sep 2007 21:00:01 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8Q401FP007100; Tue, 25 Sep 2007 21:00:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8Q4017f017214; Wed, 26 Sep 2007 04:00:01 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 21:00:00 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 21:00:00 -0700 From: "Sri Gundavelli" To: "'Alexandru Petrescu'" References: <46F848E2.40904@ericsson.com> <001f01c7ff31$1cf18860$1220fea9@amer.cisco.com> <46F8FF2A.2010701@gmail.com> Subject: RE: DHCP Relay link-address use is probably inapppropriate (was: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05) Date: Tue, 25 Sep 2007 20:59:59 -0700 Message-ID: <00d501c7fff1$b578c2e0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf/b72NHqQDLz94QbiGDYrfpwoNUAAgRgIA In-Reply-To: <46F8FF2A.2010701@gmail.com> X-OriginalArrivalTime: 26 Sep 2007 04:00:00.0660 (UTC) FILETIME=[B5DB5540:01C7FFF1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2369; t=1190779201; x=1191643201; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20DHCP=20Relay=20link-address=20use=20is=20probably=20i napppropriate=20=20(was=3A=20=20[netlmm]=20Suresh's=20review=20of=20draft- ietf-netlmm-proxymip6-05) |Sender:=20; bh=PKgZXznsXzrXfUwlDscjFZCCfAR51iZkOcmnEnuXr5U=; b=m60M715HUyzbW02mlAhomJLe6D8EKGPy5ewggPf4Lpn50OeM9tehHFSixpt4jJlBpa0+ZZNe RRbsuor6XB0VDgdXALLC3zRPH4eJ/uwn16OXI18xr91MbKm8gfBB04ho; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: Tuesday, September 25, 2007 5:30 AM > To: Sri Gundavelli > Cc: 'Suresh Krishnan'; netlmm@ietf.org > Subject: Re: DHCP Relay link-address use is probably > inapppropriate (was: [netlmm] Suresh's review of > draft-ietf-netlmm-proxymip6-05) > > Sri Gundavelli wrote: > [...] > >> Section 6.11 ============ > >> > >> I am not sure how the MAG can send the HNP of the MN in the > >> link-address field of the DHCP relay message since the link-address > >> field does not contain a prefix length. Is there an implicit > >> assumption that the prefix will be 64 bits in length? > >> > > > > This is per 3315. I will look into the format. > > I think here may be an error of interpretation or of specification. > > RFC3315: > > If the relay agent received the message to be relayed from > a client, > > the relay agent places a global or site-scoped address with > a prefix > > assigned to the link on which the client should be assigned an > > address in the link-address field. > > I think it wrongly says "with a prefix". Because: (1) it makes people > think there is a prefix length in that field, (2) the DHCP > RELAY-FORWARD > doesn't encode a prefix length (3315 pp 18) (3) wireshark > doesn't show a > prefix length field, (4) Dibbler implementation doesn't > encode a prefix > length but a full /128 address in that field, it's the address of the > Relay interface on which a mobile attaches. > Yes. I agree. I used to say, "prefix pool hint". Its the address on the interface of the AR that is hosting the prefix. You are right. Lets take Cafe::/64 as the pool. The AR has Cafe::1 on the interface, the DHCP server will allocate an address from the pool "cafe". Thats all to this dhcp based address configuration. I think, once an IPv6 link is configured and is up, all the IPv6 properties on that link should survive. It should not matter if the link is configured dynamically or statically. Its very important that we dont see the MN-AR link as a special link. The MAG vendors should have the ability to drop in features, say, Firewall, Access Security protocols ... or what ever services that are built for an IPv6 access link. This is a design goal, IMHO. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 00:08:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaOBL-0005c0-Ma; Wed, 26 Sep 2007 00:07:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaOBK-0005bt-Gj for netlmm@ietf.org; Wed, 26 Sep 2007 00:07:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaOBJ-0008Cf-Rb for netlmm@ietf.org; Wed, 26 Sep 2007 00:07:26 -0400 X-IronPort-AV: E=Sophos;i="4.20,298,1186383600"; d="scan'208";a="225161136" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Sep 2007 21:07:25 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8Q47PDF011199; Tue, 25 Sep 2007 21:07:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8Q47P8p016517; Wed, 26 Sep 2007 04:07:25 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 21:07:24 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Sep 2007 21:07:24 -0700 From: "Sri Gundavelli" To: "'Suresh Krishnan'" References: <46F848E2.40904@ericsson.com> <001f01c7ff31$1cf18860$1220fea9@amer.cisco.com> <46F918B9.3000709@ericsson.com> Subject: RE: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 Date: Tue, 25 Sep 2007 21:07:24 -0700 Message-ID: <00d601c7fff2$bedef600$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf/fwyPgil7bR/2SlO3tdx4LqfcrwAcq4Fg In-Reply-To: <46F918B9.3000709@ericsson.com> X-OriginalArrivalTime: 26 Sep 2007 04:07:24.0710 (UTC) FILETIME=[BE87FC60:01C7FFF2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4093; t=1190779645; x=1191643645; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Suresh's=20review=20of=20draft-ietf-netlmm -proxymip6-05 |Sender:=20; bh=o6vQbLLcILlkOsuWJFAw6xztOD8HmWxvAt3UPn6itVE=; b=ScrukYtadSHTgxqdKPTaCI1kzZnvLMWFc1E+c+yv1rgfw7U3HUS0ttNYp9JcXYNqxojr0xYR 3rakWR2jK8tH4Zw/OLb8vhoZvChToJ7TBNO3+0po8UBG/hZr93tSZq1v; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Suresh, Please see inline. Regards Sri > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Tuesday, September 25, 2007 7:19 AM > To: Sri Gundavelli > Cc: netlmm@ietf.org > Subject: Re: [netlmm] Suresh's review of > draft-ietf-netlmm-proxymip6-05 > > Hi Sri, > I am removing things that we agreed on. > Ok. > > > > This is for convering the case, where the MN boots on a bad MAG > > where the time is like 5 hours ahead. If LMA does not do the > > basic sanity check and accepts the PBU, all subsequent PBU's > > from the other MAG's where the MN moves to will have older TS. > > We have discussed this thread to death. No worries on this logic. > > But isn't this still the case where the MAGs have to be > synced and not > the LMAs. I am thinking about roaming scenarios where the > MAGs can and > will be connected to multiple and keeping the time in sync > between the > MAGs and the LMAs becomes a big issue. > Lets discuss this timestamp related issue offline. Need be, lets have a conf call between the main contributors to this section and close this in the right way. > > The message with the "P" flag is the PBU. The whole signaling logic > > is tied to this message. > > As I said in my mail to Vijay, I know this is the case, but it is not > mentioned anywhere in the document. Explaining this in either the > terminology for the PBU ("a PBU will have the P flag set...") > or adding > a checking step in the LMA operation will do. > Ok. Will make it explicit. > > > > > > >> Section 5.3: Binding De-registration > >> ==================================== > >> "Upon accepting the Proxy Binding Update request for a mobile node, > >> with the lifetime value of zero, the local mobility anchor MUST > >> wait for MinDelayBeforeBCEDelete amount of time, before > it deletes > >> the mobile node's Binding Cache entry." > >> > >> What is the purpose for having a timer to delete a BCE? I see > >> no reason > >> at all in waiting. If this is being done to prevent considering a > >> following BU as an initial registration ( I suspect this > is the case) > >> please extend the conceptual data structure to add a deleted flag > >> instead of using a timer. > > > > > > For covering the make-before-break case. It cant be just a flag, > > its a time sensitive operation. > > In a make-before-break case, the new PBU will arrive BEFORE the > deregistration PBU will arrive. I am not sure I see the > applicability of > the timer to this case. Can you please clarify. > No, its for the other case. If the dereg msg from the old MAG arrives at the LMA before the reg msg from the new MAG arrives, we dont want to delete the binding, but wait and see if there will be an reg BU from a new BU. Why timer ? What if the MN roams away ? We need to give enough time for the MN to roam to a new link, atleast wait till that time and later remove the BCE. > > >> Section 6.9.3 > >> ============= > >> " o If Timestamp based scheme is in use, the retransmitted Proxy > >> Binding Update messages MUST use the latest timestamp. If > >> Sequence number scheme is in use, the retransmitted > >> Proxy Binding > >> Update messages MUST use a Sequence Number value > >> greater than that > >> used for the previous transmission of this Proxy > Binding Update > >> message, just as specified in [RFC-3775]." > >> > >> I completely disagree with this. I think if a PBU is > retransmitted it > >> MUST use the same timestamp as the first time around. > >> Otherwise we will > >> run into ordering problems. > >> > > > > I dont think it will create any ordering problems. The message is > > generated at a different time. If it uses old timestamp, it breaks > > the LMA sanity check rule. > > Please see my mail to Vijay on this subject where I explained > a scenario. > Ok. We will discuss this timestamp issues in conf call. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 01:03:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaP2g-0001db-Nd; Wed, 26 Sep 2007 01:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaP2f-0001cz-Jc for netlmm@ietf.org; Wed, 26 Sep 2007 01:02:33 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaP2Z-0005Xy-8X for netlmm@ietf.org; Wed, 26 Sep 2007 01:02:33 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8Q51plL029027; Wed, 26 Sep 2007 08:02:13 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 08:02:06 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 00:02:04 -0500 Received: from 10.162.252.131 ([10.162.252.131]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 Sep 2007 05:02:03 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 26 Sep 2007 00:02:04 -0500 Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs From: Basavaraj Patil To: "ext Narayanan, Vidya" , Message-ID: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAGsy7R In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 05:02:04.0020 (UTC) FILETIME=[6126FB40:01C7FFFA] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, Multihomed MNs and how PMIP6 deals with them are out of scope in the context of this document. If this is really important, then it should be specified in a separate I-D. I realize the problem that you are stating and this is the same that was discussed some time back. At least my recollection was that we would not deal with multihoming or how to avoid assigning the same address to multiple interfaces on an MN. I am just wondering if the LMA would really assign the same prefix to multiple interfaces of an MN and in what scenario this would happen. Basically when the LMA has assigned a prefix to an MN (to a specific interface), that prefix is marked as assigned in the pool of prefixes. So I don't see the LMA assigning the same prefix to another interface of that MN. So I do not believe there is a need to do anything in the current I-D on this issue other to clarify that multi-homing and issues associated with multi-homing are out of scope for this document. -Raj On 9/25/07 8:50 PM, "ext Narayanan, Vidya" wrote: > > Just taking this one up on a separate thread. Here is the discussion > from me and Vijay: > > "Vidya: > >> - Prefix allocation and multihomed MNs: >> >> The first bullet on page 18 states that the LMA "MUST ensure the >> allocated prefix is not in use by any other mobile node". In the >> context of regular IP nodes that are multihomed, we discussed how it >> is problematic when the same prefix/address is allocated to multiple >> interfaces of the same node. To prevent that problem, are we assuming > >> that every distinct interface of an MN attached to the PMIP domain has > >> a different unique identity? If so, that needs to be stated. IMO, >> that may not be practical, especially, if an NAI is used as the MN ID. > >> So, in those cases, we really need to ensure that the LMA is not >> allocating the same prefix to multiple interfaces of a multihomed MN. > >> I think an appropriate rewording of this sentence may be something >> like "the LMA MUST ensure the allocated prefix is not already in use, >> i.e., there is no existing BCE for that prefix on the LMA". >> >> I also recall that the document is supposed to state that the protocol > >> does not support multihomed MNs more generically, but, I couldn't find > >> such text. Did I miss it? > > Vijay: > > The conclusion from that thread was the multi-homing is out of scope for > the base PMIPv6 spec and not supported in the base PMIPv6 document. I > had proposed some text at that time. We never concluded on that." > > We need to conclude this issue. The tracker somehow shows this issue as > "closed" (issue #166 on the tracker) and I'm not sure why. Other than > stating that multihoming is out of scope, we need to state one of the > following two things: > > - that PMIP is only intended for networks that have control over the > types of IP devices attaching to their networks and the burden is on the > administrators/network designers to ensure that multihomed IP devices > are not attaching using more than one interface to the same PMIP6 domain > (this is not the option I recommend) > > (OR) > > - define LMA behavior such that regular multihomed IP devices don't run > into issues of connectivity or shutting down interfaces. This is much > more logical in my view and it is not a big change in the document. > > Thanks, > Vidya > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 04:59:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaSjJ-0001oD-5v; Wed, 26 Sep 2007 04:58:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaSjH-0001nV-I7 for netlmm@ietf.org; Wed, 26 Sep 2007 04:58:47 -0400 Received: from cluster-h.mailcontrol.com ([85.115.42.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaSjB-0003gV-EC for netlmm@ietf.org; Wed, 26 Sep 2007 04:58:47 -0400 Received: from rly12h.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly12h.srv.mailcontrol.com (MailControl) with ESMTP id l8Q8wPC8023485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 09:58:28 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly12h.srv.mailcontrol.com (MailControl) id l8Q8vVD0018559 for netlmm@ietf.org; Wed, 26 Sep 2007 09:57:31 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly12h-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8Q8vQhr018300; Wed, 26 Sep 2007 09:57:30 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 5348_d934c282_6c0d_11dc_9d1c_0030482aac25; Wed, 26 Sep 2007 10:52:44 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092610572256-4886 ; Wed, 26 Sep 2007 10:57:22 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.102,BAYES_00: -1.665,TOTAL_SCORE: -1.563 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 26 Sep 2007 10:57:15 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAL5xXA References: To: "Narayanan, Vidya" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D19@lan-ex-02.panasonic.de> Date: Wed, 26 Sep 2007 10:57:11 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.72.1.122 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, I agree that we need some text about this issue. Narayanan, Vidya wrote: > - define LMA behavior such that regular multihomed IP devices=20 > don't run > into issues of connectivity or shutting down interfaces. This is much > more logical in my view and it is not a big change in the document.=20 Can you elaborate how this would work? How does the LMA differentiate between PBUs that were triggered by the same vs different MN interfaces? I guess the MAG would need to include some kind of MN physical network interface ID in the PBU, but what kind of ID would that be and how does the MAG learn that ID? Note that the MN's link-local address may not work as an ID in general, since the MN may implement a kind of virtual network interface which hides multiple physical network interfaces and only exposes a single (virtual) network interface to the IP stack. This may result in the same link-local address for multiple physical interfaces.=20 So do we need to mandate something on the MN side to solve this issue in the general case? Kilian Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 04:59:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaSjP-00022S-O0; Wed, 26 Sep 2007 04:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaSjP-000212-30 for netlmm@ietf.org; Wed, 26 Sep 2007 04:58:55 -0400 Received: from cluster-g.mailcontrol.com ([85.115.41.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaSjK-0003gh-LX for netlmm@ietf.org; Wed, 26 Sep 2007 04:58:55 -0400 Received: from rly05g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly05g.srv.mailcontrol.com (MailControl) with ESMTP id l8Q8wXHg005823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 09:58:35 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly05g.srv.mailcontrol.com (MailControl) id l8Q8vge8000585 for netlmm@ietf.org; Wed, 26 Sep 2007 09:57:42 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly05g-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8Q8vWBI032395; Wed, 26 Sep 2007 09:57:42 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 5435_dce444a2_6c0d_11dc_99c9_0030482aac25; Wed, 26 Sep 2007 10:52:50 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092610572649-4891 ; Wed, 26 Sep 2007 10:57:26 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.102,BAYES_00: -1.665,TOTAL_SCORE: -1.563 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 26 Sep 2007 10:57:15 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: Acf/sdrXSWxVJRmzQ6G5BsvD3b9qQQAKS7SgAAzXM0A= References: <46F96DF7.1000702@azairenet.com> To: "Narayanan, Vidya" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> Date: Wed, 26 Sep 2007 10:56:41 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.71.1.115 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Narayanan, Vidya wrote: > > > - Security considerations: MAG Compromise:=20 ... > If we claim this is an issue in the security considerations=20 > section and > claim that the fix to it is for the LMA to ensure the MN is actually > attached to the MAG, we can't quite hand wave on some possible ways to > do that. Those are just hints for deployments that are=20 > concerned about > MAG compromise. But, those hints need to be captured in the security > considerations section. The threats document captures this threat and > it is a valid one - so, I believe we need some text here. The type of > "detail" is what I tried to provide with the examples on AAA checks or > CGA signatures - and, I don't think we need a lot of detail=20 > here; a few > sentences would be good.=20 >=20 I had a similar comment a while ago. I think that a draft describing a severe security issue should at least give hints how this can be solved. Recently Sri, Vijay, Kuntal and I had an offline discussion about another possible solution to detect a compromised MAGs, which relies on PMIP signaling only. The basic idea is that if two MAGs simultaneously claim that the MN is attached, one of the MAGs must lie and is probably a compromised MAG. The assumption is that the MN cannot at the same time be attached to two MAGs, at least not with the same network interface. More specifically, when the LMA accepts a valid PBU from a new MAG, it changes the BCE (i.e., there is no impact on handover delay) and notifies the old MAG (i.e., old address in BCE) about this. The old MAG then checks whether the MN is still attached. If this is the case, it informs the LMA about this. The LMA then learns that two different MAGs claim MN attachement, which is not possible under the assumption stated above. Hence, after receiving one or more such notifications, the LMA can identify the compromised MAG and stop trusting this MAG. A remaining problem was which message should be used to inform the old MAG about the BCE change. PBA and revocation msg were discussed, but the former is not sent unsolicited according to RFC3775 (which could be overidden by PMIP spec of course) and the latter is not standardized yet. Comments? Kilian Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 05:40:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaTNU-0003jo-BV; Wed, 26 Sep 2007 05:40:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaTNS-0003fY-JG for netlmm@ietf.org; Wed, 26 Sep 2007 05:40:18 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IaTNR-0004Ye-9B for netlmm@ietf.org; Wed, 26 Sep 2007 05:40:18 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1190799597!9051969!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 4598 invoked from network); 26 Sep 2007 09:39:58 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-3.tower-153.messagelabs.com with SMTP; 26 Sep 2007 09:39:58 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8Q9dvHT007657; Wed, 26 Sep 2007 02:39:57 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8Q9du0m027986; Wed, 26 Sep 2007 04:39:57 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8Q9dscZ027810; Wed, 26 Sep 2007 04:39:55 -0500 (CDT) Message-ID: <46FA28E1.5010106@gmail.com> Date: Wed, 26 Sep 2007 11:39:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sri Gundavelli References: <46F848E2.40904@ericsson.com> <001f01c7ff31$1cf18860$1220fea9@amer.cisco.com> <46F8FF2A.2010701@gmail.com> <00d501c7fff1$b578c2e0$1220fea9@amer.cisco.com> In-Reply-To: <00d501c7fff1$b578c2e0$1220fea9@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000776-1, 24/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: netlmm@ietf.org Subject: [netlmm] Re: DHCP Relay link-address use is probably inapppropriate X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, more details below. In short: (1) I know three DHCPv6 implementations that don't use your 'link-address' recommendation; two of them use the Interface ID instead. (2) which implementation of 'link-address' field are you talking about? (3) logically speaking, in order to make your intention work (use 'link-address' as the prefix of the ptp link MN-AR) we need a prefix field next to the 'link-address' field in RELAY-FORWARD, otherwise it can't work; (4) how can every MAG make sure it has Cafe::1/64 on its own virtual interface whenever that certain MN attaches to it? So I don't think we should write the recommendation of 'link-address' in DHCP RELAY-FORWARD. Sri Gundavelli wrote: > Hi Alex, > > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, September 25, >> 2007 5:30 AM To: Sri Gundavelli Cc: 'Suresh Krishnan'; >> netlmm@ietf.org Subject: Re: DHCP Relay link-address use is >> probably inapppropriate (was: [netlmm] Suresh's review of >> draft-ietf-netlmm-proxymip6-05) >> >> Sri Gundavelli wrote: [...] >>>> Section 6.11 ============ >>>> >>>> I am not sure how the MAG can send the HNP of the MN in the >>>> link-address field of the DHCP relay message since the >>>> link-address field does not contain a prefix length. Is there >>>> an implicit assumption that the prefix will be 64 bits in >>>> length? >>>> >>> This is per 3315. I will look into the format. >> I think here may be an error of interpretation or of specification. >> >> >> >> RFC3315: >>> If the relay agent received the message to be relayed from a >>> client, the relay agent places a global or site-scoped address >>> with a prefix assigned to the link on which the client should be >>> assigned an address in the link-address field. >> I think it wrongly says "with a prefix". Because: (1) it makes >> people think there is a prefix length in that field, (2) the DHCP >> RELAY-FORWARD doesn't encode a prefix length (3315 pp 18) (3) >> wireshark doesn't show a prefix length field, (4) Dibbler >> implementation doesn't encode a prefix length but a full /128 >> address in that field, it's the address of the Relay interface on >> which a mobile attaches. >> > > Yes. I agree. I used to say, "prefix pool hint". Its the address on > the interface of the AR that is hosting the prefix. You are right. > Lets take Cafe::/64 as the pool. The AR has Cafe::1 on the interface, > the DHCP server will allocate an address from the pool "cafe". Thats > all to this dhcp based address configuration. This is DHCPv4 (not DHCPv6) implementation. And, this assumes that _any_ Relay to which MN will attach will have configured the Cafe::1/64 address on its (virtual) interface. Otherwise DHCP can't deliver same home address to MN wherever it attaches. How does the Relay always obtains that Cafe::1/64 for its interface when that particular MN attaches to it? > I think, once an IPv6 link is configured and is up, all the IPv6 > properties on that link should survive. It should not matter if the > link is configured dynamically or statically. I think I agree in general on this, for DHCPv4. If the MN-AR is a virtual interface and is put up dynamically at MAG/DHCP Relay, then the prefix and address configured on it and the address is taken by the Relay and sent to the Server in the 'link-address' field. What you're saying (IP link up and configured conserves all IP properties) is true for a DHCP _v4_ configuration, not DHCPv6. Running DHCPv4 Relay on a wifi link, and having configured that link with a certain prefix (/24 or other) makes the Server assign an address to that node within that prefix, because the server has the prefix configured in its configuration file (the 'subnet' in the config file). It is sufficient for the Relay to put the DHCP Relay's address in the 'link-address' field of the RELAY-FORW, and the Server will match that to the 'subnet' from config file, in order to assign an address from the pool defined within that subnet. That is ok. However, with DHCPv6 the story is different. ISC DHCP alpha most recent implementation has an equivalent 'subnet6' clause at server but no Relay implementation, unfortunately. Its 'subnet6' works only when the Server is located on the MAG (and you seem to oppose that). When and how a Relay is available and how it will work is speculation. Dibbler and WIDE DHCP Server and Relay implementations Servers' configuration files don't have this 'subnet' nor 'subnet6' fields. They do have Relay implementations and they can have prefixes on Relay interfaces, but the allocation is done by using a Interface ID in the RELAY-FORWARD message, and the 'link-address field' is not used. Basically the Server's configuration file configures interface id '1' for a Relay's interface that the Relay also calls '1'; this configuration is consistent across all Relays and the Server, and a unique IPv6 address is assigned according to this interface id. > Its very important that we dont see the MN-AR link as a special link. > The MAG vendors should have the ability to drop in features, say, > Firewall, Access Security protocols ... or what ever services that > are built for an IPv6 access link. This is a design goal, IMHO. I fully agree it is important we don't see the MN-AR link as any special link. I am not sure about which MAG vendors you talk about and about which implementations. If you take the three implementations I've described above - none follows your suggestion. One (ISC) _may_ in the future but the other two don't and don't even need, because they use Interface ID instead of 'link address'. So I am not sure why insisting with the recommendation to use 'link-address' field when existing DHCPv6 implementations don't use it. Alex PS: why do we need a prefix length field next to the 'link-address' field in DHCP RELAY-FORW in order to make this work? It's simple, because the Server needs to match the first _n_ common bits of the Relay's address and _n_ bits of the address configured in the Server's config file ('subnet6'). Makes no sense to longest prefix match _n_ bits from the 'subnet6' with an Relay's 'link-addresss having no prefix: this can easily lead to confusion in deployment. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 05:48:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaTUr-0005m3-1s; Wed, 26 Sep 2007 05:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaTUp-0005hP-7n for netlmm@ietf.org; Wed, 26 Sep 2007 05:47:55 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IaTUn-0004gu-Vw for netlmm@ietf.org; Wed, 26 Sep 2007 05:47:55 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1190800052!4698345!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 337 invoked from network); 26 Sep 2007 09:47:32 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-12.tower-153.messagelabs.com with SMTP; 26 Sep 2007 09:47:32 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l8Q9lWbJ026062; Wed, 26 Sep 2007 02:47:32 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8Q9lVQs004150; Wed, 26 Sep 2007 04:47:31 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8Q9lSbf003973; Wed, 26 Sep 2007 04:47:29 -0500 (CDT) Message-ID: <46FA2AA8.7060009@gmail.com> Date: Wed, 26 Sep 2007 11:47:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000776-1, 24/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Basavaraj Patil wrote: > Hi Vidya, > > Multihomed MNs and how PMIP6 deals with them are out of scope in the context > of this document. If this is really important, then it should be specified > in a separate I-D. > > I realize the problem that you are stating and this is the same that was > discussed some time back. At least my recollection was that we would not > deal with multihoming or how to avoid assigning the same address to multiple > interfaces on an MN. > > I am just wondering if the LMA would really assign the same prefix to > multiple interfaces of an MN and in what scenario this would happen. > Basically when the LMA has assigned a prefix to an MN (to a specific > interface), that prefix is marked as assigned in the pool of prefixes. Sorry Raj, but what method of assigning prefixes are you describing? You are using the word 'pool' of prefixes, and this makes me think you mean DHCP. (draft-06 uses 'pool' in the DHCP Section, and DHCP software has some 'pool' clauses). But DHCP for PMIP6 is very unclear at this point, I think it can't work as the text suggests. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 07:52:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVQH-00070U-RB; Wed, 26 Sep 2007 07:51:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVQG-0006yJ-Ue for netlmm@ietf.org; Wed, 26 Sep 2007 07:51:21 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaVQG-0004Mu-Ay for netlmm@ietf.org; Wed, 26 Sep 2007 07:51:20 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8QBo2EF002620; Wed, 26 Sep 2007 14:50:29 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 14:49:55 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 06:49:52 -0500 Received: from 10.241.59.237 ([10.241.59.237]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 Sep 2007 11:49:52 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 26 Sep 2007 06:49:55 -0500 Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs From: Basavaraj Patil To: ext Kilian Weniger , "Narayanan, Vidya" Message-ID: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAL5xXAAAkKj1o= In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D19@lan-ex-02.panasonic.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 11:49:52.0819 (UTC) FILETIME=[59B16830:01C80033] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Kilian, On 9/26/07 3:57 AM, "ext Kilian Weniger" wrote: > Hi Vidya, > > I agree that we need some text about this issue. > > Narayanan, Vidya wrote: >> - define LMA behavior such that regular multihomed IP devices >> don't run >> into issues of connectivity or shutting down interfaces. This is much >> more logical in my view and it is not a big change in the document. > > Can you elaborate how this would work? How does the LMA differentiate > between PBUs that were triggered by the same vs different MN interfaces? > > > I guess the MAG would need to include some kind of MN physical network > interface ID in the PBU, but what kind of ID would that be and how does > the MAG learn that ID? Note that the MN's link-local address may not > work as an ID in general, since the MN may implement a kind of virtual > network interface which hides multiple physical network interfaces and > only exposes a single (virtual) network interface to the IP stack. This > may result in the same link-local address for multiple physical > interfaces. > > So do we need to mandate something on the MN side to solve this issue in > the general case? One of the tenets of Netlmm protocol has been to not require any changes or requirements on the MN. So it is not an option. Issues that arise from multi-homing and how to deal with them should be dealt separately and not in the scope of this I-D. -Raj > > Kilian > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 08:36:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaW70-00073k-C9; Wed, 26 Sep 2007 08:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaW6y-0006vm-GX for netlmm@ietf.org; Wed, 26 Sep 2007 08:35:28 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaW6s-0000i7-97 for netlmm@ietf.org; Wed, 26 Sep 2007 08:35:28 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1IaW6W02iq-0008Ic; Wed, 26 Sep 2007 08:35:02 -0400 From: "Alper Yegin" To: Date: Wed, 26 Sep 2007 15:34:51 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKA== Message-Id: <0MKp8S-1IaW6W02iq-0008Ic@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18DV8paXmBoAbByy0sFDof2id6rAquZ3Pza3RK ZtnP+HZ9EVQUMotKX07G3yS+XHYET1MIt+PGMSO02EawX+txnP SuJXjKUARLSceGJZ6plQA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [netlmm] MN-Id overspecification X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org This issue is still hanging. So far as I understand the MN-Id is only used for performing HNP assignment in-band with PMIP6 signaling. In case HNP is already assigned, there is no need to be carrying any info that directly or indirectly points to the MN's identity. But on the other hand, MN-id is all over the spec with normative languages that suggest it be present in every message. This is an overspecification, reducing flexibility and getting in the ways of various deployment scenarios. I recommend we change the spec such that MN-id is only mandated when HNP needs to be assigned. Would there be an objection to that? Is there any technical reason to carry an identifier of the MN in every PMIP6 message? Alper _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 09:02:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaWWn-000246-UU; Wed, 26 Sep 2007 09:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaWWm-00023I-IS for netlmm@ietf.org; Wed, 26 Sep 2007 09:02:08 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IaWWh-0001GL-6P for netlmm@ietf.org; Wed, 26 Sep 2007 09:02:08 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1190811713!7904047!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 16730 invoked from network); 26 Sep 2007 13:01:54 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-7.tower-153.messagelabs.com with SMTP; 26 Sep 2007 13:01:54 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l8QD1rvs028554; Wed, 26 Sep 2007 06:01:53 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8QD1qci019999; Wed, 26 Sep 2007 08:01:53 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8QD1o9W019883; Wed, 26 Sep 2007 08:01:51 -0500 (CDT) Message-ID: <46FA5838.9040206@gmail.com> Date: Wed, 26 Sep 2007 15:01:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKp8S-1IaW6W02iq-0008Ic@mrelay.perfora.net> In-Reply-To: <0MKp8S-1IaW6W02iq-0008Ic@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000776-1, 24/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > This issue is still hanging. > > So far as I understand the MN-Id is only used for performing HNP assignment > in-band with PMIP6 signaling. In case HNP is already assigned, there is no > need to be carrying any info that directly or indirectly points to the MN's > identity. > > But on the other hand, MN-id is all over the spec with normative languages > that suggest it be present in every message. > > This is an overspecification, reducing flexibility and getting in the ways > of various deployment scenarios. > > I recommend we change the spec such that MN-id is only mandated when HNP > needs to be assigned. > > Would there be an objection to that? Is there any technical reason to carry > an identifier of the MN in every PMIP6 message? I suggest that when DHCP is used to assign the address to the Mobile to use the Remote-ID or the Subscriber-ID, and not the MAG's 'link-address'. I don't know what you mean by MN-Id? Is this a NAI? DHCP doesn't use 'MN-Id'. I also think that the only possible ways to assign addresses on the mobile are: auto-forming the LL address, stateless RS/RA, stateful DHCP and PPP IPv6 LCP. I think there isn't any other and the PMIP6 shouldn't define a new one either. Alex Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 09:04:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaWYx-0003fI-Ki; Wed, 26 Sep 2007 09:04:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaWYw-0003fB-TL for netlmm@ietf.org; Wed, 26 Sep 2007 09:04:22 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaWYr-0001Iz-NI for netlmm@ietf.org; Wed, 26 Sep 2007 09:04:22 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8QD46p09870; Wed, 26 Sep 2007 13:04:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Date: Wed, 26 Sep 2007 08:02:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116FA9A1C@zrc2hxm2.corp.nortel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: Acf/sdrXSWxVJRmzQ6G5BsvD3b9qQQAKS7SgAAzXM0AAC4LBIA== References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> From: "Ahmad Muhanna" To: "Kilian Weniger" , "Narayanan, Vidya" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, Please see comments below. Regards, Ahmad > Subject: Compromised MAG issue (was [netlmm] Review of=20 > draft-ietf-netlmm-proxymip6-05) >=20 > Narayanan, Vidya wrote: > > > > - Security considerations: MAG Compromise:=20 > ... > > If we claim this is an issue in the security considerations section=20 > > and claim that the fix to it is for the LMA to ensure the MN is=20 > > actually attached to the MAG, we can't quite hand wave on some=20 > > possible ways to do that. Those are just hints for=20 > deployments that=20 > > are concerned about MAG compromise. But, those hints need to be=20 > > captured in the security considerations section. The=20 > threats document=20 > > captures this threat and it is a valid one - so, I believe we need=20 > > some text here. The type of "detail" is what I tried to=20 > provide with=20 > > the examples on AAA checks or CGA signatures - and, I don't=20 > think we=20 > > need a lot of detail here; a few sentences would be good. > >=20 >=20 > I had a similar comment a while ago. I think that a draft describing a > severe security issue should at least give hints how this can=20 > be solved. >=20 > Recently Sri, Vijay, Kuntal and I had an offline discussion about > another possible solution to detect a compromised MAGs, which=20 > relies on > PMIP signaling only. >=20 > The basic idea is that if two MAGs simultaneously claim that the MN is > attached, one of the MAGs must lie and is probably a compromised MAG. > The assumption is that the MN cannot at the same time be=20 > attached to two > MAGs, at least not with the same network interface. >=20 > More specifically, when the LMA accepts a valid PBU from a new MAG, it > changes the BCE (i.e., there is no impact on handover delay) and > notifies the old MAG (i.e., old address in BCE) about this.=20 > The old MAG > then checks whether the MN is still attached. If this is the case, it > informs the LMA about this. The LMA then learns that two=20 > different MAGs > claim MN attachement, which is not possible under the=20 > assumption stated > above. Hence, after receiving one or more such notifications, the LMA > can identify the compromised MAG and stop trusting this MAG. >=20 > A remaining problem was which message should be used to inform the old > MAG about the BCE change. PBA and revocation msg were=20 > discussed, but the > former is not sent unsolicited according to RFC3775 (which could be > overidden by PMIP spec of course) and the latter is not standardized > yet. >=20 > Comments? [Ahmad] Hmmm. I guess that highlight the fact that binding revocation is probably important for PMIPv6 base protocol deployment. I would recommend that PMIPv6 base protocol continue to refer to this issue as out-of-scope and: 1. Capture this scenario in the binding revocation draft under the section related to PMIPv6 applicability. 2. Speed the process of addressing binding revocation by tagging it as required for PMIPv6 deployment. 3. Kill 2 birds in one stone, PMIPv6 is advanced as per the plan to IESG and speed up the adoption of binding revocation. Does this sound a good plan? >=20 > Kilian >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 09:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaWhj-0006kH-UB; Wed, 26 Sep 2007 09:13:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaWhi-0006fG-5X for netlmm@ietf.org; Wed, 26 Sep 2007 09:13:26 -0400 Received: from cluster-h.mailcontrol.com ([85.115.42.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaWhh-0006UM-KR for netlmm@ietf.org; Wed, 26 Sep 2007 09:13:26 -0400 Received: from rly16h.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly16h.srv.mailcontrol.com (MailControl) with ESMTP id l8QDD1wi029865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 14:13:18 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly16h.srv.mailcontrol.com (MailControl) id l8QDBERd022912 for netlmm@ietf.org; Wed, 26 Sep 2007 14:11:14 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly16h-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8QDBBAx022698; Wed, 26 Sep 2007 14:11:14 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 538a_4cceef74_6c31_11dc_8d2a_0030482aac25; Wed, 26 Sep 2007 15:06:30 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092615110482-27306 ; Wed, 26 Sep 2007 15:11:04 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.100,BAYES_00: -1.665,TOTAL_SCORE: -1.565 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 26 Sep 2007 15:10:54 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAL5xXAAAkKj1oAAiragA== References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D19@lan-ex-02.panasonic.de> To: "Basavaraj Patil" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> Date: Wed, 26 Sep 2007 15:10:47 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.72.1.126 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Raj, I think we should differentiate between two cases: 1. supporting multi-homing requested by the host to achieve features like load balancing, failover etc. 2. preventing that PMIP protocol breaks if an unmodified host activates more than one network interface. For case 1, I agree with you that this is out of scope of the base draft and should be handled in a separate multi-homing document. But I think Vidya was talking about case 2 and I agree that this issue should be addressed in the base draft.=20 Currently, I see the following potential issues if an unmodified host activates more than one network interface and happens to attach to more than one MAG of a given PMIP domain simultaneously: - multiple MN interfaces get the same prefix assigned, which may break something (e.g., routing) in the host and may result in loss of connectivity - BCE at LMA constantly and randomly changes since multiple MAGs send PBUs to the LMA for the same MN. This may result in packet loss both in downlink and uplink. - the MAGs may discover and use different LMA addresses for the same host etc. However, I'm not sure how we can solve this issue without modifying the host or mandating not to use multiple interfaces. Any ideas? BR, Kilian > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Mittwoch, 26. September 2007 13:50 > To: ext Kilian Weniger; Narayanan, Vidya > Cc: netlmm@ietf.org > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 >=20 > Kilian, >=20 >=20 >=20 >=20 > On 9/26/07 3:57 AM, "ext Kilian Weniger"=20 > > wrote: >=20 > > Hi Vidya, > >=20 > > I agree that we need some text about this issue. > >=20 > > Narayanan, Vidya wrote: > >> - define LMA behavior such that regular multihomed IP devices > >> don't run > >> into issues of connectivity or shutting down interfaces. =20 > This is much > >> more logical in my view and it is not a big change in the document. > >=20 > > Can you elaborate how this would work? How does the LMA=20 > differentiate > > between PBUs that were triggered by the same vs different=20 > MN interfaces? > >=20 > >=20 > > I guess the MAG would need to include some kind of MN=20 > physical network > > interface ID in the PBU, but what kind of ID would that be=20 > and how does > > the MAG learn that ID? Note that the MN's link-local address may not > > work as an ID in general, since the MN may implement a kind=20 > of virtual > > network interface which hides multiple physical network=20 > interfaces and > > only exposes a single (virtual) network interface to the IP=20 > stack. This > > may result in the same link-local address for multiple physical > > interfaces.=20 > >=20 > > So do we need to mandate something on the MN side to solve=20 > this issue in > > the general case? >=20 > One of the tenets of Netlmm protocol has been to not require=20 > any changes or > requirements on the MN. So it is not an option. >=20 > Issues that arise from multi-homing and how to deal with them=20 > should be > dealt separately and not in the scope of this I-D. >=20 > -Raj >=20 > >=20 > > Kilian > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 09:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXF7-0007Hf-Go; Wed, 26 Sep 2007 09:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXF6-0007ES-Es for netlmm@ietf.org; Wed, 26 Sep 2007 09:47:56 -0400 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaXF0-0002O9-BL for netlmm@ietf.org; Wed, 26 Sep 2007 09:47:56 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1418494nzf for ; Wed, 26 Sep 2007 06:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OHW+zlRxWdD9gY4ekZBdMHCZQXSUmyk52yAWosPcsI4=; b=QgWQT1zYjTNu+aVRobv6ql2FyPI0udqpKgvpRNtKBm7VGAd/mBZV9TYrKHmjTSWCZez1zW/nudq8KrjOW30LJizZBobSzmOOaz7upm/4QyVOlsE7DeZ3HRPqsppartCuUiDQzzQfibpU/Qsh4FDoCtzGWDny8YZeh1R0gTkWJK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qbv0iaoT2SnUEDOmgwo5VM0dwtAI9Xi23shZrSw6VhR3DhkiG3U26i8bUVCNw8fE2Fsiyy4ebEaToXEs7LzFoXcv0jkxkd1au4P1ObmbhHcmjm59Ul5y1u3JBo2/dckKLwm9BxncqJ0f+bFOLUxOKSII7MtZdGTvCWzU66/e5pc= Received: by 10.142.213.9 with SMTP id l9mr612678wfg.1190814459325; Wed, 26 Sep 2007 06:47:39 -0700 (PDT) Received: by 10.143.166.2 with HTTP; Wed, 26 Sep 2007 06:47:39 -0700 (PDT) Message-ID: <1d38a3350709260647u2154b004xd7bc2d4b2da6a17b@mail.gmail.com> Date: Wed, 26 Sep 2007 21:47:39 +0800 From: "Hui Deng" To: "Kilian Weniger" Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D19@lan-ex-02.panasonic.de> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sorry for my jumping in, > - multiple MN interfaces get the same prefix assigned, which may break > something (e.g., routing) in the host and may result in loss of > connectivity could it be possible that the same prefix, but different address? thanks, -Hui _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 10:00:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXQp-0006nl-Gb; Wed, 26 Sep 2007 10:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXQn-0006im-CM for netlmm@ietf.org; Wed, 26 Sep 2007 10:00:01 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaXQb-0002g5-AM for netlmm@ietf.org; Wed, 26 Sep 2007 09:59:56 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8QDxTh16905; Wed, 26 Sep 2007 13:59:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Wed, 26 Sep 2007 08:58:31 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116FA9BCC@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/T/RrZEqQFEePT3u9QfI2QIenQAAcXPfQAAcW7+AAGYjB4A== References: <6FC4416DDE56C44DA0AEE67BC7CA437116F669B2@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Narayanan, Vidya" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Tuesday, September 25, 2007 8:38 PM > To: Muhanna, Ahmad (RICH1:2H10); netlmm@ietf.org > Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 >=20 > Hi Ahmad,=20 >=20 > > > - NAI option in the PBA:=20 > > >=20 > > > Why is it needed? > >=20 > > [Ahmad] > > There is a very good reason to have NAI in the P-BA. > >=20 > > In case that we have SQN used for ordering the P-BU/P-BA,=20 > there is a=20 > > great possibility of SQN collision. In this case, MAG needs=20 > the NAI to=20 > > match the P-BA to the outstanding P-BU. > >=20 >=20 > Hmmm.. In this case, I can see the use in including the MN ID=20 > in the first PBA, but, subsequently, the HNP should be=20 > sufficient to match it to the MN in the PBU and PBA, right?=20 [Ahmad] Technically; Yes I agree. However, this message is not transmitted over the air, Are we concerned about the size of the message here? I guess including NAI in the initial P-BU and not in re-registration P-BU adds some complexity to the MAG and probably a lot to the LMA. If there is no real concern about including the NAI, I would recommend keeping it unless there a serious advantage in making such recommendation. >=20 > Vidya >=20 > > Regards, > > Ahmad > >=20 > > >=20 > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 10:16:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXg7-0000EL-Jo; Wed, 26 Sep 2007 10:15:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXg7-0000EG-56 for netlmm@ietf.org; Wed, 26 Sep 2007 10:15:51 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXg6-0008SD-AT for netlmm@ietf.org; Wed, 26 Sep 2007 10:15:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8QEFSmB019800; Wed, 26 Sep 2007 17:15:38 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 17:15:26 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 09:14:40 -0500 Received: from 10.241.59.237 ([10.241.59.237]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 Sep 2007 14:14:40 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 26 Sep 2007 09:14:42 -0500 Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs From: Basavaraj Patil To: ext Kilian Weniger Message-ID: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAL5xXAAAkKj1oAAiragAAC451g In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 14:14:40.0568 (UTC) FILETIME=[93FEB380:01C80047] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Kilian, While it is possible that a multi-interface MN can attach to different MAGs which cause the MAGs to send a PBU to the same LMA, I personally think that dealing with this is more of an academic exercise at the present time. I do not believe we have the possibility of making any changes to the MN. So that route is closed... At least for now. So here is how I view the current scenario which IMO is academic at this time and hence not something that we should be spending a lot of time on : - If an MN attaches to multiple MAGs via different interfaces this would trigger the MAGs to send PBUs to the LMA - If the LMA receives them almost simultaneously (as an example), and a PBAck has not been sent, then the LMA can choose to create an entry in the BC for the last received PBU and ACK only the last received PBU (the LMA would believe that the MN which attached to MAG1 moved to MAG2 resulting in the transmission of PBUs from MAG1 and MAG2 near simulatenously) - If the MN receives a PBU from another MAG for an MN which has an entry in the BC as a result of a second interface attaching to a MAG, the LMA would view this as the MN having moved to MAG2 and hence would delete the BCE for MAG1 and insert MAG2 for the MN But if we merely state (or mandate) that the LMA will only have only one MAG entry in the BC at any given time, we would not have a problem with the multi-homing scenario, right? -Raj On 9/26/07 8:10 AM, "ext Kilian Weniger" wrote: > Hi Raj, > > I think we should differentiate between two cases: > 1. supporting multi-homing requested by the host to achieve features > like load balancing, failover etc. > 2. preventing that PMIP protocol breaks if an unmodified host activates > more than one network interface. > > For case 1, I agree with you that this is out of scope of the base draft > and should be handled in a separate multi-homing document. > > But I think Vidya was talking about case 2 and I agree that this issue > should be addressed in the base draft. > > Currently, I see the following potential issues if an unmodified host > activates more than one network interface and happens to attach to more > than one MAG of a given PMIP domain simultaneously: > - multiple MN interfaces get the same prefix assigned, which may break > something (e.g., routing) in the host and may result in loss of > connectivity > - BCE at LMA constantly and randomly changes since multiple MAGs send > PBUs to the LMA for the same MN. This may result in packet loss both in > downlink and uplink. > - the MAGs may discover and use different LMA addresses for the same > host etc. > > However, I'm not sure how we can solve this issue without modifying the > host or mandating not to use multiple interfaces. Any ideas? > > BR, > > Kilian > > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Mittwoch, 26. September 2007 13:50 >> To: ext Kilian Weniger; Narayanan, Vidya >> Cc: netlmm@ietf.org >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >> >> >> Kilian, >> >> >> >> >> On 9/26/07 3:57 AM, "ext Kilian Weniger" >> >> wrote: >> >>> Hi Vidya, >>> >>> I agree that we need some text about this issue. >>> >>> Narayanan, Vidya wrote: >>>> - define LMA behavior such that regular multihomed IP devices >>>> don't run >>>> into issues of connectivity or shutting down interfaces. >> This is much >>>> more logical in my view and it is not a big change in the document. >>> >>> Can you elaborate how this would work? How does the LMA >> differentiate >>> between PBUs that were triggered by the same vs different >> MN interfaces? >>> >>> >>> I guess the MAG would need to include some kind of MN >> physical network >>> interface ID in the PBU, but what kind of ID would that be >> and how does >>> the MAG learn that ID? Note that the MN's link-local address may not >>> work as an ID in general, since the MN may implement a kind >> of virtual >>> network interface which hides multiple physical network >> interfaces and >>> only exposes a single (virtual) network interface to the IP >> stack. This >>> may result in the same link-local address for multiple physical >>> interfaces. >>> >>> So do we need to mandate something on the MN side to solve >> this issue in >>> the general case? >> >> One of the tenets of Netlmm protocol has been to not require >> any changes or >> requirements on the MN. So it is not an option. >> >> Issues that arise from multi-homing and how to deal with them >> should be >> dealt separately and not in the scope of this I-D. >> >> -Raj >> >>> >>> Kilian >>> >>> >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 >>> Managing Director: Thomas Micke >>> >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> >> >> > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 10:17:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXhb-0004lC-Gt; Wed, 26 Sep 2007 10:17:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXha-0004l7-NJ for netlmm@ietf.org; Wed, 26 Sep 2007 10:17:22 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXha-0008Vk-76 for netlmm@ietf.org; Wed, 26 Sep 2007 10:17:22 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8QEHHA23717; Wed, 26 Sep 2007 14:17:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 Date: Wed, 26 Sep 2007 09:16:29 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116FA9C86@zrc2hxm2.corp.nortel.com> In-Reply-To: <46F966FA.2020609@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/rbS5EKljgLyPQ+2Fch+9P6DmAAAmI0zg References: <46F848E2.40904@ericsson.com> <46F852A3.1040401@azairenet.com> <46F91662.6030200@ericsson.com> <6FC4416DDE56C44DA0AEE67BC7CA437116F660AB@zrc2hxm2.corp.nortel.com> <46F9607E.5030504@ericsson.com> <6FC4416DDE56C44DA0AEE67BC7CA437116F66480@zrc2hxm2.corp.nortel.com> <46F966FA.2020609@ericsson.com> From: "Ahmad Muhanna" To: "Suresh Krishnan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Suresh, My apologies for not replying earlier. I believe both scenarios that you proposed need a very special circumstances in order for them to happen. It will be a good idea to describe the reality of these scenarios, basically the MN moves quickly between three different MAGs within a second or so. IMO, it is not worth addressing scenarios that, in real deployment, will never happen. One more thing I would like to add here, this case is not specific to timestamp. BTW: IMO, The proposed solution still works but probably no point of going through the details before realizing the reality of these scenarios. One more thing that I suggested earlier to Kilian and I think it was also proposed by Vijay is the use of binding revocation.=20 But let us understand the reality first. I hope you do not mind.=20 Best Regards, Ahmad > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20 > Sent: Tuesday, September 25, 2007 2:52 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: Vijay Devarapalli; netlmm@ietf.org > Subject: Re: [netlmm] Suresh's review of=20 > draft-ietf-netlmm-proxymip6-05 >=20 > Hi Ahmad, >=20 > Ahmad Muhanna wrote: > > Hi Suresh, > >=20 > > I still believe it is the same problem and the same solution is=20 > > applicable as follows: > >=20 > > **** I cut and pasted your scenario and added my comments. ****** >=20 > Thanks a lot for doing this. It makes the discussion easier=20 > and more productive. >=20 > >=20 > > At the LMA, as per your scenario, MN has a BCE with the following > > (P-CoA1 (belongs to MAG1) <-> P-HoA1) > >=20 > > 1. M1: MAG2 sends PBU with Timestamp T (This is lost) [Ahmad] Ok. > >=20 > > 2. M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA and=20 > > updates the binding cache on the LMA) [Ahmad] i. Since LMA did not=20 > > receive M1, M2 is considered a handoff from MAG1 to MAG3. right? > > ii. LMA will create a tentative BCE with (P-CoA3 <-> P-HoA1). Right? > >=20 > > 3. M3: MAG2 retransmits PBU with Timestamp T+x+y(This=20 > arrives at LMA.=20 > > LMA sees that the timestamp is later than the current one and then=20 > > replaces the current entry in the Binding Cache) > >=20 > > [Ahmad] > > Ok, > > i. LMA receive M3 with P-CoA2 and P-HoA1, let us remember=20 > that is the=20 > > content of the P-BU, while tentative BCE is valid. Right? > >=20 > > ii. Since tentative BCE for this MN at LMA is still valid=20 > with (P-CoA3=20 > > <-> P-HoA1), i.e. timer did not expire, LMA recognizes that M3 is=20 > > happening possibly due to race condition during handoff. > > =20 > > iii. LMA rejects M3 with P-BA3 and code "MN-handoff-in-progress". > > iv. MAG2 receives P-BA3 with code "MN-handoff-in-progress" and=20 > > realizes that the MN is possibly no longer attached to it. > >=20 > > v. MAG2 cancels registration and verifies if the MN is=20 > still attached=20 > > before sending another P-BU. > >=20 > > So far, I do not see any problem and it should work just fine.=20 > >=20 > > Do you see any problem in the above? >=20 > Yes, I do see a problem. How do you differentiate the two=20 > following cases with the solution you proposed >=20 > MAG1->MAG2->MAG3 (with MAG2 PBU lost, retransmitted and arriving after > MAG3 PBU) -> Your solution detects this correctly and rejects MAG2 PBU >=20 > and >=20 > MAG1->MAG3->MAG2 (very quick movement from MAG3->MAG2 all=20 > PBUs arrive in=20 > order) -> Your solution detects this incorrectly and rejects=20 > the valid=20 > MAG2 PBU >=20 > Thanks > Suresh >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 10:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXym-0000cl-Jc; Wed, 26 Sep 2007 10:35:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXyl-0000cg-Av for netlmm@ietf.org; Wed, 26 Sep 2007 10:35:07 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXyk-0000WX-Us for netlmm@ietf.org; Wed, 26 Sep 2007 10:35:07 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8QEZ1h01258; Wed, 26 Sep 2007 14:35:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] MN-Id overspecification Date: Wed, 26 Sep 2007 09:34:16 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116FA9D12@zrc2hxm2.corp.nortel.com> In-Reply-To: <0MKp8S-1IaW6W02iq-0008Ic@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNg References: <0MKp8S-1IaW6W02iq-0008Ic@mrelay.perfora.net> From: "Ahmad Muhanna" To: "Alper Yegin" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, Let me understand your concern and your question a little more. Is what you are saying is: In case that a HNP is available at the MAG (how: out-of-scope) and included in the initial P-BU, NO NAI or any other IDs related to the MN should be included? Regards, Ahmad =20 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, September 26, 2007 7:35 AM > To: netlmm@ietf.org > Subject: [netlmm] MN-Id overspecification >=20 > This issue is still hanging. >=20 > So far as I understand the MN-Id is only used for performing=20 > HNP assignment in-band with PMIP6 signaling. In case HNP is=20 > already assigned, there is no need to be carrying any info=20 > that directly or indirectly points to the MN's identity. >=20 > But on the other hand, MN-id is all over the spec with=20 > normative languages that suggest it be present in every message.=20 >=20 > This is an overspecification, reducing flexibility and=20 > getting in the ways of various deployment scenarios. >=20 > I recommend we change the spec such that MN-id is only=20 > mandated when HNP needs to be assigned.=20 >=20 > Would there be an objection to that? Is there any technical=20 > reason to carry an identifier of the MN in every PMIP6 message? >=20 >=20 > Alper >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 10:57:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYKg-0006SF-VM; Wed, 26 Sep 2007 10:57:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYKf-0006Iv-Li for netlmm@ietf.org; Wed, 26 Sep 2007 10:57:45 -0400 Received: from cluster-g.mailcontrol.com ([85.115.41.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaYKd-000157-KN for netlmm@ietf.org; Wed, 26 Sep 2007 10:57:45 -0400 Received: from rly09g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly09g.srv.mailcontrol.com (MailControl) with ESMTP id l8QEvWb0017708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 15:57:38 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly09g.srv.mailcontrol.com (MailControl) id l8QEvRpX017240 for netlmm@ietf.org; Wed, 26 Sep 2007 15:57:27 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly09g-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8QEvHCV015663; Wed, 26 Sep 2007 15:57:26 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 53ab_1efd488e_6c40_11dc_835f_0030482aac25; Wed, 26 Sep 2007 16:52:35 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092616571002-36037 ; Wed, 26 Sep 2007 16:57:10 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.100,BAYES_00: -1.665,TOTAL_SCORE: -1.565 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 26 Sep 2007 16:57:01 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAL5xXAAAkKj1oAAiragAAC451gAAEEqRA= References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> To: "Basavaraj Patil" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> Date: Wed, 26 Sep 2007 16:56:55 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.71.1.119 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Raj, can you explain why you think this an academic exercise? Do you think that a host activating multiple network interfaces is an unrealistic scenario? At least it should be prevented that an unmodified host ends up with the same address configured on multiple interfaces. I think this can currently happen (e.g., with DHCP), right? Mandating that the LMA will have only one MAG entry in the BC at any given time doesn't solve the issues that I listed in my previous mail, since they are independent of the number of entries in the BC. BR, Kilian > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Mittwoch, 26. September 2007 16:15 > To: ext Kilian Weniger > Cc: netlmm@ietf.org > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 >=20 > Kilian, >=20 > While it is possible that a multi-interface MN can attach to=20 > different MAGs > which cause the MAGs to send a PBU to the same LMA, I=20 > personally think that > dealing with this is more of an academic exercise at the present time. >=20 > I do not believe we have the possibility of making any=20 > changes to the MN. So > that route is closed... At least for now. >=20 > So here is how I view the current scenario which IMO is=20 > academic at this > time and hence not something that we should be spending a lot=20 > of time on : >=20 > - If an MN attaches to multiple MAGs via different interfaces=20 > this would > trigger the MAGs to send PBUs to the LMA > - If the LMA receives them almost simultaneously (as an=20 > example), and a > PBAck has not been sent, then the LMA can choose to create an=20 > entry in the > BC for the last received PBU and ACK only the last received=20 > PBU (the LMA > would believe that the MN which attached to MAG1 moved to=20 > MAG2 resulting in > the transmission of PBUs from MAG1 and MAG2 near simulatenously) > - If the MN receives a PBU from another MAG for an MN which=20 > has an entry in > the BC as a result of a second interface attaching to a MAG,=20 > the LMA would > view this as the MN having moved to MAG2 and hence would=20 > delete the BCE for > MAG1 and insert MAG2 for the MN >=20 > But if we merely state (or mandate) that the LMA will only=20 > have only one MAG > entry in the BC at any given time, we would not have a=20 > problem with the > multi-homing scenario, right? >=20 > -Raj >=20 >=20 >=20 >=20 > On 9/26/07 8:10 AM, "ext Kilian Weniger"=20 > > wrote: >=20 > > Hi Raj, > >=20 > > I think we should differentiate between two cases: > > 1. supporting multi-homing requested by the host to achieve features > > like load balancing, failover etc. > > 2. preventing that PMIP protocol breaks if an unmodified=20 > host activates > > more than one network interface. > >=20 > > For case 1, I agree with you that this is out of scope of=20 > the base draft > > and should be handled in a separate multi-homing document. > >=20 > > But I think Vidya was talking about case 2 and I agree that=20 > this issue > > should be addressed in the base draft. > >=20 > > Currently, I see the following potential issues if an=20 > unmodified host > > activates more than one network interface and happens to=20 > attach to more > > than one MAG of a given PMIP domain simultaneously: > > - multiple MN interfaces get the same prefix assigned,=20 > which may break > > something (e.g., routing) in the host and may result in loss of > > connectivity > > - BCE at LMA constantly and randomly changes since multiple=20 > MAGs send > > PBUs to the LMA for the same MN. This may result in packet=20 > loss both in > > downlink and uplink. > > - the MAGs may discover and use different LMA addresses for the same > > host etc. > >=20 > > However, I'm not sure how we can solve this issue without=20 > modifying the > > host or mandating not to use multiple interfaces. Any ideas? > >=20 > > BR, > >=20 > > Kilian > >=20 > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Mittwoch, 26. September 2007 13:50 > >> To: ext Kilian Weniger; Narayanan, Vidya > >> Cc: netlmm@ietf.org > >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > >>=20 > >>=20 > >> Kilian, > >>=20 > >>=20 > >>=20 > >>=20 > >> On 9/26/07 3:57 AM, "ext Kilian Weniger" > >> > >> wrote: > >>=20 > >>> Hi Vidya, > >>>=20 > >>> I agree that we need some text about this issue. > >>>=20 > >>> Narayanan, Vidya wrote: > >>>> - define LMA behavior such that regular multihomed IP devices > >>>> don't run > >>>> into issues of connectivity or shutting down interfaces. > >> This is much > >>>> more logical in my view and it is not a big change in=20 > the document. > >>>=20 > >>> Can you elaborate how this would work? How does the LMA > >> differentiate > >>> between PBUs that were triggered by the same vs different > >> MN interfaces? > >>>=20 > >>>=20 > >>> I guess the MAG would need to include some kind of MN > >> physical network > >>> interface ID in the PBU, but what kind of ID would that be > >> and how does > >>> the MAG learn that ID? Note that the MN's link-local=20 > address may not > >>> work as an ID in general, since the MN may implement a kind > >> of virtual > >>> network interface which hides multiple physical network > >> interfaces and > >>> only exposes a single (virtual) network interface to the IP > >> stack. This > >>> may result in the same link-local address for multiple physical > >>> interfaces.=20 > >>>=20 > >>> So do we need to mandate something on the MN side to solve > >> this issue in > >>> the general case? > >>=20 > >> One of the tenets of Netlmm protocol has been to not require > >> any changes or > >> requirements on the MN. So it is not an option. > >>=20 > >> Issues that arise from multi-homing and how to deal with them > >> should be > >> dealt separately and not in the scope of this I-D. > >>=20 > >> -Raj > >>=20 > >>>=20 > >>> Kilian > >>>=20 > >>>=20 > >>> Panasonic R&D Center Germany GmbH > >>> 63225 Langen, Hessen, Germany > >>> Reg: AG Offenbach (Hessen) HRB 33974 > >>> Managing Director: Thomas Micke > >>>=20 > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >>=20 > >>=20 > >>=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 > >=20 >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 11:13:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYZv-00046j-98; Wed, 26 Sep 2007 11:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYZu-000464-0Z for netlmm@ietf.org; Wed, 26 Sep 2007 11:13:30 -0400 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaYZp-0004de-OD for netlmm@ietf.org; Wed, 26 Sep 2007 11:13:29 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1IaYZb2KA1-0007Oo; Wed, 26 Sep 2007 11:13:15 -0400 From: "Alper Yegin" To: "'Alexandru Petrescu'" Subject: RE: [netlmm] MN-Id overspecification Date: Wed, 26 Sep 2007 18:13:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAPWnpjZT3c4CtQ0aor7RdbBkZ0QAEg+4g In-Reply-To: <46FA5838.9040206@gmail.com> Message-Id: <0MKpCa-1IaYZb2KA1-0007Oo@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19LFkjDbqySEQKM+GLoZmwbhcIDgi9FUQp1D1s BcpoSCPoPoom6p+cxzDqOljjQFcr8D2MpcYs1m1n+mKSO89H1T 9A4L34ZSZPPs3407FYzSg== X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Alper Yegin wrote: > > This issue is still hanging. > > > > So far as I understand the MN-Id is only used for performing HNP > assignment > > in-band with PMIP6 signaling. In case HNP is already assigned, there is > no > > need to be carrying any info that directly or indirectly points to the > MN's > > identity. > > > > But on the other hand, MN-id is all over the spec with normative > languages > > that suggest it be present in every message. > > > > This is an overspecification, reducing flexibility and getting in the > ways > > of various deployment scenarios. > > > > I recommend we change the spec such that MN-id is only mandated when HNP > > needs to be assigned. > > > > Would there be an objection to that? Is there any technical reason to > carry > > an identifier of the MN in every PMIP6 message? > > I suggest that when DHCP is used to assign the address to the Mobile to > use the Remote-ID or the Subscriber-ID, and not the MAG's > 'link-address'. I don't know what you mean by MN-Id? Is this a NAI? > DHCP doesn't use 'MN-Id'. MN-Id is defined as Mobile Node Identifier (MN-Identifier) The identity of a mobile node in the Proxy Mobile IPv6 domain. This is the stable identifier of a mobile node that the mobility entities in a Proxy Mobile IPv6 domain can always acquire and using which a mobile node can predictably be identified. This is typically an identifier such as Mobile Node NAI [RFC-4282]. And used throughout the document. Alper > > I also think that the only possible ways to assign addresses on the > mobile are: auto-forming the LL address, stateless RS/RA, stateful DHCP > and PPP IPv6 LCP. I think there isn't any other and the PMIP6 shouldn't > define a new one either. > > Alex > > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 11:17:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYdf-0001hv-AE; Wed, 26 Sep 2007 11:17:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYde-0001hW-1p for netlmm@ietf.org; Wed, 26 Sep 2007 11:17:22 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaYdc-0004tE-KM for netlmm@ietf.org; Wed, 26 Sep 2007 11:17:22 -0400 X-IronPort-AV: E=Sophos;i="4.20,302,1186383600"; d="scan'208";a="20104035" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2007 08:17:20 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8QFHKRC027300; Wed, 26 Sep 2007 08:17:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8QFGx85020709; Wed, 26 Sep 2007 15:17:19 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 08:17:00 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 08:16:58 -0700 From: "Sri Gundavelli" To: "'Kilian Weniger'" , "'Basavaraj Patil'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Wed, 26 Sep 2007 08:16:58 -0700 Message-ID: <013b01c80050$48e41530$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAL5xXAAAkKj1oAAiragAAC451gAAEEqRAAAKausA== In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> X-OriginalArrivalTime: 26 Sep 2007 15:17:00.0143 (UTC) FILETIME=[48F48FF0:01C80050] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8414; t=1190819840; x=1191683840; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=0wjdEVNDHJ+iU570HlifLmTagG93ww8dckrXT4F/+nI=; b=X/LTqHnQ6zi343oBY7t33sTdzNhYEyCtIsXQWlK6u3ndOu0dSg/U09cElqwaOA30255cQFIW LM3Ppxd96YLHJnUdKKh3Iadjof81/WiH0T6Nd2xeY5gXMcuFShVXE9Tg; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kilian, The scenario is realistic. Agreed. But, multi-homing is not in scope for the base document. We can always publish new document for supporting multi-homing. PMIP6 deployments are going to be done in a managed way. Operators have control on what they are supporting. They will have policy control systems in place, that can pretty much eliminate simultaneous access of the device in a PMIP6 domain. We dont have to define protocol extensions for supporting that in the base document. These discussions on Multi-homing, terminology, MAG compromise dont converge that easily. It requires the WG time. I dont think, we should decide to add this work to the document, just before sending it to the IESG. Bottom line, this should be done as a new I-D. Sri > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: Wednesday, September 26, 2007 7:57 AM > To: Basavaraj Patil > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > Raj, > > can you explain why you think this an academic exercise? Do you think > that a host activating multiple network interfaces is an unrealistic > scenario? > > At least it should be prevented that an unmodified host ends > up with the > same address configured on multiple interfaces. I think this can > currently happen (e.g., with DHCP), right? > > Mandating that the LMA will have only one MAG entry in the BC at any > given time doesn't solve the issues that I listed in my previous mail, > since they are independent of the number of entries in the BC. > > BR, > > Kilian > > > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Mittwoch, 26. September 2007 16:15 > > To: ext Kilian Weniger > > Cc: netlmm@ietf.org > > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > > > > > > Kilian, > > > > While it is possible that a multi-interface MN can attach to > > different MAGs > > which cause the MAGs to send a PBU to the same LMA, I > > personally think that > > dealing with this is more of an academic exercise at the > present time. > > > > I do not believe we have the possibility of making any > > changes to the MN. So > > that route is closed... At least for now. > > > > So here is how I view the current scenario which IMO is > > academic at this > > time and hence not something that we should be spending a lot > > of time on : > > > > - If an MN attaches to multiple MAGs via different interfaces > > this would > > trigger the MAGs to send PBUs to the LMA > > - If the LMA receives them almost simultaneously (as an > > example), and a > > PBAck has not been sent, then the LMA can choose to create an > > entry in the > > BC for the last received PBU and ACK only the last received > > PBU (the LMA > > would believe that the MN which attached to MAG1 moved to > > MAG2 resulting in > > the transmission of PBUs from MAG1 and MAG2 near simulatenously) > > - If the MN receives a PBU from another MAG for an MN which > > has an entry in > > the BC as a result of a second interface attaching to a MAG, > > the LMA would > > view this as the MN having moved to MAG2 and hence would > > delete the BCE for > > MAG1 and insert MAG2 for the MN > > > > But if we merely state (or mandate) that the LMA will only > > have only one MAG > > entry in the BC at any given time, we would not have a > > problem with the > > multi-homing scenario, right? > > > > -Raj > > > > > > > > > > On 9/26/07 8:10 AM, "ext Kilian Weniger" > > > > wrote: > > > > > Hi Raj, > > > > > > I think we should differentiate between two cases: > > > 1. supporting multi-homing requested by the host to > achieve features > > > like load balancing, failover etc. > > > 2. preventing that PMIP protocol breaks if an unmodified > > host activates > > > more than one network interface. > > > > > > For case 1, I agree with you that this is out of scope of > > the base draft > > > and should be handled in a separate multi-homing document. > > > > > > But I think Vidya was talking about case 2 and I agree that > > this issue > > > should be addressed in the base draft. > > > > > > Currently, I see the following potential issues if an > > unmodified host > > > activates more than one network interface and happens to > > attach to more > > > than one MAG of a given PMIP domain simultaneously: > > > - multiple MN interfaces get the same prefix assigned, > > which may break > > > something (e.g., routing) in the host and may result in loss of > > > connectivity > > > - BCE at LMA constantly and randomly changes since multiple > > MAGs send > > > PBUs to the LMA for the same MN. This may result in packet > > loss both in > > > downlink and uplink. > > > - the MAGs may discover and use different LMA addresses > for the same > > > host etc. > > > > > > However, I'm not sure how we can solve this issue without > > modifying the > > > host or mandating not to use multiple interfaces. Any ideas? > > > > > > BR, > > > > > > Kilian > > > > > > > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Mittwoch, 26. September 2007 13:50 > > >> To: ext Kilian Weniger; Narayanan, Vidya > > >> Cc: netlmm@ietf.org > > >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > > >> > > >> > > >> Kilian, > > >> > > >> > > >> > > >> > > >> On 9/26/07 3:57 AM, "ext Kilian Weniger" > > >> > > >> wrote: > > >> > > >>> Hi Vidya, > > >>> > > >>> I agree that we need some text about this issue. > > >>> > > >>> Narayanan, Vidya wrote: > > >>>> - define LMA behavior such that regular multihomed IP devices > > >>>> don't run > > >>>> into issues of connectivity or shutting down interfaces. > > >> This is much > > >>>> more logical in my view and it is not a big change in > > the document. > > >>> > > >>> Can you elaborate how this would work? How does the LMA > > >> differentiate > > >>> between PBUs that were triggered by the same vs different > > >> MN interfaces? > > >>> > > >>> > > >>> I guess the MAG would need to include some kind of MN > > >> physical network > > >>> interface ID in the PBU, but what kind of ID would that be > > >> and how does > > >>> the MAG learn that ID? Note that the MN's link-local > > address may not > > >>> work as an ID in general, since the MN may implement a kind > > >> of virtual > > >>> network interface which hides multiple physical network > > >> interfaces and > > >>> only exposes a single (virtual) network interface to the IP > > >> stack. This > > >>> may result in the same link-local address for multiple physical > > >>> interfaces. > > >>> > > >>> So do we need to mandate something on the MN side to solve > > >> this issue in > > >>> the general case? > > >> > > >> One of the tenets of Netlmm protocol has been to not require > > >> any changes or > > >> requirements on the MN. So it is not an option. > > >> > > >> Issues that arise from multi-homing and how to deal with them > > >> should be > > >> dealt separately and not in the scope of this I-D. > > >> > > >> -Raj > > >> > > >>> > > >>> Kilian > > >>> > > >>> > > >>> Panasonic R&D Center Germany GmbH > > >>> 63225 Langen, Hessen, Germany > > >>> Reg: AG Offenbach (Hessen) HRB 33974 > > >>> Managing Director: Thomas Micke > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> netlmm mailing list > > >>> netlmm@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > >> > > >> > > >> > > > > > > > > > Panasonic R&D Center Germany GmbH > > > 63225 Langen, Hessen, Germany > > > Reg: AG Offenbach (Hessen) HRB 33974 > > > Managing Director: Thomas Micke > > > > > > > > > > > > > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 11:24:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYki-0008Ft-Ep; Wed, 26 Sep 2007 11:24:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYkg-0008Du-T2 for netlmm@ietf.org; Wed, 26 Sep 2007 11:24:38 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaYkf-00057o-MP for netlmm@ietf.org; Wed, 26 Sep 2007 11:24:38 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 08:24:36 -0700 Message-ID: <46FA79B7.2060101@azairenet.com> Date: Wed, 26 Sep 2007 08:24:39 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKp8S-1IaW6W02iq-0008Ic@mrelay.perfora.net> In-Reply-To: <0MKp8S-1IaW6W02iq-0008Ic@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 15:24:36.0486 (UTC) FILETIME=[58F4FA60:01C80051] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, Just a clarification. Are you saying it should be only in the initial Proxy BU/Proxy BAck exchange and not in the ones sent to refresh the binding? In case there is a handoff from the old MAG to the new MAG, the new MAG does not necessarily know the home network prefix for the MN. So in this case the new MAG would also send a proxy BU with the MN-ID and a request for the prefix. The LMA would assign the same prefix again. Vijay Alper Yegin wrote: > This issue is still hanging. > > So far as I understand the MN-Id is only used for performing HNP assignment > in-band with PMIP6 signaling. In case HNP is already assigned, there is no > need to be carrying any info that directly or indirectly points to the MN's > identity. > > But on the other hand, MN-id is all over the spec with normative languages > that suggest it be present in every message. > > This is an overspecification, reducing flexibility and getting in the ways > of various deployment scenarios. > > I recommend we change the spec such that MN-id is only mandated when HNP > needs to be assigned. > > Would there be an objection to that? Is there any technical reason to carry > an identifier of the MN in every PMIP6 message? > > > Alper > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 11:33:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYtP-0007YG-8s; Wed, 26 Sep 2007 11:33:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYtO-0007W9-0W for netlmm@ietf.org; Wed, 26 Sep 2007 11:33:38 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaYtN-0002FC-KJ for netlmm@ietf.org; Wed, 26 Sep 2007 11:33:37 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l8QFf49E019653; Wed, 26 Sep 2007 10:41:05 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 10:33:34 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 10:33:34 -0500 Message-ID: <46FA7BAE.5040303@ericsson.com> Date: Wed, 26 Sep 2007 11:33:02 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05 References: <46F848E2.40904@ericsson.com> <46F852A3.1040401@azairenet.com> <46F91662.6030200@ericsson.com> <6FC4416DDE56C44DA0AEE67BC7CA437116F660AB@zrc2hxm2.corp.nortel.com> <46F9607E.5030504@ericsson.com> <6FC4416DDE56C44DA0AEE67BC7CA437116F66480@zrc2hxm2.corp.nortel.com> <46F966FA.2020609@ericsson.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FA9C86@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116FA9C86@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 15:33:34.0372 (UTC) FILETIME=[998FDE40:01C80052] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, Ahmad Muhanna wrote: > Hi Suresh, > > My apologies for not replying earlier. No problems. > > I believe both scenarios that you proposed need a very special > circumstances in order for them to happen. It will be a good idea to > describe the reality of these scenarios, basically the MN moves quickly > between three different MAGs within a second or so. IMO, it is not worth > addressing scenarios that, in real deployment, will never happen. I am not sure what you mean here. I only proposed one scenario, and it does not require sub second handovers as a precondition. As long as a retransmission happens after a handover, the scenario will come into play. > > One more thing I would like to add here, this case is not specific to > timestamp. > > BTW: IMO, The proposed solution still works but probably no point of > going through the details before realizing the reality of these > scenarios. One more thing that I suggested earlier to Kilian and I think > it was also proposed by Vijay is the use of binding revocation. I will not repeat myself, but the proposed solution does not work, as I detailed in my previous mail (text attached to the end of this mail) > > But let us understand the reality first. I hope you do not mind. I certainly don't mind. Thanks Suresh >> Yes, I do see a problem. How do you differentiate the two >> following cases with the solution you proposed >> >> MAG1->MAG2->MAG3 (with MAG2 PBU lost, retransmitted and arriving after >> MAG3 PBU) -> Your solution detects this correctly and rejects MAG2 PBU >> >> and >> >> MAG1->MAG3->MAG2 (very quick movement from MAG3->MAG2 all >> PBUs arrive in >> order) -> Your solution detects this incorrectly and rejects >> the valid >> MAG2 PBU >> >> Thanks >> Suresh >> >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 12:07:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZPm-0000nQ-BG; Wed, 26 Sep 2007 12:07:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZPl-0000nK-J2 for netlmm@ietf.org; Wed, 26 Sep 2007 12:07:05 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaZPk-0003Ex-F4 for netlmm@ietf.org; Wed, 26 Sep 2007 12:07:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8QG67r4020877; Wed, 26 Sep 2007 19:06:36 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 19:06:14 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 11:06:12 -0500 Received: from 172.19.244.167 ([172.19.244.167]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 Sep 2007 16:06:12 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 26 Sep 2007 11:06:15 -0500 Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs From: Basavaraj Patil To: ext Kilian Weniger Message-ID: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAL5xXAAAkKj1oAAiragAAC451gAAEEqRAAAuCtLg== In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 16:06:12.0248 (UTC) FILETIME=[288C0980:01C80057] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Kilian, Activating multiple interfaces is something that most devices and hosts do already. However having the multiple interfaces attach to MAGs which are served by a common LMA is. This is what I was saying as being academic. If the MAGs that the MN attaches to are associated with different LMAs then it is not a problem. The issue is only when both the MAGs are associated with the same LMA and this may not be something that we want to focus on at the present time or at least not in the context of this I-D. Regarding your second point, do you believe that host implementations will assign the same address to multiple interfaces that they may receive via DHCP? -Raj On 9/26/07 9:56 AM, "ext Kilian Weniger" wrote: > Raj, > > can you explain why you think this an academic exercise? Do you think > that a host activating multiple network interfaces is an unrealistic > scenario? > > At least it should be prevented that an unmodified host ends up with the > same address configured on multiple interfaces. I think this can > currently happen (e.g., with DHCP), right? > > Mandating that the LMA will have only one MAG entry in the BC at any > given time doesn't solve the issues that I listed in my previous mail, > since they are independent of the number of entries in the BC. > > BR, > > Kilian > > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Mittwoch, 26. September 2007 16:15 >> To: ext Kilian Weniger >> Cc: netlmm@ietf.org >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >> >> >> Kilian, >> >> While it is possible that a multi-interface MN can attach to >> different MAGs >> which cause the MAGs to send a PBU to the same LMA, I >> personally think that >> dealing with this is more of an academic exercise at the present time. >> >> I do not believe we have the possibility of making any >> changes to the MN. So >> that route is closed... At least for now. >> >> So here is how I view the current scenario which IMO is >> academic at this >> time and hence not something that we should be spending a lot >> of time on : >> >> - If an MN attaches to multiple MAGs via different interfaces >> this would >> trigger the MAGs to send PBUs to the LMA >> - If the LMA receives them almost simultaneously (as an >> example), and a >> PBAck has not been sent, then the LMA can choose to create an >> entry in the >> BC for the last received PBU and ACK only the last received >> PBU (the LMA >> would believe that the MN which attached to MAG1 moved to >> MAG2 resulting in >> the transmission of PBUs from MAG1 and MAG2 near simulatenously) >> - If the MN receives a PBU from another MAG for an MN which >> has an entry in >> the BC as a result of a second interface attaching to a MAG, >> the LMA would >> view this as the MN having moved to MAG2 and hence would >> delete the BCE for >> MAG1 and insert MAG2 for the MN >> >> But if we merely state (or mandate) that the LMA will only >> have only one MAG >> entry in the BC at any given time, we would not have a >> problem with the >> multi-homing scenario, right? >> >> -Raj >> >> >> >> >> On 9/26/07 8:10 AM, "ext Kilian Weniger" >> >> wrote: >> >>> Hi Raj, >>> >>> I think we should differentiate between two cases: >>> 1. supporting multi-homing requested by the host to achieve features >>> like load balancing, failover etc. >>> 2. preventing that PMIP protocol breaks if an unmodified >> host activates >>> more than one network interface. >>> >>> For case 1, I agree with you that this is out of scope of >> the base draft >>> and should be handled in a separate multi-homing document. >>> >>> But I think Vidya was talking about case 2 and I agree that >> this issue >>> should be addressed in the base draft. >>> >>> Currently, I see the following potential issues if an >> unmodified host >>> activates more than one network interface and happens to >> attach to more >>> than one MAG of a given PMIP domain simultaneously: >>> - multiple MN interfaces get the same prefix assigned, >> which may break >>> something (e.g., routing) in the host and may result in loss of >>> connectivity >>> - BCE at LMA constantly and randomly changes since multiple >> MAGs send >>> PBUs to the LMA for the same MN. This may result in packet >> loss both in >>> downlink and uplink. >>> - the MAGs may discover and use different LMA addresses for the same >>> host etc. >>> >>> However, I'm not sure how we can solve this issue without >> modifying the >>> host or mandating not to use multiple interfaces. Any ideas? >>> >>> BR, >>> >>> Kilian >>> >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Mittwoch, 26. September 2007 13:50 >>>> To: ext Kilian Weniger; Narayanan, Vidya >>>> Cc: netlmm@ietf.org >>>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>>> >>>> >>>> Kilian, >>>> >>>> >>>> >>>> >>>> On 9/26/07 3:57 AM, "ext Kilian Weniger" >>>> >>>> wrote: >>>> >>>>> Hi Vidya, >>>>> >>>>> I agree that we need some text about this issue. >>>>> >>>>> Narayanan, Vidya wrote: >>>>>> - define LMA behavior such that regular multihomed IP devices >>>>>> don't run >>>>>> into issues of connectivity or shutting down interfaces. >>>> This is much >>>>>> more logical in my view and it is not a big change in >> the document. >>>>> >>>>> Can you elaborate how this would work? How does the LMA >>>> differentiate >>>>> between PBUs that were triggered by the same vs different >>>> MN interfaces? >>>>> >>>>> >>>>> I guess the MAG would need to include some kind of MN >>>> physical network >>>>> interface ID in the PBU, but what kind of ID would that be >>>> and how does >>>>> the MAG learn that ID? Note that the MN's link-local >> address may not >>>>> work as an ID in general, since the MN may implement a kind >>>> of virtual >>>>> network interface which hides multiple physical network >>>> interfaces and >>>>> only exposes a single (virtual) network interface to the IP >>>> stack. This >>>>> may result in the same link-local address for multiple physical >>>>> interfaces. >>>>> >>>>> So do we need to mandate something on the MN side to solve >>>> this issue in >>>>> the general case? >>>> >>>> One of the tenets of Netlmm protocol has been to not require >>>> any changes or >>>> requirements on the MN. So it is not an option. >>>> >>>> Issues that arise from multi-homing and how to deal with them >>>> should be >>>> dealt separately and not in the scope of this I-D. >>>> >>>> -Raj >>>> >>>>> >>>>> Kilian >>>>> >>>>> >>>>> Panasonic R&D Center Germany GmbH >>>>> 63225 Langen, Hessen, Germany >>>>> Reg: AG Offenbach (Hessen) HRB 33974 >>>>> Managing Director: Thomas Micke >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>> >>>> >>>> >>> >>> >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 >>> Managing Director: Thomas Micke >>> >>> >> >> >> > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 12:58:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaaDV-0006ai-5v; Wed, 26 Sep 2007 12:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaaDT-0006Xt-VO for netlmm@ietf.org; Wed, 26 Sep 2007 12:58:27 -0400 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaaDP-0008S7-LK for netlmm@ietf.org; Wed, 26 Sep 2007 12:58:27 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1IaaDG0Esb-0007NN; Wed, 26 Sep 2007 12:58:18 -0400 From: "Alper Yegin" To: "'Ahmad Muhanna'" , Subject: RE: [netlmm] MN-Id overspecification Date: Wed, 26 Sep 2007 19:58:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4A= In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116FA9D12@zrc2hxm2.corp.nortel.com> Message-Id: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19SKnbMi5f4zk7CuapIsyG1GUiVx3VWHtPZN26 OhgtIAWfaeTWAg6thknHRT/X/tt6G7F5y/9P2ca5xffzeKTuu1 aFJTmOYlnNhlvCgHSU7/A== X-Spam-Score: -0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad, > In case that a HNP is available at the MAG (how: out-of-scope) and > included in the initial P-BU, ... ... MAG is not required to include an NAI option that carries the MN-identifier. In the spec, all we need to say is "MN-Identifier MUST be included in PBU when the HNP is set to 0::0/0" Alper NO NAI or any other IDs related to the MN > should be included? > > > Regards, > Ahmad > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Wednesday, September 26, 2007 7:35 AM > > To: netlmm@ietf.org > > Subject: [netlmm] MN-Id overspecification > > > > This issue is still hanging. > > > > So far as I understand the MN-Id is only used for performing > > HNP assignment in-band with PMIP6 signaling. In case HNP is > > already assigned, there is no need to be carrying any info > > that directly or indirectly points to the MN's identity. > > > > But on the other hand, MN-id is all over the spec with > > normative languages that suggest it be present in every message. > > > > This is an overspecification, reducing flexibility and > > getting in the ways of various deployment scenarios. > > > > I recommend we change the spec such that MN-id is only > > mandated when HNP needs to be assigned. > > > > Would there be an objection to that? Is there any technical > > reason to carry an identifier of the MN in every PMIP6 message? > > > > > > Alper > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 13:14:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaaSp-0004Fy-Gh; Wed, 26 Sep 2007 13:14:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaaSo-0004EN-Kn for netlmm@ietf.org; Wed, 26 Sep 2007 13:14:18 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaaSo-0006Ep-1i for netlmm@ietf.org; Wed, 26 Sep 2007 13:14:18 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8QHDt9h001350; Wed, 26 Sep 2007 20:14:16 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 20:14:08 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 12:14:03 -0500 Received: from 172.19.244.167 ([172.19.244.167]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 Sep 2007 17:14:03 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 26 Sep 2007 12:14:07 -0500 Subject: Re: [netlmm] MN-Id overspecification From: Basavaraj Patil To: Alper Yegin , "'Ahmad Muhanna'" , Message-ID: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AABDcQjg== In-Reply-To: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 17:14:03.0679 (UTC) FILETIME=[A34F1AF0:01C80060] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, What is the downside of including the MN-ID in all the MAG/LMA messages? Does it break anything? You say that it "is an overspecification, reducing flexibility and getting in the ways of various deployment scenarios"... How is it becoming an obstacle in any deployment scenario? I am just wondering if you are optimizing the protocol by not including the MN-ID or if you see this as actually being a problem. -Raj On 9/26/07 11:58 AM, "ext Alper Yegin" wrote: > Ahmad, > >> In case that a HNP is available at the MAG (how: out-of-scope) and >> included in the initial P-BU, ... > > ... MAG is not required to include an NAI option that carries the > MN-identifier. > > In the spec, all we need to say is "MN-Identifier MUST be included in PBU > when the HNP is set to 0::0/0" > > > Alper > > > > NO NAI or any other IDs related to the MN >> should be included? >> >> >> Regards, >> Ahmad >> >> >>> -----Original Message----- >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>> Sent: Wednesday, September 26, 2007 7:35 AM >>> To: netlmm@ietf.org >>> Subject: [netlmm] MN-Id overspecification >>> >>> This issue is still hanging. >>> >>> So far as I understand the MN-Id is only used for performing >>> HNP assignment in-band with PMIP6 signaling. In case HNP is >>> already assigned, there is no need to be carrying any info >>> that directly or indirectly points to the MN's identity. >>> >>> But on the other hand, MN-id is all over the spec with >>> normative languages that suggest it be present in every message. >>> >>> This is an overspecification, reducing flexibility and >>> getting in the ways of various deployment scenarios. >>> >>> I recommend we change the spec such that MN-id is only >>> mandated when HNP needs to be assigned. >>> >>> Would there be an objection to that? Is there any technical >>> reason to carry an identifier of the MN in every PMIP6 message? >>> >>> >>> Alper >>> >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >>> > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 13:56:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iab7d-0005DW-Je; Wed, 26 Sep 2007 13:56:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iab7b-0004TJ-OP for netlmm@ietf.org; Wed, 26 Sep 2007 13:56:27 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iab7P-0007xr-5N for netlmm@ietf.org; Wed, 26 Sep 2007 13:56:15 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1190829374!29431095!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 21837 invoked from network); 26 Sep 2007 17:56:14 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-3.tower-119.messagelabs.com with SMTP; 26 Sep 2007 17:56:14 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l8QHuDQ4009706; Wed, 26 Sep 2007 10:56:13 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8QHuDiU018376; Wed, 26 Sep 2007 12:56:13 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-39.corp.mot.com [10.169.4.39]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8QHu9bR018337; Wed, 26 Sep 2007 12:56:11 -0500 (CDT) Message-ID: <46FA9D37.5060703@gmail.com> Date: Wed, 26 Sep 2007 19:56:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKpCa-1IaYZb2KA1-0007Oo@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IaYZb2KA1-0007Oo@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-0, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: >> Alper Yegin wrote: >>> This issue is still hanging. >>> >>> So far as I understand the MN-Id is only used for performing HNP >> assignment >>> in-band with PMIP6 signaling. In case HNP is already assigned, there is >> no >>> need to be carrying any info that directly or indirectly points to the >> MN's >>> identity. >>> >>> But on the other hand, MN-id is all over the spec with normative >> languages >>> that suggest it be present in every message. >>> >>> This is an overspecification, reducing flexibility and getting in the >> ways >>> of various deployment scenarios. >>> >>> I recommend we change the spec such that MN-id is only mandated when HNP >>> needs to be assigned. >>> >>> Would there be an objection to that? Is there any technical reason to >> carry >>> an identifier of the MN in every PMIP6 message? >> I suggest that when DHCP is used to assign the address to the Mobile to >> use the Remote-ID or the Subscriber-ID, and not the MAG's >> 'link-address'. I don't know what you mean by MN-Id? Is this a NAI? >> DHCP doesn't use 'MN-Id'. > > MN-Id is defined as > > Mobile Node Identifier (MN-Identifier) > > The identity of a mobile node in the Proxy Mobile IPv6 domain. > This is the stable identifier of a mobile node that the mobility > entities in a Proxy Mobile IPv6 domain can always acquire and > using which a mobile node can predictably be identified. This is > typically an identifier such as Mobile Node NAI [RFC-4282]. > > And used throughout the document. RFC4282 "Network Access Identifier" identifies a user and not a Mobile Node. "MN NAI" sounds very much illogic. The NAIs I've seen in practice are of the form "alper@domain", or "some-text" and the identifiers I've seen to identify a MN are of the form of an IP address, or MAC address. Thus I don't understand what this "MN-Identifier" is. Having an incoherent definition in the Terminology section doesn't help my reading, sorry. It doesn't fit DHCP meanings for identifiers, neither the PPP meanings of identifiers. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:00:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabAp-00005a-49; Wed, 26 Sep 2007 13:59:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabAo-00005U-EO for netlmm@ietf.org; Wed, 26 Sep 2007 13:59:46 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IabAi-00027A-9K for netlmm@ietf.org; Wed, 26 Sep 2007 13:59:46 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1190829538!23455770!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 17545 invoked from network); 26 Sep 2007 17:58:59 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-8.tower-119.messagelabs.com with SMTP; 26 Sep 2007 17:58:59 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l8QHwwIq021213; Wed, 26 Sep 2007 10:58:58 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8QHwuDE020246; Wed, 26 Sep 2007 12:58:57 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-39.corp.mot.com [10.169.4.39]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8QHwpQS020189; Wed, 26 Sep 2007 12:58:53 -0500 (CDT) Message-ID: <46FA9DDA.5060608@gmail.com> Date: Wed, 26 Sep 2007 19:58:50 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [netlmm] MN-Id overspecification References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-0, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Raj, please excuse my intruding but I agree with some points of Alper's. Basavaraj Patil wrote: > Alper, > > What is the downside of including the MN-ID in all the MAG/LMA messages? > Does it break anything? There's already the HoA in all MIP6 signalling why new identifiers? > You say that it "is an overspecification, reducing flexibility and > getting in the ways of various deployment scenarios"... I agree with that phrase of Alper, it _is_ overspefication and does create bloat and confuses the implementer and you don't know where to start reading. > How is it becoming an obstacle in any deployment scenario? A deployment deploying NAIs doesn't understand "MN NAI". > I am just wondering if you are optimizing the protocol by not including the > MN-ID or if you see this as actually being a problem. I don't know. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:03:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabE0-0005PB-Cr; Wed, 26 Sep 2007 14:03:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabDy-0005Lp-QL for netlmm@ietf.org; Wed, 26 Sep 2007 14:03:02 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IabDs-0002HC-IQ for netlmm@ietf.org; Wed, 26 Sep 2007 14:03:02 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1190829353!5329631!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 23185 invoked from network); 26 Sep 2007 17:55:53 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-8.tower-153.messagelabs.com with SMTP; 26 Sep 2007 17:55:53 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l8QHtmwX009642; Wed, 26 Sep 2007 10:55:48 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8QHtmHl018113; Wed, 26 Sep 2007 12:55:48 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-39.corp.mot.com [10.169.4.39]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8QHtjNv018080; Wed, 26 Sep 2007 12:55:46 -0500 (CDT) Message-ID: <46FA9D20.5060807@gmail.com> Date: Wed, 26 Sep 2007 19:55:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-0, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Ahmad, > >> In case that a HNP is available at the MAG (how: out-of-scope) and >> included in the initial P-BU, ... > > ... MAG is not required to include an NAI option that carries the > MN-identifier. > > In the spec, all we need to say is "MN-Identifier MUST be included in PBU > when the HNP is set to 0::0/0" This tends to define a new address assignment mechanism, and this is a very wrong way to go. Put ::/0 in PBU and obtain a HNP in PBAck is wrong to do. We already have many address auto-configuration mechanisms, we don't need a new one. P-BU and P-BAck are for updating the binding MNHoA-MAGCoA, at LMA. P-BU and P-BAck are not for assigning new addresses. Alex (OTOH I agree with you the use of various identifiers: NAI, MN-Id, HNP of the mobile are not clear in the document). ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:08:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabIo-0001FX-Qf; Wed, 26 Sep 2007 14:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabIn-0001E8-FY for netlmm@ietf.org; Wed, 26 Sep 2007 14:08:01 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IabIl-0002RA-IK for netlmm@ietf.org; Wed, 26 Sep 2007 14:08:01 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 11:07:57 -0700 Message-ID: <46FA9FFC.4070608@azairenet.com> Date: Wed, 26 Sep 2007 11:07:56 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kilian Weniger Subject: Re: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 18:07:57.0628 (UTC) FILETIME=[2AE48FC0:01C80068] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Kilian Weniger wrote: > Narayanan, Vidya wrote: >>>> - Security considerations: MAG Compromise: > ... >> If we claim this is an issue in the security considerations >> section and >> claim that the fix to it is for the LMA to ensure the MN is actually >> attached to the MAG, we can't quite hand wave on some possible ways to >> do that. Those are just hints for deployments that are >> concerned about >> MAG compromise. But, those hints need to be captured in the security >> considerations section. The threats document captures this threat and >> it is a valid one - so, I believe we need some text here. The type of >> "detail" is what I tried to provide with the examples on AAA checks or >> CGA signatures - and, I don't think we need a lot of detail >> here; a few >> sentences would be good. >> > > I had a similar comment a while ago. I think that a draft describing a > severe security issue should at least give hints how this can be solved. > > Recently Sri, Vijay, Kuntal and I had an offline discussion about > another possible solution to detect a compromised MAGs, which relies on > PMIP signaling only. > > The basic idea is that if two MAGs simultaneously claim that the MN is > attached, one of the MAGs must lie and is probably a compromised MAG. > The assumption is that the MN cannot at the same time be attached to two > MAGs, at least not with the same network interface. > > More specifically, when the LMA accepts a valid PBU from a new MAG, it > changes the BCE (i.e., there is no impact on handover delay) and > notifies the old MAG (i.e., old address in BCE) about this. The old MAG > then checks whether the MN is still attached. If this is the case, it > informs the LMA about this. The LMA then learns that two different MAGs > claim MN attachement, which is not possible under the assumption stated > above. Hence, after receiving one or more such notifications, the LMA > can identify the compromised MAG and stop trusting this MAG. > > A remaining problem was which message should be used to inform the old > MAG about the BCE change. PBA and revocation msg were discussed, but the > former is not sent unsolicited according to RFC3775 (which could be > overidden by PMIP spec of course) and the latter is not standardized > yet. As I said in another threat, we really need to standardize the revocation message from the LMA to the old MAG ASAP. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:09:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabJl-0002mm-7d; Wed, 26 Sep 2007 14:09:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabJj-0002mR-VF for netlmm@ietf.org; Wed, 26 Sep 2007 14:08:59 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IabJZ-0002S0-5T for netlmm@ietf.org; Wed, 26 Sep 2007 14:08:59 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8QI808t027952; Wed, 26 Sep 2007 21:08:23 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 21:08:22 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 13:08:04 -0500 Received: from 172.19.244.167 ([172.19.244.167]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 26 Sep 2007 18:08:04 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 26 Sep 2007 13:08:08 -0500 Subject: Re: [netlmm] MN-Id overspecification From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAaDETb3m3RmxbEdyZyQARJNUNiA== In-Reply-To: <46FA9DDA.5060608@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 18:08:04.0779 (UTC) FILETIME=[2F27B7B0:01C80068] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alex, On 9/26/07 12:58 PM, "ext Alexandru Petrescu" wrote: > Raj, please excuse my intruding but I agree with some points of Alper's. The IETF MLs are equivalent to "Open season"... So feel free to interrupt :) > > Basavaraj Patil wrote: >> Alper, >> >> What is the downside of including the MN-ID in all the MAG/LMA messages? >> Does it break anything? > > There's already the HoA in all MIP6 signalling why new identifiers? When the MAG sends the PBU, there is no HoA yet.. Hence the only identifier is an ID that was provided to the MAG during access authentication (for example). The NAI is just one form of an ID as the definition states. > >> You say that it "is an overspecification, reducing flexibility and >> getting in the ways of various deployment scenarios"... > > I agree with that phrase of Alper, it _is_ overspefication and does > create bloat and confuses the implementer and you don't know where to > start reading. You could also claim that it is actually a simplification since it provides a single identifier for matching requests and responses. Anyway to implement this protocol, you need to read the whole doc, right? > >> How is it becoming an obstacle in any deployment scenario? > > A deployment deploying NAIs doesn't understand "MN NAI". I guess you mean a deployment that does not use NAIs, right? The MN-NAI is an exampe of an identifier of the MN. It does not have to be an NAI. So in a deployment that does not use NAIs for identifying MNs, you could use other identifiers as long as they are unique. -Raj > >> I am just wondering if you are optimizing the protocol by not including the >> MN-ID or if you see this as actually being a problem. > > I don't know. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:10:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabL4-0004hl-Hm; Wed, 26 Sep 2007 14:10:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabL3-0004fV-N3 for netlmm@ietf.org; Wed, 26 Sep 2007 14:10:21 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IabL3-0000MM-7z for netlmm@ietf.org; Wed, 26 Sep 2007 14:10:21 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 11:10:19 -0700 Message-ID: <46FAA08B.10000@azairenet.com> Date: Wed, 26 Sep 2007 11:10:19 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kilian Weniger Subject: Re: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> <46FA9FFC.4070608@azairenet.com> In-Reply-To: <46FA9FFC.4070608@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 18:10:19.0610 (UTC) FILETIME=[7F854BA0:01C80068] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay Devarapalli wrote: > Kilian Weniger wrote: >> Narayanan, Vidya wrote: >>>>> - Security considerations: MAG Compromise: >> ... >>> If we claim this is an issue in the security considerations section and >>> claim that the fix to it is for the LMA to ensure the MN is actually >>> attached to the MAG, we can't quite hand wave on some possible ways to >>> do that. Those are just hints for deployments that are concerned about >>> MAG compromise. But, those hints need to be captured in the security >>> considerations section. The threats document captures this threat and >>> it is a valid one - so, I believe we need some text here. The type of >>> "detail" is what I tried to provide with the examples on AAA checks or >>> CGA signatures - and, I don't think we need a lot of detail here; a few >>> sentences would be good. >> >> I had a similar comment a while ago. I think that a draft describing a >> severe security issue should at least give hints how this can be solved. >> >> Recently Sri, Vijay, Kuntal and I had an offline discussion about >> another possible solution to detect a compromised MAGs, which relies on >> PMIP signaling only. >> >> The basic idea is that if two MAGs simultaneously claim that the MN is >> attached, one of the MAGs must lie and is probably a compromised MAG. >> The assumption is that the MN cannot at the same time be attached to two >> MAGs, at least not with the same network interface. >> >> More specifically, when the LMA accepts a valid PBU from a new MAG, it >> changes the BCE (i.e., there is no impact on handover delay) and >> notifies the old MAG (i.e., old address in BCE) about this. The old MAG >> then checks whether the MN is still attached. If this is the case, it >> informs the LMA about this. The LMA then learns that two different MAGs >> claim MN attachement, which is not possible under the assumption stated >> above. Hence, after receiving one or more such notifications, the LMA >> can identify the compromised MAG and stop trusting this MAG. >> >> A remaining problem was which message should be used to inform the old >> MAG about the BCE change. PBA and revocation msg were discussed, but the >> former is not sent unsolicited according to RFC3775 (which could be >> overidden by PMIP spec of course) and the latter is not standardized >> yet. > > As I said in another threat, we really need to standardize the > revocation message from the LMA to the old MAG ASAP. sorry, I meant "thread". Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:13:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabOA-0006Eq-DP; Wed, 26 Sep 2007 14:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabO8-00063N-BY for netlmm@ietf.org; Wed, 26 Sep 2007 14:13:32 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IabO2-0002bn-4x for netlmm@ietf.org; Wed, 26 Sep 2007 14:13:32 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 11:13:25 -0700 Message-ID: <46FAA143.6070407@azairenet.com> Date: Wed, 26 Sep 2007 11:13:23 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 18:13:25.0294 (UTC) FILETIME=[EE326CE0:01C80068] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Ahmad, > >> In case that a HNP is available at the MAG (how: out-of-scope) and >> included in the initial P-BU, ... > > ... MAG is not required to include an NAI option that carries the > MN-identifier. > > In the spec, all we need to say is "MN-Identifier MUST be included in PBU > when the HNP is set to 0::0/0" Of course not. If the MAG is going to be presenting the home network prefix in the proxy binding update to the LMA, then the LMA needs to check if the mobile node is authorized for the home network prefix. For this check to happen, the MN-ID must be there in the proxy binding update even if the home network prefix is set to something other than 0::0. In Mobile IPv6, the HA performs this check by getting the identifier from the IKEv1/IKEv2 exchange. Since we don't have a IKEv1/IKEv2 exchange between the MN and the LMA, the proxy BU from the MAG must have the MN-ID. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:19:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabTQ-0002K0-P5; Wed, 26 Sep 2007 14:19:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabTP-0002GZ-GG for netlmm@ietf.org; Wed, 26 Sep 2007 14:18:59 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IabTJ-0002oX-40 for netlmm@ietf.org; Wed, 26 Sep 2007 14:18:59 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8QIG0YY017362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 11:16:01 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8QIG0AF013639; Wed, 26 Sep 2007 11:16:00 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 11:16:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Wed, 26 Sep 2007 11:15:59 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAL5xXAAAkKj1oAAiragAAC451gAAEEqRAAAuCtLgAEMN0g References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> From: "Narayanan, Vidya" To: "Basavaraj Patil" , "ext Kilian Weniger" X-OriginalArrivalTime: 26 Sep 2007 18:16:00.0285 (UTC) FILETIME=[4A942CD0:01C80069] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Raj, Sri, The points you have raised are confusing to me. I don't understand how stating that multihoming is out of scope and that operators can ensure multiple interfaces of the MN don't end up under the same LMA is sufficient or even realistic. =20 First, the most stringent thing that an operator can do is ensure that an LMA only serves MAGs that are attached to a specific access technology. That *may* ensure that the multiple interface problem doesn't occur in many cases (even this would require a serious warning to that effect in the document), but, I don't see how that is also fool-proof. For instance, if the MN had multiple WLAN cards it wants to simultaneously use, it could end up in problems. =20 Especially with the way some of these systems may acquire the MN-ID, it may be the AAA CUI or NAI, in which case, the same ID may be acquired by the MAGs for all the interfaces of the MN. We then end up with a situation where the LMA keeps overwriting the binding (since it only keeps one entry per MN), while the MN sees the same address on its new interface and decides to shut the interface down, effectively ending up with no service. This was described by Christian in one of his emails and is a very realistic scenario. =20 I don't believe we can hand wave on this issue and get somewhere with the document. I understand the importance of getting this document to the IESG in a timely fashion, but, it is necessary to ensure that the protocol works with normal, unmodified IP nodes. =20 Regards, Vidya > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Wednesday, September 26, 2007 9:06 AM > To: ext Kilian Weniger > Cc: netlmm@ietf.org > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 >=20 > Kilian, >=20 > Activating multiple interfaces is something that most devices=20 > and hosts do already. However having the multiple interfaces=20 > attach to MAGs which are served by a common LMA is. This is=20 > what I was saying as being academic. >=20 > If the MAGs that the MN attaches to are associated with=20 > different LMAs then it is not a problem. The issue is only=20 > when both the MAGs are associated with the same LMA and this=20 > may not be something that we want to focus on at the present=20 > time or at least not in the context of this I-D. >=20 > Regarding your second point, do you believe that host=20 > implementations will assign the same address to multiple=20 > interfaces that they may receive via DHCP? >=20 > -Raj >=20 >=20 > On 9/26/07 9:56 AM, "ext Kilian Weniger"=20 > > wrote: >=20 > > Raj, > >=20 > > can you explain why you think this an academic exercise? Do=20 > you think=20 > > that a host activating multiple network interfaces is an=20 > unrealistic=20 > > scenario? > >=20 > > At least it should be prevented that an unmodified host=20 > ends up with=20 > > the same address configured on multiple interfaces. I think=20 > this can=20 > > currently happen (e.g., with DHCP), right? > >=20 > > Mandating that the LMA will have only one MAG entry in the=20 > BC at any=20 > > given time doesn't solve the issues that I listed in my=20 > previous mail,=20 > > since they are independent of the number of entries in the BC. > >=20 > > BR, > >=20 > > Kilian > >=20 > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Mittwoch, 26. September 2007 16:15 > >> To: ext Kilian Weniger > >> Cc: netlmm@ietf.org > >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > >>=20 > >>=20 > >> Kilian, > >>=20 > >> While it is possible that a multi-interface MN can attach to=20 > >> different MAGs which cause the MAGs to send a PBU to the=20 > same LMA, I=20 > >> personally think that dealing with this is more of an academic=20 > >> exercise at the present time. > >>=20 > >> I do not believe we have the possibility of making any=20 > changes to the=20 > >> MN. So that route is closed... At least for now. > >>=20 > >> So here is how I view the current scenario which IMO is=20 > academic at=20 > >> this time and hence not something that we should be=20 > spending a lot of=20 > >> time on : > >>=20 > >> - If an MN attaches to multiple MAGs via different interfaces this=20 > >> would trigger the MAGs to send PBUs to the LMA > >> - If the LMA receives them almost simultaneously (as an=20 > example), and=20 > >> a PBAck has not been sent, then the LMA can choose to=20 > create an entry=20 > >> in the BC for the last received PBU and ACK only the last received=20 > >> PBU (the LMA would believe that the MN which attached to=20 > MAG1 moved=20 > >> to > >> MAG2 resulting in > >> the transmission of PBUs from MAG1 and MAG2 near simulatenously) > >> - If the MN receives a PBU from another MAG for an MN which has an=20 > >> entry in the BC as a result of a second interface=20 > attaching to a MAG,=20 > >> the LMA would view this as the MN having moved to MAG2 and hence=20 > >> would delete the BCE for > >> MAG1 and insert MAG2 for the MN > >>=20 > >> But if we merely state (or mandate) that the LMA will only=20 > have only=20 > >> one MAG entry in the BC at any given time, we would not have a=20 > >> problem with the multi-homing scenario, right? > >>=20 > >> -Raj > >>=20 > >>=20 > >>=20 > >>=20 > >> On 9/26/07 8:10 AM, "ext Kilian Weniger" > >> > >> wrote: > >>=20 > >>> Hi Raj, > >>>=20 > >>> I think we should differentiate between two cases: > >>> 1. supporting multi-homing requested by the host to=20 > achieve features=20 > >>> like load balancing, failover etc. > >>> 2. preventing that PMIP protocol breaks if an unmodified > >> host activates > >>> more than one network interface. > >>>=20 > >>> For case 1, I agree with you that this is out of scope of > >> the base draft > >>> and should be handled in a separate multi-homing document. > >>>=20 > >>> But I think Vidya was talking about case 2 and I agree that > >> this issue > >>> should be addressed in the base draft. > >>>=20 > >>> Currently, I see the following potential issues if an > >> unmodified host > >>> activates more than one network interface and happens to > >> attach to more > >>> than one MAG of a given PMIP domain simultaneously: > >>> - multiple MN interfaces get the same prefix assigned, > >> which may break > >>> something (e.g., routing) in the host and may result in loss of=20 > >>> connectivity > >>> - BCE at LMA constantly and randomly changes since multiple > >> MAGs send > >>> PBUs to the LMA for the same MN. This may result in packet > >> loss both in > >>> downlink and uplink. > >>> - the MAGs may discover and use different LMA addresses=20 > for the same=20 > >>> host etc. > >>>=20 > >>> However, I'm not sure how we can solve this issue without > >> modifying the > >>> host or mandating not to use multiple interfaces. Any ideas? > >>>=20 > >>> BR, > >>>=20 > >>> Kilian > >>>=20 > >>>=20 > >>>> -----Original Message----- > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>> Sent: Mittwoch, 26. September 2007 13:50 > >>>> To: ext Kilian Weniger; Narayanan, Vidya > >>>> Cc: netlmm@ietf.org > >>>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > >>>>=20 > >>>>=20 > >>>> Kilian, > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> On 9/26/07 3:57 AM, "ext Kilian Weniger" > >>>> > >>>> wrote: > >>>>=20 > >>>>> Hi Vidya, > >>>>>=20 > >>>>> I agree that we need some text about this issue. > >>>>>=20 > >>>>> Narayanan, Vidya wrote: > >>>>>> - define LMA behavior such that regular multihomed IP devices=20 > >>>>>> don't run into issues of connectivity or shutting down=20 > >>>>>> interfaces. > >>>> This is much > >>>>>> more logical in my view and it is not a big change in > >> the document. > >>>>>=20 > >>>>> Can you elaborate how this would work? How does the LMA > >>>> differentiate > >>>>> between PBUs that were triggered by the same vs different > >>>> MN interfaces? > >>>>>=20 > >>>>>=20 > >>>>> I guess the MAG would need to include some kind of MN > >>>> physical network > >>>>> interface ID in the PBU, but what kind of ID would that be > >>>> and how does > >>>>> the MAG learn that ID? Note that the MN's link-local > >> address may not > >>>>> work as an ID in general, since the MN may implement a kind > >>>> of virtual > >>>>> network interface which hides multiple physical network > >>>> interfaces and > >>>>> only exposes a single (virtual) network interface to the IP > >>>> stack. This > >>>>> may result in the same link-local address for multiple physical=20 > >>>>> interfaces. > >>>>>=20 > >>>>> So do we need to mandate something on the MN side to solve > >>>> this issue in > >>>>> the general case? > >>>>=20 > >>>> One of the tenets of Netlmm protocol has been to not require any=20 > >>>> changes or requirements on the MN. So it is not an option. > >>>>=20 > >>>> Issues that arise from multi-homing and how to deal with them=20 > >>>> should be dealt separately and not in the scope of this I-D. > >>>>=20 > >>>> -Raj > >>>>=20 > >>>>>=20 > >>>>> Kilian > >>>>>=20 > >>>>>=20 > >>>>> Panasonic R&D Center Germany GmbH > >>>>> 63225 Langen, Hessen, Germany > >>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > >>>>> Micke > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>=20 > >>>>=20 > >>>>=20 > >>>=20 > >>>=20 > >>> Panasonic R&D Center Germany GmbH > >>> 63225 Langen, Hessen, Germany > >>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director:=20 > Thomas Micke > >>>=20 > >>>=20 > >>=20 > >>=20 > >>=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 > >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:31:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabfi-0005HJ-3a; Wed, 26 Sep 2007 14:31:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabfg-0005Dt-Js for netlmm@ietf.org; Wed, 26 Sep 2007 14:31:40 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iabfa-0003dU-8c for netlmm@ietf.org; Wed, 26 Sep 2007 14:31:35 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8QIVGZw019166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 11:31:16 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8QIVCuG018743; Wed, 26 Sep 2007 11:31:15 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 11:31:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Retransmissions and timestamps Date: Wed, 26 Sep 2007 11:31:12 -0700 Message-ID: In-Reply-To: <00cf01c7ffe3$64cd6570$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Retransmissions and timestamps Thread-Index: Acf/wl8f1YfuWj3kSVuieUs1PtuEowAHToKAAADRULAAIfdYgA== References: <46F848E2.40904@ericsson.com><46F852A3.1040401@azairenet.com><46F91662.6030200@ericsson.com><46F985BE.3030108@azairenet.com> <00cf01c7ffe3$64cd6570$1220fea9@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" , "Vijay Devarapalli" , "Suresh Krishnan" X-OriginalArrivalTime: 26 Sep 2007 18:31:14.0677 (UTC) FILETIME=[6B995250:01C8006B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I am then confused by the need for a change in timestamp values for retransmissions. I was going by the following from Vijay's response to Suresh:=20 "> No. It should always use the latest timestamp value. Otherwise the LMA=20 > would not be able to distinguish between a lost Proxy BU being=20 > re-transmitted from a replayed proxy BU." The text above seems to imply that for sake of detecting a replayed PBU, we need to increment timestamps. I was saying that the retransmitted PBU will have passed IPsec replay protection, while a replayed PBU wouldn't have. So, they are distinguishable.=20 If IPsec is not used as the security mechanism, the alternate security mechanism that is used must provide its own replay protection. It doesn't seem to make sense to rely on PMIP6 to do replay checks sometimes and rely on the security protocol for the same at other times. There is value in doing retransmissions without altering the packet. Given the above, is there still a reason why the timestamps should be changed for a retransmitted PBU?=20 Thanks, Vidya > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Tuesday, September 25, 2007 7:18 PM > To: Narayanan, Vidya; 'Vijay Devarapalli'; 'Suresh Krishnan' > Cc: netlmm@ietf.org > Subject: RE: [netlmm] Issue: Retransmissions and timestamps >=20 > We are not using timestamps for replay protection. When a=20 > message is retransmitted, the entity that is sending the=20 > message is claiming the presence of the node at that instance=20 > of time and the timestamp in the message should reflect that.=20 > If the nodes keep retransmitting for a longer and longer=20 > times, we need to consider lot more cases to handle this=20 > correctly. I do not know, what issues you are Suresh are=20 > foreseeing, when a message is retransmitted with a new=20 > timestamp. If there is an issue that you see, then we can try=20 > to fix this logic. >=20 > Sri >=20 >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Tuesday, September 25, 2007 6:55 PM > > To: Vijay Devarapalli; Suresh Krishnan > > Cc: netlmm@ietf.org > > Subject: [netlmm] Issue: Retransmissions and timestamps > >=20 > > I think this one is worth taking up on its own thread as=20 > well. Suresh=20 > > and I both raised this issue in our reviews and the=20 > excerpts below are=20 > > from the ongoing discussions based on Suresh's review. > >=20 > > I have a meta question here. Replay protection is provided using=20 > > IPsec, not using timestamps. Timestamps are meant for ordering the=20 > > PBUs and for that purpose, it really appears to me that=20 > retransmitted=20 > > PBUs need not change the timestamps. As I mentioned in my review,=20 > > that is desirable from a security perspective. Even from=20 > an ordering=20 > > perspective, based on the discussions I've seen here, that=20 > seems to be=20 > > better. > >=20 > > What is the problem with retransmissions going out with the same=20 > > timestamp value? Vijay pointed to replay protection and I=20 > claim that=20 > > is not needed. Were there other points? > >=20 > > Thanks, > > Vidya > >=20 > > > >>> Section 6.9.3 > > > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >>> " o If Timestamp based scheme is in use, the > > retransmitted Proxy > > > >>> Binding Update messages MUST use the latest=20 > timestamp. If > > > >>> Sequence number scheme is in use, the retransmitted > > > Proxy Binding > > > >>> Update messages MUST use a Sequence Number value > > > greater than that > > > >>> used for the previous transmission of this Proxy > > > Binding Update > > > >>> message, just as specified in [RFC-3775]." > > > >>> > > > >>> I completely disagree with this. I think if a PBU is > > > retransmitted > > > >>> it MUST use the same timestamp as the first time around.=20 > > > Otherwise > > > >>> we will run into ordering problems. > > > >> > > > >> No. It should always use the latest timestamp value.=20 > > Otherwise the > > > >> LMA would not be able to distinguish between a lost > > Proxy BU being > > > >> re-transmitted from a replayed proxy BU. > > > >=20 > > > > I cannot see how this works. Consider this scenario. > > > >=20 > > > > MN moves from MAG1 to MAG2 and then to MAG3. > > > >=20 > > > > M1: MAG2 sends PBU with Timestamp T (This is lost) > > > > M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA > > > and updates > > > > the binding cache on the LMA) > > > > M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives > > > at LMA. LMA > > > > sees that the timestamp is later than the current one and then=20 > > > > replaces the current entry in the Binding Cache) > > >=20 > > > MAG2 is supposed to check if the MN is still attached to=20 > it before=20 > > > re-transmitting the Proxy BU. > > >=20 > > > IMO, using the registration revocation mechanism for=20 > PMIPv6 might be=20 > > > the cleanest approach. Any loss of connectivity is likely to be=20 > > > temporary once we have the registration revocation mechanism for=20 > > > PMIPv6. > > >=20 > > > Vijay > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:34:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabiB-00073D-5M; Wed, 26 Sep 2007 14:34:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabi9-000705-2r for netlmm@ietf.org; Wed, 26 Sep 2007 14:34:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iabi7-0003iq-N4 for netlmm@ietf.org; Wed, 26 Sep 2007 14:34:13 -0400 X-IronPort-AV: E=Sophos;i="4.21,198,1188802800"; d="scan'208";a="528420269" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 26 Sep 2007 11:34:11 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8QIYBYs023455; Wed, 26 Sep 2007 11:34:11 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8QIYA8q025304; Wed, 26 Sep 2007 18:34:10 GMT Date: Wed, 26 Sep 2007 11:34:10 -0700 (PDT) From: Sri Gundavelli To: "Narayanan, Vidya" Subject: RE: [netlmm] Issue: Retransmissions and timestamps In-Reply-To: Message-ID: References: <46F848E2.40904@ericsson.com><46F852A3.1040401@azairenet.com><46F91662.6030200@ericsson.com><46F985BE.3030108@azairenet.com> <00cf01c7ffe3$64cd6570$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6182; t=1190831651; x=1191695651; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Retransmissions=20and=20timesta mps |Sender:=20; bh=l8CjtyL07qOa2YNXjaJFAIaRUMMvrV0nfaf3eBwetvA=; b=EdKpzCxa240lLAx+lYbwUf79lDTxSXORhuwKJTM3Ilo/C0/GDLA1yRrw22vBXgyMQK9TQyRm vSdVbfWLkGRhFqdgDOsjm5sjq1JxbRfAYAkljkFJGRTxHpDN7i+XschzvaVyP3/d4jeoKG8Igy pjIwEuep1UiXJRKOuOswzfzK8=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org We are not using timestamps for replay protection. I responded to this yesterday, please comment on this. >> We are not using timestamps for replay protection. When a >> message is retransmitted, the entity that is sending the >> message is claiming the presence of the node at that instance >> of time and the timestamp in the message should reflect that. >> If the nodes keep retransmitting for a longer and longer >> times, we need to consider lot more cases to handle this >> correctly. I do not know, what issues you are Suresh are >> foreseeing, when a message is retransmitted with a new >> timestamp. If there is an issue that you see, then we can try >> to fix this logic. >> Sri On Wed, 26 Sep 2007, Narayanan, Vidya wrote: > > I am then confused by the need for a change in timestamp values for > retransmissions. I was going by the following from Vijay's response to > Suresh: > > "> No. It should always use the latest timestamp value. Otherwise the > LMA >> would not be able to distinguish between a lost Proxy BU being >> re-transmitted from a replayed proxy BU." > > The text above seems to imply that for sake of detecting a replayed PBU, > we need to increment timestamps. I was saying that the retransmitted PBU > will have passed IPsec replay protection, while a replayed PBU wouldn't > have. So, they are distinguishable. > > If IPsec is not used as the security mechanism, the alternate security > mechanism that is used must provide its own replay protection. It > doesn't seem to make sense to rely on PMIP6 to do replay checks > sometimes and rely on the security protocol for the same at other times. > > > There is value in doing retransmissions without altering the packet. > Given the above, is there still a reason why the timestamps should be > changed for a retransmitted PBU? > > Thanks, > Vidya > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Tuesday, September 25, 2007 7:18 PM >> To: Narayanan, Vidya; 'Vijay Devarapalli'; 'Suresh Krishnan' >> Cc: netlmm@ietf.org >> Subject: RE: [netlmm] Issue: Retransmissions and timestamps >> >> We are not using timestamps for replay protection. When a >> message is retransmitted, the entity that is sending the >> message is claiming the presence of the node at that instance >> of time and the timestamp in the message should reflect that. >> If the nodes keep retransmitting for a longer and longer >> times, we need to consider lot more cases to handle this >> correctly. I do not know, what issues you are Suresh are >> foreseeing, when a message is retransmitted with a new >> timestamp. If there is an issue that you see, then we can try >> to fix this logic. >> >> Sri >> >> >> >> >> >> >>> -----Original Message----- >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>> Sent: Tuesday, September 25, 2007 6:55 PM >>> To: Vijay Devarapalli; Suresh Krishnan >>> Cc: netlmm@ietf.org >>> Subject: [netlmm] Issue: Retransmissions and timestamps >>> >>> I think this one is worth taking up on its own thread as >> well. Suresh >>> and I both raised this issue in our reviews and the >> excerpts below are >>> from the ongoing discussions based on Suresh's review. >>> >>> I have a meta question here. Replay protection is provided using >>> IPsec, not using timestamps. Timestamps are meant for ordering the >>> PBUs and for that purpose, it really appears to me that >> retransmitted >>> PBUs need not change the timestamps. As I mentioned in my review, >>> that is desirable from a security perspective. Even from >> an ordering >>> perspective, based on the discussions I've seen here, that >> seems to be >>> better. >>> >>> What is the problem with retransmissions going out with the same >>> timestamp value? Vijay pointed to replay protection and I >> claim that >>> is not needed. Were there other points? >>> >>> Thanks, >>> Vidya >>> >>>>>>> Section 6.9.3 >>>>>>> ============= >>>>>>> " o If Timestamp based scheme is in use, the >>> retransmitted Proxy >>>>>>> Binding Update messages MUST use the latest >> timestamp. If >>>>>>> Sequence number scheme is in use, the retransmitted >>>> Proxy Binding >>>>>>> Update messages MUST use a Sequence Number value >>>> greater than that >>>>>>> used for the previous transmission of this Proxy >>>> Binding Update >>>>>>> message, just as specified in [RFC-3775]." >>>>>>> >>>>>>> I completely disagree with this. I think if a PBU is >>>> retransmitted >>>>>>> it MUST use the same timestamp as the first time around. >>>> Otherwise >>>>>>> we will run into ordering problems. >>>>>> >>>>>> No. It should always use the latest timestamp value. >>> Otherwise the >>>>>> LMA would not be able to distinguish between a lost >>> Proxy BU being >>>>>> re-transmitted from a replayed proxy BU. >>>>> >>>>> I cannot see how this works. Consider this scenario. >>>>> >>>>> MN moves from MAG1 to MAG2 and then to MAG3. >>>>> >>>>> M1: MAG2 sends PBU with Timestamp T (This is lost) >>>>> M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA >>>> and updates >>>>> the binding cache on the LMA) >>>>> M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives >>>> at LMA. LMA >>>>> sees that the timestamp is later than the current one and then >>>>> replaces the current entry in the Binding Cache) >>>> >>>> MAG2 is supposed to check if the MN is still attached to >> it before >>>> re-transmitting the Proxy BU. >>>> >>>> IMO, using the registration revocation mechanism for >> PMIPv6 might be >>>> the cleanest approach. Any loss of connectivity is likely to be >>>> temporary once we have the registration revocation mechanism for >>>> PMIPv6. >>>> >>>> Vijay >>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:37:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IablX-0001cR-SO; Wed, 26 Sep 2007 14:37:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IablW-0001cL-PJ for netlmm@ietf.org; Wed, 26 Sep 2007 14:37:42 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IablV-0001xH-Dc for netlmm@ietf.org; Wed, 26 Sep 2007 14:37:42 -0400 X-IronPort-AV: E=Sophos;i="4.21,198,1188802800"; d="scan'208";a="20168007" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2007 11:37:40 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8QIbef9032128; Wed, 26 Sep 2007 11:37:40 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8QIbe8q029385; Wed, 26 Sep 2007 18:37:40 GMT Date: Wed, 26 Sep 2007 11:37:40 -0700 (PDT) From: Sri Gundavelli To: "Narayanan, Vidya" Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: Message-ID: References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10707; t=1190831860; x=1191695860; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=UBdqVq5BBFWyZRmH9aFbhiHwvbH8NjORuM69y4q2ixs=; b=P6RhxfDNCkRu/JIj2427+lPGLjVdKjIoyztJMCPKCAyFDT7o8FF9X1xho8E386r3roHabdHA 3JHC/hBXCH/ijXHgLFN2qdrhKPPFK0jBdY7BwEhndT7XooJS3etp65fb; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org We dont have to add support for every feature in the base spec. We split the IPv4 support just for the same reason. Why should this be in the base spec ? We can certainly add some text as Kilian was suggesting. But, we cant get into the solution space. If you can state what outcome you are expecting, that would be good. If its some simple text, we can do that. That we already agreed. Sri On Wed, 26 Sep 2007, Narayanan, Vidya wrote: > > Raj, Sri, > The points you have raised are confusing to me. I don't understand how > stating that multihoming is out of scope and that operators can ensure > multiple interfaces of the MN don't end up under the same LMA is > sufficient or even realistic. > > First, the most stringent thing that an operator can do is ensure that > an LMA only serves MAGs that are attached to a specific access > technology. That *may* ensure that the multiple interface problem > doesn't occur in many cases (even this would require a serious warning > to that effect in the document), but, I don't see how that is also > fool-proof. For instance, if the MN had multiple WLAN cards it wants to > simultaneously use, it could end up in problems. > > Especially with the way some of these systems may acquire the MN-ID, it > may be the AAA CUI or NAI, in which case, the same ID may be acquired by > the MAGs for all the interfaces of the MN. We then end up with a > situation where the LMA keeps overwriting the binding (since it only > keeps one entry per MN), while the MN sees the same address on its new > interface and decides to shut the interface down, effectively ending up > with no service. This was described by Christian in one of his emails > and is a very realistic scenario. > > I don't believe we can hand wave on this issue and get somewhere with > the document. I understand the importance of getting this document to > the IESG in a timely fashion, but, it is necessary to ensure that the > protocol works with normal, unmodified IP nodes. > > Regards, > Vidya > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Wednesday, September 26, 2007 9:06 AM >> To: ext Kilian Weniger >> Cc: netlmm@ietf.org >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >> >> >> Kilian, >> >> Activating multiple interfaces is something that most devices >> and hosts do already. However having the multiple interfaces >> attach to MAGs which are served by a common LMA is. This is >> what I was saying as being academic. >> >> If the MAGs that the MN attaches to are associated with >> different LMAs then it is not a problem. The issue is only >> when both the MAGs are associated with the same LMA and this >> may not be something that we want to focus on at the present >> time or at least not in the context of this I-D. >> >> Regarding your second point, do you believe that host >> implementations will assign the same address to multiple >> interfaces that they may receive via DHCP? >> >> -Raj >> >> >> On 9/26/07 9:56 AM, "ext Kilian Weniger" >> >> wrote: >> >>> Raj, >>> >>> can you explain why you think this an academic exercise? Do >> you think >>> that a host activating multiple network interfaces is an >> unrealistic >>> scenario? >>> >>> At least it should be prevented that an unmodified host >> ends up with >>> the same address configured on multiple interfaces. I think >> this can >>> currently happen (e.g., with DHCP), right? >>> >>> Mandating that the LMA will have only one MAG entry in the >> BC at any >>> given time doesn't solve the issues that I listed in my >> previous mail, >>> since they are independent of the number of entries in the BC. >>> >>> BR, >>> >>> Kilian >>> >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Mittwoch, 26. September 2007 16:15 >>>> To: ext Kilian Weniger >>>> Cc: netlmm@ietf.org >>>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>>> >>>> >>>> Kilian, >>>> >>>> While it is possible that a multi-interface MN can attach to >>>> different MAGs which cause the MAGs to send a PBU to the >> same LMA, I >>>> personally think that dealing with this is more of an academic >>>> exercise at the present time. >>>> >>>> I do not believe we have the possibility of making any >> changes to the >>>> MN. So that route is closed... At least for now. >>>> >>>> So here is how I view the current scenario which IMO is >> academic at >>>> this time and hence not something that we should be >> spending a lot of >>>> time on : >>>> >>>> - If an MN attaches to multiple MAGs via different interfaces this >>>> would trigger the MAGs to send PBUs to the LMA >>>> - If the LMA receives them almost simultaneously (as an >> example), and >>>> a PBAck has not been sent, then the LMA can choose to >> create an entry >>>> in the BC for the last received PBU and ACK only the last received >>>> PBU (the LMA would believe that the MN which attached to >> MAG1 moved >>>> to >>>> MAG2 resulting in >>>> the transmission of PBUs from MAG1 and MAG2 near simulatenously) >>>> - If the MN receives a PBU from another MAG for an MN which has an >>>> entry in the BC as a result of a second interface >> attaching to a MAG, >>>> the LMA would view this as the MN having moved to MAG2 and hence >>>> would delete the BCE for >>>> MAG1 and insert MAG2 for the MN >>>> >>>> But if we merely state (or mandate) that the LMA will only >> have only >>>> one MAG entry in the BC at any given time, we would not have a >>>> problem with the multi-homing scenario, right? >>>> >>>> -Raj >>>> >>>> >>>> >>>> >>>> On 9/26/07 8:10 AM, "ext Kilian Weniger" >>>> >>>> wrote: >>>> >>>>> Hi Raj, >>>>> >>>>> I think we should differentiate between two cases: >>>>> 1. supporting multi-homing requested by the host to >> achieve features >>>>> like load balancing, failover etc. >>>>> 2. preventing that PMIP protocol breaks if an unmodified >>>> host activates >>>>> more than one network interface. >>>>> >>>>> For case 1, I agree with you that this is out of scope of >>>> the base draft >>>>> and should be handled in a separate multi-homing document. >>>>> >>>>> But I think Vidya was talking about case 2 and I agree that >>>> this issue >>>>> should be addressed in the base draft. >>>>> >>>>> Currently, I see the following potential issues if an >>>> unmodified host >>>>> activates more than one network interface and happens to >>>> attach to more >>>>> than one MAG of a given PMIP domain simultaneously: >>>>> - multiple MN interfaces get the same prefix assigned, >>>> which may break >>>>> something (e.g., routing) in the host and may result in loss of >>>>> connectivity >>>>> - BCE at LMA constantly and randomly changes since multiple >>>> MAGs send >>>>> PBUs to the LMA for the same MN. This may result in packet >>>> loss both in >>>>> downlink and uplink. >>>>> - the MAGs may discover and use different LMA addresses >> for the same >>>>> host etc. >>>>> >>>>> However, I'm not sure how we can solve this issue without >>>> modifying the >>>>> host or mandating not to use multiple interfaces. Any ideas? >>>>> >>>>> BR, >>>>> >>>>> Kilian >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>>>> Sent: Mittwoch, 26. September 2007 13:50 >>>>>> To: ext Kilian Weniger; Narayanan, Vidya >>>>>> Cc: netlmm@ietf.org >>>>>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>>>>> >>>>>> >>>>>> Kilian, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 9/26/07 3:57 AM, "ext Kilian Weniger" >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Hi Vidya, >>>>>>> >>>>>>> I agree that we need some text about this issue. >>>>>>> >>>>>>> Narayanan, Vidya wrote: >>>>>>>> - define LMA behavior such that regular multihomed IP devices >>>>>>>> don't run into issues of connectivity or shutting down >>>>>>>> interfaces. >>>>>> This is much >>>>>>>> more logical in my view and it is not a big change in >>>> the document. >>>>>>> >>>>>>> Can you elaborate how this would work? How does the LMA >>>>>> differentiate >>>>>>> between PBUs that were triggered by the same vs different >>>>>> MN interfaces? >>>>>>> >>>>>>> >>>>>>> I guess the MAG would need to include some kind of MN >>>>>> physical network >>>>>>> interface ID in the PBU, but what kind of ID would that be >>>>>> and how does >>>>>>> the MAG learn that ID? Note that the MN's link-local >>>> address may not >>>>>>> work as an ID in general, since the MN may implement a kind >>>>>> of virtual >>>>>>> network interface which hides multiple physical network >>>>>> interfaces and >>>>>>> only exposes a single (virtual) network interface to the IP >>>>>> stack. This >>>>>>> may result in the same link-local address for multiple physical >>>>>>> interfaces. >>>>>>> >>>>>>> So do we need to mandate something on the MN side to solve >>>>>> this issue in >>>>>>> the general case? >>>>>> >>>>>> One of the tenets of Netlmm protocol has been to not require any >>>>>> changes or requirements on the MN. So it is not an option. >>>>>> >>>>>> Issues that arise from multi-homing and how to deal with them >>>>>> should be dealt separately and not in the scope of this I-D. >>>>>> >>>>>> -Raj >>>>>> >>>>>>> >>>>>>> Kilian >>>>>>> >>>>>>> >>>>>>> Panasonic R&D Center Germany GmbH >>>>>>> 63225 Langen, Hessen, Germany >>>>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas >>>>>>> Micke >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netlmm mailing list >>>>>>> netlmm@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> Panasonic R&D Center Germany GmbH >>>>> 63225 Langen, Hessen, Germany >>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: >> Thomas Micke >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 >>> Managing Director: Thomas Micke >>> >>> >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:46:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabuA-0005KG-QB; Wed, 26 Sep 2007 14:46:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iabu7-0005Eo-BL for netlmm@ietf.org; Wed, 26 Sep 2007 14:46:35 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iabu6-0002H1-PK for netlmm@ietf.org; Wed, 26 Sep 2007 14:46:35 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 11:46:33 -0700 Message-ID: <46FAA909.2000407@azairenet.com> Date: Wed, 26 Sep 2007 11:46:33 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 18:46:33.0912 (UTC) FILETIME=[8F817380:01C8006D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Basavaraj Patil wrote: > I am just wondering if the LMA would really assign the same prefix to > multiple interfaces of an MN and in what scenario this would happen. > Basically when the LMA has assigned a prefix to an MN (to a specific > interface), that prefix is marked as assigned in the pool of prefixes. So I > don't see the LMA assigning the same prefix to another interface of that MN. > So I do not believe there is a need to do anything in the current I-D on > this issue other to clarify that multi-homing and issues associated with > multi-homing are out of scope for this document. The LMA does not look at the interface, it only assigns home network prefixes based on the mobile node identifier. And the mobile node identifier might be the same irrespective of which interface the mobile node might be using. Vijay > > -Raj > > > On 9/25/07 8:50 PM, "ext Narayanan, Vidya" wrote: > >> Just taking this one up on a separate thread. Here is the discussion >> from me and Vijay: >> >> "Vidya: >> >>> - Prefix allocation and multihomed MNs: >>> >>> The first bullet on page 18 states that the LMA "MUST ensure the >>> allocated prefix is not in use by any other mobile node". In the >>> context of regular IP nodes that are multihomed, we discussed how it >>> is problematic when the same prefix/address is allocated to multiple >>> interfaces of the same node. To prevent that problem, are we assuming >>> that every distinct interface of an MN attached to the PMIP domain has >>> a different unique identity? If so, that needs to be stated. IMO, >>> that may not be practical, especially, if an NAI is used as the MN ID. >>> So, in those cases, we really need to ensure that the LMA is not >>> allocating the same prefix to multiple interfaces of a multihomed MN. >>> I think an appropriate rewording of this sentence may be something >>> like "the LMA MUST ensure the allocated prefix is not already in use, >>> i.e., there is no existing BCE for that prefix on the LMA". >>> >>> I also recall that the document is supposed to state that the protocol >>> does not support multihomed MNs more generically, but, I couldn't find >>> such text. Did I miss it? >> Vijay: >> >> The conclusion from that thread was the multi-homing is out of scope for >> the base PMIPv6 spec and not supported in the base PMIPv6 document. I >> had proposed some text at that time. We never concluded on that." >> >> We need to conclude this issue. The tracker somehow shows this issue as >> "closed" (issue #166 on the tracker) and I'm not sure why. Other than >> stating that multihoming is out of scope, we need to state one of the >> following two things: >> >> - that PMIP is only intended for networks that have control over the >> types of IP devices attaching to their networks and the burden is on the >> administrators/network designers to ensure that multihomed IP devices >> are not attaching using more than one interface to the same PMIP6 domain >> (this is not the option I recommend) >> >> (OR) >> >> - define LMA behavior such that regular multihomed IP devices don't run >> into issues of connectivity or shutting down interfaces. This is much >> more logical in my view and it is not a big change in the document. >> >> Thanks, >> Vidya >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:50:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabxU-00011t-P9; Wed, 26 Sep 2007 14:50:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabxS-0000xB-Db for netlmm@ietf.org; Wed, 26 Sep 2007 14:50:02 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IabxR-0002QQ-J8 for netlmm@ietf.org; Wed, 26 Sep 2007 14:50:02 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 11:50:00 -0700 Message-ID: <46FAA9D8.2060002@azairenet.com> Date: Wed, 26 Sep 2007 11:50:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 18:50:00.0939 (UTC) FILETIME=[0AE743B0:01C8006E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org The LMA has only one binding cache entry per mobile node at any time. So we never have a case where the MN with two interfaces is attached to two different MAGs, and both MAGs successfully create binding cache entries for the MN at the LMA. The LMA would only have one binding cache entry pointing to the MAG that sent the last proxy BU. Vijay Basavaraj Patil wrote: > Kilian, > > While it is possible that a multi-interface MN can attach to different MAGs > which cause the MAGs to send a PBU to the same LMA, I personally think that > dealing with this is more of an academic exercise at the present time. > > I do not believe we have the possibility of making any changes to the MN. So > that route is closed... At least for now. > > So here is how I view the current scenario which IMO is academic at this > time and hence not something that we should be spending a lot of time on : > > - If an MN attaches to multiple MAGs via different interfaces this would > trigger the MAGs to send PBUs to the LMA > - If the LMA receives them almost simultaneously (as an example), and a > PBAck has not been sent, then the LMA can choose to create an entry in the > BC for the last received PBU and ACK only the last received PBU (the LMA > would believe that the MN which attached to MAG1 moved to MAG2 resulting in > the transmission of PBUs from MAG1 and MAG2 near simulatenously) > - If the MN receives a PBU from another MAG for an MN which has an entry in > the BC as a result of a second interface attaching to a MAG, the LMA would > view this as the MN having moved to MAG2 and hence would delete the BCE for > MAG1 and insert MAG2 for the MN > > But if we merely state (or mandate) that the LMA will only have only one MAG > entry in the BC at any given time, we would not have a problem with the > multi-homing scenario, right? > > -Raj > > > > > On 9/26/07 8:10 AM, "ext Kilian Weniger" > wrote: > >> Hi Raj, >> >> I think we should differentiate between two cases: >> 1. supporting multi-homing requested by the host to achieve features >> like load balancing, failover etc. >> 2. preventing that PMIP protocol breaks if an unmodified host activates >> more than one network interface. >> >> For case 1, I agree with you that this is out of scope of the base draft >> and should be handled in a separate multi-homing document. >> >> But I think Vidya was talking about case 2 and I agree that this issue >> should be addressed in the base draft. >> >> Currently, I see the following potential issues if an unmodified host >> activates more than one network interface and happens to attach to more >> than one MAG of a given PMIP domain simultaneously: >> - multiple MN interfaces get the same prefix assigned, which may break >> something (e.g., routing) in the host and may result in loss of >> connectivity >> - BCE at LMA constantly and randomly changes since multiple MAGs send >> PBUs to the LMA for the same MN. This may result in packet loss both in >> downlink and uplink. >> - the MAGs may discover and use different LMA addresses for the same >> host etc. >> >> However, I'm not sure how we can solve this issue without modifying the >> host or mandating not to use multiple interfaces. Any ideas? >> >> BR, >> >> Kilian >> >> >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>> Sent: Mittwoch, 26. September 2007 13:50 >>> To: ext Kilian Weniger; Narayanan, Vidya >>> Cc: netlmm@ietf.org >>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>> >>> >>> Kilian, >>> >>> >>> >>> >>> On 9/26/07 3:57 AM, "ext Kilian Weniger" >>> >>> wrote: >>> >>>> Hi Vidya, >>>> >>>> I agree that we need some text about this issue. >>>> >>>> Narayanan, Vidya wrote: >>>>> - define LMA behavior such that regular multihomed IP devices >>>>> don't run >>>>> into issues of connectivity or shutting down interfaces. >>> This is much >>>>> more logical in my view and it is not a big change in the document. >>>> Can you elaborate how this would work? How does the LMA >>> differentiate >>>> between PBUs that were triggered by the same vs different >>> MN interfaces? >>>> >>>> I guess the MAG would need to include some kind of MN >>> physical network >>>> interface ID in the PBU, but what kind of ID would that be >>> and how does >>>> the MAG learn that ID? Note that the MN's link-local address may not >>>> work as an ID in general, since the MN may implement a kind >>> of virtual >>>> network interface which hides multiple physical network >>> interfaces and >>>> only exposes a single (virtual) network interface to the IP >>> stack. This >>>> may result in the same link-local address for multiple physical >>>> interfaces. >>>> >>>> So do we need to mandate something on the MN side to solve >>> this issue in >>>> the general case? >>> One of the tenets of Netlmm protocol has been to not require >>> any changes or >>> requirements on the MN. So it is not an option. >>> >>> Issues that arise from multi-homing and how to deal with them >>> should be >>> dealt separately and not in the scope of this I-D. >>> >>> -Raj >>> >>>> Kilian >>>> >>>> >>>> Panasonic R&D Center Germany GmbH >>>> 63225 Langen, Hessen, Germany >>>> Reg: AG Offenbach (Hessen) HRB 33974 >>>> Managing Director: Thomas Micke >>>> >>>> >>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >>> >> >> Panasonic R&D Center Germany GmbH >> 63225 Langen, Hessen, Germany >> Reg: AG Offenbach (Hessen) HRB 33974 >> Managing Director: Thomas Micke >> >> > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:55:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iac2i-0003wE-Bg; Wed, 26 Sep 2007 14:55:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iac2g-0003vG-DE for netlmm@ietf.org; Wed, 26 Sep 2007 14:55:26 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iac2d-0002ZO-JI for netlmm@ietf.org; Wed, 26 Sep 2007 14:55:24 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8QItM3N005389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 11:55:22 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8QItLvh024203; Wed, 26 Sep 2007 11:55:21 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 11:55:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Wed, 26 Sep 2007 11:55:18 -0700 Message-ID: In-Reply-To: <00d401c7ffee$5b6f5230$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/T/RrZEqQFEePT3u9QfI2QIenQAAmSnpgACChC9A= References: <00d401c7ffee$5b6f5230$1220fea9@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" , X-OriginalArrivalTime: 26 Sep 2007 18:55:21.0565 (UTC) FILETIME=[CA02E8D0:01C8006E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, =20 > >=20 > > - Page 5: PMIPv6 Domain definition:=20 > >=20 > > Isn't a PMIP domain also the topological boundary within=20 > which the MN=20 > > doesn't need to change its IP address? It would make sense=20 > to state=20 > > that as part of the definition in my view. > >=20 >=20 > This was discussed in the thread > http://www1.ietf.org/mail-archive/web/netlmm/current/msg02383.html >=20 > The definition was discussed in the WG and adopted from=20 > there. I can try to add the IP address part. >=20 Thanks. I recall the discussion, but, it still seems to make sense to mention the part about unchanging IP address, since that is the observable characteristic useful to the MN ultimately.=20 > > - General:=20 > >=20 > > Parts of the document contains text on IPv4. I suggest leaving the=20 > > IPv4 text to the IPv4 document. > > >=20 > This document does not explain how IPv4 transport or=20 > addressing is achieved. It just points to the other document,=20 > to specify the scope of this work. The references to IPv4 are=20 > only for completeness. The IPv4 support doc is an extension=20 > to this work. >=20 I realize that. I think this text is going to raise unnecessary questions outside the WG and as I see it, the text isn't adding a lot of value. That is why I'm suggesting to remove it.=20 > >=20 > > - Timestamp values:=20 > >=20 > > In the 4th bullet from the bottom on page 22, it says "MUST=20 > be close=20 > > enough" of the LMA's clock - I don't think "close enough" is=20 > > sufficient here. For interoperability, I believe we should specify=20 > > the range for closeness. > >=20 >=20 > This was the comment from Shyam. It really depends on the mechanism > that is used for time synchronization and the accuracy provided by > that mechanism. Its better we leave this to deployments. >=20 I'm not sure that this can be left to deployment. This is not something that is good to be configurable - hence, this may be an implementation choice and not a deployment choice. If it is an implementation choice, something needs to be specified as a mandatory behavior. Otherwise, the MAG and LMA may have different ranges and that would be a problem. Knowing the accuracy and adjusting for some transmission delays, I think we can come up with a reasonable number - I think it was 8 seconds in MIP4?=20 =20 > > - "SHOULD" for access authentication:=20 > >=20 > > I'm not sure why this is a SHOULD for this specification. =20 > > Just because > > access authentication is likely to be done on systems that=20 > are looking > > at adopting PMIP6 today doesn't make it a requirement for the=20 > > protocol. > > In my view, there is no depedency between having acces=20 > control versus > > not from a PMIP perspective.=20 > >=20 >=20 > Is that inline with IETF security requirements for protocols ? First, there is no such thing as IETF security "requirements" - there are guidelines. But, those only apply to the protocol being specified. In this case, access authentication has absolutely nothing to do with PMIP6 (which is what this document is specifying) whatsoever. The MN accesses the system however it was allowed to access it, period. So, having text on access authentication in the PMIP6 specification is not making sense to me.=20 > We put a MUST for network node security and a MAY for access > security ? I understand, in some networks this may not be=20 > enabled. But, the spec should require it. >=20 No, please see above explanation.=20 >=20 > > - Section 6.6, MN identity:=20 > >=20 > > We should mention that this could be a link layer address or=20 > > pretty much > > any identifier that uniquely identifies the MN in that domain.=20 > >=20 >=20 > This is per 4282. What we carry is the MN-Identifier option > and we are bound to that definition in that option. >=20 Actually, we are using RFC4283. The only sub-type defined there is the RFC4282-based NAI option. However, if someone defined additional subtypes, it may be different from an NAI. We don't need to be bound to the only currently defined subtype. At least, we should be mindful that there may be other types.=20 > =20 > > - Page 34, Binding De-registration:=20 > >=20 > > Why is this a MUST? If another MAG sends a PBU for the MN,=20 > > the existing > > entry will be overwritten anyway. If not, the binding will=20 > eventually > > time out. It seems like a SHOULD for de-registration is=20 > sufficient.=20 > >=20 >=20 > What if the lifetime is very high and the mobile roams out of the > PMIP domain. It needs to clean up the visitor state. >=20 I'm not sure I understand. If a system gives out really long lifetimes, it probably should have de-registration capabilities. But, if not, the soft state operation of the protocol is enough. Actually, in some systems, there may be notifications between MAGs so that the old MAG knows that another MAG has taken over. So, I really think SHOULD is more than sufficient - it is clearly not a MUST.=20 Thanks, Vidya _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 14:58:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iac54-0005H2-61; Wed, 26 Sep 2007 14:57:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iac53-0005Gq-0H for netlmm@ietf.org; Wed, 26 Sep 2007 14:57:53 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iac51-0002ek-JA for netlmm@ietf.org; Wed, 26 Sep 2007 14:57:52 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8QIva0x022265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 11:57:36 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8QIvZ2t024619; Wed, 26 Sep 2007 11:57:35 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 11:57:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Wed, 26 Sep 2007 11:57:32 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAbFxAsbtp2fjnTDmQfbCaMWvORwAAnXQQ References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> From: "Narayanan, Vidya" To: "Sri Gundavelli" X-OriginalArrivalTime: 26 Sep 2007 18:57:35.0000 (UTC) FILETIME=[198B7980:01C8006F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri,=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Wednesday, September 26, 2007 11:38 AM > To: Narayanan, Vidya > Cc: Basavaraj Patil; ext Kilian Weniger; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > We dont have to add support for every feature in the base spec. It is critical differentiate between a "feature" and a behavior in the current spec that may break something on existing IP nodes. Kilian clearly articulated the differences here in the multihoming case. We are discussing the latter and that needs to be fixed. =20 > We split the IPv4 support just for the same reason. Why=20 > should this be in the base spec ? >=20 > We can certainly add some text as Kilian was suggesting. But,=20 > we cant get into the solution space. >=20 > If you can state what outcome you are expecting, that would=20 > be good. If its some simple text, we can do that. That we=20 > already agreed. >=20 It is not a question of how simple the text is - it is a question of what fixes the issue at hand. I'll think about this a bit further and send some suggestion later today.=20 Thanks, Vidya > Sri >=20 > On Wed, 26 Sep 2007, Narayanan, Vidya wrote: >=20 > > > > Raj, Sri, > > The points you have raised are confusing to me. I don't understand=20 > > how stating that multihoming is out of scope and that operators can=20 > > ensure multiple interfaces of the MN don't end up under the=20 > same LMA=20 > > is sufficient or even realistic. > > > > First, the most stringent thing that an operator can do is=20 > ensure that=20 > > an LMA only serves MAGs that are attached to a specific access=20 > > technology. That *may* ensure that the multiple interface problem=20 > > doesn't occur in many cases (even this would require a=20 > serious warning=20 > > to that effect in the document), but, I don't see how that is also=20 > > fool-proof. For instance, if the MN had multiple WLAN=20 > cards it wants=20 > > to simultaneously use, it could end up in problems. > > > > Especially with the way some of these systems may acquire=20 > the MN-ID,=20 > > it may be the AAA CUI or NAI, in which case, the same ID may be=20 > > acquired by the MAGs for all the interfaces of the MN. We=20 > then end up=20 > > with a situation where the LMA keeps overwriting the=20 > binding (since it=20 > > only keeps one entry per MN), while the MN sees the same address on=20 > > its new interface and decides to shut the interface down,=20 > effectively=20 > > ending up with no service. This was described by Christian=20 > in one of=20 > > his emails and is a very realistic scenario. > > > > I don't believe we can hand wave on this issue and get=20 > somewhere with=20 > > the document. I understand the importance of getting this=20 > document to=20 > > the IESG in a timely fashion, but, it is necessary to=20 > ensure that the=20 > > protocol works with normal, unmodified IP nodes. > > > > Regards, > > Vidya > > > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Wednesday, September 26, 2007 9:06 AM > >> To: ext Kilian Weniger > >> Cc: netlmm@ietf.org > >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > >> > >> > >> Kilian, > >> > >> Activating multiple interfaces is something that most devices and=20 > >> hosts do already. However having the multiple interfaces attach to=20 > >> MAGs which are served by a common LMA is. This is what I=20 > was saying=20 > >> as being academic. > >> > >> If the MAGs that the MN attaches to are associated with different=20 > >> LMAs then it is not a problem. The issue is only when both=20 > the MAGs=20 > >> are associated with the same LMA and this may not be=20 > something that=20 > >> we want to focus on at the present time or at least not in the=20 > >> context of this I-D. > >> > >> Regarding your second point, do you believe that host=20 > implementations=20 > >> will assign the same address to multiple interfaces that they may=20 > >> receive via DHCP? > >> > >> -Raj > >> > >> > >> On 9/26/07 9:56 AM, "ext Kilian Weniger" > >> > >> wrote: > >> > >>> Raj, > >>> > >>> can you explain why you think this an academic exercise? Do > >> you think > >>> that a host activating multiple network interfaces is an > >> unrealistic > >>> scenario? > >>> > >>> At least it should be prevented that an unmodified host > >> ends up with > >>> the same address configured on multiple interfaces. I think > >> this can > >>> currently happen (e.g., with DHCP), right? > >>> > >>> Mandating that the LMA will have only one MAG entry in the > >> BC at any > >>> given time doesn't solve the issues that I listed in my > >> previous mail, > >>> since they are independent of the number of entries in the BC. > >>> > >>> BR, > >>> > >>> Kilian > >>> > >>> > >>>> -----Original Message----- > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>> Sent: Mittwoch, 26. September 2007 16:15 > >>>> To: ext Kilian Weniger > >>>> Cc: netlmm@ietf.org > >>>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > >>>> > >>>> > >>>> Kilian, > >>>> > >>>> While it is possible that a multi-interface MN can attach to=20 > >>>> different MAGs which cause the MAGs to send a PBU to the > >> same LMA, I > >>>> personally think that dealing with this is more of an academic=20 > >>>> exercise at the present time. > >>>> > >>>> I do not believe we have the possibility of making any > >> changes to the > >>>> MN. So that route is closed... At least for now. > >>>> > >>>> So here is how I view the current scenario which IMO is > >> academic at > >>>> this time and hence not something that we should be > >> spending a lot of > >>>> time on : > >>>> > >>>> - If an MN attaches to multiple MAGs via different=20 > interfaces this=20 > >>>> would trigger the MAGs to send PBUs to the LMA > >>>> - If the LMA receives them almost simultaneously (as an > >> example), and > >>>> a PBAck has not been sent, then the LMA can choose to > >> create an entry > >>>> in the BC for the last received PBU and ACK only the=20 > last received=20 > >>>> PBU (the LMA would believe that the MN which attached to > >> MAG1 moved > >>>> to > >>>> MAG2 resulting in > >>>> the transmission of PBUs from MAG1 and MAG2 near simulatenously) > >>>> - If the MN receives a PBU from another MAG for an MN=20 > which has an=20 > >>>> entry in the BC as a result of a second interface > >> attaching to a MAG, > >>>> the LMA would view this as the MN having moved to MAG2 and hence=20 > >>>> would delete the BCE for > >>>> MAG1 and insert MAG2 for the MN > >>>> > >>>> But if we merely state (or mandate) that the LMA will only > >> have only > >>>> one MAG entry in the BC at any given time, we would not have a=20 > >>>> problem with the multi-homing scenario, right? > >>>> > >>>> -Raj > >>>> > >>>> > >>>> > >>>> > >>>> On 9/26/07 8:10 AM, "ext Kilian Weniger" > >>>> > >>>> wrote: > >>>> > >>>>> Hi Raj, > >>>>> > >>>>> I think we should differentiate between two cases: > >>>>> 1. supporting multi-homing requested by the host to > >> achieve features > >>>>> like load balancing, failover etc. > >>>>> 2. preventing that PMIP protocol breaks if an unmodified > >>>> host activates > >>>>> more than one network interface. > >>>>> > >>>>> For case 1, I agree with you that this is out of scope of > >>>> the base draft > >>>>> and should be handled in a separate multi-homing document. > >>>>> > >>>>> But I think Vidya was talking about case 2 and I agree that > >>>> this issue > >>>>> should be addressed in the base draft. > >>>>> > >>>>> Currently, I see the following potential issues if an > >>>> unmodified host > >>>>> activates more than one network interface and happens to > >>>> attach to more > >>>>> than one MAG of a given PMIP domain simultaneously: > >>>>> - multiple MN interfaces get the same prefix assigned, > >>>> which may break > >>>>> something (e.g., routing) in the host and may result in loss of=20 > >>>>> connectivity > >>>>> - BCE at LMA constantly and randomly changes since multiple > >>>> MAGs send > >>>>> PBUs to the LMA for the same MN. This may result in packet > >>>> loss both in > >>>>> downlink and uplink. > >>>>> - the MAGs may discover and use different LMA addresses > >> for the same > >>>>> host etc. > >>>>> > >>>>> However, I'm not sure how we can solve this issue without > >>>> modifying the > >>>>> host or mandating not to use multiple interfaces. Any ideas? > >>>>> > >>>>> BR, > >>>>> > >>>>> Kilian > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>>>> Sent: Mittwoch, 26. September 2007 13:50 > >>>>>> To: ext Kilian Weniger; Narayanan, Vidya > >>>>>> Cc: netlmm@ietf.org > >>>>>> Subject: Re: [netlmm] Issue: Prefix allocation and=20 > multihomed MNs > >>>>>> > >>>>>> > >>>>>> Kilian, > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 9/26/07 3:57 AM, "ext Kilian Weniger" > >>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> Hi Vidya, > >>>>>>> > >>>>>>> I agree that we need some text about this issue. > >>>>>>> > >>>>>>> Narayanan, Vidya wrote: > >>>>>>>> - define LMA behavior such that regular multihomed=20 > IP devices=20 > >>>>>>>> don't run into issues of connectivity or shutting down=20 > >>>>>>>> interfaces. > >>>>>> This is much > >>>>>>>> more logical in my view and it is not a big change in > >>>> the document. > >>>>>>> > >>>>>>> Can you elaborate how this would work? How does the LMA > >>>>>> differentiate > >>>>>>> between PBUs that were triggered by the same vs different > >>>>>> MN interfaces? > >>>>>>> > >>>>>>> > >>>>>>> I guess the MAG would need to include some kind of MN > >>>>>> physical network > >>>>>>> interface ID in the PBU, but what kind of ID would that be > >>>>>> and how does > >>>>>>> the MAG learn that ID? Note that the MN's link-local > >>>> address may not > >>>>>>> work as an ID in general, since the MN may implement a kind > >>>>>> of virtual > >>>>>>> network interface which hides multiple physical network > >>>>>> interfaces and > >>>>>>> only exposes a single (virtual) network interface to the IP > >>>>>> stack. This > >>>>>>> may result in the same link-local address for=20 > multiple physical=20 > >>>>>>> interfaces. > >>>>>>> > >>>>>>> So do we need to mandate something on the MN side to solve > >>>>>> this issue in > >>>>>>> the general case? > >>>>>> > >>>>>> One of the tenets of Netlmm protocol has been to not=20 > require any=20 > >>>>>> changes or requirements on the MN. So it is not an option. > >>>>>> > >>>>>> Issues that arise from multi-homing and how to deal with them=20 > >>>>>> should be dealt separately and not in the scope of this I-D. > >>>>>> > >>>>>> -Raj > >>>>>> > >>>>>>> > >>>>>>> Kilian > >>>>>>> > >>>>>>> > >>>>>>> Panasonic R&D Center Germany GmbH > >>>>>>> 63225 Langen, Hessen, Germany > >>>>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing=20 > Director: Thomas=20 > >>>>>>> Micke > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> netlmm mailing list > >>>>>>> netlmm@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> Panasonic R&D Center Germany GmbH > >>>>> 63225 Langen, Hessen, Germany > >>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: > >> Thomas Micke > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> Panasonic R&D Center Germany GmbH > >>> 63225 Langen, Hessen, Germany > >>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director:=20 > Thomas Micke > >>> > >>> > >> > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 15:10:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IacHS-0002aq-HO; Wed, 26 Sep 2007 15:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IacHQ-0002Wz-GW for netlmm@ietf.org; Wed, 26 Sep 2007 15:10:40 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IacHP-0005N7-8o for netlmm@ietf.org; Wed, 26 Sep 2007 15:10:40 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1190833829!22021720!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 17842 invoked from network); 26 Sep 2007 19:10:29 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-4.tower-128.messagelabs.com with SMTP; 26 Sep 2007 19:10:29 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l8QJAODS027140; Wed, 26 Sep 2007 12:10:24 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l8QJAN1s016946; Wed, 26 Sep 2007 14:10:23 -0500 (CDT) Received: from [127.0.0.1] ([10.19.245.60]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l8QJAK4f016919; Wed, 26 Sep 2007 14:10:21 -0500 (CDT) Message-ID: <46FAAE9B.9040601@gmail.com> Date: Wed, 26 Sep 2007 21:10:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [netlmm] MN-Id overspecification References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-0, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Basavaraj Patil wrote: > Hi Alex, > > > On 9/26/07 12:58 PM, "ext Alexandru Petrescu" > wrote: > >> Raj, please excuse my intruding but I agree with some points of >> Alper's. > > The IETF MLs are equivalent to "Open season"... So feel free to > interrupt :) > >> Basavaraj Patil wrote: >>> Alper, >>> >>> What is the downside of including the MN-ID in all the MAG/LMA >>> messages? Does it break anything? >> There's already the HoA in all MIP6 signalling why new identifiers? >> >> > > When the MAG sends the PBU, there is no HoA yet.. Hence the only > identifier is an ID that was provided to the MAG during access > authentication (for example). The NAI is just one form of an ID as > the definition states. Right, and the problems are (1) how is that NAI provided by MN to MAG, which protocol? and (2) how does the MAG know the HNP associated to that NAI. I think you leave both these two things out of scope, right? >>> You say that it "is an overspecification, reducing flexibility >>> and getting in the ways of various deployment scenarios"... >> I agree with that phrase of Alper, it _is_ overspefication and does >> create bloat and confuses the implementer and you don't know where >> to start reading. > > You could also claim that it is actually a simplification since it > provides a single identifier for matching requests and responses. > Anyway to implement this protocol, you need to read the whole doc, > right? I would _very_ much like PMIP6 to provide a single identifier but it's not the case. There's also the HNP and the link-address. Both these are used to identify the node at various points in DHCP. >>> How is it becoming an obstacle in any deployment scenario? >> A deployment deploying NAIs doesn't understand "MN NAI". > > I guess you mean a deployment that does not use NAIs, right? No no I mean a deployment that uses NAIs doesn't understand MN-NAI. Because NAI is user identifier not device identifier. "MN-NAI" by its name sounds as a new proposal to mix the two. > The MN-NAI is an exampe of an identifier of the MN. The problem with this is that people also say that the NAI has a certain very well defined syntax (ABNF)... and that does not include strings that might identify a MN, ie addresses. > It does not have to be an NAI. So in a deployment that does not use > NAIs for identifying MNs, you could use other identifiers as long as > they are unique. Except that I can't encode an IPv6 address in a NAI. Or, an IPv6 address identifies very well a MN. Maybe we need only one _existing_ way of identifying the node throughout the document, not a new term. I think that was the initial intent. An ID that could work with DHCP too, and little modification to MIP6 too. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 16:28:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IadUx-0002pL-JY; Wed, 26 Sep 2007 16:28:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IadUv-0002lf-SL for netlmm@ietf.org; Wed, 26 Sep 2007 16:28:41 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IadUt-0006ex-Hm for netlmm@ietf.org; Wed, 26 Sep 2007 16:28:41 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8QKSZ4o016190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 13:28:35 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8QKSYXG006671; Wed, 26 Sep 2007 13:28:34 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 13:28:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] MN-Id overspecification Date: Wed, 26 Sep 2007 13:28:33 -0700 Message-ID: In-Reply-To: <46FAA143.6070407@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAagAEPu0GVwz4RQOWMN9aVbVHtwADyCQw References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> <46FAA143.6070407@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Alper Yegin" X-OriginalArrivalTime: 26 Sep 2007 20:28:34.0011 (UTC) FILETIME=[CF5E72B0:01C8007B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Based on a number of these discussions, the role of the MN-ID is now confusing to me. I've so far heard the following uses for MN-ID:=20 1. To assign a HNP (this I understand) 2. To match PBAs with PBUs (I don't get this) 3. To authorize the HNP to be mapped to that MN-ID (I don't quite get this either) 1 is clear to me and I see why an MN-ID needs to be included in the PBUs that set the HNP to 0. 2 doesn't make sense to me, since when the HNP is present, that is sufficient to match responses to requests. Also, on the matching aspect, I think the document needs clarity, since it sometimes states that sequence numbers are used, sometimes that timestamps are used and some other times that MN-ID is used. It even mandates copying of the sequence number from the PBU to the PBA for this purpose. We need to get this cleaned up.=20 On 3, it is not clear what we are achieving. This is different from the MIP6 case, since in MIP6, the ID is tied to HoA which is tied to the SA and hence, if the HoA came in with the right SA, everything is good. Here, there isn't an SA tied to anything that belongs to the MN. So, simply carrying the MN-ID in the PBU doesn't provide any assurance of that ID being tied to that HNP, other than simply trusting the MAG. So, not carrying the MN-ID is not taking away any existing guarantee - when the LMA receives a PBU for a given HNP, it needs to update that binding. If the LMA is doing something additional to verify the existence of the MN at that MAG, it has the HNP to MN-ID mapping anyway to do that.=20 So, why do we need the MN-ID for anything other than 1?=20 Thanks, Vidya > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Wednesday, September 26, 2007 11:13 AM > To: Alper Yegin > Cc: netlmm@ietf.org > Subject: Re: [netlmm] MN-Id overspecification >=20 > Alper Yegin wrote: > > Ahmad, > >=20 > >> In case that a HNP is available at the MAG (how: out-of-scope) and=20 > >> included in the initial P-BU, ... > >=20 > > ... MAG is not required to include an NAI option that carries the=20 > > MN-identifier. > >=20 > > In the spec, all we need to say is "MN-Identifier MUST be=20 > included in=20 > > PBU when the HNP is set to 0::0/0" >=20 > Of course not. If the MAG is going to be presenting the home=20 > network prefix in the proxy binding update to the LMA, then=20 > the LMA needs to check if the mobile node is authorized for=20 > the home network prefix. For this check to happen, the MN-ID=20 > must be there in the proxy binding update even if the home=20 > network prefix is set to something other than 0::0. >=20 > In Mobile IPv6, the HA performs this check by getting the=20 > identifier from the IKEv1/IKEv2 exchange. Since we don't have=20 > a IKEv1/IKEv2 exchange between the MN and the LMA, the proxy=20 > BU from the MAG must have the MN-ID. >=20 > Vijay >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 16:42:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iadhz-0001FF-0Z; Wed, 26 Sep 2007 16:42:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iadhy-0001DY-1r for netlmm@ietf.org; Wed, 26 Sep 2007 16:42:10 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iadhr-00009m-H1 for netlmm@ietf.org; Wed, 26 Sep 2007 16:42:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 18390A80F5 for ; Wed, 26 Sep 2007 16:41:28 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04288-15 for ; Wed, 26 Sep 2007 16:41:12 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 26 Sep 2007 16:41:12 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 16:40:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] MN-Id overspecification Date: Wed, 26 Sep 2007 16:10:32 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26663FC4D6@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AACh9vIA== From: "Chowdhury, Kuntal" To: "Alper Yegin" , X-OriginalArrivalTime: 26 Sep 2007 20:40:32.0872 (UTC) FILETIME=[7BD7EE80:01C8007D] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, Even if the HNP is included in the PBU, the user identity cannot be deterministically derived from that info. The HNP may be dynamically assigned to the users in many systems. The benefit of including the MN-ID (NAI) in the PMIP signaling messages is that it provides a unique and consistent way to identify the user at the LMA and the MAG at all times (i.e. initial attach and re-registration). BR, Kuntal > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Wednesday, September 26, 2007 11:58 AM > To: 'Ahmad Muhanna'; netlmm@ietf.org > Subject: RE: [netlmm] MN-Id overspecification >=20 > Ahmad, >=20 > > In case that a HNP is available at the MAG (how: out-of-scope) and > > included in the initial P-BU, ... >=20 > ... MAG is not required to include an NAI option that carries the > MN-identifier. >=20 > In the spec, all we need to say is "MN-Identifier MUST be included in PBU > when the HNP is set to 0::0/0" >=20 >=20 > Alper >=20 >=20 >=20 > NO NAI or any other IDs related to the MN > > should be included? > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > Sent: Wednesday, September 26, 2007 7:35 AM > > > To: netlmm@ietf.org > > > Subject: [netlmm] MN-Id overspecification > > > > > > This issue is still hanging. > > > > > > So far as I understand the MN-Id is only used for performing > > > HNP assignment in-band with PMIP6 signaling. In case HNP is > > > already assigned, there is no need to be carrying any info > > > that directly or indirectly points to the MN's identity. > > > > > > But on the other hand, MN-id is all over the spec with > > > normative languages that suggest it be present in every message. > > > > > > This is an overspecification, reducing flexibility and > > > getting in the ways of various deployment scenarios. > > > > > > I recommend we change the spec such that MN-id is only > > > mandated when HNP needs to be assigned. > > > > > > Would there be an objection to that? Is there any technical > > > reason to carry an identifier of the MN in every PMIP6 message? > > > > > > > > > Alper > > > > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 16:49:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IadpI-0006Ho-9K; Wed, 26 Sep 2007 16:49:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IadpH-0006Dh-0l for netlmm@ietf.org; Wed, 26 Sep 2007 16:49:43 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IadpB-0000LP-8l for netlmm@ietf.org; Wed, 26 Sep 2007 16:49:42 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8QKnDSR002880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 13:49:13 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8QKnCOJ009126; Wed, 26 Sep 2007 13:49:12 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 13:49:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Date: Wed, 26 Sep 2007 13:49:10 -0700 Message-ID: In-Reply-To: <46FA9FFC.4070608@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUg References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> <46FA9FFC.4070608@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Kilian Weniger" X-OriginalArrivalTime: 26 Sep 2007 20:49:11.0899 (UTC) FILETIME=[B1352AB0:01C8007E] X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org A few observations here. I don't believe binding revocation is going to solve anything here. The fundamental issue is how the LMA *identifies* the compromised MAG, not how the compromised MAG is notified that its binding is no longer valid. Once the MAG is identified as compromised, a number of remedies may be taken, including, simply blacklisting the MAG and not accepting PBUs from it. It is not critical that the binding be revoked, because, the LMA has already identified where the MN really is and it just needs to use that binding for data acceptance/forwarding. The issue of how the LMA identifies a compromised MAG cannot be tackled without an independent verification of the presence of the MN at that particular MAG. So, we need to focus on providing hints on how the LMA may go about achieving that.=20 Vidya > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com]=20 > Sent: Wednesday, September 26, 2007 11:08 AM > To: Kilian Weniger > Cc: Narayanan, Vidya; netlmm@ietf.org > Subject: Re: Compromised MAG issue (was [netlmm] Review of=20 > draft-ietf-netlmm-proxymip6-05) >=20 > Kilian Weniger wrote: > > Narayanan, Vidya wrote: > >>>> - Security considerations: MAG Compromise:=20 > > ... > >> If we claim this is an issue in the security=20 > considerations section=20 > >> and claim that the fix to it is for the LMA to ensure the MN is=20 > >> actually attached to the MAG, we can't quite hand wave on some=20 > >> possible ways to do that. Those are just hints for=20 > deployments that=20 > >> are concerned about MAG compromise. But, those hints need to be=20 > >> captured in the security considerations section. The threats=20 > >> document captures this threat and it is a valid one - so,=20 > I believe=20 > >> we need some text here. The type of "detail" is what I tried to=20 > >> provide with the examples on AAA checks or CGA signatures - and, I=20 > >> don't think we need a lot of detail here; a few sentences would be=20 > >> good. > >> > >=20 > > I had a similar comment a while ago. I think that a draft=20 > describing a=20 > > severe security issue should at least give hints how this=20 > can be solved. > >=20 > > Recently Sri, Vijay, Kuntal and I had an offline discussion about=20 > > another possible solution to detect a compromised MAGs,=20 > which relies=20 > > on PMIP signaling only. > >=20 > > The basic idea is that if two MAGs simultaneously claim=20 > that the MN is=20 > > attached, one of the MAGs must lie and is probably a=20 > compromised MAG. > > The assumption is that the MN cannot at the same time be=20 > attached to=20 > > two MAGs, at least not with the same network interface. > >=20 > > More specifically, when the LMA accepts a valid PBU from a=20 > new MAG, it=20 > > changes the BCE (i.e., there is no impact on handover delay) and=20 > > notifies the old MAG (i.e., old address in BCE) about this. The old=20 > > MAG then checks whether the MN is still attached. If this=20 > is the case,=20 > > it informs the LMA about this. The LMA then learns that two=20 > different=20 > > MAGs claim MN attachement, which is not possible under the=20 > assumption=20 > > stated above. Hence, after receiving one or more such=20 > notifications,=20 > > the LMA can identify the compromised MAG and stop trusting this MAG. > >=20 > > A remaining problem was which message should be used to=20 > inform the old=20 > > MAG about the BCE change. PBA and revocation msg were=20 > discussed, but=20 > > the former is not sent unsolicited according to RFC3775=20 > (which could=20 > > be overidden by PMIP spec of course) and the latter is not=20 > > standardized yet. >=20 > As I said in another threat, we really need to standardize=20 > the revocation message from the LMA to the old MAG ASAP. >=20 > Vijay >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 17:07:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iae5a-0000Nd-Nr; Wed, 26 Sep 2007 17:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iae5a-0000NY-9h for netlmm@ietf.org; Wed, 26 Sep 2007 17:06:34 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iae5Z-0000lK-38 for netlmm@ietf.org; Wed, 26 Sep 2007 17:06:34 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 14:06:24 -0700 Message-ID: <46FAC9D0.8070604@azairenet.com> Date: Wed, 26 Sep 2007 14:06:24 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [netlmm] MN-Id overspecification References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> <46FAA143.6070407@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 21:06:24.0829 (UTC) FILETIME=[18E1C6D0:01C80081] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, Narayanan, Vidya wrote: > Based on a number of these discussions, the role of the MN-ID is now > confusing to me. I've so far heard the following uses for MN-ID: > > 1. To assign a HNP (this I understand) > > 2. To match PBAs with PBUs (I don't get this) > > 3. To authorize the HNP to be mapped to that MN-ID (I don't quite get > this either) > > 1 is clear to me and I see why an MN-ID needs to be included in the PBUs > that set the HNP to 0. 2 doesn't make sense to me, since when the HNP > is present, that is sufficient to match responses to requests. You are mixing up threads here. In one thread it was claimed that it is used for matching proxy BU to proxy BAck. In that it was assumed there is no home network prefix assigned for the MN yet. Note that we don't have a mechanism described in the base PMIPv6 specification for the MAG to obtain the home network prefix without the LMA involvement. > On 3, it is not clear what we are achieving. This is different from the > MIP6 case, since in MIP6, the ID is tied to HoA which is tied to the SA > and hence, if the HoA came in with the right SA, everything is good. > Here, there isn't an SA tied to anything that belongs to the MN. So, > simply carrying the MN-ID in the PBU doesn't provide any assurance of > that ID being tied to that HNP, other than simply trusting the MAG. So, > not carrying the MN-ID is not taking away any existing guarantee - when > the LMA receives a PBU for a given HNP, it needs to update that binding. > If the LMA is doing something additional to verify the existence of the > MN at that MAG, it has the HNP to MN-ID mapping anyway to do that. If the LMA did not assign the prefix for the mobile node and the MAG obtained it through other means, the LMA would need to check if the mobile node is authorized for that home network prefix. For example the LMA could check with the entity that did the allocation. Vijay > > So, why do we need the MN-ID for anything other than 1? > > Thanks, > Vidya > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Wednesday, September 26, 2007 11:13 AM >> To: Alper Yegin >> Cc: netlmm@ietf.org >> Subject: Re: [netlmm] MN-Id overspecification >> >> Alper Yegin wrote: >>> Ahmad, >>> >>>> In case that a HNP is available at the MAG (how: out-of-scope) and >>>> included in the initial P-BU, ... >>> ... MAG is not required to include an NAI option that carries the >>> MN-identifier. >>> >>> In the spec, all we need to say is "MN-Identifier MUST be >> included in >>> PBU when the HNP is set to 0::0/0" >> Of course not. If the MAG is going to be presenting the home >> network prefix in the proxy binding update to the LMA, then >> the LMA needs to check if the mobile node is authorized for >> the home network prefix. For this check to happen, the MN-ID >> must be there in the proxy binding update even if the home >> network prefix is set to something other than 0::0. >> >> In Mobile IPv6, the HA performs this check by getting the >> identifier from the IKEv1/IKEv2 exchange. Since we don't have >> a IKEv1/IKEv2 exchange between the MN and the LMA, the proxy >> BU from the MAG must have the MN-ID. >> >> Vijay >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 17:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaeEL-00031P-Ad; Wed, 26 Sep 2007 17:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaeEJ-00031K-W9 for netlmm@ietf.org; Wed, 26 Sep 2007 17:15:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaeEI-0000z0-Pk for netlmm@ietf.org; Wed, 26 Sep 2007 17:15:35 -0400 X-IronPort-AV: E=Sophos;i="4.21,199,1188802800"; d="scan'208";a="225739435" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Sep 2007 14:15:34 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8QLFYaw016773; Wed, 26 Sep 2007 14:15:34 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l8QLFXam004693; Wed, 26 Sep 2007 21:15:33 GMT Date: Wed, 26 Sep 2007 14:15:33 -0700 (PDT) From: Sri Gundavelli To: "Narayanan, Vidya" Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: Message-ID: References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2281; t=1190841334; x=1191705334; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=1ByVxow7iNSYX841Q6+Y3udGqMNTuZZoNywQEMoihWw=; b=OwoIWLwkSh+0ZAGPr+fn6uxufNumYnKgxUNbJPf0eWgyaq6jlL4JpANtsaFuiRjnt2EHXUdq nQmi/1TMNg6A7MJWRFqH5HVlBPyvk/+P61IFEDqQXGeef3ORWzDhovmS; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vidya, On Wed, 26 Sep 2007, Narayanan, Vidya wrote: > Sri, > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Wednesday, September 26, 2007 11:38 AM >> To: Narayanan, Vidya >> Cc: Basavaraj Patil; ext Kilian Weniger; netlmm@ietf.org >> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >> >> We dont have to add support for every feature in the base spec. > > It is critical differentiate between a "feature" and a behavior in the > current spec that may break something on existing IP nodes. Kilian > clearly articulated the differences here in the multihoming case. We > are discussing the latter and that needs to be fixed. > I think, we are just looking at this as an engineering problem. A deployment has many aspects, we cannot just say, some operator may plugin the device and the protocol will break. The base spec does not support IPv4 addressing or IPv4 transport, if some one drops in a device with IPv4 only stack, the base protocol does not work. Same thing for multi-homing. I'm not saying we should not support this scenario. I do not think, we should try to do a hotch-potch solution in the base spec and in the last minute. An extension doc is the way to go. Lets add some reasonable warnings in this document and leave it for other specs. We also need to look at timelines. When draft-sgundave as adopted as the WG doc, we did send the work items to the chair and the AD to define the document scope. Number of things including Auth Option, shared links ..were all listed. This topic was never in scope. The same thing for Auth option, we are stuck on this MN-Id, because Auth Option cant fit. If some one wants to support Auth Option, sure, lets do it as a new work item. Why bring these arguments on the need for mobile node's Id. In a proxy model when a mobile is given an address in a dynamic fashion, how else will the network entities identify the mobile ? It must be there in signaling messages. Its logical to do these work items as seperate drafts and not try to make them work magically in the current spec and by opening new issues in the last minute. We can add all these features, if we dont need to follow any timelines. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 17:30:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaeSI-0003n1-5t; Wed, 26 Sep 2007 17:30:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaeSG-0003m7-TY for netlmm@ietf.org; Wed, 26 Sep 2007 17:30:00 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaeSG-0000Ey-9l for netlmm@ietf.org; Wed, 26 Sep 2007 17:30:00 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 14:29:59 -0700 Message-ID: <46FACF57.5030007@azairenet.com> Date: Wed, 26 Sep 2007 14:29:59 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> <46FA9FFC.4070608@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2007 21:29:59.0349 (UTC) FILETIME=[64006650:01C80084] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Narayanan, Vidya wrote: > A few observations here. I don't believe binding revocation is going to > solve anything here. The fundamental issue is how the LMA *identifies* > the compromised MAG, not how the compromised MAG is notified that its > binding is no longer valid. Once the MAG is identified as compromised, > a number of remedies may be taken, including, simply blacklisting the > MAG and not accepting PBUs from it. It is not critical that the binding > be revoked, because, the LMA has already identified where the MN really > is and it just needs to use that binding for data acceptance/forwarding. There is an issue of LMA identifying a compromised MAG. That is true. But that issue has been complicated by having to deal with receiving out-of-order proxy BUs from legitimate MAGs. So the registration revocation mechanism is one component of the solution. > The issue of how the LMA identifies a compromised MAG cannot be tackled > without an independent verification of the presence of the MN at that > particular MAG. So, we need to focus on providing hints on how the LMA > may go about achieving that. Well, one option is for the LMA to check with the AAA server if the MN is attached to the MAG currently. We can provide a hint to this. Anything else, for example the CGA stuff, would need substantial explanation on how it is supposed to work. Vijay > > Vidya > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >> Sent: Wednesday, September 26, 2007 11:08 AM >> To: Kilian Weniger >> Cc: Narayanan, Vidya; netlmm@ietf.org >> Subject: Re: Compromised MAG issue (was [netlmm] Review of >> draft-ietf-netlmm-proxymip6-05) >> >> Kilian Weniger wrote: >>> Narayanan, Vidya wrote: >>>>>> - Security considerations: MAG Compromise: >>> ... >>>> If we claim this is an issue in the security >> considerations section >>>> and claim that the fix to it is for the LMA to ensure the MN is >>>> actually attached to the MAG, we can't quite hand wave on some >>>> possible ways to do that. Those are just hints for >> deployments that >>>> are concerned about MAG compromise. But, those hints need to be >>>> captured in the security considerations section. The threats >>>> document captures this threat and it is a valid one - so, >> I believe >>>> we need some text here. The type of "detail" is what I tried to >>>> provide with the examples on AAA checks or CGA signatures - and, I >>>> don't think we need a lot of detail here; a few sentences would be >>>> good. >>>> >>> I had a similar comment a while ago. I think that a draft >> describing a >>> severe security issue should at least give hints how this >> can be solved. >>> Recently Sri, Vijay, Kuntal and I had an offline discussion about >>> another possible solution to detect a compromised MAGs, >> which relies >>> on PMIP signaling only. >>> >>> The basic idea is that if two MAGs simultaneously claim >> that the MN is >>> attached, one of the MAGs must lie and is probably a >> compromised MAG. >>> The assumption is that the MN cannot at the same time be >> attached to >>> two MAGs, at least not with the same network interface. >>> >>> More specifically, when the LMA accepts a valid PBU from a >> new MAG, it >>> changes the BCE (i.e., there is no impact on handover delay) and >>> notifies the old MAG (i.e., old address in BCE) about this. The old >>> MAG then checks whether the MN is still attached. If this >> is the case, >>> it informs the LMA about this. The LMA then learns that two >> different >>> MAGs claim MN attachement, which is not possible under the >> assumption >>> stated above. Hence, after receiving one or more such >> notifications, >>> the LMA can identify the compromised MAG and stop trusting this MAG. >>> >>> A remaining problem was which message should be used to >> inform the old >>> MAG about the BCE change. PBA and revocation msg were >> discussed, but >>> the former is not sent unsolicited according to RFC3775 >> (which could >>> be overidden by PMIP spec of course) and the latter is not >>> standardized yet. >> As I said in another threat, we really need to standardize >> the revocation message from the LMA to the old MAG ASAP. >> >> Vijay >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 17:43:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaefg-0003Aq-F4; Wed, 26 Sep 2007 17:43:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaeff-0003Ah-0i for netlmm@ietf.org; Wed, 26 Sep 2007 17:43:51 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaefe-0000f6-Cs for netlmm@ietf.org; Wed, 26 Sep 2007 17:43:50 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8QLhgE00888; Wed, 26 Sep 2007 21:43:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] MN-Id overspecification Date: Wed, 26 Sep 2007 16:43:27 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116FF804F@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAagAEPu0GVwz4RQOWMN9aVbVHtwADyCQwAAI5f+A= References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> <46FAA143.6070407@azairenet.com> From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Vijay Devarapalli" , "Alper Yegin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, Please see comments inline. Regards, Ahmad =20 > Subject: RE: [netlmm] MN-Id overspecification >=20 >=20 > Based on a number of these discussions, the role of the MN-ID=20 > is now confusing to me. I've so far heard the following uses=20 > for MN-ID:=20 >=20 > 1. To assign a HNP (this I understand) >=20 > 2. To match PBAs with PBUs (I don't get this) >=20 > 3. To authorize the HNP to be mapped to that MN-ID (I don't=20 > quite get this either) >=20 > 1 is clear to me and I see why an MN-ID needs to be included=20 > in the PBUs that set the HNP to 0. =20 > 2 doesn't make sense to me, =20 [Ahmad-START-1] I am not sure what do you mean here. Earlier you agreed that it is needed but now I am confused. Let me give more details here: 1. PMIPv6 base protocol supports both timestamp and SQN, NO? 2. Also, as we all know, SQN needs to be tracked on a per-MN basis. 3. SQN field is restricted to 2 bytes i.e. =3D~ 64k.=20 4. In this case, there is a very high probability that there will be collisions of the SQN of the outstanding P-BU(s). 5. This means that MN1 and MN101 have the same SQN=3Dxyz inserted in = their respected P-BU messages. 6. When MAG receives the P-BA for MN101, according to RFC3775, MAG needs to find the matching P-BU based on SQN xyz. 7. okay, there are two P-BU(s) that are outstanding waiting for reply. Right? 7.1. How the MAG needs to know which MN the P-BA belongs to? 7.2. MAG needs to use NAI to differentiate. Right? Why then this does not make sense? [Ahmad-END-1] > match responses to requests. > Also, on the matching aspect, I=20 > think the document needs clarity, since it sometimes states=20 > that sequence numbers are used, sometimes that timestamps are=20 > used and some other times that MN-ID is used. =20 [Ahmad-START-2] The same concept actually applies to timestamp too. However, in the case of time stamp, the possibility of collision is way much less. In other words, it is needed either way. May be what you are saying is the draft needs to use more details to explain this, but I guess when it comes to SQN, the original text already in RFC3775. [Ahmad-END-2] > It even=20 > mandates copying of the sequence number from the PBU to the=20 > PBA for this purpose. We need to get this cleaned up. [Ahmad-START-3] What do you expect LMA should return a SQN of ZERO. On the other hand, there is no indication of what the MAG is using the SQN for. Returning the SQN is the proper approach. [Ahmad-END-3] >=20 > On 3, it is not clear what we are achieving. This is=20 > different from the > MIP6 case, since in MIP6, the ID is tied to HoA which is tied=20 > to the SA and hence, if the HoA came in with the right SA,=20 > everything is good. > Here, there isn't an SA tied to anything that belongs to the=20 > MN. So, simply carrying the MN-ID in the PBU doesn't provide=20 > any assurance of that ID being tied to that HNP, other than=20 > simply trusting the MAG. =20 > So, not carrying the MN-ID is not=20 > taking away any existing guarantee - when the LMA receives a=20 > PBU for a given HNP, it needs to update that binding. > If the LMA is doing something additional to verify the=20 > existence of the MN at that MAG, it has the HNP to MN-ID=20 > mapping anyway to do that.=20 >=20 > So, why do we need the MN-ID for anything other than 1?=20 >=20 > Thanks, > Vidya >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Wednesday, September 26, 2007 11:13 AM > > To: Alper Yegin > > Cc: netlmm@ietf.org > > Subject: Re: [netlmm] MN-Id overspecification > >=20 > > Alper Yegin wrote: > > > Ahmad, > > >=20 > > >> In case that a HNP is available at the MAG (how:=20 > out-of-scope) and=20 > > >> included in the initial P-BU, ... > > >=20 > > > ... MAG is not required to include an NAI option that carries the=20 > > > MN-identifier. > > >=20 > > > In the spec, all we need to say is "MN-Identifier MUST be > > included in > > > PBU when the HNP is set to 0::0/0" > >=20 > > Of course not. If the MAG is going to be presenting the=20 > home network=20 > > prefix in the proxy binding update to the LMA, then the LMA=20 > needs to=20 > > check if the mobile node is authorized for the home network prefix.=20 > > For this check to happen, the MN-ID must be there in the=20 > proxy binding=20 > > update even if the home network prefix is set to something=20 > other than=20 > > 0::0. > >=20 > > In Mobile IPv6, the HA performs this check by getting the=20 > identifier=20 > > from the IKEv1/IKEv2 exchange. Since we don't have a IKEv1/IKEv2=20 > > exchange between the MN and the LMA, the proxy BU from the MAG must=20 > > have the MN-ID. > >=20 > > Vijay > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 18:25:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IafJK-0000Up-4Y; Wed, 26 Sep 2007 18:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IafJI-0000Q3-D8 for netlmm@ietf.org; Wed, 26 Sep 2007 18:24:48 -0400 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IafJC-0002UR-2g for netlmm@ietf.org; Wed, 26 Sep 2007 18:24:48 -0400 Received: by rv-out-0910.google.com with SMTP id l15so2097276rvb for ; Wed, 26 Sep 2007 15:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; bh=sM0KJhGnQIuhTFSBpe0DKYnVf8AKbx5vhpvwgxvzFYA=; b=CiA3nyOVfa7vdVvLDQUSM5CZ1IVYxZfvsXPvsEFPL7n/i4MCi0YtJKqW1L5rukl2R5JbskohG2J0GsRQYC1vIeYpeWemGY1nAVzCoSG1hV1znQ9ZHBT0+zCkHYl9P0tf2wRYzEn8lJmYyZ2+FJj42UMj54E6GnUaRuezzar7b5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=pU4BIamXTi0/O0ZqWI+4JfnnsWnE/fhAVTUxnXqJqVNYeTt59XO/bVRI89n59C9sXG9hbDMDiYbAKkn7S+36A0F9SlPU4pWfKS0Dq2ituChfFw4z+Wz925q1KWJxFvihA54uubyzBPAUpXF0dJQlwgzZrgQ0RlbqYclD3Wf2Fhg= Received: by 10.141.78.14 with SMTP id f14mr462737rvl.1190845473078; Wed, 26 Sep 2007 15:24:33 -0700 (PDT) Received: from ?203.178.143.223? ( [203.178.143.223]) by mx.google.com with ESMTPS id k41sm2848871rvb.2007.09.26.15.24.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2007 15:24:31 -0700 (PDT) In-Reply-To: <46FAA9D8.2060002@azairenet.com> References: <46FAA9D8.2060002@azairenet.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 07:24:25 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vijay and Raj When two MAGs sends PBU for multihomed-MN to the same LMA, one of MAG cannot detect the BCE change. This is also problem for multihomed scenario, too. Even if LMA keeps only one binding for MN, MN may get the same home prefix from both MAGs at the same time. MN, then, is no idea which interface should be selected for sending packet using HoA. For example, while the binding of MN is registered, LMA receives a PBU for the MN's second interface from new MAG and accepts it. In this case, the old MAG cannot know the binding change triggered by the new MAG and continue serving the MN. Because both MN's interfaces are active, both MAGs keep sending PBU and LMA overwrites the MN's binding between two MAGs. As Kilian said in another thread, we may need notification message from LMA to MAG about BCE change (ex. revocation). I think this is not academic issue. ryuji@academia:-) On 2007/09/27, at 3:50, Vijay Devarapalli wrote: > The LMA has only one binding cache entry per mobile node at any > time. So we never have a case where the MN with two interfaces is > attached to two different MAGs, and both MAGs successfully create > binding cache entries for the MN at the LMA. The LMA would only > have one binding cache entry pointing to the MAG that sent the last > proxy BU. > > Vijay > > Basavaraj Patil wrote: >> Kilian, >> While it is possible that a multi-interface MN can attach to >> different MAGs >> which cause the MAGs to send a PBU to the same LMA, I personally >> think that >> dealing with this is more of an academic exercise at the present >> time. >> I do not believe we have the possibility of making any changes to >> the MN. So >> that route is closed... At least for now. >> So here is how I view the current scenario which IMO is academic >> at this >> time and hence not something that we should be spending a lot of >> time on : >> - If an MN attaches to multiple MAGs via different interfaces this >> would >> trigger the MAGs to send PBUs to the LMA >> - If the LMA receives them almost simultaneously (as an example), >> and a >> PBAck has not been sent, then the LMA can choose to create an >> entry in the >> BC for the last received PBU and ACK only the last received PBU >> (the LMA >> would believe that the MN which attached to MAG1 moved to MAG2 >> resulting in >> the transmission of PBUs from MAG1 and MAG2 near simulatenously) >> - If the MN receives a PBU from another MAG for an MN which has an >> entry in >> the BC as a result of a second interface attaching to a MAG, the >> LMA would >> view this as the MN having moved to MAG2 and hence would delete >> the BCE for >> MAG1 and insert MAG2 for the MN >> But if we merely state (or mandate) that the LMA will only have >> only one MAG >> entry in the BC at any given time, we would not have a problem >> with the >> multi-homing scenario, right? >> -Raj >> On 9/26/07 8:10 AM, "ext Kilian Weniger" >> >> wrote: >>> Hi Raj, >>> >>> I think we should differentiate between two cases: >>> 1. supporting multi-homing requested by the host to achieve features >>> like load balancing, failover etc. >>> 2. preventing that PMIP protocol breaks if an unmodified host >>> activates >>> more than one network interface. >>> >>> For case 1, I agree with you that this is out of scope of the >>> base draft >>> and should be handled in a separate multi-homing document. >>> >>> But I think Vidya was talking about case 2 and I agree that this >>> issue >>> should be addressed in the base draft. >>> >>> Currently, I see the following potential issues if an unmodified >>> host >>> activates more than one network interface and happens to attach >>> to more >>> than one MAG of a given PMIP domain simultaneously: >>> - multiple MN interfaces get the same prefix assigned, which may >>> break >>> something (e.g., routing) in the host and may result in loss of >>> connectivity >>> - BCE at LMA constantly and randomly changes since multiple MAGs >>> send >>> PBUs to the LMA for the same MN. This may result in packet loss >>> both in >>> downlink and uplink. >>> - the MAGs may discover and use different LMA addresses for the same >>> host etc. >>> >>> However, I'm not sure how we can solve this issue without >>> modifying the >>> host or mandating not to use multiple interfaces. Any ideas? >>> >>> BR, >>> >>> Kilian >>> >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Mittwoch, 26. September 2007 13:50 >>>> To: ext Kilian Weniger; Narayanan, Vidya >>>> Cc: netlmm@ietf.org >>>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>>> >>>> >>>> Kilian, >>>> >>>> >>>> >>>> >>>> On 9/26/07 3:57 AM, "ext Kilian Weniger" >>>> >>>> wrote: >>>> >>>>> Hi Vidya, >>>>> >>>>> I agree that we need some text about this issue. >>>>> >>>>> Narayanan, Vidya wrote: >>>>>> - define LMA behavior such that regular multihomed IP devices >>>>>> don't run >>>>>> into issues of connectivity or shutting down interfaces. >>>> This is much >>>>>> more logical in my view and it is not a big change in the >>>>>> document. >>>>> Can you elaborate how this would work? How does the LMA >>>> differentiate >>>>> between PBUs that were triggered by the same vs different >>>> MN interfaces? >>>>> >>>>> I guess the MAG would need to include some kind of MN >>>> physical network >>>>> interface ID in the PBU, but what kind of ID would that be >>>> and how does >>>>> the MAG learn that ID? Note that the MN's link-local address >>>>> may not >>>>> work as an ID in general, since the MN may implement a kind >>>> of virtual >>>>> network interface which hides multiple physical network >>>> interfaces and >>>>> only exposes a single (virtual) network interface to the IP >>>> stack. This >>>>> may result in the same link-local address for multiple physical >>>>> interfaces. >>>>> So do we need to mandate something on the MN side to solve >>>> this issue in >>>>> the general case? >>>> One of the tenets of Netlmm protocol has been to not require >>>> any changes or >>>> requirements on the MN. So it is not an option. >>>> >>>> Issues that arise from multi-homing and how to deal with them >>>> should be >>>> dealt separately and not in the scope of this I-D. >>>> >>>> -Raj >>>> >>>>> Kilian >>>>> >>>>> >>>>> Panasonic R&D Center Germany GmbH >>>>> 63225 Langen, Hessen, Germany >>>>> Reg: AG Offenbach (Hessen) HRB 33974 >>>>> Managing Director: Thomas Micke >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>> >>>> >>> >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 >>> Managing Director: Thomas Micke >>> >>> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 19:12:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iag37-0001gK-1c; Wed, 26 Sep 2007 19:12:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iag35-0001fR-Tn for netlmm@ietf.org; Wed, 26 Sep 2007 19:12:07 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iag30-0003Yq-Nb for netlmm@ietf.org; Wed, 26 Sep 2007 19:12:07 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8QNBdm19826; Wed, 26 Sep 2007 23:11:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Date: Wed, 26 Sep 2007 18:11:34 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116FF81C4@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBA= References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> <46FA9FFC.4070608@azairenet.com> From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Vijay Devarapalli" , "Kilian Weniger" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, Using revocation for the compromised MAG was proposed by Kilian, et. al. but I am trying to help closing the issue so please allow me to jump into this debate. In order for the LMA to validate the presence of the MN at a specific MAG, the LMA needs to do one of the followings: 1. Validate the MN identity via a MN signature carried in the P-BU. In P-MIPv6 this currently is not available since the P-BU is NOT initiated by the MN. (the most obvious option) 2. Validate the MN presence via another trusted entity that *ALWAYS* tracks the MN current location, e.g. AAA server. 3. Validate the MN presence via another trusted entity that tracks the current or latest location of the MN, e.g. the previous MAG using binding revocation as was suggested by kilian et. al. 4. may be there are other ways... In case that the MN is still at pMAG and has not moved, the pMAG can easily indicate that in the binding revocation acknowledgement. So do not you think that should work? Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Wednesday, September 26, 2007 3:49 PM > To: Vijay Devarapalli; Kilian Weniger > Cc: netlmm@ietf.org > Subject: RE: Compromised MAG issue (was [netlmm] Review of=20 > draft-ietf-netlmm-proxymip6-05) >=20 >=20 > A few observations here. I don't believe binding revocation=20 > is going to solve anything here. The fundamental issue is=20 > how the LMA *identifies* the compromised MAG, not how the=20 > compromised MAG is notified that its binding is no longer=20 > valid. Once the MAG is identified as compromised, a number=20 > of remedies may be taken, including, simply blacklisting the=20 > MAG and not accepting PBUs from it. It is not critical that=20 > the binding be revoked, because, the LMA has already=20 > identified where the MN really is and it just needs to use=20 > that binding for data acceptance/forwarding. >=20 >=20 > The issue of how the LMA identifies a compromised MAG cannot=20 > be tackled without an independent verification of the=20 > presence of the MN at that particular MAG. So, we need to=20 > focus on providing hints on how the LMA may go about achieving that.=20 >=20 > Vidya >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > Sent: Wednesday, September 26, 2007 11:08 AM > > To: Kilian Weniger > > Cc: Narayanan, Vidya; netlmm@ietf.org > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > draft-ietf-netlmm-proxymip6-05) > >=20 > > Kilian Weniger wrote: > > > Narayanan, Vidya wrote: > > >>>> - Security considerations: MAG Compromise:=20 > > > ... > > >> If we claim this is an issue in the security > > considerations section > > >> and claim that the fix to it is for the LMA to ensure the MN is=20 > > >> actually attached to the MAG, we can't quite hand wave on some=20 > > >> possible ways to do that. Those are just hints for > > deployments that > > >> are concerned about MAG compromise. But, those hints need to be=20 > > >> captured in the security considerations section. The threats=20 > > >> document captures this threat and it is a valid one - so, > > I believe > > >> we need some text here. The type of "detail" is what I tried to=20 > > >> provide with the examples on AAA checks or CGA=20 > signatures - and, I=20 > > >> don't think we need a lot of detail here; a few=20 > sentences would be=20 > > >> good. > > >> > > >=20 > > > I had a similar comment a while ago. I think that a draft > > describing a > > > severe security issue should at least give hints how this > > can be solved. > > >=20 > > > Recently Sri, Vijay, Kuntal and I had an offline discussion about=20 > > > another possible solution to detect a compromised MAGs, > > which relies > > > on PMIP signaling only. > > >=20 > > > The basic idea is that if two MAGs simultaneously claim > > that the MN is > > > attached, one of the MAGs must lie and is probably a > > compromised MAG. > > > The assumption is that the MN cannot at the same time be > > attached to > > > two MAGs, at least not with the same network interface. > > >=20 > > > More specifically, when the LMA accepts a valid PBU from a > > new MAG, it > > > changes the BCE (i.e., there is no impact on handover delay) and=20 > > > notifies the old MAG (i.e., old address in BCE) about=20 > this. The old=20 > > > MAG then checks whether the MN is still attached. If this > > is the case, > > > it informs the LMA about this. The LMA then learns that two > > different > > > MAGs claim MN attachement, which is not possible under the > > assumption > > > stated above. Hence, after receiving one or more such > > notifications, > > > the LMA can identify the compromised MAG and stop=20 > trusting this MAG. > > >=20 > > > A remaining problem was which message should be used to > > inform the old > > > MAG about the BCE change. PBA and revocation msg were > > discussed, but > > > the former is not sent unsolicited according to RFC3775 > > (which could > > > be overidden by PMIP spec of course) and the latter is not=20 > > > standardized yet. > >=20 > > As I said in another threat, we really need to standardize the=20 > > revocation message from the LMA to the old MAG ASAP. > >=20 > > Vijay > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 19:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagXC-0000XK-0x; Wed, 26 Sep 2007 19:43:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IagXA-00005e-J2 for netlmm@ietf.org; Wed, 26 Sep 2007 19:43:12 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IagX7-0003RM-U0 for netlmm@ietf.org; Wed, 26 Sep 2007 19:43:10 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8QNh1TD005489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 16:43:01 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8QNgx9a009177; Wed, 26 Sep 2007 16:43:00 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 16:43:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Wed, 26 Sep 2007 16:42:59 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1A References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> From: "Narayanan, Vidya" To: "Sri Gundavelli" X-OriginalArrivalTime: 26 Sep 2007 23:43:00.0119 (UTC) FILETIME=[F8E94270:01C80096] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Folks, =20 It is our responsibility to ensure that the protocol does not break the operation of regular IP nodes. This is not a negotiable point and it is not debatable. This is not a feature, but, a primary part of ensuring that the protocol is designed right. =20 So, I don't believe we can forward this document to the IESG with issues that will break regular IP connectivity of devices. In no way or form is it comparable to other "features" like IPv4 support that was left out of the base document. =20 Let's focus on fixing the problem.=20 Vidya > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Wednesday, September 26, 2007 2:16 PM > To: Narayanan, Vidya > Cc: Basavaraj Patil; ext Kilian Weniger; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Vidya, >=20 >=20 >=20 > On Wed, 26 Sep 2007, Narayanan, Vidya wrote: >=20 > > Sri, > > > >> -----Original Message----- > >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> Sent: Wednesday, September 26, 2007 11:38 AM > >> To: Narayanan, Vidya > >> Cc: Basavaraj Patil; ext Kilian Weniger; netlmm@ietf.org > >> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > >> > >> We dont have to add support for every feature in the base spec. > > > > It is critical differentiate between a "feature" and a=20 > behavior in the=20 > > current spec that may break something on existing IP nodes. Kilian=20 > > clearly articulated the differences here in the multihoming=20 > case. We=20 > > are discussing the latter and that needs to be fixed. > > >=20 > I think, we are just looking at this as an engineering problem. > A deployment has many aspects, we cannot just say, some=20 > operator may plugin the device and the protocol will break.=20 > The base spec does not support IPv4 addressing or IPv4=20 > transport, if some one drops in a device with IPv4 only=20 > stack, the base protocol does not work. Same thing for multi-homing. >=20 > I'm not saying we should not support this scenario. I do not=20 > think, we should try to do a hotch-potch solution in the base=20 > spec and in the last minute. An extension doc is the way to=20 > go. Lets add some reasonable warnings in this document and=20 > leave it for other specs. >=20 > We also need to look at timelines. When draft-sgundave as=20 > adopted as the WG doc, we did send the work items to the=20 > chair and the AD to define the document scope. Number of=20 > things including Auth Option, shared links ..were all listed. > This topic was never in scope. The same thing for Auth=20 > option, we are stuck on this MN-Id, because Auth Option cant fit. > If some one wants to support Auth Option, sure, lets do it as=20 > a new work item. Why bring these arguments on the need for=20 > mobile node's Id. In a proxy model when a mobile is given an=20 > address in a dynamic fashion, how else will the network=20 > entities identify the mobile ? It must be there in signaling messages. >=20 > Its logical to do these work items as seperate drafts and not=20 > try to make them work magically in the current spec and by=20 > opening new issues in the last minute. We can add all these=20 > features, if we dont need to follow any timelines. >=20 > Sri >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 20:39:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IahPU-0000dj-FQ; Wed, 26 Sep 2007 20:39:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IahPS-0000bn-N0 for netlmm@ietf.org; Wed, 26 Sep 2007 20:39:19 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IahPN-0004dJ-Tz for netlmm@ietf.org; Wed, 26 Sep 2007 20:39:14 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8R0d4os010480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 17:39:05 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8R0d3bk012646; Wed, 26 Sep 2007 17:39:04 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 17:39:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Date: Wed, 26 Sep 2007 17:39:02 -0700 Message-ID: In-Reply-To: <46FACF57.5030007@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAhGxrC+u2JSS6SwSWSXUp+XofHwAGfCrQ References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> <46FA9FFC.4070608@azairenet.com> <46FACF57.5030007@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 27 Sep 2007 00:39:03.0706 (UTC) FILETIME=[CDC3E7A0:01C8009E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com]=20 > Sent: Wednesday, September 26, 2007 2:30 PM > To: Narayanan, Vidya > Cc: Kilian Weniger; netlmm@ietf.org > Subject: Re: Compromised MAG issue (was [netlmm] Review of=20 > draft-ietf-netlmm-proxymip6-05) >=20 > Narayanan, Vidya wrote: > > A few observations here. I don't believe binding revocation=20 > is going=20 > > to solve anything here. The fundamental issue is how the LMA=20 > > *identifies* the compromised MAG, not how the compromised MAG is=20 > > notified that its binding is no longer valid. Once the MAG is=20 > > identified as compromised, a number of remedies may be taken,=20 > > including, simply blacklisting the MAG and not accepting=20 > PBUs from it. =20 > > It is not critical that the binding be revoked, because,=20 > the LMA has=20 > > already identified where the MN really is and it just needs=20 > to use that binding for data acceptance/forwarding. >=20 > There is an issue of LMA identifying a compromised MAG. That is true.=20 > But that issue has been complicated by having to deal with=20 > receiving out-of-order proxy BUs from legitimate MAGs. So the=20 > registration revocation mechanism is one component of the solution. >=20 Sorry, I don't understand the issue with out-of-order PBUs - could you please elaborate on it?=20 Vidya > > The issue of how the LMA identifies a compromised MAG cannot be=20 > > tackled without an independent verification of the presence=20 > of the MN=20 > > at that particular MAG. So, we need to focus on providing hints on=20 > > how the LMA may go about achieving that. >=20 > Well, one option is for the LMA to check with the AAA server=20 > if the MN is attached to the MAG currently. We can provide a=20 > hint to this.=20 > Anything else, for example the CGA stuff, would need=20 > substantial explanation on how it is supposed to work. >=20 > Vijay >=20 > >=20 > > Vidya > >=20 > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > >> Sent: Wednesday, September 26, 2007 11:08 AM > >> To: Kilian Weniger > >> Cc: Narayanan, Vidya; netlmm@ietf.org > >> Subject: Re: Compromised MAG issue (was [netlmm] Review of > >> draft-ietf-netlmm-proxymip6-05) > >> > >> Kilian Weniger wrote: > >>> Narayanan, Vidya wrote: > >>>>>> - Security considerations: MAG Compromise:=20 > >>> ... > >>>> If we claim this is an issue in the security > >> considerations section > >>>> and claim that the fix to it is for the LMA to ensure the MN is=20 > >>>> actually attached to the MAG, we can't quite hand wave on some=20 > >>>> possible ways to do that. Those are just hints for > >> deployments that > >>>> are concerned about MAG compromise. But, those hints need to be=20 > >>>> captured in the security considerations section. The threats=20 > >>>> document captures this threat and it is a valid one - so, > >> I believe > >>>> we need some text here. The type of "detail" is what I tried to=20 > >>>> provide with the examples on AAA checks or CGA=20 > signatures - and, I=20 > >>>> don't think we need a lot of detail here; a few=20 > sentences would be=20 > >>>> good. > >>>> > >>> I had a similar comment a while ago. I think that a draft > >> describing a > >>> severe security issue should at least give hints how this > >> can be solved. > >>> Recently Sri, Vijay, Kuntal and I had an offline discussion about=20 > >>> another possible solution to detect a compromised MAGs, > >> which relies > >>> on PMIP signaling only. > >>> > >>> The basic idea is that if two MAGs simultaneously claim > >> that the MN is > >>> attached, one of the MAGs must lie and is probably a > >> compromised MAG. > >>> The assumption is that the MN cannot at the same time be > >> attached to > >>> two MAGs, at least not with the same network interface. > >>> > >>> More specifically, when the LMA accepts a valid PBU from a > >> new MAG, it > >>> changes the BCE (i.e., there is no impact on handover delay) and=20 > >>> notifies the old MAG (i.e., old address in BCE) about=20 > this. The old=20 > >>> MAG then checks whether the MN is still attached. If this > >> is the case, > >>> it informs the LMA about this. The LMA then learns that two > >> different > >>> MAGs claim MN attachement, which is not possible under the > >> assumption > >>> stated above. Hence, after receiving one or more such > >> notifications, > >>> the LMA can identify the compromised MAG and stop=20 > trusting this MAG. > >>> > >>> A remaining problem was which message should be used to > >> inform the old > >>> MAG about the BCE change. PBA and revocation msg were > >> discussed, but > >>> the former is not sent unsolicited according to RFC3775 > >> (which could > >>> be overidden by PMIP spec of course) and the latter is not=20 > >>> standardized yet. > >> As I said in another threat, we really need to standardize the=20 > >> revocation message from the LMA to the old MAG ASAP. > >> > >> Vijay > >> >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 20:41:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IahRp-0002V2-0g; Wed, 26 Sep 2007 20:41:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IahRo-0002Us-FP for netlmm@ietf.org; Wed, 26 Sep 2007 20:41:44 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IahRi-0005ID-1v for netlmm@ietf.org; Wed, 26 Sep 2007 20:41:44 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8R0fHRG010599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 17:41:17 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8R0fGa5017398; Wed, 26 Sep 2007 17:41:16 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 17:41:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Date: Wed, 26 Sep 2007 17:41:15 -0700 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116FF81C4@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBAABg9sAA== References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> <46FA9FFC.4070608@azairenet.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF81C4@zrc2hxm2.corp.nortel.com> From: "Narayanan, Vidya" To: "Ahmad Muhanna" , "Vijay Devarapalli" , "Kilian Weniger" X-OriginalArrivalTime: 27 Sep 2007 00:41:16.0393 (UTC) FILETIME=[1CDA5590:01C8009F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, =20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Wednesday, September 26, 2007 4:12 PM > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > Cc: netlmm@ietf.org > Subject: RE: Compromised MAG issue (was [netlmm] Review of=20 > draft-ietf-netlmm-proxymip6-05) >=20 > Hi Vidya, >=20 > Using revocation for the compromised MAG was proposed by=20 > Kilian, et. al. > but I am trying to help closing the issue so please allow me=20 > to jump into this debate. >=20 > In order for the LMA to validate the presence of the MN at a=20 > specific MAG, the LMA needs to do one of the followings: >=20 > 1. Validate the MN identity via a MN signature carried in the P-BU. In > P-MIPv6 this currently is not available since the P-BU is NOT=20 > initiated by the MN. (the most obvious option) >=20 > 2. Validate the MN presence via another trusted entity that=20 > *ALWAYS* tracks the MN current location, e.g. AAA server. >=20 > 3. Validate the MN presence via another trusted entity that=20 > tracks the current or latest location of the MN, e.g. the=20 > previous MAG using binding revocation as was suggested by=20 > kilian et. al. >=20 The LMA can't assume that the pMAG is trusted while the new MAG is the one lying. Perhaps the MN really moved and the pMAG continues to claim it is there. Regardless of which MAG tells the LMA what, 1 or 2 needs to occur to conclude where the MN really is and then, the LMA can determine which of the MAGs was lying.=20 Regards, Vidya > 4. may be there are other ways... >=20 > In case that the MN is still at pMAG and has not moved, the=20 > pMAG can easily indicate that in the binding revocation=20 > acknowledgement. >=20 > So do not you think that should work? >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Wednesday, September 26, 2007 3:49 PM > > To: Vijay Devarapalli; Kilian Weniger > > Cc: netlmm@ietf.org > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > draft-ietf-netlmm-proxymip6-05) > >=20 > >=20 > > A few observations here. I don't believe binding revocation=20 > is going=20 > > to solve anything here. The fundamental issue is how the LMA=20 > > *identifies* the compromised MAG, not how the compromised MAG is=20 > > notified that its binding is no longer valid. Once the MAG is=20 > > identified as compromised, a number of remedies may be taken,=20 > > including, simply blacklisting the MAG and not accepting=20 > PBUs from it. =20 > > It is not critical that the binding be revoked, because,=20 > the LMA has=20 > > already identified where the MN really is and it just needs to use=20 > > that binding for data acceptance/forwarding. > >=20 > >=20 > > The issue of how the LMA identifies a compromised MAG cannot=20 > > be tackled without an independent verification of the=20 > > presence of the MN at that particular MAG. So, we need to=20 > > focus on providing hints on how the LMA may go about=20 > achieving that.=20 > >=20 > > Vidya > >=20 > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > > Sent: Wednesday, September 26, 2007 11:08 AM > > > To: Kilian Weniger > > > Cc: Narayanan, Vidya; netlmm@ietf.org > > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > > draft-ietf-netlmm-proxymip6-05) > > >=20 > > > Kilian Weniger wrote: > > > > Narayanan, Vidya wrote: > > > >>>> - Security considerations: MAG Compromise:=20 > > > > ... > > > >> If we claim this is an issue in the security > > > considerations section > > > >> and claim that the fix to it is for the LMA to ensure=20 > the MN is=20 > > > >> actually attached to the MAG, we can't quite hand wave on some=20 > > > >> possible ways to do that. Those are just hints for > > > deployments that > > > >> are concerned about MAG compromise. But, those hints=20 > need to be=20 > > > >> captured in the security considerations section. The threats=20 > > > >> document captures this threat and it is a valid one - so, > > > I believe > > > >> we need some text here. The type of "detail" is what=20 > I tried to=20 > > > >> provide with the examples on AAA checks or CGA=20 > > signatures - and, I=20 > > > >> don't think we need a lot of detail here; a few=20 > > sentences would be=20 > > > >> good. > > > >> > > > >=20 > > > > I had a similar comment a while ago. I think that a draft > > > describing a > > > > severe security issue should at least give hints how this > > > can be solved. > > > >=20 > > > > Recently Sri, Vijay, Kuntal and I had an offline=20 > discussion about=20 > > > > another possible solution to detect a compromised MAGs, > > > which relies > > > > on PMIP signaling only. > > > >=20 > > > > The basic idea is that if two MAGs simultaneously claim > > > that the MN is > > > > attached, one of the MAGs must lie and is probably a > > > compromised MAG. > > > > The assumption is that the MN cannot at the same time be > > > attached to > > > > two MAGs, at least not with the same network interface. > > > >=20 > > > > More specifically, when the LMA accepts a valid PBU from a > > > new MAG, it > > > > changes the BCE (i.e., there is no impact on handover=20 > delay) and=20 > > > > notifies the old MAG (i.e., old address in BCE) about=20 > > this. The old=20 > > > > MAG then checks whether the MN is still attached. If this > > > is the case, > > > > it informs the LMA about this. The LMA then learns that two > > > different > > > > MAGs claim MN attachement, which is not possible under the > > > assumption > > > > stated above. Hence, after receiving one or more such > > > notifications, > > > > the LMA can identify the compromised MAG and stop=20 > > trusting this MAG. > > > >=20 > > > > A remaining problem was which message should be used to > > > inform the old > > > > MAG about the BCE change. PBA and revocation msg were > > > discussed, but > > > > the former is not sent unsolicited according to RFC3775 > > > (which could > > > > be overidden by PMIP spec of course) and the latter is not=20 > > > > standardized yet. > > >=20 > > > As I said in another threat, we really need to standardize the=20 > > > revocation message from the LMA to the old MAG ASAP. > > >=20 > > > Vijay > > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 20:45:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IahVW-0001qc-4V; Wed, 26 Sep 2007 20:45:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IahVV-0001po-5R for netlmm@ietf.org; Wed, 26 Sep 2007 20:45:33 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IahVT-0005Lm-Qt for netlmm@ietf.org; Wed, 26 Sep 2007 20:45:33 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8R0jL8t010884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 17:45:22 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8R0jLPI014127; Wed, 26 Sep 2007 17:45:21 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 17:45:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Retransmissions and timestamps Date: Wed, 26 Sep 2007 17:45:20 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Retransmissions and timestamps Thread-Index: AcgAa91QSn/PgZLXQvGeTGNd78aBRgAM34iw References: <46F848E2.40904@ericsson.com><46F852A3.1040401@azairenet.com><46F91662.6030200@ericsson.com><46F985BE.3030108@azairenet.com> <00cf01c7ffe3$64cd6570$1220fea9@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" X-OriginalArrivalTime: 27 Sep 2007 00:45:21.0102 (UTC) FILETIME=[AEB5F6E0:01C8009F] X-Spam-Score: -4.0 (----) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org =20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Wednesday, September 26, 2007 11:34 AM > To: Narayanan, Vidya > Cc: Vijay Devarapalli; Suresh Krishnan; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Retransmissions and timestamps >=20 >=20 > We are not using timestamps for replay protection. >=20 > I responded to this yesterday, please comment on this. >=20 > >> We are not using timestamps for replay protection. When a=20 > message is=20 > >> retransmitted, the entity that is sending the message is=20 > claiming the=20 > >> presence of the node at that instance of time and the timestamp in=20 > >> the message should reflect that. > >> If the nodes keep retransmitting for a longer and longer times, we=20 > >> need to consider lot more cases to handle this correctly.=20 I don't understand what the above means. We need to specify a maximum retransmission value and the LMA should not be responding to retransmissions beyond that. Can you elaborate on what complications retransmissions with the same timestamp value leads to? In fact, to the contrary, if the LMA could never tell the difference between a retransmission and a new PBU, it will continue to process and respond to each one. That seems less desirable to me. What am I missing?=20 Vidya > I do not=20 > >> know, what issues you are Suresh are foreseeing, when a message is=20 > >> retransmitted with a new timestamp. If there is an issue that you=20 > >> see, then we can try to fix this logic. > >> >=20 > Sri >=20 >=20 > On Wed, 26 Sep 2007, Narayanan, Vidya wrote: >=20 > > > > I am then confused by the need for a change in timestamp values for=20 > > retransmissions. I was going by the following from Vijay's=20 > response=20 > > to > > Suresh: > > > > "> No. It should always use the latest timestamp value.=20 > Otherwise the=20 > > LMA > >> would not be able to distinguish between a lost Proxy BU being=20 > >> re-transmitted from a replayed proxy BU." > > > > The text above seems to imply that for sake of detecting a replayed=20 > > PBU, we need to increment timestamps. I was saying that the=20 > > retransmitted PBU will have passed IPsec replay protection, while a=20 > > replayed PBU wouldn't have. So, they are distinguishable. > > > > If IPsec is not used as the security mechanism, the=20 > alternate security=20 > > mechanism that is used must provide its own replay protection. It=20 > > doesn't seem to make sense to rely on PMIP6 to do replay checks=20 > > sometimes and rely on the security protocol for the same at=20 > other times. > > > > > > There is value in doing retransmissions without altering the packet. > > Given the above, is there still a reason why the timestamps=20 > should be=20 > > changed for a retransmitted PBU? > > > > Thanks, > > Vidya > > > >> -----Original Message----- > >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> Sent: Tuesday, September 25, 2007 7:18 PM > >> To: Narayanan, Vidya; 'Vijay Devarapalli'; 'Suresh Krishnan' > >> Cc: netlmm@ietf.org > >> Subject: RE: [netlmm] Issue: Retransmissions and timestamps > >> > >> We are not using timestamps for replay protection. When a=20 > message is=20 > >> retransmitted, the entity that is sending the message is=20 > claiming the=20 > >> presence of the node at that instance of time and the timestamp in=20 > >> the message should reflect that. > >> If the nodes keep retransmitting for a longer and longer times, we=20 > >> need to consider lot more cases to handle this correctly. I do not=20 > >> know, what issues you are Suresh are foreseeing, when a message is=20 > >> retransmitted with a new timestamp. If there is an issue that you=20 > >> see, then we can try to fix this logic. > >> > >> Sri > >> > >> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>> Sent: Tuesday, September 25, 2007 6:55 PM > >>> To: Vijay Devarapalli; Suresh Krishnan > >>> Cc: netlmm@ietf.org > >>> Subject: [netlmm] Issue: Retransmissions and timestamps > >>> > >>> I think this one is worth taking up on its own thread as > >> well. Suresh > >>> and I both raised this issue in our reviews and the > >> excerpts below are > >>> from the ongoing discussions based on Suresh's review. > >>> > >>> I have a meta question here. Replay protection is provided using=20 > >>> IPsec, not using timestamps. Timestamps are meant for=20 > ordering the=20 > >>> PBUs and for that purpose, it really appears to me that > >> retransmitted > >>> PBUs need not change the timestamps. As I mentioned in=20 > my review,=20 > >>> that is desirable from a security perspective. Even from > >> an ordering > >>> perspective, based on the discussions I've seen here, that > >> seems to be > >>> better. > >>> > >>> What is the problem with retransmissions going out with the same=20 > >>> timestamp value? Vijay pointed to replay protection and I > >> claim that > >>> is not needed. Were there other points? > >>> > >>> Thanks, > >>> Vidya > >>> > >>>>>>> Section 6.9.3 > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>>>>> " o If Timestamp based scheme is in use, the > >>> retransmitted Proxy > >>>>>>> Binding Update messages MUST use the latest > >> timestamp. If > >>>>>>> Sequence number scheme is in use, the retransmitted > >>>> Proxy Binding > >>>>>>> Update messages MUST use a Sequence Number value > >>>> greater than that > >>>>>>> used for the previous transmission of this Proxy > >>>> Binding Update > >>>>>>> message, just as specified in [RFC-3775]." > >>>>>>> > >>>>>>> I completely disagree with this. I think if a PBU is > >>>> retransmitted > >>>>>>> it MUST use the same timestamp as the first time around. > >>>> Otherwise > >>>>>>> we will run into ordering problems. > >>>>>> > >>>>>> No. It should always use the latest timestamp value. > >>> Otherwise the > >>>>>> LMA would not be able to distinguish between a lost > >>> Proxy BU being > >>>>>> re-transmitted from a replayed proxy BU. > >>>>> > >>>>> I cannot see how this works. Consider this scenario. > >>>>> > >>>>> MN moves from MAG1 to MAG2 and then to MAG3. > >>>>> > >>>>> M1: MAG2 sends PBU with Timestamp T (This is lost) > >>>>> M2: MAG3 sends PBU with Timestamp T+x (This arrives at LMA > >>>> and updates > >>>>> the binding cache on the LMA) > >>>>> M3: MAG2 retransmits PBU with Timestamp T+x+y(This arrives > >>>> at LMA. LMA > >>>>> sees that the timestamp is later than the current one and then=20 > >>>>> replaces the current entry in the Binding Cache) > >>>> > >>>> MAG2 is supposed to check if the MN is still attached to > >> it before > >>>> re-transmitting the Proxy BU. > >>>> > >>>> IMO, using the registration revocation mechanism for > >> PMIPv6 might be > >>>> the cleanest approach. Any loss of connectivity is likely to be=20 > >>>> temporary once we have the registration revocation mechanism for=20 > >>>> PMIPv6. > >>>> > >>>> Vijay > >>>> > >>>> _______________________________________________ > >>>> netlmm mailing list > >>>> netlmm@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >> > > >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 20:51:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iahb3-0005eW-4a; Wed, 26 Sep 2007 20:51:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iahb1-0005ZS-0O for netlmm@ietf.org; Wed, 26 Sep 2007 20:51:15 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iahb0-0004vt-4H for netlmm@ietf.org; Wed, 26 Sep 2007 20:51:14 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8R0pBNP028840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 17:51:12 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8R0p81k020893; Wed, 26 Sep 2007 17:51:11 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 17:51:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] MN-Id overspecification Date: Wed, 26 Sep 2007 17:51:08 -0700 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116FF804F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAagAEPu0GVwz4RQOWMN9aVbVHtwADyCQwAAI5f+AAB5L6MA== References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> <46FAA143.6070407@azairenet.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF804F@zrc2hxm2.corp.nortel.com> From: "Narayanan, Vidya" To: "Ahmad Muhanna" , "Vijay Devarapalli" , "Alper Yegin" X-OriginalArrivalTime: 27 Sep 2007 00:51:08.0756 (UTC) FILETIME=[7DEDC140:01C800A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, In the case of matching, I did acknowledge that it may be needed when the HNP is set to 0. For any other value of the HNP, the HNP can sufficiently match the messages, can it not?=20 Regards, Vidya=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Wednesday, September 26, 2007 2:43 PM > To: Narayanan, Vidya; Vijay Devarapalli; Alper Yegin > Cc: netlmm@ietf.org > Subject: RE: [netlmm] MN-Id overspecification >=20 > Hi Vidya, >=20 > Please see comments inline. >=20 > Regards, > Ahmad > =20 >=20 > > Subject: RE: [netlmm] MN-Id overspecification > >=20 > >=20 > > Based on a number of these discussions, the role of the=20 > MN-ID is now=20 > > confusing to me. I've so far heard the following uses for MN-ID: > >=20 > > 1. To assign a HNP (this I understand) > >=20 > > 2. To match PBAs with PBUs (I don't get this) > >=20 > > 3. To authorize the HNP to be mapped to that MN-ID (I don't=20 > quite get=20 > > this either) > >=20 > > 1 is clear to me and I see why an MN-ID needs to be included in the=20 > > PBUs that set the HNP to 0. >=20 > > 2 doesn't make sense to me, > =20 > [Ahmad-START-1] > I am not sure what do you mean here. Earlier you agreed that=20 > it is needed but now I am confused. Let me give more details here: >=20 > 1. PMIPv6 base protocol supports both timestamp and SQN, NO? > 2. Also, as we all know, SQN needs to be tracked on a per-MN basis. > 3. SQN field is restricted to 2 bytes i.e. =3D~ 64k.=20 > 4. In this case, there is a very high probability that there=20 > will be collisions of the SQN of the outstanding P-BU(s). > 5. This means that MN1 and MN101 have the same SQN=3Dxyz=20 > inserted in their respected P-BU messages. > 6. When MAG receives the P-BA for MN101, according to=20 > RFC3775, MAG needs to find the matching P-BU based on SQN xyz. >=20 > 7. okay, there are two P-BU(s) that are outstanding waiting for reply. > Right? > 7.1. How the MAG needs to know which MN the P-BA belongs to? > 7.2. MAG needs to use NAI to differentiate. Right? >=20 > Why then this does not make sense? >=20 > [Ahmad-END-1] >=20 > > match responses to requests. > > Also, on the matching aspect, I > > think the document needs clarity, since it sometimes states that=20 > > sequence numbers are used, sometimes that timestamps are=20 > used and some=20 > > other times that MN-ID is used. >=20 > [Ahmad-START-2] > The same concept actually applies to timestamp too. However,=20 > in the case of time stamp, the possibility of collision is=20 > way much less. In other words, it is needed either way. >=20 > May be what you are saying is the draft needs to use more=20 > details to explain this, but I guess when it comes to SQN,=20 > the original text already in RFC3775. >=20 > [Ahmad-END-2] >=20 > > It even > > mandates copying of the sequence number from the PBU to the PBA for=20 > > this purpose. We need to get this cleaned up. >=20 > [Ahmad-START-3] >=20 > What do you expect LMA should return a SQN of ZERO. On the=20 > other hand, there is no indication of what the MAG is using=20 > the SQN for. Returning the SQN is the proper approach. >=20 > [Ahmad-END-3] > >=20 > > On 3, it is not clear what we are achieving. This is different from=20 > > the > > MIP6 case, since in MIP6, the ID is tied to HoA which is=20 > tied to the=20 > > SA and hence, if the HoA came in with the right SA, everything is=20 > > good. > > Here, there isn't an SA tied to anything that belongs to=20 > the MN. So,=20 > > simply carrying the MN-ID in the PBU doesn't provide any=20 > assurance of=20 > > that ID being tied to that HNP, other than simply trusting the MAG. > > So, not carrying the MN-ID is not > > taking away any existing guarantee - when the LMA receives=20 > a PBU for a=20 > > given HNP, it needs to update that binding. > > If the LMA is doing something additional to verify the existence of=20 > > the MN at that MAG, it has the HNP to MN-ID mapping anyway=20 > to do that. > >=20 > > So, why do we need the MN-ID for anything other than 1?=20 > >=20 > > Thanks, > > Vidya > >=20 > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > > Sent: Wednesday, September 26, 2007 11:13 AM > > > To: Alper Yegin > > > Cc: netlmm@ietf.org > > > Subject: Re: [netlmm] MN-Id overspecification > > >=20 > > > Alper Yegin wrote: > > > > Ahmad, > > > >=20 > > > >> In case that a HNP is available at the MAG (how:=20 > > out-of-scope) and > > > >> included in the initial P-BU, ... > > > >=20 > > > > ... MAG is not required to include an NAI option that=20 > carries the=20 > > > > MN-identifier. > > > >=20 > > > > In the spec, all we need to say is "MN-Identifier MUST be > > > included in > > > > PBU when the HNP is set to 0::0/0" > > >=20 > > > Of course not. If the MAG is going to be presenting the > > home network > > > prefix in the proxy binding update to the LMA, then the LMA > > needs to > > > check if the mobile node is authorized for the home=20 > network prefix.=20 > > > For this check to happen, the MN-ID must be there in the > > proxy binding > > > update even if the home network prefix is set to something > > other than > > > 0::0. > > >=20 > > > In Mobile IPv6, the HA performs this check by getting the > > identifier > > > from the IKEv1/IKEv2 exchange. Since we don't have a IKEv1/IKEv2=20 > > > exchange between the MN and the LMA, the proxy BU from=20 > the MAG must=20 > > > have the MN-ID. > > >=20 > > > Vijay > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 21:21:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iai3k-0006hD-MO; Wed, 26 Sep 2007 21:20:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iai3j-0006h7-NF for netlmm@ietf.org; Wed, 26 Sep 2007 21:20:55 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iai3j-0005Yi-0t for netlmm@ietf.org; Wed, 26 Sep 2007 21:20:55 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8R1Kqbj015490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 18:20:53 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8R1KqZF031078; Wed, 26 Sep 2007 18:20:52 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 18:20:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] MN-Id overspecification Date: Wed, 26 Sep 2007 18:20:49 -0700 Message-ID: In-Reply-To: <46FAC9D0.8070604@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAgSdOFpBaVcBSSF+jCuKjmgCXwgAH3Crg References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> <46FAA143.6070407@azairenet.com> <46FAC9D0.8070604@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 27 Sep 2007 01:20:51.0780 (UTC) FILETIME=[A4B1A040:01C800A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vijay,=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com]=20 > Sent: Wednesday, September 26, 2007 2:06 PM > To: Narayanan, Vidya > Cc: Alper Yegin; netlmm@ietf.org > Subject: Re: [netlmm] MN-Id overspecification >=20 > Hi Vidya, >=20 > Narayanan, Vidya wrote: > > Based on a number of these discussions, the role of the=20 > MN-ID is now=20 > > confusing to me. I've so far heard the following uses for MN-ID: > >=20 > > 1. To assign a HNP (this I understand) > >=20 > > 2. To match PBAs with PBUs (I don't get this) > >=20 > > 3. To authorize the HNP to be mapped to that MN-ID (I don't=20 > quite get=20 > > this either) > >=20 > > 1 is clear to me and I see why an MN-ID needs to be included in the=20 > > PBUs that set the HNP to 0. 2 doesn't make sense to me, since when=20 > > the HNP is present, that is sufficient to match responses=20 > to requests. >=20 > You are mixing up threads here. In one thread it was claimed=20 > that it is used for matching proxy BU to proxy BAck. In that=20 > it was assumed there is no home network prefix assigned for=20 > the MN yet.=20 Yes, as I just wrote in my response to Ahmad, this is correct. But, in this thread, we were discussing if the MN-ID is needed for every message. I was getting at the point that it is not needed in every PBU/PBA for the purpose of matching. =20 > Note that we don't have a mechanism described in=20 > the base PMIPv6 specification for the MAG to obtain the home=20 > network prefix without the LMA involvement. >=20 Ack.=20 > > On 3, it is not clear what we are achieving. This is different from=20 > > the > > MIP6 case, since in MIP6, the ID is tied to HoA which is=20 > tied to the=20 > > SA and hence, if the HoA came in with the right SA,=20 > everything is good. > > Here, there isn't an SA tied to anything that belongs to=20 > the MN. So,=20 > > simply carrying the MN-ID in the PBU doesn't provide any=20 > assurance of=20 > > that ID being tied to that HNP, other than simply trusting=20 > the MAG. =20 > > So, not carrying the MN-ID is not taking away any existing=20 > guarantee -=20 > > when the LMA receives a PBU for a given HNP, it needs to=20 > update that binding. > > If the LMA is doing something additional to verify the existence of=20 > > the MN at that MAG, it has the HNP to MN-ID mapping anyway=20 > to do that. >=20 > If the LMA did not assign the prefix for the mobile node and=20 > the MAG obtained it through other means, the LMA would need=20 > to check if the mobile node is authorized for that home=20 > network prefix. For example the LMA could check with the=20 > entity that did the allocation. >=20 Given what you just said above (i.e., we can only allocate prefixes through the LMA), how is this valid? But, let's suppose it is and the MAG obtained the prefix from an independent entity. How can we assume that the identity used to obtain the prefix from the independent entity is the same as the MN-ID presented in the PBU? Given that we don't define that independent mechanism of obtaining prefixes, we can't make this assumption, right?=20 Vidya > Vijay >=20 > >=20 > > So, why do we need the MN-ID for anything other than 1?=20 > >=20 > > Thanks, > > Vidya > >=20 > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >> Sent: Wednesday, September 26, 2007 11:13 AM > >> To: Alper Yegin > >> Cc: netlmm@ietf.org > >> Subject: Re: [netlmm] MN-Id overspecification > >> > >> Alper Yegin wrote: > >>> Ahmad, > >>> > >>>> In case that a HNP is available at the MAG (how:=20 > out-of-scope) and=20 > >>>> included in the initial P-BU, ... > >>> ... MAG is not required to include an NAI option that carries the=20 > >>> MN-identifier. > >>> > >>> In the spec, all we need to say is "MN-Identifier MUST be > >> included in > >>> PBU when the HNP is set to 0::0/0" > >> Of course not. If the MAG is going to be presenting the=20 > home network=20 > >> prefix in the proxy binding update to the LMA, then the=20 > LMA needs to=20 > >> check if the mobile node is authorized for the home=20 > network prefix.=20 > >> For this check to happen, the MN-ID must be there in the proxy=20 > >> binding update even if the home network prefix is set to something=20 > >> other than 0::0. > >> > >> In Mobile IPv6, the HA performs this check by getting the=20 > identifier=20 > >> from the IKEv1/IKEv2 exchange. Since we don't have a IKEv1/IKEv2=20 > >> exchange between the MN and the LMA, the proxy BU from the=20 > MAG must=20 > >> have the MN-ID. > >> > >> Vijay > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 21:29:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaiCD-0006hW-PE; Wed, 26 Sep 2007 21:29:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaiCC-0006g6-E5 for netlmm@ietf.org; Wed, 26 Sep 2007 21:29:40 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaiCC-0005rj-0h for netlmm@ietf.org; Wed, 26 Sep 2007 21:29:40 -0400 X-IronPort-AV: E=Sophos;i="4.21,200,1188802800"; d="scan'208";a="10747970" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 26 Sep 2007 18:29:39 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8R1TdkO025172; Wed, 26 Sep 2007 18:29:39 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8R1TZDL011968; Thu, 27 Sep 2007 01:29:35 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 18:29:34 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 18:29:34 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" References: <46F848E2.40904@ericsson.com><46F852A3.1040401@azairenet.com><46F91662.6030200@ericsson.com><46F985BE.3030108@azairenet.com> <00cf01c7ffe3$64cd6570$1220fea9@amer.cisco.com> Subject: RE: [netlmm] Issue: Retransmissions and timestamps Date: Wed, 26 Sep 2007 18:29:34 -0700 Message-ID: <002901c800a5$dc49d850$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAa91QSn/PgZLXQvGeTGNd78aBRgAM34iwAAEPgSA= X-OriginalArrivalTime: 27 Sep 2007 01:29:34.0662 (UTC) FILETIME=[DC5B1660:01C800A5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2309; t=1190856579; x=1191720579; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Retransmissions=20and=20timesta mps |Sender:=20; bh=f6BCGgwKdDBowAYm2ETqMRX1dfxHTZ7oBV8oTR+xDbs=; b=dkvF1/extAGu7okyFLcfXAeepxwP89d/j37NwVI21rmFVjOVHxEJ8ZwBBbqd/Br05vSZivjM bFZ7jt0UdmxQjdF7H3rS07J/DVnCxx5Lk1wiKiPJH08jCnwnEFrZu3su; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > I don't understand what the above means. We need to specify a maximum > retransmission value and the LMA should not be responding to > retransmissions beyond that. Can you elaborate on what complications > retransmissions with the same timestamp value leads to? In > fact, to the > contrary, if the LMA could never tell the difference between a > retransmission and a new PBU, it will continue to process and > respond to > each one. That seems less desirable to me. What am I missing? > What is not clear to you from the below quoted text. Let me try again. 1. What is the intended purpose of the time stamp ? To ensure ordering of the messages. A node generating the message adds the timestamp. It claims the node is present at that instance of time. Dont you think, if we use the same timestamp in the retransmissions, will that not beat the purpose ? 2. You should explain, rather than dodging the question, what is wrong in the current scheme. If there is an issue, we will be glad to change it. As we worked with Kilian, Ahmad, Federico and evolved this logic. 3. When using sequence numbers, 3775 does not use the same sequence number in retransmitted messages. Why ? This scheme is consistent with 3775. "Retransmitted Binding Updates MUST use a Sequence Number value greater than that used for the previous transmission of this Binding Update. Retransmitted Home Test Init and Care-of Test Init messages MUST use new cookie values." 4. I do not see a need for the LMA to differentiate between the two. The lifetime that it allocates to the session is w.r.t the newly received message. Sri >> We are not using timestamps for replay protection. When a >> message is retransmitted, the entity that is sending the >> message is claiming the presence of the node at that instance >> of time and the timestamp in the message should reflect that. >> If the nodes keep retransmitting for a longer and longer >> times, we need to consider lot more cases to handle this >> correctly. I do not know, what issues you are Suresh are >> foreseeing, when a message is retransmitted with a new >> timestamp. If there is an issue that you see, then we can try >> to fix this logic. >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Wed Sep 26 21:59:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaieU-0003tB-Ox; Wed, 26 Sep 2007 21:58:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaieT-0003rz-GQ for netlmm@ietf.org; Wed, 26 Sep 2007 21:58:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaieT-0006gl-1g for netlmm@ietf.org; Wed, 26 Sep 2007 21:58:53 -0400 X-IronPort-AV: E=Sophos;i="4.21,200,1188802800"; d="scan'208";a="177838069" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 26 Sep 2007 18:58:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8R1wp20011775; Wed, 26 Sep 2007 18:58:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8R1wc1p015644; Thu, 27 Sep 2007 01:58:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 18:58:42 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 18:58:42 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Wed, 26 Sep 2007 18:58:41 -0700 Message-ID: <002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7A= X-OriginalArrivalTime: 27 Sep 2007 01:58:42.0131 (UTC) FILETIME=[EDEDB230:01C800A9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2092; t=1190858331; x=1191722331; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=WkT7ogRUL68Lhh+ZgPG3BCQtCSwsLwxc/WOnKLpBbL4=; b=2TPh3vw+z6eULyTXZDXxe1V080IGlI8gv+jO5icR3h7mc3cLU507cK82y8VTdyJ460iXFp3P VacuL58CDHU/Noqc1hXshdxnvGqX/dI8t/x8/ZMNPNPeuzQXISO2wnoW; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'ext Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Wednesday, September 26, 2007 4:43 PM > To: Sri Gundavelli > Cc: Basavaraj Patil; ext Kilian Weniger; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > Folks, > > It is our responsibility to ensure that the protocol does not > break the > operation of regular IP nodes. This is not a negotiable > point and it is > not debatable. This is not a feature, but, a primary part of ensuring > that the protocol is designed right. > I agree and realize your good intent. That is fine. Please also note that it is also your responsibility to ensure the protocol gets standardized in timely fashion. We are not expecting some partially completed work to push it to the next level. We have put lot of efforts and we believe the work is complete. We responded to the review comments sent by many in the WG, and we are more than happy to fix all the issues that we agreed. However, we are not delighted to deal with these new issues in the last minute. This should been discussed in the WG prior and a consensus should have been noted. Any case, lets wrap this quickly. But, please avoid unwanted delays. There are many SDO bodies that are watching this work. Please be sensitive to that. We will greatly appreciate. Additionally, the comments on MN-Id and the indirect goal of supporting Auth Option, is not giving a clear clarity to an innocent observer. If we want to support Auth Option, lets do it the right way. There are also comments that are intended as hooks for enabling some future work, in the form of creating a reference in this document. This should be noted and clearly the comments from people with such intent, should be discounted. Please make sure, all of this is happening. Lastly, I repeat, I do not see a reason why this feature for supporting mobile nodes with multiple interface and for *Simultaneous* network access cannot be dealt in a separate document. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 00:36:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ial6f-0002ww-PM; Thu, 27 Sep 2007 00:36:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ial6e-0002pb-Ei for netlmm@ietf.org; Thu, 27 Sep 2007 00:36:08 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ial6e-0001ae-3v for netlmm@ietf.org; Thu, 27 Sep 2007 00:36:08 -0400 X-IronPort-AV: E=Sophos;i="4.21,201,1188802800"; d="scan'208";a="225940605" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Sep 2007 21:36:07 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8R4a7SX002913; Wed, 26 Sep 2007 21:36:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8R4Zs1p027289; Thu, 27 Sep 2007 04:36:03 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 21:35:58 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 21:35:57 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" , "'Vijay Devarapalli'" References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net><46FAA143.6070407@azairenet.com><46FAC9D0.8070604@azairenet.com> Subject: RE: [netlmm] MN-Id overspecification Date: Wed, 26 Sep 2007 21:35:57 -0700 Message-ID: <003f01c800bf$e60b6880$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAgSdOFpBaVcBSSF+jCuKjmgCXwgAH3CrgAAdsZcA= X-OriginalArrivalTime: 27 Sep 2007 04:35:57.0971 (UTC) FILETIME=[E6209E30:01C800BF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1064; t=1190867767; x=1191731767; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20MN-Id=20overspecification |Sender:=20; bh=3NHYh0OGx8QF824iIbD6kTWgHnlIW0WzTHIbX8t3OUs=; b=jxUATwLczFWewFKuljwUPGXoreqHz47yg3T7etMnzzDc7C5fXSj98M/jiv83IOquh93sJPiw ZpYwIz+d3I+c7/jkfqnnGXtRYGVfSs/37u5Drzucn3dZP+P5pr4/BOPU; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > > You are mixing up threads here. In one thread it was claimed > > that it is used for matching proxy BU to proxy BAck. In that > > it was assumed there is no home network prefix assigned for > > the MN yet. > > Yes, as I just wrote in my response to Ahmad, this is > correct. But, in > this thread, we were discussing if the MN-ID is needed for every > message. I was getting at the point that it is not needed in every > PBU/PBA for the purpose of matching. I asked the WG to comment on the issue of Timestamp vs Seq Number, this was some time in the Month of May 1st week. The following consensus was explicitly noted. Please note clearly the mandate for returning MN-Id in the PBA's. This was discussed in the NETLMM WG. http://www1.ietf.org/mail-archive/web/netlmm/current/msg02200.html Now, if we say, may be its not required for re-registrations, I dont believe in that fuzzy logic, its adds implementation complexity. Before reopening things that have been agreed upon, let there be a good reason. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 01:59:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IamPM-0000Z9-NI; Thu, 27 Sep 2007 01:59:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IamPL-0000Yq-HA for netlmm@ietf.org; Thu, 27 Sep 2007 01:59:31 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IamPL-0003Nc-21 for netlmm@ietf.org; Thu, 27 Sep 2007 01:59:31 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8R5xP3u001338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 22:59:25 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8R5xOd1025053; Wed, 26 Sep 2007 22:59:24 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 22:59:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Wed, 26 Sep 2007 22:59:04 -0700 Message-ID: In-Reply-To: <002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQA== References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> <002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" X-OriginalArrivalTime: 27 Sep 2007 05:59:23.0982 (UTC) FILETIME=[8DF146E0:01C800CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org All, Here is a description of the issue (I'm picking a simple scenario to describe the issue; there are other scenarios as well; also, this has been described on the list earlier):=20 * MN has two interfaces attached to MAG1 and MAG2 under the same LMA * Let's say MAG1 first created the binding at the LMA and acquired a prefix/address for the MN, using MN-ID1 * MN obtains the prefix/address on Interface1 * MAG2 now sends a PBU with MN-ID1 also (very possible when the ID is something like an NAI) * LMA thinks the MN moved, updates the binding and returns the same prefix for the MN to MAG2 * MN ends up with the same prefix/address on Interface2 At this point, if it is an IPv6 prefix, the MN may configure a different address on Interface 2, but, we would have lost the point-to-point nature and the associated properties of the MN-MAG link; if it is an IPv6 or IPv4 address, the MN detects a duplicate address and shuts down the interface from an IP point of view. The MN thinks only Interface1 is active, while the LMA has a binding to MAG2 (corresponding to Interface2 of the MN). =20 Result: MN does not have any IP access via either of its interfaces. Even if the MN has different addresses on the same prefix on its two interfaces, Interface 1 cannot be used given LMA's state, but, the MN is unaware of that.=20 Some thoughts on avoiding this problem:=20 It seems to me that this is an unavoidable problem if the same MN-ID is sent for multiple interfaces of the MN to the LMA. It seems like an interface-specific ID (link layer address or equivalent) needs to be included in the PBU, so that the LMA can ensure that the same prefix/address is not assigned to multiple IP interfaces of an MN. This may not be too difficult, given that the MN-MAG link is point-to-point. Thoughts?=20 Thanks, Vidya _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 02:49:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IanBU-0006Iy-Ka; Thu, 27 Sep 2007 02:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IanBT-0006Ek-RP for netlmm@ietf.org; Thu, 27 Sep 2007 02:49:15 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IanBL-0004Gr-If for netlmm@ietf.org; Thu, 27 Sep 2007 02:49:13 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8R6mc9e004755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Sep 2007 23:48:39 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8R6mcoB000943; Wed, 26 Sep 2007 23:48:38 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 23:48:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Retransmissions and timestamps Date: Wed, 26 Sep 2007 23:48:37 -0700 Message-ID: In-Reply-To: <002901c800a5$dc49d850$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Retransmissions and timestamps Thread-Index: AcgAa91QSn/PgZLXQvGeTGNd78aBRgAM34iwAAEPgSAAC4OxUA== References: <46F848E2.40904@ericsson.com><46F852A3.1040401@azairenet.com><46F91662.6030200@ericsson.com><46F985BE.3030108@azairenet.com> <00cf01c7ffe3$64cd6570$1220fea9@amer.cisco.com> <002901c800a5$dc49d850$1220fea9@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" X-OriginalArrivalTime: 27 Sep 2007 06:48:38.0073 (UTC) FILETIME=[6EB7CA90:01C800D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri,=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Wednesday, September 26, 2007 6:30 PM > To: Narayanan, Vidya > Cc: 'Vijay Devarapalli'; 'Suresh Krishnan'; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Retransmissions and timestamps >=20 > =20 > > I don't understand what the above means. We need to=20 > specify a maximum=20 > > retransmission value and the LMA should not be responding to=20 > > retransmissions beyond that. Can you elaborate on what=20 > complications=20 > > retransmissions with the same timestamp value leads to? In=20 > fact, to=20 > > the contrary, if the LMA could never tell the difference between a=20 > > retransmission and a new PBU, it will continue to process=20 > and respond=20 > > to each one. That seems less desirable to me. What am I missing? > >=20 >=20 >=20 > What is not clear to you from the below quoted text. Let me try > again. >=20 > 1. What is the intended purpose of the time stamp ? To ensure > ordering of the messages. A node generating the message adds > the timestamp. It claims the node is present at that instance > of time. Dont you think, if we use the same timestamp in the > retransmissions, will that not beat the purpose ? >=20 Not really. A retransmission says that the MAG notified that the MN is present earlier, but, it hasn't heard an ack yet.=20 > 2. You should explain, rather than dodging the question, what > is wrong in the current scheme. If there is an issue, we will > be glad to change it. As we worked with Kilian, Ahmad, Federico > and evolved this logic. >=20 I did explain in my review - basically, retransmissions are efficiently done by simply caching the constructed message until a response is received and sending it again if no response was received within a given time. It also helps the LMA, since the LMA can cache the responses for a short amount of time to simply re-send it upon receiving a retransmitted PBU. This is a commonly used philosophy to mitigate the impact of DoS attacks also - i.e., the idempotent nature of an entity involves less work than processing and responding to each message as if it was a new one. It also helps the LMA to stop responding after a few retransmissions have been responded to. So, I think that unless there is a good reason to increment the timestamps for retransmissions, it shouldn't be. =20 I'll let Suresh outline the issue he was describing. =20 Thanks, Vidya > 3. When using sequence numbers, 3775 does not use the same > sequence number in retransmitted messages. Why ? This scheme > is consistent with 3775. > =20 > "Retransmitted Binding Updates MUST use a Sequence Number value > greater than that used for the previous transmission of=20 > this Binding > Update. Retransmitted Home Test Init and Care-of Test=20 > Init messages > MUST use new cookie values." >=20 > 4. I do not see a need for the LMA to differentiate between the two. > The lifetime that it allocates to the session is w.r.t the newly > received message. >=20 > Sri >=20 >=20 >=20 >=20 >=20 > >> We are not using timestamps for replay protection. When a > >> message is retransmitted, the entity that is sending the > >> message is claiming the presence of the node at that instance > >> of time and the timestamp in the message should reflect that. > >> If the nodes keep retransmitting for a longer and longer > >> times, we need to consider lot more cases to handle this > >> correctly. I do not know, what issues you are Suresh are > >> foreseeing, when a message is retransmitted with a new > >> timestamp. If there is an issue that you see, then we can try > >> to fix this logic. > >> >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 03:31:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IanqH-0007Aa-7U; Thu, 27 Sep 2007 03:31:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IanqF-0007AV-Rp for netlmm@ietf.org; Thu, 27 Sep 2007 03:31:23 -0400 Received: from mout.perfora.net ([74.208.4.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IanqF-0005T5-D1 for netlmm@ietf.org; Thu, 27 Sep 2007 03:31:23 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1IanqB0VsP-0008WT; Thu, 27 Sep 2007 03:31:22 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 10:31:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAUVnb+iCtEhyMRRa8wobJwkSgsgAhtliw In-Reply-To: <46FA79B7.2060101@azairenet.com> Message-Id: <0MKp8S-1IanqB0VsP-0008WT@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+5lrna+k6nElhOCwuCFU3BiG20HQq+OzyEZGR f9Z74pqtYyUVNX/zeDPMutLvgiddonXntTjWobuZqrhyWdYrTj sSlSTFBBvWjK9IEf8dOhA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay, I don't make any distinction between initial vs refresh. The same rule applies: MN-id is only mandated when HNP needs to be assigned. If a refresh lacks the HNP, it must have the mn-id. Alper > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Wednesday, September 26, 2007 6:25 PM > To: Alper Yegin > Cc: netlmm@ietf.org > Subject: Re: [netlmm] MN-Id overspecification > > Alper, > > Just a clarification. Are you saying it should be only in the initial > Proxy BU/Proxy BAck exchange and not in the ones sent to refresh the > binding? > > In case there is a handoff from the old MAG to the new MAG, the new MAG > does not necessarily know the home network prefix for the MN. So in this > case the new MAG would also send a proxy BU with the MN-ID and a request > for the prefix. The LMA would assign the same prefix again. > > Vijay > > Alper Yegin wrote: > > This issue is still hanging. > > > > So far as I understand the MN-Id is only used for performing HNP > assignment > > in-band with PMIP6 signaling. In case HNP is already assigned, there is > no > > need to be carrying any info that directly or indirectly points to the > MN's > > identity. > > > > But on the other hand, MN-id is all over the spec with normative > languages > > that suggest it be present in every message. > > > > This is an overspecification, reducing flexibility and getting in the > ways > > of various deployment scenarios. > > > > I recommend we change the spec such that MN-id is only mandated when HNP > > needs to be assigned. > > > > Would there be an objection to that? Is there any technical reason to > carry > > an identifier of the MN in every PMIP6 message? > > > > > > Alper > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 03:37:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ianvc-0005cq-5Z; Thu, 27 Sep 2007 03:36:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ianvb-0005Ys-4b for netlmm@ietf.org; Thu, 27 Sep 2007 03:36:55 -0400 Received: from mout.perfora.net ([74.208.4.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ianva-0005cA-Kl for netlmm@ietf.org; Thu, 27 Sep 2007 03:36:55 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1IanvV202U-0007VA; Thu, 27 Sep 2007 03:36:54 -0400 From: "Alper Yegin" To: "'Basavaraj Patil'" , "'Ahmad Muhanna'" , Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 10:36:41 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AABDcQjgAd8sdw In-Reply-To: Message-Id: <0MKpCa-1IanvV202U-0007VA@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/oTD4IbOL9b2xuSVf4udHSvdt4p/3XkK88sc3 qbg+6EvARzutHaKs5g1QwfKfVVAEIKVDfDEhSCHVlxq1H06rpX L9pBCwI0RjMmAo4cRCr+A== X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Raj, > What is the downside of including the MN-ID in all the MAG/LMA messages? > Does it break anything? As I had explained earlier, one way to deploy PMIP is to use RFC 4285 with per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In that case, HNP can be assigned during network access authentication (so, we no longer need to convey the id of the "MN" in-band with PMIP), but we need to convey the id of the "proxy-MN (MAG)" for PMIP security. That scenario breaks when we unnecessarily force the protocol to always carry "MN"-id. Even without this I could be arguing against this overspecification based on lack of need and uncertainty around what to put in MN-id. Alper > You say that it "is an overspecification, reducing flexibility and > getting in the ways of various deployment scenarios"... > > How is it becoming an obstacle in any deployment scenario? > > I am just wondering if you are optimizing the protocol by not including > the > MN-ID or if you see this as actually being a problem. > > -Raj > > > On 9/26/07 11:58 AM, "ext Alper Yegin" wrote: > > > Ahmad, > > > >> In case that a HNP is available at the MAG (how: out-of-scope) and > >> included in the initial P-BU, ... > > > > ... MAG is not required to include an NAI option that carries the > > MN-identifier. > > > > In the spec, all we need to say is "MN-Identifier MUST be included in > PBU > > when the HNP is set to 0::0/0" > > > > > > Alper > > > > > > > > NO NAI or any other IDs related to the MN > >> should be included? > >> > >> > >> Regards, > >> Ahmad > >> > >> > >>> -----Original Message----- > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>> Sent: Wednesday, September 26, 2007 7:35 AM > >>> To: netlmm@ietf.org > >>> Subject: [netlmm] MN-Id overspecification > >>> > >>> This issue is still hanging. > >>> > >>> So far as I understand the MN-Id is only used for performing > >>> HNP assignment in-band with PMIP6 signaling. In case HNP is > >>> already assigned, there is no need to be carrying any info > >>> that directly or indirectly points to the MN's identity. > >>> > >>> But on the other hand, MN-id is all over the spec with > >>> normative languages that suggest it be present in every message. > >>> > >>> This is an overspecification, reducing flexibility and > >>> getting in the ways of various deployment scenarios. > >>> > >>> I recommend we change the spec such that MN-id is only > >>> mandated when HNP needs to be assigned. > >>> > >>> Would there be an objection to that? Is there any technical > >>> reason to carry an identifier of the MN in every PMIP6 message? > >>> > >>> > >>> Alper > >>> > >>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 03:51:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iao96-0006ED-SO; Thu, 27 Sep 2007 03:50:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iao95-00067a-Ig for netlmm@ietf.org; Thu, 27 Sep 2007 03:50:51 -0400 Received: from mout.perfora.net ([74.208.4.197]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iao94-00063H-W0 for netlmm@ietf.org; Thu, 27 Sep 2007 03:50:51 -0400 Received: from [88.233.198.36] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Iao910RhY-0007Ua; Thu, 27 Sep 2007 03:50:50 -0400 From: "Alper Yegin" To: "'Chowdhury, Kuntal'" , Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 10:50:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AACh9vIAAYhZmg In-Reply-To: <4D35478224365146822AE9E3AD4A26663FC4D6$0001@exchtewks3.starentnetworks.com> Message-Id: <0MKpCa-1Iao910RhY-0007Ua@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19Y1bq4M5Fi7o7Wv2+KWTzepnY3cPIxr6uSFym i2w6VlCuaYLnFvZWl9U88UavjSE4TL6PvxyaCsODFf8J0YeH/e SJq68+nXf2zaO3fM3tutw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Kuntal, > Even if the HNP is included in the PBU, the user identity cannot be > deterministically derived from that info. The HNP may be dynamically > assigned to the users in many systems. Whoever assigned the HNP has a chance to see the user id. Either it is assigned during the network access authentication, in which case the user id is best known; or it is assigned during the initial PBU in which case I say we shall include MN-id. But once the HNP<->MN-id binding is established like above, we no longer need to keep sending MN-id. HNP becomes the identifier. Alper > The benefit of including the MN-ID (NAI) in the PMIP signaling messages > is that it provides a unique and consistent way to identify the user at > the LMA and the MAG at all times (i.e. initial attach and > re-registration). > > BR, > Kuntal > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Wednesday, September 26, 2007 11:58 AM > > To: 'Ahmad Muhanna'; netlmm@ietf.org > > Subject: RE: [netlmm] MN-Id overspecification > > > > Ahmad, > > > > > In case that a HNP is available at the MAG (how: out-of-scope) and > > > included in the initial P-BU, ... > > > > ... MAG is not required to include an NAI option that carries the > > MN-identifier. > > > > In the spec, all we need to say is "MN-Identifier MUST be included in > PBU > > when the HNP is set to 0::0/0" > > > > > > Alper > > > > > > > > NO NAI or any other IDs related to the MN > > > should be included? > > > > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > > Sent: Wednesday, September 26, 2007 7:35 AM > > > > To: netlmm@ietf.org > > > > Subject: [netlmm] MN-Id overspecification > > > > > > > > This issue is still hanging. > > > > > > > > So far as I understand the MN-Id is only used for performing > > > > HNP assignment in-band with PMIP6 signaling. In case HNP is > > > > already assigned, there is no need to be carrying any info > > > > that directly or indirectly points to the MN's identity. > > > > > > > > But on the other hand, MN-id is all over the spec with > > > > normative languages that suggest it be present in every message. > > > > > > > > This is an overspecification, reducing flexibility and > > > > getting in the ways of various deployment scenarios. > > > > > > > > I recommend we change the spec such that MN-id is only > > > > mandated when HNP needs to be assigned. > > > > > > > > Would there be an objection to that? Is there any technical > > > > reason to carry an identifier of the MN in every PMIP6 message? > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. > Any review, retransmission, dissemination or other use of, or taking of > any action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not > the intended recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this message > and any attachments without reading or disclosing their contents. Thank > you." _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 04:53:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iap76-0004Xi-3a; Thu, 27 Sep 2007 04:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iap74-0004XL-OZ for netlmm@ietf.org; Thu, 27 Sep 2007 04:52:50 -0400 Received: from mout.perfora.net ([74.208.4.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iap6u-0007dI-Pd for netlmm@ietf.org; Thu, 27 Sep 2007 04:52:50 -0400 Received: from [88.233.215.25] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1Iap6Z10aj-0008JP; Thu, 27 Sep 2007 04:52:25 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 11:52:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAaO6ecckygTGLR8eKWLqA+PWvhwAclTRw In-Reply-To: <46FAA143.6070407@azairenet.com> Message-Id: <0MKp8S-1Iap6Z10aj-0008JP@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18A3/G2RMXL/noHuBD7m1hQLPv6+muNbKrEB63 SXZCDJwjtORd2YCDT+6Mr8864szZbGXRe2KeWBww1YoF1At/bH sIKPxcFe9/LDBixmCtuXg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > > Ahmad, > > > >> In case that a HNP is available at the MAG (how: out-of-scope) and > >> included in the initial P-BU, ... > > > > ... MAG is not required to include an NAI option that carries the > > MN-identifier. > > > > In the spec, all we need to say is "MN-Identifier MUST be included in > PBU > > when the HNP is set to 0::0/0" > > Of course not. If the MAG is going to be presenting the home network > prefix in the proxy binding update to the LMA, then the LMA needs to > check if the mobile node is authorized for the home network prefix. For > this check to happen, the MN-ID must be there in the proxy binding > update even if the home network prefix is set to something other than > 0::0. What really needs to be authorized is the "MAG" for sucking in all the traffic destined for a HNP. Checking if the MN-id and HNP matches is meaningless next to this one. In order to do the former, the system internally needs to perform the latter. Let me be more specific, but note that these are outside scope of PMIP6 spec. During network access authentication, the home network associates MN and MAG. Since we care about protecting the HNP, home network already knows the MN and HNP association. So, when the MAG sends the PBU, home network can check if the requested HNP matches those of MNs that are associated with the MAG. See that does not involve carrying the MN-id (when HNP is present in the PBU). Alper > > In Mobile IPv6, the HA performs this check by getting the identifier > from the IKEv1/IKEv2 exchange. Since we don't have a IKEv1/IKEv2 > exchange between the MN and the LMA, the proxy BU from the MAG must have > the MN-ID. > > Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 05:28:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IapfG-0008Rg-M6; Thu, 27 Sep 2007 05:28:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IapfF-0008RV-Gq for netlmm@ietf.org; Thu, 27 Sep 2007 05:28:09 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IapfE-0001UI-TC for netlmm@ietf.org; Thu, 27 Sep 2007 05:28:09 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1190885286!624059!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3397 invoked from network); 27 Sep 2007 09:28:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 27 Sep 2007 09:28:07 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8R9S6Mb029600; Thu, 27 Sep 2007 02:28:06 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l8R9S6S6007461; Thu, 27 Sep 2007 04:28:06 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8R9S4I3007425; Thu, 27 Sep 2007 04:28:04 -0500 (CDT) Message-ID: <46FB77A3.6040409@gmail.com> Date: Thu, 27 Sep 2007 11:28:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKpCa-1IanvV202U-0007VA@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IanvV202U-0007VA@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-1, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Raj, > >> What is the downside of including the MN-ID in all the MAG/LMA messages? >> Does it break anything? > > As I had explained earlier, one way to deploy PMIP is to use RFC 4285 with > per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In that case, HNP > can be assigned during network access authentication (so, we no longer need > to convey the id of the "MN" in-band with PMIP), but we need to convey the > id of the "proxy-MN (MAG)" for PMIP security. > > That scenario breaks when we unnecessarily force the protocol to always > carry "MN"-id. > > Even without this I could be arguing against this overspecification based on > lack of need and uncertainty around what to put in MN-id. Alper, please don't try to bring in 4285 via MN-Id. I don't support 4285 for PMIPv6. 4285 and draft-4285bis are _very_ poorly specified and are being currently discussed in MIP6. Many issues that I've raised haven't been dealt with, but I will not hesitate to re-raise them again when time comes, on that list. Alex > > Alper > > > >> You say that it "is an overspecification, reducing flexibility and >> getting in the ways of various deployment scenarios"... >> >> How is it becoming an obstacle in any deployment scenario? >> >> I am just wondering if you are optimizing the protocol by not including >> the >> MN-ID or if you see this as actually being a problem. >> >> -Raj >> >> >> On 9/26/07 11:58 AM, "ext Alper Yegin" wrote: >> >>> Ahmad, >>> >>>> In case that a HNP is available at the MAG (how: out-of-scope) and >>>> included in the initial P-BU, ... >>> ... MAG is not required to include an NAI option that carries the >>> MN-identifier. >>> >>> In the spec, all we need to say is "MN-Identifier MUST be included in >> PBU >>> when the HNP is set to 0::0/0" >>> >>> >>> Alper >>> >>> >>> >>> NO NAI or any other IDs related to the MN >>>> should be included? >>>> >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>>>> Sent: Wednesday, September 26, 2007 7:35 AM >>>>> To: netlmm@ietf.org >>>>> Subject: [netlmm] MN-Id overspecification >>>>> >>>>> This issue is still hanging. >>>>> >>>>> So far as I understand the MN-Id is only used for performing >>>>> HNP assignment in-band with PMIP6 signaling. In case HNP is >>>>> already assigned, there is no need to be carrying any info >>>>> that directly or indirectly points to the MN's identity. >>>>> >>>>> But on the other hand, MN-id is all over the spec with >>>>> normative languages that suggest it be present in every message. >>>>> >>>>> This is an overspecification, reducing flexibility and >>>>> getting in the ways of various deployment scenarios. >>>>> >>>>> I recommend we change the spec such that MN-id is only >>>>> mandated when HNP needs to be assigned. >>>>> >>>>> Would there be an objection to that? Is there any technical >>>>> reason to carry an identifier of the MN in every PMIP6 message? >>>>> >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 05:30:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaphH-0004vq-KK; Thu, 27 Sep 2007 05:30:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaphG-0004mv-Rz for netlmm@ietf.org; Thu, 27 Sep 2007 05:30:14 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IaphC-0001XP-TW for netlmm@ietf.org; Thu, 27 Sep 2007 05:30:11 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1190885409!34428930!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8704 invoked from network); 27 Sep 2007 09:30:10 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 27 Sep 2007 09:30:10 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8R9U90Z000155; Thu, 27 Sep 2007 02:30:09 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l8R9U9FK009464; Thu, 27 Sep 2007 04:30:09 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l8R9U79P009422; Thu, 27 Sep 2007 04:30:08 -0500 (CDT) Message-ID: <46FB781F.3090509@gmail.com> Date: Thu, 27 Sep 2007 11:30:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKpCa-1Iao910RhY-0007Ua@mrelay.perfora.net> In-Reply-To: <0MKpCa-1Iao910RhY-0007Ua@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-1, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Kuntal, > >> Even if the HNP is included in the PBU, the user identity cannot be >> deterministically derived from that info. The HNP may be dynamically >> assigned to the users in many systems. > > Whoever assigned the HNP has a chance to see the user id. Either it is > assigned during the network access authentication, in which case the user id > is best known; or it is assigned during the initial PBU in which case I say > we shall include MN-id. I agree it sees an 'id'. Whether that's an user id or a device address is a different story. How would this assignment work with DHCP? > But once the HNP<->MN-id binding is established like above, we no longer > need to keep sending MN-id. HNP becomes the identifier. I'd agree if you meant "HNP+id==full_address" becomes the identifier. Alex > > Alper > >> The benefit of including the MN-ID (NAI) in the PMIP signaling messages >> is that it provides a unique and consistent way to identify the user at >> the LMA and the MAG at all times (i.e. initial attach and >> re-registration). >> >> BR, >> Kuntal >> >> >>> -----Original Message----- >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>> Sent: Wednesday, September 26, 2007 11:58 AM >>> To: 'Ahmad Muhanna'; netlmm@ietf.org >>> Subject: RE: [netlmm] MN-Id overspecification >>> >>> Ahmad, >>> >>>> In case that a HNP is available at the MAG (how: out-of-scope) and >>>> included in the initial P-BU, ... >>> ... MAG is not required to include an NAI option that carries the >>> MN-identifier. >>> >>> In the spec, all we need to say is "MN-Identifier MUST be included in >> PBU >>> when the HNP is set to 0::0/0" >>> >>> >>> Alper >>> >>> >>> >>> NO NAI or any other IDs related to the MN >>>> should be included? >>>> >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>>>> Sent: Wednesday, September 26, 2007 7:35 AM >>>>> To: netlmm@ietf.org >>>>> Subject: [netlmm] MN-Id overspecification >>>>> >>>>> This issue is still hanging. >>>>> >>>>> So far as I understand the MN-Id is only used for performing >>>>> HNP assignment in-band with PMIP6 signaling. In case HNP is >>>>> already assigned, there is no need to be carrying any info >>>>> that directly or indirectly points to the MN's identity. >>>>> >>>>> But on the other hand, MN-id is all over the spec with >>>>> normative languages that suggest it be present in every message. >>>>> >>>>> This is an overspecification, reducing flexibility and >>>>> getting in the ways of various deployment scenarios. >>>>> >>>>> I recommend we change the spec such that MN-id is only >>>>> mandated when HNP needs to be assigned. >>>>> >>>>> Would there be an objection to that? Is there any technical >>>>> reason to carry an identifier of the MN in every PMIP6 message? >>>>> >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> >> "This email message and any attachments are confidential information of >> Starent Networks, Corp. The information transmitted may not be used to >> create or change any contractual obligations of Starent Networks, Corp. >> Any review, retransmission, dissemination or other use of, or taking of >> any action in reliance upon this e-mail and its attachments by persons or >> entities other than the intended recipient is prohibited. If you are not >> the intended recipient, please notify the sender immediately -- by >> replying to this message or by sending an email to >> postmaster@starentnetworks.com -- and destroy all copies of this message >> and any attachments without reading or disclosing their contents. Thank >> you." > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 08:15:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasGv-0006p6-3A; Thu, 27 Sep 2007 08:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasGt-0006cC-Q6 for netlmm@ietf.org; Thu, 27 Sep 2007 08:15:11 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IasGn-00046b-He for netlmm@ietf.org; Thu, 27 Sep 2007 08:15:11 -0400 Received: by ug-out-1314.google.com with SMTP id u2so4313622uge for ; Thu, 27 Sep 2007 05:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=w7QT6fAfeAr4ojg9cFruv+6mVbGNBElKqrw7nHi5Chc=; b=fGEG258cIJCw/SEwvd/V5TVSB9RFbXBHtdMLnhTT7jbG3ry4lOYiVj2Xo8rlqOPha4gJXr0Q7ftuudi0Q+UopUrDC0fTGY/qO8oeUE6la9+hu5KlyLiJbueUDNqQiDFj4XiV24d80rLP/W1/u2nxH1BaWpEA/0TevvDE2ni/VaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=W+sdr5tkN9T43usxY6YJUB2M2/unFGBtN7iS8gAhI+lqZDHh1NJtiUQCk5Ph2pwzkwof2GB8cvRNSavTx9zOpg2/xRGJmsjBrrDuKzSCHp+0dKYhJ3ztiP8aq0JxyEAi4GpUZNo0lq3sy5GoMJYujyh0LozzXNT1cDCntIOwi10= Received: by 10.67.30.3 with SMTP id h3mr3515515ugj.1190895277595; Thu, 27 Sep 2007 05:14:37 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id s7sm5621136uge.2007.09.27.05.14.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Sep 2007 05:14:36 -0700 (PDT) From: Julien Laganier To: netlmm@ietf.org Subject: Default router and new MAG (Was: [netlmm] Suresh's review of draft-ietf-netlmm-proxymip6-05) Date: Thu, 27 Sep 2007 14:14:33 +0200 User-Agent: KMail/1.9.6 References: <46F848E2.40904@ericsson.com> In-Reply-To: <46F848E2.40904@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709271414.33474.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On Tuesday 25 September 2007, Suresh Krishnan wrote: > Link Local address of MAG > ========================= > When an MN moves from one link to another how does it switch default > routers to the new MAG. The link local addresses of the old MAG and > the new MAG will most likely be different and hence unless nud > removes the old mag the mn will try to reach it even after handover. > Or it is assumed that all the MAGs will have the same LL address? Is > this is an assumption, it needs to be stated. FWIW the current DNAv6 spec would not require NUD to kick in and remove the old MAG. The MN would simply select a new router that is in reachable state. From [I-D.ietf-dna-protocol-06]: 5.2.6.3 Router Reachability Detection and Default Router Selection [...] Prior to sending a DNA RS in response to an indication of link change, the host SHOULD set all Neighbor Cache entries for routers on its Default Router List to STALE. When the host receives an RA in reply to the RS, the host SHOULD mark that router's Neighbor Cache Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the REACHABLE state if one does not currently exist. The host SHOULD also update its Default Router List in the following fashion. If any of the routers returning RAs are already on the default router list, the host SHOULD use the information in the RA to update the Default Route List entry with the new information. The host SHOULD add entries to the Default Router List for any routers returning RAs that are not on the list. The host SHOULD confine selection of a router from the Default Router List to those routers whose Neighbor Cache entries are in the REACHABLE state. Note that the Default Router List SHOULD be updated as described here regardless of whether the RA indicates that the host has changed to a new IP link, since changes in router reachability are possible on some link types even if the host remains on the same IP link. --julien _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 08:32:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasX8-00044m-JF; Thu, 27 Sep 2007 08:31:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasX7-00042a-6C for netlmm@ietf.org; Thu, 27 Sep 2007 08:31:57 -0400 Received: from cluster-h.mailcontrol.com ([85.115.42.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IasX3-0006lz-Ia for netlmm@ietf.org; Thu, 27 Sep 2007 08:31:54 -0400 Received: from rly16h.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly16h.srv.mailcontrol.com (MailControl) with ESMTP id l8RCVlMD028065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Sep 2007 13:31:51 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly16h.srv.mailcontrol.com (MailControl) id l8RCUxVI025588 for netlmm@ietf.org; Thu, 27 Sep 2007 13:30:59 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly16h-eth0.srv.mailcontrol.com (envelope-sender Genadi.Velev@eu.panasonic.com) (MIMEDefang) with ESMTP id l8RCUuS9025437; Thu, 27 Sep 2007 13:30:58 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 7c30_da9a6478_6cf4_11dc_9d67_0030482aac25; Thu, 27 Sep 2007 14:26:20 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092714304800-90819 ; Thu, 27 Sep 2007 14:30:48 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.124,BAYES_00: -1.665,TOTAL_SCORE: -1.541 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 27 Sep 2007 14:30:32 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxg References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> To: "Narayanan, Vidya" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> Date: Thu, 27 Sep 2007 14:30:33 +0200 From: "Genadi Velev" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.72.1.126 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, I agree that there is an issue with multihomed MN attached to different MAGs under the same LMA. First we need to differentiate between scenarios where the multiple interfaces are of the same or different access technologies. Scenario 1: if a MN has multiple interfaces of the same technology (e.g. multiple WLAN cards), most probably the interfaces would attempt to connect to the same access point which means to the *same MAG*. Scenario 2: if the interfaces are of different access technologies and the MAGs are serving a specific access technology, then the interfaces are attached to *different MAGs*. I'm not exactly sure what are the impacts in scenario 1, or if this scenario can be avoided in managed networks (e.g. the network operator may not authorize the attachment of the second interface). Any thoughts on scenario 1? The following rows are considering merely scenario 2.=20 > It seems to me that this is an unavoidable problem if the=20 > same MN-ID is > sent for multiple interfaces of the MN to the LMA. It seems like an > interface-specific ID (link layer address or equivalent) needs to be > included in the PBU, so that the LMA can ensure that the same > prefix/address is not assigned to multiple IP interfaces of=20 > an MN. This > may not be too difficult, given that the MN-MAG link is=20 > point-to-point. If we look at the available options in PBU/PBA, we can see that next to "NAI Option" (or "MN-ID option") we have a "Link-local Address Option". Supposed that the link-local addresses of the multiple interfaces are different, an LMA can differentiate among PBUs having the same MN-ID option looking at the Link-local Address Option. IMHO, what we need to specify in the PMIPv6 protocol is a behaviour in the LMA that the HNP is not solely bound to a MN-ID but also to the link-local address. In this way different HNPs would be assigned to PBUs (coming from different MAGs) containing same MN-ID option but different link-local address options. thanks, Genadi > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Thursday, September 27, 2007 7:59 AM > To: Sri Gundavelli > Cc: ext Kilian Weniger; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 >=20 > All, > Here is a description of the issue (I'm picking a simple scenario to > describe the issue; there are other scenarios as well; also, this has > been described on the list earlier):=20 >=20 > * MN has two interfaces attached to MAG1 and MAG2 under the same LMA > * Let's say MAG1 first created the binding at the LMA and acquired a > prefix/address for the MN, using MN-ID1 > * MN obtains the prefix/address on Interface1 > * MAG2 now sends a PBU with MN-ID1 also (very possible when the ID is > something like an NAI) > * LMA thinks the MN moved, updates the binding and returns the same > prefix for the MN to MAG2 > * MN ends up with the same prefix/address on Interface2 >=20 > At this point, if it is an IPv6 prefix, the MN may configure=20 > a different > address on Interface 2, but, we would have lost the point-to-point > nature and the associated properties of the MN-MAG link; if it is an > IPv6 or IPv4 address, the MN detects a duplicate address and=20 > shuts down > the interface from an IP point of view. The MN thinks only Interface1 > is active, while the LMA has a binding to MAG2 (corresponding to > Interface2 of the MN). =20 >=20 > Result: MN does not have any IP access via either of its interfaces. > Even if the MN has different addresses on the same prefix on its two > interfaces, Interface 1 cannot be used given LMA's state,=20 > but, the MN is > unaware of that.=20 >=20 > Some thoughts on avoiding this problem:=20 >=20 > It seems to me that this is an unavoidable problem if the=20 > same MN-ID is > sent for multiple interfaces of the MN to the LMA. It seems like an > interface-specific ID (link layer address or equivalent) needs to be > included in the PBU, so that the LMA can ensure that the same > prefix/address is not assigned to multiple IP interfaces of=20 > an MN. This > may not be too difficult, given that the MN-MAG link is=20 > point-to-point. >=20 >=20 > Thoughts?=20 >=20 > Thanks, > Vidya >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 09:04:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat2Q-0000r4-3l; Thu, 27 Sep 2007 09:04:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat2P-0000lz-BF for netlmm@ietf.org; Thu, 27 Sep 2007 09:04:17 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iat2K-0005OO-3F for netlmm@ietf.org; Thu, 27 Sep 2007 09:04:17 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8RD3wW01868; Thu, 27 Sep 2007 13:03:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 08:03:01 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116FF8507@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAagAEPu0GVwz4RQOWMN9aVbVHtwADyCQwAAI5f+AAB5L6MAAZdnwA References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> <46FAA143.6070407@azairenet.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF804F@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Vijay Devarapalli" , "Alper Yegin" X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, I also acknowledged earlier that it can. However, that adds complexity to the MAG and the LMA. If we need the MN-ID for the initial P-BU what prevents us from including it in the re-registration P-BU. As I said earlier in my other reply to your question, unless there is a serious advantage for not including the MN-ID in the re-registration P-BU, we SHOULD keep the MN-ID in all P-BU. Otherwise, it complicates Interoperability between MAGs and LMAs etc. Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Wednesday, September 26, 2007 7:51 PM > To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Alper Yegin > Cc: netlmm@ietf.org > Subject: RE: [netlmm] MN-Id overspecification >=20 > Hi Ahmad, > In the case of matching, I did acknowledge that it may be=20 > needed when the HNP is set to 0. For any other value of the=20 > HNP, the HNP can sufficiently match the messages, can it not?=20 >=20 > Regards, > Vidya=20 >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Wednesday, September 26, 2007 2:43 PM > > To: Narayanan, Vidya; Vijay Devarapalli; Alper Yegin > > Cc: netlmm@ietf.org > > Subject: RE: [netlmm] MN-Id overspecification > >=20 > > Hi Vidya, > >=20 > > Please see comments inline. > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > Subject: RE: [netlmm] MN-Id overspecification > > >=20 > > >=20 > > > Based on a number of these discussions, the role of the > > MN-ID is now > > > confusing to me. I've so far heard the following uses for MN-ID: > > >=20 > > > 1. To assign a HNP (this I understand) > > >=20 > > > 2. To match PBAs with PBUs (I don't get this) > > >=20 > > > 3. To authorize the HNP to be mapped to that MN-ID (I don't > > quite get > > > this either) > > >=20 > > > 1 is clear to me and I see why an MN-ID needs to be=20 > included in the=20 > > > PBUs that set the HNP to 0. > >=20 > > > 2 doesn't make sense to me, > > =20 > > [Ahmad-START-1] > > I am not sure what do you mean here. Earlier you agreed that it is=20 > > needed but now I am confused. Let me give more details here: > >=20 > > 1. PMIPv6 base protocol supports both timestamp and SQN, NO? > > 2. Also, as we all know, SQN needs to be tracked on a per-MN basis. > > 3. SQN field is restricted to 2 bytes i.e. =3D~ 64k.=20 > > 4. In this case, there is a very high probability that=20 > there will be=20 > > collisions of the SQN of the outstanding P-BU(s). > > 5. This means that MN1 and MN101 have the same SQN=3Dxyz inserted in = > > their respected P-BU messages. > > 6. When MAG receives the P-BA for MN101, according to RFC3775, MAG=20 > > needs to find the matching P-BU based on SQN xyz. > >=20 > > 7. okay, there are two P-BU(s) that are outstanding waiting=20 > for reply. > > Right? > > 7.1. How the MAG needs to know which MN the P-BA belongs to? > > 7.2. MAG needs to use NAI to differentiate. Right? > >=20 > > Why then this does not make sense? > >=20 > > [Ahmad-END-1] > >=20 > > > match responses to requests. > > > Also, on the matching aspect, I > > > think the document needs clarity, since it sometimes states that=20 > > > sequence numbers are used, sometimes that timestamps are > > used and some > > > other times that MN-ID is used. > >=20 > > [Ahmad-START-2] > > The same concept actually applies to timestamp too. However, in the=20 > > case of time stamp, the possibility of collision is way=20 > much less. In=20 > > other words, it is needed either way. > >=20 > > May be what you are saying is the draft needs to use more=20 > details to=20 > > explain this, but I guess when it comes to SQN, the original text=20 > > already in RFC3775. > >=20 > > [Ahmad-END-2] > >=20 > > > It even > > > mandates copying of the sequence number from the PBU to=20 > the PBA for=20 > > > this purpose. We need to get this cleaned up. > >=20 > > [Ahmad-START-3] > >=20 > > What do you expect LMA should return a SQN of ZERO. On the=20 > other hand,=20 > > there is no indication of what the MAG is using the SQN=20 > for. Returning=20 > > the SQN is the proper approach. > >=20 > > [Ahmad-END-3] > > >=20 > > > On 3, it is not clear what we are achieving. This is=20 > different from=20 > > > the > > > MIP6 case, since in MIP6, the ID is tied to HoA which is > > tied to the > > > SA and hence, if the HoA came in with the right SA, everything is=20 > > > good. > > > Here, there isn't an SA tied to anything that belongs to > > the MN. So, > > > simply carrying the MN-ID in the PBU doesn't provide any > > assurance of > > > that ID being tied to that HNP, other than simply=20 > trusting the MAG. > > > So, not carrying the MN-ID is not > > > taking away any existing guarantee - when the LMA receives > > a PBU for a > > > given HNP, it needs to update that binding. > > > If the LMA is doing something additional to verify the=20 > existence of=20 > > > the MN at that MAG, it has the HNP to MN-ID mapping anyway > > to do that. > > >=20 > > > So, why do we need the MN-ID for anything other than 1?=20 > > >=20 > > > Thanks, > > > Vidya > > >=20 > > > > -----Original Message----- > > > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > > > Sent: Wednesday, September 26, 2007 11:13 AM > > > > To: Alper Yegin > > > > Cc: netlmm@ietf.org > > > > Subject: Re: [netlmm] MN-Id overspecification > > > >=20 > > > > Alper Yegin wrote: > > > > > Ahmad, > > > > >=20 > > > > >> In case that a HNP is available at the MAG (how:=20 > > > out-of-scope) and > > > > >> included in the initial P-BU, ... > > > > >=20 > > > > > ... MAG is not required to include an NAI option that > > carries the > > > > > MN-identifier. > > > > >=20 > > > > > In the spec, all we need to say is "MN-Identifier MUST be > > > > included in > > > > > PBU when the HNP is set to 0::0/0" > > > >=20 > > > > Of course not. If the MAG is going to be presenting the > > > home network > > > > prefix in the proxy binding update to the LMA, then the LMA > > > needs to > > > > check if the mobile node is authorized for the home > > network prefix.=20 > > > > For this check to happen, the MN-ID must be there in the > > > proxy binding > > > > update even if the home network prefix is set to something > > > other than > > > > 0::0. > > > >=20 > > > > In Mobile IPv6, the HA performs this check by getting the > > > identifier > > > > from the IKEv1/IKEv2 exchange. Since we don't have a=20 > IKEv1/IKEv2=20 > > > > exchange between the MN and the LMA, the proxy BU from > > the MAG must > > > > have the MN-ID. > > > >=20 > > > > Vijay > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 10:03:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatxQ-00010e-JI; Thu, 27 Sep 2007 10:03:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatxP-0000zm-96 for netlmm@ietf.org; Thu, 27 Sep 2007 10:03:11 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IatxO-0001XA-Ul for netlmm@ietf.org; Thu, 27 Sep 2007 10:03:11 -0400 X-IronPort-AV: E=Sophos;i="4.21,204,1188802800"; d="scan'208";a="226225958" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2007 07:03:10 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8RE3AgR026034; Thu, 27 Sep 2007 07:03:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8RE3ADL027187; Thu, 27 Sep 2007 14:03:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:03:09 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:03:09 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de> <002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 07:03:09 -0700 Message-ID: <008901c8010f$2266aa70$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAT3K0w X-OriginalArrivalTime: 27 Sep 2007 14:03:09.0540 (UTC) FILETIME=[2285F240:01C8010F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1015; t=1190901790; x=1191765790; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=2sLr14PAe3gPQPtMYyzMhY4zRbkL0vP7ugxTy39mJHs=; b=JiLIT6sDCtmcKb97QyZPD6YoRGbFHgEm1DjDxHwdE66UAQ6mcmYFoI9nOJ7mYFJClVBDOI6U Vp6DvzC2S6O/6tPCm7sGqar0IsOR86UuCfTQBq27r7COoS565+vE+mABmgw/Ab2Iqwb+Pb/nk2 cMWMFRWGbz5j1NhesX573d7zU=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'ext Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Some thoughts on avoiding this problem: > > It seems to me that this is an unavoidable problem if the > same MN-ID is > sent for multiple interfaces of the MN to the LMA. It seems like an > interface-specific ID (link layer address or equivalent) needs to be > included in the PBU, so that the LMA can ensure that the same > prefix/address is not assigned to multiple IP interfaces of > an MN. This > may not be too difficult, given that the MN-MAG link is > point-to-point. > This adds a limitation. A mobile node in a single access mode that does a handoff between intefaces (access-1 to access-2), would loose seamless roaming. It will loose the prefix. There is no easy solution to this problem. It is impossible to handle this scenario. Either, it requires some hooks on the MN side or some complex handshake between LMA's and MAG's for MN presence detection and also requires the L-2 technology on the MN-AR link to provide some hooks for the MAG to page the node. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 10:07:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iau1u-00058i-8S; Thu, 27 Sep 2007 10:07:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iau1t-00058O-5e for netlmm@ietf.org; Thu, 27 Sep 2007 10:07:49 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iau1s-0001mJ-RD for netlmm@ietf.org; Thu, 27 Sep 2007 10:07:49 -0400 X-IronPort-AV: E=Sophos;i="4.21,204,1188802800"; d="scan'208";a="528792001" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 27 Sep 2007 07:07:47 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8RE7mFP002936; Thu, 27 Sep 2007 07:07:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8RE7mTm024555; Thu, 27 Sep 2007 14:07:48 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:07:47 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:07:47 -0700 From: "Sri Gundavelli" To: "'Genadi Velev'" , "'Narayanan, Vidya'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 07:07:47 -0700 Message-ID: <008a01c8010f$c8234130$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/A= X-OriginalArrivalTime: 27 Sep 2007 14:07:47.0656 (UTC) FILETIME=[C84B1480:01C8010F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=955; t=1190902068; x=1191766068; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=5JqQ91x5N0NAWAK6EAurMcLH2OfDeYljOUre7IAA9vY=; b=KwvMpmDDf5se2BtAkNvmIZpBNSD4YfacqgGxlgDcrUqNr1w5r5JTjiM4vyh1NNfTXWVdzdXc E/hMzcUKHM/0po3AcVWOPvLHPn9tWpcTNEoz6XP4qA6XOdKHEyj2+I1S1Q69lOToP7uOWwQV20 Y/O6GNAfrTbmQEc5uZqIPTNe4=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'ext Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Genadi, > > If we look at the available options in PBU/PBA, we can see > that next to > "NAI Option" (or "MN-ID option") we have a "Link-local > Address Option". > Supposed that the link-local addresses of the multiple interfaces are > different, an LMA can differentiate among PBUs having the same MN-ID > option looking at the Link-local Address Option. IMHO, what we need to > specify in the PMIPv6 protocol is a behaviour in the LMA that > the HNP is > not solely bound to a MN-ID but also to the link-local > address. In this > way different HNPs would be assigned to PBUs (coming from different > MAGs) containing same MN-ID option but different link-local address > options. But, we need to allow handoff between two different interfaces (of different access technologies), if we keep a relation to the LLA, we cant do handoff. This scenario is more important than the scenario of simultaneous multi-access. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 10:18:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauBI-0003iw-Dw; Thu, 27 Sep 2007 10:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauBH-0003io-3B for netlmm@ietf.org; Thu, 27 Sep 2007 10:17:31 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IauBA-0007i3-Po for netlmm@ietf.org; Thu, 27 Sep 2007 10:17:31 -0400 X-IronPort-AV: E=Sophos;i="4.21,204,1188802800"; d="scan'208";a="20351323" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 27 Sep 2007 07:17:19 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8REHJ7L028027; Thu, 27 Sep 2007 07:17:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8REHE1l001638; Thu, 27 Sep 2007 14:17:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:17:14 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:17:14 -0700 From: "Sri Gundavelli" To: "'Alper Yegin'" , "'Basavaraj Patil'" , "'Ahmad Muhanna'" , References: <0MKpCa-1IanvV202U-0007VA@mrelay.perfora.net> Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 07:17:13 -0700 Message-ID: <008b01c80111$19d59a40$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0MKpCa-1IanvV202U-0007VA@mrelay.perfora.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AABDcQjgAd8sdwAA3t6VA= X-OriginalArrivalTime: 27 Sep 2007 14:17:14.0319 (UTC) FILETIME=[1A0CFDF0:01C80111] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4127; t=1190902639; x=1191766639; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20MN-Id=20overspecification |Sender:=20; bh=7pZXXWI9OOC+inxukPSvWiOFPjLkG/t7lNFmD+vGbNI=; b=Lg7mr/odE8i9qYLIlaYIAhYnAd3hWQpy7tGrGUxx5Sr+79kyxGtHW/2O9za1ELb+I2Q911e6 32qRhi+GGZvF2EUMiY2fM8tiXHm5qAaVo4F1jfAXJ9T/py/jj4V4L6Gi; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, Assuming we relax the MUST requirement on the presence of MN-Id and when the MAG is aware of the MN-HNP, but, how do you plan to carry the Auth Option in PBU's. The spec defines HNP, TS, NAI, Link-local address options to be carried in PBU and PBA's. Any other options, such as MNP option from 3963 or Auth Option from 4285 are not defined for these messages. Sri > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Thursday, September 27, 2007 12:37 AM > To: 'Basavaraj Patil'; 'Ahmad Muhanna'; netlmm@ietf.org > Subject: RE: [netlmm] MN-Id overspecification > > Raj, > > > What is the downside of including the MN-ID in all the > MAG/LMA messages? > > Does it break anything? > > As I had explained earlier, one way to deploy PMIP is to use > RFC 4285 with > per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In > that case, HNP > can be assigned during network access authentication (so, we > no longer need > to convey the id of the "MN" in-band with PMIP), but we need > to convey the > id of the "proxy-MN (MAG)" for PMIP security. > > That scenario breaks when we unnecessarily force the protocol > to always > carry "MN"-id. > > Even without this I could be arguing against this > overspecification based on > lack of need and uncertainty around what to put in MN-id. > > Alper > > > > > You say that it "is an overspecification, reducing flexibility and > > getting in the ways of various deployment scenarios"... > > > > How is it becoming an obstacle in any deployment scenario? > > > > I am just wondering if you are optimizing the protocol by > not including > > the > > MN-ID or if you see this as actually being a problem. > > > > -Raj > > > > > > On 9/26/07 11:58 AM, "ext Alper Yegin" > wrote: > > > > > Ahmad, > > > > > >> In case that a HNP is available at the MAG (how: > out-of-scope) and > > >> included in the initial P-BU, ... > > > > > > ... MAG is not required to include an NAI option that carries the > > > MN-identifier. > > > > > > In the spec, all we need to say is "MN-Identifier MUST be > included in > > PBU > > > when the HNP is set to 0::0/0" > > > > > > > > > Alper > > > > > > > > > > > > NO NAI or any other IDs related to the MN > > >> should be included? > > >> > > >> > > >> Regards, > > >> Ahmad > > >> > > >> > > >>> -----Original Message----- > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > >>> Sent: Wednesday, September 26, 2007 7:35 AM > > >>> To: netlmm@ietf.org > > >>> Subject: [netlmm] MN-Id overspecification > > >>> > > >>> This issue is still hanging. > > >>> > > >>> So far as I understand the MN-Id is only used for performing > > >>> HNP assignment in-band with PMIP6 signaling. In case HNP is > > >>> already assigned, there is no need to be carrying any info > > >>> that directly or indirectly points to the MN's identity. > > >>> > > >>> But on the other hand, MN-id is all over the spec with > > >>> normative languages that suggest it be present in every message. > > >>> > > >>> This is an overspecification, reducing flexibility and > > >>> getting in the ways of various deployment scenarios. > > >>> > > >>> I recommend we change the spec such that MN-id is only > > >>> mandated when HNP needs to be assigned. > > >>> > > >>> Would there be an objection to that? Is there any technical > > >>> reason to carry an identifier of the MN in every PMIP6 message? > > >>> > > >>> > > >>> Alper > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> netlmm mailing list > > >>> netlmm@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > >>> > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 10:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauDX-0002ym-Rr; Thu, 27 Sep 2007 10:19:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauDW-0002yd-Gt for netlmm@ietf.org; Thu, 27 Sep 2007 10:19:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IauDV-0007la-9s for netlmm@ietf.org; Thu, 27 Sep 2007 10:19:50 -0400 X-IronPort-AV: E=Sophos;i="4.21,204,1188802800"; d="scan'208";a="528798582" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Sep 2007 07:19:38 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8REJcCI000428; Thu, 27 Sep 2007 07:19:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8REJX1l004578; Thu, 27 Sep 2007 14:19:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:19:33 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:19:33 -0700 From: "Sri Gundavelli" To: "'Julien Laganier'" , References: <46F848E2.40904@ericsson.com> <200709271414.33474.julien.IETF@laposte.net> Subject: RE: Default router and new MAG (Was: [netlmm] Suresh's review ofdraft-ietf-netlmm-proxymip6-05) Date: Thu, 27 Sep 2007 07:19:32 -0700 Message-ID: <008c01c80111$6c9d7770$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200709271414.33474.julien.IETF@laposte.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgBALsO/n3LKzJ9QkSVVvF8NxCxRwAEHRhQ X-OriginalArrivalTime: 27 Sep 2007 14:19:33.0165 (UTC) FILETIME=[6CCF35D0:01C80111] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1156; t=1190902778; x=1191766778; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20Default=20router=20and=20new=20MAG=20(Was=3A=20[netlm m]=20Suresh's=20review=20ofdraft-ietf-netlmm-proxymip6-05) |Sender:=20; bh=YQ8fCFoPXQgDy35EG1X+oRz/5BBAu/29RTsdpsKr/Fo=; b=R7p3piu8egr4HLW0bxfmCcJhG+1i3kmIj2WXMvF4oVd0NRgsPbN1rEjKubM09c2M+xw1enVj gEfHtFLXMIgfryFaqskAJ4Fbp+w0e6NASM0NgIYH+TQ/fdqMHr5PbvXv; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Julien, > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net] > Sent: Thursday, September 27, 2007 5:15 AM > To: netlmm@ietf.org > Subject: Default router and new MAG (Was: [netlmm] Suresh's > review ofdraft-ietf-netlmm-proxymip6-05) > > On Tuesday 25 September 2007, Suresh Krishnan wrote: > > Link Local address of MAG > > ========================= > > When an MN moves from one link to another how does it switch default > > routers to the new MAG. The link local addresses of the old MAG and > > the new MAG will most likely be different and hence unless nud > > removes the old mag the mn will try to reach it even after handover. > > Or it is assumed that all the MAGs will have the same LL address? Is > > this is an assumption, it needs to be stated. > > FWIW the current DNAv6 spec would not require NUD to kick in > and remove > the old MAG. The MN would simply select a new router that is in > reachable state. From [I-D.ietf-dna-protocol-06]: > Thanks. This is very important. I can add a reference to this. Probably, a good reason to enable to DNAv6 on the MN. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 10:22:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauFm-00013o-Ts; Thu, 27 Sep 2007 10:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauFg-0000zi-Ld for netlmm@ietf.org; Thu, 27 Sep 2007 10:22:04 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IauFa-0007q3-Eu for netlmm@ietf.org; Thu, 27 Sep 2007 10:22:04 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:21:57 -0700 Message-ID: <46FBBC80.8060602@azairenet.com> Date: Thu, 27 Sep 2007 07:21:52 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKp8S-1Iap6Z10aj-0008JP@mrelay.perfora.net> In-Reply-To: <0MKp8S-1Iap6Z10aj-0008JP@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 14:21:57.0735 (UTC) FILETIME=[C2FAD770:01C80111] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, Alper Yegin wrote: >>> Ahmad, >>> >>>> In case that a HNP is available at the MAG (how: out-of-scope) and >>>> included in the initial P-BU, ... >>> ... MAG is not required to include an NAI option that carries the >>> MN-identifier. >>> >>> In the spec, all we need to say is "MN-Identifier MUST be included in >> PBU >>> when the HNP is set to 0::0/0" >> Of course not. If the MAG is going to be presenting the home network >> prefix in the proxy binding update to the LMA, then the LMA needs to >> check if the mobile node is authorized for the home network prefix. For >> this check to happen, the MN-ID must be there in the proxy binding >> update even if the home network prefix is set to something other than >> 0::0. > > What really needs to be authorized is the "MAG" for sucking in all the > traffic destined for a HNP. Checking if the MN-id and HNP matches is > meaningless next to this one. In order to do the former, the system > internally needs to perform the latter. We require both. > Let me be more specific, but note that these are outside scope of PMIP6 > spec. > > During network access authentication, the home network associates MN and > MAG. Assigning the home network prefix during access authentication would involve something like the AAA server managing the home network prefixes pool. I don't see any advantages with that. Do you keep updating the AAA database everytime something changes on the LMA? > Since we care about protecting the HNP, home network already knows the > MN and HNP association. So, when the MAG sends the PBU, home network can > check if the requested HNP matches those of MNs that are associated with the > MAG. See that does not involve carrying the MN-id (when HNP is present in > the PBU). Lets assume its the AAA server that did the assignment. The LMA would need to check with the AAA server if the MAG is using the right home network prefix for a particular mobile node. What if the MAG mixed up the prefixes for two mobile nodes attached to it both authenticated by the same AAA server? This would require the LMA knowing the MN-ID and the home network prefix when the proxy BU is received at the LMA. So you have to include the MN-ID in the proxy BU. Alper, frankly I think you need to show why including the MN-ID in the proxy BU is a bad idea. If there is no issue, lets move on. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 10:27:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauLD-0005rL-J7; Thu, 27 Sep 2007 10:27:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IauLB-0005qm-7O for netlmm@ietf.org; Thu, 27 Sep 2007 10:27:45 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IauLA-0002bn-L2 for netlmm@ietf.org; Thu, 27 Sep 2007 10:27:45 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 07:27:43 -0700 Message-ID: <46FBBDDA.1050606@azairenet.com> Date: Thu, 27 Sep 2007 07:27:38 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKpCa-1Iao910RhY-0007Ua@mrelay.perfora.net> In-Reply-To: <0MKpCa-1Iao910RhY-0007Ua@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 14:27:43.0963 (UTC) FILETIME=[91590AB0:01C80112] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I don't understand. RFC 4285 requires MN-ID in the binding update. For what you want to do you would need to include the MAG-ID in addition to the MN-ID in the proxy binding update. Vijay Alper Yegin wrote: > Kuntal, > >> Even if the HNP is included in the PBU, the user identity cannot be >> deterministically derived from that info. The HNP may be dynamically >> assigned to the users in many systems. > > Whoever assigned the HNP has a chance to see the user id. Either it is > assigned during the network access authentication, in which case the user id > is best known; or it is assigned during the initial PBU in which case I say > we shall include MN-id. > > But once the HNP<->MN-id binding is established like above, we no longer > need to keep sending MN-id. HNP becomes the identifier. > > Alper > >> The benefit of including the MN-ID (NAI) in the PMIP signaling messages >> is that it provides a unique and consistent way to identify the user at >> the LMA and the MAG at all times (i.e. initial attach and >> re-registration). >> >> BR, >> Kuntal >> >> >>> -----Original Message----- >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>> Sent: Wednesday, September 26, 2007 11:58 AM >>> To: 'Ahmad Muhanna'; netlmm@ietf.org >>> Subject: RE: [netlmm] MN-Id overspecification >>> >>> Ahmad, >>> >>>> In case that a HNP is available at the MAG (how: out-of-scope) and >>>> included in the initial P-BU, ... >>> ... MAG is not required to include an NAI option that carries the >>> MN-identifier. >>> >>> In the spec, all we need to say is "MN-Identifier MUST be included in >> PBU >>> when the HNP is set to 0::0/0" >>> >>> >>> Alper >>> >>> >>> >>> NO NAI or any other IDs related to the MN >>>> should be included? >>>> >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>>>> Sent: Wednesday, September 26, 2007 7:35 AM >>>>> To: netlmm@ietf.org >>>>> Subject: [netlmm] MN-Id overspecification >>>>> >>>>> This issue is still hanging. >>>>> >>>>> So far as I understand the MN-Id is only used for performing >>>>> HNP assignment in-band with PMIP6 signaling. In case HNP is >>>>> already assigned, there is no need to be carrying any info >>>>> that directly or indirectly points to the MN's identity. >>>>> >>>>> But on the other hand, MN-id is all over the spec with >>>>> normative languages that suggest it be present in every message. >>>>> >>>>> This is an overspecification, reducing flexibility and >>>>> getting in the ways of various deployment scenarios. >>>>> >>>>> I recommend we change the spec such that MN-id is only >>>>> mandated when HNP needs to be assigned. >>>>> >>>>> Would there be an objection to that? Is there any technical >>>>> reason to carry an identifier of the MN in every PMIP6 message? >>>>> >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> >> "This email message and any attachments are confidential information of >> Starent Networks, Corp. The information transmitted may not be used to >> create or change any contractual obligations of Starent Networks, Corp. >> Any review, retransmission, dissemination or other use of, or taking of >> any action in reliance upon this e-mail and its attachments by persons or >> entities other than the intended recipient is prohibited. If you are not >> the intended recipient, please notify the sender immediately -- by >> replying to this message or by sending an email to >> postmaster@starentnetworks.com -- and destroy all copies of this message >> and any attachments without reading or disclosing their contents. Thank >> you." > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 11:11:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iav0e-0006f8-0q; Thu, 27 Sep 2007 11:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iav0c-0006bD-Gg for netlmm@ietf.org; Thu, 27 Sep 2007 11:10:34 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iav0U-0001Cz-E1 for netlmm@ietf.org; Thu, 27 Sep 2007 11:10:34 -0400 Received: from [88.233.215.25] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Iav06231l-0007Kg; Thu, 27 Sep 2007 11:10:11 -0400 From: "Alper Yegin" To: "'Sri Gundavelli'" , "'Basavaraj Patil'" , "'Ahmad Muhanna'" , Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 18:09:53 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AABDcQjgAd8sdwAA3t6VAAAfyv8A== In-Reply-To: <008b01c80111$19d59a40$1220fea9@amer.cisco.com> Message-Id: <0MKpCa-1Iav06231l-0007Kg@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/aJLCLcVRXYekfTs7JtSuZf0se1+WYkxjSyZq hfHmj9WY4Ct3RRnWVHMmi99wTbR0xh35hsNw70S7LBLzD65q1z BAmQCi9iphS0n/8S7dcfg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, > and PBA's. Any other options, such as MNP option from 3963 > or Auth Option from 4285 are not defined for these messages. Unless the PMIP6 spec explicitly disallows use of Auth Option, I don't think it needs to explicitly support it (assuming we straighten the wrinkle we are discussing). Alper > > Sri > > > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Thursday, September 27, 2007 12:37 AM > > To: 'Basavaraj Patil'; 'Ahmad Muhanna'; netlmm@ietf.org > > Subject: RE: [netlmm] MN-Id overspecification > > > > Raj, > > > > > What is the downside of including the MN-ID in all the > > MAG/LMA messages? > > > Does it break anything? > > > > As I had explained earlier, one way to deploy PMIP is to use > > RFC 4285 with > > per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In > > that case, HNP > > can be assigned during network access authentication (so, we > > no longer need > > to convey the id of the "MN" in-band with PMIP), but we need > > to convey the > > id of the "proxy-MN (MAG)" for PMIP security. > > > > That scenario breaks when we unnecessarily force the protocol > > to always > > carry "MN"-id. > > > > Even without this I could be arguing against this > > overspecification based on > > lack of need and uncertainty around what to put in MN-id. > > > > Alper > > > > > > > > > You say that it "is an overspecification, reducing flexibility and > > > getting in the ways of various deployment scenarios"... > > > > > > How is it becoming an obstacle in any deployment scenario? > > > > > > I am just wondering if you are optimizing the protocol by > > not including > > > the > > > MN-ID or if you see this as actually being a problem. > > > > > > -Raj > > > > > > > > > On 9/26/07 11:58 AM, "ext Alper Yegin" > > wrote: > > > > > > > Ahmad, > > > > > > > >> In case that a HNP is available at the MAG (how: > > out-of-scope) and > > > >> included in the initial P-BU, ... > > > > > > > > ... MAG is not required to include an NAI option that carries the > > > > MN-identifier. > > > > > > > > In the spec, all we need to say is "MN-Identifier MUST be > > included in > > > PBU > > > > when the HNP is set to 0::0/0" > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > NO NAI or any other IDs related to the MN > > > >> should be included? > > > >> > > > >> > > > >> Regards, > > > >> Ahmad > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > > >>> Sent: Wednesday, September 26, 2007 7:35 AM > > > >>> To: netlmm@ietf.org > > > >>> Subject: [netlmm] MN-Id overspecification > > > >>> > > > >>> This issue is still hanging. > > > >>> > > > >>> So far as I understand the MN-Id is only used for performing > > > >>> HNP assignment in-band with PMIP6 signaling. In case HNP is > > > >>> already assigned, there is no need to be carrying any info > > > >>> that directly or indirectly points to the MN's identity. > > > >>> > > > >>> But on the other hand, MN-id is all over the spec with > > > >>> normative languages that suggest it be present in every message. > > > >>> > > > >>> This is an overspecification, reducing flexibility and > > > >>> getting in the ways of various deployment scenarios. > > > >>> > > > >>> I recommend we change the spec such that MN-id is only > > > >>> mandated when HNP needs to be assigned. > > > >>> > > > >>> Would there be an objection to that? Is there any technical > > > >>> reason to carry an identifier of the MN in every PMIP6 message? > > > >>> > > > >>> > > > >>> Alper > > > >>> > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> netlmm mailing list > > > >>> netlmm@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > >>> > > > > > > > > > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 11:12:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iav2m-0002su-J5; Thu, 27 Sep 2007 11:12:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iav2l-0002pb-8X for netlmm@ietf.org; Thu, 27 Sep 2007 11:12:47 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iav2k-0004RX-JB for netlmm@ietf.org; Thu, 27 Sep 2007 11:12:47 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8RFCeH13166; Thu, 27 Sep 2007 15:12:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 10:12:39 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116FF8969@zrc2hxm2.corp.nortel.com> In-Reply-To: <46FBBDDA.1050606@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgBEuI91L7JwXTRRCexEK9S+8si4gABO24g References: <0MKpCa-1Iao910RhY-0007Ua@mrelay.perfora.net> <46FBBDDA.1050606@azairenet.com> From: "Muhanna, Ahmad (RICH1:2H10)" To: "Vijay Devarapalli" , "Alper Yegin" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Subject: Re: [netlmm] MN-Id overspecification >=20 > I don't understand. RFC 4285 requires MN-ID in the binding=20 > update. For what you want to do you would need to include the=20 > MAG-ID in addition to the MN-ID in the proxy binding update. [Ahmad] Actually I have the same question. I believe in another tearlier thread, Alper wants to use the MN-ID option to carry the Proxy MN-ID, which he said it should be the MAG-ID. My understanding that MN-ID option has a subtype field to identify different ID's. I hope that helps here. Unless there is a use case that I am not aware of. Is the issue here related to: if including more than one ID options in the P-BU is allowed? >=20 > Vijay >=20 > Alper Yegin wrote: > > Kuntal, > >=20 > >> Even if the HNP is included in the PBU, the user identity=20 > cannot be=20 > >> deterministically derived from that info. The HNP may be=20 > dynamically=20 > >> assigned to the users in many systems. > >=20 > > Whoever assigned the HNP has a chance to see the user id.=20 > Either it is=20 > > assigned during the network access authentication, in which=20 > case the=20 > > user id is best known; or it is assigned during the initial PBU in=20 > > which case I say we shall include MN-id. > >=20 > > But once the HNP<->MN-id binding is established like above, we no=20 > > longer need to keep sending MN-id. HNP becomes the identifier. > >=20 > > Alper > >=20 > >> The benefit of including the MN-ID (NAI) in the PMIP signaling=20 > >> messages is that it provides a unique and consistent way=20 > to identify=20 > >> the user at the LMA and the MAG at all times (i.e. initial=20 > attach and=20 > >> re-registration). > >> > >> BR, > >> Kuntal > >> > >> > >>> -----Original Message----- > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>> Sent: Wednesday, September 26, 2007 11:58 AM > >>> To: 'Ahmad Muhanna'; netlmm@ietf.org > >>> Subject: RE: [netlmm] MN-Id overspecification > >>> > >>> Ahmad, > >>> > >>>> In case that a HNP is available at the MAG (how:=20 > out-of-scope) and=20 > >>>> included in the initial P-BU, ... > >>> ... MAG is not required to include an NAI option that carries the=20 > >>> MN-identifier. > >>> > >>> In the spec, all we need to say is "MN-Identifier MUST be=20 > included=20 > >>> in > >> PBU > >>> when the HNP is set to 0::0/0" > >>> > >>> > >>> Alper > >>> > >>> > >>> > >>> NO NAI or any other IDs related to the MN > >>>> should be included? > >>>> > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>>>> Sent: Wednesday, September 26, 2007 7:35 AM > >>>>> To: netlmm@ietf.org > >>>>> Subject: [netlmm] MN-Id overspecification > >>>>> > >>>>> This issue is still hanging. > >>>>> > >>>>> So far as I understand the MN-Id is only used for=20 > performing HNP=20 > >>>>> assignment in-band with PMIP6 signaling. In case HNP is already=20 > >>>>> assigned, there is no need to be carrying any info that=20 > directly=20 > >>>>> or indirectly points to the MN's identity. > >>>>> > >>>>> But on the other hand, MN-id is all over the spec with=20 > normative=20 > >>>>> languages that suggest it be present in every message. > >>>>> > >>>>> This is an overspecification, reducing flexibility and=20 > getting in=20 > >>>>> the ways of various deployment scenarios. > >>>>> > >>>>> I recommend we change the spec such that MN-id is only mandated=20 > >>>>> when HNP needs to be assigned. > >>>>> > >>>>> Would there be an objection to that? Is there any=20 > technical reason=20 > >>>>> to carry an identifier of the MN in every PMIP6 message? > >>>>> > >>>>> > >>>>> Alper > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >> > >> "This email message and any attachments are confidential=20 > information=20 > >> of Starent Networks, Corp. The information transmitted may not be=20 > >> used to create or change any contractual obligations of=20 > Starent Networks, Corp. > >> Any review, retransmission, dissemination or other use of,=20 > or taking=20 > >> of any action in reliance upon this e-mail and its attachments by=20 > >> persons or entities other than the intended recipient is=20 > prohibited.=20 > >> If you are not the intended recipient, please notify the sender=20 > >> immediately -- by replying to this message or by sending=20 > an email to=20 > >> postmaster@starentnetworks.com -- and destroy all copies of this=20 > >> message and any attachments without reading or disclosing their=20 > >> contents. Thank you." > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 11:21:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IavAf-0002eO-Kn; Thu, 27 Sep 2007 11:20:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IavAe-0002eH-4C for netlmm@ietf.org; Thu, 27 Sep 2007 11:20:56 -0400 Received: from mout.perfora.net ([74.208.4.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IavAd-0004iH-Hi for netlmm@ietf.org; Thu, 27 Sep 2007 11:20:55 -0400 Received: from [88.233.215.25] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1IavAW3a50-0008LR; Thu, 27 Sep 2007 11:20:54 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 18:20:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgBEcMjcC3lc64RTWumd2kxgzjmrwABuYdg In-Reply-To: <46FBBC80.8060602@azairenet.com> Message-Id: <0MKp8S-1IavAW3a50-0008LR@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19jShB+ff+/F22r6BL1uLEN4YtLgC/kfANGWwM bZqiKWbuR4KGQBQtVRQtI6aPD7n8N+6CCBZ3af9vEAoxrpiii3 K/E7X7Trbyq7/+oxQEQZQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay, > >>> Ahmad, > >>> > >>>> In case that a HNP is available at the MAG (how: out-of-scope) and > >>>> included in the initial P-BU, ... > >>> ... MAG is not required to include an NAI option that carries the > >>> MN-identifier. > >>> > >>> In the spec, all we need to say is "MN-Identifier MUST be included in > >> PBU > >>> when the HNP is set to 0::0/0" > >> Of course not. If the MAG is going to be presenting the home network > >> prefix in the proxy binding update to the LMA, then the LMA needs to > >> check if the mobile node is authorized for the home network prefix. For > >> this check to happen, the MN-ID must be there in the proxy binding > >> update even if the home network prefix is set to something other than > >> 0::0. > > > > What really needs to be authorized is the "MAG" for sucking in all the > > traffic destined for a HNP. Checking if the MN-id and HNP matches is > > meaningless next to this one. In order to do the former, the system > > internally needs to perform the latter. > > We require both. > > > Let me be more specific, but note that these are outside scope of PMIP6 > > spec. > > > > During network access authentication, the home network associates MN and > > MAG. > > Assigning the home network prefix during access authentication would > involve something like the AAA server managing the home network prefixes > pool. I don't see any advantages with that. Do you keep updating the AAA > database everytime something changes on the LMA? Vijay, you are confusing me. If there is no known (to AAA) association between the MN and the HNP, why do you care to check the MN-id???? You said " LMA needs to check if the mobile node is authorized for the home network prefix" Where is the base of that check coming from? > > Since we care about protecting the HNP, home network already knows the > > MN and HNP association. So, when the MAG sends the PBU, home network can > > check if the requested HNP matches those of MNs that are associated with > the > > MAG. See that does not involve carrying the MN-id (when HNP is present > in > > the PBU). > > Lets assume its the AAA server that did the assignment. The LMA would > need to check with the AAA server if the MAG is using the right home > network prefix for a particular mobile node. What if the MAG mixed up > the prefixes for two mobile nodes attached to it both authenticated by > the same AAA server? This would require the LMA knowing the MN-ID and > the home network prefix when the proxy BU is received at the LMA. So you > have to include the MN-ID in the proxy BU. I don't understand this example at all. I don't understand the mix up, and why we would be dealing with a MAG that "mixes up things". > > Alper, frankly I think you need to show why including the MN-ID in the > proxy BU is a bad idea. If there is no issue, lets move on. Frankly, I did show it on the ML twice already. And yet to see why it is useful (other than for the HNP assignment case). Alper > > Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 11:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IavMh-0003DR-Gx; Thu, 27 Sep 2007 11:33:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IavMf-00030X-AK for netlmm@ietf.org; Thu, 27 Sep 2007 11:33:21 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IavMe-0001rl-2M for netlmm@ietf.org; Thu, 27 Sep 2007 11:33:21 -0400 Received: from [88.233.215.25] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1IavMY0n4U-0007NJ; Thu, 27 Sep 2007 11:33:19 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 18:33:05 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgBEpFeIwxJmZX2T92Pup85/gQyOQACNTdA In-Reply-To: <46FBBDDA.1050606@azairenet.com> Message-Id: <0MKpCa-1IavMY0n4U-0007NJ@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX18UU3UOPmZz25BpFmTylS7AcOmN5Nnshmal5H7 8wTRlR3n6qmA5Q6fkgUn5XqKhKIkflTA7XYSLSvAmOnusJ/v5p Pv46MQU5dwUiFcHQS6d3Q== X-Spam-Score: -0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org If the HNP is assigned during network access AAA, PMIP6 does not have to carry the MN-Id at all. Only MAG-Id is carried for RFC 4285 auth. Alper > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Thursday, September 27, 2007 5:28 PM > To: Alper Yegin > Cc: 'Chowdhury, Kuntal'; netlmm@ietf.org > Subject: Re: [netlmm] MN-Id overspecification > > I don't understand. RFC 4285 requires MN-ID in the binding update. For > what you want to do you would need to include the MAG-ID in addition to > the MN-ID in the proxy binding update. > > Vijay > > Alper Yegin wrote: > > Kuntal, > > > >> Even if the HNP is included in the PBU, the user identity cannot be > >> deterministically derived from that info. The HNP may be dynamically > >> assigned to the users in many systems. > > > > Whoever assigned the HNP has a chance to see the user id. Either it is > > assigned during the network access authentication, in which case the > user id > > is best known; or it is assigned during the initial PBU in which case I > say > > we shall include MN-id. > > > > But once the HNP<->MN-id binding is established like above, we no longer > > need to keep sending MN-id. HNP becomes the identifier. > > > > Alper > > > >> The benefit of including the MN-ID (NAI) in the PMIP signaling messages > >> is that it provides a unique and consistent way to identify the user at > >> the LMA and the MAG at all times (i.e. initial attach and > >> re-registration). > >> > >> BR, > >> Kuntal > >> > >> > >>> -----Original Message----- > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>> Sent: Wednesday, September 26, 2007 11:58 AM > >>> To: 'Ahmad Muhanna'; netlmm@ietf.org > >>> Subject: RE: [netlmm] MN-Id overspecification > >>> > >>> Ahmad, > >>> > >>>> In case that a HNP is available at the MAG (how: out-of-scope) and > >>>> included in the initial P-BU, ... > >>> ... MAG is not required to include an NAI option that carries the > >>> MN-identifier. > >>> > >>> In the spec, all we need to say is "MN-Identifier MUST be included in > >> PBU > >>> when the HNP is set to 0::0/0" > >>> > >>> > >>> Alper > >>> > >>> > >>> > >>> NO NAI or any other IDs related to the MN > >>>> should be included? > >>>> > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>>>> Sent: Wednesday, September 26, 2007 7:35 AM > >>>>> To: netlmm@ietf.org > >>>>> Subject: [netlmm] MN-Id overspecification > >>>>> > >>>>> This issue is still hanging. > >>>>> > >>>>> So far as I understand the MN-Id is only used for performing > >>>>> HNP assignment in-band with PMIP6 signaling. In case HNP is > >>>>> already assigned, there is no need to be carrying any info > >>>>> that directly or indirectly points to the MN's identity. > >>>>> > >>>>> But on the other hand, MN-id is all over the spec with > >>>>> normative languages that suggest it be present in every message. > >>>>> > >>>>> This is an overspecification, reducing flexibility and > >>>>> getting in the ways of various deployment scenarios. > >>>>> > >>>>> I recommend we change the spec such that MN-id is only > >>>>> mandated when HNP needs to be assigned. > >>>>> > >>>>> Would there be an objection to that? Is there any technical > >>>>> reason to carry an identifier of the MN in every PMIP6 message? > >>>>> > >>>>> > >>>>> Alper > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >> > >> "This email message and any attachments are confidential information of > >> Starent Networks, Corp. The information transmitted may not be used to > >> create or change any contractual obligations of Starent Networks, Corp. > >> Any review, retransmission, dissemination or other use of, or taking of > >> any action in reliance upon this e-mail and its attachments by persons > or > >> entities other than the intended recipient is prohibited. If you are > not > >> the intended recipient, please notify the sender immediately -- by > >> replying to this message or by sending an email to > >> postmaster@starentnetworks.com -- and destroy all copies of this > message > >> and any attachments without reading or disclosing their contents. Thank > >> you." > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 11:34:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IavNT-0000Pr-Iy; Thu, 27 Sep 2007 11:34:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IavNR-0000DQ-Mi for netlmm@ietf.org; Thu, 27 Sep 2007 11:34:09 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IavNR-00056L-51 for netlmm@ietf.org; Thu, 27 Sep 2007 11:34:09 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 08:34:07 -0700 Message-ID: <46FBCD6A.8030401@azairenet.com> Date: Thu, 27 Sep 2007 08:34:02 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKp8S-1IavAW3a50-0008LR@mrelay.perfora.net> In-Reply-To: <0MKp8S-1IavAW3a50-0008LR@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 15:34:08.0074 (UTC) FILETIME=[D81022A0:01C8011B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > Vijay, > >>>>> Ahmad, >>>>> >>>>>> In case that a HNP is available at the MAG (how: out-of-scope) and >>>>>> included in the initial P-BU, ... >>>>> ... MAG is not required to include an NAI option that carries the >>>>> MN-identifier. >>>>> >>>>> In the spec, all we need to say is "MN-Identifier MUST be included in >>>> PBU >>>>> when the HNP is set to 0::0/0" >>>> Of course not. If the MAG is going to be presenting the home network >>>> prefix in the proxy binding update to the LMA, then the LMA needs to >>>> check if the mobile node is authorized for the home network prefix. For >>>> this check to happen, the MN-ID must be there in the proxy binding >>>> update even if the home network prefix is set to something other than >>>> 0::0. >>> What really needs to be authorized is the "MAG" for sucking in all the >>> traffic destined for a HNP. Checking if the MN-id and HNP matches is >>> meaningless next to this one. In order to do the former, the system >>> internally needs to perform the latter. >> We require both. >> >>> Let me be more specific, but note that these are outside scope of PMIP6 >>> spec. >>> >>> During network access authentication, the home network associates MN and >>> MAG. >> Assigning the home network prefix during access authentication would >> involve something like the AAA server managing the home network prefixes >> pool. I don't see any advantages with that. Do you keep updating the AAA >> database everytime something changes on the LMA? > > Vijay, you are confusing me. If there is no known (to AAA) association > between the MN and the HNP, why do you care to check the MN-id???? You said > " LMA needs to check if the mobile node is authorized for the home network > prefix" Where is the base of that check coming from? The sequence would be as follows for your scenario (assuming your scenario is to allocate HNP during access authentication) - MN does access authentication - AAA server sends the HNP for the MN to the MAG - MAG sends a proxy BU with the MN-ID and the HNP to the LMA - LMA checks if the MN-ID is authorized for the HNP (with AAA's help) Note that I completely disagree with the AAA server assigning the HNP. I would like HNP assignment always coming from the LMA. >> Alper, frankly I think you need to show why including the MN-ID in the >> proxy BU is a bad idea. If there is no issue, lets move on. > > Frankly, I did show it on the ML twice already. And yet to see why it is > useful (other than for the HNP assignment case). With 4285? That was hardly convincing. Sorry. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 12:51:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawaQ-0007RT-90; Thu, 27 Sep 2007 12:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawaO-0007RO-Qc for netlmm@ietf.org; Thu, 27 Sep 2007 12:51:36 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IawaI-0004CC-IW for netlmm@ietf.org; Thu, 27 Sep 2007 12:51:36 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8RGpKFP003179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 27 Sep 2007 09:51:20 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8RGpCow014078 for ; Thu, 27 Sep 2007 09:51:20 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 09:51:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Concluding this thread (RE: [netlmm] MN-Id overspecification) Date: Thu, 27 Sep 2007 09:51:13 -0700 Message-ID: In-Reply-To: <0MKpCa-1IavMY0n4U-0007NJ@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Concluding this thread (RE: [netlmm] MN-Id overspecification) Thread-Index: AcgBEpFeIwxJmZX2T92Pup85/gQyOQACNTdAAAKPQ3A= References: <46FBBDDA.1050606@azairenet.com> <0MKpCa-1IavMY0n4U-0007NJ@mrelay.perfora.net> From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 27 Sep 2007 16:51:16.0457 (UTC) FILETIME=[9ECB5590:01C80126] X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org All, I think this discussion has gone on long enough and is now getting into the same points again. The discussion of Auth protocol in this thread at the moment is not useful. The WG is not working on that and we really don't have the bandwidth to spend on that right now. =20 >From the various points I've seen, it appears like the MN-ID may not be technically needed in all the messages, but, also, there doesn't seem to be anything technically wrong with the inclusion of it. It also appears that most people prefer that the procedures for all the PBU/PBA signaling be similar where possible and hence, prefer keeping the MN-ID in all the messages.=20 I note that Alper, Alex and I* (to some extent) prefer to keep it out of messages that don't need it, but, I don't see anyone else agreeing with that viewpoint. So, let's move on with the conclusion that we leave the MN-ID in the messaging as specified in the document now. =20 Thanks, Vidya * Although I was saying that we can keep the MN-ID out of messages that don't need it, I don't have a strong preference. It is not a technical showstopper and so, I'm fine with moving on with the preference of the WG. =20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:08:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawqM-0000rJ-LZ; Thu, 27 Sep 2007 13:08:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawqJ-0000Wg-4P for netlmm@ietf.org; Thu, 27 Sep 2007 13:08:03 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IawqI-00088Q-61 for netlmm@ietf.org; Thu, 27 Sep 2007 13:08:02 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8RH7jxW019518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Sep 2007 10:07:45 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8RH7gsU008903; Thu, 27 Sep 2007 10:07:43 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 10:07:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 10:07:43 -0700 Message-ID: In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAArCQhA= References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> From: "Narayanan, Vidya" To: "Genadi Velev" X-OriginalArrivalTime: 27 Sep 2007 17:07:42.0554 (UTC) FILETIME=[EA8DCBA0:01C80128] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Genadi, > -----Original Message----- > From: Genadi Velev [mailto:Genadi.Velev@eu.panasonic.com]=20 > Sent: Thursday, September 27, 2007 5:31 AM > To: Narayanan, Vidya > Cc: ext Kilian Weniger; netlmm@ietf.org; Sri Gundavelli > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Hi Vidya, >=20 > I agree that there is an issue with multihomed MN attached to=20 > different MAGs under the same LMA. First we need to=20 > differentiate between scenarios where the multiple interfaces=20 > are of the same or different access technologies. Scenario 1:=20 > if a MN has multiple interfaces of the same technology (e.g.=20 > multiple WLAN cards), most probably the interfaces would=20 > attempt to connect to the same access point which means to=20 > the *same MAG*. Scenario 2: if the interfaces are of=20 > different access technologies and the MAGs are serving a=20 > specific access technology, then the interfaces are attached=20 > to *different MAGs*. I'm not exactly sure what are the=20 > impacts in scenario 1, or if this scenario can be avoided in=20 > managed networks (e.g. the network operator may not authorize=20 > the attachment of the second interface). Any thoughts on scenario 1? >=20 Actually, I don't think we can guarantee that two interfaces of the same access technology are attached to the same MAG. The RF characteristics (including, say, types of antennas on each one, which may well differ between two interfaces of the same technology) could end up with the MN attaching to say, two different base stations or access points going to different MAGs. It also gets into how do we define a particular technology - for instance, is WLAN an access technology or are 802.11a/b/g/n all different access technologies? So, this is too tricky to be making that assumption here.=20 > The following rows are considering merely scenario 2.=20 >=20 > > It seems to me that this is an unavoidable problem if the=20 > same MN-ID=20 > > is sent for multiple interfaces of the MN to the LMA. It=20 > seems like=20 > > an interface-specific ID (link layer address or equivalent)=20 > needs to=20 > > be included in the PBU, so that the LMA can ensure that the same=20 > > prefix/address is not assigned to multiple IP interfaces of an MN. =20 > > This may not be too difficult, given that the MN-MAG link is=20 > > point-to-point. >=20 > If we look at the available options in PBU/PBA, we can see=20 > that next to "NAI Option" (or "MN-ID option") we have a=20 > "Link-local Address Option". > Supposed that the link-local addresses of the multiple=20 > interfaces are different, an LMA can differentiate among PBUs=20 > having the same MN-ID option looking at the Link-local=20 > Address Option. IMHO, what we need to specify in the PMIPv6=20 > protocol is a behaviour in the LMA that the HNP is not solely=20 > bound to a MN-ID but also to the link-local address. In this=20 > way different HNPs would be assigned to PBUs (coming from different > MAGs) containing same MN-ID option but different link-local=20 > address options. >=20 Hmmm.. Can the LLA ever be the same over both interfaces? Given that the MN-MAG link is a point-to-point link, I would think it may be the same.. If we can guarantee uniqueness of the LLA, that may work. But, I'm not sure.=20 Regards, Vidya > thanks, > Genadi >=20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Thursday, September 27, 2007 7:59 AM > > To: Sri Gundavelli > > Cc: ext Kilian Weniger; netlmm@ietf.org > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > >=20 > >=20 > > All, > > Here is a description of the issue (I'm picking a simple=20 > scenario to=20 > > describe the issue; there are other scenarios as well;=20 > also, this has=20 > > been described on the list earlier): > >=20 > > * MN has two interfaces attached to MAG1 and MAG2 under the same LMA > > * Let's say MAG1 first created the binding at the LMA and=20 > acquired a=20 > > prefix/address for the MN, using MN-ID1 > > * MN obtains the prefix/address on Interface1 > > * MAG2 now sends a PBU with MN-ID1 also (very possible when=20 > the ID is=20 > > something like an NAI) > > * LMA thinks the MN moved, updates the binding and returns the same=20 > > prefix for the MN to MAG2 > > * MN ends up with the same prefix/address on Interface2 > >=20 > > At this point, if it is an IPv6 prefix, the MN may configure a=20 > > different address on Interface 2, but, we would have lost the=20 > > point-to-point nature and the associated properties of the MN-MAG=20 > > link; if it is an > > IPv6 or IPv4 address, the MN detects a duplicate address and shuts=20 > > down the interface from an IP point of view. The MN thinks only=20 > > Interface1 is active, while the LMA has a binding to MAG2=20 > > (corresponding to > > Interface2 of the MN). =20 > >=20 > > Result: MN does not have any IP access via either of its interfaces. > > Even if the MN has different addresses on the same prefix=20 > on its two=20 > > interfaces, Interface 1 cannot be used given LMA's state,=20 > but, the MN=20 > > is unaware of that. > >=20 > > Some thoughts on avoiding this problem:=20 > >=20 > > It seems to me that this is an unavoidable problem if the=20 > same MN-ID=20 > > is sent for multiple interfaces of the MN to the LMA. It=20 > seems like=20 > > an interface-specific ID (link layer address or equivalent)=20 > needs to=20 > > be included in the PBU, so that the LMA can ensure that the same=20 > > prefix/address is not assigned to multiple IP interfaces of an MN. =20 > > This may not be too difficult, given that the MN-MAG link is=20 > > point-to-point. > >=20 > >=20 > > Thoughts?=20 > >=20 > > Thanks, > > Vidya > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 > >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:10:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iawsx-0004T2-2G; Thu, 27 Sep 2007 13:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iawsu-0004L5-8r for netlmm@ietf.org; Thu, 27 Sep 2007 13:10:44 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iawsn-0004fE-W6 for netlmm@ietf.org; Thu, 27 Sep 2007 13:10:44 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8RHA1FW005578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Sep 2007 10:10:01 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8RHA02O012400; Thu, 27 Sep 2007 10:10:01 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 10:10:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 10:10:01 -0700 Message-ID: In-Reply-To: <008a01c8010f$c8234130$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoA== References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" , "Genadi Velev" X-OriginalArrivalTime: 27 Sep 2007 17:10:00.0693 (UTC) FILETIME=[3CE42250:01C80129] X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, I hope this is not news to anyone, but, we are not chartered to solve inter-interface handoffs in the WG at the moment. This is what our charter states: "The protocol will not attempt to hide handover between two separate interfaces on the mobile node. "=20 Inter-technology handoffs being a tricky problem to handle with NETLMM was identified in the early stages of charter creation. So, that is not a limitation for considering some interface-specific identity to be included in the PBU. =20 Hope that helps.=20 Regards, Vidya=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Thursday, September 27, 2007 7:08 AM > To: 'Genadi Velev'; Narayanan, Vidya > Cc: 'ext Kilian Weniger'; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Hi Genadi, > =20 > >=20 > > If we look at the available options in PBU/PBA, we can see=20 > that next=20 > > to "NAI Option" (or "MN-ID option") we have a "Link-local Address=20 > > Option". > > Supposed that the link-local addresses of the multiple=20 > interfaces are=20 > > different, an LMA can differentiate among PBUs having the=20 > same MN-ID=20 > > option looking at the Link-local Address Option. IMHO, what=20 > we need to=20 > > specify in the PMIPv6 protocol is a behaviour in the LMA=20 > that the HNP=20 > > is not solely bound to a MN-ID but also to the link-local=20 > address. In=20 > > this way different HNPs would be assigned to PBUs (coming from=20 > > different > > MAGs) containing same MN-ID option but different link-local address=20 > > options. >=20 > But, we need to allow handoff between two different=20 > interfaces (of different access technologies), if we keep a=20 > relation to the LLA, we cant do handoff. This scenario is=20 > more important than the scenario of simultaneous multi-access. >=20 > Sri >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:16:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iawy4-0002yk-EA; Thu, 27 Sep 2007 13:16:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iawy3-0002x5-5K for netlmm@ietf.org; Thu, 27 Sep 2007 13:16:03 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iawy2-0008Kr-CQ for netlmm@ietf.org; Thu, 27 Sep 2007 13:16:03 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8RHFFXk011696; Thu, 27 Sep 2007 19:15:17 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 27 Sep 2007 19:15:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 19:15:59 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AD4@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <0MKpCa-1IanvV202U-0007VA@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AABDcQjgAd8sdwAAhTU2A= References: <0MKpCa-1IanvV202U-0007VA@mrelay.perfora.net> From: "DE JUAN HUARTE FEDERICO" To: "Alper Yegin" X-OriginalArrivalTime: 27 Sep 2007 17:15:59.0775 (UTC) FILETIME=[12EBB2F0:01C8012A] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, I don't quite understand why the security solution you advocate for is = exclusive with in-band HNP assignment If I've understood clearly what you're trying to enable, I wonder if it = would suit you to have 2 NAIs: MN-NAI and MAG-NAI Then you could specify that the MAG-NAI is the one to be used for 4285 = purposes (wherever this is defined) Regards federico -----Message d'origine----- De : Alper Yegin [mailto:alper.yegin@yegin.org]=20 Envoy=E9 : jeudi 27 septembre 2007 09:37 =C0 : 'Basavaraj Patil'; 'Ahmad Muhanna'; netlmm@ietf.org Objet : RE: [netlmm] MN-Id overspecification Raj, > What is the downside of including the MN-ID in all the MAG/LMA = messages? > Does it break anything? As I had explained earlier, one way to deploy PMIP is to use RFC 4285 = with per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In that = case, HNP can be assigned during network access authentication (so, we = no longer need to convey the id of the "MN" in-band with PMIP), but we = need to convey the id of the "proxy-MN (MAG)" for PMIP security.=20 That scenario breaks when we unnecessarily force the protocol to always = carry "MN"-id. Even without this I could be arguing against this overspecification = based on lack of need and uncertainty around what to put in MN-id. Alper > You say that it "is an overspecification, reducing flexibility and=20 > getting in the ways of various deployment scenarios"... >=20 > How is it becoming an obstacle in any deployment scenario? >=20 > I am just wondering if you are optimizing the protocol by not=20 > including the MN-ID or if you see this as actually being a problem. >=20 > -Raj >=20 >=20 > On 9/26/07 11:58 AM, "ext Alper Yegin" wrote: >=20 > > Ahmad, > > > >> In case that a HNP is available at the MAG (how: out-of-scope) and=20 > >> included in the initial P-BU, ... > > > > ... MAG is not required to include an NAI option that carries the=20 > > MN-identifier. > > > > In the spec, all we need to say is "MN-Identifier MUST be included=20 > > in > PBU > > when the HNP is set to 0::0/0" > > > > > > Alper > > > > > > > > NO NAI or any other IDs related to the MN > >> should be included? > >> > >> > >> Regards, > >> Ahmad > >> > >> > >>> -----Original Message----- > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>> Sent: Wednesday, September 26, 2007 7:35 AM > >>> To: netlmm@ietf.org > >>> Subject: [netlmm] MN-Id overspecification > >>> > >>> This issue is still hanging. > >>> > >>> So far as I understand the MN-Id is only used for performing HNP=20 > >>> assignment in-band with PMIP6 signaling. In case HNP is already=20 > >>> assigned, there is no need to be carrying any info that directly=20 > >>> or indirectly points to the MN's identity. > >>> > >>> But on the other hand, MN-id is all over the spec with normative=20 > >>> languages that suggest it be present in every message. > >>> > >>> This is an overspecification, reducing flexibility and getting in=20 > >>> the ways of various deployment scenarios. > >>> > >>> I recommend we change the spec such that MN-id is only mandated=20 > >>> when HNP needs to be assigned. > >>> > >>> Would there be an objection to that? Is there any technical reason = > >>> to carry an identifier of the MN in every PMIP6 message? > >>> > >>> > >>> Alper > >>> > >>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:26:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iax8H-0002qp-D7; Thu, 27 Sep 2007 13:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iax8F-0002qj-U3 for netlmm@ietf.org; Thu, 27 Sep 2007 13:26:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iax89-00052M-LK for netlmm@ietf.org; Thu, 27 Sep 2007 13:26:35 -0400 X-IronPort-AV: E=Sophos;i="4.21,204,1188802800"; d="scan'208";a="177938874" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 27 Sep 2007 10:26:25 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8RHQOnj013631; Thu, 27 Sep 2007 10:26:24 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8RHQG21013436; Thu, 27 Sep 2007 17:26:24 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 10:26:19 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 10:26:19 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" , "'Genadi Velev'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 10:26:19 -0700 Message-ID: <00ba01c8012b$84300460$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAw X-OriginalArrivalTime: 27 Sep 2007 17:26:19.0269 (UTC) FILETIME=[842AFB50:01C8012B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3079; t=1190913984; x=1191777984; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=7ojScCQfQfUVTljorFr7TOkWXbHcaCjn3lhYMHgzmH4=; b=NNd+Nso4U7S+yXfOVsxG12pQ8lImgoTRmnPul/AllsvQ+/jam5hB6ZcxJe0OZ5UVTIF/pBam ozAm316J/AFU7xqz1r/8namueInANM2JgQdsIN6tDBs4dcv6wsgvQqS7+vDdHrXEkT+ckPtmoH 83bYuUIirlDFffkZ+lh15yAz0=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: 'ext Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, That's interesting. We dont allow inter-interface handoff, but we want to deal with multi-interface support issues ? We dont have to do any thing for supporting the former and the later requires some work. The charter also does not talk about multi-homing and I wonder if our decision to deal with this issue, is the right one. We may need some clarification from Jari on this. IMO, if we really think, this breaks the protocol, operator has the tools to deal with this. If a deployment has to support multi-homing, there are number of things that have to be place, including accounting system and other things. The operator has the knobs to control this aspect, it can be avoided in many different ways. Not sure, what other solution we have. Sri > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Thursday, September 27, 2007 10:10 AM > To: Sri Gundavelli; Genadi Velev > Cc: ext Kilian Weniger; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > Hi Sri, > I hope this is not news to anyone, but, we are not chartered to solve > inter-interface handoffs in the WG at the moment. This is what our > charter states: > > "The protocol will not attempt to hide handover > between two separate interfaces on the mobile node. " > > Inter-technology handoffs being a tricky problem to handle with NETLMM > was identified in the early stages of charter creation. So, > that is not > a limitation for considering some interface-specific identity to be > included in the PBU. > > Hope that helps. > > Regards, > Vidya > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Thursday, September 27, 2007 7:08 AM > > To: 'Genadi Velev'; Narayanan, Vidya > > Cc: 'ext Kilian Weniger'; netlmm@ietf.org > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > > > Hi Genadi, > > > > > > > > If we look at the available options in PBU/PBA, we can see > > that next > > > to "NAI Option" (or "MN-ID option") we have a "Link-local Address > > > Option". > > > Supposed that the link-local addresses of the multiple > > interfaces are > > > different, an LMA can differentiate among PBUs having the > > same MN-ID > > > option looking at the Link-local Address Option. IMHO, what > > we need to > > > specify in the PMIPv6 protocol is a behaviour in the LMA > > that the HNP > > > is not solely bound to a MN-ID but also to the link-local > > address. In > > > this way different HNPs would be assigned to PBUs (coming from > > > different > > > MAGs) containing same MN-ID option but different > link-local address > > > options. > > > > But, we need to allow handoff between two different > > interfaces (of different access technologies), if we keep a > > relation to the LLA, we cant do handoff. This scenario is > > more important than the scenario of simultaneous multi-access. > > > > Sri > > > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxDu-0001yp-Oh; Thu, 27 Sep 2007 13:32:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxDt-0001sN-JA for netlmm@ietf.org; Thu, 27 Sep 2007 13:32:25 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaxDn-0005C4-8N for netlmm@ietf.org; Thu, 27 Sep 2007 13:32:25 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8RHVvH7023015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Sep 2007 10:31:57 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8RHVu1W014613; Thu, 27 Sep 2007 10:31:57 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 10:31:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 10:31:53 -0700 Message-ID: In-Reply-To: <00ba01c8012b$84300460$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRA= References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> <00ba01c8012b$84300460$1220fea9@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" , "Genadi Velev" X-OriginalArrivalTime: 27 Sep 2007 17:31:56.0855 (UTC) FILETIME=[4D628470:01C8012C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, You seem to be missing the point. We are not dealing with multi-interface support issues in this thread. What we are dealing with is the fact that an MN may not be able to use *any* interface simply because it happens to have two interfaces. Unless the MN knows that the network is using PMIP and hence, it can only use one interface at a time, you are going to have regular IP nodes that run into this problem. In a nutshell, the problem is about an MN ending up with no IP service using even one of its interfaces. =20 I hope you can see that the problem doesn't relate to providing multihoming to the MN; rather it relates to something far more fundamental that this protocol is supposed to ensure - IP connectivity to the MN.=20 Vidya=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Thursday, September 27, 2007 10:26 AM > To: Narayanan, Vidya; 'Genadi Velev' > Cc: 'ext Kilian Weniger'; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Hi Vidya, >=20 >=20 > That's interesting. We dont allow inter-interface handoff,=20 > but we want to deal with multi-interface support issues ? > We dont have to do any thing for supporting the former and=20 > the later requires some work. >=20 > The charter also does not talk about multi-homing and I=20 > wonder if our decision to deal with this issue, is the right=20 > one. We may need some clarification from Jari on this. > =09 > IMO, if we really think, this breaks the protocol, operator=20 > has the tools to deal with this. If a deployment has to=20 > support multi-homing, there are number of things that have to=20 > be place, including accounting system and other things. The=20 > operator has the knobs to control this aspect, it can be=20 > avoided in many different ways. >=20 > Not sure, what other solution we have. >=20 > Sri >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Thursday, September 27, 2007 10:10 AM > > To: Sri Gundavelli; Genadi Velev > > Cc: ext Kilian Weniger; netlmm@ietf.org > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > >=20 > > Hi Sri, > > I hope this is not news to anyone, but, we are not=20 > chartered to solve=20 > > inter-interface handoffs in the WG at the moment. This is what our=20 > > charter states: > >=20 > > "The protocol will not attempt to hide handover between two=20 > separate=20 > > interfaces on the mobile node. " > >=20 > > Inter-technology handoffs being a tricky problem to handle=20 > with NETLMM=20 > > was identified in the early stages of charter creation. =20 > So, that is=20 > > not a limitation for considering some interface-specific=20 > identity to=20 > > be included in the PBU. > >=20 > > Hope that helps.=20 > >=20 > > Regards, > > Vidya > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Thursday, September 27, 2007 7:08 AM > > > To: 'Genadi Velev'; Narayanan, Vidya > > > Cc: 'ext Kilian Weniger'; netlmm@ietf.org > > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > >=20 > > > Hi Genadi, > > > =20 > > > >=20 > > > > If we look at the available options in PBU/PBA, we can see > > > that next > > > > to "NAI Option" (or "MN-ID option") we have a=20 > "Link-local Address=20 > > > > Option". > > > > Supposed that the link-local addresses of the multiple > > > interfaces are > > > > different, an LMA can differentiate among PBUs having the > > > same MN-ID > > > > option looking at the Link-local Address Option. IMHO, what > > > we need to > > > > specify in the PMIPv6 protocol is a behaviour in the LMA > > > that the HNP > > > > is not solely bound to a MN-ID but also to the link-local > > > address. In > > > > this way different HNPs would be assigned to PBUs (coming from=20 > > > > different > > > > MAGs) containing same MN-ID option but different > > link-local address > > > > options. > > >=20 > > > But, we need to allow handoff between two different=20 > interfaces (of=20 > > > different access technologies), if we keep a relation to=20 > the LLA, we=20 > > > cant do handoff. This scenario is more important than the=20 > scenario=20 > > > of simultaneous multi-access. > > >=20 > > > Sri > > >=20 > > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:34:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxFh-0004Gj-Kn; Thu, 27 Sep 2007 13:34:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxFg-0004G5-Vl for netlmm@ietf.org; Thu, 27 Sep 2007 13:34:16 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaxFa-0005Ez-Ke for netlmm@ietf.org; Thu, 27 Sep 2007 13:34:16 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8RHXuWj029401; Thu, 27 Sep 2007 20:34:00 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 20:33:40 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 12:33:32 -0500 Received: from 172.19.244.136 ([172.19.244.136]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 Sep 2007 17:33:32 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 27 Sep 2007 12:33:37 -0500 Subject: Re: Default router and new MAG (Was: [netlmm] Suresh's review ofdraft-ietf-netlmm-proxymip6-05) From: Basavaraj Patil To: Sri Gundavelli , "'Julien Laganier'" , Message-ID: Thread-Topic: Default router and new MAG (Was: [netlmm] Suresh's review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgBALsO/n3LKzJ9QkSVVvF8NxCxRwAEHRhQAAbWaZg= In-Reply-To: <008c01c80111$6c9d7770$1220fea9@amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 17:33:32.0480 (UTC) FILETIME=[8661BC00:01C8012C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, On 9/27/07 9:19 AM, "ext Sri Gundavelli" wrote: > Hi Julien, > > >> -----Original Message----- >> From: Julien Laganier [mailto:julien.IETF@laposte.net] >> Sent: Thursday, September 27, 2007 5:15 AM >> To: netlmm@ietf.org >> Subject: Default router and new MAG (Was: [netlmm] Suresh's >> review ofdraft-ietf-netlmm-proxymip6-05) >> >> On Tuesday 25 September 2007, Suresh Krishnan wrote: >>> Link Local address of MAG >>> ========================= >>> When an MN moves from one link to another how does it switch default >>> routers to the new MAG. The link local addresses of the old MAG and >>> the new MAG will most likely be different and hence unless nud >>> removes the old mag the mn will try to reach it even after handover. >>> Or it is assumed that all the MAGs will have the same LL address? Is >>> this is an assumption, it needs to be stated. >> >> FWIW the current DNAv6 spec would not require NUD to kick in >> and remove >> the old MAG. The MN would simply select a new router that is in >> reachable state. From [I-D.ietf-dna-protocol-06]: >> > > Thanks. This is very important. I can add a reference to this. > Probably, a good reason to enable to DNAv6 on the MN. We cannot be having any requirements on the MN. So lets not start saying that the MN should enable DNAv6 or expect it to do anything new for it to work in a PMIP domain. -Raj > > Sri > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:38:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxJx-0007D8-6O; Thu, 27 Sep 2007 13:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxJw-0007D2-Hv for netlmm@ietf.org; Thu, 27 Sep 2007 13:38:40 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaxJq-0005LE-6v for netlmm@ietf.org; Thu, 27 Sep 2007 13:38:40 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8RHcEjX010665; Thu, 27 Sep 2007 20:38:21 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 20:38:07 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 12:37:43 -0500 Received: from 172.19.244.136 ([172.19.244.136]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 Sep 2007 17:37:42 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 27 Sep 2007 12:37:48 -0500 Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs From: Basavaraj Patil To: "ext Narayanan, Vidya" , Sri Gundavelli , Genadi Velev Message-ID: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAFIfSQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 17:37:43.0043 (UTC) FILETIME=[1BBA9D30:01C8012D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vidya, Just for my education, can you please explain why the MN would shutdown both interfaces if it were to receive the same prefix on another interface on a multi-interface host? I guess I could dig up the archives... But if you can explain the issue behind such behavior, I would appreciate it. -Raj On 9/27/07 12:31 PM, "ext Narayanan, Vidya" wrote: > Sri, > You seem to be missing the point. We are not dealing with > multi-interface support issues in this thread. What we are dealing with > is the fact that an MN may not be able to use *any* interface simply > because it happens to have two interfaces. Unless the MN knows that the > network is using PMIP and hence, it can only use one interface at a > time, you are going to have regular IP nodes that run into this problem. > > > In a nutshell, the problem is about an MN ending up with no IP service > using even one of its interfaces. > > I hope you can see that the problem doesn't relate to providing > multihoming to the MN; rather it relates to something far more > fundamental that this protocol is supposed to ensure - IP connectivity > to the MN. > > Vidya _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:41:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxMR-0002Yd-7V; Thu, 27 Sep 2007 13:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxMP-0002TZ-FN for netlmm@ietf.org; Thu, 27 Sep 2007 13:41:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaxMO-0005PL-8H for netlmm@ietf.org; Thu, 27 Sep 2007 13:41:13 -0400 X-IronPort-AV: E=Sophos;i="4.21,204,1188802800"; d="scan'208";a="177943997" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 27 Sep 2007 10:41:12 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8RHfBUS011547; Thu, 27 Sep 2007 10:41:11 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8RHf6DX003821; Thu, 27 Sep 2007 17:41:11 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 10:41:09 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 10:41:08 -0700 From: "Sri Gundavelli" To: "'Basavaraj Patil'" , "'Julien Laganier'" , References: <008c01c80111$6c9d7770$1220fea9@amer.cisco.com> Subject: RE: Default router and new MAG (Was: [netlmm] Suresh's review ofdraft-ietf-netlmm-proxymip6-05) Date: Thu, 27 Sep 2007 10:41:08 -0700 Message-ID: <00bb01c8012d$96993c00$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgBALsO/n3LKzJ9QkSVVvF8NxCxRwAEHRhQAAbWaZgAAAxPMA== X-OriginalArrivalTime: 27 Sep 2007 17:41:09.0087 (UTC) FILETIME=[968A6EF0:01C8012D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=531; t=1190914871; x=1191778871; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20Default=20router=20and=20new=20MAG=20(Was=3A=20[netlm m]=20Suresh's=20review=20ofdraft-ietf-netlmm-proxymip6-05) |Sender:=20; bh=k/FP89wq4cNzJVXr3md/0G18dcAGXl2pg8KyWCINp1A=; b=HQ5CreywNBgKBcqnmfPShp46CYzLcj3NlQw4gK2++tvcp4yUJIf1A+aYM8pdskI2RLDroM39 pd9sd38esjPQhzBqGDERMQFCTPZ7dHbBwIYFraIrYZqjSa8Y8JPSwpfiSve5bIHtO4n5Jtfhnk /D3n2WTZU2U0tU8QzpJY4mfAg=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Raj, > > > > Thanks. This is very important. I can add a reference to this. > > Probably, a good reason to enable to DNAv6 on the MN. > > We cannot be having any requirements on the MN. So lets not > start saying > that the MN should enable DNAv6 or expect it to do anything > new for it to > work in a PMIP domain. > We are not mandating DNAv6. Its informational. If MN has DNAv6 stack, it can flush the old AR entry immediatly. That is very important. Do you see any issue, stating that point ? Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxVn-00008Y-7B; Thu, 27 Sep 2007 13:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxVl-0008Uc-TL for netlmm@ietf.org; Thu, 27 Sep 2007 13:50:53 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaxVh-0005db-O6 for netlmm@ietf.org; Thu, 27 Sep 2007 13:50:53 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8RHo1Hu011155; Thu, 27 Sep 2007 20:50:45 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 20:50:44 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 12:50:42 -0500 Received: from 172.19.244.136 ([172.19.244.136]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 Sep 2007 17:50:42 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 27 Sep 2007 12:50:48 -0500 Subject: Re: [netlmm] MN-Id overspecification From: Basavaraj Patil To: Alper Yegin , "'Ahmad Muhanna'" , Message-ID: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AABDcQjgAd8sdwABWfzR0= In-Reply-To: <0MKpCa-1IanvV202U-0007VA@mrelay.perfora.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 17:50:42.0982 (UTC) FILETIME=[EC9BDC60:01C8012E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, On 9/27/07 2:36 AM, "ext Alper Yegin" wrote: > Raj, > >> What is the downside of including the MN-ID in all the MAG/LMA messages? >> Does it break anything? > > As I had explained earlier, one way to deploy PMIP is to use RFC 4285 with > per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In that case, HNP > can be assigned during network access authentication (so, we no longer need > to convey the id of the "MN" in-band with PMIP), but we need to convey the > id of the "proxy-MN (MAG)" for PMIP security. To use RFC4285 for PMIP6, you will need to specify how this is used. I think Sri stated something similarly that the extensions needed in PMIP6 messages for using 4285 cannot be simply used as is. > > That scenario breaks when we unnecessarily force the protocol to always > carry "MN"-id. I don't think it breaks. Having MN-ID in addition to another parameter should solve your issue. > > Even without this I could be arguing against this overspecification based on > lack of need and uncertainty around what to put in MN-id. Lack of need in subsequent messages is what I think you are refering to and that seems to be the general view. An example of what the MN-ID possibly is, is given in the ID, i.e the NAI. Any other ID types can be used but will need to be registered in IANA. -Raj > > Alper > > > >> You say that it "is an overspecification, reducing flexibility and >> getting in the ways of various deployment scenarios"... >> >> How is it becoming an obstacle in any deployment scenario? >> >> I am just wondering if you are optimizing the protocol by not including >> the >> MN-ID or if you see this as actually being a problem. >> >> -Raj >> >> >> On 9/26/07 11:58 AM, "ext Alper Yegin" wrote: >> >>> Ahmad, >>> >>>> In case that a HNP is available at the MAG (how: out-of-scope) and >>>> included in the initial P-BU, ... >>> >>> ... MAG is not required to include an NAI option that carries the >>> MN-identifier. >>> >>> In the spec, all we need to say is "MN-Identifier MUST be included in >> PBU >>> when the HNP is set to 0::0/0" >>> >>> >>> Alper >>> >>> >>> >>> NO NAI or any other IDs related to the MN >>>> should be included? >>>> >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] >>>>> Sent: Wednesday, September 26, 2007 7:35 AM >>>>> To: netlmm@ietf.org >>>>> Subject: [netlmm] MN-Id overspecification >>>>> >>>>> This issue is still hanging. >>>>> >>>>> So far as I understand the MN-Id is only used for performing >>>>> HNP assignment in-band with PMIP6 signaling. In case HNP is >>>>> already assigned, there is no need to be carrying any info >>>>> that directly or indirectly points to the MN's identity. >>>>> >>>>> But on the other hand, MN-id is all over the spec with >>>>> normative languages that suggest it be present in every message. >>>>> >>>>> This is an overspecification, reducing flexibility and >>>>> getting in the ways of various deployment scenarios. >>>>> >>>>> I recommend we change the spec such that MN-id is only >>>>> mandated when HNP needs to be assigned. >>>>> >>>>> Would there be an objection to that? Is there any technical >>>>> reason to carry an identifier of the MN in every PMIP6 message? >>>>> >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>> >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 13:52:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxXQ-00031P-2K; Thu, 27 Sep 2007 13:52:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxXO-00031J-Hf for netlmm@ietf.org; Thu, 27 Sep 2007 13:52:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaxXN-0000ti-L8 for netlmm@ietf.org; Thu, 27 Sep 2007 13:52:34 -0400 X-IronPort-AV: E=Sophos;i="4.21,204,1188802800"; d="scan'208";a="20432895" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Sep 2007 10:52:33 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8RHqXel009576; Thu, 27 Sep 2007 10:52:33 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l8RHqRfu001128; Thu, 27 Sep 2007 17:52:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 10:52:32 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 10:52:31 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" , "'Genadi Velev'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> <00ba01c8012b$84300460$1220fea9@amer.cisco.com> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 10:52:31 -0700 Message-ID: <00c201c8012f$2dabe5b0$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAJfjsA== X-OriginalArrivalTime: 27 Sep 2007 17:52:32.0092 (UTC) FILETIME=[2DA4B9C0:01C8012F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5543; t=1190915553; x=1191779553; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=HlxhTGvgvklaTl7+sXbgIAvHc0pccfDuY52JPPp+gnM=; b=tSkvRnZnsQZ/7qkGl81gemBy6eM13q1ae5kuE/8PIHG/91OWKAvVnfG8cpFVEKiOTM0eoj4W 58lQKslN04jGDvV6T2MQhwHzQJZLwpaezNHRcUfbDexGr7RiCHeCrVV/; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: 'ext Kilian Weniger' , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vidya, We are not dealing with > multi-interface support issues in this thread. What we are > dealing with > is the fact that an MN may not be able to use *any* interface simply > because it happens to have two interfaces. If we are not dealing with multi-interface support, we dont need to talk about the scenario where the MN has multiple active interfaces. This is not the right interpretation of the charter, IMHO. If operators want to deal with this, let them configure a unique NAI for each interface and even when multiple interfaces are active, each interface will endup with a unique prefix. Sri > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Thursday, September 27, 2007 10:32 AM > To: Sri Gundavelli; Genadi Velev > Cc: ext Kilian Weniger; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > Sri, > You seem to be missing the point. We are not dealing with > multi-interface support issues in this thread. What we are > dealing with > is the fact that an MN may not be able to use *any* interface simply > because it happens to have two interfaces. Unless the MN > knows that the > network is using PMIP and hence, it can only use one interface at a > time, you are going to have regular IP nodes that run into > this problem. > > > In a nutshell, the problem is about an MN ending up with no IP service > using even one of its interfaces. > > I hope you can see that the problem doesn't relate to providing > multihoming to the MN; rather it relates to something far more > fundamental that this protocol is supposed to ensure - IP connectivity > to the MN. > > Vidya > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Thursday, September 27, 2007 10:26 AM > > To: Narayanan, Vidya; 'Genadi Velev' > > Cc: 'ext Kilian Weniger'; netlmm@ietf.org > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > > > Hi Vidya, > > > > > > That's interesting. We dont allow inter-interface handoff, > > but we want to deal with multi-interface support issues ? > > We dont have to do any thing for supporting the former and > > the later requires some work. > > > > The charter also does not talk about multi-homing and I > > wonder if our decision to deal with this issue, is the right > > one. We may need some clarification from Jari on this. > > > > IMO, if we really think, this breaks the protocol, operator > > has the tools to deal with this. If a deployment has to > > support multi-homing, there are number of things that have to > > be place, including accounting system and other things. The > > operator has the knobs to control this aspect, it can be > > avoided in many different ways. > > > > Not sure, what other solution we have. > > > > Sri > > > > > > > > > > > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Thursday, September 27, 2007 10:10 AM > > > To: Sri Gundavelli; Genadi Velev > > > Cc: ext Kilian Weniger; netlmm@ietf.org > > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > > > > > Hi Sri, > > > I hope this is not news to anyone, but, we are not > > chartered to solve > > > inter-interface handoffs in the WG at the moment. This > is what our > > > charter states: > > > > > > "The protocol will not attempt to hide handover between two > > separate > > > interfaces on the mobile node. " > > > > > > Inter-technology handoffs being a tricky problem to handle > > with NETLMM > > > was identified in the early stages of charter creation. > > So, that is > > > not a limitation for considering some interface-specific > > identity to > > > be included in the PBU. > > > > > > Hope that helps. > > > > > > Regards, > > > Vidya > > > > > > > -----Original Message----- > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > Sent: Thursday, September 27, 2007 7:08 AM > > > > To: 'Genadi Velev'; Narayanan, Vidya > > > > Cc: 'ext Kilian Weniger'; netlmm@ietf.org > > > > Subject: RE: [netlmm] Issue: Prefix allocation and > multihomed MNs > > > > > > > > Hi Genadi, > > > > > > > > > > > > > > If we look at the available options in PBU/PBA, we can see > > > > that next > > > > > to "NAI Option" (or "MN-ID option") we have a > > "Link-local Address > > > > > Option". > > > > > Supposed that the link-local addresses of the multiple > > > > interfaces are > > > > > different, an LMA can differentiate among PBUs having the > > > > same MN-ID > > > > > option looking at the Link-local Address Option. IMHO, what > > > > we need to > > > > > specify in the PMIPv6 protocol is a behaviour in the LMA > > > > that the HNP > > > > > is not solely bound to a MN-ID but also to the link-local > > > > address. In > > > > > this way different HNPs would be assigned to PBUs > (coming from > > > > > different > > > > > MAGs) containing same MN-ID option but different > > > link-local address > > > > > options. > > > > > > > > But, we need to allow handoff between two different > > interfaces (of > > > > different access technologies), if we keep a relation to > > the LLA, we > > > > cant do handoff. This scenario is more important than the > > scenario > > > > of simultaneous multi-access. > > > > > > > > Sri > > > > > > > > > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 14:02:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxgT-0001Yj-1O; Thu, 27 Sep 2007 14:01:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxgQ-0001Mm-OH for netlmm@ietf.org; Thu, 27 Sep 2007 14:01:54 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaxgP-00017x-6x for netlmm@ietf.org; Thu, 27 Sep 2007 14:01:54 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8RI13Hn013576; Thu, 27 Sep 2007 20:01:03 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 27 Sep 2007 20:01:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [netlmm] Issue: Retransmissions and timestamps Date: Thu, 27 Sep 2007 20:01:42 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AD9@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Retransmissions and timestamps Thread-Index: AcgAa91QSn/PgZLXQvGeTGNd78aBRgAM34iwAAEPgSAAC4OxUAAMLDVw References: <46F848E2.40904@ericsson.com><46F852A3.1040401@azairenet.com><46F91662.6030200@ericsson.com><46F985BE.3030108@azairenet.com><00cf01c7ffe3$64cd6570$1220fea9@amer.cisco.com><002901c800a5$dc49d850$1220fea9@amer.cisco.com> From: "DE JUAN HUARTE FEDERICO" To: "Narayanan, Vidya" X-OriginalArrivalTime: 27 Sep 2007 18:01:50.0088 (UTC) FILETIME=[7A3C2880:01C80130] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 876202f9cbc0933cffbc58102e40f8f2 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0750445914==" Errors-To: netlmm-bounces@ietf.org This is a multi-part message in MIME format. --===============0750445914== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80130.7A180B2E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80130.7A180B2E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vidya, I think you and Sri are talking about different re-transmissions You're talking about the retransmission of a PBU in case the previous = PBU or the previous PBack was lost Sri is talking about the retransmission of a PBU when the MAG receives a = TIMESTAMP_MISTMACH error code Citing v6 of the I-D: "If the received Proxy Binding Acknowledgement message has the Status = field value set to TIMESTAMP_MISMATCH (Invalid Timestamp), the mobile = access gateway SHOULD try to register again only after it has = synchronized its clock to a common time source that is used by all the = mobility entities in that domain for their clock synchronization. " Regards federico =20 -----Message d'origine----- De : Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 Envoy=E9 : jeudi 27 septembre 2007 08:49 =C0 : Sri Gundavelli Cc : netlmm@ietf.org Objet : RE: [netlmm] Issue: Retransmissions and timestamps Hi Sri,=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Wednesday, September 26, 2007 6:30 PM > To: Narayanan, Vidya > Cc: 'Vijay Devarapalli'; 'Suresh Krishnan'; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Retransmissions and timestamps >=20 > =20 > > I don't understand what the above means. We need to > specify a maximum > > retransmission value and the LMA should not be responding to=20 > > retransmissions beyond that. Can you elaborate on what > complications > > retransmissions with the same timestamp value leads to? In > fact, to > > the contrary, if the LMA could never tell the difference between a=20 > > retransmission and a new PBU, it will continue to process > and respond > > to each one. That seems less desirable to me. What am I missing? > >=20 >=20 >=20 > What is not clear to you from the below quoted text. Let me try again. >=20 > 1. What is the intended purpose of the time stamp ? To ensure > ordering of the messages. A node generating the message adds > the timestamp. It claims the node is present at that instance > of time. Dont you think, if we use the same timestamp in the > retransmissions, will that not beat the purpose ? >=20 Not really. A retransmission says that the MAG notified that the MN is = present earlier, but, it hasn't heard an ack yet.=20 > 2. You should explain, rather than dodging the question, what > is wrong in the current scheme. If there is an issue, we will > be glad to change it. As we worked with Kilian, Ahmad, Federico > and evolved this logic. >=20 I did explain in my review - basically, retransmissions are efficiently = done by simply caching the constructed message until a response is = received and sending it again if no response was received within a given = time. It also helps the LMA, since the LMA can cache the responses for = a short amount of time to simply re-send it upon receiving a = retransmitted PBU. This is a commonly used philosophy to mitigate the = impact of DoS attacks also - i.e., the idempotent nature of an entity = involves less work than processing and responding to each message as if = it was a new one. It also helps the LMA to stop responding after a few = retransmissions have been responded to. So, I think that unless there = is a good reason to increment the timestamps for retransmissions, it = shouldn't be. =20 I'll let Suresh outline the issue he was describing. =20 Thanks, Vidya > 3. When using sequence numbers, 3775 does not use the same > sequence number in retransmitted messages. Why ? This scheme > is consistent with 3775. > =20 > "Retransmitted Binding Updates MUST use a Sequence Number value > greater than that used for the previous transmission of this=20 > Binding > Update. Retransmitted Home Test Init and Care-of Test Init=20 > messages > MUST use new cookie values." >=20 > 4. I do not see a need for the LMA to differentiate between the two. > The lifetime that it allocates to the session is w.r.t the newly > received message. >=20 > Sri >=20 >=20 >=20 >=20 >=20 > >> We are not using timestamps for replay protection. When a message=20 > >> is retransmitted, the entity that is sending the message is=20 > >> claiming the presence of the node at that instance of time and the=20 > >> timestamp in the message should reflect that. > >> If the nodes keep retransmitting for a longer and longer times, we=20 > >> need to consider lot more cases to handle this correctly. I do not=20 > >> know, what issues you are Suresh are foreseeing, when a message is=20 > >> retransmitted with a new timestamp. If there is an issue that you=20 > >> see, then we can try to fix this logic. > >> >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm ------_=_NextPart_001_01C80130.7A180B2E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [netlmm] Issue: Retransmissions and timestamps

Hi = Vidya,

I think you and Sri = are talking about different re-transmissions
You're talking about = the retransmission of a PBU in case the previous PBU or the previous = PBack was lost
Sri is talking about = the retransmission of a PBU when the MAG receives a TIMESTAMP_MISTMACH = error code

Citing v6 of the = I-D:
"If the = received Proxy Binding Acknowledgement message has the Status field = value set to TIMESTAMP_MISMATCH (Invalid Timestamp), the mobile access = gateway SHOULD try to register again only after it has synchronized its = clock to a common time source that is used by all the mobility entities = in that domain for their clock synchronization. = "

Regards

federico
 

-----Message = d'origine-----
De : Narayanan, = Vidya [mailto:vidyan@qualcomm.com]
Envoy=E9 : jeudi 27 = septembre 2007 08:49
=C0 : Sri = Gundavelli
Cc : = netlmm@ietf.org
Objet : RE: [netlmm] = Issue: Retransmissions and timestamps

Hi Sri, =

> -----Original = Message-----
> From: Sri = Gundavelli [mailto:sgundave@cisco.com]
> Sent: = Wednesday, September 26, 2007 6:30 PM
> To: Narayanan, = Vidya
> Cc: 'Vijay = Devarapalli'; 'Suresh Krishnan'; netlmm@ietf.org
> Subject: RE: = [netlmm] Issue: Retransmissions and timestamps
>
>  =
> > I don't = understand what the above means.  We need to
> specify a = maximum
> > = retransmission value and the LMA should not be responding to =
> > = retransmissions beyond that.  Can you elaborate on = what
> = complications
> > = retransmissions with the same timestamp value leads to?  = In
> fact, = to
> > the = contrary, if the LMA could never tell the difference between a =
> > = retransmission and a new PBU, it will continue to process
> and = respond
> > to each = one.  That seems less desirable to me.  What am I = missing?
> > =
>
>
> What is not = clear to you from the below quoted text. Let me try again.
>
> 1. What is the = intended purpose of the time stamp ? To ensure
>    ordering of the messages. A node = generating the message adds
>    the timestamp. It claims the node = is present at that instance
>    of time. Dont you think, if we use = the same timestamp in the
>    retransmissions, will that not = beat the purpose ?
>

Not really.  A = retransmission says that the MAG notified that the MN is present = earlier, but, it hasn't heard an ack yet.

> 2. You should = explain, rather than dodging the question, what
>    is wrong in the current scheme. If = there is an issue, we will
>    be glad to change it. As we worked = with Kilian, Ahmad, Federico
>    and evolved this = logic.
>

I did explain in my = review - basically, retransmissions are efficiently done by simply = caching the constructed message until a response is received and sending = it again if no response was received within a given time.  It also = helps the LMA, since the LMA can cache the responses for a short amount = of time to simply re-send it upon receiving a retransmitted PBU.  = This is a commonly used philosophy to mitigate the impact of DoS attacks = also - i.e., the idempotent nature of an entity involves less work than = processing and responding to each message as if it was a new one.  = It also helps the LMA to stop responding after a few retransmissions = have been responded to.  So, I think that unless there is a good = reason to increment the timestamps for retransmissions, it shouldn't = be. 

I'll let Suresh = outline the issue he was describing. 

Thanks,
Vidya

> 3. When using = sequence numbers, 3775 does not use the same
>    sequence number in retransmitted = messages. Why ? This scheme
>    is consistent with = 3775.
>   
>    "Retransmitted Binding = Updates MUST use a Sequence Number value
>    greater than that used for the = previous transmission of this
> = Binding
>    Update.  Retransmitted Home = Test Init and Care-of Test Init
> = messages
>    MUST use new cookie = values."
>
> 4. I do not see = a need for the LMA to differentiate between the two.
>    The lifetime that it allocates to = the session is w.r.t the newly
>    received message.
>
> = Sri
>
>
>
>
>
> >> We are = not using timestamps for replay protection. When a message =
> >> is = retransmitted, the entity that is sending the message is
> >> = claiming the presence of the node at that instance of time and the =
> >> = timestamp in the message should reflect that.
> >> If the = nodes keep retransmitting for a longer and longer times, we =
> >> need = to consider lot more cases to handle this correctly. I do not =
> >> know, = what issues you are Suresh are foreseeing, when a message is =
> >> = retransmitted with a new timestamp. If there is an issue that you =
> >> see, = then we can try to fix this logic.
> = >>
>

_______________________________________________
netlmm mailing = list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm

------_=_NextPart_001_01C80130.7A180B2E-- --===============0750445914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0750445914==-- From netlmm-bounces@ietf.org Thu Sep 27 14:02:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaxga-00026d-Bv; Thu, 27 Sep 2007 14:02:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaxgY-0001r8-UM for netlmm@ietf.org; Thu, 27 Sep 2007 14:02:03 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaxgY-000188-7y for netlmm@ietf.org; Thu, 27 Sep 2007 14:02:02 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8RI13Hp013576; Thu, 27 Sep 2007 20:01:03 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 27 Sep 2007 20:01:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Thu, 27 Sep 2007 20:01:09 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399ADA@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: Acf/sdrXSWxVJRmzQ6G5BsvD3b9qQQAKS7SgAAzXM0AAQwyTcA== References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> From: "DE JUAN HUARTE FEDERICO" To: "Kilian Weniger" X-OriginalArrivalTime: 27 Sep 2007 18:01:50.0307 (UTC) FILETIME=[7A5D9330:01C80130] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Killian, I had been told that this problem was out of scope ... >From your input: Killian> Hence, after receiving one or more such notifications, the LMA = can identify the compromised MAG and stop trusting this MAG. How does the LMA identify the compromised MAG? Regards federico -----Message d'origine----- De : Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 Envoy=E9 : mercredi 26 septembre 2007 10:57 =C0 : Narayanan, Vidya Cc : netlmm@ietf.org Objet : Compromised MAG issue (was [netlmm] Review = ofdraft-ietf-netlmm-proxymip6-05) Narayanan, Vidya wrote: > > > - Security considerations: MAG Compromise:=20 ... > If we claim this is an issue in the security considerations section=20 > and claim that the fix to it is for the LMA to ensure the MN is=20 > actually attached to the MAG, we can't quite hand wave on some=20 > possible ways to do that. Those are just hints for deployments that=20 > are concerned about MAG compromise. But, those hints need to be=20 > captured in the security considerations section. The threats document = > captures this threat and it is a valid one - so, I believe we need=20 > some text here. The type of "detail" is what I tried to provide with=20 > the examples on AAA checks or CGA signatures - and, I don't think we=20 > need a lot of detail here; a few sentences would be good. >=20 I had a similar comment a while ago. I think that a draft describing a severe security issue should at least give hints how this can be solved. Recently Sri, Vijay, Kuntal and I had an offline discussion about another possible solution to detect a compromised MAGs, which relies on PMIP signaling only. The basic idea is that if two MAGs simultaneously claim that the MN is attached, one of the MAGs must lie and is probably a compromised MAG. The assumption is that the MN cannot at the same time be attached to two MAGs, at least not with the same network interface. More specifically, when the LMA accepts a valid PBU from a new MAG, it changes the BCE (i.e., there is no impact on handover delay) and notifies the old MAG (i.e., old address in BCE) about this. The old MAG then checks whether the MN is still attached. If this is the case, it informs the LMA about this. The LMA then learns that two different MAGs claim MN attachement, which is not possible under the assumption stated above. Hence, after receiving one or more such notifications, the LMA can identify the compromised MAG and stop trusting this MAG. A remaining problem was which message should be used to inform the old MAG about the BCE change. PBA and revocation msg were discussed, but the former is not sent unsolicited according to RFC3775 (which could be overidden by PMIP spec of course) and the latter is not standardized yet. Comments? Kilian Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 14:52:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayTY-00053P-Ih; Thu, 27 Sep 2007 14:52:40 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IayTW-00052r-UK for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 14:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayTW-0004SC-Kl for netlmm@ietf.org; Thu, 27 Sep 2007 14:52:38 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IayT6-0007hB-AS for netlmm@ietf.org; Thu, 27 Sep 2007 14:52:17 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8RIplb10429; Thu, 27 Sep 2007 18:51:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 13:51:47 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6E7C@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAFIfSQACUu5w From: "Mohamed Khalil" To: "Basavaraj Patil" , "ext Narayanan, Vidya" , "Sri Gundavelli" , "Genadi Velev" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Raj, I think an IPv6 node with unmodified IPv6 stack, should not be allowing more than one interface to configure the same address configuration or share the same onlink prefix. So the interface who tries to claim the ownership of a prefix who is assigned to another interface will shut down but not the original owner. -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Thursday, September 27, 2007 12:38 PM To: ext Narayanan, Vidya; Sri Gundavelli; Genadi Velev Cc: ext Kilian Weniger; netlmm@ietf.org Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs Vidya, Just for my education, can you please explain why the MN would shutdown both interfaces if it were to receive the same prefix on another interface on a multi-interface host? I guess I could dig up the archives... But if you can explain the issue behind such behavior, I would appreciate it. -Raj On 9/27/07 12:31 PM, "ext Narayanan, Vidya" wrote: > Sri, > You seem to be missing the point. We are not dealing with=20 > multi-interface support issues in this thread. What we are dealing=20 > with is the fact that an MN may not be able to use *any* interface=20 > simply because it happens to have two interfaces. Unless the MN knows > that the network is using PMIP and hence, it can only use one=20 > interface at a time, you are going to have regular IP nodes that run=20 > into this problem. >=20 >=20 > In a nutshell, the problem is about an MN ending up with no IP service > using even one of its interfaces. >=20 > I hope you can see that the problem doesn't relate to providing=20 > multihoming to the MN; rather it relates to something far more=20 > fundamental that this protocol is supposed to ensure - IP connectivity > to the MN. >=20 > Vidya _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 15:16:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayqP-0004et-2S; Thu, 27 Sep 2007 15:16:17 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IayqN-0004ei-LX for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 15:16:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayqN-0004ag-9q for netlmm@ietf.org; Thu, 27 Sep 2007 15:16:15 -0400 Received: from mout.perfora.net ([74.208.4.196]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IayqK-0003sk-N2 for netlmm@ietf.org; Thu, 27 Sep 2007 15:16:13 -0400 Received: from [88.233.215.25] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1IayqG0oxg-0008Ut; Thu, 27 Sep 2007 15:16:12 -0400 From: "Alper Yegin" To: "'Narayanan, Vidya'" , Subject: RE: Concluding this thread (RE: [netlmm] MN-Id overspecification) Date: Thu, 27 Sep 2007 22:15:58 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgBEpFeIwxJmZX2T92Pup85/gQyOQACNTdAAAKPQ3AABPsqUA== In-Reply-To: Message-Id: <0MKp8S-1IayqG0oxg-0008Ut@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/5Gw8Ew4Fl3CuHVqjdEQAxGxH692UYjNaad1B jCowVkOhxqmoeKJHt0MESQZkfhTs1npjvclTDSGCo+mR9MYn7R CWWScs7xDCGDBcHTBeOgQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vidya, Aren't you jumping the gun too soon? - 3 people (Alper, Alex, Vidya) agree document is specifying something that is not needed. - 5 people (Ahmad, Raj, Vijay, Kuntal, Sri) have a spectrum of positions varying between objecting to trying to understand. - Thread has not been going on for too long or anything - People in the WG are still struggling with the use of MN-id and what is in MN-id in fact. Besides, I'm not getting any solid technical reasons why the proposal should be rejected. Can you summarize it?? " prefer that the procedures for all the PBU/PBA signaling be similar where possible" is such a weak reason. Do you think aesthetic look of packets are more important than getting in the way of some deployment possibilities? Alper Alper Samsung > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Thursday, September 27, 2007 7:51 PM > To: netlmm@ietf.org > Subject: Concluding this thread (RE: [netlmm] MN-Id overspecification) > > All, > > > > I think this discussion has gone on long enough and is now getting into > the same points again. The discussion of Auth protocol in this thread > at the moment is not useful. The WG is not working on that and we > really don't have the bandwidth to spend on that right now. > > >From the various points I've seen, it appears like the MN-ID may not be > technically needed in all the messages, but, also, there doesn't seem to > be anything technically wrong with the inclusion of it. It also appears > that most people prefer that the procedures for all the PBU/PBA > signaling be similar where possible and hence, prefer keeping the MN-ID > in all the messages. > > I note that Alper, Alex and I* (to some extent) prefer to keep it out of > messages that don't need it, but, I don't see anyone else agreeing with > that viewpoint. So, let's move on with the conclusion that we leave the > MN-ID in the messaging as specified in the document now. > > > > Thanks, > Vidya > > > > * Although I was saying that we can keep the MN-ID out of messages that > don't need it, I don't have a strong preference. It is not a technical > showstopper and so, I'm fine with moving on with the preference of the > WG. > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 15:17:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayrQ-0005cD-Eg; Thu, 27 Sep 2007 15:17:20 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IayrP-0005b1-Uf for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 15:17:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayrP-0005as-Ih for netlmm@ietf.org; Thu, 27 Sep 2007 15:17:19 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IayrP-0003v0-2u for netlmm@ietf.org; Thu, 27 Sep 2007 15:17:19 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8RJHCQ01010; Thu, 27 Sep 2007 19:17:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 14:16:51 -0500 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F6E7E@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F6E7C@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAFIfSQACUu5wAAENQMA= From: "Mohamed Khalil" To: "Mohamed Khalil" , "Basavaraj Patil" , "ext Narayanan, Vidya" , "Sri Gundavelli" , "Genadi Velev" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Raj, Q to u, how MIP6 handle the issue of multihoming?=20 -----Original Message----- From: Khalil, Mohamed (RICH2:2S20)=20 Sent: Thursday, September 27, 2007 1:52 PM To: Basavaraj Patil; ext Narayanan, Vidya; Sri Gundavelli; Genadi Velev Cc: ext Kilian Weniger; netlmm@ietf.org Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Hi Raj, I think an IPv6 node with unmodified IPv6 stack, should not be allowing more than one interface to configure the same address configuration or share the same onlink prefix. So the interface who tries to claim the ownership of a prefix who is assigned to another interface will shut down but not the original owner. -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Thursday, September 27, 2007 12:38 PM To: ext Narayanan, Vidya; Sri Gundavelli; Genadi Velev Cc: ext Kilian Weniger; netlmm@ietf.org Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs Vidya, Just for my education, can you please explain why the MN would shutdown both interfaces if it were to receive the same prefix on another interface on a multi-interface host? I guess I could dig up the archives... But if you can explain the issue behind such behavior, I would appreciate it. -Raj On 9/27/07 12:31 PM, "ext Narayanan, Vidya" wrote: > Sri, > You seem to be missing the point. We are not dealing with > multi-interface support issues in this thread. What we are dealing=20 > with is the fact that an MN may not be able to use *any* interface=20 > simply because it happens to have two interfaces. Unless the MN knows > that the network is using PMIP and hence, it can only use one > interface at a time, you are going to have regular IP nodes that run=20 > into this problem. >=20 >=20 > In a nutshell, the problem is about an MN ending up with no IP service > using even one of its interfaces. >=20 > I hope you can see that the problem doesn't relate to providing > multihoming to the MN; rather it relates to something far more=20 > fundamental that this protocol is supposed to ensure - IP connectivity > to the MN. >=20 > Vidya _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 15:19:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaytt-000134-38; Thu, 27 Sep 2007 15:19:53 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Iayts-00012v-Gx for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 15:19:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iayts-00012i-69 for netlmm@ietf.org; Thu, 27 Sep 2007 15:19:52 -0400 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iaytr-0003yc-Og for netlmm@ietf.org; Thu, 27 Sep 2007 15:19:52 -0400 Received: from [88.233.215.25] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1Iaytj3R4h-0008Jv; Thu, 27 Sep 2007 15:19:49 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 22:19:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgBG9idi5HpOFniRVeGzBKc7DuQ/gAHyU5g In-Reply-To: <46FBCD6A.8030401@azairenet.com> Message-Id: <0MKp8S-1Iaytj3R4h-0008Jv@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/DFtvNu8Q6AkZ3nAXGqGlYP/7WC+I9UWR2WwA pTW4c+ccUk7AvdeVpa5dvtuRp2eFt5y7MtTgzAyOKjjbNyDLnD gM51eMevEfDab1JJgqQuw== X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > The sequence would be as follows for your scenario (assuming your > scenario is to allocate HNP during access authentication) > > - MN does access authentication > - AAA server sends the HNP for the MN to the MAG > - MAG sends a proxy BU with the MN-ID and the HNP to the LMA > - LMA checks if the MN-ID is authorized for the HNP (with AAA's help) Yes. > > Note that I completely disagree with the AAA server assigning the HNP. I > would like HNP assignment always coming from the LMA. If you prefer that in your deployments, fine by me. But if you somehow want to force any IETF spec to limit deployments in that way, we need to discuss that. > >> Alper, frankly I think you need to show why including the MN-ID in the > >> proxy BU is a bad idea. If there is no issue, lets move on. > > > > Frankly, I did show it on the ML twice already. And yet to see why it is > > useful (other than for the HNP assignment case). > > With 4285? That was hardly convincing. Sorry. Do you have any technical feedback, or is it just that you don't feel like being convinced? Alper > > Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 15:24:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iayyc-0007Uj-UH; Thu, 27 Sep 2007 15:24:46 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Iayyb-0007G9-Nh for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 15:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iayyb-0007Bt-AX for netlmm@ietf.org; Thu, 27 Sep 2007 15:24:45 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IayyW-0008UK-0N for netlmm@ietf.org; Thu, 27 Sep 2007 15:24:45 -0400 Received: from [88.233.215.25] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1IayyJ33b8-0007TD; Thu, 27 Sep 2007 15:24:33 -0400 From: "Alper Yegin" To: "'Basavaraj Patil'" , "'Ahmad Muhanna'" , Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 22:24:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AABDcQjgAd8sdwABWfzR0AAxxBYA== In-Reply-To: Message-Id: <0MKpCa-1IayyJ33b8-0007TD@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19u2RfmZDWHQxMQJReIPmleBAro4lmyQcr+PQH 6fJ5ADPmPXYOCVH+G0lkPlPxIB4ZCRQwC3xF4Sdl43MnYc+E6V M3JW4AI5FljrTL3m2Xaeg== X-Spam-Score: -0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Raj, > >> What is the downside of including the MN-ID in all the MAG/LMA > messages? > >> Does it break anything? > > > > As I had explained earlier, one way to deploy PMIP is to use RFC 4285 > with > > per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In that case, > HNP > > can be assigned during network access authentication (so, we no longer > need > > to convey the id of the "MN" in-band with PMIP), but we need to convey > the > > id of the "proxy-MN (MAG)" for PMIP security. > > To use RFC4285 for PMIP6, you will need to specify how this is used. I > think > Sri stated something similarly that the extensions needed in PMIP6 > messages > for using 4285 cannot be simply used as is. I responded to Sri (I don't see why "cannot"). > > > > > That scenario breaks when we unnecessarily force the protocol to always > > carry "MN"-id. > > I don't think it breaks. Having MN-ID in addition to another parameter > should solve your issue. Will respond via Federico's email. > > > > > Even without this I could be arguing against this overspecification > based on > > lack of need and uncertainty around what to put in MN-id. > > Lack of need in subsequent messages is what I think you are refering to > and Yes. > that seems to be the general view. An example of what the MN-ID possibly > is, > is given in the ID, i.e the NAI. Any other ID types can be used but will > need to be registered in IANA. You mean the NAI used during the network access authentication? By now it is understood that does not work. NAI may lack uniqueness (e.g., just realm used w/o username), or change from one auth to another. It's such an unstable non-unique id. Alper > > -Raj > > > > > Alper > > > > > > > >> You say that it "is an overspecification, reducing flexibility and > >> getting in the ways of various deployment scenarios"... > >> > >> How is it becoming an obstacle in any deployment scenario? > >> > >> I am just wondering if you are optimizing the protocol by not including > >> the > >> MN-ID or if you see this as actually being a problem. > >> > >> -Raj > >> > >> > >> On 9/26/07 11:58 AM, "ext Alper Yegin" wrote: > >> > >>> Ahmad, > >>> > >>>> In case that a HNP is available at the MAG (how: out-of-scope) and > >>>> included in the initial P-BU, ... > >>> > >>> ... MAG is not required to include an NAI option that carries the > >>> MN-identifier. > >>> > >>> In the spec, all we need to say is "MN-Identifier MUST be included in > >> PBU > >>> when the HNP is set to 0::0/0" > >>> > >>> > >>> Alper > >>> > >>> > >>> > >>> NO NAI or any other IDs related to the MN > >>>> should be included? > >>>> > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >>>>> Sent: Wednesday, September 26, 2007 7:35 AM > >>>>> To: netlmm@ietf.org > >>>>> Subject: [netlmm] MN-Id overspecification > >>>>> > >>>>> This issue is still hanging. > >>>>> > >>>>> So far as I understand the MN-Id is only used for performing > >>>>> HNP assignment in-band with PMIP6 signaling. In case HNP is > >>>>> already assigned, there is no need to be carrying any info > >>>>> that directly or indirectly points to the MN's identity. > >>>>> > >>>>> But on the other hand, MN-id is all over the spec with > >>>>> normative languages that suggest it be present in every message. > >>>>> > >>>>> This is an overspecification, reducing flexibility and > >>>>> getting in the ways of various deployment scenarios. > >>>>> > >>>>> I recommend we change the spec such that MN-id is only > >>>>> mandated when HNP needs to be assigned. > >>>>> > >>>>> Would there be an objection to that? Is there any technical > >>>>> reason to carry an identifier of the MN in every PMIP6 message? > >>>>> > >>>>> > >>>>> Alper > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>> > >>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 15:31:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaz51-00064o-CI; Thu, 27 Sep 2007 15:31:23 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Iaz4z-00062z-Go for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 15:31:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaz4z-00062h-6K for netlmm@ietf.org; Thu, 27 Sep 2007 15:31:21 -0400 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iaz4x-0000F4-Sj for netlmm@ietf.org; Thu, 27 Sep 2007 15:31:21 -0400 Received: from [88.233.215.25] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Iaz4i3RPt-0007SO; Thu, 27 Sep 2007 15:31:08 -0400 From: "Alper Yegin" To: "'DE JUAN HUARTE FEDERICO'" Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 22:30:55 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AABDcQjgAd8sdwAAhTU2AAEJFzsA== In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399AD4@FRVELSMBS12.ad2.ad.alcatel.com> Message-Id: <0MKpCa-1Iaz4i3RPt-0007SO@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19vv3HmFqEcYH0Y554Mpa5lAaTM896w0PHC6gW idfzjY65hNr5+fVKNOJ+HCd5r2FMoscHtPBKza49i+t/jr6M0q WMmmGma1l5fxYt52ssUkQ== X-Spam-Score: -0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, > I don't quite understand why the security solution you advocate for is > exclusive with in-band HNP assignment > If I've understood clearly what you're trying to enable, I wonder if = it > would suit you to have 2 NAIs: MN-NAI and MAG-NAI > Then you could specify that the MAG-NAI is the one to be used for 4285 > purposes (wherever this is defined) Raj and Ahmad also suggested that. The problem is, RFC 4285 does not accommodate that. It expects the identifier be in "MN-NAI mobility option as defined in [RFC4283]". If = PMIP6 spec uses a suboption type other than type 1 (MN-NAI) then it works. Otherwise this breaks RFC 4285.=20 Alper >=20 > Regards >=20 > federico >=20 >=20 > -----Message d'origine----- > De : Alper Yegin [mailto:alper.yegin@yegin.org] > Envoy=E9 : jeudi 27 septembre 2007 09:37 > =C0 : 'Basavaraj Patil'; 'Ahmad Muhanna'; netlmm@ietf.org > Objet : RE: [netlmm] MN-Id overspecification >=20 > Raj, >=20 > > What is the downside of including the MN-ID in all the MAG/LMA = messages? > > Does it break anything? >=20 > As I had explained earlier, one way to deploy PMIP is to use RFC 4285 = with > per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In that = case, > HNP can be assigned during network access authentication (so, we no = longer > need to convey the id of the "MN" in-band with PMIP), but we need to > convey the id of the "proxy-MN (MAG)" for PMIP security. >=20 > That scenario breaks when we unnecessarily force the protocol to = always > carry "MN"-id. >=20 > Even without this I could be arguing against this overspecification = based > on lack of need and uncertainty around what to put in MN-id. >=20 > Alper >=20 >=20 >=20 > > You say that it "is an overspecification, reducing flexibility and > > getting in the ways of various deployment scenarios"... > > > > How is it becoming an obstacle in any deployment scenario? > > > > I am just wondering if you are optimizing the protocol by not > > including the MN-ID or if you see this as actually being a problem. > > > > -Raj > > > > > > On 9/26/07 11:58 AM, "ext Alper Yegin" = wrote: > > > > > Ahmad, > > > > > >> In case that a HNP is available at the MAG (how: out-of-scope) = and > > >> included in the initial P-BU, ... > > > > > > ... MAG is not required to include an NAI option that carries the > > > MN-identifier. > > > > > > In the spec, all we need to say is "MN-Identifier MUST be included > > > in > > PBU > > > when the HNP is set to 0::0/0" > > > > > > > > > Alper > > > > > > > > > > > > NO NAI or any other IDs related to the MN > > >> should be included? > > >> > > >> > > >> Regards, > > >> Ahmad > > >> > > >> > > >>> -----Original Message----- > > >>> From: Alper Yegin [mailto:alper.yegin@yegin.org] > > >>> Sent: Wednesday, September 26, 2007 7:35 AM > > >>> To: netlmm@ietf.org > > >>> Subject: [netlmm] MN-Id overspecification > > >>> > > >>> This issue is still hanging. > > >>> > > >>> So far as I understand the MN-Id is only used for performing HNP > > >>> assignment in-band with PMIP6 signaling. In case HNP is already > > >>> assigned, there is no need to be carrying any info that directly > > >>> or indirectly points to the MN's identity. > > >>> > > >>> But on the other hand, MN-id is all over the spec with normative > > >>> languages that suggest it be present in every message. > > >>> > > >>> This is an overspecification, reducing flexibility and getting = in > > >>> the ways of various deployment scenarios. > > >>> > > >>> I recommend we change the spec such that MN-id is only mandated > > >>> when HNP needs to be assigned. > > >>> > > >>> Would there be an objection to that? Is there any technical = reason > > >>> to carry an identifier of the MN in every PMIP6 message? > > >>> > > >>> > > >>> Alper > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> netlmm mailing list > > >>> netlmm@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > >>> > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 16:12:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iazhg-0000vg-0S; Thu, 27 Sep 2007 16:11:20 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Iazhf-0000qX-1k for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 16:11:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iazhe-0000jn-Kv for netlmm@ietf.org; Thu, 27 Sep 2007 16:11:18 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iazha-0005S1-0R for netlmm@ietf.org; Thu, 27 Sep 2007 16:11:14 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8RKB02S008659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Sep 2007 13:11:01 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8RKB0rZ019868; Thu, 27 Sep 2007 13:11:00 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 13:11:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Thu, 27 Sep 2007 13:10:58 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAFIfSQAFTWoQ References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Sri Gundavelli" , "Genadi Velev" X-OriginalArrivalTime: 27 Sep 2007 20:11:00.0130 (UTC) FILETIME=[859EB820:01C80142] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Raj, In the example I wrote, the MN doesn't shut down both its interfaces. It thinks Interface 1 is operational and has shutdown Interface 2 due to a duplicate address. However, the LMA only has a binding corresponding to Interface 2 - so, the fact that the MN thinks it can use Interface 1 is not useful, since it really cannot send/receive any packets through it. As a result, the MN has no IP connectivity.=20 Hope that clarifies.=20 Vidya=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Thursday, September 27, 2007 10:38 AM > To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev > Cc: ext Kilian Weniger; netlmm@ietf.org > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 >=20 > Vidya, >=20 > Just for my education, can you please explain why the MN=20 > would shutdown both interfaces if it were to receive the same=20 > prefix on another interface on a multi-interface host? > I guess I could dig up the archives... But if you can explain=20 > the issue behind such behavior, I would appreciate it. >=20 > -Raj >=20 >=20 > On 9/27/07 12:31 PM, "ext Narayanan, Vidya"=20 > wrote: >=20 > > Sri, > > You seem to be missing the point. We are not dealing with=20 > > multi-interface support issues in this thread. What we are dealing=20 > > with is the fact that an MN may not be able to use *any* interface=20 > > simply because it happens to have two interfaces. Unless=20 > the MN knows=20 > > that the network is using PMIP and hence, it can only use one=20 > > interface at a time, you are going to have regular IP nodes=20 > that run into this problem. > >=20 > >=20 > > In a nutshell, the problem is about an MN ending up with no=20 > IP service=20 > > using even one of its interfaces. > >=20 > > I hope you can see that the problem doesn't relate to providing=20 > > multihoming to the MN; rather it relates to something far more=20 > > fundamental that this protocol is supposed to ensure - IP=20 > connectivity=20 > > to the MN. > >=20 > > Vidya >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 16:14:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazkX-0005Jw-Tu; Thu, 27 Sep 2007 16:14:17 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IazkW-0005JK-Dh for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 16:14:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazkW-0005GE-1u for netlmm@ietf.org; Thu, 27 Sep 2007 16:14:16 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IazkV-0005Vt-Cq for netlmm@ietf.org; Thu, 27 Sep 2007 16:14:15 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8RKEEY7008899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Sep 2007 13:14:14 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8RKED8F000516; Thu, 27 Sep 2007 13:14:13 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Sep 2007 13:14:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Concluding this thread (RE: [netlmm] MN-Id overspecification) Date: Thu, 27 Sep 2007 13:14:11 -0700 Message-ID: In-Reply-To: <0MKp8S-1IayqG0oxg-0008Ut@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Concluding this thread (RE: [netlmm] MN-Id overspecification) Thread-Index: AcgBEpFeIwxJmZX2T92Pup85/gQyOQACNTdAAAKPQ3AABPsqUAACP5Aw References: <0MKp8S-1IayqG0oxg-0008Ut@mrelay.perfora.net> From: "Narayanan, Vidya" To: "Alper Yegin" , X-OriginalArrivalTime: 27 Sep 2007 20:14:13.0230 (UTC) FILETIME=[F8B770E0:01C80142] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper, I'm making an observation based on two aspects - 1. we seem to be revisiting the same discussion points again; 2. this is now becoming an Auth protocol discussion, which is not the current focus of the group. =20 Also, please note that I mentioned I'm fine with the approach of keeping the MN-ID, given all the discussions. So, I really see only you and Alex objecting at this point. Please also note that Alex drew attention to the fact that he is not intending to discuss the Auth protocol here. A digression on the Auth protocol discussion is not useful at the moment. We need to make progress on the open issues at hand and progress the document.=20 Thanks, Vidya > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Thursday, September 27, 2007 12:16 PM > To: Narayanan, Vidya; netlmm@ietf.org > Subject: RE: Concluding this thread (RE: [netlmm] MN-Id=20 > overspecification) >=20 > Vidya, >=20 > Aren't you jumping the gun too soon? >=20 > - 3 people (Alper, Alex, Vidya) agree document is specifying=20 > something that is not needed. > - 5 people (Ahmad, Raj, Vijay, Kuntal, Sri) have a spectrum=20 > of positions varying between objecting to trying to understand. > - Thread has not been going on for too long or anything > - People in the WG are still struggling with the use of MN-id=20 > and what is in MN-id in fact. >=20 > Besides, I'm not getting any solid technical reasons why the=20 > proposal should be rejected. Can you summarize it?? >=20 > " prefer that the procedures for all the PBU/PBA signaling be=20 > similar where possible" is such a weak reason. Do you think=20 > aesthetic look of packets are more important than getting in=20 > the way of some deployment possibilities? >=20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Alper > Samsung=20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Thursday, September 27, 2007 7:51 PM > > To: netlmm@ietf.org > > Subject: Concluding this thread (RE: [netlmm] MN-Id=20 > overspecification) > >=20 > > All, > >=20 > > > >=20 > > I think this discussion has gone on long enough and is now getting=20 > > into the same points again. The discussion of Auth=20 > protocol in this=20 > > thread at the moment is not useful. The WG is not working=20 > on that and=20 > > we really don't have the bandwidth to spend on that right now. > >=20 > > >From the various points I've seen, it appears like the=20 > MN-ID may not=20 > > >be > > technically needed in all the messages, but, also, there=20 > doesn't seem=20 > > to be anything technically wrong with the inclusion of it. It also=20 > > appears that most people prefer that the procedures for all the=20 > > PBU/PBA signaling be similar where possible and hence,=20 > prefer keeping=20 > > the MN-ID in all the messages. > >=20 > > I note that Alper, Alex and I* (to some extent) prefer to=20 > keep it out=20 > > of messages that don't need it, but, I don't see anyone=20 > else agreeing=20 > > with that viewpoint. So, let's move on with the conclusion that we=20 > > leave the MN-ID in the messaging as specified in the document now. > >=20 > > > >=20 > > Thanks, > > Vidya > >=20 > > > >=20 > > * Although I was saying that we can keep the MN-ID out of messages=20 > > that don't need it, I don't have a strong preference. It is not a=20 > > technical showstopper and so, I'm fine with moving on with the=20 > > preference of the WG. > >=20 > > > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 16:46:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0E5-0005ZA-OJ; Thu, 27 Sep 2007 16:44:49 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ib0E4-0005Z4-Rz for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 16:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0E4-0005Yw-IC for netlmm@ietf.org; Thu, 27 Sep 2007 16:44:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib0E3-0001xJ-By for netlmm@ietf.org; Thu, 27 Sep 2007 16:44:48 -0400 X-IronPort-AV: E=Sophos;i="4.21,204,1188802800"; d="scan'208";a="226486160" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 27 Sep 2007 13:44:46 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8RKikm0011604; Thu, 27 Sep 2007 13:44:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8RKig1v014530; Thu, 27 Sep 2007 20:44:46 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 13:44:42 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 13:44:42 -0700 From: "Sri Gundavelli" To: "'Alper Yegin'" , "'DE JUAN HUARTE FEDERICO'" References: <319D54578EAC3147BA8CC78DAB5467A501399AD4@FRVELSMBS12.ad2.ad.alcatel.com> <0MKpCa-1Iaz4i3RPt-0007SO@mrelay.perfora.net> Subject: RE: [netlmm] MN-Id overspecification Date: Thu, 27 Sep 2007 13:44:42 -0700 Message-ID: <011001c80147$3afacd40$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0MKpCa-1Iaz4i3RPt-0007SO@mrelay.perfora.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAOaGP7OMO7uECTYSkP0wO0ExJKAAEBBNgAAGFy4AABDcQjgAd8sdwAAhTU2AAEJFzsAACoq2w X-OriginalArrivalTime: 27 Sep 2007 20:44:42.0236 (UTC) FILETIME=[3AE39BC0:01C80147] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=749; t=1190925886; x=1191789886; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20MN-Id=20overspecification |Sender:=20; bh=Q8songG3rdtF/5f89dYpEBAzD5LJ2g2RwpVEKZexoXY=; b=Cq8dSH2fZd/aQwh5/VEdX715x9UT12lJxaem2Kr1RPePh20GQ4XFGBrXb7gd3hh7FtaoS/Zj vhiEtxgRyXAHpPxUFqlWrFos0+mchkd2F8F3ciA51o9mTgpBWhQ7ZbPItVPBORFOP3aF+l952u +pA0tqjkF3zAt3URSofdsrKuc=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Alper, > > Raj and Ahmad also suggested that. > > The problem is, RFC 4285 does not accommodate that. It expects the > identifier be in "MN-NAI mobility option as defined in > [RFC4283]". If PMIP6 > spec uses a suboption type other than type 1 (MN-NAI) then it works. > Otherwise this breaks RFC 4285. > If you use Auth Option in PBU/PBA's, you will break PMIP6. The options are not defined for PBU/PBA's. No guidance on how LMA interpret that option. If you use MN-NAI, it will break 4285. Either case, to use 4285, you will have to break one of them. On a lighter note, I'd say, you should break 4285. It is broken any ways. I really think what Federico/Ahmad suggesting is ok. Small deviation from 4285. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 17:59:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib1Nt-0003cy-II; Thu, 27 Sep 2007 17:59:01 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ib1Ns-0003cs-79 for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 17:59:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib1Nr-0003bd-Qq for netlmm@ietf.org; Thu, 27 Sep 2007 17:58:59 -0400 Received: from mout.perfora.net ([74.208.4.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib1Nr-00089p-5L for netlmm@ietf.org; Thu, 27 Sep 2007 17:58:59 -0400 Received: from [88.233.215.25] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Ib1Nm2RVY-0007Xb; Thu, 27 Sep 2007 17:58:58 -0400 From: "Alper Yegin" To: "'Narayanan, Vidya'" , Subject: RE: Concluding this thread (RE: [netlmm] MN-Id overspecification) Date: Fri, 28 Sep 2007 00:58:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-index: AcgBEpFeIwxJmZX2T92Pup85/gQyOQACNTdAAAKPQ3AABPsqUAACP5AwAAMuw9A= In-Reply-To: Message-Id: <0MKpCa-1Ib1Nm2RVY-0007Xb@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19QBX6GY6KLk7AXnPn7EgUoJEQYpYPx7UQhNO6 ghNsQToG80fAYYKMgNbanV5AfNTGgbZbeOATl8gC+28HQBvxHH LfXjqAtGsfrR8oYFrBnWw== X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vidya, I don't know why auth protocol is such a taboo. If it is so bad, why is IETF even trying to revise it? Rather than introducing artificial constraints against it, IETF should do something more meaningful. Note that WiMAX Forum R1.0 is using that for MIP6. ... No part of the proposal is meant to cause additional work to the WG for supporting RFC 4285, despite how you framed it in your e-mail. In fact, not cleaning the overspecification part prevents a RFC 4285-based deployment scenario. Why do we want to do that? You may be fine with keeping the extra mandates, but you also agreed it is not necessary to keep them. Unless people want to block an RFC 4285-based scenario, I see there is no technical justification to keep them. If you really want to close this thread as a chair, I appreciate if you can summarize the technical justifications to keep the current constraints in the document despite its unintended(?) consequences. Alper > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Thursday, September 27, 2007 11:14 PM > To: Alper Yegin; netlmm@ietf.org > Subject: RE: Concluding this thread (RE: [netlmm] MN-Id overspecification) > > Alper, > I'm making an observation based on two aspects - 1. we seem to be > revisiting the same discussion points again; 2. this is now becoming an > Auth protocol discussion, which is not the current focus of the group. > > Also, please note that I mentioned I'm fine with the approach of keeping > the MN-ID, given all the discussions. So, I really see only you and > Alex objecting at this point. Please also note that Alex drew attention > to the fact that he is not intending to discuss the Auth protocol here. > > > A digression on the Auth protocol discussion is not useful at the > moment. We need to make progress on the open issues at hand and > progress the document. > > Thanks, > Vidya > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Thursday, September 27, 2007 12:16 PM > > To: Narayanan, Vidya; netlmm@ietf.org > > Subject: RE: Concluding this thread (RE: [netlmm] MN-Id > > overspecification) > > > > Vidya, > > > > Aren't you jumping the gun too soon? > > > > - 3 people (Alper, Alex, Vidya) agree document is specifying > > something that is not needed. > > - 5 people (Ahmad, Raj, Vijay, Kuntal, Sri) have a spectrum > > of positions varying between objecting to trying to understand. > > - Thread has not been going on for too long or anything > > - People in the WG are still struggling with the use of MN-id > > and what is in MN-id in fact. > > > > Besides, I'm not getting any solid technical reasons why the > > proposal should be rejected. Can you summarize it?? > > > > " prefer that the procedures for all the PBU/PBA signaling be > > similar where possible" is such a weak reason. Do you think > > aesthetic look of packets are more important than getting in > > the way of some deployment possibilities? > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > Alper > > Samsung > > > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Thursday, September 27, 2007 7:51 PM > > > To: netlmm@ietf.org > > > Subject: Concluding this thread (RE: [netlmm] MN-Id > > overspecification) > > > > > > All, > > > > > > > > > > > > I think this discussion has gone on long enough and is now getting > > > into the same points again. The discussion of Auth > > protocol in this > > > thread at the moment is not useful. The WG is not working > > on that and > > > we really don't have the bandwidth to spend on that right now. > > > > > > >From the various points I've seen, it appears like the > > MN-ID may not > > > >be > > > technically needed in all the messages, but, also, there > > doesn't seem > > > to be anything technically wrong with the inclusion of it. It also > > > appears that most people prefer that the procedures for all the > > > PBU/PBA signaling be similar where possible and hence, > > prefer keeping > > > the MN-ID in all the messages. > > > > > > I note that Alper, Alex and I* (to some extent) prefer to > > keep it out > > > of messages that don't need it, but, I don't see anyone > > else agreeing > > > with that viewpoint. So, let's move on with the conclusion that we > > > leave the MN-ID in the messaging as specified in the document now. > > > > > > > > > > > > Thanks, > > > Vidya > > > > > > > > > > > > * Although I was saying that we can keep the MN-ID out of messages > > > that don't need it, I don't have a strong preference. It is not a > > > technical showstopper and so, I'm fine with moving on with the > > > preference of the WG. > > > > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 21:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib4dg-00082z-Oj; Thu, 27 Sep 2007 21:27:32 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ib4de-000818-RS for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 21:27:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib4de-0007uZ-Hc for netlmm@ietf.org; Thu, 27 Sep 2007 21:27:30 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ib4dU-0007pD-DZ for netlmm@ietf.org; Thu, 27 Sep 2007 21:27:25 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007092721270424187 ; Thu, 27 Sep 2007 21:27:04 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.258,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.24.113.74]) by s-utl02-atpop.stsn.net; Thu, 27 Sep 2007 21:27:02 -0400 Message-ID: <46FC5857.90408@azairenet.com> Date: Thu, 27 Sep 2007 18:26:47 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [netlmm] MN-Id overspecification References: <0MKp8S-1Iaytj3R4h-0008Jv@mrelay.perfora.net> In-Reply-To: <0MKp8S-1Iaytj3R4h-0008Jv@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alper Yegin wrote: > >> The sequence would be as follows for your scenario (assuming your >> scenario is to allocate HNP during access authentication) >> >> - MN does access authentication >> - AAA server sends the HNP for the MN to the MAG >> - MAG sends a proxy BU with the MN-ID and the HNP to the LMA >> - LMA checks if the MN-ID is authorized for the HNP (with AAA's help) > > Yes. If you agree with the above, it means the LMA needs to have the MN-ID when the proxy BU is processed. Does this not mean, it is carried in the proxy BU. >> Note that I completely disagree with the AAA server assigning the HNP. I >> would like HNP assignment always coming from the LMA. > > If you prefer that in your deployments, fine by me. But if you somehow want > to force any IETF spec to limit deployments in that way, we need to discuss > that. You can of course disagree. >>>> Alper, frankly I think you need to show why including the MN-ID in the >>>> proxy BU is a bad idea. If there is no issue, lets move on. >>> Frankly, I did show it on the ML twice already. And yet to see why it is >>> useful (other than for the HNP assignment case). >> With 4285? That was hardly convincing. Sorry. > > Do you have any technical feedback, or is it just that you don't feel like > being convinced? Hard to give technical feedback on something that is not technically convincing. :) Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 22:28:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib5a2-0000gW-Aw; Thu, 27 Sep 2007 22:27:50 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ib5a1-0000gQ-DC for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 22:27:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib5a1-0000WI-39 for netlmm@ietf.org; Thu, 27 Sep 2007 22:27:49 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ib5Zs-00064h-L2 for netlmm@ietf.org; Thu, 27 Sep 2007 22:27:40 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007092722273814316 ; Thu, 27 Sep 2007 22:27:38 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.091,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.24.113.74]) by s-utl01-atpop.stsn.net; Thu, 27 Sep 2007 22:27:38 -0400 Message-ID: <46FC6689.4020304@azairenet.com> Date: Thu, 27 Sep 2007 19:27:21 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [netlmm] MN-Id overspecification References: <0MKpCa-1IaaDG0Esb-0007NN@mrelay.perfora.net> <46FAA143.6070407@azairenet.com> <46FAC9D0.8070604@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Narayanan, Vidya wrote: >> If the LMA did not assign the prefix for the mobile node and >> the MAG obtained it through other means, the LMA would need >> to check if the mobile node is authorized for that home >> network prefix. For example the LMA could check with the >> entity that did the allocation. >> > Given what you just said above (i.e., we can only allocate prefixes > through the LMA), how is this valid? But, let's suppose it is and the > MAG obtained the prefix from an independent entity. How can we assume > that the identity used to obtain the prefix from the independent entity > is the same as the MN-ID presented in the PBU? We do have an assumption that the identity that the mobile node used for access authentication to the MAG is the same as the identity carried in the proxy BU. > Given that we don't > define that independent mechanism of obtaining prefixes, we can't make > this assumption, right? Here we have an assumption that the "independent mechanism to obtain the prefix" is tied to access authentication. Vijay _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Thu Sep 27 23:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib6DP-0006Xh-7X; Thu, 27 Sep 2007 23:08:31 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ib6DN-0006Vk-0K for netlmm-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 23:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib6DM-0006Vc-Mx for netlmm@ietf.org; Thu, 27 Sep 2007 23:08:28 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ib6DL-0001es-I5 for netlmm@ietf.org; Thu, 27 Sep 2007 23:08:28 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007092723080724552 ; Thu, 27 Sep 2007 23:08:07 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.254,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.24.113.74]) by s-utl02-atpop.stsn.net; Thu, 27 Sep 2007 23:08:05 -0400 Message-ID: <46FC7002.9060909@azairenet.com> Date: Thu, 27 Sep 2007 20:07:46 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ext Kilian Weniger , netlmm@ietf.org, Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Narayanan, Vidya wrote: > Hi Raj, > In the example I wrote, the MN doesn't shut down both its interfaces. > It thinks Interface 1 is operational and has shutdown Interface 2 due to > a duplicate address. However, the LMA only has a binding corresponding > to Interface 2 - so, the fact that the MN thinks it can use Interface 1 > is not useful, since it really cannot send/receive any packets through > it. As a result, the MN has no IP connectivity. The above situation is recoverable. MAG2 would detect that the MN is no longer attached to it and send a de-registration proxy BU. LMA deletes the binding cache entry. Eventually MAG1 re-transmits the proxy BU and creates a new binding update at the LMA. The MN can now send/receive packets on interface 1. Having a binding revocation mechanism will help in recovering sooner. The LMA would have sent a revocation mechanism to MAG1 when MAG2 sent a proxy BU. MAG1 would check if the MN is still attached, if yes would send a proxy BU again. MAG2 won't try to send a proxy BU once the mobile node's interface 2 goes down. Vijay > > Hope that clarifies. > > Vidya > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Thursday, September 27, 2007 10:38 AM >> To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev >> Cc: ext Kilian Weniger; netlmm@ietf.org >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >> >> >> Vidya, >> >> Just for my education, can you please explain why the MN >> would shutdown both interfaces if it were to receive the same >> prefix on another interface on a multi-interface host? >> I guess I could dig up the archives... But if you can explain >> the issue behind such behavior, I would appreciate it. >> >> -Raj >> >> >> On 9/27/07 12:31 PM, "ext Narayanan, Vidya" >> wrote: >> >>> Sri, >>> You seem to be missing the point. We are not dealing with >>> multi-interface support issues in this thread. What we are dealing >>> with is the fact that an MN may not be able to use *any* interface >>> simply because it happens to have two interfaces. Unless >> the MN knows >>> that the network is using PMIP and hence, it can only use one >>> interface at a time, you are going to have regular IP nodes >> that run into this problem. >>> >>> In a nutshell, the problem is about an MN ending up with no >> IP service >>> using even one of its interfaces. >>> >>> I hope you can see that the problem doesn't relate to providing >>> multihoming to the MN; rather it relates to something far more >>> fundamental that this protocol is supposed to ensure - IP >> connectivity >>> to the MN. >>> >>> Vidya > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 01:37:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib8XE-0007Uu-7U; Fri, 28 Sep 2007 01:37:08 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ib8XA-0006wp-CK for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 01:37:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib8X9-0003tK-Fr for netlmm@ietf.org; Fri, 28 Sep 2007 01:37:03 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib8Wo-0002Rd-En for netlmm@ietf.org; Fri, 28 Sep 2007 01:36:43 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8S5aaF24128; Fri, 28 Sep 2007 05:36:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 00:36:35 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBAABg9sAAA7Ds6QAAB/OaAAAErRsA== From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Vijay Devarapalli" , "Kilian Weniger" X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org All, I sincerely do not want to debate the use of revocation for compromised MAG at the present time. I am sure that all of us are interested in getting this issue addressed properly and have it closed sooner than later. What about the following text: Current text under security consideration: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " To eliminate the threats related to a compromised mobile access gateway, this specification recommends that the local mobility anchor before accepting a Proxy Binding Update message for a given mobile node, should ensure the mobile node is definitively attached to the mobile access gateway that sent the binding registration request. " New Text: =3D=3D=3D=3D=3D=3D=3D=3D=3D " To eliminate the threats related to a compromised mobile access gateway, this specification recommends that the local mobility anchor before accepting a Proxy Binding Update message for a given mobile node, should ensure the mobile node is definitively attached to the mobile access gateway that sent the binding registration request=20 by contacting a trusted entity which tracks the MN current location,=20 e.g. AAA server. " Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Wednesday, September 26, 2007 7:41 PM > To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger > Cc: netlmm@ietf.org > Subject: RE: Compromised MAG issue (was [netlmm] Review of > draft-ietf-netlmm-proxymip6-05) >=20 > Hi Ahmad, > =20 >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Wednesday, September 26, 2007 4:12 PM > > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > > Cc: netlmm@ietf.org > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > draft-ietf-netlmm-proxymip6-05) > >=20 > > Hi Vidya, > >=20 > > Using revocation for the compromised MAG was proposed by > Kilian, et.=20 > > al. > > but I am trying to help closing the issue so please allow > me to jump > > into this debate. > >=20 > > In order for the LMA to validate the presence of the MN at > a specific > > MAG, the LMA needs to do one of the followings: > >=20 > > 1. Validate the MN identity via a MN signature carried in > the P-BU. In > > P-MIPv6 this currently is not available since the P-BU is NOT=20 > > initiated by the MN. (the most obvious option) > >=20 > > 2. Validate the MN presence via another trusted entity that > > *ALWAYS* tracks the MN current location, e.g. AAA server. > >=20 > > 3. Validate the MN presence via another trusted entity that > tracks the > > current or latest location of the MN, e.g. the previous MAG using=20 > > binding revocation as was suggested by kilian et. al. > >=20 >=20 > The LMA can't assume that the pMAG is trusted while the new MAG is the > one lying. Perhaps the MN really moved and the pMAG continues to=20 > claim it is there. Regardless of which MAG tells the LMA what, 1 or 2 > needs to occur to conclude where the MN really is and then, the LMA=20 > can determine which of the MAGs was lying. >=20 > Regards, > Vidya >=20 > > 4. may be there are other ways... > >=20 > > In case that the MN is still at pMAG and has not moved, the > pMAG can > > easily indicate that in the binding revocation acknowledgement. > >=20 > > So do not you think that should work? > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Wednesday, September 26, 2007 3:49 PM > > > To: Vijay Devarapalli; Kilian Weniger > > > Cc: netlmm@ietf.org > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > draft-ietf-netlmm-proxymip6-05) > > >=20 > > >=20 > > > A few observations here. I don't believe binding revocation > > is going > > > to solve anything here. The fundamental issue is how the LMA > > > *identifies* the compromised MAG, not how the compromised MAG is=20 > > > notified that its binding is no longer valid. Once the MAG is=20 > > > identified as compromised, a number of remedies may be taken,=20 > > > including, simply blacklisting the MAG and not accepting > > PBUs from it. =20 > > > It is not critical that the binding be revoked, because, > > the LMA has > > > already identified where the MN really is and it just > needs to use > > > that binding for data acceptance/forwarding. > > >=20 > > >=20 > > > The issue of how the LMA identifies a compromised MAG cannot be=20 > > > tackled without an independent verification of the > presence of the > > > MN at that particular MAG. So, we need to focus on > providing hints > > > on how the LMA may go about > > achieving that.=20 > > >=20 > > > Vidya > > >=20 > > > > -----Original Message----- > > > > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > > > Sent: Wednesday, September 26, 2007 11:08 AM > > > > To: Kilian Weniger > > > > Cc: Narayanan, Vidya; netlmm@ietf.org > > > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > > > draft-ietf-netlmm-proxymip6-05) > > > >=20 > > > > Kilian Weniger wrote: > > > > > Narayanan, Vidya wrote: > > > > >>>> - Security considerations: MAG Compromise:=20 > > > > > ... > > > > >> If we claim this is an issue in the security > > > > considerations section > > > > >> and claim that the fix to it is for the LMA to ensure > > the MN is > > > > >> actually attached to the MAG, we can't quite hand > wave on some > > > > >> possible ways to do that. Those are just hints for > > > > deployments that > > > > >> are concerned about MAG compromise. But, those hints > > need to be > > > > >> captured in the security considerations section. =20 > The threats > > > > >> document captures this threat and it is a valid one - so, > > > > I believe > > > > >> we need some text here. The type of "detail" is what > > I tried to > > > > >> provide with the examples on AAA checks or CGA > > > signatures - and, I > > > > >> don't think we need a lot of detail here; a few > > > sentences would be > > > > >> good. > > > > >> > > > > >=20 > > > > > I had a similar comment a while ago. I think that a draft > > > > describing a > > > > > severe security issue should at least give hints how this > > > > can be solved. > > > > >=20 > > > > > Recently Sri, Vijay, Kuntal and I had an offline > > discussion about > > > > > another possible solution to detect a compromised MAGs, > > > > which relies > > > > > on PMIP signaling only. > > > > >=20 > > > > > The basic idea is that if two MAGs simultaneously claim > > > > that the MN is > > > > > attached, one of the MAGs must lie and is probably a > > > > compromised MAG. > > > > > The assumption is that the MN cannot at the same time be > > > > attached to > > > > > two MAGs, at least not with the same network interface. > > > > >=20 > > > > > More specifically, when the LMA accepts a valid PBU from a > > > > new MAG, it > > > > > changes the BCE (i.e., there is no impact on handover > > delay) and > > > > > notifies the old MAG (i.e., old address in BCE) about > > > this. The old > > > > > MAG then checks whether the MN is still attached. If this > > > > is the case, > > > > > it informs the LMA about this. The LMA then learns that two > > > > different > > > > > MAGs claim MN attachement, which is not possible under the > > > > assumption > > > > > stated above. Hence, after receiving one or more such > > > > notifications, > > > > > the LMA can identify the compromised MAG and stop > > > trusting this MAG. > > > > >=20 > > > > > A remaining problem was which message should be used to > > > > inform the old > > > > > MAG about the BCE change. PBA and revocation msg were > > > > discussed, but > > > > > the former is not sent unsolicited according to RFC3775 > > > > (which could > > > > > be overidden by PMIP spec of course) and the latter is not=20 > > > > > standardized yet. > > > >=20 > > > > As I said in another threat, we really need to standardize the=20 > > > > revocation message from the LMA to the old MAG ASAP. > > > >=20 > > > > Vijay > > > >=20 > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 02:02:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib8ve-0005y7-QG; Fri, 28 Sep 2007 02:02:22 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ib8vd-0005xk-GD for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 02:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib8vd-0005hY-6P for netlmm@ietf.org; Fri, 28 Sep 2007 02:02:21 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib8vQ-0005bE-7m for netlmm@ietf.org; Fri, 28 Sep 2007 02:02:13 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8S61IF10762; Fri, 28 Sep 2007 06:01:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] MN-Id overspecification Date: Fri, 28 Sep 2007 01:01:17 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711704A538@zrc2hxm2.corp.nortel.com> In-Reply-To: <46FC5857.90408@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] MN-Id overspecification Thread-Index: AcgBbq/rBOC4gwqTTQi2bROAQPUCTgAJbnsg References: <0MKp8S-1Iaytj3R4h-0008Jv@mrelay.perfora.net> <46FC5857.90408@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Alper Yegin" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay, Let me add one comment below. Regards, Ahmad > Subject: Re: [netlmm] MN-Id overspecification >=20 > Alper Yegin wrote: > > =20 > >> The sequence would be as follows for your scenario (assuming your=20 > >> scenario is to allocate HNP during access authentication) > >> > >> - MN does access authentication > >> - AAA server sends the HNP for the MN to the MAG > >> - MAG sends a proxy BU with the MN-ID and the HNP to the LMA > >> - LMA checks if the MN-ID is authorized for the HNP (with=20 > AAA's help) > >=20 > > Yes. >=20 > If you agree with the above, it means the LMA needs to have=20 > the MN-ID when the proxy BU is processed. Does this not mean,=20 > it is carried in the proxy BU. [Ahmad] In case that LMA needs to contact AAA server for this authorization which is very much expected during initial registration, how the LMA would know which AAA server it needs to forward the RADIUS or DIAMETER request if P-BU ONLY has the HNP? Is there a mechanism which allows the LMA to identify the MN home AAA server based on HNP? Regards, Ahmad >=20 > >> Note that I completely disagree with the AAA server assigning the=20 > >> HNP. I would like HNP assignment always coming from the LMA. > >=20 > > If you prefer that in your deployments, fine by me. But if=20 > you somehow=20 > > want to force any IETF spec to limit deployments in that=20 > way, we need=20 > > to discuss that. >=20 > You can of course disagree. >=20 > >>>> Alper, frankly I think you need to show why including=20 > the MN-ID in=20 > >>>> the proxy BU is a bad idea. If there is no issue, lets move on. > >>> Frankly, I did show it on the ML twice already. And yet=20 > to see why=20 > >>> it is useful (other than for the HNP assignment case). > >> With 4285? That was hardly convincing. Sorry. > >=20 > > Do you have any technical feedback, or is it just that you=20 > don't feel=20 > > like being convinced? >=20 > Hard to give technical feedback on something that is not=20 > technically convincing. :) >=20 > Vijay >=20 >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 02:34:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib9R5-0003W5-C1; Fri, 28 Sep 2007 02:34:51 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ib9R3-0003W0-Tr for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 02:34:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib9R3-0003Vb-IP for netlmm@ietf.org; Fri, 28 Sep 2007 02:34:49 -0400 Received: from mxs1.siemens.at ([194.138.12.131]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib9R1-0003mj-Uf for netlmm@ietf.org; Fri, 28 Sep 2007 02:34:49 -0400 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs1.siemens.at with ESMTP id l8S6XfDt003972; Fri, 28 Sep 2007 08:33:41 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l8S6XdTh007396; Fri, 28 Sep 2007 08:33:40 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 08:33:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 08:33:38 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD6802AAC62F@zagh223a.ww300.siemens.net> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBAABg9sAAA7Ds6QAAB/OaAAAErRsAACrJ6Q References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> From: "Premec, Domagoj" To: "Ahmad Muhanna" , "Narayanan, Vidya" , "Vijay Devarapalli" , "Kilian Weniger" X-OriginalArrivalTime: 28 Sep 2007 06:33:39.0393 (UTC) FILETIME=[8179DB10:01C80199] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070928083341-0B321BB0-46ADBAAF/0-0/0-15 X-purgate-size: 9886/0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, If we have context transfer mechanism in place between MAGs, then the MN = may move to a new MAG without authentication and the AAA would not know = about the new MAG. I don't think we can assume that the AAA has an = accurate info on the MS location. domagoj > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: 28. rujan 2007 07:37 > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > Cc: netlmm > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) >=20 >=20 > All, >=20 > I sincerely do not want to debate the use of revocation for=20 > compromised MAG at the present time. I am sure that all of us=20 > are interested in getting this issue addressed properly and=20 > have it closed sooner than later. What about the following text: >=20 > Current text under security consideration: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > " > To eliminate the threats related to a compromised mobile access > gateway, this specification recommends that the local=20 > mobility anchor > before accepting a Proxy Binding Update message for a given mobile > node, should ensure the mobile node is definitively attached to the > mobile access gateway that sent the binding registration request. > " >=20 > New Text: > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > " > To eliminate the threats related to a compromised mobile access > gateway, this specification recommends that the local=20 > mobility anchor > before accepting a Proxy Binding Update message for a given mobile > node, should ensure the mobile node is definitively attached to the > mobile access gateway that sent the binding registration request=20 > by contacting a trusted entity which tracks the MN current=20 > location,=20 > e.g. AAA server. > " >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Wednesday, September 26, 2007 7:41 PM > > To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger > > Cc: netlmm@ietf.org > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > draft-ietf-netlmm-proxymip6-05) > >=20 > > Hi Ahmad, > > =20 > >=20 > > > -----Original Message----- > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > Sent: Wednesday, September 26, 2007 4:12 PM > > > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > > > Cc: netlmm@ietf.org > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > draft-ietf-netlmm-proxymip6-05) > > >=20 > > > Hi Vidya, > > >=20 > > > Using revocation for the compromised MAG was proposed by > > Kilian, et.=20 > > > al. > > > but I am trying to help closing the issue so please allow > > me to jump > > > into this debate. > > >=20 > > > In order for the LMA to validate the presence of the MN at > > a specific > > > MAG, the LMA needs to do one of the followings: > > >=20 > > > 1. Validate the MN identity via a MN signature carried in > > the P-BU. In > > > P-MIPv6 this currently is not available since the P-BU is NOT=20 > > > initiated by the MN. (the most obvious option) > > >=20 > > > 2. Validate the MN presence via another trusted entity that > > > *ALWAYS* tracks the MN current location, e.g. AAA server. > > >=20 > > > 3. Validate the MN presence via another trusted entity that > > tracks the > > > current or latest location of the MN, e.g. the previous MAG using=20 > > > binding revocation as was suggested by kilian et. al. > > >=20 > >=20 > > The LMA can't assume that the pMAG is trusted while the new=20 > MAG is the >=20 > > one lying. Perhaps the MN really moved and the pMAG continues to=20 > > claim it is there. Regardless of which MAG tells the LMA=20 > what, 1 or 2 >=20 > > needs to occur to conclude where the MN really is and then, the LMA=20 > > can determine which of the MAGs was lying. > >=20 > > Regards, > > Vidya > >=20 > > > 4. may be there are other ways... > > >=20 > > > In case that the MN is still at pMAG and has not moved, the > > pMAG can > > > easily indicate that in the binding revocation acknowledgement. > > >=20 > > > So do not you think that should work? > > >=20 > > > Regards, > > > Ahmad > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > Sent: Wednesday, September 26, 2007 3:49 PM > > > > To: Vijay Devarapalli; Kilian Weniger > > > > Cc: netlmm@ietf.org > > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > > draft-ietf-netlmm-proxymip6-05) > > > >=20 > > > >=20 > > > > A few observations here. I don't believe binding revocation > > > is going > > > > to solve anything here. The fundamental issue is how the LMA > > > > *identifies* the compromised MAG, not how the=20 > compromised MAG is=20 > > > > notified that its binding is no longer valid. Once the MAG is=20 > > > > identified as compromised, a number of remedies may be taken,=20 > > > > including, simply blacklisting the MAG and not accepting > > > PBUs from it. =20 > > > > It is not critical that the binding be revoked, because, > > > the LMA has > > > > already identified where the MN really is and it just > > needs to use > > > > that binding for data acceptance/forwarding. > > > >=20 > > > >=20 > > > > The issue of how the LMA identifies a compromised MAG cannot be=20 > > > > tackled without an independent verification of the > > presence of the > > > > MN at that particular MAG. So, we need to focus on > > providing hints > > > > on how the LMA may go about > > > achieving that.=20 > > > >=20 > > > > Vidya > > > >=20 > > > > > -----Original Message----- > > > > > From: Vijay Devarapalli=20 > [mailto:vijay.devarapalli@AzaireNet.com] > > > > > Sent: Wednesday, September 26, 2007 11:08 AM > > > > > To: Kilian Weniger > > > > > Cc: Narayanan, Vidya; netlmm@ietf.org > > > > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > > > > draft-ietf-netlmm-proxymip6-05) > > > > >=20 > > > > > Kilian Weniger wrote: > > > > > > Narayanan, Vidya wrote: > > > > > >>>> - Security considerations: MAG Compromise:=20 > > > > > > ... > > > > > >> If we claim this is an issue in the security > > > > > considerations section > > > > > >> and claim that the fix to it is for the LMA to ensure > > > the MN is > > > > > >> actually attached to the MAG, we can't quite hand > > wave on some > > > > > >> possible ways to do that. Those are just hints for > > > > > deployments that > > > > > >> are concerned about MAG compromise. But, those hints > > > need to be > > > > > >> captured in the security considerations section. =20 > > The threats > > > > > >> document captures this threat and it is a valid one - so, > > > > > I believe > > > > > >> we need some text here. The type of "detail" is what > > > I tried to > > > > > >> provide with the examples on AAA checks or CGA > > > > signatures - and, I > > > > > >> don't think we need a lot of detail here; a few > > > > sentences would be > > > > > >> good. > > > > > >> > > > > > >=20 > > > > > > I had a similar comment a while ago. I think that a draft > > > > > describing a > > > > > > severe security issue should at least give hints how this > > > > > can be solved. > > > > > >=20 > > > > > > Recently Sri, Vijay, Kuntal and I had an offline > > > discussion about > > > > > > another possible solution to detect a compromised MAGs, > > > > > which relies > > > > > > on PMIP signaling only. > > > > > >=20 > > > > > > The basic idea is that if two MAGs simultaneously claim > > > > > that the MN is > > > > > > attached, one of the MAGs must lie and is probably a > > > > > compromised MAG. > > > > > > The assumption is that the MN cannot at the same time be > > > > > attached to > > > > > > two MAGs, at least not with the same network interface. > > > > > >=20 > > > > > > More specifically, when the LMA accepts a valid PBU from a > > > > > new MAG, it > > > > > > changes the BCE (i.e., there is no impact on handover > > > delay) and > > > > > > notifies the old MAG (i.e., old address in BCE) about > > > > this. The old > > > > > > MAG then checks whether the MN is still attached. If this > > > > > is the case, > > > > > > it informs the LMA about this. The LMA then learns that two > > > > > different > > > > > > MAGs claim MN attachement, which is not possible under the > > > > > assumption > > > > > > stated above. Hence, after receiving one or more such > > > > > notifications, > > > > > > the LMA can identify the compromised MAG and stop > > > > trusting this MAG. > > > > > >=20 > > > > > > A remaining problem was which message should be used to > > > > > inform the old > > > > > > MAG about the BCE change. PBA and revocation msg were > > > > > discussed, but > > > > > > the former is not sent unsolicited according to RFC3775 > > > > > (which could > > > > > > be overidden by PMIP spec of course) and the latter is not=20 > > > > > > standardized yet. > > > > >=20 > > > > > As I said in another threat, we really need to=20 > standardize the=20 > > > > > revocation message from the LMA to the old MAG ASAP. > > > > >=20 > > > > > Vijay > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 > > >=20 > >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 03:08:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib9xM-0002fz-LL; Fri, 28 Sep 2007 03:08:12 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ib9xK-0002Zg-WF for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 03:08:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib9xG-0002X8-Rw for netlmm@ietf.org; Fri, 28 Sep 2007 03:08:06 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib9xA-00075n-6C for netlmm@ietf.org; Fri, 28 Sep 2007 03:08:06 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1891948nzf for ; Fri, 28 Sep 2007 00:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=NJiTF2ip3UYuXmgY+8qJA/AKxs571Qt8wteFKZBOo4s=; b=kZPtdxbbe6HynJ4zWNM7XsvhWALG7HsKwrN1j0iiLGflGJTifvlba7F/a+awSQU/mmER+lSG3XciLAK7k5aJJl0L3KjIjMR6nzBzMZMc9SLGIgO2PkZYhlPiHyj57una1TRihGJKumzYIv32kiyaBS6S4EMM4CcXBX9XwvB55DU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=cAZczHtg2vRh2NhYHgVILs0O7vP8tvvDPX1gD4eJVw09FzQ7suk5vRwVZzSSaxsR8tUeKIe+IqSVp2EGjc8e+f5SJ1gu0Idma5xOirBEVMPkISCGo2bloi18HaXmlbN2OiTZUU6N1rysOrAk3seFcfLJ+m3EBUi9rCXJOmBlMIQ= Received: by 10.141.146.11 with SMTP id y11mr1380327rvn.1190963265640; Fri, 28 Sep 2007 00:07:45 -0700 (PDT) Received: by 10.141.78.6 with HTTP; Fri, 28 Sep 2007 00:07:45 -0700 (PDT) Message-ID: Date: Fri, 28 Sep 2007 16:07:45 +0900 From: "Jong-Hyouk Lee" To: "Premec, Domagoj" Subject: Re: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6802AAC62F@zagh223a.ww300.siemens.net> MIME-Version: 1.0 References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <3C31CDD06342EA4A8137716247B1CD6802AAC62F@zagh223a.ww300.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: Kilian Weniger , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0735755212==" Errors-To: netlmm-bounces@ietf.org --===============0735755212== Content-Type: multipart/alternative; boundary="----=_Part_1514_9609065.1190963265617" ------=_Part_1514_9609065.1190963265617 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Domagoj. I'd like to be the side of AAA. As you mentioned, the context transfer mechanism may provide a reduced authentication time or procedure in the handoff procedure. But, I think that AAA has to recognize the state information of mobile node including the accurate location information. Why? For instance, for an accurate accounting for the mobile node. So, I agree with Ahmad Muhanna's text. (Using AAA mechanism is natural, why not?) Cheers. On 9/28/07, Premec, Domagoj wrote: > > Hi Ahmad, > > If we have context transfer mechanism in place between MAGs, then the MN > may move to a new MAG without authentication and the AAA would not know > about the new MAG. I don't think we can assume that the AAA has an accurate > info on the MS location. > > domagoj > > > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: 28. rujan 2007 07:37 > > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > > Cc: netlmm > > Subject: RE: Text Proposal for Compromised MAG issue (was > > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) > > > > > > All, > > > > I sincerely do not want to debate the use of revocation for > > compromised MAG at the present time. I am sure that all of us > > are interested in getting this issue addressed properly and > > have it closed sooner than later. What about the following text: > > > > Current text under security consideration: > > ========================================== > > " > > To eliminate the threats related to a compromised mobile access > > gateway, this specification recommends that the local > > mobility anchor > > before accepting a Proxy Binding Update message for a given mobile > > node, should ensure the mobile node is definitively attached to the > > mobile access gateway that sent the binding registration request. > > " > > > > New Text: > > ========= > > > > " > > To eliminate the threats related to a compromised mobile access > > gateway, this specification recommends that the local > > mobility anchor > > before accepting a Proxy Binding Update message for a given mobile > > node, should ensure the mobile node is definitively attached to the > > mobile access gateway that sent the binding registration request > > by contacting a trusted entity which tracks the MN current > > location, > > e.g. AAA server. > > " > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Wednesday, September 26, 2007 7:41 PM > > > To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger > > > Cc: netlmm@ietf.org > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > draft-ietf-netlmm-proxymip6-05) > > > > > > Hi Ahmad, > > > > > > > > > > -----Original Message----- > > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > Sent: Wednesday, September 26, 2007 4:12 PM > > > > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > > > > Cc: netlmm@ietf.org > > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > > draft-ietf-netlmm-proxymip6-05) > > > > > > > > Hi Vidya, > > > > > > > > Using revocation for the compromised MAG was proposed by > > > Kilian, et. > > > > al. > > > > but I am trying to help closing the issue so please allow > > > me to jump > > > > into this debate. > > > > > > > > In order for the LMA to validate the presence of the MN at > > > a specific > > > > MAG, the LMA needs to do one of the followings: > > > > > > > > 1. Validate the MN identity via a MN signature carried in > > > the P-BU. In > > > > P-MIPv6 this currently is not available since the P-BU is NOT > > > > initiated by the MN. (the most obvious option) > > > > > > > > 2. Validate the MN presence via another trusted entity that > > > > *ALWAYS* tracks the MN current location, e.g. AAA server. > > > > > > > > 3. Validate the MN presence via another trusted entity that > > > tracks the > > > > current or latest location of the MN, e.g. the previous MAG using > > > > binding revocation as was suggested by kilian et. al. > > > > > > > > > > The LMA can't assume that the pMAG is trusted while the new > > MAG is the > > > > > one lying. Perhaps the MN really moved and the pMAG continues to > > > claim it is there. Regardless of which MAG tells the LMA > > what, 1 or 2 > > > > > needs to occur to conclude where the MN really is and then, the LMA > > > can determine which of the MAGs was lying. > > > > > > Regards, > > > Vidya > > > > > > > 4. may be there are other ways... > > > > > > > > In case that the MN is still at pMAG and has not moved, the > > > pMAG can > > > > easily indicate that in the binding revocation acknowledgement. > > > > > > > > So do not you think that should work? > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > > Sent: Wednesday, September 26, 2007 3:49 PM > > > > > To: Vijay Devarapalli; Kilian Weniger > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > > > draft-ietf-netlmm-proxymip6-05) > > > > > > > > > > > > > > > A few observations here. I don't believe binding revocation > > > > is going > > > > > to solve anything here. The fundamental issue is how the LMA > > > > > *identifies* the compromised MAG, not how the > > compromised MAG is > > > > > notified that its binding is no longer valid. Once the MAG is > > > > > identified as compromised, a number of remedies may be taken, > > > > > including, simply blacklisting the MAG and not accepting > > > > PBUs from it. > > > > > It is not critical that the binding be revoked, because, > > > > the LMA has > > > > > already identified where the MN really is and it just > > > needs to use > > > > > that binding for data acceptance/forwarding. > > > > > > > > > > > > > > > The issue of how the LMA identifies a compromised MAG cannot be > > > > > tackled without an independent verification of the > > > presence of the > > > > > MN at that particular MAG. So, we need to focus on > > > providing hints > > > > > on how the LMA may go about > > > > achieving that. > > > > > > > > > > Vidya > > > > > > > > > > > -----Original Message----- > > > > > > From: Vijay Devarapalli > > [mailto:vijay.devarapalli@AzaireNet.com] > > > > > > Sent: Wednesday, September 26, 2007 11:08 AM > > > > > > To: Kilian Weniger > > > > > > Cc: Narayanan, Vidya; netlmm@ietf.org > > > > > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > > > > > draft-ietf-netlmm-proxymip6-05) > > > > > > > > > > > > Kilian Weniger wrote: > > > > > > > Narayanan, Vidya wrote: > > > > > > >>>> - Security considerations: MAG Compromise: > > > > > > > ... > > > > > > >> If we claim this is an issue in the security > > > > > > considerations section > > > > > > >> and claim that the fix to it is for the LMA to ensure > > > > the MN is > > > > > > >> actually attached to the MAG, we can't quite hand > > > wave on some > > > > > > >> possible ways to do that. Those are just hints for > > > > > > deployments that > > > > > > >> are concerned about MAG compromise. But, those hints > > > > need to be > > > > > > >> captured in the security considerations section. > > > The threats > > > > > > >> document captures this threat and it is a valid one - so, > > > > > > I believe > > > > > > >> we need some text here. The type of "detail" is what > > > > I tried to > > > > > > >> provide with the examples on AAA checks or CGA > > > > > signatures - and, I > > > > > > >> don't think we need a lot of detail here; a few > > > > > sentences would be > > > > > > >> good. > > > > > > >> > > > > > > > > > > > > > > I had a similar comment a while ago. I think that a draft > > > > > > describing a > > > > > > > severe security issue should at least give hints how this > > > > > > can be solved. > > > > > > > > > > > > > > Recently Sri, Vijay, Kuntal and I had an offline > > > > discussion about > > > > > > > another possible solution to detect a compromised MAGs, > > > > > > which relies > > > > > > > on PMIP signaling only. > > > > > > > > > > > > > > The basic idea is that if two MAGs simultaneously claim > > > > > > that the MN is > > > > > > > attached, one of the MAGs must lie and is probably a > > > > > > compromised MAG. > > > > > > > The assumption is that the MN cannot at the same time be > > > > > > attached to > > > > > > > two MAGs, at least not with the same network interface. > > > > > > > > > > > > > > More specifically, when the LMA accepts a valid PBU from a > > > > > > new MAG, it > > > > > > > changes the BCE (i.e., there is no impact on handover > > > > delay) and > > > > > > > notifies the old MAG (i.e., old address in BCE) about > > > > > this. The old > > > > > > > MAG then checks whether the MN is still attached. If this > > > > > > is the case, > > > > > > > it informs the LMA about this. The LMA then learns that two > > > > > > different > > > > > > > MAGs claim MN attachement, which is not possible under the > > > > > > assumption > > > > > > > stated above. Hence, after receiving one or more such > > > > > > notifications, > > > > > > > the LMA can identify the compromised MAG and stop > > > > > trusting this MAG. > > > > > > > > > > > > > > A remaining problem was which message should be used to > > > > > > inform the old > > > > > > > MAG about the BCE change. PBA and revocation msg were > > > > > > discussed, but > > > > > > > the former is not sent unsolicited according to RFC3775 > > > > > > (which could > > > > > > > be overidden by PMIP spec of course) and the latter is not > > > > > > > standardized yet. > > > > > > > > > > > > As I said in another threat, we really need to > > standardize the > > > > > > revocation message from the LMA to the old MAG ASAP. > > > > > > > > > > > > Vijay > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://www.hurryon.org ------=_Part_1514_9609065.1190963265617 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Domagoj.
 
I'd like to be the side of AAA. As you mentioned, the context transfer mechanism may provide a reduced authentication time or procedure in the handoff procedure. But, I think that AAA has to recognize the state information of mobile node including the accurate location information. Why? For instance, for an accurate accounting for the mobile node.
 
So, I agree with Ahmad Muhanna's text. (Using AAA mechanism is natural, why not?)
 
Cheers.

 
On 9/28/07, Premec, Domagoj <domagoj.premec@siemens.com> wrote:
Hi Ahmad,

If we have context transfer mechanism in place between MAGs, then the MN may move to a new MAG without authentication and the AAA  would not know about the new MAG. I don't think we can assume that the AAA has an accurate info on the MS location.

domagoj


> -----Original Message-----
> From: Ahmad Muhanna [mailto:amuhanna@nortel.com]
> Sent: 28. rujan 2007 07:37
> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger
> Cc: netlmm
> Subject: RE: Text Proposal for Compromised MAG issue (was
> [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)
>
>
> All,
>
> I sincerely do not want to debate the use of revocation for
> compromised MAG at the present time. I am sure that all of us
> are interested in getting this issue addressed properly and
> have it closed sooner than later. What about the following text:
>
> Current text under security consideration:
> ==========================================
> "
>    To eliminate the threats related to a compromised mobile access
>    gateway, this specification recommends that the local
> mobility anchor
>    before accepting a Proxy Binding Update message for a given mobile
>    node, should ensure the mobile node is definitively attached to the
>    mobile access gateway that sent the binding registration request.
> "
>
> New Text:
> =========
>
> "
>    To eliminate the threats related to a compromised mobile access
>    gateway, this specification recommends that the local
> mobility anchor
>    before accepting a Proxy Binding Update message for a given mobile
>    node, should ensure the mobile node is definitively attached to the
>    mobile access gateway that sent the binding registration request
>    by contacting a trusted entity which tracks the MN current
> location,
>    e.g. AAA server.
> "
>
> Regards,
> Ahmad
>
>
> > -----Original Message-----
> > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]
> > Sent: Wednesday, September 26, 2007 7:41 PM
> > To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger
> > Cc: netlmm@ietf.org
> > Subject: RE: Compromised MAG issue (was [netlmm] Review of
> > draft-ietf-netlmm-proxymip6-05)
> >
> > Hi Ahmad,
> >
> >
> > > -----Original Message-----
> > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]
> > > Sent: Wednesday, September 26, 2007 4:12 PM
> > > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger
> > > Cc: netlmm@ietf.org
> > > Subject: RE: Compromised MAG issue (was [netlmm] Review of
> > > draft-ietf-netlmm-proxymip6-05)
> > >
> > > Hi Vidya,
> > >
> > > Using revocation for the compromised MAG was proposed by
> > Kilian, et.
> > > al.
> > > but I am trying to help closing the issue so please allow
> > me to jump
> > > into this debate.
> > >
> > > In order for the LMA to validate the presence of the MN at
> > a specific
> > > MAG, the LMA needs to do one of the followings:
> > >
> > > 1. Validate the MN identity via a MN signature carried in
> > the P-BU. In
> > > P-MIPv6 this currently is not available since the P-BU is NOT
> > > initiated by the MN. (the most obvious option)
> > >
> > > 2. Validate the MN presence via another trusted entity that
> > > *ALWAYS* tracks the MN current location, e.g. AAA server.
> > >
> > > 3. Validate the MN presence via another trusted entity that
> > tracks the
> > > current or latest location of the MN, e.g. the previous MAG using
> > > binding revocation as was suggested by kilian et. al.
> > >
> >
> > The LMA can't assume that the pMAG is trusted while the new
> MAG is the
>
> > one lying.  Perhaps the MN really moved and the pMAG continues to
> > claim it is there.  Regardless of which MAG tells the LMA
> what, 1 or 2
>
> > needs to occur to conclude where the MN really is and then, the LMA
> > can determine which of the MAGs was lying.
> >
> > Regards,
> > Vidya
> >
> > > 4. may be there are other ways...
> > >
> > > In case that the MN is still at pMAG and has not moved, the
> > pMAG can
> > > easily indicate that in the binding revocation acknowledgement.
> > >
> > > So do not you think that should work?
> > >
> > > Regards,
> > > Ahmad
> > >
> > >
> > > > -----Original Message-----
> > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]
> > > > Sent: Wednesday, September 26, 2007 3:49 PM
> > > > To: Vijay Devarapalli; Kilian Weniger
> > > > Cc: netlmm@ietf.org
> > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of
> > > > draft-ietf-netlmm-proxymip6-05)
> > > >
> > > >
> > > > A few observations here. I don't believe binding revocation
> > > is going
> > > > to solve anything here.  The fundamental issue is how the LMA
> > > > *identifies* the compromised MAG, not how the
> compromised MAG is
> > > > notified that its binding is no longer valid.  Once the MAG is
> > > > identified as compromised, a number of remedies may be taken,
> > > > including, simply blacklisting the MAG and not accepting
> > > PBUs from it.
> > > > It is not critical that the binding be revoked, because,
> > > the LMA has
> > > > already identified where the MN really is and it just
> > needs to use
> > > > that binding for data acceptance/forwarding.
> > > >
> > > >
> > > > The issue of how the LMA identifies a compromised MAG cannot be
> > > > tackled without an independent verification of the
> > presence of the
> > > > MN at that particular MAG.  So, we need to focus on
> > providing hints
> > > > on how the LMA may go about
> > > achieving that.
> > > >
> > > > Vidya
> > > >
> > > > > -----Original Message-----
> > > > > From: Vijay Devarapalli
> [mailto:vijay.devarapalli@AzaireNet.com]
> > > > > Sent: Wednesday, September 26, 2007 11:08 AM
> > > > > To: Kilian Weniger
> > > > > Cc: Narayanan, Vidya; netlmm@ietf.org
> > > > > Subject: Re: Compromised MAG issue (was [netlmm] Review of
> > > > > draft-ietf-netlmm-proxymip6-05)
> > > > >
> > > > > Kilian Weniger wrote:
> > > > > > Narayanan, Vidya wrote:
> > > > > >>>> - Security considerations: MAG Compromise:
> > > > > > ...
> > > > > >> If we claim this is an issue in the security
> > > > > considerations section
> > > > > >> and claim that the fix to it is for the LMA to ensure
> > > the MN is
> > > > > >> actually attached to the MAG, we can't quite hand
> > wave on some
> > > > > >> possible ways to do that.  Those are just hints for
> > > > > deployments that
> > > > > >> are concerned about MAG compromise.  But, those hints
> > > need to be
> > > > > >> captured in the security considerations section.
> > The threats
> > > > > >> document captures this threat and it is a valid one - so,
> > > > > I believe
> > > > > >> we need some text here.  The type of "detail" is what
> > > I tried to
> > > > > >> provide with the examples on AAA checks or CGA
> > > > signatures - and, I
> > > > > >> don't think we need a lot of detail here; a few
> > > > sentences would be
> > > > > >> good.
> > > > > >>
> > > > > >
> > > > > > I had a similar comment a while ago. I think that a draft
> > > > > describing a
> > > > > > severe security issue should at least give hints how this
> > > > > can be solved.
> > > > > >
> > > > > > Recently Sri, Vijay, Kuntal and I had an offline
> > > discussion about
> > > > > > another possible solution to detect a compromised MAGs,
> > > > > which relies
> > > > > > on PMIP signaling only.
> > > > > >
> > > > > > The basic idea is that if two MAGs simultaneously claim
> > > > > that the MN is
> > > > > > attached, one of the MAGs must lie and is probably a
> > > > > compromised MAG.
> > > > > > The assumption is that the MN cannot at the same time be
> > > > > attached to
> > > > > > two MAGs, at least not with the same network interface.
> > > > > >
> > > > > > More specifically, when the LMA accepts a valid PBU from a
> > > > > new MAG, it
> > > > > > changes the BCE (i.e., there is no impact on handover
> > > delay) and
> > > > > > notifies the old MAG (i.e., old address in BCE) about
> > > > this. The old
> > > > > > MAG then checks whether the MN is still attached. If this
> > > > > is the case,
> > > > > > it informs the LMA about this. The LMA then learns that two
> > > > > different
> > > > > > MAGs claim MN attachement, which is not possible under the
> > > > > assumption
> > > > > > stated above. Hence, after receiving one or more such
> > > > > notifications,
> > > > > > the LMA can identify the compromised MAG and stop
> > > > trusting this MAG.
> > > > > >
> > > > > > A remaining problem was which message should be used to
> > > > > inform the old
> > > > > > MAG about the BCE change. PBA and revocation msg were
> > > > > discussed, but
> > > > > > the former is not sent unsolicited according to RFC3775
> > > > > (which could
> > > > > > be overidden by PMIP spec of course) and the latter is not
> > > > > > standardized yet.
> > > > >
> > > > > As I said in another threat, we really need to
> standardize the
> > > > > revocation message from the LMA to the old MAG ASAP.
> > > > >
> > > > > Vijay
> > > > >
> > > >
> > > > _______________________________________________
> > > > netlmm mailing list
> > > > netlmm@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/netlmm
> > > >
> > >
> >
>
>
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www1.ietf.org/mailman/listinfo/netlmm
>


_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm



--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org ------=_Part_1514_9609065.1190963265617-- --===============0735755212== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0735755212==-- From netlmm-bounces@ietf.org Fri Sep 28 05:23:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbC3X-0006FD-W5; Fri, 28 Sep 2007 05:22:44 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbC3X-0006F1-2K for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 05:22:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbC3W-0006Es-MP for netlmm@ietf.org; Fri, 28 Sep 2007 05:22:42 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbC3V-00008z-BX for netlmm@ietf.org; Fri, 28 Sep 2007 05:22:42 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8S9LtuI000470; Fri, 28 Sep 2007 11:21:55 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 11:22:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 11:22:30 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBAABg9sAAA7Ds6QAAB/OaAAAErRsAAF+R9A References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Ahmad Muhanna" X-OriginalArrivalTime: 28 Sep 2007 09:22:31.0647 (UTC) FILETIME=[18C51EF0:01C801B1] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, in my understanding there's a general motivation to make AAA Servers = stateless, so the draft should not put such a strong "tracking" = requirement It is clear to me that in some/many deployments the AAA Server is not = stateless anyway, so this is a minor comment But then, what the AAA Server actually tracks is the NAS and not really = the MAG Somehow you're assuming that the AAA Server is aware of the relationship = between NASs and MAGs With the current text, the security solution was left for deployments to = choose With the new text you're trying to close the solution space to one given = solution Let's be fair here: - or the security solution is discussed and we do the beauty contest = with all of them - or the security solution is not discussed and we leave the = discussion for other contexts Regards federico -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Envoy=E9 : vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text Proposal for Compromised MAG issue (was [netlmm] Review = ofdraft-ietf-netlmm-proxymip6-05) All, I sincerely do not want to debate the use of revocation for compromised = MAG at the present time. I am sure that all of us are interested in = getting this issue addressed properly and have it closed sooner than = later. What about the following text: Current text under security consideration: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " To eliminate the threats related to a compromised mobile access gateway, this specification recommends that the local mobility anchor before accepting a Proxy Binding Update message for a given mobile node, should ensure the mobile node is definitively attached to the mobile access gateway that sent the binding registration request. " New Text: =3D=3D=3D=3D=3D=3D=3D=3D=3D " To eliminate the threats related to a compromised mobile access gateway, this specification recommends that the local mobility anchor before accepting a Proxy Binding Update message for a given mobile node, should ensure the mobile node is definitively attached to the mobile access gateway that sent the binding registration request=20 by contacting a trusted entity which tracks the MN current location,=20 e.g. AAA server. " Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Wednesday, September 26, 2007 7:41 PM > To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger > Cc: netlmm@ietf.org > Subject: RE: Compromised MAG issue (was [netlmm] Review of > draft-ietf-netlmm-proxymip6-05) >=20 > Hi Ahmad, > =20 >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Wednesday, September 26, 2007 4:12 PM > > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > > Cc: netlmm@ietf.org > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > draft-ietf-netlmm-proxymip6-05) > >=20 > > Hi Vidya, > >=20 > > Using revocation for the compromised MAG was proposed by > Kilian, et.=20 > > al. > > but I am trying to help closing the issue so please allow > me to jump > > into this debate. > >=20 > > In order for the LMA to validate the presence of the MN at > a specific > > MAG, the LMA needs to do one of the followings: > >=20 > > 1. Validate the MN identity via a MN signature carried in > the P-BU. In > > P-MIPv6 this currently is not available since the P-BU is NOT=20 > > initiated by the MN. (the most obvious option) > >=20 > > 2. Validate the MN presence via another trusted entity that > > *ALWAYS* tracks the MN current location, e.g. AAA server. > >=20 > > 3. Validate the MN presence via another trusted entity that > tracks the > > current or latest location of the MN, e.g. the previous MAG using=20 > > binding revocation as was suggested by kilian et. al. > >=20 >=20 > The LMA can't assume that the pMAG is trusted while the new MAG is the > one lying. Perhaps the MN really moved and the pMAG continues to=20 > claim it is there. Regardless of which MAG tells the LMA what, 1 or 2 > needs to occur to conclude where the MN really is and then, the LMA=20 > can determine which of the MAGs was lying. >=20 > Regards, > Vidya >=20 > > 4. may be there are other ways... > >=20 > > In case that the MN is still at pMAG and has not moved, the > pMAG can > > easily indicate that in the binding revocation acknowledgement. > >=20 > > So do not you think that should work? > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Wednesday, September 26, 2007 3:49 PM > > > To: Vijay Devarapalli; Kilian Weniger > > > Cc: netlmm@ietf.org > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > draft-ietf-netlmm-proxymip6-05) > > >=20 > > >=20 > > > A few observations here. I don't believe binding revocation > > is going > > > to solve anything here. The fundamental issue is how the LMA > > > *identifies* the compromised MAG, not how the compromised MAG is=20 > > > notified that its binding is no longer valid. Once the MAG is=20 > > > identified as compromised, a number of remedies may be taken,=20 > > > including, simply blacklisting the MAG and not accepting > > PBUs from it. =20 > > > It is not critical that the binding be revoked, because, > > the LMA has > > > already identified where the MN really is and it just > needs to use > > > that binding for data acceptance/forwarding. > > >=20 > > >=20 > > > The issue of how the LMA identifies a compromised MAG cannot be=20 > > > tackled without an independent verification of the > presence of the > > > MN at that particular MAG. So, we need to focus on > providing hints > > > on how the LMA may go about > > achieving that.=20 > > >=20 > > > Vidya > > >=20 > > > > -----Original Message----- > > > > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > > > Sent: Wednesday, September 26, 2007 11:08 AM > > > > To: Kilian Weniger > > > > Cc: Narayanan, Vidya; netlmm@ietf.org > > > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > > > draft-ietf-netlmm-proxymip6-05) > > > >=20 > > > > Kilian Weniger wrote: > > > > > Narayanan, Vidya wrote: > > > > >>>> - Security considerations: MAG Compromise:=20 > > > > > ... > > > > >> If we claim this is an issue in the security > > > > considerations section > > > > >> and claim that the fix to it is for the LMA to ensure > > the MN is > > > > >> actually attached to the MAG, we can't quite hand > wave on some > > > > >> possible ways to do that. Those are just hints for > > > > deployments that > > > > >> are concerned about MAG compromise. But, those hints > > need to be > > > > >> captured in the security considerations section. =20 > The threats > > > > >> document captures this threat and it is a valid one - so, > > > > I believe > > > > >> we need some text here. The type of "detail" is what > > I tried to > > > > >> provide with the examples on AAA checks or CGA > > > signatures - and, I > > > > >> don't think we need a lot of detail here; a few > > > sentences would be > > > > >> good. > > > > >> > > > > >=20 > > > > > I had a similar comment a while ago. I think that a draft > > > > describing a > > > > > severe security issue should at least give hints how this > > > > can be solved. > > > > >=20 > > > > > Recently Sri, Vijay, Kuntal and I had an offline > > discussion about > > > > > another possible solution to detect a compromised MAGs, > > > > which relies > > > > > on PMIP signaling only. > > > > >=20 > > > > > The basic idea is that if two MAGs simultaneously claim > > > > that the MN is > > > > > attached, one of the MAGs must lie and is probably a > > > > compromised MAG. > > > > > The assumption is that the MN cannot at the same time be > > > > attached to > > > > > two MAGs, at least not with the same network interface. > > > > >=20 > > > > > More specifically, when the LMA accepts a valid PBU from a > > > > new MAG, it > > > > > changes the BCE (i.e., there is no impact on handover > > delay) and > > > > > notifies the old MAG (i.e., old address in BCE) about > > > this. The old > > > > > MAG then checks whether the MN is still attached. If this > > > > is the case, > > > > > it informs the LMA about this. The LMA then learns that two > > > > different > > > > > MAGs claim MN attachement, which is not possible under the > > > > assumption > > > > > stated above. Hence, after receiving one or more such > > > > notifications, > > > > > the LMA can identify the compromised MAG and stop > > > trusting this MAG. > > > > >=20 > > > > > A remaining problem was which message should be used to > > > > inform the old > > > > > MAG about the BCE change. PBA and revocation msg were > > > > discussed, but > > > > > the former is not sent unsolicited according to RFC3775 > > > > (which could > > > > > be overidden by PMIP spec of course) and the latter is not=20 > > > > > standardized yet. > > > >=20 > > > > As I said in another threat, we really need to standardize the=20 > > > > revocation message from the LMA to the old MAG ASAP. > > > >=20 > > > > Vijay > > > >=20 > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 07:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbDsP-0005JS-Bu; Fri, 28 Sep 2007 07:19:21 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbDsO-0005JN-Qk for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 07:19:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbDsO-0005En-Fd for netlmm@ietf.org; Fri, 28 Sep 2007 07:19:20 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbDsE-00054t-2G for netlmm@ietf.org; Fri, 28 Sep 2007 07:19:16 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SBI9r5031824; Fri, 28 Sep 2007 13:18:10 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 13:18:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 13:18:42 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AE7@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <008901c8010f$2266aa70$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAT3K0wACxplKA= References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <008901c8010f$2266aa70$1220fea9@amer.cisco.com> From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" , "Narayanan, Vidya" X-OriginalArrivalTime: 28 Sep 2007 11:18:57.0777 (UTC) FILETIME=[5CD3F610:01C801C1] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, Sri> This adds a limitation. A mobile node in a single access mode that = does a handoff between intefaces (access-1 to access-2), would loose = seamless roaming. It will loose the prefix. [FDJ] Not necessarily. I can understand Vidya's proposal by making an analogy with DHCPv4. In DHCPv4 the client adds "chaddr" in the DHCP messages, and the DHCP = Server can use this information to allocate different IP@. In PMIP6, the MAG (analogy to DHCP cleint) should add a link-indentifier = of the MN, so that the LMA (analogy with DHCP Server) may allocate a = different IP@. Different interfaces would have different link identifiers (somehow = required to be able to perform access authentication). Note that such link identifier would be permanent for the same interface = (i.e. it's not the LLA). At first look, the proposed solution seems fine to me. In .16 such link identifier would be a IEEE 802 MAC@, I presume there's = a valid identifier in other link technologies. On a side note and as FMI, Vidya's problem statement includes that a = host with multiple interfaces will shutdown one of them when it sees a = duplicated IP@. May I ask where such behavior is defined? It is rather constraining when thinking of multiple technologies and = make-before-break. Regards federico -----Message d'origine----- De : Sri Gundavelli [mailto:sgundave@cisco.com]=20 Envoy=E9 : jeudi 27 septembre 2007 16:03 =C0 : 'Narayanan, Vidya' Cc : 'ext Kilian Weniger'; netlmm@ietf.org Objet : RE: [netlmm] Issue: Prefix allocation and multihomed MNs =20 > Some thoughts on avoiding this problem:=20 >=20 > It seems to me that this is an unavoidable problem if the same MN-ID=20 > is sent for multiple interfaces of the MN to the LMA. It seems like=20 > an interface-specific ID (link layer address or equivalent) needs to=20 > be included in the PBU, so that the LMA can ensure that the same=20 > prefix/address is not assigned to multiple IP interfaces of an MN. =20 > This may not be too difficult, given that the MN-MAG link is=20 > point-to-point. >=20 This adds a limitation. A mobile node in a single access mode that does a handoff between intefaces (access-1 to access-2), would loose seamless roaming. It will loose the prefix. There is no easy solution to this problem. It is impossible to handle this scenario. Either, it requires some hooks on the MN side or some complex handshake between LMA's and MAG's for MN presence detection and also requires the L-2 technology on the MN-AR link to provide some hooks for the MAG to page the node. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 07:21:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbDuM-0008Pu-S6; Fri, 28 Sep 2007 07:21:22 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbDuL-0008Po-9A for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 07:21:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbDuK-0008Pa-Tn for netlmm@ietf.org; Fri, 28 Sep 2007 07:21:20 -0400 Received: from cluster-g.mailcontrol.com ([85.115.41.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbDuK-00034J-9R for netlmm@ietf.org; Fri, 28 Sep 2007 07:21:20 -0400 Received: from rly04g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly04g.srv.mailcontrol.com (MailControl) with ESMTP id l8SBL6Il000748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Sep 2007 12:21:17 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly04g.srv.mailcontrol.com (MailControl) id l8SBK9YT030478 for netlmm@ietf.org; Fri, 28 Sep 2007 12:20:09 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly04g-eth0.srv.mailcontrol.com (envelope-sender Genadi.Velev@eu.panasonic.com) (MIMEDefang) with ESMTP id l8SBJxZL029996; Fri, 28 Sep 2007 12:20:08 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 268d_1db92f5e_6db4_11dc_97fe_0030482aac25; Fri, 28 Sep 2007 13:15:27 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092813195491-21057 ; Fri, 28 Sep 2007 13:19:54 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.122,BAYES_00: -1.665,TOTAL_SCORE: -1.543 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 28 Sep 2007 13:19:36 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: <008a01c8010f$c8234130$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AAKZOVYA== References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8EA2@lan-ex-02.panasonic.de> Date: Fri, 28 Sep 2007 13:19:40 +0200 From: "Genadi Velev" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.71.1.114 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, =20 I see your point: handover between two different interfaces shall not be supported in the base spec. This was also my understanding until Vidya, Kilian and others raised the problem. Hence, I suggested the modified behaviour in the LMA. After the recent discussions on this thread I tend to think that we need to prevent a handoff between two different interfaces in the base spec (rather than allowing/supporting this handover). Supporting this handover and multihoming can be done later in a separate doc.=20 I can think about several approaches to overcome this issue: 1) we can specify that the network operator shall take care of preventing that a MN attaches with 2 interfaces to a PMIP domain (at least to the same LMA). For example, the operator doesn't allow attachment (i.e. authorization) of interface 2, since interface 1 is still attached. 2) we can write a short text in the draft that the network operator shall take care about assignment of different MN-ID (NAI) to different interfaces during attachment procedure.=20 3) we can describe how the current protocol behaves when a MN attempts to attach with two interfaces. Similar to what is explained in Vijay's email: http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html 4) we can go further and specify a procedure in the LMA: LMA doesn't accept PBU from a new MAG, if the PBU contains same MN-ID option but different LLA option which were received by old MAG. Maybe somebody can think of another approaches? Anyway, I think that we have to include some text in the base spec covering this issue. Genadi > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Thursday, September 27, 2007 4:08 PM > To: 'Genadi Velev'; 'Narayanan, Vidya' > Cc: 'ext Kilian Weniger'; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Hi Genadi, > =20 > >=20 > > If we look at the available options in PBU/PBA, we can see=20 > > that next to > > "NAI Option" (or "MN-ID option") we have a "Link-local=20 > > Address Option". > > Supposed that the link-local addresses of the multiple=20 > interfaces are > > different, an LMA can differentiate among PBUs having the same MN-ID > > option looking at the Link-local Address Option. IMHO, what=20 > we need to > > specify in the PMIPv6 protocol is a behaviour in the LMA that=20 > > the HNP is > > not solely bound to a MN-ID but also to the link-local=20 > > address. In this > > way different HNPs would be assigned to PBUs (coming from different > > MAGs) containing same MN-ID option but different link-local address > > options. >=20 > But, we need to allow handoff between two different interfaces (of > different access technologies), if we keep a relation to the LLA, > we cant do handoff. This scenario is more important than the scenario > of simultaneous multi-access. >=20 > Sri >=20 >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 07:37:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbE9g-00008z-UT; Fri, 28 Sep 2007 07:37:12 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbE9f-00008W-W5 for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 07:37:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbE9f-0008Sx-FF for netlmm@ietf.org; Fri, 28 Sep 2007 07:37:11 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbE9Z-0005Xn-BK for netlmm@ietf.org; Fri, 28 Sep 2007 07:37:11 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007092807364615719 ; Fri, 28 Sep 2007 07:36:46 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.075,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.24.113.49]) by s-utl01-atpop.stsn.net; Fri, 28 Sep 2007 07:36:44 -0400 Message-ID: <46FCE73D.8060707@azairenet.com> Date: Fri, 28 Sep 2007 04:36:29 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] MN-Id overspecification References: <0MKp8S-1Iaytj3R4h-0008Jv@mrelay.perfora.net> <46FC5857.90408@azairenet.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A538@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711704A538@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Vijay, > Let me add one comment below. > > Regards, > Ahmad > >> Subject: Re: [netlmm] MN-Id overspecification >> >> Alper Yegin wrote: >>> >>>> The sequence would be as follows for your scenario (assuming your >>>> scenario is to allocate HNP during access authentication) >>>> >>>> - MN does access authentication >>>> - AAA server sends the HNP for the MN to the MAG >>>> - MAG sends a proxy BU with the MN-ID and the HNP to the LMA >>>> - LMA checks if the MN-ID is authorized for the HNP (with >> AAA's help) >>> Yes. >> If you agree with the above, it means the LMA needs to have >> the MN-ID when the proxy BU is processed. Does this not mean, >> it is carried in the proxy BU. > > [Ahmad] > In case that LMA needs to contact AAA server for this authorization > which is very much expected during initial registration, how the LMA > would know which AAA server it needs to forward the RADIUS or DIAMETER > request if P-BU ONLY has the HNP? > > Is there a mechanism which allows the LMA to identify the MN home AAA > server based on HNP? No. The MN-ID (in the form of NAI) would be required again. Vijay > > Regards, > Ahmad > >>>> Note that I completely disagree with the AAA server assigning the >>>> HNP. I would like HNP assignment always coming from the LMA. >>> If you prefer that in your deployments, fine by me. But if >> you somehow >>> want to force any IETF spec to limit deployments in that >> way, we need >>> to discuss that. >> You can of course disagree. >> >>>>>> Alper, frankly I think you need to show why including >> the MN-ID in >>>>>> the proxy BU is a bad idea. If there is no issue, lets move on. >>>>> Frankly, I did show it on the ML twice already. And yet >> to see why >>>>> it is useful (other than for the HNP assignment case). >>>> With 4285? That was hardly convincing. Sorry. >>> Do you have any technical feedback, or is it just that you >> don't feel >>> like being convinced? >> Hard to give technical feedback on something that is not >> technically convincing. :) >> >> Vijay >> >> >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 07:41:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEDo-0000Pu-RG; Fri, 28 Sep 2007 07:41:28 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbEDn-0000OO-0T for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 07:41:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEDm-0000OG-LF for netlmm@ietf.org; Fri, 28 Sep 2007 07:41:26 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbEDl-0003bP-Mb for netlmm@ietf.org; Fri, 28 Sep 2007 07:41:26 -0400 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SBe50t010475; Fri, 28 Sep 2007 13:40:35 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 13:41:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 13:41:01 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AEB@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: Acf/35RrVDIAtmxORBmRCjzmW0khpwAL5xXAAAkKj1oAAiragAAC451gAF6P+cA= References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" X-OriginalArrivalTime: 28 Sep 2007 11:41:09.0909 (UTC) FILETIME=[76D72C50:01C801C4] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, I have seen several times now statements that the LMA would only have = one binding per MN. I'm a bit puzzled by this. In MIP6 AFAIK the HA may have multiple bindings per MN (multiple CoA) = but only one of them is primary. The statement that there's only one single binding per MN makes me think = that this feature is not supported by PMIP6. Has this been discussed earlier? If yes I'll dig up the archives to = catch up. Thanks federico -----Message d'origine----- De : Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Envoy=E9 : mercredi 26 septembre 2007 16:15 =C0 : ext Kilian Weniger Cc : netlmm@ietf.org Objet : Re: [netlmm] Issue: Prefix allocation and multihomed MNs Kilian, While it is possible that a multi-interface MN can attach to different = MAGs which cause the MAGs to send a PBU to the same LMA, I personally = think that dealing with this is more of an academic exercise at the = present time. I do not believe we have the possibility of making any changes to the = MN. So that route is closed... At least for now. So here is how I view the current scenario which IMO is academic at this = time and hence not something that we should be spending a lot of time on = : - If an MN attaches to multiple MAGs via different interfaces this would = trigger the MAGs to send PBUs to the LMA - If the LMA receives them almost simultaneously (as an example), and a = PBAck has not been sent, then the LMA can choose to create an entry in = the BC for the last received PBU and ACK only the last received PBU (the = LMA would believe that the MN which attached to MAG1 moved to MAG2 = resulting in the transmission of PBUs from MAG1 and MAG2 near = simulatenously) - If the MN receives a PBU from another MAG for an MN which has an entry = in the BC as a result of a second interface attaching to a MAG, the LMA = would view this as the MN having moved to MAG2 and hence would delete = the BCE for MAG1 and insert MAG2 for the MN But if we merely state (or mandate) that the LMA will only have only one = MAG entry in the BC at any given time, we would not have a problem with = the multi-homing scenario, right? -Raj On 9/26/07 8:10 AM, "ext Kilian Weniger" = wrote: > Hi Raj, >=20 > I think we should differentiate between two cases: > 1. supporting multi-homing requested by the host to achieve features=20 > like load balancing, failover etc. > 2. preventing that PMIP protocol breaks if an unmodified host=20 > activates more than one network interface. >=20 > For case 1, I agree with you that this is out of scope of the base=20 > draft and should be handled in a separate multi-homing document. >=20 > But I think Vidya was talking about case 2 and I agree that this issue = > should be addressed in the base draft. >=20 > Currently, I see the following potential issues if an unmodified host=20 > activates more than one network interface and happens to attach to=20 > more than one MAG of a given PMIP domain simultaneously: > - multiple MN interfaces get the same prefix assigned, which may break = > something (e.g., routing) in the host and may result in loss of=20 > connectivity > - BCE at LMA constantly and randomly changes since multiple MAGs send=20 > PBUs to the LMA for the same MN. This may result in packet loss both=20 > in downlink and uplink. > - the MAGs may discover and use different LMA addresses for the same=20 > host etc. >=20 > However, I'm not sure how we can solve this issue without modifying=20 > the host or mandating not to use multiple interfaces. Any ideas? >=20 > BR, >=20 > Kilian >=20 >=20 >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Mittwoch, 26. September 2007 13:50 >> To: ext Kilian Weniger; Narayanan, Vidya >> Cc: netlmm@ietf.org >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>=20 >>=20 >> Kilian, >>=20 >>=20 >>=20 >>=20 >> On 9/26/07 3:57 AM, "ext Kilian Weniger" >> >> wrote: >>=20 >>> Hi Vidya, >>>=20 >>> I agree that we need some text about this issue. >>>=20 >>> Narayanan, Vidya wrote: >>>> - define LMA behavior such that regular multihomed IP devices don't = >>>> run into issues of connectivity or shutting down interfaces. >> This is much >>>> more logical in my view and it is not a big change in the document. >>>=20 >>> Can you elaborate how this would work? How does the LMA >> differentiate >>> between PBUs that were triggered by the same vs different >> MN interfaces? >>>=20 >>>=20 >>> I guess the MAG would need to include some kind of MN >> physical network >>> interface ID in the PBU, but what kind of ID would that be >> and how does >>> the MAG learn that ID? Note that the MN's link-local address may not = >>> work as an ID in general, since the MN may implement a kind >> of virtual >>> network interface which hides multiple physical network >> interfaces and >>> only exposes a single (virtual) network interface to the IP >> stack. This >>> may result in the same link-local address for multiple physical=20 >>> interfaces. >>>=20 >>> So do we need to mandate something on the MN side to solve >> this issue in >>> the general case? >>=20 >> One of the tenets of Netlmm protocol has been to not require any=20 >> changes or requirements on the MN. So it is not an option. >>=20 >> Issues that arise from multi-homing and how to deal with them should=20 >> be dealt separately and not in the scope of this I-D. >>=20 >> -Raj >>=20 >>>=20 >>> Kilian >>>=20 >>>=20 >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >>=20 >>=20 >>=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 07:49:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbELM-0001zA-Ly; Fri, 28 Sep 2007 07:49:16 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbELL-0001xT-Ah for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 07:49:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbELK-0001wB-V1 for netlmm@ietf.org; Fri, 28 Sep 2007 07:49:15 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbELK-0003oM-7W for netlmm@ietf.org; Fri, 28 Sep 2007 07:49:14 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007092807490925307 ; Fri, 28 Sep 2007 07:49:09 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.251,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.24.113.49]) by s-utl02-atpop.stsn.net; Fri, 28 Sep 2007 07:49:08 -0400 Message-ID: <46FCEA26.8020909@azairenet.com> Date: Fri, 28 Sep 2007 04:48:54 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: DE JUAN HUARTE FEDERICO Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> <319D54578EAC3147BA8CC78DAB5467A501399AEB@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399AEB@FRVELSMBS12.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org DE JUAN HUARTE FEDERICO wrote: > Hi Sri, > > I have seen several times now statements that the LMA would only have one binding per MN. > I'm a bit puzzled by this. > > In MIP6 AFAIK the HA may have multiple bindings per MN (multiple CoA) but only one of them is primary. > The statement that there's only one single binding per MN makes me think that this feature is not supported by PMIP6. > Has this been discussed earlier? If yes I'll dig up the archives to catch up. Multiple CoA support is only possible through monami6. Currently we don't support that with PMIPv6. The base PMIPv6 document assumes there is only MAG registered with the LMA at a time for a particular mobile node. Vijay > > Thanks > > federico > > > > -----Message d'origine----- > De : Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Envoyé : mercredi 26 septembre 2007 16:15 > À : ext Kilian Weniger > Cc : netlmm@ietf.org > Objet : Re: [netlmm] Issue: Prefix allocation and multihomed MNs > > > Kilian, > > While it is possible that a multi-interface MN can attach to different MAGs which cause the MAGs to send a PBU to the same LMA, I personally think that dealing with this is more of an academic exercise at the present time. > > I do not believe we have the possibility of making any changes to the MN. So that route is closed... At least for now. > > So here is how I view the current scenario which IMO is academic at this time and hence not something that we should be spending a lot of time on : > > - If an MN attaches to multiple MAGs via different interfaces this would trigger the MAGs to send PBUs to the LMA > - If the LMA receives them almost simultaneously (as an example), and a PBAck has not been sent, then the LMA can choose to create an entry in the BC for the last received PBU and ACK only the last received PBU (the LMA would believe that the MN which attached to MAG1 moved to MAG2 resulting in the transmission of PBUs from MAG1 and MAG2 near simulatenously) > - If the MN receives a PBU from another MAG for an MN which has an entry in the BC as a result of a second interface attaching to a MAG, the LMA would view this as the MN having moved to MAG2 and hence would delete the BCE for > MAG1 and insert MAG2 for the MN > > But if we merely state (or mandate) that the LMA will only have only one MAG entry in the BC at any given time, we would not have a problem with the multi-homing scenario, right? > > -Raj > > > > > On 9/26/07 8:10 AM, "ext Kilian Weniger" > wrote: > >> Hi Raj, >> >> I think we should differentiate between two cases: >> 1. supporting multi-homing requested by the host to achieve features >> like load balancing, failover etc. >> 2. preventing that PMIP protocol breaks if an unmodified host >> activates more than one network interface. >> >> For case 1, I agree with you that this is out of scope of the base >> draft and should be handled in a separate multi-homing document. >> >> But I think Vidya was talking about case 2 and I agree that this issue >> should be addressed in the base draft. >> >> Currently, I see the following potential issues if an unmodified host >> activates more than one network interface and happens to attach to >> more than one MAG of a given PMIP domain simultaneously: >> - multiple MN interfaces get the same prefix assigned, which may break >> something (e.g., routing) in the host and may result in loss of >> connectivity >> - BCE at LMA constantly and randomly changes since multiple MAGs send >> PBUs to the LMA for the same MN. This may result in packet loss both >> in downlink and uplink. >> - the MAGs may discover and use different LMA addresses for the same >> host etc. >> >> However, I'm not sure how we can solve this issue without modifying >> the host or mandating not to use multiple interfaces. Any ideas? >> >> BR, >> >> Kilian >> >> >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>> Sent: Mittwoch, 26. September 2007 13:50 >>> To: ext Kilian Weniger; Narayanan, Vidya >>> Cc: netlmm@ietf.org >>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>> >>> >>> Kilian, >>> >>> >>> >>> >>> On 9/26/07 3:57 AM, "ext Kilian Weniger" >>> >>> wrote: >>> >>>> Hi Vidya, >>>> >>>> I agree that we need some text about this issue. >>>> >>>> Narayanan, Vidya wrote: >>>>> - define LMA behavior such that regular multihomed IP devices don't >>>>> run into issues of connectivity or shutting down interfaces. >>> This is much >>>>> more logical in my view and it is not a big change in the document. >>>> Can you elaborate how this would work? How does the LMA >>> differentiate >>>> between PBUs that were triggered by the same vs different >>> MN interfaces? >>>> >>>> I guess the MAG would need to include some kind of MN >>> physical network >>>> interface ID in the PBU, but what kind of ID would that be >>> and how does >>>> the MAG learn that ID? Note that the MN's link-local address may not >>>> work as an ID in general, since the MN may implement a kind >>> of virtual >>>> network interface which hides multiple physical network >>> interfaces and >>>> only exposes a single (virtual) network interface to the IP >>> stack. This >>>> may result in the same link-local address for multiple physical >>>> interfaces. >>>> >>>> So do we need to mandate something on the MN side to solve >>> this issue in >>>> the general case? >>> One of the tenets of Netlmm protocol has been to not require any >>> changes or requirements on the MN. So it is not an option. >>> >>> Issues that arise from multi-homing and how to deal with them should >>> be dealt separately and not in the scope of this I-D. >>> >>> -Raj >>> >>>> Kilian >>>> >>>> >>>> Panasonic R&D Center Germany GmbH >>>> 63225 Langen, Hessen, Germany >>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke >>>> >>>> >>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >>> >> >> Panasonic R&D Center Germany GmbH >> 63225 Langen, Hessen, Germany >> Reg: AG Offenbach (Hessen) HRB 33974 >> Managing Director: Thomas Micke >> >> > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 08:06:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEcG-0001tt-Qc; Fri, 28 Sep 2007 08:06:44 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbEcF-0001p3-Ng for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 08:06:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEcF-0001dO-BU for netlmm@ietf.org; Fri, 28 Sep 2007 08:06:43 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbEcA-0004DL-EP for netlmm@ietf.org; Fri, 28 Sep 2007 08:06:39 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1190981197!22531529!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 29178 invoked from network); 28 Sep 2007 12:06:37 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-5.tower-119.messagelabs.com with SMTP; 28 Sep 2007 12:06:37 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l8SC6VUO010156; Fri, 28 Sep 2007 05:06:31 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l8SC6UA5012485; Fri, 28 Sep 2007 07:06:31 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8SC6SYJ012465; Fri, 28 Sep 2007 07:06:29 -0500 (CDT) Message-ID: <46FCEE43.3070701@gmail.com> Date: Fri, 28 Sep 2007 14:06:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> <319D54578EAC3147BA8CC78DAB5467A501399AEB@FRVELSMBS12.ad2.ad.alcatel.com> <46FCEA26.8020909@azairenet.com> In-Reply-To: <46FCEA26.8020909@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 000777-1, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Vijay Devarapalli wrote: > DE JUAN HUARTE FEDERICO wrote: >> Hi Sri, >> >> I have seen several times now statements that the LMA would only >> have one binding per MN. I'm a bit puzzled by this. >> >> In MIP6 AFAIK the HA may have multiple bindings per MN (multiple >> CoA) but only one of them is primary. The statement that there's >> only one single binding per MN makes me think that this feature is >> not supported by PMIP6. Has this been discussed earlier? If yes >> I'll dig up the archives to catch up. > > Multiple CoA support is only possible through monami6. Currently we > don't support that with PMIPv6. The base PMIPv6 document assumes > there is only MAG registered with the LMA at a time for a particular > mobile node. That is a problem. MIP6 allows the MN to use two different interfaces, each with a different HoA. Monami6 is not needed for that MIP6 to work. One can't require Monami6 for PMIP6 in order for a MN to use two interfaces. PMIP6 relying its identifications on a unique 'MN-Id' for the mobile is not good. If the MN could have several such MN-Ids, each attached to an interface then PMIP6 relying on MN-Id concept could work. In this sense, the easiest way for MN-Id is to actually be an address. Alex > > Vijay > >> >> Thanks >> >> federico >> >> >> >> -----Message d'origine----- De : Basavaraj Patil >> [mailto:basavaraj.patil@nsn.com] Envoyé : mercredi 26 septembre >> 2007 16:15 À : ext Kilian Weniger Cc : netlmm@ietf.org Objet : Re: >> [netlmm] Issue: Prefix allocation and multihomed MNs >> >> >> Kilian, >> >> While it is possible that a multi-interface MN can attach to >> different MAGs which cause the MAGs to send a PBU to the same LMA, >> I personally think that dealing with this is more of an academic >> exercise at the present time. >> >> I do not believe we have the possibility of making any changes to >> the MN. So that route is closed... At least for now. >> >> So here is how I view the current scenario which IMO is academic at >> this time and hence not something that we should be spending a lot >> of time on : >> >> - If an MN attaches to multiple MAGs via different interfaces this >> would trigger the MAGs to send PBUs to the LMA - If the LMA >> receives them almost simultaneously (as an example), and a PBAck >> has not been sent, then the LMA can choose to create an entry in >> the BC for the last received PBU and ACK only the last received PBU >> (the LMA would believe that the MN which attached to MAG1 moved to >> MAG2 resulting in the transmission of PBUs from MAG1 and MAG2 near >> simulatenously) - If the MN receives a PBU from another MAG for an >> MN which has an entry in the BC as a result of a second interface >> attaching to a MAG, the LMA would view this as the MN having moved >> to MAG2 and hence would delete the BCE for MAG1 and insert MAG2 for >> the MN >> >> But if we merely state (or mandate) that the LMA will only have >> only one MAG entry in the BC at any given time, we would not have a >> problem with the multi-homing scenario, right? >> >> -Raj >> >> >> >> >> On 9/26/07 8:10 AM, "ext Kilian Weniger" >> wrote: >> >>> Hi Raj, >>> >>> I think we should differentiate between two cases: 1. supporting >>> multi-homing requested by the host to achieve features like load >>> balancing, failover etc. 2. preventing that PMIP protocol breaks >>> if an unmodified host activates more than one network interface. >>> >>> For case 1, I agree with you that this is out of scope of the >>> base draft and should be handled in a separate multi-homing >>> document. >>> >>> But I think Vidya was talking about case 2 and I agree that this >>> issue should be addressed in the base draft. >>> >>> Currently, I see the following potential issues if an unmodified >>> host activates more than one network interface and happens to >>> attach to more than one MAG of a given PMIP domain >>> simultaneously: - multiple MN interfaces get the same prefix >>> assigned, which may break something (e.g., routing) in the host >>> and may result in loss of connectivity - BCE at LMA constantly >>> and randomly changes since multiple MAGs send PBUs to the LMA for >>> the same MN. This may result in packet loss both in downlink and >>> uplink. - the MAGs may discover and use different LMA addresses >>> for the same host etc. >>> >>> However, I'm not sure how we can solve this issue without >>> modifying the host or mandating not to use multiple interfaces. >>> Any ideas? >>> >>> BR, >>> >>> Kilian >>> >>> >>>> -----Original Message----- From: Basavaraj Patil >>>> [mailto:basavaraj.patil@nsn.com] Sent: Mittwoch, 26. September >>>> 2007 13:50 To: ext Kilian Weniger; Narayanan, Vidya Cc: >>>> netlmm@ietf.org Subject: Re: [netlmm] Issue: Prefix allocation >>>> and multihomed MNs >>>> >>>> >>>> Kilian, >>>> >>>> >>>> >>>> >>>> On 9/26/07 3:57 AM, "ext Kilian Weniger" >>>> wrote: >>>> >>>>> Hi Vidya, >>>>> >>>>> I agree that we need some text about this issue. >>>>> >>>>> Narayanan, Vidya wrote: >>>>>> - define LMA behavior such that regular multihomed IP >>>>>> devices don't run into issues of connectivity or shutting >>>>>> down interfaces. >>>> This is much >>>>>> more logical in my view and it is not a big change in the >>>>>> document. >>>>> Can you elaborate how this would work? How does the LMA >>>> differentiate >>>>> between PBUs that were triggered by the same vs different >>>> MN interfaces? >>>>> >>>>> I guess the MAG would need to include some kind of MN >>>> physical network >>>>> interface ID in the PBU, but what kind of ID would that be >>>> and how does >>>>> the MAG learn that ID? Note that the MN's link-local address >>>>> may not work as an ID in general, since the MN may implement >>>>> a kind >>>> of virtual >>>>> network interface which hides multiple physical network >>>> interfaces and >>>>> only exposes a single (virtual) network interface to the IP >>>> stack. This >>>>> may result in the same link-local address for multiple >>>>> physical interfaces. >>>>> >>>>> So do we need to mandate something on the MN side to solve >>>> this issue in >>>>> the general case? >>>> One of the tenets of Netlmm protocol has been to not require >>>> any changes or requirements on the MN. So it is not an option. >>>> >>>> Issues that arise from multi-homing and how to deal with them >>>> should be dealt separately and not in the scope of this I-D. >>>> >>>> -Raj >>>> >>>>> Kilian >>>>> >>>>> >>>>> Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, >>>>> Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing >>>>> Director: Thomas Micke >>>>> >>>>> >>>>> >>>>> _______________________________________________ netlmm >>>>> mailing list netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>> >>>> >>> >>> Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas >>> Micke >>> >>> >> >> >> _______________________________________________ netlmm mailing list >> netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm >> >> >> _______________________________________________ netlmm mailing list >> netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > _______________________________________________ netlmm mailing list > netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 08:17:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEmK-0008W0-KZ; Fri, 28 Sep 2007 08:17:08 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbEmJ-0008S6-Fp for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 08:17:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEmJ-0008QQ-02 for netlmm@ietf.org; Fri, 28 Sep 2007 08:17:07 -0400 Received: from cluster-h.mailcontrol.com ([85.115.42.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbEmI-0004OU-A9 for netlmm@ietf.org; Fri, 28 Sep 2007 08:17:06 -0400 Received: from rly01h.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly01h.srv.mailcontrol.com (MailControl) with ESMTP id l8SCGx3m001698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Sep 2007 13:17:00 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly01h.srv.mailcontrol.com (MailControl) id l8SCGCs2031206 for netlmm@ietf.org; Fri, 28 Sep 2007 13:16:12 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly01h-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8SCGAa5031144; Fri, 28 Sep 2007 13:16:12 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 25f7_f74170cc_6dbb_11dc_95c0_0030482aac25; Fri, 28 Sep 2007 14:11:38 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092814160603-25119 ; Fri, 28 Sep 2007 14:16:06 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.099,BAYES_00: -1.665,TOTAL_SCORE: -1.566 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 28 Sep 2007 14:15:52 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: <46FC7002.9060909@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgBfOMl5m9ti9ZOTWatN8r6aIoHSwAOn5Eg References: <46FC7002.9060909@azairenet.com> To: "Vijay Devarapalli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8EAC@lan-ex-02.panasonic.de> Date: Fri, 28 Sep 2007 14:11:05 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.72.1.111 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vijay, > Having a binding revocation mechanism will help in recovering sooner.=20 > The LMA would have sent a revocation mechanism to MAG1 when=20 > MAG2 sent a=20 > proxy BU. MAG1 would check if the MN is still attached, if yes would=20 > send a proxy BU again. MAG2 won't try to send a proxy BU once=20 > the mobile=20 > node's interface 2 goes down. I couldn't find any text in draft-muhanna-mip6-binding-revocation-01.txt that says that a MAG should send a new PBU after receiving Binding Revocation Indication (BRI) msg.=20 According to current text, MAG1 would clean up ressources and unicast RA message to the MN local link IP address with the home network prefix lifetime is set to zero. "3.2.2. Use Case No. 2: LMA to MAG In this case, LMA MAY send a BRI message to the MAG, hosting a specific MN mobile IPv6 session, to indicate that the mobile IPv6 binding of a specific MN session, which is registered and anchored at the LMA, has been revoked and MAG can clean up the associated resources. If the MAG processes the BRI message, the MAG MUST send a BRA message in response to the LMA if the A bit in the BRI message is set. In this case, the MAG SHOULD send a unicast RA message to the MN local link IP address with the home network prefix lifetime is set to zero." I guess what you proposed requires changes to the revocation message format (e.g., a new flag in the BRI) and processing of revocation messages, right?=20 BR, Kilian >=20 > Vijay >=20 > >=20 > > Hope that clarifies.=20 > >=20 > > Vidya=20 > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > >> Sent: Thursday, September 27, 2007 10:38 AM > >> To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev > >> Cc: ext Kilian Weniger; netlmm@ietf.org > >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > >> > >> > >> Vidya, > >> > >> Just for my education, can you please explain why the MN=20 > >> would shutdown both interfaces if it were to receive the same=20 > >> prefix on another interface on a multi-interface host? > >> I guess I could dig up the archives... But if you can explain=20 > >> the issue behind such behavior, I would appreciate it. > >> > >> -Raj > >> > >> > >> On 9/27/07 12:31 PM, "ext Narayanan, Vidya"=20 > >> wrote: > >> > >>> Sri, > >>> You seem to be missing the point. We are not dealing with=20 > >>> multi-interface support issues in this thread. What we=20 > are dealing=20 > >>> with is the fact that an MN may not be able to use *any*=20 > interface=20 > >>> simply because it happens to have two interfaces. Unless=20 > >> the MN knows=20 > >>> that the network is using PMIP and hence, it can only use one=20 > >>> interface at a time, you are going to have regular IP nodes=20 > >> that run into this problem. > >>> > >>> In a nutshell, the problem is about an MN ending up with no=20 > >> IP service=20 > >>> using even one of its interfaces. > >>> > >>> I hope you can see that the problem doesn't relate to providing=20 > >>> multihoming to the MN; rather it relates to something far more=20 > >>> fundamental that this protocol is supposed to ensure - IP=20 > >> connectivity=20 > >>> to the MN. > >>> > >>> Vidya > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 08:17:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEmX-0000Pl-Sn; Fri, 28 Sep 2007 08:17:21 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbEmX-0000Pg-0o for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 08:17:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbEmW-0000PY-Lc for netlmm@ietf.org; Fri, 28 Sep 2007 08:17:20 -0400 Received: from cluster-h.mailcontrol.com ([85.115.42.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbEmW-0004P2-13 for netlmm@ietf.org; Fri, 28 Sep 2007 08:17:20 -0400 Received: from rly13h.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly13h.srv.mailcontrol.com (MailControl) with ESMTP id l8SCHDCY020852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Sep 2007 13:17:13 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly13h.srv.mailcontrol.com (MailControl) id l8SCGGnJ017741 for netlmm@ietf.org; Fri, 28 Sep 2007 13:16:16 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly13h-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l8SCGCGI017511; Fri, 28 Sep 2007 13:16:16 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 262c_f865b9d6_6dbb_11dc_8261_0030482aac25; Fri, 28 Sep 2007 14:11:40 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092814160843-25121 ; Fri, 28 Sep 2007 14:16:08 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.098,BAYES_00: -1.665,TOTAL_SCORE: -1.567 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 28 Sep 2007 14:15:52 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399ADA@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: Acf/sdrXSWxVJRmzQ6G5BsvD3b9qQQAKS7SgAAzXM0AAQwyTcAAne6bA References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> <319D54578EAC3147BA8CC78DAB5467A501399ADA@FRVELSMBS12.ad2.ad.alcatel.com> To: "DE JUAN HUARTE FEDERICO" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8EAB@lan-ex-02.panasonic.de> Date: Fri, 28 Sep 2007 14:11:08 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.72.1.123 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Frederico,=20 one way to identify a compromised MAG is to rely on notifications from = multiple MAGs and trust the opinion of the majority: If the LMA detects = the situation that two MAGs simultaneously claim attachment of same MN = multiple times and one of the MAGs is always MAG X while the other one = is different each time, the LMA can be pretty sure that MAG X is the = compromised MAG. BR, Kilian > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Donnerstag, 27. September 2007 20:01 > To: Kilian Weniger > Cc: netlmm@ietf.org > Subject: RE: Compromised MAG issue (was [netlmm] Review=20 > ofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Killian, >=20 > I had been told that this problem was out of scope ... > From your input: > Killian> Hence, after receiving one or more such=20 > notifications, the LMA can identify the compromised MAG and=20 > stop trusting this MAG. > How does the LMA identify the compromised MAG? >=20 > Regards >=20 > federico >=20 > -----Message d'origine----- > De : Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > Envoy=E9 : mercredi 26 septembre 2007 10:57 > =C0 : Narayanan, Vidya > Cc : netlmm@ietf.org > Objet : Compromised MAG issue (was [netlmm] Review=20 > ofdraft-ietf-netlmm-proxymip6-05) >=20 > Narayanan, Vidya wrote: > > > > - Security considerations: MAG Compromise:=20 > ... > > If we claim this is an issue in the security considerations section=20 > > and claim that the fix to it is for the LMA to ensure the MN is=20 > > actually attached to the MAG, we can't quite hand wave on some=20 > > possible ways to do that. Those are just hints for=20 > deployments that=20 > > are concerned about MAG compromise. But, those hints need to be=20 > > captured in the security considerations section. The=20 > threats document=20 > > captures this threat and it is a valid one - so, I believe we need=20 > > some text here. The type of "detail" is what I tried to=20 > provide with=20 > > the examples on AAA checks or CGA signatures - and, I don't=20 > think we=20 > > need a lot of detail here; a few sentences would be good. > >=20 >=20 > I had a similar comment a while ago. I think that a draft describing a > severe security issue should at least give hints how this can=20 > be solved. >=20 > Recently Sri, Vijay, Kuntal and I had an offline discussion about > another possible solution to detect a compromised MAGs, which=20 > relies on > PMIP signaling only. >=20 > The basic idea is that if two MAGs simultaneously claim that the MN is > attached, one of the MAGs must lie and is probably a compromised MAG. > The assumption is that the MN cannot at the same time be=20 > attached to two > MAGs, at least not with the same network interface. >=20 > More specifically, when the LMA accepts a valid PBU from a new MAG, it > changes the BCE (i.e., there is no impact on handover delay) and > notifies the old MAG (i.e., old address in BCE) about this.=20 > The old MAG > then checks whether the MN is still attached. If this is the case, it > informs the LMA about this. The LMA then learns that two=20 > different MAGs > claim MN attachement, which is not possible under the=20 > assumption stated > above. Hence, after receiving one or more such notifications, the LMA > can identify the compromised MAG and stop trusting this MAG. >=20 > A remaining problem was which message should be used to inform the old > MAG about the BCE change. PBA and revocation msg were=20 > discussed, but the > former is not sent unsolicited according to RFC3775 (which could be > overidden by PMIP spec of course) and the latter is not standardized > yet. >=20 > Comments? >=20 > Kilian >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 08:32:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbF13-00042Q-4g; Fri, 28 Sep 2007 08:32:21 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbF11-00042K-Th for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 08:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbF11-00042C-KA for netlmm@ietf.org; Fri, 28 Sep 2007 08:32:19 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbF10-0006b5-Ey for netlmm@ietf.org; Fri, 28 Sep 2007 08:32:19 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007092808320515889 ; Fri, 28 Sep 2007 08:32:05 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.073,BAYES_00: -1.665 X-Spam-Level: Received: from [127.0.0.1] ([10.24.113.49]) by s-utl01-atpop.stsn.net; Fri, 28 Sep 2007 08:32:03 -0400 Message-ID: <46FCF435.200@azairenet.com> Date: Fri, 28 Sep 2007 05:31:49 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: <46FC7002.9060909@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8EAC@lan-ex-02.panasonic.de> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8EAC@lan-ex-02.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Kilian Weniger wrote: > Hi Vijay, > >> Having a binding revocation mechanism will help in recovering sooner. >> The LMA would have sent a revocation mechanism to MAG1 when >> MAG2 sent a >> proxy BU. MAG1 would check if the MN is still attached, if yes would >> send a proxy BU again. MAG2 won't try to send a proxy BU once >> the mobile >> node's interface 2 goes down. > > I couldn't find any text in draft-muhanna-mip6-binding-revocation-01.txt > that says that a MAG should send a new PBU after receiving Binding > Revocation Indication (BRI) msg. When the MAG gets a revocation, it obviously checks if the MN is still attached. It is true that draft-muhanna-mip6-binding-revocation-01, but then the revocation draft is a "work in progress". :) Vijay > > According to current text, MAG1 would clean up ressources and unicast RA > message to the MN local link IP address with the home network prefix > lifetime is set to zero. > > "3.2.2. Use Case No. 2: LMA to MAG > > In this case, LMA MAY send a BRI message to the MAG, hosting a > specific MN mobile IPv6 session, to indicate that the mobile IPv6 > binding of a specific MN session, which is registered and anchored at > the LMA, has been revoked and MAG can clean up the associated > resources. If the MAG processes the BRI message, the MAG MUST send a > BRA message in response to the LMA if the A bit in the BRI message is > set. In this case, the MAG SHOULD send a unicast RA message to the > MN local link IP address with the home network prefix lifetime is set > to zero." > > I guess what you proposed requires changes to the revocation message > format (e.g., a new flag in the BRI) and processing of revocation > messages, right? > > > BR, > > Kilian > > >> Vijay >> >>> Hope that clarifies. >>> >>> Vidya >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Thursday, September 27, 2007 10:38 AM >>>> To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev >>>> Cc: ext Kilian Weniger; netlmm@ietf.org >>>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>>> >>>> >>>> Vidya, >>>> >>>> Just for my education, can you please explain why the MN >>>> would shutdown both interfaces if it were to receive the same >>>> prefix on another interface on a multi-interface host? >>>> I guess I could dig up the archives... But if you can explain >>>> the issue behind such behavior, I would appreciate it. >>>> >>>> -Raj >>>> >>>> >>>> On 9/27/07 12:31 PM, "ext Narayanan, Vidya" >>>> wrote: >>>> >>>>> Sri, >>>>> You seem to be missing the point. We are not dealing with >>>>> multi-interface support issues in this thread. What we >> are dealing >>>>> with is the fact that an MN may not be able to use *any* >> interface >>>>> simply because it happens to have two interfaces. Unless >>>> the MN knows >>>>> that the network is using PMIP and hence, it can only use one >>>>> interface at a time, you are going to have regular IP nodes >>>> that run into this problem. >>>>> In a nutshell, the problem is about an MN ending up with no >>>> IP service >>>>> using even one of its interfaces. >>>>> >>>>> I hope you can see that the problem doesn't relate to providing >>>>> multihoming to the MN; rather it relates to something far more >>>>> fundamental that this protocol is supposed to ensure - IP >>>> connectivity >>>>> to the MN. >>>>> >>>>> Vidya >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> >> >> >> > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 09:04:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFWc-0001Fp-0r; Fri, 28 Sep 2007 09:04:58 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbFWb-0001Ak-8r for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFWa-0001AZ-VD for netlmm@ietf.org; Fri, 28 Sep 2007 09:04:56 -0400 Received: from airmax.sfc.wide.ad.jp ([203.178.143.74] helo=mail.wakikawa.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbFWS-0007i2-7H for netlmm@ietf.org; Fri, 28 Sep 2007 09:04:56 -0400 Received: (qmail 87292 invoked from network); 28 Sep 2007 22:02:52 +0000 Received: from unknown (HELO ?203.178.143.223?) (ryuji@203.178.143.223) by 0 with SMTP; 28 Sep 2007 22:02:52 +0000 In-Reply-To: <46FCEA26.8020909@azairenet.com> References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> <319D54578EAC3147BA8CC78DAB5467A501399AEB@FRVELSMBS12.ad2.ad.alcatel.com> <46FCEA26.8020909@azairenet.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: RYUJI WAKIKAWA Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 22:04:17 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On 2007/09/28, at 20:48, Vijay Devarapalli wrote: > DE JUAN HUARTE FEDERICO wrote: >> Hi Sri, >> I have seen several times now statements that the LMA would only =20 >> have one binding per MN. >> I'm a bit puzzled by this. >> In MIP6 AFAIK the HA may have multiple bindings per MN (multiple =20 >> CoA) but only one of them is primary. >> The statement that there's only one single binding per MN makes me =20= >> think that this feature is not supported by PMIP6. >> Has this been discussed earlier? If yes I'll dig up the archives =20 >> to catch up. > > Multiple CoA support is only possible through monami6. Currently we =20= > don't support that with PMIPv6. The base PMIPv6 document assumes =20 > there is only MAG registered with the LMA at a time for a =20 > particular mobile node. Right. and MCoA is out of scope in netlmm. Even if PMIP work with MCoA, MN cannot utilize the same HoA to two =20 interfaces... I am not sure it is useful to consider MCoA here. ryuji > Vijay > >> Thanks >> federico >> -----Message d'origine----- >> De : Basavaraj Patil [mailto:basavaraj.patil@nsn.com] Envoy=E9 : =20 >> mercredi 26 septembre 2007 16:15 >> =C0 : ext Kilian Weniger >> Cc : netlmm@ietf.org >> Objet : Re: [netlmm] Issue: Prefix allocation and multihomed MNs >> Kilian, >> While it is possible that a multi-interface MN can attach to =20 >> different MAGs which cause the MAGs to send a PBU to the same LMA, =20= >> I personally think that dealing with this is more of an academic =20 >> exercise at the present time. >> I do not believe we have the possibility of making any changes to =20 >> the MN. So that route is closed... At least for now. >> So here is how I view the current scenario which IMO is academic =20 >> at this time and hence not something that we should be spending a =20 >> lot of time on : >> - If an MN attaches to multiple MAGs via different interfaces this =20= >> would trigger the MAGs to send PBUs to the LMA >> - If the LMA receives them almost simultaneously (as an example), =20 >> and a PBAck has not been sent, then the LMA can choose to create =20 >> an entry in the BC for the last received PBU and ACK only the last =20= >> received PBU (the LMA would believe that the MN which attached to =20 >> MAG1 moved to MAG2 resulting in the transmission of PBUs from MAG1 =20= >> and MAG2 near simulatenously) >> - If the MN receives a PBU from another MAG for an MN which has an =20= >> entry in the BC as a result of a second interface attaching to a =20 >> MAG, the LMA would view this as the MN having moved to MAG2 and =20 >> hence would delete the BCE for >> MAG1 and insert MAG2 for the MN >> But if we merely state (or mandate) that the LMA will only have =20 >> only one MAG entry in the BC at any given time, we would not have =20 >> a problem with the multi-homing scenario, right? >> -Raj >> On 9/26/07 8:10 AM, "ext Kilian Weniger" =20 >> >> wrote: >>> Hi Raj, >>> >>> I think we should differentiate between two cases: >>> 1. supporting multi-homing requested by the host to achieve =20 >>> features like load balancing, failover etc. >>> 2. preventing that PMIP protocol breaks if an unmodified host =20 >>> activates more than one network interface. >>> >>> For case 1, I agree with you that this is out of scope of the =20 >>> base draft and should be handled in a separate multi-homing =20 >>> document. >>> >>> But I think Vidya was talking about case 2 and I agree that this =20 >>> issue should be addressed in the base draft. >>> >>> Currently, I see the following potential issues if an unmodified =20 >>> host activates more than one network interface and happens to =20 >>> attach to more than one MAG of a given PMIP domain simultaneously: >>> - multiple MN interfaces get the same prefix assigned, which may =20 >>> break something (e.g., routing) in the host and may result in =20 >>> loss of connectivity >>> - BCE at LMA constantly and randomly changes since multiple MAGs =20 >>> send PBUs to the LMA for the same MN. This may result in packet =20 >>> loss both in downlink and uplink. >>> - the MAGs may discover and use different LMA addresses for the =20 >>> same host etc. >>> >>> However, I'm not sure how we can solve this issue without =20 >>> modifying the host or mandating not to use multiple interfaces. =20 >>> Any ideas? >>> >>> BR, >>> >>> Kilian >>> >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Mittwoch, 26. September 2007 13:50 >>>> To: ext Kilian Weniger; Narayanan, Vidya >>>> Cc: netlmm@ietf.org >>>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>>> >>>> >>>> Kilian, >>>> >>>> >>>> >>>> >>>> On 9/26/07 3:57 AM, "ext Kilian Weniger" >>>> >>>> wrote: >>>> >>>>> Hi Vidya, >>>>> >>>>> I agree that we need some text about this issue. >>>>> >>>>> Narayanan, Vidya wrote: >>>>>> - define LMA behavior such that regular multihomed IP devices =20 >>>>>> don't run into issues of connectivity or shutting down =20 >>>>>> interfaces. >>>> This is much >>>>>> more logical in my view and it is not a big change in the =20 >>>>>> document. >>>>> Can you elaborate how this would work? How does the LMA >>>> differentiate >>>>> between PBUs that were triggered by the same vs different >>>> MN interfaces? >>>>> >>>>> I guess the MAG would need to include some kind of MN >>>> physical network >>>>> interface ID in the PBU, but what kind of ID would that be >>>> and how does >>>>> the MAG learn that ID? Note that the MN's link-local address =20 >>>>> may not work as an ID in general, since the MN may implement a =20 >>>>> kind >>>> of virtual >>>>> network interface which hides multiple physical network >>>> interfaces and >>>>> only exposes a single (virtual) network interface to the IP >>>> stack. This >>>>> may result in the same link-local address for multiple physical =20= >>>>> interfaces. >>>>> >>>>> So do we need to mandate something on the MN side to solve >>>> this issue in >>>>> the general case? >>>> One of the tenets of Netlmm protocol has been to not require any =20= >>>> changes or requirements on the MN. So it is not an option. >>>> >>>> Issues that arise from multi-homing and how to deal with them =20 >>>> should be dealt separately and not in the scope of this I-D. >>>> >>>> -Raj >>>> >>>>> Kilian >>>>> >>>>> >>>>> Panasonic R&D Center Germany GmbH >>>>> 63225 Langen, Hessen, Germany >>>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas =20 >>>>> Micke >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>> >>>> >>> >>> Panasonic R&D Center Germany GmbH >>> 63225 Langen, Hessen, Germany >>> Reg: AG Offenbach (Hessen) HRB 33974 >>> Managing Director: Thomas Micke >>> >>> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 09:08:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFZz-0005qn-7M; Fri, 28 Sep 2007 09:08:27 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbFZy-0005lo-7L for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:08:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFZx-0005Xd-Qw for netlmm@ietf.org; Fri, 28 Sep 2007 09:08:25 -0400 Received: from airmax.sfc.wide.ad.jp ([203.178.143.74] helo=mail.wakikawa.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbFZs-0006Hx-Kw for netlmm@ietf.org; Fri, 28 Sep 2007 09:08:21 -0400 Received: (qmail 87305 invoked from network); 28 Sep 2007 22:06:52 +0000 Received: from unknown (HELO ?203.178.143.223?) (ryuji@203.178.143.223) by 0 with SMTP; 28 Sep 2007 22:06:52 +0000 In-Reply-To: <00c201c8012f$2dabe5b0$1220fea9@amer.cisco.com> References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> <00ba01c8012b$84300460$1220fea9@amer.cisco.com> <00c201c8012f$2dabe5b0$1220fea9@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F633DFC-3181-42E0-B284-4B1DC732F1BB@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 22:08:16 +0900 To: Sri Gundavelli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: 'ext Kilian Weniger' , netlmm@ietf.org, 'Genadi Velev' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri On 2007/09/28, at 2:52, Sri Gundavelli wrote: > Vidya, > > We are not dealing with >> multi-interface support issues in this thread. What we are >> dealing with >> is the fact that an MN may not be able to use *any* interface simply >> because it happens to have two interfaces. > > If we are not dealing with multi-interface support, we dont > need to talk about the scenario where the MN has multiple active > interfaces. This is not the right interpretation of the charter, > IMHO. > > If operators want to deal with this, let them configure a unique > NAI for each interface and even when multiple interfaces are > active, each interface will endup with a unique prefix. I think this is one way to avoid this multi-interface issue. You can mention in the doc that MN should have different NAI per interfaces if it has multiple interfaces attached to the PMIP domain. regards, ryuji > > Sri > > > >> -----Original Message----- >> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >> Sent: Thursday, September 27, 2007 10:32 AM >> To: Sri Gundavelli; Genadi Velev >> Cc: ext Kilian Weniger; netlmm@ietf.org >> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >> >> Sri, >> You seem to be missing the point. We are not dealing with >> multi-interface support issues in this thread. What we are >> dealing with >> is the fact that an MN may not be able to use *any* interface simply >> because it happens to have two interfaces. Unless the MN >> knows that the >> network is using PMIP and hence, it can only use one interface at a >> time, you are going to have regular IP nodes that run into >> this problem. >> >> >> In a nutshell, the problem is about an MN ending up with no IP >> service >> using even one of its interfaces. >> >> I hope you can see that the problem doesn't relate to providing >> multihoming to the MN; rather it relates to something far more >> fundamental that this protocol is supposed to ensure - IP >> connectivity >> to the MN. >> >> Vidya >> >>> -----Original Message----- >>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>> Sent: Thursday, September 27, 2007 10:26 AM >>> To: Narayanan, Vidya; 'Genadi Velev' >>> Cc: 'ext Kilian Weniger'; netlmm@ietf.org >>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >>> >>> Hi Vidya, >>> >>> >>> That's interesting. We dont allow inter-interface handoff, >>> but we want to deal with multi-interface support issues ? >>> We dont have to do any thing for supporting the former and >>> the later requires some work. >>> >>> The charter also does not talk about multi-homing and I >>> wonder if our decision to deal with this issue, is the right >>> one. We may need some clarification from Jari on this. >>> >>> IMO, if we really think, this breaks the protocol, operator >>> has the tools to deal with this. If a deployment has to >>> support multi-homing, there are number of things that have to >>> be place, including accounting system and other things. The >>> operator has the knobs to control this aspect, it can be >>> avoided in many different ways. >>> >>> Not sure, what other solution we have. >>> >>> Sri >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>>> Sent: Thursday, September 27, 2007 10:10 AM >>>> To: Sri Gundavelli; Genadi Velev >>>> Cc: ext Kilian Weniger; netlmm@ietf.org >>>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >>>> >>>> Hi Sri, >>>> I hope this is not news to anyone, but, we are not >>> chartered to solve >>>> inter-interface handoffs in the WG at the moment. This >> is what our >>>> charter states: >>>> >>>> "The protocol will not attempt to hide handover between two >>> separate >>>> interfaces on the mobile node. " >>>> >>>> Inter-technology handoffs being a tricky problem to handle >>> with NETLMM >>>> was identified in the early stages of charter creation. >>> So, that is >>>> not a limitation for considering some interface-specific >>> identity to >>>> be included in the PBU. >>>> >>>> Hope that helps. >>>> >>>> Regards, >>>> Vidya >>>> >>>>> -----Original Message----- >>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>>> Sent: Thursday, September 27, 2007 7:08 AM >>>>> To: 'Genadi Velev'; Narayanan, Vidya >>>>> Cc: 'ext Kilian Weniger'; netlmm@ietf.org >>>>> Subject: RE: [netlmm] Issue: Prefix allocation and >> multihomed MNs >>>>> >>>>> Hi Genadi, >>>>> >>>>>> >>>>>> If we look at the available options in PBU/PBA, we can see >>>>> that next >>>>>> to "NAI Option" (or "MN-ID option") we have a >>> "Link-local Address >>>>>> Option". >>>>>> Supposed that the link-local addresses of the multiple >>>>> interfaces are >>>>>> different, an LMA can differentiate among PBUs having the >>>>> same MN-ID >>>>>> option looking at the Link-local Address Option. IMHO, what >>>>> we need to >>>>>> specify in the PMIPv6 protocol is a behaviour in the LMA >>>>> that the HNP >>>>>> is not solely bound to a MN-ID but also to the link-local >>>>> address. In >>>>>> this way different HNPs would be assigned to PBUs >> (coming from >>>>>> different >>>>>> MAGs) containing same MN-ID option but different >>>> link-local address >>>>>> options. >>>>> >>>>> But, we need to allow handoff between two different >>> interfaces (of >>>>> different access technologies), if we keep a relation to >>> the LLA, we >>>>> cant do handoff. This scenario is more important than the >>> scenario >>>>> of simultaneous multi-access. >>>>> >>>>> Sri >>>>> >>>>> >>> > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 09:09:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFbA-0007k4-DO; Fri, 28 Sep 2007 09:09:40 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbFb8-0007cJ-R5 for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFb8-0007c4-HF for netlmm@ietf.org; Fri, 28 Sep 2007 09:09:38 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbFb2-0008A5-Ae for netlmm@ietf.org; Fri, 28 Sep 2007 09:09:38 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8SD9BT04955; Fri, 28 Sep 2007 13:09:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 08:09:06 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711704A6CD@zrc2hxm2.corp.nortel.com> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD6802AAC62F@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBAABg9sAAA7Ds6QAAB/OaAAAErRsAACrJ6QAA2LwsA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <3C31CDD06342EA4A8137716247B1CD6802AAC62F@zagh223a.ww300.siemens.net> From: "Ahmad Muhanna" To: "Premec, Domagoj" , "Narayanan, Vidya" , "Vijay Devarapalli" , "Kilian Weniger" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Domagoj, Any mechanism which is not currently defined and can not be referenced in the base PMIPv6 protocol is not to be considered a default for the PMIPv6 base protocol. Context transfer is one example. Therefore, when documenting a high level solution (hint) we need to consider the basic default scenario. Having said that and keeping it in mind, the provided text is accurate. On the other hand, we do not need to list all possible trusted entities which may have the current location of the MN in all different deployments. Again, that is out-of-scope. AAA server was listed as an example only. I hope that is good enough to close this thread and move on. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Premec, Domagoj [mailto:domagoj.premec@siemens.com]=20 > Sent: Friday, September 28, 2007 1:34 AM > To: Muhanna, Ahmad (RICH1:2H10); Narayanan, Vidya; Vijay=20 > Devarapalli; Kilian Weniger > Cc: netlmm > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Ahmad, >=20 > If we have context transfer mechanism in place between MAGs,=20 > then the MN may move to a new MAG without authentication and=20 > the AAA would not know about the new MAG. I don't think we=20 > can assume that the AAA has an accurate info on the MS location. >=20 > domagoj >=20 >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: 28. rujan 2007 07:37 > > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > > Cc: netlmm > > Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]=20 > > Review ofdraft-ietf-netlmm-proxymip6-05) > >=20 > >=20 > > All, > >=20 > > I sincerely do not want to debate the use of revocation for=20 > > compromised MAG at the present time. I am sure that all of us are=20 > > interested in getting this issue addressed properly and=20 > have it closed=20 > > sooner than later. What about the following text: > >=20 > > Current text under security consideration: > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > " > > To eliminate the threats related to a compromised mobile access > > gateway, this specification recommends that the local mobility=20 > > anchor > > before accepting a Proxy Binding Update message for a=20 > given mobile > > node, should ensure the mobile node is definitively=20 > attached to the > > mobile access gateway that sent the binding registration request. > > " > >=20 > > New Text: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > " > > To eliminate the threats related to a compromised mobile access > > gateway, this specification recommends that the local mobility=20 > > anchor > > before accepting a Proxy Binding Update message for a=20 > given mobile > > node, should ensure the mobile node is definitively=20 > attached to the > > mobile access gateway that sent the binding registration request=20 > > by contacting a trusted entity which tracks the MN current=20 > > location, > > e.g. AAA server. > > " > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Wednesday, September 26, 2007 7:41 PM > > > To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger > > > Cc: netlmm@ietf.org > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > draft-ietf-netlmm-proxymip6-05) > > >=20 > > > Hi Ahmad, > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > Sent: Wednesday, September 26, 2007 4:12 PM > > > > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > > > > Cc: netlmm@ietf.org > > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > > draft-ietf-netlmm-proxymip6-05) > > > >=20 > > > > Hi Vidya, > > > >=20 > > > > Using revocation for the compromised MAG was proposed by > > > Kilian, et.=20 > > > > al. > > > > but I am trying to help closing the issue so please allow > > > me to jump > > > > into this debate. > > > >=20 > > > > In order for the LMA to validate the presence of the MN at > > > a specific > > > > MAG, the LMA needs to do one of the followings: > > > >=20 > > > > 1. Validate the MN identity via a MN signature carried in > > > the P-BU. In > > > > P-MIPv6 this currently is not available since the P-BU is NOT=20 > > > > initiated by the MN. (the most obvious option) > > > >=20 > > > > 2. Validate the MN presence via another trusted entity that > > > > *ALWAYS* tracks the MN current location, e.g. AAA server. > > > >=20 > > > > 3. Validate the MN presence via another trusted entity that > > > tracks the > > > > current or latest location of the MN, e.g. the previous=20 > MAG using=20 > > > > binding revocation as was suggested by kilian et. al. > > > >=20 > > >=20 > > > The LMA can't assume that the pMAG is trusted while the new > > MAG is the > >=20 > > > one lying. Perhaps the MN really moved and the pMAG continues to=20 > > > claim it is there. Regardless of which MAG tells the LMA > > what, 1 or 2 > >=20 > > > needs to occur to conclude where the MN really is and=20 > then, the LMA=20 > > > can determine which of the MAGs was lying. > > >=20 > > > Regards, > > > Vidya > > >=20 > > > > 4. may be there are other ways... > > > >=20 > > > > In case that the MN is still at pMAG and has not moved, the > > > pMAG can > > > > easily indicate that in the binding revocation acknowledgement. > > > >=20 > > > > So do not you think that should work? > > > >=20 > > > > Regards, > > > > Ahmad > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > > Sent: Wednesday, September 26, 2007 3:49 PM > > > > > To: Vijay Devarapalli; Kilian Weniger > > > > > Cc: netlmm@ietf.org > > > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > > > draft-ietf-netlmm-proxymip6-05) > > > > >=20 > > > > >=20 > > > > > A few observations here. I don't believe binding revocation > > > > is going > > > > > to solve anything here. The fundamental issue is how the LMA > > > > > *identifies* the compromised MAG, not how the > > compromised MAG is > > > > > notified that its binding is no longer valid. Once=20 > the MAG is=20 > > > > > identified as compromised, a number of remedies may be taken,=20 > > > > > including, simply blacklisting the MAG and not accepting > > > > PBUs from it. =20 > > > > > It is not critical that the binding be revoked, because, > > > > the LMA has > > > > > already identified where the MN really is and it just > > > needs to use > > > > > that binding for data acceptance/forwarding. > > > > >=20 > > > > >=20 > > > > > The issue of how the LMA identifies a compromised MAG=20 > cannot be=20 > > > > > tackled without an independent verification of the > > > presence of the > > > > > MN at that particular MAG. So, we need to focus on > > > providing hints > > > > > on how the LMA may go about > > > > achieving that.=20 > > > > >=20 > > > > > Vidya > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Vijay Devarapalli > > [mailto:vijay.devarapalli@AzaireNet.com] > > > > > > Sent: Wednesday, September 26, 2007 11:08 AM > > > > > > To: Kilian Weniger > > > > > > Cc: Narayanan, Vidya; netlmm@ietf.org > > > > > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > > > > > draft-ietf-netlmm-proxymip6-05) > > > > > >=20 > > > > > > Kilian Weniger wrote: > > > > > > > Narayanan, Vidya wrote: > > > > > > >>>> - Security considerations: MAG Compromise:=20 > > > > > > > ... > > > > > > >> If we claim this is an issue in the security > > > > > > considerations section > > > > > > >> and claim that the fix to it is for the LMA to ensure > > > > the MN is > > > > > > >> actually attached to the MAG, we can't quite hand > > > wave on some > > > > > > >> possible ways to do that. Those are just hints for > > > > > > deployments that > > > > > > >> are concerned about MAG compromise. But, those hints > > > > need to be > > > > > > >> captured in the security considerations section. =20 > > > The threats > > > > > > >> document captures this threat and it is a valid one - so, > > > > > > I believe > > > > > > >> we need some text here. The type of "detail" is what > > > > I tried to > > > > > > >> provide with the examples on AAA checks or CGA > > > > > signatures - and, I > > > > > > >> don't think we need a lot of detail here; a few > > > > > sentences would be > > > > > > >> good. > > > > > > >> > > > > > > >=20 > > > > > > > I had a similar comment a while ago. I think that a draft > > > > > > describing a > > > > > > > severe security issue should at least give hints how this > > > > > > can be solved. > > > > > > >=20 > > > > > > > Recently Sri, Vijay, Kuntal and I had an offline > > > > discussion about > > > > > > > another possible solution to detect a compromised MAGs, > > > > > > which relies > > > > > > > on PMIP signaling only. > > > > > > >=20 > > > > > > > The basic idea is that if two MAGs simultaneously claim > > > > > > that the MN is > > > > > > > attached, one of the MAGs must lie and is probably a > > > > > > compromised MAG. > > > > > > > The assumption is that the MN cannot at the same time be > > > > > > attached to > > > > > > > two MAGs, at least not with the same network interface. > > > > > > >=20 > > > > > > > More specifically, when the LMA accepts a valid PBU from a > > > > > > new MAG, it > > > > > > > changes the BCE (i.e., there is no impact on handover > > > > delay) and > > > > > > > notifies the old MAG (i.e., old address in BCE) about > > > > > this. The old > > > > > > > MAG then checks whether the MN is still attached. If this > > > > > > is the case, > > > > > > > it informs the LMA about this. The LMA then=20 > learns that two > > > > > > different > > > > > > > MAGs claim MN attachement, which is not possible under the > > > > > > assumption > > > > > > > stated above. Hence, after receiving one or more such > > > > > > notifications, > > > > > > > the LMA can identify the compromised MAG and stop > > > > > trusting this MAG. > > > > > > >=20 > > > > > > > A remaining problem was which message should be used to > > > > > > inform the old > > > > > > > MAG about the BCE change. PBA and revocation msg were > > > > > > discussed, but > > > > > > > the former is not sent unsolicited according to RFC3775 > > > > > > (which could > > > > > > > be overidden by PMIP spec of course) and the=20 > latter is not=20 > > > > > > > standardized yet. > > > > > >=20 > > > > > > As I said in another threat, we really need to > > standardize the > > > > > > revocation message from the LMA to the old MAG ASAP. > > > > > >=20 > > > > > > Vijay > > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 09:18:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFjN-0006zd-7L; Fri, 28 Sep 2007 09:18:09 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbFjM-0006zY-62 for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFjL-0006yh-Ry for netlmm@ietf.org; Fri, 28 Sep 2007 09:18:07 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbFjK-0008OT-NF for netlmm@ietf.org; Fri, 28 Sep 2007 09:18:07 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1190985472!34541462!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6131 invoked from network); 28 Sep 2007 13:17:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 28 Sep 2007 13:17:52 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8SDHqrZ025221; Fri, 28 Sep 2007 06:17:52 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8SDHqdE004869; Fri, 28 Sep 2007 08:17:52 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8SDHo9q004850; Fri, 28 Sep 2007 08:17:50 -0500 (CDT) Message-ID: <46FCFEFF.7020101@gmail.com> Date: Fri, 28 Sep 2007 15:17:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> <00ba01c8012b$84300460$1220fea9@amer.cisco.com> <00c201c8012f$2dabe5b0$1220fea9@amer.cisco.com> <4F633DFC-3181-42E0-B284-4B1DC732F1BB@gmail.com> In-Reply-To: <4F633DFC-3181-42E0-B284-4B1DC732F1BB@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-1, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'ext Kilian Weniger' , netlmm@ietf.org, 'Genadi Velev' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org RYUJI WAKIKAWA wrote: > Hi Sri > > On 2007/09/28, at 2:52, Sri Gundavelli wrote: > >> Vidya, >> >> We are not dealing with >>> multi-interface support issues in this thread. What we are >>> dealing with is the fact that an MN may not be able to use *any* >>> interface simply because it happens to have two interfaces. >> >> If we are not dealing with multi-interface support, we dont need to >> talk about the scenario where the MN has multiple active >> interfaces. This is not the right interpretation of the charter, >> IMHO. >> >> If operators want to deal with this, let them configure a unique >> NAI for each interface and even when multiple interfaces are >> active, each interface will endup with a unique prefix. > > I think this is one way to avoid this multi-interface issue. You can > mention in the doc that MN should have different NAI per interfaces > if it has multiple interfaces attached to the PMIP domain. I think this can be made to work. But it sounds unnatural. An interface is identified by an address, or sometimes a number, and a user is identified by a NAI. Alex PS: especially this is an issue because HA tries to assign the HNP to the MN, at MAG. This is a problem too. The HA shouldn't try to assign addresses or HNPs in the PMIP6 signalling, for MN. And it should continue keeping BCE entries as usual in MIP6. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 09:19:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFkn-0008HG-HJ; Fri, 28 Sep 2007 09:19:37 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbFkl-0008HA-QI for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:19:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFkl-0008H2-Gi for netlmm@ietf.org; Fri, 28 Sep 2007 09:19:35 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbFkh-0008QM-7t for netlmm@ietf.org; Fri, 28 Sep 2007 09:19:35 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8SDJIT06467; Fri, 28 Sep 2007 13:19:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 08:19:10 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBAABg9sAAA7Ds6QAAB/OaAAAErRsAAF+R9AAAq6S4A= References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, It is very nice to know that we are getting into the beauty context.:) Please let us focus on all of the added text:=20 " .... by contacting a trusted entity which tracks the MN current = location, e.g. AAA server. " If AAA server is not stateful, then deployment may use another trusted = entity and that is granted by the above text. Originally I am in favor of leaving the whole thing out-of-scope all = together, but listing AAA server as an example does not eliminate any = other security mechanisms nor require that all deployment have AAA = server as stateful.=20 Do not you agree? Sincerely, If we do not have any serious objection to this text, we need = to close the issue and move on. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Friday, September 28, 2007 4:23 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: netlmm > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Ahmad, >=20 > in my understanding there's a general motivation to make AAA=20 > Servers stateless, so the draft should not put such a strong=20 > "tracking" requirement It is clear to me that in some/many=20 > deployments the AAA Server is not stateless anyway, so this=20 > is a minor comment But then, what the AAA Server actually=20 > tracks is the NAS and not really the MAG Somehow you're=20 > assuming that the AAA Server is aware of the relationship=20 > between NASs and MAGs >=20 > With the current text, the security solution was left for=20 > deployments to choose With the new text you're trying to=20 > close the solution space to one given solution Let's be fair here: > - or the security solution is discussed and we do the=20 > beauty contest with all of them > - or the security solution is not discussed and we leave=20 > the discussion for other contexts >=20 > Regards >=20 > federico >=20 >=20 >=20 > -----Message d'origine----- > De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 :=20 > vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay=20 > Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text=20 > Proposal for Compromised MAG issue (was [netlmm] Review=20 > ofdraft-ietf-netlmm-proxymip6-05) >=20 >=20 > All, >=20 > I sincerely do not want to debate the use of revocation for=20 > compromised MAG at the present time. I am sure that all of us=20 > are interested in getting this issue addressed properly and=20 > have it closed sooner than later. What about the following text: >=20 > Current text under security consideration: > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > " > To eliminate the threats related to a compromised mobile access > gateway, this specification recommends that the local=20 > mobility anchor > before accepting a Proxy Binding Update message for a given mobile > node, should ensure the mobile node is definitively attached to the > mobile access gateway that sent the binding registration request. > " >=20 > New Text: > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > " > To eliminate the threats related to a compromised mobile access > gateway, this specification recommends that the local=20 > mobility anchor > before accepting a Proxy Binding Update message for a given mobile > node, should ensure the mobile node is definitively attached to the > mobile access gateway that sent the binding registration request=20 > by contacting a trusted entity which tracks the MN current=20 > location,=20 > e.g. AAA server. > " >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Wednesday, September 26, 2007 7:41 PM > > To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger > > Cc: netlmm@ietf.org > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > draft-ietf-netlmm-proxymip6-05) > >=20 > > Hi Ahmad, > > =20 > >=20 > > > -----Original Message----- > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > Sent: Wednesday, September 26, 2007 4:12 PM > > > To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > > > Cc: netlmm@ietf.org > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > draft-ietf-netlmm-proxymip6-05) > > >=20 > > > Hi Vidya, > > >=20 > > > Using revocation for the compromised MAG was proposed by > > Kilian, et.=20 > > > al. > > > but I am trying to help closing the issue so please allow > > me to jump > > > into this debate. > > >=20 > > > In order for the LMA to validate the presence of the MN at > > a specific > > > MAG, the LMA needs to do one of the followings: > > >=20 > > > 1. Validate the MN identity via a MN signature carried in > > the P-BU. In > > > P-MIPv6 this currently is not available since the P-BU is NOT=20 > > > initiated by the MN. (the most obvious option) > > >=20 > > > 2. Validate the MN presence via another trusted entity that > > > *ALWAYS* tracks the MN current location, e.g. AAA server. > > >=20 > > > 3. Validate the MN presence via another trusted entity that > > tracks the > > > current or latest location of the MN, e.g. the previous MAG using=20 > > > binding revocation as was suggested by kilian et. al. > > >=20 > >=20 > > The LMA can't assume that the pMAG is trusted while the new=20 > MAG is the >=20 > > one lying. Perhaps the MN really moved and the pMAG continues to=20 > > claim it is there. Regardless of which MAG tells the LMA=20 > what, 1 or 2 >=20 > > needs to occur to conclude where the MN really is and then, the LMA=20 > > can determine which of the MAGs was lying. > >=20 > > Regards, > > Vidya > >=20 > > > 4. may be there are other ways... > > >=20 > > > In case that the MN is still at pMAG and has not moved, the > > pMAG can > > > easily indicate that in the binding revocation acknowledgement. > > >=20 > > > So do not you think that should work? > > >=20 > > > Regards, > > > Ahmad > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > Sent: Wednesday, September 26, 2007 3:49 PM > > > > To: Vijay Devarapalli; Kilian Weniger > > > > Cc: netlmm@ietf.org > > > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > > > draft-ietf-netlmm-proxymip6-05) > > > >=20 > > > >=20 > > > > A few observations here. I don't believe binding revocation > > > is going > > > > to solve anything here. The fundamental issue is how the LMA > > > > *identifies* the compromised MAG, not how the=20 > compromised MAG is=20 > > > > notified that its binding is no longer valid. Once the MAG is=20 > > > > identified as compromised, a number of remedies may be taken,=20 > > > > including, simply blacklisting the MAG and not accepting > > > PBUs from it. =20 > > > > It is not critical that the binding be revoked, because, > > > the LMA has > > > > already identified where the MN really is and it just > > needs to use > > > > that binding for data acceptance/forwarding. > > > >=20 > > > >=20 > > > > The issue of how the LMA identifies a compromised MAG cannot be=20 > > > > tackled without an independent verification of the > > presence of the > > > > MN at that particular MAG. So, we need to focus on > > providing hints > > > > on how the LMA may go about > > > achieving that.=20 > > > >=20 > > > > Vidya > > > >=20 > > > > > -----Original Message----- > > > > > From: Vijay Devarapalli=20 > [mailto:vijay.devarapalli@AzaireNet.com] > > > > > Sent: Wednesday, September 26, 2007 11:08 AM > > > > > To: Kilian Weniger > > > > > Cc: Narayanan, Vidya; netlmm@ietf.org > > > > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > > > > draft-ietf-netlmm-proxymip6-05) > > > > >=20 > > > > > Kilian Weniger wrote: > > > > > > Narayanan, Vidya wrote: > > > > > >>>> - Security considerations: MAG Compromise:=20 > > > > > > ... > > > > > >> If we claim this is an issue in the security > > > > > considerations section > > > > > >> and claim that the fix to it is for the LMA to ensure > > > the MN is > > > > > >> actually attached to the MAG, we can't quite hand > > wave on some > > > > > >> possible ways to do that. Those are just hints for > > > > > deployments that > > > > > >> are concerned about MAG compromise. But, those hints > > > need to be > > > > > >> captured in the security considerations section. =20 > > The threats > > > > > >> document captures this threat and it is a valid one - so, > > > > > I believe > > > > > >> we need some text here. The type of "detail" is what > > > I tried to > > > > > >> provide with the examples on AAA checks or CGA > > > > signatures - and, I > > > > > >> don't think we need a lot of detail here; a few > > > > sentences would be > > > > > >> good. > > > > > >> > > > > > >=20 > > > > > > I had a similar comment a while ago. I think that a draft > > > > > describing a > > > > > > severe security issue should at least give hints how this > > > > > can be solved. > > > > > >=20 > > > > > > Recently Sri, Vijay, Kuntal and I had an offline > > > discussion about > > > > > > another possible solution to detect a compromised MAGs, > > > > > which relies > > > > > > on PMIP signaling only. > > > > > >=20 > > > > > > The basic idea is that if two MAGs simultaneously claim > > > > > that the MN is > > > > > > attached, one of the MAGs must lie and is probably a > > > > > compromised MAG. > > > > > > The assumption is that the MN cannot at the same time be > > > > > attached to > > > > > > two MAGs, at least not with the same network interface. > > > > > >=20 > > > > > > More specifically, when the LMA accepts a valid PBU from a > > > > > new MAG, it > > > > > > changes the BCE (i.e., there is no impact on handover > > > delay) and > > > > > > notifies the old MAG (i.e., old address in BCE) about > > > > this. The old > > > > > > MAG then checks whether the MN is still attached. If this > > > > > is the case, > > > > > > it informs the LMA about this. The LMA then learns that two > > > > > different > > > > > > MAGs claim MN attachement, which is not possible under the > > > > > assumption > > > > > > stated above. Hence, after receiving one or more such > > > > > notifications, > > > > > > the LMA can identify the compromised MAG and stop > > > > trusting this MAG. > > > > > >=20 > > > > > > A remaining problem was which message should be used to > > > > > inform the old > > > > > > MAG about the BCE change. PBA and revocation msg were > > > > > discussed, but > > > > > > the former is not sent unsolicited according to RFC3775 > > > > > (which could > > > > > > be overidden by PMIP spec of course) and the latter is not=20 > > > > > > standardized yet. > > > > >=20 > > > > > As I said in another threat, we really need to=20 > standardize the=20 > > > > > revocation message from the LMA to the old MAG ASAP. > > > > >=20 > > > > > Vijay > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 > > >=20 > >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 09:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbG8s-0003XA-E6; Fri, 28 Sep 2007 09:44:30 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbG8p-0003LJ-Tt for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:44:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbG8p-0003Kn-9V for netlmm@ietf.org; Fri, 28 Sep 2007 09:44:27 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbG8o-00077W-HK for netlmm@ietf.org; Fri, 28 Sep 2007 09:44:27 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SDhZJS004372; Fri, 28 Sep 2007 15:43:36 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 15:44:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Default router and new MAG (Was: [netlmm] Suresh's reviewofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 15:44:20 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AF1@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <00bb01c8012d$96993c00$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default router and new MAG (Was: [netlmm] Suresh's reviewofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgBALsO/n3LKzJ9QkSVVvF8NxCxRwAEHRhQAAbWaZgAAAxPMAAocPFw References: <008c01c80111$6c9d7770$1220fea9@amer.cisco.com> <00bb01c8012d$96993c00$1220fea9@amer.cisco.com> From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" X-OriginalArrivalTime: 28 Sep 2007 13:44:20.0843 (UTC) FILETIME=[AC2E33B0:01C801D5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, Sri> If MN has DNAv6 stack, it can flush the old AR entry immediately. = That is very important. [FDJ] Can you clarify why is it "very important"? Link Local address of MAG >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>> When an MN moves from one link to another how does it switch default = >>> routers to the new MAG. The link local addresses of the old MAG and=20 >>> the new MAG will most likely be different and hence unless nud=20 >>> removes the old mag the mn will try to reach it even after handover. >>> Or it is assumed that all the MAGs will have the same LL address? Is = >>> this is an assumption, it needs to be stated. The above problem statement talks about LLAs and the title of the thread = talks about default routers Is there a link between the two? When the link model is point-to-point I presume that it is useless to = keep track of the default router Even if the host was keeping track of the default router, I presume that = this should be per link, and since the link changed, the host should be = capable of handling it autonomously What the LLA concernFrom netlmm-bounces@ietf.org Fri Sep 28 09:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbG8s-0003XA-E6; Fri, 28 Sep 2007 09:44:30 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbG8p-0003LJ-Tt for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:44:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbG8p-0003Kn-9V for netlmm@ietf.org; Fri, 28 Sep 2007 09:44:27 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbG8o-00077W-HK for netlmm@ietf.org; Fri, 28 Sep 2007 09:44:27 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SDhZJS004372; Fri, 28 Sep 2007 15:43:36 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 15:44:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Default router and new MAG (Was: [netlmm] Suresh's reviewofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 15:44:20 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AF1@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <00bb01c8012d$96993c00$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Default router and new MAG (Was: [netlmm] Suresh's reviewofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgBALsO/n3LKzJ9QkSVVvF8NxCxRwAEHRhQAAbWaZgAAAxPMAAocPFw References: <008c01c80111$6c9d7770$1220fea9@amer.cisco.com> <00bb01c8012d$96993c00$1220fea9@amer.cisco.com> From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" X-OriginalArrivalTime: 28 Sep 2007 13:44:20.0843 (UTC) FILETIME=[AC2E33B0:01C801D5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: netlmm@ietf.org, Julien Laganier X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, Sri> If MN has DNAv6 stack, it can flush the old AR entry immediately. = That is very important. [FDJ] Can you clarify why is it "very important"? Link Local address of MAG >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>> When an MN moves from one link to another how does it switch default = >>> routers to the new MAG. The link local addresses of the old MAG and=20 >>> the new MAG will most likely be different and hence unless nud=20 >>> removes the old mag the mn will try to reach it even after handover. >>> Or it is assumed that all the MAGs will have the same LL address? Is = >>> this is an assumption, it needs to be stated. The above problem statement talks about LLAs and the title of the thread = talks about default routers Is there a link between the two? When the link model is point-to-point I presume that it is useless to = keep track of the default router Even if the host was keeping track of the default router, I presume that = this should be per link, and since the link changed, the host should be = capable of handling it autonomously What the LLA concerns, I guess that the LLA of the old MAG will = eventually go stale Is the MAG LLA actually relevant for the host? Regards federico -----Message d'origine----- De : Sri Gundavelli [mailto:sgundave@cisco.com]=20 Envoy=E9 : jeudi 27 septembre 2007 19:41 =C0 : 'Basavaraj Patil'; 'Julien Laganier'; netlmm@ietf.org Objet : RE: Default router and new MAG (Was: [netlmm] Suresh's = reviewofdraft-ietf-netlmm-proxymip6-05) Raj,=20 > >=20 > > Thanks. This is very important. I can add a reference to this. > > Probably, a good reason to enable to DNAv6 on the MN. >=20 > We cannot be having any requirements on the MN. So lets not start=20 > saying that the MN should enable DNAv6 or expect it to do anything new = > for it to work in a PMIP domain. >=20 We are not mandating DNAv6. Its informational. If MN has DNAv6 stack, it = can flush the old AR entry immediatly. That is very important. Do you = see any issue, stating that point ?=20 Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 09:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbG8o-0003KR-BN; Fri, 28 Sep 2007 09:44:26 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbG8n-0003KG-KH for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:44:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbG8n-0003JD-8f for netlmm@ietf.org; Fri, 28 Sep 2007 09:44:25 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbG8m-00077M-2Q for netlmm@ietf.org; Fri, 28 Sep 2007 09:44:25 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SDhZJQ004372; Fri, 28 Sep 2007 15:43:35 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 15:44:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Compromised MAG issue (was [netlmm]Review of draft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 15:44:05 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AEF@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116FF81C4@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm]Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBAAU7NvoA== References: <46F96DF7.1000702@azairenet.com><1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de><46FA9FFC.4070608@azairenet.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF81C4@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Ahmad Muhanna" X-OriginalArrivalTime: 28 Sep 2007 13:44:20.0624 (UTC) FILETIME=[AC0CC900:01C801D5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: >=20 > > Thanks. This is very important. I can add a reference to this. > > Probably, a good reason to enable to DNAv6 on the MN. >=20 > We cannot be having any requirements on the MN. So lets not start=20 > saying that the MN should enable DNAv6 or expect it to do anything new = > for it to work in a PMIP domain. >=20 We are not mandating DNAv6. Its informational. If MN has DNAv6 stack, it = can flush the old AR entry immediatly. That is very important. Do you = see any issue, stating that point ?=20 Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 09:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbG8o-0003KR-BN; Fri, 28 Sep 2007 09:44:26 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbG8n-0003KG-KH for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:44:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbG8n-0003JD-8f for netlmm@ietf.org; Fri, 28 Sep 2007 09:44:25 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbG8m-00077M-2Q for netlmm@ietf.org; Fri, 28 Sep 2007 09:44:25 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SDhZJQ004372; Fri, 28 Sep 2007 15:43:35 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 15:44:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Compromised MAG issue (was [netlmm]Review of draft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 15:44:05 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AEF@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116FF81C4@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm]Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBAAU7NvoA== References: <46F96DF7.1000702@azairenet.com><1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de><46FA9FFC.4070608@azairenet.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF81C4@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Ahmad Muhanna" X-OriginalArrivalTime: 28 Sep 2007 13:44:20.0624 (UTC) FILETIME=[AC0CC900:01C801D5] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmead Please see inline Regards federico=20 -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Envoy=E9 : jeudi 27 septembre 2007 01:12 =C0 : Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger Cc : netlmm@ietf.org Objet : RE: Compromised MAG issue (was [netlmm]Review of = draft-ietf-netlmm-proxymip6-05) Hi Vidya, Using revocation for the compromised MAG was proposed by Kilian, et. al. but I am trying to help closing the issue so please allow me to jump = into this debate. In order for the LMA to validate the presence of the MN at a specific = MAG, the LMA needs to do one of the followings: 1. Validate the MN identity via a MN signature carried in the P-BU. In P-MIPv6 this currently is not available since the P-BU is NOT initiated = by the MN. (the most obvious option) [FDJ] Adding a MN-signature does not require that the BU is initiated by = the MAG, does it? 2. Validate the MN presence via another trusted entity that *ALWAYS* = tracks the MN current location, e.g. AAA server. 3. Validate the MN presence via another trusted entity that tracks the = current or latest location of the MN, e.g. the previous MAG using = binding revocation as was suggested by kilian et. al. [FDJ] Apart form Vidya's comment, this bullet also misses the initial = registration (no previous MAG available) 4. may be there are other ways... In case that the MN is still at pMAG and has not moved, the pMAG can = easily indicate that in the binding revocation acknowledgement. So do not you think that should work? Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Wednesday, September 26, 2007 3:49 PM > To: Vijay Devarapalli; Kilian Weniger > Cc: netlmm@ietf.org > Subject: RE: Compromised MAG issue (was [netlmm] Review of > draft-ietf-netlmm-proxymip6-05) >=20 >=20 > A few observations here. I don't believe binding revocation is going=20 > to solve anything here. The fundamental issue is how the LMA=20 > *identifies* the compromised MAG, not how the compromised MAG is=20 > notified that its binding is no longer valid. Once the MAG is=20 > identified as compromised, a number of remedies may be taken,=20 > including, simply blacklisting the MAG and not accepting PBUs from it. = =20 > It is not critical that the binding be revoked, because, the LMA has=20 > already identified where the MN really is and it just needs to use=20 > that binding for data acceptance/forwarding. >=20 >=20 > The issue of how the LMA identifies a compromised MAG cannot=20 > be tackled without an independent verification of the=20 > presence of the MN at that particular MAG. So, we need to=20 > focus on providing hints on how the LMA may go about achieving that.=20 >=20 > Vidya >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > Sent: Wednesday, September 26, 2007 11:08 AM > > To: Kilian Weniger > > Cc: Narayanan, Vidya; netlmm@ietf.org > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > draft-ietf-netlmm-proxymip6-05) > >=20 > > Kilian Weniger wrote: > > > Narayanan, Vidya wrote: > > >>>> - Security considerations: MAG Compromise:=20 > > > ... > > >> If we claim this is an issue in the security > > considerations section > > >> and claim that the fix to it is for the LMA to ensure the MN is=20 > > >> actually attached to the MAG, we can't quite hand wave on some=20 > > >> possible ways to do that. Those are just hints for > > deployments that > > >> are concerned about MAG compromise. But, those hints need to be=20 > > >> captured in the security considerations section. The threats=20 > > >> document captures this threat and it is a valid one - so, > > I believe > > >> we need some text here. The type of "detail" is what I tried to=20 > >rg/pipermail/netlmm> List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmead Please see inline Regards federico=20 -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Envoy=E9 : jeudi 27 septembre 2007 01:12 =C0 : Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger Cc : netlmm@ietf.org Objet : RE: Compromised MAG issue (was [netlmm]Review of = draft-ietf-netlmm-proxymip6-05) Hi Vidya, Using revocation for the compromised MAG was proposed by Kilian, et. al. but I am trying to help closing the issue so please allow me to jump = into this debate. In order for the LMA to validate the presence of the MN at a specific = MAG, the LMA needs to do one of the followings: 1. Validate the MN identity via a MN signature carried in the P-BU. In P-MIPv6 this currently is not available since the P-BU is NOT initiated = by the MN. (the most obvious option) [FDJ] Adding a MN-signature does not require that the BU is initiated by = the MAG, does it? 2. Validate the MN presence via another trusted entity that *ALWAYS* = tracks the MN current location, e.g. AAA server. 3. Validate the MN presence via another trusted entity that tracks the = current or latest location of the MN, e.g. the previous MAG using = binding revocation as was suggested by kilian et. al. [FDJ] Apart form Vidya's comment, this bullet also misses the initial = registration (no previous MAG available) 4. may be there are other ways... In case that the MN is still at pMAG and has not moved, the pMAG can = easily indicate that in the binding revocation acknowledgement. So do not you think that should work? Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Wednesday, September 26, 2007 3:49 PM > To: Vijay Devarapalli; Kilian Weniger > Cc: netlmm@ietf.org > Subject: RE: Compromised MAG issue (was [netlmm] Review of > draft-ietf-netlmm-proxymip6-05) >=20 >=20 > A few observations here. I don't believe binding revocation is going=20 > to solve anything here. The fundamental issue is how the LMA=20 > *identifies* the compromised MAG, not how the compromised MAG is=20 > notified that its binding is no longer valid. Once the MAG is=20 > identified as compromised, a number of remedies may be taken,=20 > including, simply blacklisting the MAG and not accepting PBUs from it. = =20 > It is not critical that the binding be revoked, because, the LMA has=20 > already identified where the MN really is and it just needs to use=20 > that binding for data acceptance/forwarding. >=20 >=20 > The issue of how the LMA identifies a compromised MAG cannot=20 > be tackled without an independent verification of the=20 > presence of the MN at that particular MAG. So, we need to=20 > focus on providing hints on how the LMA may go about achieving that.=20 >=20 > Vidya >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > Sent: Wednesday, September 26, 2007 11:08 AM > > To: Kilian Weniger > > Cc: Narayanan, Vidya; netlmm@ietf.org > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > draft-ietf-netlmm-proxymip6-05) > >=20 > > Kilian Weniger wrote: > > > Narayanan, Vidya wrote: > > >>>> - Security considerations: MAG Compromise:=20 > > > ... > > >> If we claim this is an issue in the security > > considerations section > > >> and claim that the fix to it is for the LMA to ensure the MN is=20 > > >> actually attached to the MAG, we can't quite hand wave on some=20 > > >> possible ways to do that. Those are just hints for > > deployments that > > >> are concerned about MAG compromise. But, those hints need to be=20 > > >> captured in the security considerations section. The threats=20 > > >> document captures this threat and it is a valid one - so, > > I believe > > >> we need some text here. The type of "detail" is what I tried to=20 > > >> provide with the examples on AAA checks or CGA=20 > signatures - and, I=20 > > >> don't think we need a lot of detail here; a few=20 > sentences would be=20 > > >> good. > > >> > > >=20 > > > I had a similar comment a while ago. I think that a draft > > describing a > > > severe security issue should at least give hints how this > > can be solved. > > >=20 > > > Recently Sri, Vijay, Kuntal and I had an offline discussion about=20 > > > another possible solution to detect a compromised MAGs, > > which relies > > > on PMIP signaling only. > > >=20 > > > The basic idea is that if two MAGs simultaneously claim > > that the MN is > > > attached, one of the MAGs must lie and is probably a > > compromised MAG. > > > The assumption is that the MN cannot at the same time be > > attached to > > > two MAGs, at least not with the same network interface. > > >=20 > > > More specifically, when the LMA accepts a valid PBU from a > > new MAG, it > > > changes the BCE (i.e., there is no impact on handover delay) and=20 > > > notifies the old MAG (i.e., old address in BCE) about=20 > this. The old=20 > > > MAG then checks whether the MN is still attached. If this > > is the case, > > > it informs the LMA about this. The LMA then learns that two > > different > > > MAGs claim MN attachement, which is not possible under the > > assumption > > > stated above. Hence, after receiving one or more such > > notifications, > > > the LMA can identify the compromised MAG and stop=20 > trusting this MAG. > > >=20 > > > A remaining problem was which message should be used to > > inform the old > > > MAG about the BCE change. PBA and revocation msg were > > discussed, but > > > the former is not sent unsolicited according to RFC3775 > > (which could > > > be overidden by PMIP spec of course) and the latter is not=20 > > > standardized yet. > >=20 > > As I said in another threat, we really need to standardize the=20 > > revocation message from the LMA to the old MAG ASAP. > >=20 > > Vijay > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm >> provide with the examples on AAA checks or CGA=20 > signatures - and, I=20 > > >> don't think we need a lot of detail here; a few=20 > sentences would be=20 > > >> good. > > >> > > >=20 > > > I had a similar comment a while ago. I think that a draft > > describing a > > > severe security issue should at least give hints how this > > can be solved. > > >=20 > > > Recently Sri, Vijay, Kuntal and I had an offline discussion about=20 > > > another possible solution to detect a compromised MAGs, > > which relies > > > on PMIP signaling only. > > >=20 > > > The basic idea is that if two MAGs simultaneously claim > > that the MN is > > > attached, one of the MAGs must lie and is probably a > > compromised MAG. > > > The assumption is that the MN cannot at the same time be > > attached to > > > two MAGs, at least not with the same network interface. > > >=20 > > > More specifically, when the LMA accepts a valid PBU from a > > new MAG, it > > > changes the BCE (i.e., there is no impact on handover delay) and=20 > > > notifies the old MAG (i.e., old address in BCE) about=20 > this. The old=20 > > > MAG then checks whether the MN is still attached. If this > > is the case, > > > it informs the LMA about this. The LMA then learns that two > > different > > > MAGs claim MN attachement, which is not possible under the > > assumption > > > stated above. Hence, after receiving one or more such > > notifications, > > > the LMA can identify the compromised MAG and stop=20 > trusting this MAG. > > >=20 > > > A remaining problem was which message should be used to > > inform the old > > > MAG about the BCE change. PBA and revocation msg were > > discussed, but > > > the former is not sent unsolicited according to RFC3775 > > (which could > > > be overidden by PMIP spec of course) and the latter is not=20 > > > standardized yet. > >=20 > > As I said in another threat, we really need to standardize the=20 > > revocation message from the LMA to the old MAG ASAP. > >=20 > > Vijay > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 09:48:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGCw-0002le-5Y; Fri, 28 Sep 2007 09:48:42 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbGCt-0002Xo-LC for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:48:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGCt-0002Xg-9e for netlmm@ietf.org; Fri, 28 Sep 2007 09:48:39 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbGCs-0007GA-HQ for netlmm@ietf.org; Fri, 28 Sep 2007 09:48:39 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8SDmWR09209; Fri, 28 Sep 2007 13:48:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Compromised MAG issue (was [netlmm]Review of draft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 08:48:22 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711704A7CB@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399AEF@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm]Review of draft-ietf-netlmm-proxymip6-05) Thread-Index: AcgAaDRLuec8wehWRHqetycmxRP53AAFRVUgAAJSNBAAU7NvoAAAIMQg References: <46F96DF7.1000702@azairenet.com><1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de><46FA9FFC.4070608@azairenet.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FF81C4@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AEF@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, Let us focus on the proposed text and close this thread. We all agree that a detailed solution is out-of-scope. Thanks.=20 Regards, Ahmad =20 > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Friday, September 28, 2007 8:44 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: netlmm@ietf.org > Subject: RE: Compromised MAG issue (was [netlmm]Review of=20 > draft-ietf-netlmm-proxymip6-05) >=20 > Hi Ahmead >=20 > Please see inline > Regards >=20 > federico=20 >=20 > -----Message d'origine----- > De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 :=20 > jeudi 27 septembre 2007 01:12 =C0 : Narayanan, Vidya; Vijay=20 > Devarapalli; Kilian Weniger Cc : netlmm@ietf.org Objet : RE:=20 > Compromised MAG issue (was [netlmm]Review of=20 > draft-ietf-netlmm-proxymip6-05) >=20 > Hi Vidya, >=20 > Using revocation for the compromised MAG was proposed by=20 > Kilian, et. al. > but I am trying to help closing the issue so please allow me=20 > to jump into this debate. >=20 > In order for the LMA to validate the presence of the MN at a=20 > specific MAG, the LMA needs to do one of the followings: >=20 > 1. Validate the MN identity via a MN signature carried in the P-BU. In > P-MIPv6 this currently is not available since the P-BU is NOT=20 > initiated by the MN. (the most obvious option) [FDJ] Adding a=20 > MN-signature does not require that the BU is initiated by the=20 > MAG, does it? >=20 > 2. Validate the MN presence via another trusted entity that=20 > *ALWAYS* tracks the MN current location, e.g. AAA server. >=20 > 3. Validate the MN presence via another trusted entity that=20 > tracks the current or latest location of the MN, e.g. the=20 > previous MAG using binding revocation as was suggested by=20 > kilian et. al. > [FDJ] Apart form Vidya's comment, this bullet also misses the=20 > initial registration (no previous MAG available) >=20 > 4. may be there are other ways... >=20 > In case that the MN is still at pMAG and has not moved, the=20 > pMAG can easily indicate that in the binding revocation=20 > acknowledgement. >=20 > So do not you think that should work? >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Wednesday, September 26, 2007 3:49 PM > > To: Vijay Devarapalli; Kilian Weniger > > Cc: netlmm@ietf.org > > Subject: RE: Compromised MAG issue (was [netlmm] Review of > > draft-ietf-netlmm-proxymip6-05) > >=20 > >=20 > > A few observations here. I don't believe binding revocation=20 > is going=20 > > to solve anything here. The fundamental issue is how the LMA > > *identifies* the compromised MAG, not how the compromised MAG is=20 > > notified that its binding is no longer valid. Once the MAG is=20 > > identified as compromised, a number of remedies may be taken,=20 > > including, simply blacklisting the MAG and not accepting=20 > PBUs from it. > > It is not critical that the binding be revoked, because,=20 > the LMA has=20 > > already identified where the MN really is and it just needs to use=20 > > that binding for data acceptance/forwarding. > >=20 > >=20 > > The issue of how the LMA identifies a compromised MAG cannot=20 > > be tackled without an independent verification of the=20 > > presence of the MN at that particular MAG. So, we need to=20 > > focus on providing hints on how the LMA may go about=20 > achieving that.=20 > >=20 > > Vidya > >=20 > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > > Sent: Wednesday, September 26, 2007 11:08 AM > > > To: Kilian Weniger > > > Cc: Narayanan, Vidya; netlmm@ietf.org > > > Subject: Re: Compromised MAG issue (was [netlmm] Review of > > > draft-ietf-netlmm-proxymip6-05) > > >=20 > > > Kilian Weniger wrote: > > > > Narayanan, Vidya wrote: > > > >>>> - Security considerations: MAG Compromise:=20 > > > > ... > > > >> If we claim this is an issue in the security > > > considerations section > > > >> and claim that the fix to it is for the LMA to ensure=20 > the MN is=20 > > > >> actually attached to the MAG, we can't quite hand wave on some=20 > > > >> possible ways to do that. Those are just hints for > > > deployments that > > > >> are concerned about MAG compromise. But, those hints=20 > need to be=20 > > > >> captured in the security considerations section. The threats=20 > > > >> document captures this threat and it is a valid one - so, > > > I believe > > > >> we need some text here. The type of "detail" is what=20 > I tried to=20 > > > >> provide with the examples on AAA checks or CGA=20 > > signatures - and, I=20 > > > >> don't think we need a lot of detail here; a few=20 > > sentences would be=20 > > > >> good. > > > >> > > > >=20 > > > > I had a similar comment a while ago. I think that a draft > > > describing a > > > > severe security issue should at least give hints how this > > > can be solved. > > > >=20 > > > > Recently Sri, Vijay, Kuntal and I had an offline=20 > discussion about=20 > > > > another possible solution to detect a compromised MAGs, > > > which relies > > > > on PMIP signaling only. > > > >=20 > > > > The basic idea is that if two MAGs simultaneously claim > > > that the MN is > > > > attached, one of the MAGs must lie and is probably a > > > compromised MAG. > > > > The assumption is that the MN cannot at the same time be > > > attached to > > > > two MAGs, at least not with the same network interface. > > > >=20 > > > > More specifically, when the LMA accepts a valid PBU from a > > > new MAG, it > > > > changes the BCE (i.e., there is no impact on handover=20 > delay) and=20 > > > > notifies the old MAG (i.e., old address in BCE) about=20 > > this. The old=20 > > > > MAG then checks whether the MN is still attached. If this > > > is the case, > > > > it informs the LMA about this. The LMA then learns that two > > > different > > > > MAGs claim MN attachement, which is not possible under the > > > assumption > > > > stated above. Hence, after receiving one or more such > > > notifications, > > > > the LMA can identify the compromised MAG and stop=20 > > trusting this MAG. > > > >=20 > > > > A remaining problem was which message should be used to > > > inform the old > > > > MAG about the BCE change. PBA and revocation msg were > > > discussed, but > > > > the former is not sent unsolicited according to RFC3775 > > > (which could > > > > be overidden by PMIP spec of course) and the latter is not=20 > > > > standardized yet. > > >=20 > > > As I said in another threat, we really need to standardize the=20 > > > revocation message from the LMA to the old MAG ASAP. > > >=20 > > > Vijay > > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 10:04:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGRo-0001JL-95; Fri, 28 Sep 2007 10:04:04 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbGRm-000192-LG for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 10:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGRm-00012a-3l for netlmm@ietf.org; Fri, 28 Sep 2007 10:04:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbGRe-0000pC-ON for netlmm@ietf.org; Fri, 28 Sep 2007 10:04:01 -0400 X-IronPort-AV: E=Sophos;i="4.21,210,1188802800"; d="scan'208";a="226991266" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2007 07:03:41 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8SE3el3008918; Fri, 28 Sep 2007 07:03:40 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8SE3eTn003011; Fri, 28 Sep 2007 14:03:40 GMT Date: Fri, 28 Sep 2007 07:03:40 -0700 (PDT) From: Sri Gundavelli To: DE JUAN HUARTE FEDERICO Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399AEB@FRVELSMBS12.ad2.ad.alcatel.com> Message-ID: References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D60@lan-ex-02.panasonic.de> <319D54578EAC3147BA8CC78DAB5467A501399AEB@FRVELSMBS12.ad2.ad.alcatel.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1141662977-1190988220=:3846" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6865; t=1190988220; x=1191852220; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=gRCAQZLFnawlNSroifADAB9DVvU/FzYdyw8HlcattmM=; b=WrTeVQogb4mjOn2Jd3Kjw+/wKOgWf9FGDEUf+ADEM4yyND+kyJZeY0pY9TC2WOnOUdkqof5z dlMQcPknpQGdEygFVc5sodVC6oy+kxPMWpbUMQyame90MjPw9xd2v+5v; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1141662977-1190988220=:3846 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Federico, That is correct. We do not support simultaneous bindings. This was discussed in the ML before. Regards Sri On Fri, 28 Sep 2007, DE JUAN HUARTE FEDERICO wrote: > Hi Sri, > > I have seen several times now statements that the LMA would only have one= binding per MN. > I'm a bit puzzled by this. > > In MIP6 AFAIK the HA may have multiple bindings per MN (multiple CoA) but= only one of them is primary. > The statement that there's only one single binding per MN makes me think = that this feature is not supported by PMIP6. > Has this been discussed earlier? If yes I'll dig up the archives to catch= up. > > Thanks > > federico > > > > -----Message d'origine----- > De : Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Envoy=E9 : mercredi 26 septembre 2007 16:15 > =C0 : ext Kilian Weniger > Cc : netlmm@ietf.org > Objet : Re: [netlmm] Issue: Prefix allocation and multihomed MNs > > > Kilian, > > While it is possible that a multi-interface MN can attach to different MA= Gs which cause the MAGs to send a PBU to the same LMA, I personally think t= hat dealing with this is more of an academic exercise at the present time. > > I do not believe we have the possibility of making any changes to the MN.= So that route is closed... At least for now. > > So here is how I view the current scenario which IMO is academic at this = time and hence not something that we should be spending a lot of time on : > > - If an MN attaches to multiple MAGs via different interfaces this would = trigger the MAGs to send PBUs to the LMA > - If the LMA receives them almost simultaneously (as an example), and a P= BAck has not been sent, then the LMA can choose to create an entry in the B= C for the last received PBU and ACK only the last received PBU (the LMA wou= ld believe that the MN which attached to MAG1 moved to MAG2 resulting in th= e transmission of PBUs from MAG1 and MAG2 near simulatenously) > - If the MN receives a PBU from another MAG for an MN which has an entry = in the BC as a result of a second interface attaching to a MAG, the LMA wou= ld view this as the MN having moved to MAG2 and hence would delete the BCE = for > MAG1 and insert MAG2 for the MN > > But if we merely state (or mandate) that the LMA will only have only one = MAG entry in the BC at any given time, we would not have a problem with the= multi-homing scenario, right? > > -Raj > > > > > On 9/26/07 8:10 AM, "ext Kilian Weniger" > wrote: > >> Hi Raj, >> >> I think we should differentiate between two cases: >> 1. supporting multi-homing requested by the host to achieve features >> like load balancing, failover etc. >> 2. preventing that PMIP protocol breaks if an unmodified host >> activates more than one network interface. >> >> For case 1, I agree with you that this is out of scope of the base >> draft and should be handled in a separate multi-homing document. >> >> But I think Vidya was talking about case 2 and I agree that this issue >> should be addressed in the base draft. >> >> Currently, I see the following potential issues if an unmodified host >> activates more than one network interface and happens to attach to >> more than one MAG of a given PMIP domain simultaneously: >> - multiple MN interfaces get the same prefix assigned, which may break >> something (e.g., routing) in the host and may result in loss of >> connectivity >> - BCE at LMA constantly and randomly changes since multiple MAGs send >> PBUs to the LMA for the same MN. This may result in packet loss both >> in downlink and uplink. >> - the MAGs may discover and use different LMA addresses for the same >> host etc. >> >> However, I'm not sure how we can solve this issue without modifying >> the host or mandating not to use multiple interfaces. Any ideas? >> >> BR, >> >> Kilian >> >> >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>> Sent: Mittwoch, 26. September 2007 13:50 >>> To: ext Kilian Weniger; Narayanan, Vidya >>> Cc: netlmm@ietf.org >>> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >>> >>> >>> Kilian, >>> >>> >>> >>> >>> On 9/26/07 3:57 AM, "ext Kilian Weniger" >>> >>> wrote: >>> >>>> Hi Vidya, >>>> >>>> I agree that we need some text about this issue. >>>> >>>> Narayanan, Vidya wrote: >>>>> - define LMA behavior such that regular multihomed IP devices don't >>>>> run into issues of connectivity or shutting down interfaces. >>> This is much >>>>> more logical in my view and it is not a big change in the document. >>>> >>>> Can you elaborate how this would work? How does the LMA >>> differentiate >>>> between PBUs that were triggered by the same vs different >>> MN interfaces? >>>> >>>> >>>> I guess the MAG would need to include some kind of MN >>> physical network >>>> interface ID in the PBU, but what kind of ID would that be >>> and how does >>>> the MAG learn that ID? Note that the MN's link-local address may not >>>> work as an ID in general, since the MN may implement a kind >>> of virtual >>>> network interface which hides multiple physical network >>> interfaces and >>>> only exposes a single (virtual) network interface to the IP >>> stack. This >>>> may result in the same link-local address for multiple physical >>>> interfaces. >>>> >>>> So do we need to mandate something on the MN side to solve >>> this issue in >>>> the general case? >>> >>> One of the tenets of Netlmm protocol has been to not require any >>> changes or requirements on the MN. So it is not an option. >>> >>> Issues that arise from multi-homing and how to deal with them should >>> be dealt separately and not in the scope of this I-D. >>> >>> -Raj >>> >>>> >>>> Kilian >>>> >>>> >>>> Panasonic R&D Center Germany GmbH >>>> 63225 Langen, Hessen, Germany >>>> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke >>>> >>>> >>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >>> >>> >> >> >> Panasonic R&D Center Germany GmbH >> 63225 Langen, Hessen, Germany >> Reg: AG Offenbach (Hessen) HRB 33974 >> Managing Director: Thomas Micke >> >> > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ---559023410-1141662977-1190988220=:3846 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm ---559023410-1141662977-1190988220=:3846-- From netlmm-bounces@ietf.org Fri Sep 28 10:15:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGcl-00016z-CY; Fri, 28 Sep 2007 10:15:23 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbGck-00015i-Qs for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 10:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGck-00015a-HL for netlmm@ietf.org; Fri, 28 Sep 2007 10:15:22 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbGcj-00011J-Ak for netlmm@ietf.org; Fri, 28 Sep 2007 10:15:22 -0400 X-IronPort-AV: E=Sophos;i="4.21,210,1188802800"; d="scan'208";a="529287533" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2007 07:15:21 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8SEFKLi010624; Fri, 28 Sep 2007 07:15:20 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8SEFKTn015034; Fri, 28 Sep 2007 14:15:20 GMT Date: Fri, 28 Sep 2007 07:15:20 -0700 (PDT) From: Sri Gundavelli To: Genadi Velev Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8EA2@lan-ex-02.panasonic.de> Message-ID: References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8EA2@lan-ex-02.panasonic.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1473; t=1190988920; x=1191852920; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=tCosoTximDxQsZh+MC4lEN/JQ9kvJ9jCdDho1DqvQUw=; b=SXLf/5kksmFAKMnzTFVYWtRTBtpeberEZ8AgXDnYzZic6ZihpM1TUyHuOzezmwc8iu7LQ52g lotJNqN3S90LV8jQJ1VPG6HsO2GcdGTnPd2ongwoMjVaQDMTvrBcSfa9; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Genadi, Please see inline. On Fri, 28 Sep 2007, Genadi Velev wrote: > I can think about several approaches to overcome this issue: > 1) we can specify that the network operator shall take care of > preventing that a MN attaches with 2 interfaces to a PMIP domain (at > least to the same LMA). For example, the operator doesn't allow > attachment (i.e. authorization) of interface 2, since interface 1 is > still attached. > 2) we can write a short text in the draft that the network operator > shall take care about assignment of different MN-ID (NAI) to different > interfaces during attachment procedure. > 3) we can describe how the current protocol behaves when a MN attempts > to attach with two interfaces. Similar to what is explained in Vijay's > email: > http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html I'm ok with any of the above three options. We can certainly document the scenario and close the issue. I do no think, we should try to solve this problem here or use this issue to explicitly add text to block the inter-access handoff, we did not do any thing to support that scenario. When the charter says, its out of scope, we dont need to solve all the issues, when the scenario is enabled. Operators can solve this issue, these are managed deployments. Its not a like a consumer buying a device and turning it on at home. So, I agree with your above three suggested options. Regards Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 10:17:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGeN-00025m-FI; Fri, 28 Sep 2007 10:17:03 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbGeK-00025Y-Gc for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 10:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGeK-00025K-6u for netlmm@ietf.org; Fri, 28 Sep 2007 10:17:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbGeI-00012t-WF for netlmm@ietf.org; Fri, 28 Sep 2007 10:17:00 -0400 X-IronPort-AV: E=Sophos;i="4.21,210,1188802800"; d="scan'208";a="529288341" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2007 07:16:58 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8SEGwhr032748; Fri, 28 Sep 2007 07:16:58 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8SEGv1m006591; Fri, 28 Sep 2007 14:16:58 GMT Date: Fri, 28 Sep 2007 07:16:57 -0700 (PDT) From: Sri Gundavelli To: RYUJI WAKIKAWA Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: <4F633DFC-3181-42E0-B284-4B1DC732F1BB@gmail.com> Message-ID: References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> <00ba01c8012b$84300460$1220fea9@amer.cisco.com> <00c201c8012f$2dabe5b0$1220fea9@amer.cisco.com> <4F633DFC-3181-42E0-B284-4B1DC732F1BB@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=926; t=1190989018; x=1191853018; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=/S5t7v1KyhYVvkoYoSJ+gppDKHDz3DzUk4AMYB65i54=; b=aCiUdnM/K6VW5E26GdkSGVcwXXp3mW7rkoOIz4NgtYffLEi0rr2ibgnKhiNNwG/DlaRWHUGd ye94trWw77VOr26UdwPheyqzJZI6Zr07pWjM42mBgJqMYJas6E/Lsg6z; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'ext Kilian Weniger' , netlmm@ietf.org, 'Genadi Velev' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ryuji, >> > multi-interface support issues in this thread. What we are >> > dealing with >> > is the fact that an MN may not be able to use *any* interface simply >> > because it happens to have two interfaces. >> >> If we are not dealing with multi-interface support, we dont >> need to talk about the scenario where the MN has multiple active >> interfaces. This is not the right interpretation of the charter, >> IMHO. >> >> If operators want to deal with this, let them configure a unique >> NAI for each interface and even when multiple interfaces are >> active, each interface will endup with a unique prefix. > > I think this is one way to avoid this multi-interface issue. > You can mention in the doc that MN should have different NAI per interfaces > if it has multiple interfaces attached to the PMIP domain. > Sure. We can probably document this, as Genadi suggested. Regards Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 10:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGqP-0006kc-7C; Fri, 28 Sep 2007 10:29:29 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbGqO-0006kX-4o for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 10:29:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbGqN-0006kP-RP for netlmm@ietf.org; Fri, 28 Sep 2007 10:29:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbGqM-0001ET-Az for netlmm@ietf.org; Fri, 28 Sep 2007 10:29:27 -0400 X-IronPort-AV: E=Sophos;i="4.21,210,1188802800"; d="scan'208";a="227006804" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2007 07:29:25 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8SETPWl023682; Fri, 28 Sep 2007 07:29:25 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8SETP1m019081; Fri, 28 Sep 2007 14:29:25 GMT Date: Fri, 28 Sep 2007 07:29:25 -0700 (PDT) From: Sri Gundavelli To: Ahmad Muhanna Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-986468767-1190989765=:3846" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12535; t=1190989765; x=1191853765; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20Text=20Proposal=20for=20Compromised=20MAG=20issue=20( was=20[netlmm]=20Review=0A=20ofdraft-ietf-netlmm-proxymip6-05) |Sender:=20; bh=wWstwWMf58ODb+n4VtHAk/82iePMgjcJtx9DUZnjGiw=; b=VpZJHsxguXCbk5/EDw/sXvTs3jMXmALzkSfaPOoLL9HWmTnWYlBPAi2aNoxQNFGX7tYL9eNw Z9NpKXOu2V0ZIxuYbLjG+/bziU/zaR6NC+WmmifDOjf6yzUUVmyDw0zcb6lRCLjIRT4Rcv6b8J VdazQKHCny8L56ZyojCBv5dtg=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: DE JUAN HUARTE FEDERICO , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-986468767-1190989765=:3846 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Federico, We need to provide some guidance on how LMA implementations can esnure the presence of a MN at a given MAG in a deterministic fashion. One possible way is that the Authentication infrastructure such as AAA that generated the keys for the mobile node session would know the current point of attachment. The LMA can query the same. These entire arguments on MAG compromise ..etc, are loosing arguments. Unfortunately, we have to agree, there may not be access authentication, but, at the same time we have to provide all the guidance on how to prevent MAG compromise. These are all killer arguments. So, these issues just delay the work. So, lets try to find some text and put a closure to this work. By adding a reference to AAA, does not imply, we have mandatory requirement on AAA, or we are making AAA stateful. Just any reasonable guidance with/without AAA should be fine. Sri On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > Hi Federico, > > It is very nice to know that we are getting into the beauty context.:) > > Please let us focus on all of the added text: > > " > .... by contacting a trusted entity which tracks the MN current location,= e.g. AAA server. > " > > If AAA server is not stateful, then deployment may use another trusted en= tity and that is granted by the above text. > Originally I am in favor of leaving the whole thing out-of-scope all toge= ther, but listing AAA server as an example does not eliminate any other sec= urity mechanisms nor require that all deployment have AAA server as statefu= l. > > Do not you agree? > > Sincerely, If we do not have any serious objection to this text, we need = to close the issue and move on. > Thanks. > > > Regards, > Ahmad > > >> -----Original Message----- >> From: DE JUAN HUARTE FEDERICO >> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] >> Sent: Friday, September 28, 2007 4:23 AM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: netlmm >> Subject: RE: Text Proposal for Compromised MAG issue (was >> [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) >> >> Hi Ahmad, >> >> in my understanding there's a general motivation to make AAA >> Servers stateless, so the draft should not put such a strong >> "tracking" requirement It is clear to me that in some/many >> deployments the AAA Server is not stateless anyway, so this >> is a minor comment But then, what the AAA Server actually >> tracks is the NAS and not really the MAG Somehow you're >> assuming that the AAA Server is aware of the relationship >> between NASs and MAGs >> >> With the current text, the security solution was left for >> deployments to choose With the new text you're trying to >> close the solution space to one given solution Let's be fair here: >> - or the security solution is discussed and we do the >> beauty contest with all of them >> - or the security solution is not discussed and we leave >> the discussion for other contexts >> >> Regards >> >> federico >> >> >> >> -----Message d'origine----- >> De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 : >> vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay >> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text >> Proposal for Compromised MAG issue (was [netlmm] Review >> ofdraft-ietf-netlmm-proxymip6-05) >> >> >> All, >> >> I sincerely do not want to debate the use of revocation for >> compromised MAG at the present time. I am sure that all of us >> are interested in getting this issue addressed properly and >> have it closed sooner than later. What about the following text: >> >> Current text under security consideration: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> " >> To eliminate the threats related to a compromised mobile access >> gateway, this specification recommends that the local >> mobility anchor >> before accepting a Proxy Binding Update message for a given mobile >> node, should ensure the mobile node is definitively attached to the >> mobile access gateway that sent the binding registration request. >> " >> >> New Text: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> " >> To eliminate the threats related to a compromised mobile access >> gateway, this specification recommends that the local >> mobility anchor >> before accepting a Proxy Binding Update message for a given mobile >> node, should ensure the mobile node is definitively attached to the >> mobile access gateway that sent the binding registration request >> by contacting a trusted entity which tracks the MN current >> location, >> e.g. AAA server. >> " >> >> Regards, >> Ahmad >> >> >>> -----Original Message----- >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>> Sent: Wednesday, September 26, 2007 7:41 PM >>> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger >>> Cc: netlmm@ietf.org >>> Subject: RE: Compromised MAG issue (was [netlmm] Review of >>> draft-ietf-netlmm-proxymip6-05) >>> >>> Hi Ahmad, >>> >>> >>>> -----Original Message----- >>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >>>> Sent: Wednesday, September 26, 2007 4:12 PM >>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger >>>> Cc: netlmm@ietf.org >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of >>>> draft-ietf-netlmm-proxymip6-05) >>>> >>>> Hi Vidya, >>>> >>>> Using revocation for the compromised MAG was proposed by >>> Kilian, et. >>>> al. >>>> but I am trying to help closing the issue so please allow >>> me to jump >>>> into this debate. >>>> >>>> In order for the LMA to validate the presence of the MN at >>> a specific >>>> MAG, the LMA needs to do one of the followings: >>>> >>>> 1. Validate the MN identity via a MN signature carried in >>> the P-BU. In >>>> P-MIPv6 this currently is not available since the P-BU is NOT >>>> initiated by the MN. (the most obvious option) >>>> >>>> 2. Validate the MN presence via another trusted entity that >>>> *ALWAYS* tracks the MN current location, e.g. AAA server. >>>> >>>> 3. Validate the MN presence via another trusted entity that >>> tracks the >>>> current or latest location of the MN, e.g. the previous MAG using >>>> binding revocation as was suggested by kilian et. al. >>>> >>> >>> The LMA can't assume that the pMAG is trusted while the new >> MAG is the >> >>> one lying. Perhaps the MN really moved and the pMAG continues to >>> claim it is there. Regardless of which MAG tells the LMA >> what, 1 or 2 >> >>> needs to occur to conclude where the MN really is and then, the LMA >>> can determine which of the MAGs was lying. >>> >>> Regards, >>> Vidya >>> >>>> 4. may be there are other ways... >>>> >>>> In case that the MN is still at pMAG and has not moved, the >>> pMAG can >>>> easily indicate that in the binding revocation acknowledgement. >>>> >>>> So do not you think that should work? >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>>> -----Original Message----- >>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>>>> Sent: Wednesday, September 26, 2007 3:49 PM >>>>> To: Vijay Devarapalli; Kilian Weniger >>>>> Cc: netlmm@ietf.org >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of >>>>> draft-ietf-netlmm-proxymip6-05) >>>>> >>>>> >>>>> A few observations here. I don't believe binding revocation >>>> is going >>>>> to solve anything here. The fundamental issue is how the LMA >>>>> *identifies* the compromised MAG, not how the >> compromised MAG is >>>>> notified that its binding is no longer valid. Once the MAG is >>>>> identified as compromised, a number of remedies may be taken, >>>>> including, simply blacklisting the MAG and not accepting >>>> PBUs from it. >>>>> It is not critical that the binding be revoked, because, >>>> the LMA has >>>>> already identified where the MN really is and it just >>> needs to use >>>>> that binding for data acceptance/forwarding. >>>>> >>>>> >>>>> The issue of how the LMA identifies a compromised MAG cannot be >>>>> tackled without an independent verification of the >>> presence of the >>>>> MN at that particular MAG. So, we need to focus on >>> providing hints >>>>> on how the LMA may go about >>>> achieving that. >>>>> >>>>> Vidya >>>>> >>>>>> -----Original Message----- >>>>>> From: Vijay Devarapalli >> [mailto:vijay.devarapalli@AzaireNet.com] >>>>>> Sent: Wednesday, September 26, 2007 11:08 AM >>>>>> To: Kilian Weniger >>>>>> Cc: Narayanan, Vidya; netlmm@ietf.org >>>>>> Subject: Re: Compromised MAG issue (was [netlmm] Review of >>>>>> draft-ietf-netlmm-proxymip6-05) >>>>>> >>>>>> Kilian Weniger wrote: >>>>>>> Narayanan, Vidya wrote: >>>>>>>>>> - Security considerations: MAG Compromise: >>>>>>> ... >>>>>>>> If we claim this is an issue in the security >>>>>> considerations section >>>>>>>> and claim that the fix to it is for the LMA to ensure >>>> the MN is >>>>>>>> actually attached to the MAG, we can't quite hand >>> wave on some >>>>>>>> possible ways to do that. Those are just hints for >>>>>> deployments that >>>>>>>> are concerned about MAG compromise. But, those hints >>>> need to be >>>>>>>> captured in the security considerations section. >>> The threats >>>>>>>> document captures this threat and it is a valid one - so, >>>>>> I believe >>>>>>>> we need some text here. The type of "detail" is what >>>> I tried to >>>>>>>> provide with the examples on AAA checks or CGA >>>>> signatures - and, I >>>>>>>> don't think we need a lot of detail here; a few >>>>> sentences would be >>>>>>>> good. >>>>>>>> >>>>>>> >>>>>>> I had a similar comment a while ago. I think that a draft >>>>>> describing a >>>>>>> severe security issue should at least give hints how this >>>>>> can be solved. >>>>>>> >>>>>>> Recently Sri, Vijay, Kuntal and I had an offline >>>> discussion about >>>>>>> another possible solution to detect a compromised MAGs, >>>>>> which relies >>>>>>> on PMIP signaling only. >>>>>>> >>>>>>> The basic idea is that if two MAGs simultaneously claim >>>>>> that the MN is >>>>>>> attached, one of the MAGs must lie and is probably a >>>>>> compromised MAG. >>>>>>> The assumption is that the MN cannot at the same time be >>>>>> attached to >>>>>>> two MAGs, at least not with the same network interface. >>>>>>> >>>>>>> More specifically, when the LMA accepts a valid PBU from a >>>>>> new MAG, it >>>>>>> changes the BCE (i.e., there is no impact on handover >>>> delay) and >>>>>>> notifies the old MAG (i.e., old address in BCE) about >>>>> this. The old >>>>>>> MAG then checks whether the MN is still attached. If this >>>>>> is the case, >>>>>>> it informs the LMA about this. The LMA then learns that two >>>>>> different >>>>>>> MAGs claim MN attachement, which is not possible under the >>>>>> assumption >>>>>>> stated above. Hence, after receiving one or more such >>>>>> notifications, >>>>>>> the LMA can identify the compromised MAG and stop >>>>> trusting this MAG. >>>>>>> >>>>>>> A remaining problem was which message should be used to >>>>>> inform the old >>>>>>> MAG about the BCE change. PBA and revocation msg were >>>>>> discussed, but >>>>>>> the former is not sent unsolicited according to RFC3775 >>>>>> (which could >>>>>>> be overidden by PMIP spec of course) and the latter is not >>>>>>> standardized yet. >>>>>> >>>>>> As I said in another threat, we really need to >> standardize the >>>>>> revocation message from the LMA to the old MAG ASAP. >>>>>> >>>>>> Vijay >>>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>> >>>> >>> >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > ---559023410-986468767-1190989765=:3846 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm ---559023410-986468767-1190989765=:3846-- From netlmm-bounces@ietf.org Fri Sep 28 10:49:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbH9f-0004cz-D2; Fri, 28 Sep 2007 10:49:23 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbH9e-0004ca-Fb for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 10:49:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbH9e-0004Zk-2h for netlmm@ietf.org; Fri, 28 Sep 2007 10:49:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbH9d-0008KG-ND for netlmm@ietf.org; Fri, 28 Sep 2007 10:49:21 -0400 X-IronPort-AV: E=Sophos;i="4.21,210,1188802800"; d="scan'208,217";a="227017938" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2007 07:49:21 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8SEnKUP031892; Fri, 28 Sep 2007 07:49:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8SEnBDR002454; Fri, 28 Sep 2007 14:49:20 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 07:49:16 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 07:49:16 -0700 From: "Sri Gundavelli" To: "'Jong-Hyouk Lee'" , "'Premec, Domagoj'" References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com><3C31CDD06342EA4A8137716247B1CD6802AAC62F@zagh223a.ww300.siemens.net> Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Reviewofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 07:49:17 -0700 Message-ID: <018c01c801de$bed4e550$1220fea9@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgBnx0eA6XYG512TFCww6AL9FbghQAP4NFA X-OriginalArrivalTime: 28 Sep 2007 14:49:16.0617 (UTC) FILETIME=[BE3E2390:01C801DE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2561; t=1190990961; x=1191854961; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20Text=20Proposal=20for=20Compromised=20MAG=20issue=20( was=20[netlmm]=20Reviewofdraft-ietf-netlmm-proxymip6-05) |Sender:=20; bh=vymFNG/IEo8qi3Q5fviXthKofwOpdqZ/48+t41CFszs=; b=n6N+594chidZoDOpIcVRj9i7ixTAmC2emu71mOJrZ+24A7utkINgxlvQLFHGFnw64L7CnrSu s8G6gVIz46ywJKEW4mzMMdHky1Ugqcz73Fo3rcv00lZDT4JTz/lQCzlM; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'Kilian Weniger' , 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0503795597==" Errors-To: netlmm-bounces@ietf.org This is a multi-part message in MIME format. --===============0503795597== Content-Type: multipart/alternative; boundary="----=_NextPart_000_018D_01C801A4.12760D50" This is a multi-part message in MIME format. ------=_NextPart_000_018D_01C801A4.12760D50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Jong-Hyouk, I'd like to be the side of AAA. As you mentioned, the context transfer mechanism may provide a reduced authentication time or procedure in the handoff procedure. But, I think that AAA has to recognize the state information of mobile node including the accurate location information. Why? For instance, for an accurate accounting for the mobile node. So, I agree with Ahmad Muhanna's text. (Using AAA mechanism is natural, why not?) OK Thanks Sri ------=_NextPart_000_018D_01C801A4.12760D50 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Jong-Hyouk,
 
 
I'd like to be the side of AAA. As you mentioned, the context = transfer=20 mechanism may provide a reduced authentication time or procedure in = the=20 handoff procedure. But, I think that AAA has to recognize the state=20 information of mobile node including the accurate location = information.=20 Why? For instance, for an accurate accounting for the mobile = node.=20
 
So, I agree with Ahmad Muhanna's text. (Using AAA mechanism is = natural,=20 why not?)
 
 
OK
 
Thanks
Sri
------=_NextPart_000_018D_01C801A4.12760D50-- --===============0503795597== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0503795597==-- From netlmm-bounces@ietf.org Fri Sep 28 10:57:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHHP-0005Mg-Ps; Fri, 28 Sep 2007 10:57:23 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbHHO-0005MZ-QC for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 10:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHHO-0005MR-Ge for netlmm@ietf.org; Fri, 28 Sep 2007 10:57:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbHHN-00022O-A2 for netlmm@ietf.org; Fri, 28 Sep 2007 10:57:22 -0400 X-IronPort-AV: E=Sophos;i="4.21,210,1188802800"; d="scan'208";a="227022223" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2007 07:57:21 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8SEvKAR032273; Fri, 28 Sep 2007 07:57:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8SEvKDL010647; Fri, 28 Sep 2007 14:57:20 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 07:57:10 -0700 Received: from sgundavewxp ([10.32.246.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 07:57:08 -0700 From: "Sri Gundavelli" To: "'DE JUAN HUARTE FEDERICO'" , "'Narayanan, Vidya'" References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <008901c8010f$2266aa70$1220fea9@amer.cisco.com> <319D54578EAC3147BA8CC78DAB5467A501399AE7@FRVELSMBS12.ad2.ad.alcatel.com> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 07:57:09 -0700 Message-ID: <019701c801df$d93c6d90$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399AE7@FRVELSMBS12.ad2.ad.alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAT3K0wACxplKAAB9wXQA== X-OriginalArrivalTime: 28 Sep 2007 14:57:10.0190 (UTC) FILETIME=[D883A4E0:01C801DF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=697; t=1190991440; x=1191855440; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=y9K3FujyIop666L0zX2Eu0jDRagRDOwsLGQzoGO7kVs=; b=Eyy/uYlP7odiEE9A7EEwiFqmesq2lLMAfe0xbBLebJx+F5GQ3dbYL3eHnyfWmBLt28refVJ2 6FfZe2LqKZv8It/DP3EmEpzLO0el4ZQuo67xBLoH1Tj+1PYYqObN505j; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > On a side note and as FMI, Vidya's problem statement includes > that a host with multiple interfaces will shutdown one of > them when it sees a duplicated IP@. > May I ask where such behavior is defined? No where, as far as I know. It is perfectly valid to configure two interfaces on the same subnet/prefix. Each interface will obtain a different address, when using SLAAC or using DHCPv6. But, it is invalid to enable ip.forwarding in such scenario. In other words, a host can do this, but not a router. You can try that out using your Linux or Windows machine. I do not agree we should discuss about multi-homing and so I'm ok to add some text and move on. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 11:30:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHnp-0003K5-Ld; Fri, 28 Sep 2007 11:30:53 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbHno-0003JM-Fm for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 11:30:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHno-0003Ij-2m for netlmm@ietf.org; Fri, 28 Sep 2007 11:30:52 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbHnm-00026C-Cr for netlmm@ietf.org; Fri, 28 Sep 2007 11:30:51 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SFU2vK010380; Fri, 28 Sep 2007 17:30:02 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 17:30:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 17:30:41 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB2/vks+0kQvu4Rt+gKIeCSXJBzQABPUwA References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Sri Gundavelli" , "Ahmad Muhanna" X-OriginalArrivalTime: 28 Sep 2007 15:30:47.0632 (UTC) FILETIME=[8B00DD00:01C801E4] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, Ahmad I was fine with the original text If addressing the security concern is necessary because of IESG or = whatever and you're going to hint at possible solutions, then I would = add as an alternative that the MAG may add a per-MN signature to the = PBU. The current proposed alternative: > .... by contacting a trusted entity which tracks the MN current = location, e.g. AAA server. it's also fine for me, except that the AAA Server is not a good example = because it only tracks the NAS (not the user nor the MAG) One final comment, if the MN can only be attached to one MAG at a given = time, and if the LMA is going to validate the BU with the AAA Server and = the AAA server is capable of tracking the location of the MAG ... then = do we still need timestamps for message ordering? It sems to me that the solution for a "compromised MAG" problem and for = BU ordering are actually part of the same package, since solving the = "compormised MAG" problem leads to the certainty of having only 1 MAG = serving the user and then a SQN per MAG and per MN is sufficient (no = need for context transfer) Regards federico -----Message d'origine----- De : Sri Gundavelli [mailto:sgundave@cisco.com]=20 Envoy=E9 : vendredi 28 septembre 2007 16:29 =C0 : Ahmad Muhanna Cc : DE JUAN HUARTE FEDERICO; netlmm Objet : RE: Text Proposal for Compromised MAG issue (was [netlmm] Review = ofdraft-ietf-netlmm-proxymip6-05) Hi Federico, We need to provide some guidance on how LMA implementations can esnure = the presence of a MN at a given MAG in a deterministic fashion. One = possible way is that the Authentication infrastructure such as AAA that = generated the keys for the mobile node session would know the current = point of attachment. The LMA can query the same. These entire arguments on MAG compromise ..etc, are loosing = arguments. Unfortunately, we have to agree, there may not be access = authentication, but, at the same time we have to provide all the = guidance on how to prevent MAG compromise. These are all killer = arguments. So, these issues just delay the work. So, lets try to find = some text and put a closure to this work. By adding a reference to AAA, = does not imply, we have mandatory requirement on AAA, or we are making = AAA stateful. Just any reasonable guidance with/without AAA should be = fine. Sri On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > Hi Federico, > > It is very nice to know that we are getting into the beauty context.:) > > Please let us focus on all of the added text: > > " > .... by contacting a trusted entity which tracks the MN current = location, e.g. AAA server. > " > > If AAA server is not stateful, then deployment may use another trusted = entity and that is granted by the above text. > Originally I am in favor of leaving the whole thing out-of-scope all = together, but listing AAA server as an example does not eliminate any = other security mechanisms nor require that all deployment have AAA = server as stateful. > > Do not you agree? > > Sincerely, If we do not have any serious objection to this text, we = need to close the issue and move on. > Thanks. > > > Regards, > Ahmad > > >> -----Original Message----- >> From: DE JUAN HUARTE FEDERICO >> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] >> Sent: Friday, September 28, 2007 4:23 AM >> To: Muhanna, Ahmad (RICH1:2H10) >> Cc: netlmm >> Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]=20 >> Review ofdraft-ietf-netlmm-proxymip6-05) >> >> Hi Ahmad, >> >> in my understanding there's a general motivation to make AAA Servers=20 >> stateless, so the draft should not put such a strong "tracking"=20 >> requirement It is clear to me that in some/many deployments the AAA=20 >> Server is not stateless anyway, so this is a minor comment But then,=20 >> what the AAA Server actually tracks is the NAS and not really the MAG = >> Somehow you're assuming that the AAA Server is aware of the=20 >> relationship between NASs and MAGs >> >> With the current text, the security solution was left for deployments = >> to choose With the new text you're trying to close the solution space = >> to one given solution Let's be fair here: >> - or the security solution is discussed and we do the beauty=20 >> contest with all of them >> - or the security solution is not discussed and we leave the=20 >> discussion for other contexts >> >> Regards >> >> federico >> >> >> >> -----Message d'origine----- >> De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 : >> vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay=20 >> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text Proposal for = >> Compromised MAG issue (was [netlmm] Review >> ofdraft-ietf-netlmm-proxymip6-05) >> >> >> All, >> >> I sincerely do not want to debate the use of revocation for=20 >> compromised MAG at the present time. I am sure that all of us are=20 >> interested in getting this issue addressed properly and have it=20 >> closed sooner than later. What about the following text: >> >> Current text under security consideration: >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> " >> To eliminate the threats related to a compromised mobile access >> gateway, this specification recommends that the local mobility=20 >> anchor >> before accepting a Proxy Binding Update message for a given mobile >> node, should ensure the mobile node is definitively attached to = the >> mobile access gateway that sent the binding registration request. >> " >> >> New Text: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> " >> To eliminate the threats related to a compromised mobile access >> gateway, this specification recommends that the local mobility=20 >> anchor >> before accepting a Proxy Binding Update message for a given mobile >> node, should ensure the mobile node is definitively attached to = the >> mobile access gateway that sent the binding registration request >> by contacting a trusted entity which tracks the MN current=20 >> location, >> e.g. AAA server. >> " >> >> Regards, >> Ahmad >> >> >>> -----Original Message----- >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>> Sent: Wednesday, September 26, 2007 7:41 PM >>> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger >>> Cc: netlmm@ietf.org >>> Subject: RE: Compromised MAG issue (was [netlmm] Review of >>> draft-ietf-netlmm-proxymip6-05) >>> >>> Hi Ahmad, >>> >>> >>>> -----Original Message----- >>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >>>> Sent: Wednesday, September 26, 2007 4:12 PM >>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger >>>> Cc: netlmm@ietf.org >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of >>>> draft-ietf-netlmm-proxymip6-05) >>>> >>>> Hi Vidya, >>>> >>>> Using revocation for the compromised MAG was proposed by >>> Kilian, et. >>>> al. >>>> but I am trying to help closing the issue so please allow >>> me to jump >>>> into this debate. >>>> >>>> In order for the LMA to validate the presence of the MN at >>> a specific >>>> MAG, the LMA needs to do one of the followings: >>>> >>>> 1. Validate the MN identity via a MN signature carried in >>> the P-BU. In >>>> P-MIPv6 this currently is not available since the P-BU is NOT=20 >>>> initiated by the MN. (the most obvious option) >>>> >>>> 2. Validate the MN presence via another trusted entity that >>>> *ALWAYS* tracks the MN current location, e.g. AAA server. >>>> >>>> 3. Validate the MN presence via another trusted entity that >>> tracks the >>>> current or latest location of the MN, e.g. the previous MAG using=20 >>>> binding revocation as was suggested by kilian et. al. >>>> >>> >>> The LMA can't assume that the pMAG is trusted while the new >> MAG is the >> >>> one lying. Perhaps the MN really moved and the pMAG continues to=20 >>> claim it is there. Regardless of which MAG tells the LMA >> what, 1 or 2 >> >>> needs to occur to conclude where the MN really is and then, the LMA=20 >>> can determine which of the MAGs was lying. >>> >>> Regards, >>> Vidya >>> >>>> 4. may be there are other ways... >>>> >>>> In case that the MN is still at pMAG and has not moved, the >>> pMAG can >>>> easily indicate that in the binding revocation acknowledgement. >>>> >>>> So do not you think that should work? >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>>> -----Original Message----- >>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>>>> Sent: Wednesday, September 26, 2007 3:49 PM >>>>> To: Vijay Devarapalli; Kilian Weniger >>>>> Cc: netlmm@ietf.org >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of >>>>> draft-ietf-netlmm-proxymip6-05) >>>>> >>>>> >>>>> A few observations here. I don't believe binding revocation >>>> is going >>>>> to solve anything here. The fundamental issue is how the LMA >>>>> *identifies* the compromised MAG, not how the >> compromised MAG is >>>>> notified that its binding is no longer valid. Once the MAG is=20 >>>>> identified as compromised, a number of remedies may be taken,=20 >>>>> including, simply blacklisting the MAG and not accepting >>>> PBUs from it. >>>>> It is not critical that the binding be revoked, because, >>>> the LMA has >>>>> already identified where the MN really is and it just >>> needs to use >>>>> that binding for data acceptance/forwarding. >>>>> >>>>> >>>>> The issue of how the LMA identifies a compromised MAG cannot be=20 >>>>> tackled without an independent verification of the >>> presence of the >>>>> MN at that particular MAG. So, we need to focus on >>> providing hints >>>>> on how the LMA may go about >>>> achieving that. >>>>> >>>>> Vidya >>>>> >>>>>> -----Original Message----- >>>>>> From: Vijay Devarapalli >> [mailto:vijay.devarapalli@AzaireNet.com] >>>>>> Sent: Wednesday, September 26, 2007 11:08 AM >>>>>> To: Kilian Weniger >>>>>> Cc: Narayanan, Vidya; netlmm@ietf.org >>>>>> Subject: Re: Compromised MAG issue (was [netlmm] Review of >>>>>> draft-ietf-netlmm-proxymip6-05) >>>>>> >>>>>> Kilian Weniger wrote: >>>>>>> Narayanan, Vidya wrote: >>>>>>>>>> - Security considerations: MAG Compromise: >>>>>>> ... >>>>>>>> If we claim this is an issue in the security >>>>>> considerations section >>>>>>>> and claim that the fix to it is for the LMA to ensure >>>> the MN is >>>>>>>> actually attached to the MAG, we can't quite hand >>> wave on some >>>>>>>> possible ways to do that. Those are just hints for >>>>>> deployments that >>>>>>>> are concerned about MAG compromise. But, those hints >>>> need to be >>>>>>>> captured in the security considerations section. >>> The threats >>>>>>>> document captures this threat and it is a valid one - so, >>>>>> I believe >>>>>>>> we need some text here. The type of "detail" is what >>>> I tried to >>>>>>>> provide with the examples on AAA checks or CGA >>>>> signatures - and, I >>>>>>>> don't think we need a lot of detail here; a few >>>>> sentences would be >>>>>>>> good. >>>>>>>> >>>>>>> >>>>>>> I had a similar comment a while ago. I think that a draft >>>>>> describing a >>>>>>> severe security issue should at least give hints how this >>>>>> can be solved. >>>>>>> >>>>>>> Recently Sri, Vijay, Kuntal and I had an offline >>>> discussion about >>>>>>> another possible solution to detect a compromised MAGs, >>>>>> which relies >>>>>>> on PMIP signaling only. >>>>>>> >>>>>>> The basic idea is that if two MAGs simultaneously claim >>>>>> that the MN is >>>>>>> attached, one of the MAGs must lie and is probably a >>>>>> compromised MAG. >>>>>>> The assumption is that the MN cannot at the same time be >>>>>> attached to >>>>>>> two MAGs, at least not with the same network interface. >>>>>>> >>>>>>> More specifically, when the LMA accepts a valid PBU from a >>>>>> new MAG, it >>>>>>> changes the BCE (i.e., there is no impact on handover >>>> delay) and >>>>>>> notifies the old MAG (i.e., old address in BCE) about >>>>> this. The old >>>>>>> MAG then checks whether the MN is still attached. If this >>>>>> is the case, >>>>>>> it informs the LMA about this. The LMA then learns that two >>>>>> different >>>>>>> MAGs claim MN attachement, which is not possible under the >>>>>> assumption >>>>>>> stated above. Hence, after receiving one or more such >>>>>> notifications, >>>>>>> the LMA can identify the compromised MAG and stop >>>>> trusting this MAG. >>>>>>> >>>>>>> A remaining problem was which message should be used to >>>>>> inform the old >>>>>>> MAG about the BCE change. PBA and revocation msg were >>>>>> discussed, but >>>>>>> the former is not sent unsolicited according to RFC3775 >>>>>> (which could >>>>>>> be overidden by PMIP spec of course) and the latter is not=20 >>>>>>> standardized yet. >>>>>> >>>>>> As I said in another threat, we really need to >> standardize the >>>>>> revocation message from the LMA to the old MAG ASAP. >>>>>> >>>>>> Vijay >>>>>> >>>>> >>>>> _______________________________________________ >>>>> netlmm mailing list >>>>> netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>> >>>> >>> >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 11:31:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHoX-0003xA-JQ; Fri, 28 Sep 2007 11:31:37 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbHoW-0003x2-Da for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 11:31:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHoW-0003wp-3x for netlmm@ietf.org; Fri, 28 Sep 2007 11:31:36 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbHoU-0003gO-9e for netlmm@ietf.org; Fri, 28 Sep 2007 11:31:36 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SFU2vI010380; Fri, 28 Sep 2007 17:30:02 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 17:30:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 17:30:46 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AF3@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8EAB@lan-ex-02.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: Acf/sdrXSWxVJRmzQ6G5BsvD3b9qQQAKS7SgAAzXM0AAQwyTcAAne6bAAAU7sKA= References: <46F96DF7.1000702@azairenet.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8D1A@lan-ex-02.panasonic.de> <319D54578EAC3147BA8CC78DAB5467A501399ADA@FRVELSMBS12.ad2.ad.alcatel.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8EAB@lan-ex-02.panasonic.de> From: "DE JUAN HUARTE FEDERICO" To: "Kilian Weniger" X-OriginalArrivalTime: 28 Sep 2007 15:30:47.0413 (UTC) FILETIME=[8ADF7250:01C801E4] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Killian, a couple quick comments about the solution you propose: - it limits the impact but it doesn't avoid it completely: for a = period of time the network is compromised - it can not be generalized to solve the problem when the number of = compromised MAGs is more than one Regards federico -----Message d'origine----- De : Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 Envoy=E9 : vendredi 28 septembre 2007 14:11 =C0 : DE JUAN HUARTE FEDERICO Cc : netlmm@ietf.org Objet : RE: Compromised MAG issue (was [netlmm] Review = ofdraft-ietf-netlmm-proxymip6-05) Hi Frederico,=20 one way to identify a compromised MAG is to rely on notifications from = multiple MAGs and trust the opinion of the majority: If the LMA detects = the situation that two MAGs simultaneously claim attachment of same MN = multiple times and one of the MAGs is always MAG X while the other one = is different each time, the LMA can be pretty sure that MAG X is the = compromised MAG. BR, Kilian > -----Original Message----- > From: DE JUAN HUARTE FEDERICO > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > Sent: Donnerstag, 27. September 2007 20:01 > To: Kilian Weniger > Cc: netlmm@ietf.org > Subject: RE: Compromised MAG issue (was [netlmm] Review > ofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Killian, >=20 > I had been told that this problem was out of scope ... > From your input: > Killian> Hence, after receiving one or more such > notifications, the LMA can identify the compromised MAG and stop=20 > trusting this MAG. > How does the LMA identify the compromised MAG? >=20 > Regards >=20 > federico >=20 > -----Message d'origine----- > De : Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Envoy=E9 : mercredi 26 septembre 2007 10:57 =C0 : Narayanan, Vidya Cc = :=20 > netlmm@ietf.org Objet : Compromised MAG issue (was [netlmm] Review > ofdraft-ietf-netlmm-proxymip6-05) >=20 > Narayanan, Vidya wrote: > > > > - Security considerations: MAG Compromise:=20 > ... > > If we claim this is an issue in the security considerations section=20 > > and claim that the fix to it is for the LMA to ensure the MN is=20 > > actually attached to the MAG, we can't quite hand wave on some=20 > > possible ways to do that. Those are just hints for > deployments that > > are concerned about MAG compromise. But, those hints need to be=20 > > captured in the security considerations section. The > threats document > > captures this threat and it is a valid one - so, I believe we need=20 > > some text here. The type of "detail" is what I tried to > provide with > > the examples on AAA checks or CGA signatures - and, I don't > think we > > need a lot of detail here; a few sentences would be good. > >=20 >=20 > I had a similar comment a while ago. I think that a draft describing a = > severe security issue should at least give hints how this can be=20 > solved. >=20 > Recently Sri, Vijay, Kuntal and I had an offline discussion about=20 > another possible solution to detect a compromised MAGs, which relies=20 > on PMIP signaling only. >=20 > The basic idea is that if two MAGs simultaneously claim that the MN is = > attached, one of the MAGs must lie and is probably a compromised MAG. > The assumption is that the MN cannot at the same time be attached to=20 > two MAGs, at least not with the same network interface. >=20 > More specifically, when the LMA accepts a valid PBU from a new MAG, it = > changes the BCE (i.e., there is no impact on handover delay) and=20 > notifies the old MAG (i.e., old address in BCE) about this. > The old MAG > then checks whether the MN is still attached. If this is the case, it=20 > informs the LMA about this. The LMA then learns that two different=20 > MAGs claim MN attachement, which is not possible under the assumption=20 > stated above. Hence, after receiving one or more such notifications,=20 > the LMA can identify the compromised MAG and stop trusting this MAG. >=20 > A remaining problem was which message should be used to inform the old = > MAG about the BCE change. PBA and revocation msg were discussed, but=20 > the former is not sent unsolicited according to RFC3775 (which could=20 > be overidden by PMIP spec of course) and the latter is not=20 > standardized yet. >=20 > Comments? >=20 > Kilian >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 11:42:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHzB-0001B9-P3; Fri, 28 Sep 2007 11:42:37 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbHz9-00016g-0N for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 11:42:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHz8-00016B-DM for netlmm@ietf.org; Fri, 28 Sep 2007 11:42:34 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbHyz-0003wq-OX for netlmm@ietf.org; Fri, 28 Sep 2007 11:42:34 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8SFgBT04224; Fri, 28 Sep 2007 15:42:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 10:42:04 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711709DA67@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB2/vks+0kQvu4Rt+gKIeCSXJBzQABPUwAAAETAyA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" , "Sri Gundavelli" X-Spam-Score: 0.9 (/) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Sri, Ahmad >=20 > I was fine with the original text > If addressing the security concern is necessary because of=20 > IESG or whatever and you're going to hint at possible=20 > solutions, then I would add as an alternative that the MAG=20 > may add a per-MN signature to the PBU. [Ahmad] This also falls under the proposed text.=20 Again, AAA is given as an example nothing else. Let us forget about the = AAA server for a second. Apparently you do not have a problem with the proposed text but with = listing AAA as an example. Is that right? >=20 > The current proposed alternative: > > .... by contacting a trusted entity which tracks the MN=20 > current location, e.g. AAA server. > it's also fine for me, except that the AAA Server is not a=20 > good example because it only tracks the NAS (not the user nor the MAG) >=20 > One final comment, if the MN can only be attached to one MAG=20 > at a given time, and if the LMA is going to validate the BU=20 > with the AAA Server and the AAA server is capable of tracking=20 > the location of the MAG ... then do we still need timestamps=20 > for message ordering? > It sems to me that the solution for a "compromised MAG"=20 > problem and for BU ordering are actually part of the same=20 > package, since solving the "compormised MAG" problem leads to=20 > the certainty of having only 1 MAG serving the user and then=20 > a SQN per MAG and per MN is sufficient (no need for context transfer) >=20 > Regards >=20 > federico >=20 >=20 > -----Message d'origine----- > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :=20 > vendredi 28 septembre 2007 16:29 =C0 : Ahmad Muhanna Cc : DE=20 > JUAN HUARTE FEDERICO; netlmm Objet : RE: Text Proposal for=20 > Compromised MAG issue (was [netlmm] Review=20 > ofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Federico, >=20 > We need to provide some guidance on how LMA implementations=20 > can esnure the presence of a MN at a given MAG in a=20 > deterministic fashion. One possible way is that the=20 > Authentication infrastructure such as AAA that generated the=20 > keys for the mobile node session would know the current point=20 > of attachment. The LMA can query the same. >=20 > These entire arguments on MAG compromise ..etc, are=20 > loosing arguments. Unfortunately, we have to agree, there may=20 > not be access authentication, but, at the same time we have=20 > to provide all the guidance on how to prevent MAG compromise.=20 > These are all killer arguments. So, these issues just delay=20 > the work. So, lets try to find some text and put a closure to=20 > this work. By adding a reference to AAA, does not imply, we=20 > have mandatory requirement on AAA, or we are making AAA=20 > stateful. Just any reasonable guidance with/without AAA=20 > should be fine. >=20 > Sri >=20 >=20 >=20 >=20 >=20 > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: >=20 > > Hi Federico, > > > > It is very nice to know that we are getting into the beauty=20 > context.:) > > > > Please let us focus on all of the added text: > > > > " > > .... by contacting a trusted entity which tracks the MN=20 > current location, e.g. AAA server. > > " > > > > If AAA server is not stateful, then deployment may use=20 > another trusted entity and that is granted by the above text. > > Originally I am in favor of leaving the whole thing=20 > out-of-scope all together, but listing AAA server as an=20 > example does not eliminate any other security mechanisms nor=20 > require that all deployment have AAA server as stateful. > > > > Do not you agree? > > > > Sincerely, If we do not have any serious objection to this=20 > text, we need to close the issue and move on. > > Thanks. > > > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: DE JUAN HUARTE FEDERICO > >> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > >> Sent: Friday, September 28, 2007 4:23 AM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: netlmm > >> Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]=20 > >> Review ofdraft-ietf-netlmm-proxymip6-05) > >> > >> Hi Ahmad, > >> > >> in my understanding there's a general motivation to make=20 > AAA Servers=20 > >> stateless, so the draft should not put such a strong "tracking" > >> requirement It is clear to me that in some/many=20 > deployments the AAA=20 > >> Server is not stateless anyway, so this is a minor comment=20 > But then,=20 > >> what the AAA Server actually tracks is the NAS and not=20 > really the MAG=20 > >> Somehow you're assuming that the AAA Server is aware of the=20 > >> relationship between NASs and MAGs > >> > >> With the current text, the security solution was left for=20 > deployments=20 > >> to choose With the new text you're trying to close the=20 > solution space=20 > >> to one given solution Let's be fair here: > >> - or the security solution is discussed and we do the beauty=20 > >> contest with all of them > >> - or the security solution is not discussed and we leave the=20 > >> discussion for other contexts > >> > >> Regards > >> > >> federico > >> > >> > >> > >> -----Message d'origine----- > >> De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 : > >> vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay=20 > >> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text=20 > Proposal for=20 > >> Compromised MAG issue (was [netlmm] Review > >> ofdraft-ietf-netlmm-proxymip6-05) > >> > >> > >> All, > >> > >> I sincerely do not want to debate the use of revocation for=20 > >> compromised MAG at the present time. I am sure that all of us are=20 > >> interested in getting this issue addressed properly and have it=20 > >> closed sooner than later. What about the following text: > >> > >> Current text under security consideration: > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> " > >> To eliminate the threats related to a compromised mobile access > >> gateway, this specification recommends that the local mobility=20 > >> anchor > >> before accepting a Proxy Binding Update message for a=20 > given mobile > >> node, should ensure the mobile node is definitively=20 > attached to the > >> mobile access gateway that sent the binding=20 > registration request. > >> " > >> > >> New Text: > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> " > >> To eliminate the threats related to a compromised mobile access > >> gateway, this specification recommends that the local mobility=20 > >> anchor > >> before accepting a Proxy Binding Update message for a=20 > given mobile > >> node, should ensure the mobile node is definitively=20 > attached to the > >> mobile access gateway that sent the binding registration request > >> by contacting a trusted entity which tracks the MN current=20 > >> location, > >> e.g. AAA server. > >> " > >> > >> Regards, > >> Ahmad > >> > >> > >>> -----Original Message----- > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>> Sent: Wednesday, September 26, 2007 7:41 PM > >>> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger > >>> Cc: netlmm@ietf.org > >>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>> draft-ietf-netlmm-proxymip6-05) > >>> > >>> Hi Ahmad, > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > >>>> Sent: Wednesday, September 26, 2007 4:12 PM > >>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > >>>> Cc: netlmm@ietf.org > >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>> draft-ietf-netlmm-proxymip6-05) > >>>> > >>>> Hi Vidya, > >>>> > >>>> Using revocation for the compromised MAG was proposed by > >>> Kilian, et. > >>>> al. > >>>> but I am trying to help closing the issue so please allow > >>> me to jump > >>>> into this debate. > >>>> > >>>> In order for the LMA to validate the presence of the MN at > >>> a specific > >>>> MAG, the LMA needs to do one of the followings: > >>>> > >>>> 1. Validate the MN identity via a MN signature carried in > >>> the P-BU. In > >>>> P-MIPv6 this currently is not available since the P-BU is NOT=20 > >>>> initiated by the MN. (the most obvious option) > >>>> > >>>> 2. Validate the MN presence via another trusted entity that > >>>> *ALWAYS* tracks the MN current location, e.g. AAA server. > >>>> > >>>> 3. Validate the MN presence via another trusted entity that > >>> tracks the > >>>> current or latest location of the MN, e.g. the previous=20 > MAG using=20 > >>>> binding revocation as was suggested by kilian et. al. > >>>> > >>> > >>> The LMA can't assume that the pMAG is trusted while the new > >> MAG is the > >> > >>> one lying. Perhaps the MN really moved and the pMAG continues to=20 > >>> claim it is there. Regardless of which MAG tells the LMA > >> what, 1 or 2 > >> > >>> needs to occur to conclude where the MN really is and=20 > then, the LMA=20 > >>> can determine which of the MAGs was lying. > >>> > >>> Regards, > >>> Vidya > >>> > >>>> 4. may be there are other ways... > >>>> > >>>> In case that the MN is still at pMAG and has not moved, the > >>> pMAG can > >>>> easily indicate that in the binding revocation acknowledgement. > >>>> > >>>> So do not you think that should work? > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>>>> Sent: Wednesday, September 26, 2007 3:49 PM > >>>>> To: Vijay Devarapalli; Kilian Weniger > >>>>> Cc: netlmm@ietf.org > >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>>> draft-ietf-netlmm-proxymip6-05) > >>>>> > >>>>> > >>>>> A few observations here. I don't believe binding revocation > >>>> is going > >>>>> to solve anything here. The fundamental issue is how the LMA > >>>>> *identifies* the compromised MAG, not how the > >> compromised MAG is > >>>>> notified that its binding is no longer valid. Once the MAG is=20 > >>>>> identified as compromised, a number of remedies may be taken,=20 > >>>>> including, simply blacklisting the MAG and not accepting > >>>> PBUs from it. > >>>>> It is not critical that the binding be revoked, because, > >>>> the LMA has > >>>>> already identified where the MN really is and it just > >>> needs to use > >>>>> that binding for data acceptance/forwarding. > >>>>> > >>>>> > >>>>> The issue of how the LMA identifies a compromised MAG cannot be=20 > >>>>> tackled without an independent verification of the > >>> presence of the > >>>>> MN at that particular MAG. So, we need to focus on > >>> providing hints > >>>>> on how the LMA may go about > >>>> achieving that. > >>>>> > >>>>> Vidya > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Vijay Devarapalli > >> [mailto:vijay.devarapalli@AzaireNet.com] > >>>>>> Sent: Wednesday, September 26, 2007 11:08 AM > >>>>>> To: Kilian Weniger > >>>>>> Cc: Narayanan, Vidya; netlmm@ietf.org > >>>>>> Subject: Re: Compromised MAG issue (was [netlmm] Review of > >>>>>> draft-ietf-netlmm-proxymip6-05) > >>>>>> > >>>>>> Kilian Weniger wrote: > >>>>>>> Narayanan, Vidya wrote: > >>>>>>>>>> - Security considerations: MAG Compromise: > >>>>>>> ... > >>>>>>>> If we claim this is an issue in the security > >>>>>> considerations section > >>>>>>>> and claim that the fix to it is for the LMA to ensure > >>>> the MN is > >>>>>>>> actually attached to the MAG, we can't quite hand > >>> wave on some > >>>>>>>> possible ways to do that. Those are just hints for > >>>>>> deployments that > >>>>>>>> are concerned about MAG compromise. But, those hints > >>>> need to be > >>>>>>>> captured in the security considerations section. > >>> The threats > >>>>>>>> document captures this threat and it is a valid one - so, > >>>>>> I believe > >>>>>>>> we need some text here. The type of "detail" is what > >>>> I tried to > >>>>>>>> provide with the examples on AAA checks or CGA > >>>>> signatures - and, I > >>>>>>>> don't think we need a lot of detail here; a few > >>>>> sentences would be > >>>>>>>> good. > >>>>>>>> > >>>>>>> > >>>>>>> I had a similar comment a while ago. I think that a draft > >>>>>> describing a > >>>>>>> severe security issue should at least give hints how this > >>>>>> can be solved. > >>>>>>> > >>>>>>> Recently Sri, Vijay, Kuntal and I had an offline > >>>> discussion about > >>>>>>> another possible solution to detect a compromised MAGs, > >>>>>> which relies > >>>>>>> on PMIP signaling only. > >>>>>>> > >>>>>>> The basic idea is that if two MAGs simultaneously claim > >>>>>> that the MN is > >>>>>>> attached, one of the MAGs must lie and is probably a > >>>>>> compromised MAG. > >>>>>>> The assumption is that the MN cannot at the same time be > >>>>>> attached to > >>>>>>> two MAGs, at least not with the same network interface. > >>>>>>> > >>>>>>> More specifically, when the LMA accepts a valid PBU from a > >>>>>> new MAG, it > >>>>>>> changes the BCE (i.e., there is no impact on handover > >>>> delay) and > >>>>>>> notifies the old MAG (i.e., old address in BCE) about > >>>>> this. The old > >>>>>>> MAG then checks whether the MN is still attached. If this > >>>>>> is the case, > >>>>>>> it informs the LMA about this. The LMA then learns that two > >>>>>> different > >>>>>>> MAGs claim MN attachement, which is not possible under the > >>>>>> assumption > >>>>>>> stated above. Hence, after receiving one or more such > >>>>>> notifications, > >>>>>>> the LMA can identify the compromised MAG and stop > >>>>> trusting this MAG. > >>>>>>> > >>>>>>> A remaining problem was which message should be used to > >>>>>> inform the old > >>>>>>> MAG about the BCE change. PBA and revocation msg were > >>>>>> discussed, but > >>>>>>> the former is not sent unsolicited according to RFC3775 > >>>>>> (which could > >>>>>>> be overidden by PMIP spec of course) and the latter is not=20 > >>>>>>> standardized yet. > >>>>>> > >>>>>> As I said in another threat, we really need to > >> standardize the > >>>>>> revocation message from the LMA to the old MAG ASAP. > >>>>>> > >>>>>> Vijay > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>> > >>>> > >>> > >> > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 11:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbI1c-0005x1-Pu; Fri, 28 Sep 2007 11:45:08 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbI1a-0005uA-Vr for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 11:45:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbI1a-0005u2-M5 for netlmm@ietf.org; Fri, 28 Sep 2007 11:45:06 -0400 Received: from web84104.mail.mud.yahoo.com ([68.142.206.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbI1U-00040V-CB for netlmm@ietf.org; Fri, 28 Sep 2007 11:45:06 -0400 Received: (qmail 20146 invoked by uid 60001); 28 Sep 2007 15:44:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ykfRXEW+1NeWnw/RkJVCrOciMfDNxv0sbuUrTFG+9BT3MuQ3a698n2a9z3RFpI0AGQltl8VcMSpldknGRUW8aFpRVle6DExKFm3ZOqWUnupXaIPBtuYVtULV3azy0V02meQi1XLfvRz0rjLypIztPoB/eLC5z700rd0Ne4fTj1s=; X-YMail-OSG: qeIGmAQVM1mW6a152qTyqY10.BktZbniInHjpdlxvUxMkOJ_E.Af1L7PamULvsKI6tichfGVPlidfqi19OJtSBaAYmI5bN4dygk2FmhWlpRGV_k- Received: from [206.16.17.212] by web84104.mail.mud.yahoo.com via HTTP; Fri, 28 Sep 2007 08:44:44 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Fri, 28 Sep 2007 08:44:44 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs To: Sri Gundavelli MIME-Version: 1.0 Message-ID: <625514.19833.qm@web84104.mail.mud.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0694562843==" Errors-To: netlmm-bounces@ietf.org --===============0694562843== Content-Type: multipart/alternative; boundary="0-16044804-1190994284=:19833" --0-16044804-1190994284=:19833 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Sri,=0A I am for simply stating that multi-homed MNs and compromised MA= Gs are out of scope of this document.=0A Regards,=0A=0ABehcet=0A=0A----- O= riginal Message ----=0AFrom: Sri Gundavelli =0ATo: DE J= UAN HUARTE FEDERICO ; "Narayanan= , Vidya" =0ACc: netlmm@ietf.org=0ASent: Friday, Septem= ber 28, 2007 9:57:09 AM=0ASubject: RE: [netlmm] Issue: Prefix allocation an= d multihomed MNs=0A=0A =0A=0A> On a side note and as FMI, Vidya's problem s= tatement includes =0A> that a host with multiple interfaces will shutdown o= ne of =0A> them when it sees a duplicated IP@.=0A> May I ask where such beh= avior is defined?=0A=0ANo where, as far as I know. It is perfectly valid to= configure=0Atwo interfaces on the same subnet/prefix. Each interface will= =0Aobtain a different address, when using SLAAC or using DHCPv6.=0ABut, it = is invalid to enable ip.forwarding in such scenario.=0AIn other words, a ho= st can do this, but not a router. =0A=0AYou can try that out using your Lin= ux or Windows machine.=0A=0AI do not agree we should discuss about multi-ho= ming and so=0AI'm ok to add some text and move on. =0A=0ASri=0A=0A=0A=0A__= _____________________________________________=0Anetlmm mailing list=0Anetlm= m@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/netlmm=0A=0A=0A=0A=0A --0-16044804-1190994284=:19833 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi Sri,
  I am for simply stating that multi-h= omed MNs and compromised MAGs are out of scope of this document.
  = Regards,

Behcet

----- Original Message ----
From: = Sri Gundavelli <sgundave@cisco.com>
To: DE JUAN HUARTE FEDERICO &l= t;Federico.De_Juan_Huarte@alcatel-lucent.fr>; "Narayanan, Vidya" <vid= yan@qualcomm.com>
Cc: netlmm@ietf.org
Sent: Friday, September 28, = 2007 9:57:09 AM
Subject: RE: [netlmm] Issue: Prefix allocation and multi= homed MNs



> On a side note and as FMI, Vidya's prob= lem statement includes
> that a host with multiple interfaces will shutdown one of
> them when it sees a duplicated IP@.
> May I= ask where such behavior is defined?

No where, as far as I know. It = is perfectly valid to configure
two interfaces on the same subnet/prefix= . Each interface will
obtain a different address, when using SLAAC or us= ing DHCPv6.
But, it is invalid to enable ip.forwarding in such scenario.=
In other words, a host can do this, but not a router.

You can t= ry that out using your Linux or Windows machine.

I do not agree we s= hould discuss about multi-homing and so
I'm ok to add some text and move= on.  

Sri



________________________________= _______________
netlmm mailing list
netlmm@ietf.org
https://www1.= ietf.org/mailman/listinfo/netlmm

= --0-16044804-1190994284=:19833-- --===============0694562843== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0694562843==-- From netlmm-bounces@ietf.org Fri Sep 28 11:52:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbI8R-0001Wq-DN; Fri, 28 Sep 2007 11:52:11 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbI8Q-0001WJ-1x for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 11:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbI8P-0001W9-Ob for netlmm@ietf.org; Fri, 28 Sep 2007 11:52:09 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbI8N-0004fF-Nc for netlmm@ietf.org; Fri, 28 Sep 2007 11:52:09 -0400 X-IronPort-AV: E=Sophos;i="4.21,210,1188802800"; d="scan'208";a="178146182" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2007 08:52:07 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8SFq745011287; Fri, 28 Sep 2007 08:52:07 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8SFq7DM010122; Fri, 28 Sep 2007 15:52:07 GMT Date: Fri, 28 Sep 2007 08:52:06 -0700 (PDT) From: Sri Gundavelli To: Behcet Sarikaya Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: <625514.19833.qm@web84104.mail.mud.yahoo.com> Message-ID: References: <625514.19833.qm@web84104.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=297; t=1190994727; x=1191858727; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=F7pr/C9WUePemDH4r4MNYOnDQr1SdisTEBz16PlgBSo=; b=oK1P/AZDRPgKJ8C8mg6n1o77DtxPRcbNIN5rJZUlZlyHuSUEMFa0hX1mMp5PWCpi0G8MN2k6 OGF4mnpcRtsCPxmZJ1wUqdcZDf/bQYOtq8GX7o0Ooena309IuT1v1fCLalm/xvxSflv/K3V0ww MXcq7ysQP4ak9fhqYRa4HoaYM=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Behcet, On Fri, 28 Sep 2007, Behcet Sarikaya wrote: > Hi Sri, > I am for simply stating that multi-homed MNs and compromised MAGs are out of scope of this document. > Regards, > Ok. We will add the text as we are discussing in the other threads and close this issue. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 11:57:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIDV-000586-Q0; Fri, 28 Sep 2007 11:57:25 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbIDU-00056c-9w for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 11:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIDU-00054b-0E for netlmm@ietf.org; Fri, 28 Sep 2007 11:57:24 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbIDH-0005Gu-Uy for netlmm@ietf.org; Fri, 28 Sep 2007 11:57:20 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id F0E762C020D48; Fri, 28 Sep 2007 18:56:56 +0300 (EEST) Date: Fri, 28 Sep 2007 18:56:56 +0300 (EEST) From: Wassim Haddad To: DE JUAN HUARTE FEDERICO Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-1888668737-1190995016=:1993" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---377318441-1888668737-1190995016=:1993 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 28 Sep 2007, DE JUAN HUARTE FEDERICO wrote: > One final comment, if the MN can only be attached to one MAG at a given t= ime, and if the LMA > is going to validate the BU with the AAA Server and the AAA server is cap= able of tracking the > location of the MAG ... then do we still need timestamps for message orde= ring? =3D> It is not only this feature which may be questionable. In fact, what= =20 Ahmad is proposing about AAA (which btw is interesting) can significantly enhance the protocol in many ways: If the AAA is able to tell the LMA where the MN is located (i.e., the MAG), then you can simply let the LMA updates the MAG (instead of the opposite) and also let the LMA sends to the MAG a temporary key to provide all SeND features without the need for CGA. So basically, you can address the MAG=20 compromise problem together with the CGA problem... Regards, Wassim H. > -----Message d'origine----- > De : Sri Gundavelli [mailto:sgundave@cisco.com] > Envoy=E9 : vendredi 28 septembre 2007 16:29 > =C0 : Ahmad Muhanna > Cc : DE JUAN HUARTE FEDERICO; netlmm > Objet : RE: Text Proposal for Compromised MAG issue (was [netlmm] Review = ofdraft-ietf-netlmm-proxymip6-05) > > Hi Federico, > > We need to provide some guidance on how LMA implementations can esnure th= e presence of a MN at a given MAG in a deterministic fashion. One possible = way is that the Authentication infrastructure such as AAA that generated th= e keys for the mobile node session would know the current point of attachme= nt. The LMA can query the same. > > These entire arguments on MAG compromise ..etc, are loosing argumen= ts. Unfortunately, we have to agree, there may not be access authentication= , but, at the same time we have to provide all the guidance on how to preve= nt MAG compromise. These are all killer arguments. So, these issues just de= lay the work. So, lets try to find some text and put a closure to this work= =2E By adding a reference to AAA, does not imply, we have mandatory require= ment on AAA, or we are making AAA stateful. Just any reasonable guidance w= ith/without AAA should be fine. > > Sri > > > > > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > >> Hi Federico, >> >> It is very nice to know that we are getting into the beauty context.:) >> >> Please let us focus on all of the added text: >> >> " >> .... by contacting a trusted entity which tracks the MN current location= , e.g. AAA server. >> " >> >> If AAA server is not stateful, then deployment may use another trusted e= ntity and that is granted by the above text. >> Originally I am in favor of leaving the whole thing out-of-scope all tog= ether, but listing AAA server as an example does not eliminate any other se= curity mechanisms nor require that all deployment have AAA server as statef= ul. >> >> Do not you agree? >> >> Sincerely, If we do not have any serious objection to this text, we need= to close the issue and move on. >> Thanks. >> >> >> Regards, >> Ahmad >> >> >>> -----Original Message----- >>> From: DE JUAN HUARTE FEDERICO >>> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] >>> Sent: Friday, September 28, 2007 4:23 AM >>> To: Muhanna, Ahmad (RICH1:2H10) >>> Cc: netlmm >>> Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] >>> Review ofdraft-ietf-netlmm-proxymip6-05) >>> >>> Hi Ahmad, >>> >>> in my understanding there's a general motivation to make AAA Servers >>> stateless, so the draft should not put such a strong "tracking" >>> requirement It is clear to me that in some/many deployments the AAA >>> Server is not stateless anyway, so this is a minor comment But then, >>> what the AAA Server actually tracks is the NAS and not really the MAG >>> Somehow you're assuming that the AAA Server is aware of the >>> relationship between NASs and MAGs >>> >>> With the current text, the security solution was left for deployments >>> to choose With the new text you're trying to close the solution space >>> to one given solution Let's be fair here: >>> - or the security solution is discussed and we do the beauty >>> contest with all of them >>> - or the security solution is not discussed and we leave the >>> discussion for other contexts >>> >>> Regards >>> >>> federico >>> >>> >>> >>> -----Message d'origine----- >>> De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 : >>> vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay >>> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text Proposal for >>> Compromised MAG issue (was [netlmm] Review >>> ofdraft-ietf-netlmm-proxymip6-05) >>> >>> >>> All, >>> >>> I sincerely do not want to debate the use of revocation for >>> compromised MAG at the present time. I am sure that all of us are >>> interested in getting this issue addressed properly and have it >>> closed sooner than later. What about the following text: >>> >>> Current text under security consideration: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> " >>> To eliminate the threats related to a compromised mobile access >>> gateway, this specification recommends that the local mobility >>> anchor >>> before accepting a Proxy Binding Update message for a given mobile >>> node, should ensure the mobile node is definitively attached to the >>> mobile access gateway that sent the binding registration request. >>> " >>> >>> New Text: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> " >>> To eliminate the threats related to a compromised mobile access >>> gateway, this specification recommends that the local mobility >>> anchor >>> before accepting a Proxy Binding Update message for a given mobile >>> node, should ensure the mobile node is definitively attached to the >>> mobile access gateway that sent the binding registration request >>> by contacting a trusted entity which tracks the MN current >>> location, >>> e.g. AAA server. >>> " >>> >>> Regards, >>> Ahmad >>> >>> >>>> -----Original Message----- >>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>>> Sent: Wednesday, September 26, 2007 7:41 PM >>>> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger >>>> Cc: netlmm@ietf.org >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of >>>> draft-ietf-netlmm-proxymip6-05) >>>> >>>> Hi Ahmad, >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >>>>> Sent: Wednesday, September 26, 2007 4:12 PM >>>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger >>>>> Cc: netlmm@ietf.org >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of >>>>> draft-ietf-netlmm-proxymip6-05) >>>>> >>>>> Hi Vidya, >>>>> >>>>> Using revocation for the compromised MAG was proposed by >>>> Kilian, et. >>>>> al. >>>>> but I am trying to help closing the issue so please allow >>>> me to jump >>>>> into this debate. >>>>> >>>>> In order for the LMA to validate the presence of the MN at >>>> a specific >>>>> MAG, the LMA needs to do one of the followings: >>>>> >>>>> 1. Validate the MN identity via a MN signature carried in >>>> the P-BU. In >>>>> P-MIPv6 this currently is not available since the P-BU is NOT >>>>> initiated by the MN. (the most obvious option) >>>>> >>>>> 2. Validate the MN presence via another trusted entity that >>>>> *ALWAYS* tracks the MN current location, e.g. AAA server. >>>>> >>>>> 3. Validate the MN presence via another trusted entity that >>>> tracks the >>>>> current or latest location of the MN, e.g. the previous MAG using >>>>> binding revocation as was suggested by kilian et. al. >>>>> >>>> >>>> The LMA can't assume that the pMAG is trusted while the new >>> MAG is the >>> >>>> one lying. Perhaps the MN really moved and the pMAG continues to >>>> claim it is there. Regardless of which MAG tells the LMA >>> what, 1 or 2 >>> >>>> needs to occur to conclude where the MN really is and then, the LMA >>>> can determine which of the MAGs was lying. >>>> >>>> Regards, >>>> Vidya >>>> >>>>> 4. may be there are other ways... >>>>> >>>>> In case that the MN is still at pMAG and has not moved, the >>>> pMAG can >>>>> easily indicate that in the binding revocation acknowledgement. >>>>> >>>>> So do not you think that should work? >>>>> >>>>> Regards, >>>>> Ahmad >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>>>>> Sent: Wednesday, September 26, 2007 3:49 PM >>>>>> To: Vijay Devarapalli; Kilian Weniger >>>>>> Cc: netlmm@ietf.org >>>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of >>>>>> draft-ietf-netlmm-proxymip6-05) >>>>>> >>>>>> >>>>>> A few observations here. I don't believe binding revocation >>>>> is going >>>>>> to solve anything here. The fundamental issue is how the LMA >>>>>> *identifies* the compromised MAG, not how the >>> compromised MAG is >>>>>> notified that its binding is no longer valid. Once the MAG is >>>>>> identified as compromised, a number of remedies may be taken, >>>>>> including, simply blacklisting the MAG and not accepting >>>>> PBUs from it. >>>>>> It is not critical that the binding be revoked, because, >>>>> the LMA has >>>>>> already identified where the MN really is and it just >>>> needs to use >>>>>> that binding for data acceptance/forwarding. >>>>>> >>>>>> >>>>>> The issue of how the LMA identifies a compromised MAG cannot be >>>>>> tackled without an independent verification of the >>>> presence of the >>>>>> MN at that particular MAG. So, we need to focus on >>>> providing hints >>>>>> on how the LMA may go about >>>>> achieving that. >>>>>> >>>>>> Vidya >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vijay Devarapalli >>> [mailto:vijay.devarapalli@AzaireNet.com] >>>>>>> Sent: Wednesday, September 26, 2007 11:08 AM >>>>>>> To: Kilian Weniger >>>>>>> Cc: Narayanan, Vidya; netlmm@ietf.org >>>>>>> Subject: Re: Compromised MAG issue (was [netlmm] Review of >>>>>>> draft-ietf-netlmm-proxymip6-05) >>>>>>> >>>>>>> Kilian Weniger wrote: >>>>>>>> Narayanan, Vidya wrote: >>>>>>>>>>> - Security considerations: MAG Compromise: >>>>>>>> ... >>>>>>>>> If we claim this is an issue in the security >>>>>>> considerations section >>>>>>>>> and claim that the fix to it is for the LMA to ensure >>>>> the MN is >>>>>>>>> actually attached to the MAG, we can't quite hand >>>> wave on some >>>>>>>>> possible ways to do that. Those are just hints for >>>>>>> deployments that >>>>>>>>> are concerned about MAG compromise. But, those hints >>>>> need to be >>>>>>>>> captured in the security considerations section. >>>> The threats >>>>>>>>> document captures this threat and it is a valid one - so, >>>>>>> I believe >>>>>>>>> we need some text here. The type of "detail" is what >>>>> I tried to >>>>>>>>> provide with the examples on AAA checks or CGA >>>>>> signatures - and, I >>>>>>>>> don't think we need a lot of detail here; a few >>>>>> sentences would be >>>>>>>>> good. >>>>>>>>> >>>>>>>> >>>>>>>> I had a similar comment a while ago. I think that a draft >>>>>>> describing a >>>>>>>> severe security issue should at least give hints how this >>>>>>> can be solved. >>>>>>>> >>>>>>>> Recently Sri, Vijay, Kuntal and I had an offline >>>>> discussion about >>>>>>>> another possible solution to detect a compromised MAGs, >>>>>>> which relies >>>>>>>> on PMIP signaling only. >>>>>>>> >>>>>>>> The basic idea is that if two MAGs simultaneously claim >>>>>>> that the MN is >>>>>>>> attached, one of the MAGs must lie and is probably a >>>>>>> compromised MAG. >>>>>>>> The assumption is that the MN cannot at the same time be >>>>>>> attached to >>>>>>>> two MAGs, at least not with the same network interface. >>>>>>>> >>>>>>>> More specifically, when the LMA accepts a valid PBU from a >>>>>>> new MAG, it >>>>>>>> changes the BCE (i.e., there is no impact on handover >>>>> delay) and >>>>>>>> notifies the old MAG (i.e., old address in BCE) about >>>>>> this. The old >>>>>>>> MAG then checks whether the MN is still attached. If this >>>>>>> is the case, >>>>>>>> it informs the LMA about this. The LMA then learns that two >>>>>>> different >>>>>>>> MAGs claim MN attachement, which is not possible under the >>>>>>> assumption >>>>>>>> stated above. Hence, after receiving one or more such >>>>>>> notifications, >>>>>>>> the LMA can identify the compromised MAG and stop >>>>>> trusting this MAG. >>>>>>>> >>>>>>>> A remaining problem was which message should be used to >>>>>>> inform the old >>>>>>>> MAG about the BCE change. PBA and revocation msg were >>>>>>> discussed, but >>>>>>>> the former is not sent unsolicited according to RFC3775 >>>>>>> (which could >>>>>>>> be overidden by PMIP spec of course) and the latter is not >>>>>>>> standardized yet. >>>>>>> >>>>>>> As I said in another threat, we really need to >>> standardize the >>>>>>> revocation message from the LMA to the old MAG ASAP. >>>>>>> >>>>>>> Vijay >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netlmm mailing list >>>>>> netlmm@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm > > ---377318441-1888668737-1190995016=:1993 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm ---377318441-1888668737-1190995016=:1993-- From netlmm-bounces@ietf.org Fri Sep 28 12:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIGn-0008MW-FS; Fri, 28 Sep 2007 12:00:49 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbIGl-0008Ih-AS for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIGk-0008IN-RF for netlmm@ietf.org; Fri, 28 Sep 2007 12:00:46 -0400 Received: from cluster-g.mailcontrol.com ([85.115.41.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbIGd-0005QN-P1 for netlmm@ietf.org; Fri, 28 Sep 2007 12:00:46 -0400 Received: from rly13g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly13g.srv.mailcontrol.com (MailControl) with ESMTP id l8SG0Mmb019031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Sep 2007 17:00:26 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly13g.srv.mailcontrol.com (MailControl) id l8SFxqPp017115 for netlmm@ietf.org; Fri, 28 Sep 2007 16:59:52 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly13g-eth0.srv.mailcontrol.com (envelope-sender Genadi.Velev@eu.panasonic.com) (MIMEDefang) with ESMTP id l8SFxib5016716; Fri, 28 Sep 2007 16:59:52 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 260e_3340f6dc_6ddb_11dc_977c_0030482aac25; Fri, 28 Sep 2007 17:55:13 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007092817594012-38747 ; Fri, 28 Sep 2007 17:59:40 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.120,BAYES_00: -1.665,TOTAL_SCORE: -1.545 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 28 Sep 2007 17:59:20 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgB2hUdvbTtGdHSTqmQpprklkoYOwAC8wCA References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8EA2@lan-ex-02.panasonic.de> To: "Sri Gundavelli" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB4F8EE7@lan-ex-02.panasonic.de> Date: Fri, 28 Sep 2007 17:59:24 +0200 From: "Genadi Velev" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-08-10 (www.mailcontrol.com) on 10.71.1.123 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.9 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Sri, it seems that we converge on this issue :-) I was also agnostic on any of the initial options 1-4. Of course the simplest way to go forward is to describe options 1 and 2. The operator can choose between not allowing multiple interfaces to be simultaneously attached (option 1) or to support multiple interfaces to be attached but assuring that different MN-ID is assigned to each interface. =20 Option 3 still needs to be worked out in draft-muhanna-mip6-binding-revocation-01, as discussed by Kilian and Vijay. So, we can leave it out for the base PMIP specification.=20 Genadi > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Friday, September 28, 2007 4:15 PM > To: Genadi Velev > Cc: Narayanan, Vidya; ext Kilian Weniger; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Hi Genadi, >=20 > Please see inline. >=20 >=20 > On Fri, 28 Sep 2007, Genadi Velev wrote: >=20 >=20 > > I can think about several approaches to overcome this issue: > > 1) we can specify that the network operator shall take care of > > preventing that a MN attaches with 2 interfaces to a PMIP domain (at > > least to the same LMA). For example, the operator doesn't allow > > attachment (i.e. authorization) of interface 2, since interface 1 is > > still attached. >=20 >=20 > > 2) we can write a short text in the draft that the network operator > > shall take care about assignment of different MN-ID (NAI)=20 > to different > > interfaces during attachment procedure. >=20 > > 3) we can describe how the current protocol behaves when a=20 > MN attempts > > to attach with two interfaces. Similar to what is explained=20 > in Vijay's > > email: > > http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html >=20 > I'm ok with any of the above three options. We can certainly document > the scenario and close the issue. I do no think, we should try to > solve this problem here or use this issue to explicitly add text to > block the inter-access handoff, we did not do any thing to=20 > support that > scenario. When the charter says, its out of scope, we dont=20 > need to solve > all the issues, when the scenario is enabled. Operators can solve this > issue, these are managed deployments. Its not a like a=20 > consumer buying a > device and turning it on at home. So, I agree with your above three > suggested options. >=20 > Regards > Sri >=20 >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 12:32:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIku-0006nS-1U; Fri, 28 Sep 2007 12:31:56 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbIks-0006ly-Oo for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:31:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIks-0006lH-Es for netlmm@ietf.org; Fri, 28 Sep 2007 12:31:54 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbIkk-0006AI-82 for netlmm@ietf.org; Fri, 28 Sep 2007 12:31:54 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8SGVKF15517; Fri, 28 Sep 2007 16:31:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 11:31:17 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB6DfKDfRR1RcOR/ybAFUZm7QULwAAbLBg References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "Wassim Haddad" , "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.9 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Wassim, Please see comment below. Regards, Ahmad > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) >=20 > On Fri, 28 Sep 2007, DE JUAN HUARTE FEDERICO wrote: >=20 > > One final comment, if the MN can only be attached to one MAG at a=20 > > given time, and if the LMA is going to validate the BU with the AAA=20 > > Server and the AAA server is capable of tracking the=20 > location of the MAG ... then do we still need timestamps for=20 > message ordering? >=20 > =3D> It is not only this feature which may be questionable. =20 [Ahmad] May be you can help us understand how this feature is questionable with = the proposed text hint? > In=20 > fact, what Ahmad is proposing about AAA (which btw is=20 > interesting) can significantly enhance the protocol in many ways: > If the AAA is able to tell the LMA where the MN is located=20 > (i.e., the MAG), =20 [Ahmad] So, can I read this that you think it is impossible and does not make = sense? > then you can simply let the LMA updates the=20 > MAG (instead of the opposite)=20 [Ahmad] I am not experienced with those reverse logic mechanisms but I am = willing to listen to your theory in a separate thread! > and also let the LMA sends to=20 > the MAG a temporary key to provide all SeND features without=20 > the need for CGA. So basically, you can address the MAG=20 > compromise problem together with the CGA problem... [Ahmad] Just FYI:=20 1. A detailed solution for the so called compromised MAG is = out-of-scope. 2. The text hint including the AAA has been proposed several times = before on the ml by different people. Finally, if you have a different text to propose (with the above 1 & 2 = in mind) that would be great! >=20 >=20 > Regards, >=20 > Wassim H. >=20 >=20 >=20 > > -----Message d'origine----- > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :=20 > vendredi 28=20 > > septembre 2007 16:29 =C0 : Ahmad Muhanna Cc : DE JUAN HUARTE=20 > FEDERICO;=20 > > netlmm Objet : RE: Text Proposal for Compromised MAG issue (was=20 > > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) > > > > Hi Federico, > > > > We need to provide some guidance on how LMA implementations=20 > can esnure the presence of a MN at a given MAG in a=20 > deterministic fashion. One possible way is that the=20 > Authentication infrastructure such as AAA that generated the=20 > keys for the mobile node session would know the current point=20 > of attachment. The LMA can query the same. > > > > These entire arguments on MAG compromise ..etc, are=20 > loosing arguments. Unfortunately, we have to agree, there may=20 > not be access authentication, but, at the same time we have=20 > to provide all the guidance on how to prevent MAG compromise.=20 > These are all killer arguments. So, these issues just delay=20 > the work. So, lets try to find some text and put a closure to=20 > this work. By adding a reference to AAA, does not imply, we=20 > have mandatory requirement on AAA, or we are making AAA=20 > stateful. Just any reasonable guidance with/without AAA=20 > should be fine. > > > > Sri > > > > > > > > > > > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > > > >> Hi Federico, > >> > >> It is very nice to know that we are getting into the beauty=20 > >> context.:) > >> > >> Please let us focus on all of the added text: > >> > >> " > >> .... by contacting a trusted entity which tracks the MN=20 > current location, e.g. AAA server. > >> " > >> > >> If AAA server is not stateful, then deployment may use=20 > another trusted entity and that is granted by the above text. > >> Originally I am in favor of leaving the whole thing=20 > out-of-scope all together, but listing AAA server as an=20 > example does not eliminate any other security mechanisms nor=20 > require that all deployment have AAA server as stateful. > >> > >> Do not you agree? > >> > >> Sincerely, If we do not have any serious objection to this=20 > text, we need to close the issue and move on. > >> Thanks. > >> > >> > >> Regards, > >> Ahmad > >> > >> > >>> -----Original Message----- > >>> From: DE JUAN HUARTE FEDERICO > >>> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > >>> Sent: Friday, September 28, 2007 4:23 AM > >>> To: Muhanna, Ahmad (RICH1:2H10) > >>> Cc: netlmm > >>> Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm]=20 > >>> Review ofdraft-ietf-netlmm-proxymip6-05) > >>> > >>> Hi Ahmad, > >>> > >>> in my understanding there's a general motivation to make=20 > AAA Servers=20 > >>> stateless, so the draft should not put such a strong "tracking" > >>> requirement It is clear to me that in some/many=20 > deployments the AAA=20 > >>> Server is not stateless anyway, so this is a minor=20 > comment But then,=20 > >>> what the AAA Server actually tracks is the NAS and not really the=20 > >>> MAG Somehow you're assuming that the AAA Server is aware of the=20 > >>> relationship between NASs and MAGs > >>> > >>> With the current text, the security solution was left for=20 > >>> deployments to choose With the new text you're trying to=20 > close the=20 > >>> solution space to one given solution Let's be fair here: > >>> - or the security solution is discussed and we do the beauty=20 > >>> contest with all of them > >>> - or the security solution is not discussed and we leave the=20 > >>> discussion for other contexts > >>> > >>> Regards > >>> > >>> federico > >>> > >>> > >>> > >>> -----Message d'origine----- > >>> De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 : > >>> vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay=20 > >>> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text Proposal=20 > >>> for Compromised MAG issue (was [netlmm] Review > >>> ofdraft-ietf-netlmm-proxymip6-05) > >>> > >>> > >>> All, > >>> > >>> I sincerely do not want to debate the use of revocation for=20 > >>> compromised MAG at the present time. I am sure that all of us are=20 > >>> interested in getting this issue addressed properly and have it=20 > >>> closed sooner than later. What about the following text: > >>> > >>> Current text under security consideration: > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> " > >>> To eliminate the threats related to a compromised mobile access > >>> gateway, this specification recommends that the local mobility=20 > >>> anchor > >>> before accepting a Proxy Binding Update message for a=20 > given mobile > >>> node, should ensure the mobile node is definitively=20 > attached to the > >>> mobile access gateway that sent the binding=20 > registration request. > >>> " > >>> > >>> New Text: > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> " > >>> To eliminate the threats related to a compromised mobile access > >>> gateway, this specification recommends that the local mobility=20 > >>> anchor > >>> before accepting a Proxy Binding Update message for a=20 > given mobile > >>> node, should ensure the mobile node is definitively=20 > attached to the > >>> mobile access gateway that sent the binding=20 > registration request > >>> by contacting a trusted entity which tracks the MN current=20 > >>> location, > >>> e.g. AAA server. > >>> " > >>> > >>> Regards, > >>> Ahmad > >>> > >>> > >>>> -----Original Message----- > >>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>>> Sent: Wednesday, September 26, 2007 7:41 PM > >>>> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli;=20 > Kilian Weniger > >>>> Cc: netlmm@ietf.org > >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>> draft-ietf-netlmm-proxymip6-05) > >>>> > >>>> Hi Ahmad, > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > >>>>> Sent: Wednesday, September 26, 2007 4:12 PM > >>>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > >>>>> Cc: netlmm@ietf.org > >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>>> draft-ietf-netlmm-proxymip6-05) > >>>>> > >>>>> Hi Vidya, > >>>>> > >>>>> Using revocation for the compromised MAG was proposed by > >>>> Kilian, et. > >>>>> al. > >>>>> but I am trying to help closing the issue so please allow > >>>> me to jump > >>>>> into this debate. > >>>>> > >>>>> In order for the LMA to validate the presence of the MN at > >>>> a specific > >>>>> MAG, the LMA needs to do one of the followings: > >>>>> > >>>>> 1. Validate the MN identity via a MN signature carried in > >>>> the P-BU. In > >>>>> P-MIPv6 this currently is not available since the P-BU is NOT=20 > >>>>> initiated by the MN. (the most obvious option) > >>>>> > >>>>> 2. Validate the MN presence via another trusted entity that > >>>>> *ALWAYS* tracks the MN current location, e.g. AAA server. > >>>>> > >>>>> 3. Validate the MN presence via another trusted entity that > >>>> tracks the > >>>>> current or latest location of the MN, e.g. the previous=20 > MAG using=20 > >>>>> binding revocation as was suggested by kilian et. al. > >>>>> > >>>> > >>>> The LMA can't assume that the pMAG is trusted while the new > >>> MAG is the > >>> > >>>> one lying. Perhaps the MN really moved and the pMAG=20 > continues to=20 > >>>> claim it is there. Regardless of which MAG tells the LMA > >>> what, 1 or 2 > >>> > >>>> needs to occur to conclude where the MN really is and=20 > then, the LMA=20 > >>>> can determine which of the MAGs was lying. > >>>> > >>>> Regards, > >>>> Vidya > >>>> > >>>>> 4. may be there are other ways... > >>>>> > >>>>> In case that the MN is still at pMAG and has not moved, the > >>>> pMAG can > >>>>> easily indicate that in the binding revocation acknowledgement. > >>>>> > >>>>> So do not you think that should work? > >>>>> > >>>>> Regards, > >>>>> Ahmad > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>>>>> Sent: Wednesday, September 26, 2007 3:49 PM > >>>>>> To: Vijay Devarapalli; Kilian Weniger > >>>>>> Cc: netlmm@ietf.org > >>>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>>>> draft-ietf-netlmm-proxymip6-05) > >>>>>> > >>>>>> > >>>>>> A few observations here. I don't believe binding revocation > >>>>> is going > >>>>>> to solve anything here. The fundamental issue is how the LMA > >>>>>> *identifies* the compromised MAG, not how the > >>> compromised MAG is > >>>>>> notified that its binding is no longer valid. Once the MAG is=20 > >>>>>> identified as compromised, a number of remedies may be taken,=20 > >>>>>> including, simply blacklisting the MAG and not accepting > >>>>> PBUs from it. > >>>>>> It is not critical that the binding be revoked, because, > >>>>> the LMA has > >>>>>> already identified where the MN really is and it just > >>>> needs to use > >>>>>> that binding for data acceptance/forwarding. > >>>>>> > >>>>>> > >>>>>> The issue of how the LMA identifies a compromised MAG=20 > cannot be=20 > >>>>>> tackled without an independent verification of the > >>>> presence of the > >>>>>> MN at that particular MAG. So, we need to focus on > >>>> providing hints > >>>>>> on how the LMA may go about > >>>>> achieving that. > >>>>>> > >>>>>> Vidya > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Vijay Devarapalli > >>> [mailto:vijay.devarapalli@AzaireNet.com] > >>>>>>> Sent: Wednesday, September 26, 2007 11:08 AM > >>>>>>> To: Kilian Weniger > >>>>>>> Cc: Narayanan, Vidya; netlmm@ietf.org > >>>>>>> Subject: Re: Compromised MAG issue (was [netlmm] Review of > >>>>>>> draft-ietf-netlmm-proxymip6-05) > >>>>>>> > >>>>>>> Kilian Weniger wrote: > >>>>>>>> Narayanan, Vidya wrote: > >>>>>>>>>>> - Security considerations: MAG Compromise: > >>>>>>>> ... > >>>>>>>>> If we claim this is an issue in the security > >>>>>>> considerations section > >>>>>>>>> and claim that the fix to it is for the LMA to ensure > >>>>> the MN is > >>>>>>>>> actually attached to the MAG, we can't quite hand > >>>> wave on some > >>>>>>>>> possible ways to do that. Those are just hints for > >>>>>>> deployments that > >>>>>>>>> are concerned about MAG compromise. But, those hints > >>>>> need to be > >>>>>>>>> captured in the security considerations section. > >>>> The threats > >>>>>>>>> document captures this threat and it is a valid one - so, > >>>>>>> I believe > >>>>>>>>> we need some text here. The type of "detail" is what > >>>>> I tried to > >>>>>>>>> provide with the examples on AAA checks or CGA > >>>>>> signatures - and, I > >>>>>>>>> don't think we need a lot of detail here; a few > >>>>>> sentences would be > >>>>>>>>> good. > >>>>>>>>> > >>>>>>>> > >>>>>>>> I had a similar comment a while ago. I think that a draft > >>>>>>> describing a > >>>>>>>> severe security issue should at least give hints how this > >>>>>>> can be solved. > >>>>>>>> > >>>>>>>> Recently Sri, Vijay, Kuntal and I had an offline > >>>>> discussion about > >>>>>>>> another possible solution to detect a compromised MAGs, > >>>>>>> which relies > >>>>>>>> on PMIP signaling only. > >>>>>>>> > >>>>>>>> The basic idea is that if two MAGs simultaneously claim > >>>>>>> that the MN is > >>>>>>>> attached, one of the MAGs must lie and is probably a > >>>>>>> compromised MAG. > >>>>>>>> The assumption is that the MN cannot at the same time be > >>>>>>> attached to > >>>>>>>> two MAGs, at least not with the same network interface. > >>>>>>>> > >>>>>>>> More specifically, when the LMA accepts a valid PBU from a > >>>>>>> new MAG, it > >>>>>>>> changes the BCE (i.e., there is no impact on handover > >>>>> delay) and > >>>>>>>> notifies the old MAG (i.e., old address in BCE) about > >>>>>> this. The old > >>>>>>>> MAG then checks whether the MN is still attached. If this > >>>>>>> is the case, > >>>>>>>> it informs the LMA about this. The LMA then learns that two > >>>>>>> different > >>>>>>>> MAGs claim MN attachement, which is not possible under the > >>>>>>> assumption > >>>>>>>> stated above. Hence, after receiving one or more such > >>>>>>> notifications, > >>>>>>>> the LMA can identify the compromised MAG and stop > >>>>>> trusting this MAG. > >>>>>>>> > >>>>>>>> A remaining problem was which message should be used to > >>>>>>> inform the old > >>>>>>>> MAG about the BCE change. PBA and revocation msg were > >>>>>>> discussed, but > >>>>>>>> the former is not sent unsolicited according to RFC3775 > >>>>>>> (which could > >>>>>>>> be overidden by PMIP spec of course) and the latter is not=20 > >>>>>>>> standardized yet. > >>>>>>> > >>>>>>> As I said in another threat, we really need to > >>> standardize the > >>>>>>> revocation message from the LMA to the old MAG ASAP. > >>>>>>> > >>>>>>> Vijay > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> netlmm mailing list > >>>>>> netlmm@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>>> > >>>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > >> > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 12:36:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIpQ-000234-AV; Fri, 28 Sep 2007 12:36:36 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbIpP-00022y-DK for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:36:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIpP-00022q-1E for netlmm@ietf.org; Fri, 28 Sep 2007 12:36:35 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbIpN-00054K-A0 for netlmm@ietf.org; Fri, 28 Sep 2007 12:36:34 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SGZjKF027203; Fri, 28 Sep 2007 18:35:45 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 18:36:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 18:36:30 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AF8@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711709DA67@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB2/vks+0kQvu4Rt+gKIeCSXJBzQABPUwAAAETAyAAAHXxQA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711709DA67@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Ahmad Muhanna" X-OriginalArrivalTime: 28 Sep 2007 16:36:30.0289 (UTC) FILETIME=[B9029410:01C801ED] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, please see inline Regards federico=20 -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Envoy=E9 : vendredi 28 septembre 2007 17:42 =C0 : DE JUAN HUARTE FEDERICO; Sri Gundavelli Cc : netlmm Objet : RE: Text Proposal for Compromised MAG issue (was [netlmm] Review = ofdraft-ietf-netlmm-proxymip6-05) > Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]=20 > Review ofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Sri, Ahmad >=20 > I was fine with the original text > If addressing the security concern is necessary because of IESG or=20 > whatever and you're going to hint at possible solutions, then I would=20 > add as an alternative that the MAG may add a per-MN signature to the=20 > PBU. [Ahmad] This also falls under the proposed text.=20 [FDJ] How does "per-MN signature added by MAG in BU" fall under the text = "by contacting a trusted entity which tracks the MN current location"? Or I didn't express myself well or I am missing something Again, AAA is given as an example nothing else. Let us forget about the = AAA server for a second. Apparently you do not have a problem with the proposed text but with = listing AAA as an example. Is that right? [FDJ] As far as I'm concerned you can list the AAA Server as an example I give more relevance to the fact that if one solution is hinted, that = we also hint the "per-MN signature" solution >=20 > The current proposed alternative: > > .... by contacting a trusted entity which tracks the MN > current location, e.g. AAA server. > it's also fine for me, except that the AAA Server is not a good=20 > example because it only tracks the NAS (not the user nor the MAG) >=20 > One final comment, if the MN can only be attached to one MAG at a=20 > given time, and if the LMA is going to validate the BU with the AAA=20 > Server and the AAA server is capable of tracking the location of the=20 > MAG ... then do we still need timestamps for message ordering? > It sems to me that the solution for a "compromised MAG"=20 > problem and for BU ordering are actually part of the same package,=20 > since solving the "compormised MAG" problem leads to the certainty of=20 > having only 1 MAG serving the user and then a SQN per MAG and per MN=20 > is sufficient (no need for context transfer) >=20 > Regards >=20 > federico >=20 >=20 > -----Message d'origine----- > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :=20 > vendredi 28 septembre 2007 16:29 =C0 : Ahmad Muhanna Cc : DE JUAN = HUARTE=20 > FEDERICO; netlmm Objet : RE: Text Proposal for Compromised MAG issue=20 > (was [netlmm] Review > ofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Federico, >=20 > We need to provide some guidance on how LMA implementations can esnure = > the presence of a MN at a given MAG in a deterministic fashion. One=20 > possible way is that the Authentication infrastructure such as AAA=20 > that generated the keys for the mobile node session would know the=20 > current point of attachment. The LMA can query the same. >=20 > These entire arguments on MAG compromise ..etc, are loosing=20 > arguments. Unfortunately, we have to agree, there may not be access=20 > authentication, but, at the same time we have to provide all the=20 > guidance on how to prevent MAG compromise. > These are all killer arguments. So, these issues just delay the work.=20 > So, lets try to find some text and put a closure to this work. By=20 > adding a reference to AAA, does not imply, we have mandatory=20 > requirement on AAA, or we are making AAA stateful. Just any=20 > reasonable guidance with/without AAA should be fine. >=20 > Sri >=20 >=20 >=20 >=20 >=20 > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: >=20 > > Hi Federico, > > > > It is very nice to know that we are getting into the beauty > context.:) > > > > Please let us focus on all of the added text: > > > > " > > .... by contacting a trusted entity which tracks the MN > current location, e.g. AAA server. > > " > > > > If AAA server is not stateful, then deployment may use > another trusted entity and that is granted by the above text. > > Originally I am in favor of leaving the whole thing > out-of-scope all together, but listing AAA server as an example does=20 > not eliminate any other security mechanisms nor require that all=20 > deployment have AAA server as stateful. > > > > Do not you agree? > > > > Sincerely, If we do not have any serious objection to this > text, we need to close the issue and move on. > > Thanks. > > > > > > Regards, > > Ahmad > > > > > >> -----Original Message----- > >> From: DE JUAN HUARTE FEDERICO > >> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > >> Sent: Friday, September 28, 2007 4:23 AM > >> To: Muhanna, Ahmad (RICH1:2H10) > >> Cc: netlmm > >> Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]=20 > >> Review ofdraft-ietf-netlmm-proxymip6-05) > >> > >> Hi Ahmad, > >> > >> in my understanding there's a general motivation to make > AAA Servers > >> stateless, so the draft should not put such a strong "tracking" > >> requirement It is clear to me that in some/many > deployments the AAA > >> Server is not stateless anyway, so this is a minor comment > But then, > >> what the AAA Server actually tracks is the NAS and not > really the MAG > >> Somehow you're assuming that the AAA Server is aware of the=20 > >> relationship between NASs and MAGs > >> > >> With the current text, the security solution was left for > deployments > >> to choose With the new text you're trying to close the > solution space > >> to one given solution Let's be fair here: > >> - or the security solution is discussed and we do the beauty=20 > >> contest with all of them > >> - or the security solution is not discussed and we leave the=20 > >> discussion for other contexts > >> > >> Regards > >> > >> federico > >> > >> > >> > >> -----Message d'origine----- > >> De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 : > >> vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay=20 > >> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text > Proposal for > >> Compromised MAG issue (was [netlmm] Review > >> ofdraft-ietf-netlmm-proxymip6-05) > >> > >> > >> All, > >> > >> I sincerely do not want to debate the use of revocation for=20 > >> compromised MAG at the present time. I am sure that all of us are=20 > >> interested in getting this issue addressed properly and have it=20 > >> closed sooner than later. What about the following text: > >> > >> Current text under security consideration: > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> " > >> To eliminate the threats related to a compromised mobile access > >> gateway, this specification recommends that the local mobility=20 > >> anchor > >> before accepting a Proxy Binding Update message for a > given mobile > >> node, should ensure the mobile node is definitively > attached to the > >> mobile access gateway that sent the binding > registration request. > >> " > >> > >> New Text: > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> " > >> To eliminate the threats related to a compromised mobile access > >> gateway, this specification recommends that the local mobility=20 > >> anchor > >> before accepting a Proxy Binding Update message for a > given mobile > >> node, should ensure the mobile node is definitively > attached to the > >> mobile access gateway that sent the binding registration request > >> by contacting a trusted entity which tracks the MN current=20 > >> location, > >> e.g. AAA server. > >> " > >> > >> Regards, > >> Ahmad > >> > >> > >>> -----Original Message----- > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>> Sent: Wednesday, September 26, 2007 7:41 PM > >>> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Kilian Weniger > >>> Cc: netlmm@ietf.org > >>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>> draft-ietf-netlmm-proxymip6-05) > >>> > >>> Hi Ahmad, > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > >>>> Sent: Wednesday, September 26, 2007 4:12 PM > >>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > >>>> Cc: netlmm@ietf.org > >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>> draft-ietf-netlmm-proxymip6-05) > >>>> > >>>> Hi Vidya, > >>>> > >>>> Using revocation for the compromised MAG was proposed by > >>> Kilian, et. > >>>> al. > >>>> but I am trying to help closing the issue so please allow > >>> me to jump > >>>> into this debate. > >>>> > >>>> In order for the LMA to validate the presence of the MN at > >>> a specific > >>>> MAG, the LMA needs to do one of the followings: > >>>> > >>>> 1. Validate the MN identity via a MN signature carried in > >>> the P-BU. In > >>>> P-MIPv6 this currently is not available since the P-BU is NOT=20 > >>>> initiated by the MN. (the most obvious option) > >>>> > >>>> 2. Validate the MN presence via another trusted entity that > >>>> *ALWAYS* tracks the MN current location, e.g. AAA server. > >>>> > >>>> 3. Validate the MN presence via another trusted entity that > >>> tracks the > >>>> current or latest location of the MN, e.g. the previous > MAG using > >>>> binding revocation as was suggested by kilian et. al. > >>>> > >>> > >>> The LMA can't assume that the pMAG is trusted while the new > >> MAG is the > >> > >>> one lying. Perhaps the MN really moved and the pMAG continues to=20 > >>> claim it is there. Regardless of which MAG tells the LMA > >> what, 1 or 2 > >> > >>> needs to occur to conclude where the MN really is and > then, the LMA > >>> can determine which of the MAGs was lying. > >>> > >>> Regards, > >>> Vidya > >>> > >>>> 4. may be there are other ways... > >>>> > >>>> In case that the MN is still at pMAG and has not moved, the > >>> pMAG can > >>>> easily indicate that in the binding revocation acknowledgement. > >>>> > >>>> So do not you think that should work? > >>>> > >>>> Regards, > >>>> Ahmad > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>>>> Sent: Wednesday, September 26, 2007 3:49 PM > >>>>> To: Vijay Devarapalli; Kilian Weniger > >>>>> Cc: netlmm@ietf.org > >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>>> draft-ietf-netlmm-proxymip6-05) > >>>>> > >>>>> > >>>>> A few observations here. I don't believe binding revocation > >>>> is going > >>>>> to solve anything here. The fundamental issue is how the LMA > >>>>> *identifies* the compromised MAG, not how the > >> compromised MAG is > >>>>> notified that its binding is no longer valid. Once the MAG is=20 > >>>>> identified as compromised, a number of remedies may be taken,=20 > >>>>> including, simply blacklisting the MAG and not accepting > >>>> PBUs from it. > >>>>> It is not critical that the binding be revoked, because, > >>>> the LMA has > >>>>> already identified where the MN really is and it just > >>> needs to use > >>>>> that binding for data acceptance/forwarding. > >>>>> > >>>>> > >>>>> The issue of how the LMA identifies a compromised MAG cannot be=20 > >>>>> tackled without an independent verification of the > >>> presence of the > >>>>> MN at that particular MAG. So, we need to focus on > >>> providing hints > >>>>> on how the LMA may go about > >>>> achieving that. > >>>>> > >>>>> Vidya > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Vijay Devarapalli > >> [mailto:vijay.devarapalli@AzaireNet.com] > >>>>>> Sent: Wednesday, September 26, 2007 11:08 AM > >>>>>> To: Kilian Weniger > >>>>>> Cc: Narayanan, Vidya; netlmm@ietf.org > >>>>>> Subject: Re: Compromised MAG issue (was [netlmm] Review of > >>>>>> draft-ietf-netlmm-proxymip6-05) > >>>>>> > >>>>>> Kilian Weniger wrote: > >>>>>>> Narayanan, Vidya wrote: > >>>>>>>>>> - Security considerations: MAG Compromise: > >>>>>>> ... > >>>>>>>> If we claim this is an issue in the security > >>>>>> considerations section > >>>>>>>> and claim that the fix to it is for the LMA to ensure > >>>> the MN is > >>>>>>>> actually attached to the MAG, we can't quite hand > >>> wave on some > >>>>>>>> possible ways to do that. Those are just hints for > >>>>>> deployments that > >>>>>>>> are concerned about MAG compromise. But, those hints > >>>> need to be > >>>>>>>> captured in the security considerations section. > >>> The threats > >>>>>>>> document captures this threat and it is a valid one - so, > >>>>>> I believe > >>>>>>>> we need some text here. The type of "detail" is what > >>>> I tried to > >>>>>>>> provide with the examples on AAA checks or CGA > >>>>> signatures - and, I > >>>>>>>> don't think we need a lot of detail here; a few > >>>>> sentences would be > >>>>>>>> good. > >>>>>>>> > >>>>>>> > >>>>>>> I had a similar comment a while ago. I think that a draft > >>>>>> describing a > >>>>>>> severe security issue should at least give hints how this > >>>>>> can be solved. > >>>>>>> > >>>>>>> Recently Sri, Vijay, Kuntal and I had an offline > >>>> discussion about > >>>>>>> another possible solution to detect a compromised MAGs, > >>>>>> which relies > >>>>>>> on PMIP signaling only. > >>>>>>> > >>>>>>> The basic idea is that if two MAGs simultaneously claim > >>>>>> that the MN is > >>>>>>> attached, one of the MAGs must lie and is probably a > >>>>>> compromised MAG. > >>>>>>> The assumption is that the MN cannot at the same time be > >>>>>> attached to > >>>>>>> two MAGs, at least not with the same network interface. > >>>>>>> > >>>>>>> More specifically, when the LMA accepts a valid PBU from a > >>>>>> new MAG, it > >>>>>>> changes the BCE (i.e., there is no impact on handover > >>>> delay) and > >>>>>>> notifies the old MAG (i.e., old address in BCE) about > >>>>> this. The old > >>>>>>> MAG then checks whether the MN is still attached. If this > >>>>>> is the case, > >>>>>>> it informs the LMA about this. The LMA then learns that two > >>>>>> different > >>>>>>> MAGs claim MN attachement, which is not possible under the > >>>>>> assumption > >>>>>>> stated above. Hence, after receiving one or more such > >>>>>> notifications, > >>>>>>> the LMA can identify the compromised MAG and stop > >>>>> trusting this MAG. > >>>>>>> > >>>>>>> A remaining problem was which message should be used to > >>>>>> inform the old > >>>>>>> MAG about the BCE change. PBA and revocation msg were > >>>>>> discussed, but > >>>>>>> the former is not sent unsolicited according to RFC3775 > >>>>>> (which could > >>>>>>> be overidden by PMIP spec of course) and the latter is not=20 > >>>>>>> standardized yet. > >>>>>> > >>>>>> As I said in another threat, we really need to > >> standardize the > >>>>>> revocation message from the LMA to the old MAG ASAP. > >>>>>> > >>>>>> Vijay > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>> > >>>> > >>> > >> > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 12:36:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIpT-00028Q-Mp; Fri, 28 Sep 2007 12:36:39 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbIpS-00028D-3t for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIpR-00025k-IP for netlmm@ietf.org; Fri, 28 Sep 2007 12:36:37 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbIpL-0006Hu-6r for netlmm@ietf.org; Fri, 28 Sep 2007 12:36:37 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l8SGZjKD027203; Fri, 28 Sep 2007 18:35:45 +0200 Received: from FRVELSMBS12.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 28 Sep 2007 18:36:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Fri, 28 Sep 2007 18:36:22 +0200 Message-ID: <319D54578EAC3147BA8CC78DAB5467A501399AF7@FRVELSMBS12.ad2.ad.alcatel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116FA9BCC@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/T/RrZEqQFEePT3u9QfI2QIenQAAcXPfQAAcW7+AAGYjB4ABpOoZg References: <6FC4416DDE56C44DA0AEE67BC7CA437116F669B2@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FA9BCC@zrc2hxm2.corp.nortel.com> From: "DE JUAN HUARTE FEDERICO" To: "Ahmad Muhanna" X-OriginalArrivalTime: 28 Sep 2007 16:36:30.0071 (UTC) FILETIME=[B8E15070:01C801ED] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, catching up with this week emails ... In the use case of SQNs, I presume that it is the SQN itself that would = be used for matching PBU<=3D>PBA Having both the SQN and the NAI in the PBA seems to me redundant Then, the LMA doesn't need to add the NAI in any PBA Regards federico -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Envoy=E9 : mercredi 26 septembre 2007 15:59 =C0 : Narayanan, Vidya; netlmm@ietf.org Objet : RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Hi Vidya, Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Tuesday, September 25, 2007 8:38 PM > To: Muhanna, Ahmad (RICH1:2H10); netlmm@ietf.org > Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 >=20 > Hi Ahmad, >=20 > > > - NAI option in the PBA:=20 > > >=20 > > > Why is it needed? > >=20 > > [Ahmad] > > There is a very good reason to have NAI in the P-BA. > >=20 > > In case that we have SQN used for ordering the P-BU/P-BA, > there is a > > great possibility of SQN collision. In this case, MAG needs > the NAI to > > match the P-BA to the outstanding P-BU. > >=20 >=20 > Hmmm.. In this case, I can see the use in including the MN ID in the=20 > first PBA, but, subsequently, the HNP should be sufficient to match it = > to the MN in the PBU and PBA, right? [Ahmad] Technically; Yes I agree. However, this message is not transmitted over the air, Are we concerned = about the size of the message here? I guess including NAI in the initial P-BU and not in re-registration = P-BU adds some complexity to the MAG and probably a lot to the LMA. If = there is no real concern about including the NAI, I would recommend = keeping it unless there a serious advantage in making such = recommendation. >=20 > Vidya >=20 > > Regards, > > Ahmad > >=20 > > >=20 > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 12:40:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIsp-0005Ix-PS; Fri, 28 Sep 2007 12:40:07 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbIsn-0005Ii-Lu for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIsn-0005He-B7 for netlmm@ietf.org; Fri, 28 Sep 2007 12:40:05 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbIsh-0006MX-QP for netlmm@ietf.org; Fri, 28 Sep 2007 12:40:05 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8SGcrc8010312; Fri, 28 Sep 2007 19:39:34 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 19:39:10 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 11:39:00 -0500 Received: from 172.19.244.136 ([172.19.244.136]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 28 Sep 2007 16:39:00 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 28 Sep 2007 11:39:06 -0500 Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs From: Basavaraj Patil To: ext Genadi Velev , Sri Gundavelli Message-ID: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgB2hUdvbTtGdHSTqmQpprklkoYOwAC8wCAAAINLVc= In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB4F8EE7@lan-ex-02.panasonic.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Sep 2007 16:39:00.0327 (UTC) FILETIME=[12708F70:01C801EE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org I don't know if we have really converged ;) Two questions: 1. How can you prevent a device from attaching via multiple interfaces simultaneously? Are you suggesting that within the scope of a PMIP6 domain, you could potentially verify (at AAA level or some such thing) if an MN is already attached via another interface and hence prevent it from attaching via the second interface? 2. How do you ensure that variable MN-IDs are used depending on the interface used by the host to attach to a network? An MN which attaches via different interfaces simultaneously to a PMIP6 domain will result in the LMA having a BCE for the last received PBU. Host behavior when multiple interfaces have the same address is unspecified and we can just leave it at that. In the context of this document, we do not need to solve it. -Raj On 9/28/07 10:59 AM, "ext Genadi Velev" wrote: > Hi Sri, > > it seems that we converge on this issue :-) > > I was also agnostic on any of the initial options 1-4. Of course the > simplest way to go forward is to describe options 1 and 2. The operator > can choose between not allowing multiple interfaces to be simultaneously > attached (option 1) or to support multiple interfaces to be attached but > assuring that different MN-ID is assigned to each interface. > > Option 3 still needs to be worked out in > draft-muhanna-mip6-binding-revocation-01, as discussed by Kilian and > Vijay. So, we can leave it out for the base PMIP specification. > > Genadi > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Friday, September 28, 2007 4:15 PM >> To: Genadi Velev >> Cc: Narayanan, Vidya; ext Kilian Weniger; netlmm@ietf.org >> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >> >> Hi Genadi, >> >> Please see inline. >> >> >> On Fri, 28 Sep 2007, Genadi Velev wrote: >> >> >>> I can think about several approaches to overcome this issue: >>> 1) we can specify that the network operator shall take care of >>> preventing that a MN attaches with 2 interfaces to a PMIP domain (at >>> least to the same LMA). For example, the operator doesn't allow >>> attachment (i.e. authorization) of interface 2, since interface 1 is >>> still attached. >> >> >>> 2) we can write a short text in the draft that the network operator >>> shall take care about assignment of different MN-ID (NAI) >> to different >>> interfaces during attachment procedure. >> >>> 3) we can describe how the current protocol behaves when a >> MN attempts >>> to attach with two interfaces. Similar to what is explained >> in Vijay's >>> email: >>> http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html >> >> I'm ok with any of the above three options. We can certainly document >> the scenario and close the issue. I do no think, we should try to >> solve this problem here or use this issue to explicitly add text to >> block the inter-access handoff, we did not do any thing to >> support that >> scenario. When the charter says, its out of scope, we dont >> need to solve >> all the issues, when the scenario is enabled. Operators can solve this >> issue, these are managed deployments. Its not a like a >> consumer buying a >> device and turning it on at home. So, I agree with your above three >> suggested options. >> >> Regards >> Sri >> >> >> >> > > > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke > > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 12:42:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIuv-0006Lq-3v; Fri, 28 Sep 2007 12:42:17 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbIut-0006Le-G0 for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:42:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIut-0006I8-0Y for netlmm@ietf.org; Fri, 28 Sep 2007 12:42:15 -0400 Received: from web84105.mail.mud.yahoo.com ([68.142.206.192]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbIup-0005AV-Kl for netlmm@ietf.org; Fri, 28 Sep 2007 12:42:14 -0400 Received: (qmail 58759 invoked by uid 60001); 28 Sep 2007 16:42:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=sKbSlFfiFgN4MBuDaDniYcwP2z+gjdPJNMYoRxXhNNLffvHp7rL0JDWPEMFq8LgaBNyR3MlwvHDz3eIOeqgv3rsYgTw55tKXDK6MrU7wqAatDpp5Sgoxk0I2QHhB4K+3VubC2oB9nl+H1RlAVrnKWaGHhH3PewVgXZGl4eqtH0I=; X-YMail-OSG: M6P149UVM1lJukVh1q5LhxvH6M90cjkN7CgbxCzNy7jB1PFG_TG7bSjOTbeL9JGsEV.dOyVRH4EGU8hCPd4S6eeSofvbbIiLUhKqmu_fxIyIwBk- Received: from [206.16.17.212] by web84105.mail.mud.yahoo.com via HTTP; Fri, 28 Sep 2007 09:42:10 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Fri, 28 Sep 2007 09:42:10 -0700 (PDT) From: Behcet Sarikaya Subject: Re: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) To: Ahmad Muhanna MIME-Version: 1.0 Message-ID: <35640.58334.qm@web84105.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0780602271==" Errors-To: netlmm-bounces@ietf.org --===============0780602271== Content-Type: multipart/alternative; boundary="0-956562916-1190997730=:58334" --0-956562916-1190997730=:58334 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ahmad and all,=0A I saw postings in the list saying let's move on which co= ntradicts with statements suggesting creation of another thread .=0A Shoul= d we move on or keep spawning new threads?=0A=0A=0ARegards,=0A=0ABehcet=0A= =0A----- Original Message ----=0AFrom: Ahmad Muhanna = =0ATo: Wassim Haddad ; DE JUAN HUARTE FEDERICO =0ACc: netlmm =0ASent: = Friday, September 28, 2007 11:31:17 AM=0ASubject: RE: Text Proposal for Com= promised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)= =0A=0AHi Wassim,=0A=0APlease see comment below.=0A=0ARegards,=0AAhmad=0A=0A= > Subject: RE: Text Proposal for Compromised MAG issue (was =0A> [netlmm] R= eview ofdraft-ietf-netlmm-proxymip6-05)=0A> =0A> On Fri, 28 Sep 2007, DE JU= AN HUARTE FEDERICO wrote:=0A> =0A> > One final comment, if the MN can only = be attached to one MAG at a =0A> > given time, and if the LMA is going to v= alidate the BU with the AAA =0A> > Server and the AAA server is capable of = tracking the =0A> location of the MAG ... then do we still need timestamps = for =0A> message ordering?=0A> =0A> =3D> It is not only this feature which = may be questionable.=0A =0A[Ahmad]=0AMay be you can help us understand how = this feature is questionable with the proposed text hint?=0A=0A> In =0A> fa= ct, what Ahmad is proposing about AAA (which btw is =0A> interesting) can s= ignificantly enhance the protocol in many ways:=0A> If the AAA is able to t= ell the LMA where the MN is located =0A> (i.e., the MAG),=0A =0A[Ahmad]=0AS= o, can I read this that you think it is impossible and does not make sense?= =0A=0A=0A> then you can simply let the LMA updates the =0A> MAG (instead of= the opposite) =0A=0A[Ahmad]=0AI am not experienced with those reverse logi= c mechanisms but I am willing to listen to your theory in a separate thread= !=0A=0A> and also let the LMA sends to =0A> the MAG a temporary key to prov= ide all SeND features without =0A> the need for CGA. So basically, you can = address the MAG =0A> compromise problem together with the CGA problem...=0A= =0A[Ahmad]=0AJust FYI: =0A1. A detailed solution for the so called compromi= sed MAG is out-of-scope.=0A2. The text hint including the AAA has been prop= osed several times before on the ml by different people.=0AFinally, if you = have a different text to propose (with the above 1 & 2 in mind) that would = be great!=0A=0A> =0A> =0A> Regards,=0A> =0A> Wassim H.=0A> =0A> =0A> =0A> >= -----Message d'origine-----=0A> > De : Sri Gundavelli [mailto:sgundave@cis= co.com] Envoy=E9 : =0A> vendredi 28 =0A> > septembre 2007 16:29 =C0 : Ahmad= Muhanna Cc : DE JUAN HUARTE =0A> FEDERICO; =0A> > netlmm Objet : RE: Text = Proposal for Compromised MAG issue (was =0A> > [netlmm] Review ofdraft-ietf= -netlmm-proxymip6-05)=0A> >=0A> > Hi Federico,=0A> >=0A> > We need to provi= de some guidance on how LMA implementations =0A> can esnure the presence of= a MN at a given MAG in a =0A> deterministic fashion. One possible way is t= hat the =0A> Authentication infrastructure such as AAA that generated the = =0A> keys for the mobile node session would know the current point =0A> of = attachment. The LMA can query the same.=0A> >=0A> > These entire argu= ments on MAG compromise ..etc, are =0A> loosing arguments. Unfortunately, w= e have to agree, there may =0A> not be access authentication, but, at the s= ame time we have =0A> to provide all the guidance on how to prevent MAG com= promise. =0A> These are all killer arguments. So, these issues just delay = =0A> the work. So, lets try to find some text and put a closure to =0A> thi= s work. By adding a reference to AAA, does not imply, we =0A> have mandator= y requirement on AAA, or we are making AAA =0A> stateful. Just any reasona= ble guidance with/without AAA =0A> should be fine.=0A> >=0A> > Sri=0A> >=0A= > >=0A> >=0A> >=0A> >=0A> > On Fri, 28 Sep 2007, Ahmad Muhanna wrote:=0A> >= =0A> >> Hi Federico,=0A> >>=0A> >> It is very nice to know that we are gett= ing into the beauty =0A> >> context.:)=0A> >>=0A> >> Please let us focus on= all of the added text:=0A> >>=0A> >> "=0A> >> .... by contacting a trusted= entity which tracks the MN =0A> current location, e.g. AAA server.=0A> >> = "=0A> >>=0A> >> If AAA server is not stateful, then deployment may use =0A>= another trusted entity and that is granted by the above text.=0A> >> Origi= nally I am in favor of leaving the whole thing =0A> out-of-scope all togeth= er, but listing AAA server as an =0A> example does not eliminate any other = security mechanisms nor =0A> require that all deployment have AAA server as= stateful.=0A> >>=0A> >> Do not you agree?=0A> >>=0A> >> Sincerely, If we d= o not have any serious objection to this =0A> text, we need to close the is= sue and move on.=0A> >> Thanks.=0A> >>=0A> >>=0A> >> Regards,=0A> >> Ahmad= =0A> >>=0A> >>=0A> >>> -----Original Message-----=0A> >>> From: DE JUAN HUA= RTE FEDERICO=0A> >>> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=0A>= >>> Sent: Friday, September 28, 2007 4:23 AM=0A> >>> To: Muhanna, Ahmad (R= ICH1:2H10)=0A> >>> Cc: netlmm=0A> >>> Subject: RE: Text Proposal for Compro= mised MAG issue (was =0A> [netlmm] =0A> >>> Review ofdraft-ietf-netlmm-prox= ymip6-05)=0A> >>>=0A> >>> Hi Ahmad,=0A> >>>=0A> >>> in my understanding the= re's a general motivation to make =0A> AAA Servers =0A> >>> stateless, so t= he draft should not put such a strong "tracking"=0A> >>> requirement It is = clear to me that in some/many =0A> deployments the AAA =0A> >>> Server is n= ot stateless anyway, so this is a minor =0A> comment But then, =0A> >>> wha= t the AAA Server actually tracks is the NAS and not really the =0A> >>> MAG= Somehow you're assuming that the AAA Server is aware of the =0A> >>> relat= ionship between NASs and MAGs=0A> >>>=0A> >>> With the current text, the se= curity solution was left for =0A> >>> deployments to choose With the new te= xt you're trying to =0A> close the =0A> >>> solution space to one given sol= ution Let's be fair here:=0A> >>> - or the security solution is discusse= d and we do the beauty =0A> >>> contest with all of them=0A> >>> - or th= e security solution is not discussed and we leave the =0A> >>> discussion f= or other contexts=0A> >>>=0A> >>> Regards=0A> >>>=0A> >>> federico=0A> >>>= =0A> >>>=0A> >>>=0A> >>> -----Message d'origine-----=0A> >>> De : Ahmad Muh= anna [mailto:amuhanna@nortel.com] Envoy=E9 :=0A> >>> vendredi 28 septembre = 2007 07:37 =C0 : Narayanan, Vidya; Vijay =0A> >>> Devarapalli; Kilian Wenig= er Cc : netlmm Objet : RE: Text Proposal =0A> >>> for Compromised MAG issue= (was [netlmm] Review=0A> >>> ofdraft-ietf-netlmm-proxymip6-05)=0A> >>>=0A>= >>>=0A> >>> All,=0A> >>>=0A> >>> I sincerely do not want to debate the use= of revocation for =0A> >>> compromised MAG at the present time. I am sure = that all of us are =0A> >>> interested in getting this issue addressed prop= erly and have it =0A> >>> closed sooner than later. What about the followin= g text:=0A> >>>=0A> >>> Current text under security consideration:=0A> >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> >>> "=0A> >>> To= eliminate the threats related to a compromised mobile access=0A> >>> ga= teway, this specification recommends that the local mobility =0A> >>> ancho= r=0A> >>> before accepting a Proxy Binding Update message for a =0A> giv= en mobile=0A> >>> node, should ensure the mobile node is definitively = =0A> attached to the=0A> >>> mobile access gateway that sent the binding= =0A> registration request.=0A> >>> "=0A> >>>=0A> >>> New Text:=0A> >>> =3D= =3D=3D=3D=3D=3D=3D=3D=3D=0A> >>>=0A> >>> "=0A> >>> To eliminate the thre= ats related to a compromised mobile access=0A> >>> gateway, this specifi= cation recommends that the local mobility =0A> >>> anchor=0A> >>> before= accepting a Proxy Binding Update message for a =0A> given mobile=0A> >>> = node, should ensure the mobile node is definitively =0A> attached to the= =0A> >>> mobile access gateway that sent the binding =0A> registration r= equest=0A> >>> by contacting a trusted entity which tracks the MN curren= t =0A> >>> location,=0A> >>> e.g. AAA server.=0A> >>> "=0A> >>>=0A> >>> = Regards,=0A> >>> Ahmad=0A> >>>=0A> >>>=0A> >>>> -----Original Message-----= =0A> >>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=0A> >>>> Sent= : Wednesday, September 26, 2007 7:41 PM=0A> >>>> To: Muhanna, Ahmad (RICH1:= 2H10); Vijay Devarapalli; =0A> Kilian Weniger=0A> >>>> Cc: netlmm@ietf.org= =0A> >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of=0A> >>= >> draft-ietf-netlmm-proxymip6-05)=0A> >>>>=0A> >>>> Hi Ahmad,=0A> >>>>=0A>= >>>>=0A> >>>>> -----Original Message-----=0A> >>>>> From: Ahmad Muhanna [m= ailto:amuhanna@nortel.com]=0A> >>>>> Sent: Wednesday, September 26, 2007 4:= 12 PM=0A> >>>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger=0A>= >>>>> Cc: netlmm@ietf.org=0A> >>>>> Subject: RE: Compromised MAG issue (wa= s [netlmm] Review of=0A> >>>>> draft-ietf-netlmm-proxymip6-05)=0A> >>>>>=0A= > >>>>> Hi Vidya,=0A> >>>>>=0A> >>>>> Using revocation for the compromised = MAG was proposed by=0A> >>>> Kilian, et.=0A> >>>>> al.=0A> >>>>> but I am t= rying to help closing the issue so please allow=0A> >>>> me to jump=0A> >>>= >> into this debate.=0A> >>>>>=0A> >>>>> In order for the LMA to validate t= he presence of the MN at=0A> >>>> a specific=0A> >>>>> MAG, the LMA needs t= o do one of the followings:=0A> >>>>>=0A> >>>>> 1. Validate the MN identity= via a MN signature carried in=0A> >>>> the P-BU. In=0A> >>>>> P-MIPv6 this= currently is not available since the P-BU is NOT =0A> >>>>> initiated by t= he MN. (the most obvious option)=0A> >>>>>=0A> >>>>> 2. Validate the MN pre= sence via another trusted entity that=0A> >>>>> *ALWAYS* tracks the MN curr= ent location, e.g. AAA server.=0A> >>>>>=0A> >>>>> 3. Validate the MN prese= nce via another trusted entity that=0A> >>>> tracks the=0A> >>>>> current o= r latest location of the MN, e.g. the previous =0A> MAG using =0A> >>>>> bi= nding revocation as was suggested by kilian et. al.=0A> >>>>>=0A> >>>>=0A> = >>>> The LMA can't assume that the pMAG is trusted while the new=0A> >>> MA= G is the=0A> >>>=0A> >>>> one lying. Perhaps the MN really moved and the p= MAG =0A> continues to =0A> >>>> claim it is there. Regardless of which MAG= tells the LMA=0A> >>> what, 1 or 2=0A> >>>=0A> >>>> needs to occur to conc= lude where the MN really is and =0A> then, the LMA =0A> >>>> can determine = which of the MAGs was lying.=0A> >>>>=0A> >>>> Regards,=0A> >>>> Vidya=0A> = >>>>=0A> >>>>> 4. may be there are other ways...=0A> >>>>>=0A> >>>>> In cas= e that the MN is still at pMAG and has not moved, the=0A> >>>> pMAG can=0A>= >>>>> easily indicate that in the binding revocation acknowledgement.=0A> = >>>>>=0A> >>>>> So do not you think that should work?=0A> >>>>>=0A> >>>>> R= egards,=0A> >>>>> Ahmad=0A> >>>>>=0A> >>>>>=0A> >>>>>> -----Original Messag= e-----=0A> >>>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=0A> >= >>>>> Sent: Wednesday, September 26, 2007 3:49 PM=0A> >>>>>> To: Vijay Deva= rapalli; Kilian Weniger=0A> >>>>>> Cc: netlmm@ietf.org=0A> >>>>>> Subject: = RE: Compromised MAG issue (was [netlmm] Review of=0A> >>>>>> draft-ietf-net= lmm-proxymip6-05)=0A> >>>>>>=0A> >>>>>>=0A> >>>>>> A few observations here.= I don't believe binding revocation=0A> >>>>> is going=0A> >>>>>> to solve = anything here. The fundamental issue is how the LMA=0A> >>>>>> *identifies= * the compromised MAG, not how the=0A> >>> compromised MAG is=0A> >>>>>> no= tified that its binding is no longer valid. Once the MAG is =0A> >>>>>> id= entified as compromised, a number of remedies may be taken, =0A> >>>>>> inc= luding, simply blacklisting the MAG and not accepting=0A> >>>>> PBUs from i= t.=0A> >>>>>> It is not critical that the binding be revoked, because,=0A> = >>>>> the LMA has=0A> >>>>>> already identified where the MN really is and = it just=0A> >>>> needs to use=0A> >>>>>> that binding for data acceptance/f= orwarding.=0A> >>>>>>=0A> >>>>>>=0A> >>>>>> The issue of how the LMA identi= fies a compromised MAG =0A> cannot be =0A> >>>>>> tackled without an indepe= ndent verification of the=0A> >>>> presence of the=0A> >>>>>> MN at that pa= rticular MAG. So, we need to focus on=0A> >>>> providing hints=0A> >>>>>> = on how the LMA may go about=0A> >>>>> achieving that.=0A> >>>>>>=0A> >>>>>>= Vidya=0A> >>>>>>=0A> >>>>>>> -----Original Message-----=0A> >>>>>>> From: = Vijay Devarapalli=0A> >>> [mailto:vijay.devarapalli@AzaireNet.com]=0A> >>>>= >>> Sent: Wednesday, September 26, 2007 11:08 AM=0A> >>>>>>> To: Kilian Wen= iger=0A> >>>>>>> Cc: Narayanan, Vidya; netlmm@ietf.org=0A> >>>>>>> Subject:= Re: Compromised MAG issue (was [netlmm] Review of=0A> >>>>>>> draft-ietf-n= etlmm-proxymip6-05)=0A> >>>>>>>=0A> >>>>>>> Kilian Weniger wrote:=0A> >>>>>= >>> Narayanan, Vidya wrote:=0A> >>>>>>>>>>> - Security considerations: MAG = Compromise:=0A> >>>>>>>> ...=0A> >>>>>>>>> If we claim this is an issue in = the security=0A> >>>>>>> considerations section=0A> >>>>>>>>> and claim tha= t the fix to it is for the LMA to ensure=0A> >>>>> the MN is=0A> >>>>>>>>> = actually attached to the MAG, we can't quite hand=0A> >>>> wave on some=0A>= >>>>>>>>> possible ways to do that. Those are just hints for=0A> >>>>>>> = deployments that=0A> >>>>>>>>> are concerned about MAG compromise. But, th= ose hints=0A> >>>>> need to be=0A> >>>>>>>>> captured in the security consi= derations section.=0A> >>>> The threats=0A> >>>>>>>>> document captures thi= s threat and it is a valid one - so,=0A> >>>>>>> I believe=0A> >>>>>>>>> we= need some text here. The type of "detail" is what=0A> >>>>> I tried to=0A= > >>>>>>>>> provide with the examples on AAA checks or CGA=0A> >>>>>> signa= tures - and, I=0A> >>>>>>>>> don't think we need a lot of detail here; a fe= w=0A> >>>>>> sentences would be=0A> >>>>>>>>> good.=0A> >>>>>>>>>=0A> >>>>>= >>>=0A> >>>>>>>> I had a similar comment a while ago. I think that a draft= =0A> >>>>>>> describing a=0A> >>>>>>>> severe security issue should at leas= t give hints how this=0A> >>>>>>> can be solved.=0A> >>>>>>>>=0A> >>>>>>>> = Recently Sri, Vijay, Kuntal and I had an offline=0A> >>>>> discussion about= =0A> >>>>>>>> another possible solution to detect a compromised MAGs,=0A> >= >>>>>> which relies=0A> >>>>>>>> on PMIP signaling only.=0A> >>>>>>>>=0A> >= >>>>>>> The basic idea is that if two MAGs simultaneously claim=0A> >>>>>>>= that the MN is=0A> >>>>>>>> attached, one of the MAGs must lie and is prob= ably a=0A> >>>>>>> compromised MAG.=0A> >>>>>>>> The assumption is that the= MN cannot at the same time be=0A> >>>>>>> attached to=0A> >>>>>>>> two MAG= s, at least not with the same network interface.=0A> >>>>>>>>=0A> >>>>>>>> = More specifically, when the LMA accepts a valid PBU from a=0A> >>>>>>> new = MAG, it=0A> >>>>>>>> changes the BCE (i.e., there is no impact on handover= =0A> >>>>> delay) and=0A> >>>>>>>> notifies the old MAG (i.e., old address = in BCE) about=0A> >>>>>> this. The old=0A> >>>>>>>> MAG then checks whether= the MN is still attached. If this=0A> >>>>>>> is the case,=0A> >>>>>>>> it= informs the LMA about this. The LMA then learns that two=0A> >>>>>>> diffe= rent=0A> >>>>>>>> MAGs claim MN attachement, which is not possible under th= e=0A> >>>>>>> assumption=0A> >>>>>>>> stated above. Hence, after receiving = one or more such=0A> >>>>>>> notifications,=0A> >>>>>>>> the LMA can identi= fy the compromised MAG and stop=0A> >>>>>> trusting this MAG.=0A> >>>>>>>>= =0A> >>>>>>>> A remaining problem was which message should be used to=0A> >= >>>>>> inform the old=0A> >>>>>>>> MAG about the BCE change. PBA and revoca= tion msg were=0A> >>>>>>> discussed, but=0A> >>>>>>>> the former is not sen= t unsolicited according to RFC3775=0A> >>>>>>> (which could=0A> >>>>>>>> be= overidden by PMIP spec of course) and the latter is not =0A> >>>>>>>> stan= dardized yet.=0A> >>>>>>>=0A> >>>>>>> As I said in another threat, we reall= y need to=0A> >>> standardize the=0A> >>>>>>> revocation message from the L= MA to the old MAG ASAP.=0A> >>>>>>>=0A> >>>>>>> Vijay=0A> >>>>>>>=0A> >>>>>= >=0A> >>>>>> _______________________________________________=0A> >>>>>> net= lmm mailing list=0A> >>>>>> netlmm@ietf.org=0A> >>>>>> https://www1.ietf.or= g/mailman/listinfo/netlmm=0A> >>>>>>=0A> >>>>>=0A> >>>>=0A> >>>=0A> >>>=0A>= >>> _______________________________________________=0A> >>> netlmm mailing= list=0A> >>> netlmm@ietf.org=0A> >>> https://www1.ietf.org/mailman/listinf= o/netlmm=0A> >>>=0A> >>=0A> >>=0A> >> _____________________________________= __________=0A> >> netlmm mailing list=0A> >> netlmm@ietf.org=0A> >> https:/= /www1.ietf.org/mailman/listinfo/netlmm=0A> >>=0A> >=0A> >=0A> > ___________= ____________________________________=0A> > netlmm mailing list=0A> > netlmm= @ietf.org=0A> > https://www1.ietf.org/mailman/listinfo/netlmm=0A> >=0A> >= =0A> =0A=0A=0A_______________________________________________=0Anetlmm mail= ing list=0Anetlmm@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/netlmm= =0A=0A=0A=0A=0A --0-956562916-1190997730=:58334 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Ahmad and all,
  I saw postings in the list sa= ying let's move on which contradicts with statements suggesting creation of= another thread .
  Should we move on or keep spawning new threads?
<= br>
Regards,

Behcet

----- Original Message ----From: Ahmad Muhanna <amuhanna@nortel.com>
To: Wassim Haddad <w= haddad@tcs.hut.fi>; DE JUAN HUARTE FEDERICO <Federico.De_Juan_Huarte@= alcatel-lucent.fr>
Cc: netlmm <netlmm@ietf.org>
Sent: Friday= , September 28, 2007 11:31:17 AM
Subject: RE: Text Proposal for Compromi= sed MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)

Hi Wassim,

Please see comment below.

Regards,
Ahmad
=
> Subject: RE: Text Proposal for Compromised MAG issue (was
>= [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)
>
> On Fri,= 28 Sep 2007, DE JUAN HUARTE FEDERICO wrote:
>
> > One fina= l comment, if the MN can only be attached to one MAG at a
> > giv= en time, and if the LMA is going to validate the BU with the AAA
> &= gt; Server and the AAA server is capable of tracking the
> location = of the MAG ... then do we still need timestamps for
> message orderi= ng?
>
> =3D> It is not only this feature which may be quest= ionable.

[Ahmad]
May be you can help us understand how this feat= ure is questionable with the proposed text hint?

> In
> fa= ct, what Ahmad is proposing about AAA (which btw is
> interesting) can significantly enhance the protocol in many ways:
> = If the AAA is able to tell the LMA where the MN is located
> (i.e., = the MAG),

[Ahmad]
So, can I read this that you think it is impos= sible and does not make sense?


> then you can simply let the = LMA updates the
> MAG (instead of the opposite)

[Ahmad]
I= am not experienced with those reverse logic mechanisms but I am willing to= listen to your theory in a separate thread!

> and also let the L= MA sends to
> the MAG a temporary key to provide all SeND features w= ithout
> the need for CGA. So basically, you can address the MAG > compromise problem together with the CGA problem...

[Ahmad]Just FYI:
1. A detailed solution for the so called compromised MAG is = out-of-scope.
2. The text hint including the AAA has been proposed sever= al times before on the ml by different people.
Finally, if you have a different text to propose (with the above 1 & 2 in mind) that w= ould be great!

>
>
> Regards,
>
> Wass= im H.
>
>
>
> > -----Message d'origine-----> > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :
= > vendredi 28
> > septembre 2007 16:29 =C0 : Ahmad Muhanna Cc = : DE JUAN HUARTE
> FEDERICO;
> > netlmm Objet : RE: Text P= roposal for Compromised MAG issue (was
> > [netlmm] Review ofdraf= t-ietf-netlmm-proxymip6-05)
> >
> > Hi Federico,
> = >
> > We need to provide some guidance on how LMA implementatio= ns
> can esnure the presence of a MN at a given MAG in a
> de= terministic fashion. One possible way is that the
> Authentication i= nfrastructure such as AAA that generated the
> keys for the mobile n= ode session would know the current point
> of attachment. The LMA can query the same.
> >
> >    &= nbsp;  These entire arguments on MAG compromise ..etc, are
> lo= osing arguments. Unfortunately, we have to agree, there may
> not be= access authentication, but, at the same time we have
> to provide a= ll the guidance on how to prevent MAG compromise.
> These are all ki= ller arguments. So, these issues just delay
> the work. So, lets try= to find some text and put a closure to
> this work. By adding a ref= erence to AAA, does not imply, we
> have mandatory requirement on AA= A, or we are  making AAA
> stateful. Just any reasonable g= uidance with/without AAA
> should be fine.
> >
> >= Sri
> >
> >
> >
> >
> >
&g= t; > On Fri, 28 Sep 2007, Ahmad Muhanna wrote:
> >
> >= > Hi Federico,
> >>
> >> It is very nice to know that we are getting into the beauty
> >> context.:)> >>
> >> Please let us focus on all of the added te= xt:
> >>
> >> "
> >> .... by contacting= a trusted entity which tracks the MN
> current location, e.g. AAA s= erver.
> >> "
> >>
> >> If AAA server i= s not stateful, then deployment may use
> another trusted entity and= that is granted by the above text.
> >> Originally I am in fav= or of leaving the whole thing
> out-of-scope all together, but listi= ng AAA server as an
> example does not eliminate any other security = mechanisms nor
> require that all deployment have AAA server as stat= eful.
> >>
> >> Do not you agree?
> >><= br>> >> Sincerely, If we do not have any serious objection to this=
> text, we need to close the issue and move on.
> >> Thanks.
> >>
> >>
> >> Regard= s,
> >> Ahmad
> >>
> >>
> >>= ;> -----Original Message-----
> >>> From: DE JUAN HUARTE = FEDERICO
> >>> [mailto:Federico.De_Juan_Huarte@alcatel-lucen= t.fr]
> >>> Sent: Friday, September 28, 2007 4:23 AM
>= >>> To: Muhanna, Ahmad (RICH1:2H10)
> >>> Cc: netl= mm
> >>> Subject: RE: Text Proposal for Compromised MAG issu= e (was
> [netlmm]
> >>> Review ofdraft-ietf-netlmm-p= roxymip6-05)
> >>>
> >>> Hi Ahmad,
> &g= t;>>
> >>> in my understanding there's a general motiv= ation to make
> AAA Servers
> >>> stateless, so the = draft should not put such a strong "tracking"
> >>> requirem= ent It is clear to me that in some/many
> deployments the AAA
> >>> Server is not stateless anyway, so this is a minor <= br>> comment But then,
> >>> what the AAA Server actuall= y tracks is the NAS and not really the
> >>> MAG Somehow yo= u're assuming that the AAA Server is aware of the
> >>> rel= ationship between NASs and MAGs
> >>>
> >>> W= ith the current text, the security solution was left for
> >>&= gt; deployments to choose With the new text you're trying to
> close= the
> >>> solution space to one given solution Let's be fa= ir here:
> >>>    - or the security solu= tion is discussed and we do the beauty
> >>> contest with a= ll of them
> >>>    - or the security so= lution is not discussed and we leave the
> >>> discussion f= or other contexts
> >>>
> >>> Regards
> >>>
> >>> federico
> >>= ;>
> >>>
> >>>
> >>> -----M= essage d'origine-----
> >>> De : Ahmad Muhanna [mailto:amuha= nna@nortel.com] Envoy=E9 :
> >>> vendredi 28 septembre 2007 = 07:37 =C0 : Narayanan, Vidya; Vijay
> >>> Devarapalli; Kili= an Weniger Cc : netlmm Objet : RE: Text Proposal
> >>> for = Compromised MAG issue (was [netlmm] Review
> >>> ofdraft-iet= f-netlmm-proxymip6-05)
> >>>
> >>>
> &g= t;>> All,
> >>>
> >>> I sincerely do no= t want to debate the use of revocation for
> >>> compromise= d MAG at the present time. I am sure that all of us are
> >>&g= t; interested in getting this issue addressed properly and have it
>= >>> closed sooner than later. What about the following text:
> >>>
> >>> Current text under securit= y consideration:
> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
> >>> "
> >>>  &nbs= p; To eliminate the threats related to a compromised mobile access
= > >>>    gateway, this specification recomm= ends that the local mobility
> >>> anchor
> >>&= gt;    before accepting a Proxy Binding Update message = for a
> given mobile
> >>>    nod= e, should ensure the mobile node is definitively
> attached to the> >>>    mobile access gateway that sent = the binding
> registration request.
> >>> "
> &= gt;>>
> >>> New Text:
> >>> =3D=3D=3D= =3D=3D=3D=3D=3D=3D
> >>>
> >>> "
> >>>    To eliminate the threats related to a = compromised mobile access
> >>>    gatew= ay, this specification recommends that the local mobility
> >>= > anchor
> >>>    before accepting a = Proxy Binding Update message for a
> given mobile
> >>&g= t;    node, should ensure the mobile node is definitive= ly
> attached to the
> >>>    mob= ile access gateway that sent the binding
> registration request
&= gt; >>>    by contacting a trusted entity whic= h tracks the MN current
> >>> location,
> >>>= ;    e.g. AAA server.
> >>> "
> &g= t;>>
> >>> Regards,
> >>> Ahmad
>= >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Narayanan, Vidya= [mailto:vidyan@qualcomm.com]
> >>>> Sent: Wednesday, Sep= tember 26, 2007 7:41 PM
> >>>> To: Muhanna, Ahmad (RICH1:= 2H10); Vijay Devarapalli;
> Kilian Weniger
> >>>> = Cc: netlmm@ietf.org
> >>>> Subject: RE: Compromised MAG i= ssue (was [netlmm] Review of
> >>>> draft-ietf-netlmm-pro= xymip6-05)
> >>>>
> >>>> Hi Ahmad,
&= gt; >>>>
> >>>>
> >>>>> = -----Original Message-----
> >>>>> From: Ahmad Muhanna= [mailto:amuhanna@nortel.com]
> >>>>> Sent: Wednesday,= September 26, 2007 4:12 PM
> >>>>> To: Narayanan, Vid= ya; Vijay Devarapalli; Kilian Weniger
> >>>>> Cc: netl= mm@ietf.org
> >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of
> >>>>> draft-ietf-= netlmm-proxymip6-05)
> >>>>>
> >>>>&= gt; Hi Vidya,
> >>>>>
> >>>>> Usi= ng revocation for the compromised MAG was proposed by
> >>>&= gt; Kilian, et.
> >>>>> al.
> >>>>&g= t; but I am trying to help closing the issue so please allow
> >&g= t;>> me to jump
> >>>>> into this debate.
>= ; >>>>>
> >>>>> In order for the LMA to= validate the presence of the MN at
> >>>> a specific
= > >>>>> MAG, the LMA needs to do one of the followings:> >>>>>
> >>>>> 1. Validate the MN= identity via a MN signature carried in
> >>>> the P-BU. = In
> >>>>> P-MIPv6 this currently is not available since the P-BU is NOT
> >>>>> initiated by= the MN. (the most obvious option)
> >>>>>
> >= ;>>>> 2. Validate the MN presence via another trusted entity th= at
> >>>>> *ALWAYS* tracks the MN current location, e.= g. AAA server.
> >>>>>
> >>>>> 3.= Validate the MN presence via another trusted entity that
> >>&= gt;> tracks the
> >>>>> current or latest location = of the MN, e.g. the previous
> MAG using
> >>>>&g= t; binding revocation as was suggested by kilian et. al.
> >>&g= t;>>
> >>>>
> >>>> The LMA can't = assume that the pMAG is trusted while the new
> >>> MAG is t= he
> >>>
> >>>> one lying.  Perh= aps the MN really moved and the pMAG
> continues to
> >>>> claim it is there.  Regardless of which MAG tel= ls the LMA
> >>> what, 1 or 2
> >>>
> &= gt;>>> needs to occur to conclude where the MN really is and
&= gt; then, the LMA
> >>>> can determine which of the MAGs= was lying.
> >>>>
> >>>> Regards,
&= gt; >>>> Vidya
> >>>>
> >>>>= ;> 4. may be there are other ways...
> >>>>>
>= ; >>>>> In case that the MN is still at pMAG and has not mov= ed, the
> >>>> pMAG can
> >>>>> easi= ly indicate that in the binding revocation acknowledgement.
> >>= ;>>>
> >>>>> So do not you think that should = work?
> >>>>>
> >>>>> Regards,> >>>>> Ahmad
> >>>>>
> >>>>>
> >>>>= >> -----Original Message-----
> >>>>>> From: = Narayanan, Vidya [mailto:vidyan@qualcomm.com]
> >>>>>&= gt; Sent: Wednesday, September 26, 2007 3:49 PM
> >>>>>= ;> To: Vijay Devarapalli; Kilian Weniger
> >>>>>>= ; Cc: netlmm@ietf.org
> >>>>>> Subject: RE: Comprom= ised MAG issue (was [netlmm] Review of
> >>>>>> dra= ft-ietf-netlmm-proxymip6-05)
> >>>>>>
> >&= gt;>>>>
> >>>>>> A few observations her= e. I don't believe binding revocation
> >>>>> is going=
> >>>>>> to solve anything here.  The fu= ndamental issue is how the LMA
> >>>>>> *identifies= * the compromised MAG, not how the
> >>> compromised MAG is
> >>>>>> notified that its binding is no lo= nger valid.  Once the MAG is
> >>>>>> id= entified as compromised, a number of remedies may be taken,
> >&g= t;>>>> including, simply blacklisting the MAG and not accepting=
> >>>>> PBUs from it.
> >>>>>>= ; It is not critical that the binding be revoked, because,
> >>= >>> the LMA has
> >>>>>> already identifie= d where the MN really is and it just
> >>>> needs to use<= br>> >>>>>> that binding for data acceptance/forwardin= g.
> >>>>>>
> >>>>>>
>= ; >>>>>> The issue of how the LMA identifies a compromise= d MAG
> cannot be
> >>>>>> tackled without = an independent verification of the
> >>>> presence of the
> >>>>>> MN at that particular MAG. &n= bsp;So, we need to focus on
> >>>> providing hints
>= ; >>>>>> on how the LMA may go about
> >>>= >> achieving that.
> >>>>>>
> >>&= gt;>>> Vidya
> >>>>>>
> >>>= >>>> -----Original Message-----
> >>>>>>= ;> From: Vijay Devarapalli
> >>> [mailto:vijay.devarapall= i@AzaireNet.com]
> >>>>>>> Sent: Wednesday, Sept= ember 26, 2007 11:08 AM
> >>>>>>> To: Kilian Wen= iger
> >>>>>>> Cc: Narayanan, Vidya; netlmm@ietf= .org
> >>>>>>> Subject: Re: Compromised MAG issu= e (was [netlmm] Review of
> >>>>>>> draft-ietf-n= etlmm-proxymip6-05)
> >>>>>>>
> >>>>>>> Kilian Weniger wrote:
> >>>>= ;>>>> Narayanan, Vidya wrote:
> >>>>>>&= gt;>>>> - Security considerations: MAG Compromise:
> >= >>>>>>> ...
> >>>>>>>>&g= t; If we claim this is an issue in the security
> >>>>>= ;>> considerations section
> >>>>>>>>&g= t; and claim that the fix to it is for the LMA to ensure
> >>&g= t;>> the MN is
> >>>>>>>>> actually = attached to the MAG, we can't quite hand
> >>>> wave on s= ome
> >>>>>>>>> possible ways to do that.&= nbsp; Those are just hints for
> >>>>>>> de= ployments that
> >>>>>>>>> are concerned a= bout MAG compromise.  But, those hints
> >>>>> need to be
> >>>>>>>>&g= t; captured in the security considerations section.
> >>>>= ; The threats
> >>>>>>>>> document capture= s this threat and it is a valid one - so,
> >>>>>>&= gt; I believe
> >>>>>>>>> we need some tex= t here.  The type of "detail" is what
> >>>>>= ; I tried to
> >>>>>>>>> provide with the = examples on AAA checks or CGA
> >>>>>> signatures -= and, I
> >>>>>>>>> don't think we need a = lot of detail here; a few
> >>>>>> sentences would = be
> >>>>>>>>> good.
> >>>&= gt;>>>>>
> >>>>>>>>
> &g= t;>>>>>>> I had a similar comment a while ago. I think that a draft
> >>>>>>> describing a
= > >>>>>>>> severe security issue should at least= give hints how this
> >>>>>>> can be solved.> >>>>>>>>
> >>>>>>>= > Recently Sri, Vijay, Kuntal and I had an offline
> >>>&= gt;> discussion about
> >>>>>>>> another p= ossible solution to detect a compromised MAGs,
> >>>>>= >> which relies
> >>>>>>>> on PMIP sign= aling only.
> >>>>>>>>
> >>>&g= t;>>>> The basic idea is that if two MAGs simultaneously claim<= br>> >>>>>>> that the MN is
> >>>>= ;>>>> attached, one of the MAGs must lie and is probably a
&= gt; >>>>>>> compromised MAG.
> >>>>>>>> The assumption is that the MN cannot at t= he same time be
> >>>>>>> attached to
> &g= t;>>>>>>> two MAGs, at least not with the same network= interface.
> >>>>>>>>
> >>>&g= t;>>>> More specifically, when the LMA accepts a valid PBU from= a
> >>>>>>> new MAG, it
> >>>>= ;>>>> changes the BCE (i.e., there is no impact on handover
= > >>>>> delay) and
> >>>>>>>&g= t; notifies the old MAG (i.e., old address in BCE) about
> >>&g= t;>>> this. The old
> >>>>>>>> MAG t= hen checks whether the MN is still attached. If this
> >>>&g= t;>>> is the case,
> >>>>>>>> it inf= orms the LMA about this. The LMA then learns that two
> >>>>>>> different
> >>>>>>>= ;> MAGs claim MN attachement, which is not possible under the
> &g= t;>>>>>> assumption
> >>>>>>>&= gt; stated above. Hence, after receiving one or more such
> >>&= gt;>>>> notifications,
> >>>>>>>>= the LMA can identify the compromised MAG and stop
> >>>>= >> trusting this MAG.
> >>>>>>>>
>= ; >>>>>>>> A remaining problem was which message sh= ould be used to
> >>>>>>> inform the old
>= >>>>>>>> MAG about the BCE change. PBA and revocat= ion msg were
> >>>>>>> discussed, but
> &g= t;>>>>>>> the former is not sent unsolicited according= to RFC3775
> >>>>>>> (which could
> >>>>>>>> be overidden by PMIP spec o= f course) and the latter is not
> >>>>>>>> s= tandardized yet.
> >>>>>>>
> >>>&= gt;>>> As I said in another threat, we really need to
> >= >> standardize the
> >>>>>>> revocation me= ssage from the LMA to the old MAG ASAP.
> >>>>>>>= ;
> >>>>>>> Vijay
> >>>>>&g= t;>
> >>>>>>
> >>>>>> __= _____________________________________________
> >>>>>&= gt; netlmm mailing list
> >>>>>> netlmm@ietf.org> >>>>>> https://www1.ietf.org/mailman/listinfo/netl= mm
> >>>>>>
> >>>>>
> >>>>
> >>>
>= >>>
> >>> ________________________________________= _______
> >>> netlmm mailing list
> >>> netlm= m@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/net= lmm
> >>>
> >>
> >>
> >= > _______________________________________________
> >> netlm= m mailing list
> >> netlmm@ietf.org
> >> https://= www1.ietf.org/mailman/listinfo/netlmm
> >>
> >
= > >
> > _______________________________________________
&= gt; > netlmm mailing list
> > netlmm@ietf.org
> > https://www1.ietf.o= rg/mailman/listinfo/netlmm
> >
> >
>

_______________________________________________
netlmm mailing listnetlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm
<= /div>

--0-956562916-1190997730=:58334-- --===============0780602271== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0780602271==-- From netlmm-bounces@ietf.org Fri Sep 28 12:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIxf-0000aT-Rm; Fri, 28 Sep 2007 12:45:07 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbIxe-0000aO-AG for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:45:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIxe-0000aF-07 for netlmm@ietf.org; Fri, 28 Sep 2007 12:45:06 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbIxX-0006Ri-EN for netlmm@ietf.org; Fri, 28 Sep 2007 12:45:05 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8SGiSR23254; Fri, 28 Sep 2007 16:44:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 11:44:27 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711709DC87@zrc2hxm2.corp.nortel.com> In-Reply-To: <35640.58334.qm@web84105.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB7o0QwuHMpthsTbm4n4gGh8OoUQAAAUvw References: <35640.58334.qm@web84105.mail.mud.yahoo.com> From: "Ahmad Muhanna" To: "Behcet Sarikaya" X-Spam-Score: 0.0 (/) X-Scan-Signature: b675de3830c03375a22785cd725f9979 Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0425291758==" Errors-To: netlmm-bounces@ietf.org This is a multi-part message in MIME format. --===============0425291758== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C801EE.D5B964B3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C801EE.D5B964B3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Behcet, =20 No there is no contradiction. that issue is not related here and if we = need to discuss it further we can go ahead and do so in a separate = thread. that all what I meant. =20 Cheers. Regards,=20 Ahmad=20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Friday, September 28, 2007 11:42 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: netlmm Subject: Re: Text Proposal for Compromised MAG issue (was [netlmm] = Review ofdraft-ietf-netlmm-proxymip6-05) =09 =09 Ahmad and all, I saw postings in the list saying let's move on which contradicts = with statements suggesting creation of another thread = . Should we move on or keep spawning new threads? =09 =09 Regards, =09 Behcet =09 =09 ----- Original Message ---- From: Ahmad Muhanna To: Wassim Haddad ; DE JUAN HUARTE FEDERICO = Cc: netlmm Sent: Friday, September 28, 2007 11:31:17 AM Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] = Review ofdraft-ietf-netlmm-proxymip6-05) =09 =09 Hi Wassim, =09 Please see comment below. =09 Regards, Ahmad =09 > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) >=20 > On Fri, 28 Sep 2007, DE JUAN HUARTE FEDERICO wrote: >=20 > > One final comment, if the MN can only be attached to one MAG at a=20 > > given time, and if the LMA is going to validate the BU with the AAA = > > Server and the AAA server is capable of tracking the=20 > location of the MAG ... then do we still need timestamps for=20 > message ordering? >=20 > =3D> It is not only this feature which may be questionable. =09 [Ahmad] May be you can help us understand how this feature is questionable with = the proposed text hint? =09 > In=20 > fact, what Ahmad is proposing about AAA (which btw is=20 > interesting) can significantly enhance the protocol in many ways: > If the AAA is able to tell the LMA where the MN is located=20 > (i.e., the MAG), =09 [Ahmad] So, can I read this that you think it is impossible and does not make = sense? =09 =09 > then you can simply let the LMA updates the=20 > MAG (instead of the opposite)=20 =09 [Ahmad] I am not experienced with those reverse logic mechanisms but I am = willing to listen to your theory in a separate thread! =09 > and also let the LMA sends to=20 > the MAG a temporary key to provide all SeND features without=20 > the need for CGA. So basically, you can address the MAG=20 > compromise problem together with the CGA problem... =09 [Ahmad] Just FYI:=20 1. A detailed solution for the so called compromised MAG is = out-of-scope. 2. The text hint including the AAA has been proposed several times = before on the ml by different people. Finally, if you have a different text to propose (with the above 1 & 2 = in mind) that would be great! =09 >=20 >=20 > Regards, >=20 > Wassim H. >=20 >=20 >=20 > > -----Message d'origine----- > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :=20 > vendredi 28=20 > > septembre 2007 16:29 =C0 : Ahmad Muhanna Cc : DE JUAN HUARTE=20 > FEDERICO;=20 > > netlmm Objet : RE: Text Proposal for Compromised MAG issue (was=20 > > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) > > > > Hi Federico, > > > > We need to provide some guidance on how LMA implementations=20 > can esnure the presence of a MN at a given MAG in a=20 > deterministic fashion. One possible way is that the=20 > Authentication infrastructure such as AAA that generated the=20 > keys for the mobile node session would know the current point=20 > of attachment. The LMA can query the same. > > > > These entire arguments on MAG compromise ..etc, are=20 > loosing arguments. Unfortunately, we have to agree, there may=20 > not be access authentication, but, at the same time we have=20 > to provide all the guidance on how to prevent MAG compromise.=20 > These are all killer arguments. So, these issues just delay=20 > the work. So, lets try to find some text and put a closure to=20 > this work. By adding a reference to AAA, does not imply, we=20 > have mandatory requirement on AAA, or we are making AAA=20 > stateful. Just any reasonable guidance with/without AAA=20 > should be fine. > > > > Sri > > > > > > > > > > > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > > > >> Hi Federico, > >> > >> It is very nice to know that we are getting into the beauty=20 > >> context.:) > >> > >> Please let us focus on all of the added text: > >> > >> " > >> .... by contacting a trusted entity which tracks the MN=20 > current location, e.g. AAA server. > >> " > >> > >> If AAA server is not stateful, then deployment may use=20 > another trusted entity and that is granted by the above text. > >> Originally I am in favor of leaving the whole thing=20 > out-of-scope all together, but listing AAA server as an=20 > example does not eliminate any other security mechanisms nor=20 > require that all deployment have AAA server as stateful. > >> > >> Do not you agree? > >> > >> Sincerely, If we do not have any serious objection to this=20 > text, we need to close the issue and move on. > >> Thanks. > >> > >> > >> Regards, > >> Ahmad > >> > >> > >>> -----Original Message----- > >>> From: DE JUAN HUARTE FEDERICO > >>> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > >>> Sent: Friday, September 28, 2007 4:23 AM > >>> To: Muhanna, Ahmad (RICH1:2H10) > >>> Cc: netlmm > >>> Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm]=20 > >>> Review ofdraft-ietf-netlmm-proxymip6-05) > >>> > >>> Hi Ahmad, > >>> > >>> in my understanding there's a general motivation to make=20 > AAA Servers=20 > >>> stateless, so the draft should not put such a strong "tracking" > >>> requirement It is clear to me that in some/many=20 > deployments the AAA=20 > >>> Server is not stateless anyway, so this is a minor=20 > comment But then,=20 > >>> what the AAA Server actually tracks is the NAS and not really the = > >>> MAG Somehow you're assuming that the AAA Server is aware of the=20 > >>> relationship between NASs and MAGs > >>> > >>> With the current text, the security solution was left for=20 > >>> deployments to choose With the new text you're trying to=20 > close the=20 > >>> solution space to one given solution Let's be fair here: > >>> - or the security solution is discussed and we do the beauty=20 > >>> contest with all of them > >>> - or the security solution is not discussed and we leave the=20 > >>> discussion for other contexts > >>> > >>> Regards > >>> > >>> federico > >>> > >>> > >>> > >>> -----Message d'origine----- > >>> De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 : > >>> vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay=20 > >>> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text Proposal = > >>> for Compromised MAG issue (was [netlmm] Review > >>> ofdraft-ietf-netlmm-proxymip6-05) > >>> > >>> > >>> All, > >>> > >>> I sincerely do not want to debate the use of revocation for=20 > >>> compromised MAG at the present time. I am sure that all of us are = > >>> interested in getting this issue addressed properly and have it=20 > >>> closed sooner than later. What about the following text: > >>> > >>> Current text under security consideration: > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> " > >>> To eliminate the threats related to a compromised mobile = access > >>> gateway, this specification recommends that the local mobility = > >>> anchor > >>> before accepting a Proxy Binding Update message for a=20 > given mobile > >>> node, should ensure the mobile node is definitively=20 > attached to the > >>> mobile access gateway that sent the binding=20 > registration request. > >>> " > >>> > >>> New Text: > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> " > >>> To eliminate the threats related to a compromised mobile = access > >>> gateway, this specification recommends that the local mobility = > >>> anchor > >>> before accepting a Proxy Binding Update message for a=20 > given mobile > >>> node, should ensure the mobile node is definitively=20 > attached to the > >>> mobile access gateway that sent the binding=20 > registration request > >>> by contacting a trusted entity which tracks the MN current=20 > >>> location, > >>> e.g. AAA server. > >>> " > >>> > >>> Regards, > >>> Ahmad > >>> > >>> > >>>> -----Original Message----- > >>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>>> Sent: Wednesday, September 26, 2007 7:41 PM > >>>> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli;=20 > Kilian Weniger > >>>> Cc: netlmm@ietf.org > >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>> draft-ietf-netlmm-proxymip6-05) > >>>> > >>>> Hi Ahmad, > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > >>>>> Sent: Wednesday, September 26, 2007 4:12 PM > >>>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > >>>>> Cc: netlmm@ietf.org > >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>>> draft-ietf-netlmm-proxymip6-05) > >>>>> > >>>>> Hi Vidya, > >>>>> > >>>>> Using revocation for the compromised MAG was proposed by > >>>> Kilian, et. > >>>>> al. > >>>>> but I am trying to help closing the issue so please allow > >>>> me to jump > >>>>> into this debate. > >>>>> > >>>>> In order for the LMA to validate the presence of the MN at > >>>> a specific > >>>>> MAG, the LMA needs to do one of the followings: > >>>>> > >>>>> 1. Validate the MN identity via a MN signature carried in > >>>> the P-BU. In > >>>>> P-MIPv6 this currently is not available since the P-BU is NOT=20 > >>>>> initiated by the MN. (the most obvious option) > >>>>> > >>>>> 2. Validate the MN presence via another trusted entity that > >>>>> *ALWAYS* tracks the MN current location, e.g. AAA server. > >>>>> > >>>>> 3. Validate the MN presence via another trusted entity that > >>>> tracks the > >>>>> current or latest location of the MN, e.g. the previous=20 > MAG using=20 > >>>>> binding revocation as was suggested by kilian et. al. > >>>>> > >>>> > >>>> The LMA can't assume that the pMAG is trusted while the new > >>> MAG is the > >>> > >>>> one lying. Perhaps the MN really moved and the pMAG=20 > continues to=20 > >>>> claim it is there. Regardless of which MAG tells the LMA > >>> what, 1 or 2 > >>> > >>>> needs to occur to conclude where the MN really is and=20 > then, the LMA=20 > >>>> can determine which of the MAGs was lying. > >>>> > >>>> Regards, > >>>> Vidya > >>>> > >>>>> 4. may be there are other ways... > >>>>> > >>>>> In case that the MN is still at pMAG and has not moved, the > >>>> pMAG can > >>>>> easily indicate that in the binding revocation acknowledgement. > >>>>> > >>>>> So do not you think that should work? > >>>>> > >>>>> Regards, > >>>>> Ahmad > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>>>>> Sent: Wednesday, September 26, 2007 3:49 PM > >>>>>> To: Vijay Devarapalli; Kilian Weniger > >>>>>> Cc: netlmm@ietf.org > >>>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > >>>>>> draft-ietf-netlmm-proxymip6-05) > >>>>>> > >>>>>> > >>>>>> A few observations here. I don't believe binding revocation > >>>>> is going > >>>>>> to solve anything here. The fundamental issue is how the LMA > >>>>>> *identifies* the compromised MAG, not how the > >>> compromised MAG is > >>>>>> notified that its binding is no longer valid. Once the MAG is = > >>>>>> identified as compromised, a number of remedies may be taken,=20 > >>>>>> including, simply blacklisting the MAG and not accepting > >>>>> PBUs from it. > >>>>>> It is not critical that the binding be revoked, because, > >>>>> the LMA has > >>>>>> already identified where the MN really is and it just > >>>> needs to use > >>>>>> that binding for data acceptance/forwarding. > >>>>>> > >>>>>> > >>>>>> The issue of how the LMA identifies a compromised MAG=20 > cannot be=20 > >>>>>> tackled without an independent verification of the > >>>> presence of the > >>>>>> MN at that particular MAG. So, we need to focus on > >>>> providing hints > >>>>>> on how the LMA may go about > >>>>> achieving that. > >>>>>> > >>>>>> Vidya > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Vijay Devarapalli > >>> [mailto:vijay.devarapalli@AzaireNet.com] > >>>>>>> Sent: Wednesday, September 26, 2007 11:08 AM > >>>>>>> To: Kilian Weniger > >>>>>>> Cc: Narayanan, Vidya; netlmm@ietf.org > >>>>>>> Subject: Re: Compromised MAG issue (was [netlmm] Review of > >>>>>>> draft-ietf-netlmm-proxymip6-05) > >>>>>>> > >>>>>>> Kilian Weniger wrote: > >>>>>>>> Narayanan, Vidya wrote: > >>>>>>>>>>> - Security considerations: MAG Compromise: > >>>>>>>> ... > >>>>>>>>> If we claim this is an issue in the security > >>>>>>> considerations section > >>>>>>>>> and claim that the fix to it is for the LMA to ensure > >>>>> the MN is > >>>>>>>>> actually attached to the MAG, we can't quite hand > >>>> wave on some > >>>>>>>>> possible ways to do that. Those are just hints for > >>>>>>> deployments that > >>>>>>>>> are concerned about MAG compromise. But, those hints > >>>>> need to be > >>>>>>>>> captured in the security considerations section. > >>>> The threats > >>>>>>>>> document captures this threat and it is a valid one - so, > >>>>>>> I believe > >>>>>>>>> we need some text here. The type of "detail" is what > >>>>> I tried to > >>>>>>>>> provide with the examples on AAA checks or CGA > >>>>>> signatures - and, I > >>>>>>>>> don't think we need a lot of detail here; a few > >>>>>> sentences would be > >>>>>>>>> good. > >>>>>>>>> > >>>>>>>> > >>>>>>>> I had a similar comment a while ago. I think that a draft > >>>>>>> describing a > >>>>>>>> severe security issue should at least give hints how this > >>>>>>> can be solved. > >>>>>>>> > >>>>>>>> Recently Sri, Vijay, Kuntal and I had an offline > >>>>> discussion about > >>>>>>>> another possible solution to detect a compromised MAGs, > >>>>>>> which relies > >>>>>>>> on PMIP signaling only. > >>>>>>>> > >>>>>>>> The basic idea is that if two MAGs simultaneously claim > >>>>>>> that the MN is > >>>>>>>> attached, one of the MAGs must lie and is probably a > >>>>>>> compromised MAG. > >>>>>>>> The assumption is that the MN cannot at the same time be > >>>>>>> attached to > >>>>>>>> two MAGs, at least not with the same network interface. > >>>>>>>> > >>>>>>>> More specifically, when the LMA accepts a valid PBU from a > >>>>>>> new MAG, it > >>>>>>>> changes the BCE (i.e., there is no impact on handover > >>>>> delay) and > >>>>>>>> notifies the old MAG (i.e., old address in BCE) about > >>>>>> this. The old > >>>>>>>> MAG then checks whether the MN is still attached. If this > >>>>>>> is the case, > >>>>>>>> it informs the LMA about this. The LMA then learns that two > >>>>>>> different > >>>>>>>> MAGs claim MN attachement, which is not possible under the > >>>>>>> assumption > >>>>>>>> stated above. Hence, after receiving one or more such > >>>>>>> notifications, > >>>>>>>> the LMA can identify the compromised MAG and stop > >>>>>> trusting this MAG. > >>>>>>>> > >>>>>>>> A remaining problem was which message should be used to > >>>>>>> inform the old > >>>>>>>> MAG about the BCE change. PBA and revocation msg were > >>>>>>> discussed, but > >>>>>>>> the former is not sent unsolicited according to RFC3775 > >>>>>>> (which could > >>>>>>>> be overidden by PMIP spec of course) and the latter is not=20 > >>>>>>>> standardized yet. > >>>>>>> > >>>>>>> As I said in another threat, we really need to > >>> standardize the > >>>>>>> revocation message from the LMA to the old MAG ASAP. > >>>>>>> > >>>>>>> Vijay > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> netlmm mailing list > >>>>>> netlmm@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>>> > >>>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > >> > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >> > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > >=20 =09 =09 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm =09 ------_=_NextPart_001_01C801EE.D5B964B3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Behcet,
 
No there is no contradiction. that issue is not = related=20 here and if we need to discuss it further we can go ahead and = do so in=20 a separate thread. that all what I meant.
 
Cheers.

Regards, =
Ahmad

 

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: Friday, September = 28, 2007=20 11:42 AM
To: Muhanna, Ahmad (RICH1:2H10)
Cc:=20 netlmm
Subject: Re: Text Proposal for Compromised MAG issue = (was=20 [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)

Ahmad=20 and all,
  I saw postings in the list saying let's move on = which=20 contradicts with statements suggesting creation of another thread .
  Should we move on or keep spawning new=20 threads?


Regards,

Behcet

-----=20 Original Message ----
From: Ahmad Muhanna=20 <amuhanna@nortel.com>
To: Wassim Haddad = <whaddad@tcs.hut.fi>;=20 DE JUAN HUARTE FEDERICO=20 <Federico.De_Juan_Huarte@alcatel-lucent.fr>
Cc: netlmm=20 <netlmm@ietf.org>
Sent: Friday, September 28, 2007 11:31:17=20 AM
Subject: RE: Text Proposal for Compromised MAG issue (was = [netlmm]=20 Review ofdraft-ietf-netlmm-proxymip6-05)

Hi Wassim,

Please see comment=20 below.

Regards,
Ahmad

> Subject: RE: Text Proposal = for=20 Compromised MAG issue (was
> [netlmm] Review=20 ofdraft-ietf-netlmm-proxymip6-05)
>
> On Fri, 28 Sep = 2007, DE=20 JUAN HUARTE FEDERICO wrote:
>
> > One final comment, = if the MN=20 can only be attached to one MAG at a
> > given time, and if = the LMA=20 is going to validate the BU with the AAA
> > Server and the = AAA=20 server is capable of tracking the
> location of the MAG ... = then do we=20 still need timestamps for
> message ordering?
>
> = =3D> It=20 is not only this feature which may be = questionable.

[Ahmad]
May be=20 you can help us understand how this feature is questionable with the = proposed=20 text hint?

> In
> fact, what Ahmad is proposing about = AAA=20 (which btw is
> interesting) can significantly enhance the = protocol in=20 many ways:
> If the AAA is able to tell the LMA where the MN is = located=20
> (i.e., the MAG),

[Ahmad]
So, can I read this that = you think=20 it is impossible and does not make sense?


> then you can = simply=20 let the LMA updates the
> MAG (instead of the opposite)=20

[Ahmad]
I am not experienced with those reverse logic = mechanisms=20 but I am willing to listen to your theory in a separate = thread!

>=20 and also let the LMA sends to
> the MAG a temporary key to = provide all=20 SeND features without
> the need for CGA. So basically, you can = address=20 the MAG
> compromise problem together with the CGA=20 problem...

[Ahmad]
Just FYI:
1. A detailed solution for = the so=20 called compromised MAG is out-of-scope.
2. The text hint including = the AAA=20 has been proposed several times before on the ml by different=20 people.
Finally, if you have a different text to propose (with the = above 1=20 & 2 in mind) that would be great!

>
>
>=20 Regards,
>
> Wassim H.
>
>
>
> = >=20 -----Message d'origine-----
> > De : Sri Gundavelli=20 [mailto:sgundave@cisco.com] Envoy=E9 :
> vendredi 28
> = >=20 septembre 2007 16:29 =C0 : Ahmad Muhanna Cc : DE JUAN HUARTE
> = FEDERICO;=20
> > netlmm Objet : RE: Text Proposal for Compromised MAG = issue (was=20
> > [netlmm] Review = ofdraft-ietf-netlmm-proxymip6-05)
>=20 >
> > Hi Federico,
> >
> > We need to = provide=20 some guidance on how LMA implementations
> can esnure the = presence of a=20 MN at a given MAG in a
> deterministic fashion. One possible = way is=20 that the
> Authentication infrastructure such as AAA that = generated the=20
> keys for the mobile node session would know the current point =
> of attachment. The LMA can query the same.
> = >
>=20 >       These entire arguments on MAG = compromise ..etc, are
> loosing arguments. Unfortunately, we = have to=20 agree, there may
> not be access authentication, but, at the = same time=20 we have
> to provide all the guidance on how to prevent MAG = compromise.=20
> These are all killer arguments. So, these issues just delay =
>=20 the work. So, lets try to find some text and put a closure to
> = this=20 work. By adding a reference to AAA, does not imply, we
> have = mandatory=20 requirement on AAA, or we are  making AAA
> stateful. = Just=20 any reasonable guidance with/without AAA
> should be = fine.
>=20 >
> > Sri
> >
> >
> >
>=20 >
> >
> > On Fri, 28 Sep 2007, Ahmad Muhanna=20 wrote:
> >
> >> Hi Federico,
> = >>
>=20 >> It is very nice to know that we are getting into the beauty =
>=20 >> context.:)
> >>
> >> Please let us = focus on=20 all of the added text:
> >>
> >> "
> = >>=20 .... by contacting a trusted entity which tracks the MN
> = current=20 location, e.g. AAA server.
> >> "
> >>
> = >> If AAA server is not stateful, then deployment may use =
>=20 another trusted entity and that is granted by the above text.
> = >>=20 Originally I am in favor of leaving the whole thing
> = out-of-scope all=20 together, but listing AAA server as an
> example does not = eliminate any=20 other security mechanisms nor
> require that all deployment = have AAA=20 server as stateful.
> >>
> >> Do not you=20 agree?
> >>
> >> Sincerely, If we do not have = any=20 serious objection to this
> text, we need to close the issue = and move=20 on.
> >> Thanks.
> >>
> >>
> = >> Regards,
> >> Ahmad
> >>
>=20 >>
> >>> -----Original Message-----
> = >>>=20 From: DE JUAN HUARTE FEDERICO
> >>>=20 [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]
> = >>> Sent:=20 Friday, September 28, 2007 4:23 AM
> >>> To: Muhanna, = Ahmad=20 (RICH1:2H10)
> >>> Cc: netlmm
> >>> = Subject: RE:=20 Text Proposal for Compromised MAG issue (was
> [netlmm] =
>=20 >>> Review ofdraft-ietf-netlmm-proxymip6-05)
>=20 >>>
> >>> Hi Ahmad,
> = >>>
>=20 >>> in my understanding there's a general motivation to make =
>=20 AAA Servers
> >>> stateless, so the draft should not = put such=20 a strong "tracking"
> >>> requirement It is clear to me = that in=20 some/many
> deployments the AAA
> >>> Server is = not=20 stateless anyway, so this is a minor
> comment But then, =
>=20 >>> what the AAA Server actually tracks is the NAS and not = really the=20
> >>> MAG Somehow you're assuming that the AAA Server = is aware=20 of the
> >>> relationship between NASs and = MAGs
>=20 >>>
> >>> With the current text, the security = solution=20 was left for
> >>> deployments to choose With the new = text=20 you're trying to
> close the
> >>> solution = space to=20 one given solution Let's be fair here:
>=20 >>>    - or the security solution is = discussed=20 and we do the beauty
> >>> contest with all of = them
>=20 >>>    - or the security solution is not=20 discussed and we leave the
> >>> discussion for other=20 contexts
> >>>
> >>> Regards
>=20 >>>
> >>> federico
> = >>>
>=20 >>>
> >>>
> >>> -----Message=20 d'origine-----
> >>> De : Ahmad Muhanna=20 [mailto:amuhanna@nortel.com] Envoy=E9 :
> >>> vendredi = 28=20 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay
> = >>>=20 Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text Proposal =
>=20 >>> for Compromised MAG issue (was [netlmm] Review
>=20 >>> ofdraft-ietf-netlmm-proxymip6-05)
> = >>>
>=20 >>>
> >>> All,
> >>>
>=20 >>> I sincerely do not want to debate the use of revocation = for=20
> >>> compromised MAG at the present time. I am sure = that all=20 of us are
> >>> interested in getting this issue = addressed=20 properly and have it
> >>> closed sooner than later. = What=20 about the following text:
> >>>
> >>> = Current=20 text under security consideration:
> >>>=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>> = "
>=20 >>>    To eliminate the threats related = to a=20 compromised mobile access
> = >>>    gateway,=20 this specification recommends that the local mobility
> = >>>=20 anchor
> >>>    before accepting a = Proxy=20 Binding Update message for a
> given mobile
>=20 >>>    node, should ensure the mobile = node is=20 definitively
> attached to the
>=20 >>>    mobile access gateway that sent = the=20 binding
> registration request.
> >>> "
>=20 >>>
> >>> New Text:
> >>>=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>>
> >>> = "
>=20 >>>    To eliminate the threats related = to a=20 compromised mobile access
> = >>>    gateway,=20 this specification recommends that the local mobility
> = >>>=20 anchor
> >>>    before accepting a = Proxy=20 Binding Update message for a
> given mobile
>=20 >>>    node, should ensure the mobile = node is=20 definitively
> attached to the
>=20 >>>    mobile access gateway that sent = the=20 binding
> registration request
>=20 >>>    by contacting a trusted entity = which=20 tracks the MN current
> >>> location,
>=20 >>>    e.g. AAA server.
> = >>>=20 "
> >>>
> >>> Regards,
> = >>>=20 Ahmad
> >>>
> >>>
> = >>>>=20 -----Original Message-----
> >>>> From: Narayanan, = Vidya=20 [mailto:vidyan@qualcomm.com]
> >>>> Sent: Wednesday, = September 26, 2007 7:41 PM
> >>>> To: Muhanna, Ahmad = (RICH1:2H10); Vijay Devarapalli;
> Kilian Weniger
>=20 >>>> Cc: netlmm@ietf.org
> >>>> Subject: = RE:=20 Compromised MAG issue (was [netlmm] Review of
> >>>> = draft-ietf-netlmm-proxymip6-05)
> >>>>
>=20 >>>> Hi Ahmad,
> >>>>
>=20 >>>>
> >>>>> -----Original=20 Message-----
> >>>>> From: Ahmad Muhanna=20 [mailto:amuhanna@nortel.com]
> >>>>> Sent: = Wednesday,=20 September 26, 2007 4:12 PM
> >>>>> To: Narayanan, = Vidya;=20 Vijay Devarapalli; Kilian Weniger
> >>>>> Cc:=20 netlmm@ietf.org
> >>>>> Subject: RE: Compromised = MAG=20 issue (was [netlmm] Review of
> >>>>>=20 draft-ietf-netlmm-proxymip6-05)
> >>>>>
>=20 >>>>> Hi Vidya,
> >>>>>
>=20 >>>>> Using revocation for the compromised MAG was = proposed=20 by
> >>>> Kilian, et.
> >>>>>=20 al.
> >>>>> but I am trying to help closing the = issue so=20 please allow
> >>>> me to jump
> = >>>>>=20 into this debate.
> >>>>>
> = >>>>> In=20 order for the LMA to validate the presence of the MN at
>=20 >>>> a specific
> >>>>> MAG, the LMA = needs to=20 do one of the followings:
> >>>>>
>=20 >>>>> 1. Validate the MN identity via a MN signature = carried=20 in
> >>>> the P-BU. In
> >>>>> = P-MIPv6=20 this currently is not available since the P-BU is NOT
>=20 >>>>> initiated by the MN. (the most obvious = option)
>=20 >>>>>
> >>>>> 2. Validate the MN = presence=20 via another trusted entity that
> >>>>> *ALWAYS* = tracks=20 the MN current location, e.g. AAA server.
> = >>>>>
>=20 >>>>> 3. Validate the MN presence via another trusted = entity=20 that
> >>>> tracks the
> >>>>> = current=20 or latest location of the MN, e.g. the previous
> MAG using =
>=20 >>>>> binding revocation as was suggested by kilian et. = al.
> >>>>>
> >>>>
>=20 >>>> The LMA can't assume that the pMAG is trusted while = the=20 new
> >>> MAG is the
> >>>
>=20 >>>> one lying.  Perhaps the MN really moved and = the=20 pMAG
> continues to
> >>>> claim it is=20 there.  Regardless of which MAG tells the LMA
> = >>>=20 what, 1 or 2
> >>>
> >>>> needs to = occur to=20 conclude where the MN really is and
> then, the LMA
>=20 >>>> can determine which of the MAGs was lying.
>=20 >>>>
> >>>> Regards,
> = >>>>=20 Vidya
> >>>>
> >>>>> 4. may be = there=20 are other ways...
> >>>>>
> = >>>>> In=20 case that the MN is still at pMAG and has not moved, the
>=20 >>>> pMAG can
> >>>>> easily indicate = that in=20 the binding revocation acknowledgement.
> = >>>>>
>=20 >>>>> So do not you think that should work?
>=20 >>>>>
> >>>>> Regards,
>=20 >>>>> Ahmad
> >>>>>
>=20 >>>>>
> >>>>>> -----Original=20 Message-----
> >>>>>> From: Narayanan, Vidya=20 [mailto:vidyan@qualcomm.com]
> >>>>>> Sent: = Wednesday,=20 September 26, 2007 3:49 PM
> >>>>>> To: Vijay=20 Devarapalli; Kilian Weniger
> >>>>>> Cc:=20 netlmm@ietf.org
> >>>>>> Subject: RE: = Compromised MAG=20 issue (was [netlmm] Review of
> >>>>>>=20 draft-ietf-netlmm-proxymip6-05)
> = >>>>>>
>=20 >>>>>>
> >>>>>> A few = observations=20 here. I don't believe binding revocation
> >>>>> = is=20 going
> >>>>>> to solve anything = here.  The=20 fundamental issue is how the LMA
> >>>>>> = *identifies*=20 the compromised MAG, not how the
> >>> compromised MAG=20 is
> >>>>>> notified that its binding is no = longer=20 valid.  Once the MAG is
> >>>>>> = identified=20 as compromised, a number of remedies may be taken,
>=20 >>>>>> including, simply blacklisting the MAG and = not=20 accepting
> >>>>> PBUs from it.
>=20 >>>>>> It is not critical that the binding be = revoked,=20 because,
> >>>>> the LMA has
>=20 >>>>>> already identified where the MN really is and = it=20 just
> >>>> needs to use
> = >>>>>>=20 that binding for data acceptance/forwarding.
>=20 >>>>>>
> >>>>>>
>=20 >>>>>> The issue of how the LMA identifies a = compromised MAG=20
> cannot be
> >>>>>> tackled without = an=20 independent verification of the
> >>>> presence of=20 the
> >>>>>> MN at that particular = MAG.  So,=20 we need to focus on
> >>>> providing hints
>=20 >>>>>> on how the LMA may go about
>=20 >>>>> achieving that.
> = >>>>>>
>=20 >>>>>> Vidya
> = >>>>>>
>=20 >>>>>>> -----Original Message-----
>=20 >>>>>>> From: Vijay Devarapalli
> = >>>=20 [mailto:vijay.devarapalli@AzaireNet.com]
> = >>>>>>>=20 Sent: Wednesday, September 26, 2007 11:08 AM
>=20 >>>>>>> To: Kilian Weniger
>=20 >>>>>>> Cc: Narayanan, Vidya; = netlmm@ietf.org
>=20 >>>>>>> Subject: Re: Compromised MAG issue (was = [netlmm]=20 Review of
> >>>>>>>=20 draft-ietf-netlmm-proxymip6-05)
> = >>>>>>>
>=20 >>>>>>> Kilian Weniger wrote:
>=20 >>>>>>>> Narayanan, Vidya wrote:
>=20 >>>>>>>>>>> - Security = considerations: MAG=20 Compromise:
> >>>>>>>> ...
>=20 >>>>>>>>> If we claim this is an issue in = the=20 security
> >>>>>>> considerations = section
>=20 >>>>>>>>> and claim that the fix to it is = for the=20 LMA to ensure
> >>>>> the MN is
>=20 >>>>>>>>> actually attached to the MAG, we = can't=20 quite hand
> >>>> wave on some
>=20 >>>>>>>>> possible ways to do=20 that.  Those are just hints for
> = >>>>>>>=20 deployments that
> >>>>>>>>> are = concerned=20 about MAG compromise.  But, those hints
> = >>>>>=20 need to be
> >>>>>>>>> captured in = the=20 security considerations section.
> >>>> The = threats
>=20 >>>>>>>>> document captures this threat and = it is a=20 valid one - so,
> >>>>>>> I believe
> = >>>>>>>>> we need some text = here.  The=20 type of "detail" is what
> >>>>> I tried = to
>=20 >>>>>>>>> provide with the examples on AAA = checks=20 or CGA
> >>>>>> signatures - and, I
>=20 >>>>>>>>> don't think we need a lot of = detail here;=20 a few
> >>>>>> sentences would be
>=20 >>>>>>>>> good.
>=20 >>>>>>>>>
>=20 >>>>>>>>
> = >>>>>>>> I=20 had a similar comment a while ago. I think that a draft
>=20 >>>>>>> describing a
>=20 >>>>>>>> severe security issue should at least = give=20 hints how this
> >>>>>>> can be = solved.
>=20 >>>>>>>>
> = >>>>>>>>=20 Recently Sri, Vijay, Kuntal and I had an offline
> = >>>>>=20 discussion about
> >>>>>>>> another = possible=20 solution to detect a compromised MAGs,
> = >>>>>>>=20 which relies
> >>>>>>>> on PMIP = signaling=20 only.
> >>>>>>>>
>=20 >>>>>>>> The basic idea is that if two MAGs=20 simultaneously claim
> >>>>>>> that the MN=20 is
> >>>>>>>> attached, one of the MAGs = must lie=20 and is probably a
> >>>>>>> compromised=20 MAG.
> >>>>>>>> The assumption is that = the MN=20 cannot at the same time be
> >>>>>>> = attached=20 to
> >>>>>>>> two MAGs, at least not = with the=20 same network interface.
> = >>>>>>>>
>=20 >>>>>>>> More specifically, when the LMA = accepts a=20 valid PBU from a
> >>>>>>> new MAG, = it
>=20 >>>>>>>> changes the BCE (i.e., there is no = impact on=20 handover
> >>>>> delay) and
>=20 >>>>>>>> notifies the old MAG (i.e., old = address in=20 BCE) about
> >>>>>> this. The old
>=20 >>>>>>>> MAG then checks whether the MN is = still=20 attached. If this
> >>>>>>> is the = case,
>=20 >>>>>>>> it informs the LMA about this. The = LMA then=20 learns that two
> >>>>>>> different
> = >>>>>>>> MAGs claim MN attachement, which is = not=20 possible under the
> >>>>>>> = assumption
>=20 >>>>>>>> stated above. Hence, after receiving = one or=20 more such
> >>>>>>> notifications,
>=20 >>>>>>>> the LMA can identify the compromised = MAG and=20 stop
> >>>>>> trusting this MAG.
>=20 >>>>>>>>
> = >>>>>>>> A=20 remaining problem was which message should be used to
>=20 >>>>>>> inform the old
>=20 >>>>>>>> MAG about the BCE change. PBA and = revocation=20 msg were
> >>>>>>> discussed, but
>=20 >>>>>>>> the former is not sent unsolicited = according=20 to RFC3775
> >>>>>>> (which could
>=20 >>>>>>>> be overidden by PMIP spec of course) = and the=20 latter is not
> >>>>>>>> standardized=20 yet.
> >>>>>>>
> = >>>>>>>=20 As I said in another threat, we really need to
> >>>=20 standardize the
> >>>>>>> revocation = message from=20 the LMA to the old MAG ASAP.
> = >>>>>>>
>=20 >>>>>>> Vijay
>=20 >>>>>>>
> >>>>>>
>=20 >>>>>>=20 _______________________________________________
>=20 >>>>>> netlmm mailing list
> = >>>>>>=20 netlmm@ietf.org
> >>>>>> https://www1.ietf.org/mailman/listinfo/netlmm
>= =20 >>>>>>
> >>>>>
>=20 >>>>
> >>>
> >>>
>=20 >>> _______________________________________________
>=20 >>> netlmm mailing list
> >>> = netlmm@ietf.org
>=20 >>> https://www1.ietf.org/mailman/listinfo/netlmm
>= =20 >>>
> >>
> >>
> >>=20 _______________________________________________
> >> = netlmm=20 mailing list
> >> netlmm@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/netlmm
>= =20 >>
> >
> >
> >=20 _______________________________________________
> > netlmm = mailing=20 list
> > netlmm@ietf.org
> > https://www1.ietf.org/mailman/listinfo/netlmm
>= =20 >
> >
>=20


_______________________________________________
netlmm = mailing=20 list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm

------_=_NextPart_001_01C801EE.D5B964B3-- --===============0425291758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm --===============0425291758==-- From netlmm-bounces@ietf.org Fri Sep 28 12:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJ8d-0002L9-8O; Fri, 28 Sep 2007 12:56:27 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbJ8c-0002Jw-04 for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 12:56:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJ8b-00026d-Km for netlmm@ietf.org; Fri, 28 Sep 2007 12:56:25 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbJ8P-0005UM-ON for netlmm@ietf.org; Fri, 28 Sep 2007 12:56:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8SGrdp05401; Fri, 28 Sep 2007 16:53:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 11:56:06 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711709DCE5@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399AF8@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB2/vks+0kQvu4Rt+gKIeCSXJBzQABPUwAAAETAyAAAHXxQAABrrng References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711709DA67@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF8@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Cc: netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org >=20 > > Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]=20 > > Review ofdraft-ietf-netlmm-proxymip6-05) > >=20 > > Hi Sri, Ahmad > >=20 > > I was fine with the original text > > If addressing the security concern is necessary because of IESG or=20 > > whatever and you're going to hint at possible solutions,=20 > then I would=20 > > add as an alternative that the MAG may add a per-MN=20 > signature to the=20 > > PBU. >=20 > [Ahmad] > This also falls under the proposed text.=20 > [FDJ] How does "per-MN signature added by MAG in BU" fall=20 > under the text "by contacting a trusted entity which tracks=20 > the MN current location"? [Ahmad] Federico, I assume that MAG is getting that signature or the material to derive it = from somewhere. Right? In order for the LMA to validate that signature, it needs to get the = needed information from somewhere too. Is there still a problem? That = also does not necessarily means that LMA needs to contact a trusted = entity every time it receives a P-BU for the MN. But all of this are = details that we do not need to go through. > Or I didn't express myself well or I am missing something >=20 > Again, AAA is given as an example nothing else. Let us forget=20 > about the AAA server for a second. >=20 > Apparently you do not have a problem with the proposed text=20 > but with listing AAA as an example. Is that right? > [FDJ] As far as I'm concerned you can list the AAA Server as=20 > an example I give more relevance to the fact that if one=20 > solution is hinted, that we also hint the "per-MN signature" solution [Ahmad] Then why do not we list all possible hints?=20 And if we have to do that, we need to get into the details of all of = these proposed hints. In that case I am afraid that the issue will no = longer become an out-of-scope. Personally, I do not mind removing the AAA server hint and leave the = rest of the text. >=20 > >=20 > > The current proposed alternative: > > > .... by contacting a trusted entity which tracks the MN > > current location, e.g. AAA server. > > it's also fine for me, except that the AAA Server is not a good=20 > > example because it only tracks the NAS (not the user nor the MAG) > >=20 > > One final comment, if the MN can only be attached to one MAG at a=20 > > given time, and if the LMA is going to validate the BU with the AAA=20 > > Server and the AAA server is capable of tracking the=20 > location of the=20 > > MAG ... then do we still need timestamps for message ordering? > > It sems to me that the solution for a "compromised MAG"=20 > > problem and for BU ordering are actually part of the same package,=20 > > since solving the "compormised MAG" problem leads to the=20 > certainty of=20 > > having only 1 MAG serving the user and then a SQN per MAG=20 > and per MN=20 > > is sufficient (no need for context transfer) > >=20 > > Regards > >=20 > > federico > >=20 > >=20 > > -----Message d'origine----- > > De : Sri Gundavelli [mailto:sgundave@cisco.com] Envoy=E9 :=20 > > vendredi 28 septembre 2007 16:29 =C0 : Ahmad Muhanna Cc : DE=20 > JUAN HUARTE=20 > > FEDERICO; netlmm Objet : RE: Text Proposal for Compromised=20 > MAG issue=20 > > (was [netlmm] Review > > ofdraft-ietf-netlmm-proxymip6-05) > >=20 > > Hi Federico, > >=20 > > We need to provide some guidance on how LMA implementations=20 > can esnure=20 > > the presence of a MN at a given MAG in a deterministic fashion. One=20 > > possible way is that the Authentication infrastructure such as AAA=20 > > that generated the keys for the mobile node session would know the=20 > > current point of attachment. The LMA can query the same. > >=20 > > These entire arguments on MAG compromise ..etc, are loosing=20 > > arguments. Unfortunately, we have to agree, there may not be access=20 > > authentication, but, at the same time we have to provide all the=20 > > guidance on how to prevent MAG compromise. > > These are all killer arguments. So, these issues just delay=20 > the work.=20 > > So, lets try to find some text and put a closure to this work. By=20 > > adding a reference to AAA, does not imply, we have mandatory=20 > > requirement on AAA, or we are making AAA stateful. Just any=20 > > reasonable guidance with/without AAA should be fine. > >=20 > > Sri > >=20 > >=20 > >=20 > >=20 > >=20 > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > >=20 > > > Hi Federico, > > > > > > It is very nice to know that we are getting into the beauty > > context.:) > > > > > > Please let us focus on all of the added text: > > > > > > " > > > .... by contacting a trusted entity which tracks the MN > > current location, e.g. AAA server. > > > " > > > > > > If AAA server is not stateful, then deployment may use > > another trusted entity and that is granted by the above text. > > > Originally I am in favor of leaving the whole thing > > out-of-scope all together, but listing AAA server as an=20 > example does=20 > > not eliminate any other security mechanisms nor require that all=20 > > deployment have AAA server as stateful. > > > > > > Do not you agree? > > > > > > Sincerely, If we do not have any serious objection to this > > text, we need to close the issue and move on. > > > Thanks. > > > > > > > > > Regards, > > > Ahmad > > > > > > > > >> -----Original Message----- > > >> From: DE JUAN HUARTE FEDERICO > > >> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] > > >> Sent: Friday, September 28, 2007 4:23 AM > > >> To: Muhanna, Ahmad (RICH1:2H10) > > >> Cc: netlmm > > >> Subject: RE: Text Proposal for Compromised MAG issue=20 > (was [netlmm]=20 > > >> Review ofdraft-ietf-netlmm-proxymip6-05) > > >> > > >> Hi Ahmad, > > >> > > >> in my understanding there's a general motivation to make > > AAA Servers > > >> stateless, so the draft should not put such a strong "tracking" > > >> requirement It is clear to me that in some/many > > deployments the AAA > > >> Server is not stateless anyway, so this is a minor comment > > But then, > > >> what the AAA Server actually tracks is the NAS and not > > really the MAG > > >> Somehow you're assuming that the AAA Server is aware of the=20 > > >> relationship between NASs and MAGs > > >> > > >> With the current text, the security solution was left for > > deployments > > >> to choose With the new text you're trying to close the > > solution space > > >> to one given solution Let's be fair here: > > >> - or the security solution is discussed and we do the beauty=20 > > >> contest with all of them > > >> - or the security solution is not discussed and we leave the=20 > > >> discussion for other contexts > > >> > > >> Regards > > >> > > >> federico > > >> > > >> > > >> > > >> -----Message d'origine----- > > >> De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 : > > >> vendredi 28 septembre 2007 07:37 =C0 : Narayanan, Vidya; Vijay=20 > > >> Devarapalli; Kilian Weniger Cc : netlmm Objet : RE: Text > > Proposal for > > >> Compromised MAG issue (was [netlmm] Review > > >> ofdraft-ietf-netlmm-proxymip6-05) > > >> > > >> > > >> All, > > >> > > >> I sincerely do not want to debate the use of revocation for=20 > > >> compromised MAG at the present time. I am sure that all=20 > of us are=20 > > >> interested in getting this issue addressed properly and have it=20 > > >> closed sooner than later. What about the following text: > > >> > > >> Current text under security consideration: > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> " > > >> To eliminate the threats related to a compromised=20 > mobile access > > >> gateway, this specification recommends that the local=20 > mobility=20 > > >> anchor > > >> before accepting a Proxy Binding Update message for a > > given mobile > > >> node, should ensure the mobile node is definitively > > attached to the > > >> mobile access gateway that sent the binding > > registration request. > > >> " > > >> > > >> New Text: > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D > > >> > > >> " > > >> To eliminate the threats related to a compromised=20 > mobile access > > >> gateway, this specification recommends that the local=20 > mobility=20 > > >> anchor > > >> before accepting a Proxy Binding Update message for a > > given mobile > > >> node, should ensure the mobile node is definitively > > attached to the > > >> mobile access gateway that sent the binding=20 > registration request > > >> by contacting a trusted entity which tracks the MN current=20 > > >> location, > > >> e.g. AAA server. > > >> " > > >> > > >> Regards, > > >> Ahmad > > >> > > >> > > >>> -----Original Message----- > > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > >>> Sent: Wednesday, September 26, 2007 7:41 PM > > >>> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli;=20 > Kilian Weniger > > >>> Cc: netlmm@ietf.org > > >>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > > >>> draft-ietf-netlmm-proxymip6-05) > > >>> > > >>> Hi Ahmad, > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > >>>> Sent: Wednesday, September 26, 2007 4:12 PM > > >>>> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger > > >>>> Cc: netlmm@ietf.org > > >>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > > >>>> draft-ietf-netlmm-proxymip6-05) > > >>>> > > >>>> Hi Vidya, > > >>>> > > >>>> Using revocation for the compromised MAG was proposed by > > >>> Kilian, et. > > >>>> al. > > >>>> but I am trying to help closing the issue so please allow > > >>> me to jump > > >>>> into this debate. > > >>>> > > >>>> In order for the LMA to validate the presence of the MN at > > >>> a specific > > >>>> MAG, the LMA needs to do one of the followings: > > >>>> > > >>>> 1. Validate the MN identity via a MN signature carried in > > >>> the P-BU. In > > >>>> P-MIPv6 this currently is not available since the P-BU is NOT=20 > > >>>> initiated by the MN. (the most obvious option) > > >>>> > > >>>> 2. Validate the MN presence via another trusted entity that > > >>>> *ALWAYS* tracks the MN current location, e.g. AAA server. > > >>>> > > >>>> 3. Validate the MN presence via another trusted entity that > > >>> tracks the > > >>>> current or latest location of the MN, e.g. the previous > > MAG using > > >>>> binding revocation as was suggested by kilian et. al. > > >>>> > > >>> > > >>> The LMA can't assume that the pMAG is trusted while the new > > >> MAG is the > > >> > > >>> one lying. Perhaps the MN really moved and the pMAG=20 > continues to=20 > > >>> claim it is there. Regardless of which MAG tells the LMA > > >> what, 1 or 2 > > >> > > >>> needs to occur to conclude where the MN really is and > > then, the LMA > > >>> can determine which of the MAGs was lying. > > >>> > > >>> Regards, > > >>> Vidya > > >>> > > >>>> 4. may be there are other ways... > > >>>> > > >>>> In case that the MN is still at pMAG and has not moved, the > > >>> pMAG can > > >>>> easily indicate that in the binding revocation acknowledgement. > > >>>> > > >>>> So do not you think that should work? > > >>>> > > >>>> Regards, > > >>>> Ahmad > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > >>>>> Sent: Wednesday, September 26, 2007 3:49 PM > > >>>>> To: Vijay Devarapalli; Kilian Weniger > > >>>>> Cc: netlmm@ietf.org > > >>>>> Subject: RE: Compromised MAG issue (was [netlmm] Review of > > >>>>> draft-ietf-netlmm-proxymip6-05) > > >>>>> > > >>>>> > > >>>>> A few observations here. I don't believe binding revocation > > >>>> is going > > >>>>> to solve anything here. The fundamental issue is how the LMA > > >>>>> *identifies* the compromised MAG, not how the > > >> compromised MAG is > > >>>>> notified that its binding is no longer valid. Once=20 > the MAG is=20 > > >>>>> identified as compromised, a number of remedies may be taken,=20 > > >>>>> including, simply blacklisting the MAG and not accepting > > >>>> PBUs from it. > > >>>>> It is not critical that the binding be revoked, because, > > >>>> the LMA has > > >>>>> already identified where the MN really is and it just > > >>> needs to use > > >>>>> that binding for data acceptance/forwarding. > > >>>>> > > >>>>> > > >>>>> The issue of how the LMA identifies a compromised MAG=20 > cannot be=20 > > >>>>> tackled without an independent verification of the > > >>> presence of the > > >>>>> MN at that particular MAG. So, we need to focus on > > >>> providing hints > > >>>>> on how the LMA may go about > > >>>> achieving that. > > >>>>> > > >>>>> Vidya > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Vijay Devarapalli > > >> [mailto:vijay.devarapalli@AzaireNet.com] > > >>>>>> Sent: Wednesday, September 26, 2007 11:08 AM > > >>>>>> To: Kilian Weniger > > >>>>>> Cc: Narayanan, Vidya; netlmm@ietf.org > > >>>>>> Subject: Re: Compromised MAG issue (was [netlmm] Review of > > >>>>>> draft-ietf-netlmm-proxymip6-05) > > >>>>>> > > >>>>>> Kilian Weniger wrote: > > >>>>>>> Narayanan, Vidya wrote: > > >>>>>>>>>> - Security considerations: MAG Compromise: > > >>>>>>> ... > > >>>>>>>> If we claim this is an issue in the security > > >>>>>> considerations section > > >>>>>>>> and claim that the fix to it is for the LMA to ensure > > >>>> the MN is > > >>>>>>>> actually attached to the MAG, we can't quite hand > > >>> wave on some > > >>>>>>>> possible ways to do that. Those are just hints for > > >>>>>> deployments that > > >>>>>>>> are concerned about MAG compromise. But, those hints > > >>>> need to be > > >>>>>>>> captured in the security considerations section. > > >>> The threats > > >>>>>>>> document captures this threat and it is a valid one - so, > > >>>>>> I believe > > >>>>>>>> we need some text here. The type of "detail" is what > > >>>> I tried to > > >>>>>>>> provide with the examples on AAA checks or CGA > > >>>>> signatures - and, I > > >>>>>>>> don't think we need a lot of detail here; a few > > >>>>> sentences would be > > >>>>>>>> good. > > >>>>>>>> > > >>>>>>> > > >>>>>>> I had a similar comment a while ago. I think that a draft > > >>>>>> describing a > > >>>>>>> severe security issue should at least give hints how this > > >>>>>> can be solved. > > >>>>>>> > > >>>>>>> Recently Sri, Vijay, Kuntal and I had an offline > > >>>> discussion about > > >>>>>>> another possible solution to detect a compromised MAGs, > > >>>>>> which relies > > >>>>>>> on PMIP signaling only. > > >>>>>>> > > >>>>>>> The basic idea is that if two MAGs simultaneously claim > > >>>>>> that the MN is > > >>>>>>> attached, one of the MAGs must lie and is probably a > > >>>>>> compromised MAG. > > >>>>>>> The assumption is that the MN cannot at the same time be > > >>>>>> attached to > > >>>>>>> two MAGs, at least not with the same network interface. > > >>>>>>> > > >>>>>>> More specifically, when the LMA accepts a valid PBU from a > > >>>>>> new MAG, it > > >>>>>>> changes the BCE (i.e., there is no impact on handover > > >>>> delay) and > > >>>>>>> notifies the old MAG (i.e., old address in BCE) about > > >>>>> this. The old > > >>>>>>> MAG then checks whether the MN is still attached. If this > > >>>>>> is the case, > > >>>>>>> it informs the LMA about this. The LMA then learns that two > > >>>>>> different > > >>>>>>> MAGs claim MN attachement, which is not possible under the > > >>>>>> assumption > > >>>>>>> stated above. Hence, after receiving one or more such > > >>>>>> notifications, > > >>>>>>> the LMA can identify the compromised MAG and stop > > >>>>> trusting this MAG. > > >>>>>>> > > >>>>>>> A remaining problem was which message should be used to > > >>>>>> inform the old > > >>>>>>> MAG about the BCE change. PBA and revocation msg were > > >>>>>> discussed, but > > >>>>>>> the former is not sent unsolicited according to RFC3775 > > >>>>>> (which could > > >>>>>>> be overidden by PMIP spec of course) and the latter is not=20 > > >>>>>>> standardized yet. > > >>>>>> > > >>>>>> As I said in another threat, we really need to > > >> standardize the > > >>>>>> revocation message from the LMA to the old MAG ASAP. > > >>>>>> > > >>>>>> Vijay > > >>>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> netlmm mailing list > > >>>>> netlmm@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > > >>>>> > > >>>> > > >>> > > >> > > >> > > >> _______________________________________________ > > >> netlmm mailing list > > >> netlmm@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/netlmm > > >> > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 13:07:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJJa-0006ix-IH; Fri, 28 Sep 2007 13:07:46 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbJJY-0006dV-4K for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 13:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJJX-0006ay-Qz for netlmm@ietf.org; Fri, 28 Sep 2007 13:07:43 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbJJP-0006ug-Lv for netlmm@ietf.org; Fri, 28 Sep 2007 13:07:41 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8SH7AR09329; Fri, 28 Sep 2007 17:07:10 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Fri, 28 Sep 2007 12:07:07 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711709DD1F@zrc2hxm2.corp.nortel.com> In-Reply-To: <319D54578EAC3147BA8CC78DAB5467A501399AF7@FRVELSMBS12.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: Acf/T/RrZEqQFEePT3u9QfI2QIenQAAcXPfQAAcW7+AAGYjB4ABpOoZgAAIIIHA= References: <6FC4416DDE56C44DA0AEE67BC7CA437116F669B2@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FA9BCC@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF7@FRVELSMBS12.ad2.ad.alcatel.com> From: "Ahmad Muhanna" To: "DE JUAN HUARTE FEDERICO" X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Federico, No problem, do you we need to keep this thread open for another 2 weeks = or so :-) Of course SQN is used to map the P-BA to the outstanding P-BU. But there = is a great possibility of collision. In that case we need the NAI. BTW: I thought that we already converged on this very specific one. Cheers. Regards, Ahmad =20 > -----Original Message----- > From: DE JUAN HUARTE FEDERICO=20 > [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr]=20 > Sent: Friday, September 28, 2007 11:36 AM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: netlmm@ietf.org; Narayanan, Vidya > Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 >=20 > Hi Ahmad, >=20 > catching up with this week emails ... > In the use case of SQNs, I presume that it is the SQN itself=20 > that would be used for matching PBU<=3D>PBA Having both the SQN=20 > and the NAI in the PBA seems to me redundant Then, the LMA=20 > doesn't need to add the NAI in any PBA >=20 > Regards >=20 > federico >=20 >=20 > -----Message d'origine----- > De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoy=E9 :=20 > mercredi 26 septembre 2007 15:59 =C0 : Narayanan, Vidya;=20 > netlmm@ietf.org Objet : RE: [netlmm] Review of=20 > draft-ietf-netlmm-proxymip6-05 >=20 > Hi Vidya, >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Tuesday, September 25, 2007 8:38 PM > > To: Muhanna, Ahmad (RICH1:2H10); netlmm@ietf.org > > Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 > >=20 > > Hi Ahmad, > >=20 > > > > - NAI option in the PBA:=20 > > > >=20 > > > > Why is it needed? > > >=20 > > > [Ahmad] > > > There is a very good reason to have NAI in the P-BA. > > >=20 > > > In case that we have SQN used for ordering the P-BU/P-BA, > > there is a > > > great possibility of SQN collision. In this case, MAG needs > > the NAI to > > > match the P-BA to the outstanding P-BU. > > >=20 > >=20 > > Hmmm.. In this case, I can see the use in including the MN=20 > ID in the=20 > > first PBA, but, subsequently, the HNP should be sufficient=20 > to match it=20 > > to the MN in the PBU and PBA, right? >=20 > [Ahmad] > Technically; Yes I agree. >=20 > However, this message is not transmitted over the air, Are we=20 > concerned about the size of the message here? > I guess including NAI in the initial P-BU and not in=20 > re-registration P-BU adds some complexity to the MAG and=20 > probably a lot to the LMA. If there is no real concern about=20 > including the NAI, I would recommend keeping it unless there=20 > a serious advantage in making such recommendation. >=20 >=20 > >=20 > > Vidya > >=20 > > > Regards, > > > Ahmad > > >=20 > > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 13:18:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJU6-0000Mx-1j; Fri, 28 Sep 2007 13:18:38 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbJU4-00008R-9I for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 13:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJU3-00008J-Vs for netlmm@ietf.org; Fri, 28 Sep 2007 13:18:35 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbJTx-0007gr-O3 for netlmm@ietf.org; Fri, 28 Sep 2007 13:18:35 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1190999897!24963672!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11973 invoked from network); 28 Sep 2007 17:18:17 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 28 Sep 2007 17:18:17 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8SHIHCm008200; Fri, 28 Sep 2007 10:18:17 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8SHIGMD025542; Fri, 28 Sep 2007 12:18:17 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8SHIFlR025516; Fri, 28 Sep 2007 12:18:15 -0500 (CDT) Message-ID: <46FD3756.6070302@gmail.com> Date: Fri, 28 Sep 2007 19:18:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ahmad Muhanna Subject: Re: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 References: <6FC4416DDE56C44DA0AEE67BC7CA437116F669B2@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FA9BCC@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF7@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711709DD1F@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711709DD1F@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 000777-1, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -3.1 (---) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Hi Federico, > > No problem, do you we need to keep this thread open for another 2 > weeks or so :-) > > Of course SQN is used to map the P-BA to the outstanding P-BU. But > there is a great possibility of collision. In that case we need the > NAI. > > BTW: I thought that we already converged on this very specific one. > Cheers. Ahmad, I don't converge on PMIP6 using exclusively the NAI to identify the Mobile Node. I think the protocol PMIP6 itself should work ok if it identified the mobile by its IP address; and then use NAI if necessary sometimes in some deployments. But in no case should PMIP6 IMHO use NAI to assign an address to the mobile: we already have many mechanisms for that. Alex > > Regards, Ahmad > > >> -----Original Message----- From: DE JUAN HUARTE FEDERICO >> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] Sent: Friday, >> September 28, 2007 11:36 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: >> netlmm@ietf.org; Narayanan, Vidya Subject: RE: [netlmm] Review of >> draft-ietf-netlmm-proxymip6-05 >> >> Hi Ahmad, >> >> catching up with this week emails ... In the use case of SQNs, I >> presume that it is the SQN itself that would be used for matching >> PBU<=>PBA Having both the SQN and the NAI in the PBA seems to me >> redundant Then, the LMA doesn't need to add the NAI in any PBA >> >> Regards >> >> federico >> >> >> -----Message d'origine----- De : Ahmad Muhanna >> [mailto:amuhanna@nortel.com] Envoyé : mercredi 26 septembre 2007 >> 15:59 À : Narayanan, Vidya; netlmm@ietf.org Objet : RE: [netlmm] >> Review of draft-ietf-netlmm-proxymip6-05 >> >> Hi Vidya, >> >> Regards, Ahmad >> >> >>> -----Original Message----- From: Narayanan, Vidya >>> [mailto:vidyan@qualcomm.com] Sent: Tuesday, September 25, 2007 >>> 8:38 PM To: Muhanna, Ahmad (RICH1:2H10); netlmm@ietf.org Subject: >>> RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 >>> >>> Hi Ahmad, >>> >>>>> - NAI option in the PBA: >>>>> >>>>> Why is it needed? >>>> [Ahmad] There is a very good reason to have NAI in the P-BA. >>>> >>>> In case that we have SQN used for ordering the P-BU/P-BA, >>> there is a >>>> great possibility of SQN collision. In this case, MAG needs >>> the NAI to >>>> match the P-BA to the outstanding P-BU. >>>> >>> Hmmm.. In this case, I can see the use in including the MN >> ID in the >>> first PBA, but, subsequently, the HNP should be sufficient >> to match it >>> to the MN in the PBU and PBA, right? >> [Ahmad] Technically; Yes I agree. >> >> However, this message is not transmitted over the air, Are we >> concerned about the size of the message here? I guess including NAI >> in the initial P-BU and not in re-registration P-BU adds some >> complexity to the MAG and probably a lot to the LMA. If there is no >> real concern about including the NAI, I would recommend keeping it >> unless there a serious advantage in making such recommendation. >> >> >>> Vidya >>> >>>> Regards, Ahmad >>>> >> _______________________________________________ netlmm mailing list >> netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm >> > > > _______________________________________________ netlmm mailing list > netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 13:22:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJXh-0004gz-L0; Fri, 28 Sep 2007 13:22:21 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbJXe-0004dM-G0 for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 13:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJXe-0004aQ-41 for netlmm@ietf.org; Fri, 28 Sep 2007 13:22:18 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbJXY-0007lG-U3 for netlmm@ietf.org; Fri, 28 Sep 2007 13:22:18 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8SHLsF11038; Fri, 28 Sep 2007 17:21:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 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: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Date: Fri, 28 Sep 2007 12:21:53 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711709DD67@zrc2hxm2.corp.nortel.com> In-Reply-To: <46FD3756.6070302@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 Thread-Index: AcgB85YJg29y/97vRyOKLR4IXbhIEQAAA5uA References: <6FC4416DDE56C44DA0AEE67BC7CA437116F669B2@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FA9BCC@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF7@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711709DD1F@zrc2hxm2.corp.nortel.com> <46FD3756.6070302@gmail.com> From: "Ahmad Muhanna" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: DE JUAN HUARTE FEDERICO , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Alex, But that is a different topic. We are talking about the need for NAI in = case of SQN collision. I thought that we converged on that longtime ago. = But what you are saying is something different. Right? Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Friday, September 28, 2007 12:18 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: DE JUAN HUARTE FEDERICO; netlmm@ietf.org > Subject: Re: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 >=20 > Ahmad Muhanna wrote: > > Hi Federico, > >=20 > > No problem, do you we need to keep this thread open for another 2=20 > > weeks or so :-) > >=20 > > Of course SQN is used to map the P-BA to the outstanding P-BU. But=20 > > there is a great possibility of collision. In that case we need the=20 > > NAI. > >=20 > > BTW: I thought that we already converged on this very specific one.=20 > > Cheers. >=20 > Ahmad, I don't converge on PMIP6 using exclusively the NAI to=20 > identify the Mobile Node. I think the protocol PMIP6 itself=20 > should work ok if it identified the mobile by its IP address;=20 > and then use NAI if necessary sometimes in some deployments. =20 > But in no case should PMIP6 IMHO use NAI to assign an address=20 > to the mobile: we already have many mechanisms for that. >=20 > Alex >=20 > >=20 > > Regards, Ahmad > >=20 > >=20 > >> -----Original Message----- From: DE JUAN HUARTE FEDERICO=20 > >> [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] Sent: Friday,=20 > >> September 28, 2007 11:36 AM To: Muhanna, Ahmad (RICH1:2H10) Cc: > >> netlmm@ietf.org; Narayanan, Vidya Subject: RE: [netlmm] Review of > >> draft-ietf-netlmm-proxymip6-05 > >>=20 > >> Hi Ahmad, > >>=20 > >> catching up with this week emails ... In the use case of SQNs, I=20 > >> presume that it is the SQN itself that would be used for matching=20 > >> PBU<=3D>PBA Having both the SQN and the NAI in the PBA seems to me=20 > >> redundant Then, the LMA doesn't need to add the NAI in any PBA > >>=20 > >> Regards > >>=20 > >> federico > >>=20 > >>=20 > >> -----Message d'origine----- De : Ahmad Muhanna=20 > >> [mailto:amuhanna@nortel.com] Envoy=E9 : mercredi 26 septembre 2007 > >> 15:59 =C0 : Narayanan, Vidya; netlmm@ietf.org Objet : RE: [netlmm]=20 > >> Review of draft-ietf-netlmm-proxymip6-05 > >>=20 > >> Hi Vidya, > >>=20 > >> Regards, Ahmad > >>=20 > >>=20 > >>> -----Original Message----- From: Narayanan, Vidya=20 > >>> [mailto:vidyan@qualcomm.com] Sent: Tuesday, September 25, 2007 > >>> 8:38 PM To: Muhanna, Ahmad (RICH1:2H10); netlmm@ietf.org Subject: > >>> RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 > >>>=20 > >>> Hi Ahmad, > >>>=20 > >>>>> - NAI option in the PBA: > >>>>>=20 > >>>>> Why is it needed? > >>>> [Ahmad] There is a very good reason to have NAI in the P-BA. > >>>>=20 > >>>> In case that we have SQN used for ordering the P-BU/P-BA, > >>> there is a > >>>> great possibility of SQN collision. In this case, MAG needs > >>> the NAI to > >>>> match the P-BA to the outstanding P-BU. > >>>>=20 > >>> Hmmm.. In this case, I can see the use in including the MN > >> ID in the > >>> first PBA, but, subsequently, the HNP should be sufficient > >> to match it > >>> to the MN in the PBU and PBA, right? > >> [Ahmad] Technically; Yes I agree. > >>=20 > >> However, this message is not transmitted over the air, Are we=20 > >> concerned about the size of the message here? I guess=20 > including NAI=20 > >> in the initial P-BU and not in re-registration P-BU adds some=20 > >> complexity to the MAG and probably a lot to the LMA. If=20 > there is no=20 > >> real concern about including the NAI, I would recommend keeping it=20 > >> unless there a serious advantage in making such recommendation. > >>=20 > >>=20 > >>> Vidya > >>>=20 > >>>> Regards, Ahmad > >>>>=20 > >> _______________________________________________ netlmm=20 > mailing list =20 > >> netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > >>=20 > >=20 > >=20 > > _______________________________________________ netlmm mailing list=20 > > netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 13:31:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJgJ-00050X-Bc; Fri, 28 Sep 2007 13:31:15 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbJgH-0004qM-PL for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 13:31:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJgH-0004di-EW for netlmm@ietf.org; Fri, 28 Sep 2007 13:31:13 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbJgB-00070f-T2 for netlmm@ietf.org; Fri, 28 Sep 2007 13:31:08 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id EACFA2C020D5E; Fri, 28 Sep 2007 20:31:06 +0300 (EEST) Date: Fri, 28 Sep 2007 20:31:06 +0300 (EEST) From: Wassim Haddad To: Ahmad Muhanna Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com> Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: DE JUAN HUARTE FEDERICO , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > [Ahmad] > So, can I read this that you think it is impossible and does not make sense? => Not at all! Am saying that having the AAA involved to tell the LMA about the MN's whereabouts paves the way to provide other features. >> then you can simply let the LMA updates the MAG (instead of the >> opposite) > but I am willing to listen to your theory in a separate thread! => Yes sure. But let summarize it again in few words: the AAA can tell the LMA where the MN is following a successful authentication, i.e., at a very early stage, which in turn enables the LMA to send a PBU to the MAG and updates it with what the MAG needs to know. In the same PBU, the LMA can include a secret which can be used by the MAG to provide SeND features to the MN without CGA (so you don't need CGA). > [Ahmad] > Just FYI: > 1. A detailed solution for the so called compromised MAG is out-of-scope. => Agree. But from the above you can see that we don't need to create such problem from the beginning and then claim that it is out of scope... > 2. The text hint including the AAA has been proposed several times before > on the ml by different people. => which I also agree with and am trying to strech its impact on other features. Wassim H. _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 13:40:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJoq-0004Fr-A6; Fri, 28 Sep 2007 13:40:04 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbJoo-0004Fb-7S for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 13:40:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJon-0004FR-Sd for netlmm@ietf.org; Fri, 28 Sep 2007 13:40:01 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbJon-0007IB-2f for netlmm@ietf.org; Fri, 28 Sep 2007 13:40:01 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1191001199!19441015!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29761 invoked from network); 28 Sep 2007 17:40:00 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-128.messagelabs.com with SMTP; 28 Sep 2007 17:40:00 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8SHdxf6013831 for ; Fri, 28 Sep 2007 10:39:59 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l8SHdxRB015794 for ; Fri, 28 Sep 2007 12:39:59 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l8SHdwjQ015783 for ; Fri, 28 Sep 2007 12:39:58 -0500 (CDT) Message-ID: <46FD3C6D.2090708@gmail.com> Date: Fri, 28 Sep 2007 19:39:57 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 CC: netlmm@ietf.org Subject: Re: [netlmm] Review of draft-ietf-netlmm-proxymip6-05 References: <6FC4416DDE56C44DA0AEE67BC7CA437116F669B2@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116FA9BCC@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF7@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711709DD1F@zrc2hxm2.corp.nortel.com> <46FD3756.6070302@gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA43711709DD67@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711709DD67@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 000777-1, 26/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: 1.6 (+) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Ahmad Muhanna wrote: > Alex, > > But that is a different topic. We are talking about the need for NAI > in case of SQN collision. I thought that we converged on that > longtime ago. But what you are saying is something different. Right? Right, it is different. When/if there's SQN collision NAI or home address can be able to solve the collision. But to a certain extent we're talking long and wide about NAI and identifiers and this stales the advancement. If we kept PMIP6 without NAI in the basic specification then we'd not even need to converge. Alex > > Regards, Ahmad > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, September 28, >> 2007 12:18 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: DE JUAN HUARTE >> FEDERICO; netlmm@ietf.org Subject: Re: [netlmm] Review of >> draft-ietf-netlmm-proxymip6-05 >> >> Ahmad Muhanna wrote: >>> Hi Federico, >>> >>> No problem, do you we need to keep this thread open for another 2 >>> weeks or so :-) >>> >>> Of course SQN is used to map the P-BA to the outstanding P-BU. >>> But there is a great possibility of collision. In that case we >>> need the NAI. >>> >>> BTW: I thought that we already converged on this very specific >>> one. Cheers. >> Ahmad, I don't converge on PMIP6 using exclusively the NAI to identify the Mobile Node. I think the protocol PMIP6 itself should >> work ok if it identified the mobile by its IP address; and then use >> NAI if necessary sometimes in some deployments. But in no case >> should PMIP6 IMHO use NAI to assign an address to the mobile: we >> already have many mechanisms for that. >> >> Alex >> >>> Regards, Ahmad >>> >>> >>>> -----Original Message----- From: DE JUAN HUARTE FEDERICO [mailto:Federico.De_Juan_Huarte@alcatel-lucent.fr] Sent: >>>> Friday, September 28, 2007 11:36 AM To: Muhanna, Ahmad >>>> (RICH1:2H10) Cc: netlmm@ietf.org; Narayanan, Vidya Subject: RE: >>>> [netlmm] Review of draft-ietf-netlmm-proxymip6-05 >>>> >>>> Hi Ahmad, >>>> >>>> catching up with this week emails ... In the use case of SQNs, >>>> I presume that it is the SQN itself that would be used for >>>> matching PBU<=>PBA Having both the SQN and the NAI in the PBA >>>> seems to me redundant Then, the LMA doesn't need to add the NAI >>>> in any PBA >>>> >>>> Regards >>>> >>>> federico >>>> >>>> >>>> -----Message d'origine----- De : Ahmad Muhanna [mailto:amuhanna@nortel.com] Envoyé : mercredi 26 septembre >>>> 2007 15:59 À : Narayanan, Vidya; netlmm@ietf.org Objet : RE: >>>> [netlmm] Review of draft-ietf-netlmm-proxymip6-05 >>>> >>>> Hi Vidya, >>>> >>>> Regards, Ahmad >>>> >>>> >>>>> -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] Sent: Tuesday, September 25, >>>>> 2007 8:38 PM To: Muhanna, Ahmad (RICH1:2H10); netlmm@ietf.org >>>>> Subject: RE: [netlmm] Review of >>>>> draft-ietf-netlmm-proxymip6-05 >>>>> >>>>> Hi Ahmad, >>>>> >>>>>>> - NAI option in the PBA: >>>>>>> >>>>>>> Why is it needed? >>>>>> [Ahmad] There is a very good reason to have NAI in the >>>>>> P-BA. >>>>>> >>>>>> In case that we have SQN used for ordering the P-BU/P-BA, >>>>> there is a >>>>>> great possibility of SQN collision. In this case, MAG needs >>>>>> >>>>>> >>>>> the NAI to >>>>>> match the P-BA to the outstanding P-BU. >>>>>> >>>>> Hmmm.. In this case, I can see the use in including the MN >>>> ID in the >>>>> first PBA, but, subsequently, the HNP should be sufficient >>>> to match it >>>>> to the MN in the PBU and PBA, right? >>>> [Ahmad] Technically; Yes I agree. >>>> >>>> However, this message is not transmitted over the air, Are we concerned about the size of the message here? I guess >> including NAI >>>> in the initial P-BU and not in re-registration P-BU adds some complexity to the MAG and probably a lot to the LMA. If >> there is no >>>> real concern about including the NAI, I would recommend keeping >>>> it unless there a serious advantage in making such >>>> recommendation. >>>> >>>> >>>>> Vidya >>>>> >>>>>> Regards, Ahmad >>>>>> >>>> _______________________________________________ netlmm >> mailing list >>>> netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm >>>> >>> >>> _______________________________________________ netlmm mailing >>> list netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ >> >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 13:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbK0d-00061C-WD; Fri, 28 Sep 2007 13:52:16 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbK0b-0005wo-DF for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 13:52:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbK0a-0005vI-UN for netlmm@ietf.org; Fri, 28 Sep 2007 13:52:12 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbK0T-0008S5-Nf for netlmm@ietf.org; Fri, 28 Sep 2007 13:52:06 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8SHmnp22805; Fri, 28 Sep 2007 17:48:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 12:51:15 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711709DE18@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB9VyUEAd/bxJDSgONgCCgghhYrwAASyfQ References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com> <319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Wassim Haddad" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: DE JUAN HUARTE FEDERICO , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Wassim, To be honest, the least to be said about all of this compromised MAG discussion/issue is: May be not necessary and probably a lot of time is wasted:-( I am sorry I misunderstood what you were trying to say earlier, But yes, I see it much clearer now. One more comment inline. Cheers:) Regards, Ahmad =20 > -----Original Message----- > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi]=20 > Sent: Friday, September 28, 2007 12:31 PM > To: Muhanna, Ahmad (RICH1:2H10) > Cc: DE JUAN HUARTE FEDERICO; Sri Gundavelli; netlmm > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Ahmad, >=20 > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: >=20 > > [Ahmad] > > So, can I read this that you think it is impossible and=20 > does not make sense? >=20 > =3D> Not at all! Am saying that having the AAA involved to=20 > tell the LMA about the MN's whereabouts paves the way to=20 > provide other features. >=20 > >> then you can simply let the LMA updates the MAG (instead of the > >> opposite) >=20 > > but I am willing to listen to your theory in a separate thread! >=20 > =3D> Yes sure. But let summarize it again in few words: > the AAA can tell the LMA where the MN is following a=20 > successful authentication, i.e., at a very early stage, which=20 > in turn enables the LMA to send a PBU to the MAG and updates=20 > it with what the MAG needs to know. [Ahmad] Very interesting! >=20 > In the same PBU, the LMA can include a secret which can be=20 > used by the MAG to provide SeND features to the MN without=20 > CGA (so you don't need CGA). >=20 > > [Ahmad] > > Just FYI: > > 1. A detailed solution for the so called compromised MAG is=20 > out-of-scope. >=20 > =3D> Agree. But from the above you can see that we don't need=20 > to create such problem from the beginning and then claim that=20 > it is out of scope... >=20 > > 2. The text hint including the AAA has been proposed several times=20 > > before on the ml by different people. >=20 > =3D> which I also agree with and am trying to strech its impact=20 > on other features. >=20 >=20 > Wassim H. >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 17:02:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbMxx-0003DS-9A; Fri, 28 Sep 2007 17:01:41 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbMxv-0003DM-FY for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 17:01:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbMxv-00030u-2j for netlmm@ietf.org; Fri, 28 Sep 2007 17:01:39 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbMxp-0006Yt-8V for netlmm@ietf.org; Fri, 28 Sep 2007 17:01:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 1C5D3A8098 for ; Fri, 28 Sep 2007 17:01:27 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07402-09 for ; Fri, 28 Sep 2007 17:01:25 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 28 Sep 2007 17:01:25 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 16:59:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 16:57:31 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26663FC4FA@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgB2hUdvbTtGdHSTqmQpprklkoYOwAC8wCAAAqjm+A= From: "Chowdhury, Kuntal" To: "Genadi Velev" , "Sri Gundavelli" , X-OriginalArrivalTime: 28 Sep 2007 20:59:44.0293 (UTC) FILETIME=[7EF85550:01C80212] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: ext Kilian Weniger X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Dear All, I don't think any of these options make sense. Requiring the MN to associate different MN-IDs over different interfaces means we are imposing new requirements on the MN which we tried to avoid, IMHO. Also, we cannot prevent the MN to attempt network access over more than one interface.=20 I do not believe that there will be any issue if the MN attempts to use more than one interface. In the particular example given before, if the MN chooses to use interface 2, everything will be good. If the MN chooses to use interface 1, there are ways to recover from a momentary glitch. However, I think we should stay out of this level of detail to describe an out-of-scope topic (multi-homing) in the base spec. I like Behcet's proposal to state that: support for multi-homing is out of scope of the document. This is simple and precise. BR, Kuntal =20 > -----Original Message----- > From: Genadi Velev [mailto:Genadi.Velev@eu.panasonic.com] > Sent: Friday, September 28, 2007 10:59 AM > To: Sri Gundavelli > Cc: ext Kilian Weniger; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Hi Sri, >=20 > it seems that we converge on this issue :-) >=20 > I was also agnostic on any of the initial options 1-4. Of course the > simplest way to go forward is to describe options 1 and 2. The operator > can choose between not allowing multiple interfaces to be simultaneously > attached (option 1) or to support multiple interfaces to be attached but > assuring that different MN-ID is assigned to each interface. >=20 > Option 3 still needs to be worked out in > draft-muhanna-mip6-binding-revocation-01, as discussed by Kilian and > Vijay. So, we can leave it out for the base PMIP specification. >=20 > Genadi >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Friday, September 28, 2007 4:15 PM > > To: Genadi Velev > > Cc: Narayanan, Vidya; ext Kilian Weniger; netlmm@ietf.org > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > > > Hi Genadi, > > > > Please see inline. > > > > > > On Fri, 28 Sep 2007, Genadi Velev wrote: > > > > > > > I can think about several approaches to overcome this issue: > > > 1) we can specify that the network operator shall take care of > > > preventing that a MN attaches with 2 interfaces to a PMIP domain (at > > > least to the same LMA). For example, the operator doesn't allow > > > attachment (i.e. authorization) of interface 2, since interface 1 is > > > still attached. > > > > > > > 2) we can write a short text in the draft that the network operator > > > shall take care about assignment of different MN-ID (NAI) > > to different > > > interfaces during attachment procedure. > > > > > 3) we can describe how the current protocol behaves when a > > MN attempts > > > to attach with two interfaces. Similar to what is explained > > in Vijay's > > > email: > > > http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html > > > > I'm ok with any of the above three options. We can certainly document > > the scenario and close the issue. I do no think, we should try to > > solve this problem here or use this issue to explicitly add text to > > block the inter-access handoff, we did not do any thing to > > support that > > scenario. When the charter says, its out of scope, we dont > > need to solve > > all the issues, when the scenario is enabled. Operators can solve this > > issue, these are managed deployments. Its not a like a > > consumer buying a > > device and turning it on at home. So, I agree with your above three > > suggested options. > > > > Regards > > Sri > > > > > > > > >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 17:15:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNB3-0007An-2u; Fri, 28 Sep 2007 17:15:13 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbNB1-00077U-M8 for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 17:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNB1-00077I-C0 for netlmm@ietf.org; Fri, 28 Sep 2007 17:15:11 -0400 Received: from mailx01.tmomail.net ([66.94.9.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbNAu-0005yI-Un for netlmm@ietf.org; Fri, 28 Sep 2007 17:15:11 -0400 Received: from [127.0.0.1] (112.0.240.10.in-addr.arpa [10.240.0.112]) by mailx01.tmomail.net (8.14.1/8.12.11) with ESMTP id l8SLE6jh005500; Fri, 28 Sep 2007 14:14:18 -0700 Message-ID: <46FD6EA4.5000305@azairenet.com> Date: Fri, 28 Sep 2007 14:14:12 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8D80@lan-ex-02.panasonic.de><002a01c800a9$edd8f1b0$1220fea9@amer.cisco.com> <1FEB9B9F2EC38343955D02B2AE86AACB4F8DF4@lan-ex-02.panasonic.de> <008a01c8010f$c8234130$1220fea9@amer.cisco.com> <00ba01c8012b$84300460$1220fea9@amer.cisco.com> <00c201c8012f$2dabe5b0$1220fea9@amer.cisco.com> <4F633DFC-3181-42E0-B284-4B1DC732F1BB@gmail.com> In-Reply-To: <4F633DFC-3181-42E0-B284-4B1DC732F1BB@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0708230000 definitions=main-0709280051 X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: 'ext Kilian Weniger' , netlmm@ietf.org, 'Genadi Velev' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org RYUJI WAKIKAWA wrote: > Hi Sri > > On 2007/09/28, at 2:52, Sri Gundavelli wrote: > >> Vidya, >> >> We are not dealing with >>> multi-interface support issues in this thread. What we are >>> dealing with >>> is the fact that an MN may not be able to use *any* interface simply >>> because it happens to have two interfaces. >> >> If we are not dealing with multi-interface support, we dont >> need to talk about the scenario where the MN has multiple active >> interfaces. This is not the right interpretation of the charter, >> IMHO. >> >> If operators want to deal with this, let them configure a unique >> NAI for each interface and even when multiple interfaces are >> active, each interface will endup with a unique prefix. > > I think this is one way to avoid this multi-interface issue. > You can mention in the doc that MN should have different NAI per interfaces > if it has multiple interfaces attached to the PMIP domain. In a practical deployment there is typically just one identity for the user with all the subscription information stored against this identity. Vijay > > regards, > ryuji > >> >> Sri >> >> >> >>> -----Original Message----- >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>> Sent: Thursday, September 27, 2007 10:32 AM >>> To: Sri Gundavelli; Genadi Velev >>> Cc: ext Kilian Weniger; netlmm@ietf.org >>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >>> >>> Sri, >>> You seem to be missing the point. We are not dealing with >>> multi-interface support issues in this thread. What we are >>> dealing with >>> is the fact that an MN may not be able to use *any* interface simply >>> because it happens to have two interfaces. Unless the MN >>> knows that the >>> network is using PMIP and hence, it can only use one interface at a >>> time, you are going to have regular IP nodes that run into >>> this problem. >>> >>> >>> In a nutshell, the problem is about an MN ending up with no IP service >>> using even one of its interfaces. >>> >>> I hope you can see that the problem doesn't relate to providing >>> multihoming to the MN; rather it relates to something far more >>> fundamental that this protocol is supposed to ensure - IP connectivity >>> to the MN. >>> >>> Vidya >>> >>>> -----Original Message----- >>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>> Sent: Thursday, September 27, 2007 10:26 AM >>>> To: Narayanan, Vidya; 'Genadi Velev' >>>> Cc: 'ext Kilian Weniger'; netlmm@ietf.org >>>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >>>> >>>> Hi Vidya, >>>> >>>> >>>> That's interesting. We dont allow inter-interface handoff, >>>> but we want to deal with multi-interface support issues ? >>>> We dont have to do any thing for supporting the former and >>>> the later requires some work. >>>> >>>> The charter also does not talk about multi-homing and I >>>> wonder if our decision to deal with this issue, is the right >>>> one. We may need some clarification from Jari on this. >>>> >>>> IMO, if we really think, this breaks the protocol, operator >>>> has the tools to deal with this. If a deployment has to >>>> support multi-homing, there are number of things that have to >>>> be place, including accounting system and other things. The >>>> operator has the knobs to control this aspect, it can be >>>> avoided in many different ways. >>>> >>>> Not sure, what other solution we have. >>>> >>>> Sri >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>>>> Sent: Thursday, September 27, 2007 10:10 AM >>>>> To: Sri Gundavelli; Genadi Velev >>>>> Cc: ext Kilian Weniger; netlmm@ietf.org >>>>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >>>>> >>>>> Hi Sri, >>>>> I hope this is not news to anyone, but, we are not >>>> chartered to solve >>>>> inter-interface handoffs in the WG at the moment. This >>> is what our >>>>> charter states: >>>>> >>>>> "The protocol will not attempt to hide handover between two >>>> separate >>>>> interfaces on the mobile node. " >>>>> >>>>> Inter-technology handoffs being a tricky problem to handle >>>> with NETLMM >>>>> was identified in the early stages of charter creation. >>>> So, that is >>>>> not a limitation for considering some interface-specific >>>> identity to >>>>> be included in the PBU. >>>>> >>>>> Hope that helps. >>>>> >>>>> Regards, >>>>> Vidya >>>>> >>>>>> -----Original Message----- >>>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>>>> Sent: Thursday, September 27, 2007 7:08 AM >>>>>> To: 'Genadi Velev'; Narayanan, Vidya >>>>>> Cc: 'ext Kilian Weniger'; netlmm@ietf.org >>>>>> Subject: RE: [netlmm] Issue: Prefix allocation and >>> multihomed MNs >>>>>> >>>>>> Hi Genadi, >>>>>> >>>>>>> >>>>>>> If we look at the available options in PBU/PBA, we can see >>>>>> that next >>>>>>> to "NAI Option" (or "MN-ID option") we have a >>>> "Link-local Address >>>>>>> Option". >>>>>>> Supposed that the link-local addresses of the multiple >>>>>> interfaces are >>>>>>> different, an LMA can differentiate among PBUs having the >>>>>> same MN-ID >>>>>>> option looking at the Link-local Address Option. IMHO, what >>>>>> we need to >>>>>>> specify in the PMIPv6 protocol is a behaviour in the LMA >>>>>> that the HNP >>>>>>> is not solely bound to a MN-ID but also to the link-local >>>>>> address. In >>>>>>> this way different HNPs would be assigned to PBUs >>> (coming from >>>>>>> different >>>>>>> MAGs) containing same MN-ID option but different >>>>> link-local address >>>>>>> options. >>>>>> >>>>>> But, we need to allow handoff between two different >>>> interfaces (of >>>>>> different access technologies), if we keep a relation to >>>> the LLA, we >>>>>> cant do handoff. This scenario is more important than the >>>> scenario >>>>>> of simultaneous multi-access. >>>>>> >>>>>> Sri >>>>>> >>>>>> >>>> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 17:17:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbND0-0002U6-S2; Fri, 28 Sep 2007 17:17:14 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbND0-0002Ml-5Q for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 17:17:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNCz-0002LG-PW for netlmm@ietf.org; Fri, 28 Sep 2007 17:17:13 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbNCy-0007eX-SI for netlmm@ietf.org; Fri, 28 Sep 2007 17:17:13 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8SLGndK012224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2007 14:16:49 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8SLGmvu017839; Fri, 28 Sep 2007 14:16:49 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 14:16:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 14:16:47 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgB2hUdvbTtGdHSTqmQpprklkoYOwAC8wCAAAINLVcACWIVMA== References: <1FEB9B9F2EC38343955D02B2AE86AACB4F8EE7@lan-ex-02.panasonic.de> From: "Narayanan, Vidya" To: "Basavaraj Patil" , "ext Genadi Velev" , "Sri Gundavelli" X-OriginalArrivalTime: 28 Sep 2007 21:16:48.0735 (UTC) FILETIME=[E195C6F0:01C80214] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Thanks, Raj, for capturing the questions :) Just catching up with all the emails, these are exactly the questions I arrived at as well. These are important questions to answer. Some thoughts inline. =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, September 28, 2007 9:39 AM > To: ext Genadi Velev; Sri Gundavelli > Cc: ext Kilian Weniger; netlmm@ietf.org > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 >=20 > I don't know if we have really converged ;) >=20 > Two questions:=20 > 1. How can you prevent a device from attaching via multiple=20 > interfaces simultaneously? Are you suggesting that within the=20 > scope of a PMIP6 domain, you could potentially verify (at AAA=20 > level or some such thing) if an MN is already attached via=20 > another interface and hence prevent it from attaching via the=20 > second interface? >=20 I think the above is very tricky and it is also quite difficult to detect the difference between movement and a second interface in practical scenarios. For instance, not all systems go back to the AAA upon every attachment (even assuming a AAA-enabled system, which itself is not a constraint for PMIPv6). So, the state that a AAA has may only be as broad as which administrative domain the MN is presently at, not exactly at which MAG. Going down that path seems difficult to me. Several AAA functions, including accounting, may be aggregated at some middle point in the network, which further makes this detection difficult.=20 > 2. How do you ensure that variable MN-IDs are used depending=20 > on the interface used by the host to attach to a network? >=20 If we left the MN-ID to be anything (e.g., an NAI), I don't believe we can ensure this. This is exactly identical to the DHCP analogy made earlier in this thread by Federico. When a DHCP client wishes to acquire a routable IP address on multiple interfaces, it uses a different client ID for each interface. This situation is not different, except that the network is trying to automatically obtain an address for the MN. So, I think we are back to having an interface-specific ID as the MN-ID. =20 > An MN which attaches via different interfaces simultaneously=20 > to a PMIP6 domain will result in the LMA having a BCE for the=20 > last received PBU. Host behavior when multiple interfaces=20 > have the same address is unspecified and we can just leave it=20 > at that. In the context of this document, we do not need to solve it. >=20 I don't get this part though. Given that there isn't a practical way for the network to determine if the MN is attaching to multiple MAGs or just one (I can imagine somewhat more complicated ways of figuring that out with additional help from the lower layers, but, we can't rely on that), if we left it unsolved, that just means that an MN which happens to have multiple interfaces may suffer lack of IP connectivity or toggling/intermittent connectivity. So, I think we do need to state that the MN-ID used must be interface-specific. How a system ensures that the ID used is interface-specific doesn't need to be mandated.=20 Vidya > -Raj >=20 >=20 > On 9/28/07 10:59 AM, "ext Genadi Velev"=20 > > wrote: >=20 > > Hi Sri, > >=20 > > it seems that we converge on this issue :-) > >=20 > > I was also agnostic on any of the initial options 1-4. Of=20 > course the=20 > > simplest way to go forward is to describe options 1 and 2. The=20 > > operator can choose between not allowing multiple interfaces to be=20 > > simultaneously attached (option 1) or to support multiple=20 > interfaces=20 > > to be attached but assuring that different MN-ID is=20 > assigned to each interface. > >=20 > > Option 3 still needs to be worked out in=20 > > draft-muhanna-mip6-binding-revocation-01, as discussed by=20 > Kilian and=20 > > Vijay. So, we can leave it out for the base PMIP specification. > >=20 > > Genadi > >=20 > >> -----Original Message----- > >> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >> Sent: Friday, September 28, 2007 4:15 PM > >> To: Genadi Velev > >> Cc: Narayanan, Vidya; ext Kilian Weniger; netlmm@ietf.org > >> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > >>=20 > >> Hi Genadi, > >>=20 > >> Please see inline. > >>=20 > >>=20 > >> On Fri, 28 Sep 2007, Genadi Velev wrote: > >>=20 > >>=20 > >>> I can think about several approaches to overcome this issue: > >>> 1) we can specify that the network operator shall take care of=20 > >>> preventing that a MN attaches with 2 interfaces to a PMIP=20 > domain (at=20 > >>> least to the same LMA). For example, the operator doesn't allow=20 > >>> attachment (i.e. authorization) of interface 2, since=20 > interface 1 is=20 > >>> still attached. > >>=20 > >>=20 > >>> 2) we can write a short text in the draft that the=20 > network operator=20 > >>> shall take care about assignment of different MN-ID (NAI) > >> to different > >>> interfaces during attachment procedure. > >>=20 > >>> 3) we can describe how the current protocol behaves when a > >> MN attempts > >>> to attach with two interfaces. Similar to what is explained > >> in Vijay's > >>> email: > >>> http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html > >>=20 > >> I'm ok with any of the above three options. We can=20 > certainly document=20 > >> the scenario and close the issue. I do no think, we should try to=20 > >> solve this problem here or use this issue to explicitly=20 > add text to=20 > >> block the inter-access handoff, we did not do any thing to support=20 > >> that scenario. When the charter says, its out of scope, we=20 > dont need=20 > >> to solve all the issues, when the scenario is enabled.=20 > Operators can=20 > >> solve this issue, these are managed deployments. Its not a like a=20 > >> consumer buying a device and turning it on at home. So, I=20 > agree with=20 > >> your above three suggested options. > >>=20 > >> Regards > >> Sri > >>=20 > >>=20 > >>=20 > >>=20 > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 17:18:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNEV-0005UC-MA; Fri, 28 Sep 2007 17:18:47 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbNEU-0005U2-OX for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 17:18:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNEU-0005Tq-Eh for netlmm@ietf.org; Fri, 28 Sep 2007 17:18:46 -0400 Received: from mailx03.tmomail.net ([66.94.9.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbNEO-0006La-4u for netlmm@ietf.org; Fri, 28 Sep 2007 17:18:46 -0400 Received: from [127.0.0.1] (112.0.240.10.in-addr.arpa [10.240.0.112]) by mailx03.tmomail.net (8.14.1/8.12.11) with ESMTP id l8SLHvqc024586; Fri, 28 Sep 2007 14:18:10 -0700 Message-ID: <46FD6F86.4000600@azairenet.com> Date: Fri, 28 Sep 2007 14:17:58 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=3.1.0-0708230000 definitions=main-0709280051 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ext Kilian Weniger , netlmm@ietf.org, ext Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Using two different identifiers on two different interfaces is a non-starter. The MN might just not have two different identifiers to use. Vijay Basavaraj Patil wrote: > I don't know if we have really converged ;) > > Two questions: > 1. How can you prevent a device from attaching via multiple interfaces > simultaneously? Are you suggesting that within the scope of a PMIP6 domain, > you could potentially verify (at AAA level or some such thing) if an MN is > already attached via another interface and hence prevent it from attaching > via the second interface? > > 2. How do you ensure that variable MN-IDs are used depending on the > interface used by the host to attach to a network? > > An MN which attaches via different interfaces simultaneously to a PMIP6 > domain will result in the LMA having a BCE for the last received PBU. Host > behavior when multiple interfaces have the same address is unspecified and > we can just leave it at that. In the context of this document, we do not > need to solve it. > > -Raj > > > On 9/28/07 10:59 AM, "ext Genadi Velev" > wrote: > >> Hi Sri, >> >> it seems that we converge on this issue :-) >> >> I was also agnostic on any of the initial options 1-4. Of course the >> simplest way to go forward is to describe options 1 and 2. The operator >> can choose between not allowing multiple interfaces to be simultaneously >> attached (option 1) or to support multiple interfaces to be attached but >> assuring that different MN-ID is assigned to each interface. >> >> Option 3 still needs to be worked out in >> draft-muhanna-mip6-binding-revocation-01, as discussed by Kilian and >> Vijay. So, we can leave it out for the base PMIP specification. >> >> Genadi >> >>> -----Original Message----- >>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>> Sent: Friday, September 28, 2007 4:15 PM >>> To: Genadi Velev >>> Cc: Narayanan, Vidya; ext Kilian Weniger; netlmm@ietf.org >>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >>> >>> Hi Genadi, >>> >>> Please see inline. >>> >>> >>> On Fri, 28 Sep 2007, Genadi Velev wrote: >>> >>> >>>> I can think about several approaches to overcome this issue: >>>> 1) we can specify that the network operator shall take care of >>>> preventing that a MN attaches with 2 interfaces to a PMIP domain (at >>>> least to the same LMA). For example, the operator doesn't allow >>>> attachment (i.e. authorization) of interface 2, since interface 1 is >>>> still attached. >>> >>>> 2) we can write a short text in the draft that the network operator >>>> shall take care about assignment of different MN-ID (NAI) >>> to different >>>> interfaces during attachment procedure. >>>> 3) we can describe how the current protocol behaves when a >>> MN attempts >>>> to attach with two interfaces. Similar to what is explained >>> in Vijay's >>>> email: >>>> http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html >>> I'm ok with any of the above three options. We can certainly document >>> the scenario and close the issue. I do no think, we should try to >>> solve this problem here or use this issue to explicitly add text to >>> block the inter-access handoff, we did not do any thing to >>> support that >>> scenario. When the charter says, its out of scope, we dont >>> need to solve >>> all the issues, when the scenario is enabled. Operators can solve this >>> issue, these are managed deployments. Its not a like a >>> consumer buying a >>> device and turning it on at home. So, I agree with your above three >>> suggested options. >>> >>> Regards >>> Sri >>> >>> >>> >>> >> >> Panasonic R&D Center Germany GmbH >> 63225 Langen, Hessen, Germany >> Reg: AG Offenbach (Hessen) HRB 33974 >> Managing Director: Thomas Micke >> >> >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 17:38:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNXo-0008Sa-KO; Fri, 28 Sep 2007 17:38:44 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbNXn-0008RP-CA for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 17:38:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNXn-0008QX-0s for netlmm@ietf.org; Fri, 28 Sep 2007 17:38:43 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbNXm-00008X-LE for netlmm@ietf.org; Fri, 28 Sep 2007 17:38:42 -0400 X-IronPort-AV: E=Sophos;i="4.21,211,1188802800"; d="scan'208";a="178188966" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2007 14:38:42 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8SLcg2s026561; Fri, 28 Sep 2007 14:38:42 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8SLcfTn003169; Fri, 28 Sep 2007 21:38:41 GMT Date: Fri, 28 Sep 2007 14:38:41 -0700 (PDT) From: Sri Gundavelli To: "Chowdhury, Kuntal" Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs In-Reply-To: <4D35478224365146822AE9E3AD4A26663FC4FA$0001@exchtewks3.starentnetworks.com> Message-ID: References: <4D35478224365146822AE9E3AD4A26663FC4FA$0001@exchtewks3.starentnetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1591; t=1191015522; x=1191879522; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20; bh=WXDfwtWbTCd+aECS6ECjbsHKNdmTI8AiUanVFD+MIH4=; b=YnVI5QX7MtOkQNMpBVt4omSfFSg4/7eMaSNeNrTMkXxLT7sltIG0U4yV0Pj1RIAjjTuh52hm YKIule8UBRBdpu6ZqTxWdM6nCFx8R5kAP+qhDHBh4NjH2ZCozrO7VXgT; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ext Kilian Weniger , netlmm@ietf.org, Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kuntal, On Fri, 28 Sep 2007, Chowdhury, Kuntal wrote: > Dear All, > > I don't think any of these options make sense. Requiring the MN to > associate different MN-IDs over different interfaces means we are > imposing new requirements on the MN which we tried to avoid, IMHO. Also, > we cannot prevent the MN to attempt network access over more than one > interface. > > I do not believe that there will be any issue if the MN attempts to use > more than one interface. In the particular example given before, if the > MN chooses to use interface 2, everything will be good. If the MN > chooses to use interface 1, there are ways to recover from a momentary > glitch. However, I think we should stay out of this level of detail to > describe an out-of-scope topic (multi-homing) in the base spec. > > I like Behcet's proposal to state that: support for multi-homing is out > of scope of the document. This is simple and precise. I agree and I've been saying this is out-of-scope. I do not want this argument to lead to a solution with some explicit restrictions on inter-access handoffs (which comes naturally with the current spec). If the text suggested by Genadi leads to any such restrictions, which I did not analyze in detail, I'll not be in favour of this. My point is, we dont go into the details for some thing that is out of scope. Just have a note that there may be glitch, when multiple interfaces are active in a single domain and leave it there. If every one agrees on this, we can suggest some text on this and close this issue. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 18:12:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbO4X-00013G-Jz; Fri, 28 Sep 2007 18:12:33 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbO4W-00013B-If for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 18:12:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbO4W-00012p-91 for netlmm@ietf.org; Fri, 28 Sep 2007 18:12:32 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbO4O-0007V8-B5 for netlmm@ietf.org; Fri, 28 Sep 2007 18:12:29 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 8CA39A817B for ; Fri, 28 Sep 2007 18:11:59 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06654-18 for ; Fri, 28 Sep 2007 18:11:58 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 28 Sep 2007 18:11:58 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 18:11:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 18:11:32 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26663FC4FD@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgCF/Q05tXmU6gmSZCYtQqBXYMxCgABDueg From: "Chowdhury, Kuntal" To: "Sri Gundavelli" X-OriginalArrivalTime: 28 Sep 2007 22:11:28.0165 (UTC) FILETIME=[84471550:01C8021C] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ext Kilian Weniger , netlmm@ietf.org, Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri, If we just add a note to say that: support for multi-homing is out of scope of the document, it should suffice. This topic is out of scope, and we should close this thread and move on. BR, Kuntal > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, September 28, 2007 4:39 PM > To: Chowdhury, Kuntal > Cc: Genadi Velev; netlmm@ietf.org; ext Kilian Weniger > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Hi Kuntal, >=20 >=20 > On Fri, 28 Sep 2007, Chowdhury, Kuntal wrote: >=20 > > Dear All, > > > > I don't think any of these options make sense. Requiring the MN to > > associate different MN-IDs over different interfaces means we are > > imposing new requirements on the MN which we tried to avoid, IMHO. Also, > > we cannot prevent the MN to attempt network access over more than one > > interface. > > > > I do not believe that there will be any issue if the MN attempts to use > > more than one interface. In the particular example given before, if the > > MN chooses to use interface 2, everything will be good. If the MN > > chooses to use interface 1, there are ways to recover from a momentary > > glitch. However, I think we should stay out of this level of detail to > > describe an out-of-scope topic (multi-homing) in the base spec. > > > > I like Behcet's proposal to state that: support for multi-homing is out > > of scope of the document. This is simple and precise. >=20 > I agree and I've been saying this is out-of-scope. I do not want > this argument to lead to a solution with some explicit restrictions > on inter-access handoffs (which comes naturally with the current > spec). If the text suggested by Genadi leads to any such restrictions, > which I did not analyze in detail, I'll not be in favour of this. My > point is, we dont go into the details for some thing that is out of > scope. Just have a note that there may be glitch, when multiple > interfaces are active in a single domain and leave it there. >=20 > If every one agrees on this, we can suggest some text on this and > close this issue. >=20 > Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 18:22:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbODm-00007O-Qr; Fri, 28 Sep 2007 18:22:06 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbODk-0008Ny-FR for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 18:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbODj-0008IN-9f for netlmm@ietf.org; Fri, 28 Sep 2007 18:22:03 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbODd-0007gL-0v for netlmm@ietf.org; Fri, 28 Sep 2007 18:22:03 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8SMLHGO006295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2007 15:21:18 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8SMLH0X000823; Fri, 28 Sep 2007 15:21:17 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 15:21:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 15:21:16 -0700 Message-ID: In-Reply-To: <46FD6F86.4000600@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgCFuB0NHIXeq05SDyd38t7x9cndgABtpXw References: <46FD6F86.4000600@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Basavaraj Patil" X-OriginalArrivalTime: 28 Sep 2007 22:21:17.0054 (UTC) FILETIME=[E34869E0:01C8021D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: ext Kilian Weniger , netlmm@ietf.org, ext Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org We are just talking about equivalents of link-layer IDs here. The MN will have a different link ID on each of its interfaces. Actually, the MN here has to do nothing. The MAG needs to pick up an interface specific identity for the MN - e.g., use its MAC address or something equivalent.=20 Vidya=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Friday, September 28, 2007 2:18 PM > To: Basavaraj Patil > Cc: ext Kilian Weniger; netlmm@ietf.org; ext Genadi Velev > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Using two different identifiers on two different interfaces=20 > is a non-starter. The MN might just not have two different=20 > identifiers to use. >=20 > Vijay >=20 > Basavaraj Patil wrote: > > I don't know if we have really converged ;) > >=20 > > Two questions:=20 > > 1. How can you prevent a device from attaching via multiple=20 > interfaces=20 > > simultaneously? Are you suggesting that within the scope of a PMIP6=20 > > domain, you could potentially verify (at AAA level or some=20 > such thing)=20 > > if an MN is already attached via another interface and=20 > hence prevent=20 > > it from attaching via the second interface? > >=20 > > 2. How do you ensure that variable MN-IDs are used depending on the=20 > > interface used by the host to attach to a network? > >=20 > > An MN which attaches via different interfaces simultaneously to a=20 > > PMIP6 domain will result in the LMA having a BCE for the=20 > last received=20 > > PBU. Host behavior when multiple interfaces have the same=20 > address is=20 > > unspecified and we can just leave it at that. In the=20 > context of this=20 > > document, we do not need to solve it. > >=20 > > -Raj > >=20 > >=20 > > On 9/28/07 10:59 AM, "ext Genadi Velev"=20 > > > > wrote: > >=20 > >> Hi Sri, > >> > >> it seems that we converge on this issue :-) > >> > >> I was also agnostic on any of the initial options 1-4. Of=20 > course the=20 > >> simplest way to go forward is to describe options 1 and 2. The=20 > >> operator can choose between not allowing multiple interfaces to be=20 > >> simultaneously attached (option 1) or to support multiple=20 > interfaces=20 > >> to be attached but assuring that different MN-ID is=20 > assigned to each interface. > >> > >> Option 3 still needs to be worked out in=20 > >> draft-muhanna-mip6-binding-revocation-01, as discussed by=20 > Kilian and=20 > >> Vijay. So, we can leave it out for the base PMIP specification. > >> > >> Genadi > >> > >>> -----Original Message----- > >>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >>> Sent: Friday, September 28, 2007 4:15 PM > >>> To: Genadi Velev > >>> Cc: Narayanan, Vidya; ext Kilian Weniger; netlmm@ietf.org > >>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > >>> > >>> Hi Genadi, > >>> > >>> Please see inline. > >>> > >>> > >>> On Fri, 28 Sep 2007, Genadi Velev wrote: > >>> > >>> > >>>> I can think about several approaches to overcome this issue: > >>>> 1) we can specify that the network operator shall take care of=20 > >>>> preventing that a MN attaches with 2 interfaces to a PMIP domain=20 > >>>> (at least to the same LMA). For example, the operator=20 > doesn't allow=20 > >>>> attachment (i.e. authorization) of interface 2, since=20 > interface 1=20 > >>>> is still attached. > >>> > >>>> 2) we can write a short text in the draft that the=20 > network operator=20 > >>>> shall take care about assignment of different MN-ID (NAI) > >>> to different > >>>> interfaces during attachment procedure. > >>>> 3) we can describe how the current protocol behaves when a > >>> MN attempts > >>>> to attach with two interfaces. Similar to what is explained > >>> in Vijay's > >>>> email: > >>>>=20 > http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html > >>> I'm ok with any of the above three options. We can certainly=20 > >>> document the scenario and close the issue. I do no think,=20 > we should=20 > >>> try to solve this problem here or use this issue to=20 > explicitly add=20 > >>> text to block the inter-access handoff, we did not do any=20 > thing to=20 > >>> support that scenario. When the charter says, its out of=20 > scope, we=20 > >>> dont need to solve all the issues, when the scenario is enabled.=20 > >>> Operators can solve this issue, these are managed=20 > deployments. Its=20 > >>> not a like a consumer buying a device and turning it on=20 > at home. So,=20 > >>> I agree with your above three suggested options. > >>> > >>> Regards > >>> Sri > >>> > >>> > >>> > >>> > >> > >> Panasonic R&D Center Germany GmbH > >> 63225 Langen, Hessen, Germany > >> Reg: AG Offenbach (Hessen) HRB 33974 > >> Managing Director: Thomas Micke > >> > >> > >> > >> > >> _______________________________________________ > >> netlmm mailing list > >> netlmm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/netlmm > >=20 > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 18:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbOLT-0008Nu-SY; Fri, 28 Sep 2007 18:30:03 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbOLS-0008L7-8R for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 18:30:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbOLR-0008Kz-V2 for netlmm@ietf.org; Fri, 28 Sep 2007 18:30:01 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbOLQ-0007xe-NN for netlmm@ietf.org; Fri, 28 Sep 2007 18:30:01 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 74791A812F for ; Fri, 28 Sep 2007 18:29:52 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07767-19 for ; Fri, 28 Sep 2007 18:29:51 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 28 Sep 2007 18:29:51 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 18:29:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 18:29:25 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26663FC4FE@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgCFuB0NHIXeq05SDyd38t7x9cndgABtpXwAAAwMfA= From: "Chowdhury, Kuntal" To: "Narayanan, Vidya" X-OriginalArrivalTime: 28 Sep 2007 22:29:44.0523 (UTC) FILETIME=[11C209B0:01C8021F] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: ext Kilian Weniger , netlmm@ietf.org, ext Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Link IDs are not guaranteed to be unique and constant per interface if the MN does not have MAC addresses. There are access technologies out there (e.g. HRPD) where MN's link Id is not even known by the AR. I agree with Vijay. Assuming interface specific MN-ID or embedding Link ID in PBU is a non-starter. -Kuntal > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Friday, September 28, 2007 5:21 PM > To: Vijay Devarapalli; Basavaraj Patil > Cc: ext Kilian Weniger; netlmm@ietf.org; ext Genadi Velev > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > We are just talking about equivalents of link-layer IDs here. The MN > will have a different link ID on each of its interfaces. Actually, the > MN here has to do nothing. The MAG needs to pick up an interface > specific identity for the MN - e.g., use its MAC address or something > equivalent. >=20 > Vidya >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Friday, September 28, 2007 2:18 PM > > To: Basavaraj Patil > > Cc: ext Kilian Weniger; netlmm@ietf.org; ext Genadi Velev > > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > > > > Using two different identifiers on two different interfaces > > is a non-starter. The MN might just not have two different > > identifiers to use. > > > > Vijay > > > > Basavaraj Patil wrote: > > > I don't know if we have really converged ;) > > > > > > Two questions: > > > 1. How can you prevent a device from attaching via multiple > > interfaces > > > simultaneously? Are you suggesting that within the scope of a PMIP6 > > > domain, you could potentially verify (at AAA level or some > > such thing) > > > if an MN is already attached via another interface and > > hence prevent > > > it from attaching via the second interface? > > > > > > 2. How do you ensure that variable MN-IDs are used depending on the > > > interface used by the host to attach to a network? > > > > > > An MN which attaches via different interfaces simultaneously to a > > > PMIP6 domain will result in the LMA having a BCE for the > > last received > > > PBU. Host behavior when multiple interfaces have the same > > address is > > > unspecified and we can just leave it at that. In the > > context of this > > > document, we do not need to solve it. > > > > > > -Raj > > > > > > > > > On 9/28/07 10:59 AM, "ext Genadi Velev" > > > > > > wrote: > > > > > >> Hi Sri, > > >> > > >> it seems that we converge on this issue :-) > > >> > > >> I was also agnostic on any of the initial options 1-4. Of > > course the > > >> simplest way to go forward is to describe options 1 and 2. The > > >> operator can choose between not allowing multiple interfaces to be > > >> simultaneously attached (option 1) or to support multiple > > interfaces > > >> to be attached but assuring that different MN-ID is > > assigned to each interface. > > >> > > >> Option 3 still needs to be worked out in > > >> draft-muhanna-mip6-binding-revocation-01, as discussed by > > Kilian and > > >> Vijay. So, we can leave it out for the base PMIP specification. > > >> > > >> Genadi > > >> > > >>> -----Original Message----- > > >>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > > >>> Sent: Friday, September 28, 2007 4:15 PM > > >>> To: Genadi Velev > > >>> Cc: Narayanan, Vidya; ext Kilian Weniger; netlmm@ietf.org > > >>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > >>> > > >>> Hi Genadi, > > >>> > > >>> Please see inline. > > >>> > > >>> > > >>> On Fri, 28 Sep 2007, Genadi Velev wrote: > > >>> > > >>> > > >>>> I can think about several approaches to overcome this issue: > > >>>> 1) we can specify that the network operator shall take care of > > >>>> preventing that a MN attaches with 2 interfaces to a PMIP domain > > >>>> (at least to the same LMA). For example, the operator > > doesn't allow > > >>>> attachment (i.e. authorization) of interface 2, since > > interface 1 > > >>>> is still attached. > > >>> > > >>>> 2) we can write a short text in the draft that the > > network operator > > >>>> shall take care about assignment of different MN-ID (NAI) > > >>> to different > > >>>> interfaces during attachment procedure. > > >>>> 3) we can describe how the current protocol behaves when a > > >>> MN attempts > > >>>> to attach with two interfaces. Similar to what is explained > > >>> in Vijay's > > >>>> email: > > >>>> > > http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html > > >>> I'm ok with any of the above three options. We can certainly > > >>> document the scenario and close the issue. I do no think, > > we should > > >>> try to solve this problem here or use this issue to > > explicitly add > > >>> text to block the inter-access handoff, we did not do any > > thing to > > >>> support that scenario. When the charter says, its out of > > scope, we > > >>> dont need to solve all the issues, when the scenario is enabled. > > >>> Operators can solve this issue, these are managed > > deployments. Its > > >>> not a like a consumer buying a device and turning it on > > at home. So, > > >>> I agree with your above three suggested options. > > >>> > > >>> Regards > > >>> Sri > > >>> > > >>> > > >>> > > >>> > > >> > > >> Panasonic R&D Center Germany GmbH > > >> 63225 Langen, Hessen, Germany > > >> Reg: AG Offenbach (Hessen) HRB 33974 > > >> Managing Director: Thomas Micke > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> netlmm mailing list > > >> netlmm@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 19:09:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbOws-0002mz-N7; Fri, 28 Sep 2007 19:08:42 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbOwr-0002mJ-LM for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 19:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbOwr-0002hf-BM for netlmm@ietf.org; Fri, 28 Sep 2007 19:08:41 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IbOwW-0000NI-UY for netlmm@ietf.org; Fri, 28 Sep 2007 19:08:22 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1191020879!24989129!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19018 invoked from network); 28 Sep 2007 23:07:59 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 28 Sep 2007 23:07:59 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l8SN7x8r027943; Fri, 28 Sep 2007 16:07:59 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l8SN7wqa026321; Fri, 28 Sep 2007 18:07:59 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-144.corp.mot.com [10.169.4.144]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l8SN7tIB026300; Fri, 28 Sep 2007 18:07:56 -0500 (CDT) Message-ID: <46FD894A.8000000@gmail.com> Date: Sat, 29 Sep 2007 01:07:54 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: <4D35478224365146822AE9E3AD4A26663FC4FE@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26663FC4FE@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000777-2, 28/09/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: ext Kilian Weniger , netlmm@ietf.org, ext Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Chowdhury, Kuntal wrote: > Link IDs are not guaranteed to be unique and constant per interface > if the MN does not have MAC addresses. There are access technologies > out there (e.g. HRPD) where MN's link Id is not even known by the AR. I agree, this is right. > I agree with Vijay. Assuming interface specific MN-ID or embedding > Link ID in PBU is a non-starter. As presented it sounds non-starter to me too (two NAIs for one MN). Because NAI is for user, not for interface. And couldn't we just keep all this NAI and identifier issue out of the base spec? Imagine PMIP6 basic just goes about IP addresses. Imagine the AAA or DHCP does all address assignment based on NAI, MAC address, Subscriber-ID, CGA SeND Public Key and any other identifier that is not an IP address. What's so far-fetched about this? Not only MN-Id looks as overspecification, but its entire use in PMIP6 sounds as overspecification to me. Alex > > -Kuntal > > >> -----Original Message----- From: Narayanan, Vidya >> [mailto:vidyan@qualcomm.com] Sent: Friday, September 28, 2007 5:21 >> PM To: Vijay Devarapalli; Basavaraj Patil Cc: ext Kilian Weniger; >> netlmm@ietf.org; ext Genadi Velev Subject: RE: [netlmm] Issue: >> Prefix allocation and multihomed MNs >> >> We are just talking about equivalents of link-layer IDs here. The >> MN will have a different link ID on each of its interfaces. >> Actually, > the >> MN here has to do nothing. The MAG needs to pick up an interface >> specific identity for the MN - e.g., use its MAC address or >> something equivalent. >> >> Vidya >> >>> -----Original Message----- From: Vijay Devarapalli >>> [mailto:vijay.devarapalli@azairenet.com] Sent: Friday, September >>> 28, 2007 2:18 PM To: Basavaraj Patil Cc: ext Kilian Weniger; >>> netlmm@ietf.org; ext Genadi Velev Subject: Re: [netlmm] Issue: >>> Prefix allocation and multihomed MNs >>> >>> Using two different identifiers on two different interfaces is a >>> non-starter. The MN might just not have two different identifiers >>> to use. >>> >>> Vijay >>> >>> Basavaraj Patil wrote: >>>> I don't know if we have really converged ;) >>>> >>>> Two questions: 1. How can you prevent a device from attaching >>>> via multiple >>> interfaces >>>> simultaneously? Are you suggesting that within the scope of a > PMIP6 >>>> domain, you could potentially verify (at AAA level or some >>> such thing) >>>> if an MN is already attached via another interface and >>> hence prevent >>>> it from attaching via the second interface? >>>> >>>> 2. How do you ensure that variable MN-IDs are used depending on >>>> > the >>>> interface used by the host to attach to a network? >>>> >>>> An MN which attaches via different interfaces simultaneously to >>>> a PMIP6 domain will result in the LMA having a BCE for the >>> last received >>>> PBU. Host behavior when multiple interfaces have the same >>> address is >>>> unspecified and we can just leave it at that. In the >>> context of this >>>> document, we do not need to solve it. >>>> >>>> -Raj >>>> >>>> >>>> On 9/28/07 10:59 AM, "ext Genadi Velev" >>>> wrote: >>>> >>>>> Hi Sri, >>>>> >>>>> it seems that we converge on this issue :-) >>>>> >>>>> I was also agnostic on any of the initial options 1-4. Of >>> course the >>>>> simplest way to go forward is to describe options 1 and 2. >>>>> The operator can choose between not allowing multiple >>>>> interfaces to > be >>>>> simultaneously attached (option 1) or to support multiple >>> interfaces >>>>> to be attached but assuring that different MN-ID is >>> assigned to each interface. >>>>> Option 3 still needs to be worked out in >>>>> draft-muhanna-mip6-binding-revocation-01, as discussed by >>> Kilian and >>>>> Vijay. So, we can leave it out for the base PMIP >>>>> specification. >>>>> >>>>> Genadi >>>>> >>>>>> -----Original Message----- From: Sri Gundavelli >>>>>> [mailto:sgundave@cisco.com] Sent: Friday, September 28, >>>>>> 2007 4:15 PM To: Genadi Velev Cc: Narayanan, Vidya; ext >>>>>> Kilian Weniger; netlmm@ietf.org Subject: RE: [netlmm] >>>>>> Issue: Prefix allocation and multihomed > MNs >>>>>> Hi Genadi, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> >>>>>> On Fri, 28 Sep 2007, Genadi Velev wrote: >>>>>> >>>>>> >>>>>>> I can think about several approaches to overcome this >>>>>>> issue: 1) we can specify that the network operator shall >>>>>>> take care of preventing that a MN attaches with 2 >>>>>>> interfaces to a PMIP > domain >>>>>>> (at least to the same LMA). For example, the operator >>> doesn't allow >>>>>>> attachment (i.e. authorization) of interface 2, since >>> interface 1 >>>>>>> is still attached. 2) we can write a short text in the >>>>>>> draft that the >>> network operator >>>>>>> shall take care about assignment of different MN-ID (NAI) >>>>>>> >>>>>> to different >>>>>>> interfaces during attachment procedure. 3) we can >>>>>>> describe how the current protocol behaves when a >>>>>> MN attempts >>>>>>> to attach with two interfaces. Similar to what is >>>>>>> explained >>>>>> in Vijay's >>>>>>> email: >>>>>>> >>> http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html >>> >>>>>> I'm ok with any of the above three options. We can >>>>>> certainly document the scenario and close the issue. I do >>>>>> no think, >>> we should >>>>>> try to solve this problem here or use this issue to >>> explicitly add >>>>>> text to block the inter-access handoff, we did not do any >>> thing to >>>>>> support that scenario. When the charter says, its out of >>> scope, we >>>>>> dont need to solve all the issues, when the scenario is >>>>>> enabled. Operators can solve this issue, these are managed >>> deployments. Its >>>>>> not a like a consumer buying a device and turning it on >>> at home. So, >>>>>> I agree with your above three suggested options. >>>>>> >>>>>> Regards Sri >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Panasonic R&D Center Germany GmbH 63225 Langen, Hessen, >>>>> Germany Reg: AG Offenbach (Hessen) HRB 33974 Managing >>>>> Director: Thomas Micke >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ netlmm >>>>> mailing list netlmm@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>> >>>> >>>> _______________________________________________ netlmm mailing >>>> list netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >>> >>> >>> _______________________________________________ netlmm mailing >>> list netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >> >> _______________________________________________ netlmm mailing list >> netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > > > _______________________________________________ netlmm mailing list > netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 19:23:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbPBC-0007ut-03; Fri, 28 Sep 2007 19:23:30 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbPBA-0007un-VB for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 19:23:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbPBA-0007mM-LK for netlmm@ietf.org; Fri, 28 Sep 2007 19:23:28 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbPB0-0000dV-Ct for netlmm@ietf.org; Fri, 28 Sep 2007 19:23:24 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8SNMmvA024917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2007 16:22:49 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8SNMj1e015082; Fri, 28 Sep 2007 16:22:48 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 16:22:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 16:22:45 -0700 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A26663FC4FD@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgCF/Q05tXmU6gmSZCYtQqBXYMxCgABDuegAAIWYAA= References: <4D35478224365146822AE9E3AD4A26663FC4FD@exchtewks3.starentnetworks.com> From: "Narayanan, Vidya" To: "Chowdhury, Kuntal" , "Sri Gundavelli" X-OriginalArrivalTime: 28 Sep 2007 23:22:46.0369 (UTC) FILETIME=[7A493510:01C80226] X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ext Kilian Weniger , netlmm@ietf.org, Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Folks, It is not helping to keep insisting that stating multi-homing is out of scope is sufficient. The situation at hand is really the following and let's own up to it:=20 "This protocol, as currently specified, may result in unpredictable, intermittent or no IP connectivity to a device that is multihomed, over any of its interfaces."=20 This doesn't just mean multi-homing is not supported; it means that a unmodified multi-homed IP device can't have stable IP access.=20 If all this protocol is doing is providing IP connectivity over only one interface of a multi-homed device, we won't be having this conversation. I don't believe we can call this document done given the situation at hand. So, please work towards solving the issue, rather than repeatedly claiming it is out of scope.=20 Thanks, Vidya > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Friday, September 28, 2007 3:12 PM > To: Sri Gundavelli > Cc: ext Kilian Weniger; netlmm@ietf.org; Genadi Velev > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Sri, >=20 > If we just add a note to say that: support for multi-homing=20 > is out of scope of the document, it should suffice. >=20 > This topic is out of scope, and we should close this thread=20 > and move on. >=20 > BR, > Kuntal >=20 >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Friday, September 28, 2007 4:39 PM > > To: Chowdhury, Kuntal > > Cc: Genadi Velev; netlmm@ietf.org; ext Kilian Weniger > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > >=20 > > Hi Kuntal, > >=20 > >=20 > > On Fri, 28 Sep 2007, Chowdhury, Kuntal wrote: > >=20 > > > Dear All, > > > > > > I don't think any of these options make sense. Requiring=20 > the MN to=20 > > > associate different MN-IDs over different interfaces means we are=20 > > > imposing new requirements on the MN which we tried to avoid, IMHO. > Also, > > > we cannot prevent the MN to attempt network access over more than > one > > > interface. > > > > > > I do not believe that there will be any issue if the MN=20 > attempts to > use > > > more than one interface. In the particular example given=20 > before, if > the > > > MN chooses to use interface 2, everything will be good. If the MN=20 > > > chooses to use interface 1, there are ways to recover from a > momentary > > > glitch. However, I think we should stay out of this level=20 > of detail > to > > > describe an out-of-scope topic (multi-homing) in the base spec. > > > > > > I like Behcet's proposal to state that: support for=20 > multi-homing is > out > > > of scope of the document. This is simple and precise. > >=20 > > I agree and I've been saying this is out-of-scope. I do not=20 > want this=20 > > argument to lead to a solution with some explicit restrictions on=20 > > inter-access handoffs (which comes naturally with the=20 > current spec).=20 > > If the text suggested by Genadi leads to any such=20 > restrictions, which=20 > > I did not analyze in detail, I'll not be in favour of this.=20 > My point=20 > > is, we dont go into the details for some thing that is out=20 > of scope.=20 > > Just have a note that there may be glitch, when multiple interfaces=20 > > are active in a single domain and leave it there. > >=20 > > If every one agrees on this, we can suggest some text on this and=20 > > close this issue. > >=20 > > Sri >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 20:04:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbPnq-00063X-0z; Fri, 28 Sep 2007 20:03:26 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbPnp-00063R-1c for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 20:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbPno-00063J-O5 for netlmm@ietf.org; Fri, 28 Sep 2007 20:03:24 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbPni-0001Hl-Fd for netlmm@ietf.org; Fri, 28 Sep 2007 20:03:24 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8T031TP015493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2007 17:03:02 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8T030EV006751; Fri, 28 Sep 2007 17:03:00 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 17:03:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm] Reviewofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 17:02:59 -0700 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711709DE18@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm] Reviewofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB9VyUEAd/bxJDSgONgCCgghhYrwAASyfQAA0qlEA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711709DE18@zrc2hxm2.corp.nortel.com> From: "Narayanan, Vidya" To: "Ahmad Muhanna" , "Wassim Haddad" X-OriginalArrivalTime: 29 Sep 2007 00:03:00.0020 (UTC) FILETIME=[18EF1F40:01C8022C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: DE JUAN HUARTE FEDERICO , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org All, The text proposed by Ahmad mostly looks fine to me, although it may be worthwhile providing a hint for how one may do it in a non-AAA based system. How about the following (I've taken Ahmad's text and made some minor changes/additions):=20 "To deal with threats related to a compromised mobile access gateway, the local mobility anchor, before accepting a Proxy Binding Update message for a given mobile node, may choose to ensure that the mobile node is definitively attached to the mobile access gateway that sent the binding registration request. This may be done by contacting a trusted entity which tracks the MN current point of attachment, e.g. a AAA server (as a result of an authentication exchange with the MN). This may also be accomplished by verification of a live signature from the MN, e.g., a CGA signature. Details of how such verification of the MN's point of attachment is done is outside the scope of this specification."=20 I've tried to stay away from any normative language in the text, indicating that we are merely providing examples.=20 Thanks, Vidya > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Friday, September 28, 2007 10:51 AM > To: Wassim Haddad > Cc: DE JUAN HUARTE FEDERICO; netlmm > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm] Reviewofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Wassim, >=20 > To be honest, the least to be said about all of this=20 > compromised MAG discussion/issue is: May be not necessary and=20 > probably a lot of time is wasted:-( I am sorry I=20 > misunderstood what you were trying to say earlier, But yes, I=20 > see it much clearer now. >=20 > One more comment inline. >=20 > Cheers:) >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > > Sent: Friday, September 28, 2007 12:31 PM > > To: Muhanna, Ahmad (RICH1:2H10) > > Cc: DE JUAN HUARTE FEDERICO; Sri Gundavelli; netlmm > > Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]=20 > > Review ofdraft-ietf-netlmm-proxymip6-05) > >=20 > > Hi Ahmad, > >=20 > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > >=20 > > > [Ahmad] > > > So, can I read this that you think it is impossible and > > does not make sense? > >=20 > > =3D> Not at all! Am saying that having the AAA involved to=20 > tell the LMA=20 > > about the MN's whereabouts paves the way to provide other features. > >=20 > > >> then you can simply let the LMA updates the MAG (instead of the > > >> opposite) > >=20 > > > but I am willing to listen to your theory in a separate thread! > >=20 > > =3D> Yes sure. But let summarize it again in few words: > > the AAA can tell the LMA where the MN is following a successful=20 > > authentication, i.e., at a very early stage, which in turn=20 > enables the=20 > > LMA to send a PBU to the MAG and updates it with what the=20 > MAG needs to=20 > > know. >=20 > [Ahmad] > Very interesting! >=20 > >=20 > > In the same PBU, the LMA can include a secret which can be=20 > used by the=20 > > MAG to provide SeND features to the MN without CGA (so you=20 > don't need=20 > > CGA). > >=20 > > > [Ahmad] > > > Just FYI: > > > 1. A detailed solution for the so called compromised MAG is > > out-of-scope. > >=20 > > =3D> Agree. But from the above you can see that we don't need=20 > to create=20 > > such problem from the beginning and then claim that it is out of=20 > > scope... > >=20 > > > 2. The text hint including the AAA has been proposed=20 > several times=20 > > > before on the ml by different people. > >=20 > > =3D> which I also agree with and am trying to strech its=20 > impact on other=20 > > features. > >=20 > >=20 > > Wassim H. > >=20 >=20 >=20 > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 21:47:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbRQP-00063R-HY; Fri, 28 Sep 2007 21:47:21 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbRQO-00062N-B0 for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 21:47:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbRQO-00062F-1N for netlmm@ietf.org; Fri, 28 Sep 2007 21:47:20 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbRQM-0002rl-LA for netlmm@ietf.org; Fri, 28 Sep 2007 21:47:20 -0400 X-IronPort-AV: E=Sophos;i="4.21,211,1188802800"; d="scan'208";a="227373797" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2007 18:47:18 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8T1lI7s001228; Fri, 28 Sep 2007 18:47:18 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8T1ko1r029565; Sat, 29 Sep 2007 01:47:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 21:47:06 -0400 Received: from sgundavewxp ([10.32.246.213]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 21:47:05 -0400 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" , "'Ahmad Muhanna'" , "'Wassim Haddad'" References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DE18@zrc2hxm2.corp.nortel.com> Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) Date: Fri, 28 Sep 2007 18:46:46 -0700 Message-ID: <027601c8023a$a6bb9890$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgB9VyUEAd/bxJDSgONgCCgghhYrwAASyfQAA0qlEAAA5FRAA== X-OriginalArrivalTime: 29 Sep 2007 01:47:06.0045 (UTC) FILETIME=[A3DAE6D0:01C8023A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5180; t=1191030438; x=1191894438; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20Text=20Proposal=20for=20Compromised=20MAG=20issue=20( was=20[netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) |Sender:=20; bh=7UGoAad2VIi2QRiOf3/EdqWd9qJ1NtGF1LRJJT2zXUo=; b=zFgMQn1AH+J603ItRybfthr4fhZsvMXIU7hShMbeR/dwX4IPw60hbi6d4Zqtfs8k6hLxhrMb SdMmGNazwtTfhaKBMT387FQTw/Eq67snQMP0X+JtruuzWdkNMGyXjsp3; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: 'DE JUAN HUARTE FEDERICO' , 'netlmm' X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org It looks fine, except for the CGA part. The CGA generation requires the IPv6 subnet prefix and that the mobile node in a Proxy Mobile IPv6 domain would not have it before the signaling is complete. So, the mobile node would not be able to assert the address ownership or infact even generate an address until the MAG completes the signaling. This may work for subsequent registrations, but not during initial attachment in Proxy Mobile IPv6 domain. So, I suggest taking out the CGA part and close this issue. Thanks Ahmad for the text. Sri > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Friday, September 28, 2007 5:03 PM > To: Ahmad Muhanna; Wassim Haddad > Cc: DE JUAN HUARTE FEDERICO; netlmm > Subject: RE: Text Proposal for Compromised MAG issue (was > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > > All, > The text proposed by Ahmad mostly looks fine to me, although it may be > worthwhile providing a hint for how one may do it in a non-AAA based > system. How about the following (I've taken Ahmad's text and > made some > minor changes/additions): > > "To deal with threats related to a compromised mobile access gateway, > the local mobility anchor, before accepting a Proxy Binding Update > message for a given mobile node, may choose to ensure that the mobile > node is definitively attached to the mobile access gateway that sent > the binding registration request. This may be done by contacting a > trusted entity which tracks the MN current point of attachment, e.g. a > AAA server (as a result of an authentication exchange with the MN). > This may also be accomplished by verification of a live signature from > the MN, e.g., a CGA signature. Details of how such > verification of the > MN's point of attachment is done is outside the scope of this > specification." > > I've tried to stay away from any normative language in the text, > indicating that we are merely providing examples. > > Thanks, > Vidya > > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Friday, September 28, 2007 10:51 AM > > To: Wassim Haddad > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > Subject: RE: Text Proposal for Compromised MAG issue (was > > [netlmm] Reviewofdraft-ietf-netlmm-proxymip6-05) > > > > Hi Wassim, > > > > To be honest, the least to be said about all of this > > compromised MAG discussion/issue is: May be not necessary and > > probably a lot of time is wasted:-( I am sorry I > > misunderstood what you were trying to say earlier, But yes, I > > see it much clearer now. > > > > One more comment inline. > > > > Cheers:) > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > > > Sent: Friday, September 28, 2007 12:31 PM > > > To: Muhanna, Ahmad (RICH1:2H10) > > > Cc: DE JUAN HUARTE FEDERICO; Sri Gundavelli; netlmm > > > Subject: RE: Text Proposal for Compromised MAG issue (was > [netlmm] > > > Review ofdraft-ietf-netlmm-proxymip6-05) > > > > > > Hi Ahmad, > > > > > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > > > > > > > [Ahmad] > > > > So, can I read this that you think it is impossible and > > > does not make sense? > > > > > > => Not at all! Am saying that having the AAA involved to > > tell the LMA > > > about the MN's whereabouts paves the way to provide other > features. > > > > > > >> then you can simply let the LMA updates the MAG (instead of the > > > >> opposite) > > > > > > > but I am willing to listen to your theory in a separate thread! > > > > > > => Yes sure. But let summarize it again in few words: > > > the AAA can tell the LMA where the MN is following a successful > > > authentication, i.e., at a very early stage, which in turn > > enables the > > > LMA to send a PBU to the MAG and updates it with what the > > MAG needs to > > > know. > > > > [Ahmad] > > Very interesting! > > > > > > > > In the same PBU, the LMA can include a secret which can be > > used by the > > > MAG to provide SeND features to the MN without CGA (so you > > don't need > > > CGA). > > > > > > > [Ahmad] > > > > Just FYI: > > > > 1. A detailed solution for the so called compromised MAG is > > > out-of-scope. > > > > > > => Agree. But from the above you can see that we don't need > > to create > > > such problem from the beginning and then claim that it is out of > > > scope... > > > > > > > 2. The text hint including the AAA has been proposed > > several times > > > > before on the ml by different people. > > > > > > => which I also agree with and am trying to strech its > > impact on other > > > features. > > > > > > > > > Wassim H. > > > > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 23:18:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbSpu-0000Tg-HX; Fri, 28 Sep 2007 23:17:46 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbSpt-0000TP-8f for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 23:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbSps-0000SS-UK for netlmm@ietf.org; Fri, 28 Sep 2007 23:17:44 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbSpg-000492-V1 for netlmm@ietf.org; Fri, 28 Sep 2007 23:17:44 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 20:17:31 -0700 Message-ID: <46FDC3CA.7060302@azairenet.com> Date: Fri, 28 Sep 2007 20:17:30 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs References: <46FD6F86.4000600@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2007 03:17:32.0245 (UTC) FILETIME=[461F5050:01C80247] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: ext Kilian Weniger , netlmm@ietf.org, ext Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Narayanan, Vidya wrote: > We are just talking about equivalents of link-layer IDs here. The MN > will have a different link ID on each of its interfaces. Actually, the > MN here has to do nothing. The MAG needs to pick up an interface > specific identity for the MN - e.g., use its MAC address or something > equivalent. How do you ensure it is unique? What if there is no no equivalent to the MAC address? Sorry, the MN-ID must remain unique across the PMIPv6 domain. Vijay > > Vidya > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Friday, September 28, 2007 2:18 PM >> To: Basavaraj Patil >> Cc: ext Kilian Weniger; netlmm@ietf.org; ext Genadi Velev >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >> >> Using two different identifiers on two different interfaces >> is a non-starter. The MN might just not have two different >> identifiers to use. >> >> Vijay >> >> Basavaraj Patil wrote: >>> I don't know if we have really converged ;) >>> >>> Two questions: >>> 1. How can you prevent a device from attaching via multiple >> interfaces >>> simultaneously? Are you suggesting that within the scope of a PMIP6 >>> domain, you could potentially verify (at AAA level or some >> such thing) >>> if an MN is already attached via another interface and >> hence prevent >>> it from attaching via the second interface? >>> >>> 2. How do you ensure that variable MN-IDs are used depending on the >>> interface used by the host to attach to a network? >>> >>> An MN which attaches via different interfaces simultaneously to a >>> PMIP6 domain will result in the LMA having a BCE for the >> last received >>> PBU. Host behavior when multiple interfaces have the same >> address is >>> unspecified and we can just leave it at that. In the >> context of this >>> document, we do not need to solve it. >>> >>> -Raj >>> >>> >>> On 9/28/07 10:59 AM, "ext Genadi Velev" >>> >>> wrote: >>> >>>> Hi Sri, >>>> >>>> it seems that we converge on this issue :-) >>>> >>>> I was also agnostic on any of the initial options 1-4. Of >> course the >>>> simplest way to go forward is to describe options 1 and 2. The >>>> operator can choose between not allowing multiple interfaces to be >>>> simultaneously attached (option 1) or to support multiple >> interfaces >>>> to be attached but assuring that different MN-ID is >> assigned to each interface. >>>> Option 3 still needs to be worked out in >>>> draft-muhanna-mip6-binding-revocation-01, as discussed by >> Kilian and >>>> Vijay. So, we can leave it out for the base PMIP specification. >>>> >>>> Genadi >>>> >>>>> -----Original Message----- >>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] >>>>> Sent: Friday, September 28, 2007 4:15 PM >>>>> To: Genadi Velev >>>>> Cc: Narayanan, Vidya; ext Kilian Weniger; netlmm@ietf.org >>>>> Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >>>>> >>>>> Hi Genadi, >>>>> >>>>> Please see inline. >>>>> >>>>> >>>>> On Fri, 28 Sep 2007, Genadi Velev wrote: >>>>> >>>>> >>>>>> I can think about several approaches to overcome this issue: >>>>>> 1) we can specify that the network operator shall take care of >>>>>> preventing that a MN attaches with 2 interfaces to a PMIP domain >>>>>> (at least to the same LMA). For example, the operator >> doesn't allow >>>>>> attachment (i.e. authorization) of interface 2, since >> interface 1 >>>>>> is still attached. >>>>>> 2) we can write a short text in the draft that the >> network operator >>>>>> shall take care about assignment of different MN-ID (NAI) >>>>> to different >>>>>> interfaces during attachment procedure. >>>>>> 3) we can describe how the current protocol behaves when a >>>>> MN attempts >>>>>> to attach with two interfaces. Similar to what is explained >>>>> in Vijay's >>>>>> email: >>>>>> >> http://www1.ietf.org/mail-archive/web/netlmm/current/msg03483.html >>>>> I'm ok with any of the above three options. We can certainly >>>>> document the scenario and close the issue. I do no think, >> we should >>>>> try to solve this problem here or use this issue to >> explicitly add >>>>> text to block the inter-access handoff, we did not do any >> thing to >>>>> support that scenario. When the charter says, its out of >> scope, we >>>>> dont need to solve all the issues, when the scenario is enabled. >>>>> Operators can solve this issue, these are managed >> deployments. Its >>>>> not a like a consumer buying a device and turning it on >> at home. So, >>>>> I agree with your above three suggested options. >>>>> >>>>> Regards >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>> Panasonic R&D Center Germany GmbH >>>> 63225 Langen, Hessen, Germany >>>> Reg: AG Offenbach (Hessen) HRB 33974 >>>> Managing Director: Thomas Micke >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> >> >> >> _______________________________________________ >> netlmm mailing list >> netlmm@ietf.org >> https://www1.ietf.org/mailman/listinfo/netlmm >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 23:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbTFW-0002cZ-F1; Fri, 28 Sep 2007 23:44:14 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbTFV-0002cS-Gj for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 23:44:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbTFV-0002cK-79 for netlmm@ietf.org; Fri, 28 Sep 2007 23:44:13 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbTFO-0004Vo-RU for netlmm@ietf.org; Fri, 28 Sep 2007 23:44:13 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8T3hgxq020430; Sat, 29 Sep 2007 06:43:44 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 06:43:42 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 22:43:40 -0500 Received: from 10.241.58.240 ([10.241.58.240]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Sep 2007 03:43:39 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 28 Sep 2007 22:43:46 -0500 Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs From: Basavaraj Patil To: "ext Narayanan, Vidya" , Sri Gundavelli , Genadi Velev Message-ID: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAFIfSQAFTWoQAEIm9dM= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Sep 2007 03:43:40.0392 (UTC) FILETIME=[ECCF8E80:01C8024A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, I believe the behavior of a host in the case where the interfaces are configured with the same address (duplication of addresses assigned to the interfaces) is implementation specific. A host does not necessarily switch off an interface as a result of duplicate addresses on the interfaces. I discussed this offline with Ryuji and he is of the opinion that duplicate addresses on the interfaces do not cause the IF to be shut down. So I don't think we can conclude that an interface is shut down or unusable and causes disruption of IP connectivity to the MN. It is behavior that is variable. Quoting Ryuji here: " RFC2462 says in '5.4.5. When Duplicate Address Detection Fails" A tentative address that is determined to be a duplicate as Described above, MUST NOT be assigned to an interface and the node SHOULD log a system management error. If the address is a link-local address formed from an interface identifier, the interface SHOULD be disabled. ' So, according to the RFC, a node only shutdown when link-local address is duplicated.. Not for the global. " The route table entry and interface used for sending/receiving is again implementation specific. Basically the point is that the issue of duplicate addresses being assigned to multi-homed hosts needs to be addressed in the IPv6 maintenance WG or elsewhere. Solving this problem is not in the scope of PMIP6 or the Netlmm WG. The problem of course arises in the PMI6 protocol scenario. But it is a generic IPv6 issue that needs to be dealt with elsewhere. Rgds, -Raj On 9/27/07 3:10 PM, "ext Narayanan, Vidya" wrote: > Hi Raj, > In the example I wrote, the MN doesn't shut down both its interfaces. > It thinks Interface 1 is operational and has shutdown Interface 2 due to > a duplicate address. However, the LMA only has a binding corresponding > to Interface 2 - so, the fact that the MN thinks it can use Interface 1 > is not useful, since it really cannot send/receive any packets through > it. As a result, the MN has no IP connectivity. > > Hope that clarifies. > > Vidya > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Thursday, September 27, 2007 10:38 AM >> To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev >> Cc: ext Kilian Weniger; netlmm@ietf.org >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >> >> >> Vidya, >> >> Just for my education, can you please explain why the MN >> would shutdown both interfaces if it were to receive the same >> prefix on another interface on a multi-interface host? >> I guess I could dig up the archives... But if you can explain >> the issue behind such behavior, I would appreciate it. >> >> -Raj >> >> >> On 9/27/07 12:31 PM, "ext Narayanan, Vidya" >> wrote: >> >>> Sri, >>> You seem to be missing the point. We are not dealing with >>> multi-interface support issues in this thread. What we are dealing >>> with is the fact that an MN may not be able to use *any* interface >>> simply because it happens to have two interfaces. Unless >> the MN knows >>> that the network is using PMIP and hence, it can only use one >>> interface at a time, you are going to have regular IP nodes >> that run into this problem. >>> >>> >>> In a nutshell, the problem is about an MN ending up with no >> IP service >>> using even one of its interfaces. >>> >>> I hope you can see that the problem doesn't relate to providing >>> multihoming to the MN; rather it relates to something far more >>> fundamental that this protocol is supposed to ensure - IP >> connectivity >>> to the MN. >>> >>> Vidya >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Fri Sep 28 23:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbTUA-00060e-KS; Fri, 28 Sep 2007 23:59:22 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbTU8-0005zk-Mx for netlmm-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 23:59:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbTU8-0005zS-Bz for netlmm@ietf.org; Fri, 28 Sep 2007 23:59:20 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbTU7-00071x-NW for netlmm@ietf.org; Fri, 28 Sep 2007 23:59:20 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8T3w8N5026553; Sat, 29 Sep 2007 06:59:01 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 06:58:16 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 22:58:14 -0500 Received: from 10.241.58.240 ([10.241.58.240]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Sep 2007 03:58:14 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 28 Sep 2007 22:58:20 -0500 Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs From: Basavaraj Patil To: "ext Narayanan, Vidya" , ext Genadi Velev , Sri Gundavelli Message-ID: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgB2hUdvbTtGdHSTqmQpprklkoYOwAC8wCAAAINLVcACWIVMAAOVr22 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Sep 2007 03:58:14.0675 (UTC) FILETIME=[F5EC8E30:01C8024C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On 9/28/07 4:16 PM, "ext Narayanan, Vidya" wrote: Snip.. Snip.. > >> An MN which attaches via different interfaces simultaneously >> to a PMIP6 domain will result in the LMA having a BCE for the >> last received PBU. Host behavior when multiple interfaces >> have the same address is unspecified and we can just leave it >> at that. In the context of this document, we do not need to solve it. >> > > I don't get this part though. Given that there isn't a practical way > for the network to determine if the MN is attaching to multiple MAGs or > just one (I can imagine somewhat more complicated ways of figuring that > out with additional help from the lower layers, but, we can't rely on > that), if we left it unsolved, that just means that an MN which happens > to have multiple interfaces may suffer lack of IP connectivity or > toggling/intermittent connectivity. So, I think we do need to state > that the MN-ID used must be interface-specific. How a system ensures > that the ID used is interface-specific doesn't need to be mandated. I agree that the LMA does not have a way of realizing if the PBU from MAG2 is a result of the MN doing a HO vs the MN attaching to MAG2 via an alternate interface. And as you state there can be out-of-band means to detect it but cannot be relied on being available in all networks. I think that in the context of the base PMIP6 protocol it is acceptable to state that an MN may suffer IP connectivity loss in multi-homing cases. I think we are trying to solve a corner case here. Because the behavior of an MN which has duplicate addresses configured on its interfaces is implementation specific, we cannot really conclude that there is IP connectivity loss. Analyzing this further we (authors) concluded that the address configured on the interfaces will be a duplicate only in the case when RFC3041 type of addresses are generated based on the prefix in the RA. If EUI64 or DHCP is used for address config, the addresses for the interfaces will be unique although the prefix in the RAs from both MAGs are identical. The LMA will however have only a single MAG in the BCE and this will be the one from which the most recent PBU was received. There will be oscillation of the MAG address in the BCE (betwee MAG1 and MAG2) as a result of the MAGs periodically sending PBUs to the LMA. However I do not think this is a problem that can be completely scoped or solved in the context of the base PMIP6 protocol. It is best to acknowledge the issues and move forward. After all, there are many things that need to be specified in addition to the basic operation of PMIP6 to make this really work. This issue would be one of those topics. -Raj > > Vidya > >> -Raj >> >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 00:05:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbTZv-0002RL-JY; Sat, 29 Sep 2007 00:05:19 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbTZu-0002RD-S6 for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 00:05:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbTZu-0002Qs-GJ for netlmm@ietf.org; Sat, 29 Sep 2007 00:05:18 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbTZt-00078u-VC for netlmm@ietf.org; Sat, 29 Sep 2007 00:05:18 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8T44xEa031804; Sat, 29 Sep 2007 07:05:00 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 07:04:59 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Sep 2007 23:04:57 -0500 Received: from 10.241.58.240 ([10.241.58.240]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Sat, 29 Sep 2007 04:04:56 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 28 Sep 2007 23:05:02 -0500 Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs From: Basavaraj Patil To: "ext Narayanan, Vidya" , ext Genadi Velev , Sri Gundavelli Message-ID: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgB2hUdvbTtGdHSTqmQpprklkoYOwAC8wCAAAINLVcACWIVMAAOkqQG In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Sep 2007 04:04:57.0047 (UTC) FILETIME=[E5C1A670:01C8024D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On 9/28/07 4:16 PM, "ext Narayanan, Vidya" wrote: Snip.. Snip.. > >> An MN which attaches via different interfaces simultaneously >> to a PMIP6 domain will result in the LMA having a BCE for the >> last received PBU. Host behavior when multiple interfaces >> have the same address is unspecified and we can just leave it >> at that. In the context of this document, we do not need to solve it. >> > > I don't get this part though. Given that there isn't a practical way > for the network to determine if the MN is attaching to multiple MAGs or > just one (I can imagine somewhat more complicated ways of figuring that > out with additional help from the lower layers, but, we can't rely on > that), if we left it unsolved, that just means that an MN which happens > to have multiple interfaces may suffer lack of IP connectivity or > toggling/intermittent connectivity. So, I think we do need to state > that the MN-ID used must be interface-specific. How a system ensures > that the ID used is interface-specific doesn't need to be mandated. Forgot one more thing.... I don't think we want to take the route of making the MN-ID being interface specific. We can consider adding other hints to the LMA that can be used as a means to interpret that it is the same MN attaching via an alternate interface... But not change MN-ID to be interface specific. -Raj > > Vidya > >> -Raj >> >> _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 01:41:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbV44-0007Pf-BV; Sat, 29 Sep 2007 01:40:32 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbV42-0007Im-Hl for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 01:40:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbV42-0007Hc-63 for netlmm@ietf.org; Sat, 29 Sep 2007 01:40:30 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbV3w-0006Js-I6 for netlmm@ietf.org; Sat, 29 Sep 2007 01:40:29 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 28236A815F for ; Sat, 29 Sep 2007 01:39:51 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15558-02 for ; Sat, 29 Sep 2007 01:39:49 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Sat, 29 Sep 2007 01:39:49 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 01:39:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Sat, 29 Sep 2007 01:35:07 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26663FC504@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgCF/Q05tXmU6gmSZCYtQqBXYMxCgABDuegAAIWYAAADNYxoA== From: "Chowdhury, Kuntal" To: "Narayanan, Vidya" X-OriginalArrivalTime: 29 Sep 2007 05:39:43.0869 (UTC) FILETIME=[235DD2D0:01C8025B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: ext Kilian Weniger , netlmm@ietf.org, Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Friday, September 28, 2007 6:23 PM > To: Chowdhury, Kuntal; Sri Gundavelli > Cc: ext Kilian Weniger; netlmm@ietf.org; Genadi Velev > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Folks, > It is not helping to keep insisting that stating multi-homing is out of > scope is sufficient. The situation at hand is really the following and > let's own up to it: >=20 > "This protocol, as currently specified, may result in unpredictable, > intermittent or no IP connectivity to a device that is multihomed, over > any of its interfaces." >=20 > This doesn't just mean multi-homing is not supported; it means that a > unmodified multi-homed IP device can't have stable IP access. >=20 [KC>] Well, how can you be so certain w/o getting into MN implementation discussion? Didn't we decide to stay away from discussing MN implementation? There are known ways to address the issue of IP address collision over different interfaces on a host or a router. But, let's not get into that discussion here. BTW, why this is a PMIP6 specific issue? What happens in case of MIP6 when CoAs are non-unique over two interfaces of the MN? Take the case of a laptop with WiFi and RJ-45 Ethernet port (pretty common laptop configuration). What happens when both the interfaces are active and both the interfaces configure the same IP address (possible because WiFi and LANs mostly use private address pools)?=20 > If all this protocol is doing is providing IP connectivity over only one > interface of a multi-homed device, we won't be having this conversation. >=20 [KC>] I think you have a very specific MN implementation in mind. Note, if the MN has uncoordinated interfaces and if the MN lacks the capability of hiding the interfaces from the IP stack, only then it will be forced to use only one interface. >=20 > I don't believe we can call this document done given the situation at > hand. So, please work towards solving the issue, rather than repeatedly > claiming it is out of scope. >=20 [KC>] Well, this issue is out-of-scope since it pertains to MN implementation. As I have mentioned in my examples above, this issue may arise in many situations regardless of the use of PMIP6. > Thanks, > Vidya >=20 > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: Friday, September 28, 2007 3:12 PM > > To: Sri Gundavelli > > Cc: ext Kilian Weniger; netlmm@ietf.org; Genadi Velev > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > > > Sri, > > > > If we just add a note to say that: support for multi-homing > > is out of scope of the document, it should suffice. > > > > This topic is out of scope, and we should close this thread > > and move on. > > > > BR, > > Kuntal > > > > > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Friday, September 28, 2007 4:39 PM > > > To: Chowdhury, Kuntal > > > Cc: Genadi Velev; netlmm@ietf.org; ext Kilian Weniger > > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > > > > > Hi Kuntal, > > > > > > > > > On Fri, 28 Sep 2007, Chowdhury, Kuntal wrote: > > > > > > > Dear All, > > > > > > > > I don't think any of these options make sense. Requiring > > the MN to > > > > associate different MN-IDs over different interfaces means we are > > > > imposing new requirements on the MN which we tried to avoid, IMHO. > > Also, > > > > we cannot prevent the MN to attempt network access over more than > > one > > > > interface. > > > > > > > > I do not believe that there will be any issue if the MN > > attempts to > > use > > > > more than one interface. In the particular example given > > before, if > > the > > > > MN chooses to use interface 2, everything will be good. If the MN > > > > chooses to use interface 1, there are ways to recover from a > > momentary > > > > glitch. However, I think we should stay out of this level > > of detail > > to > > > > describe an out-of-scope topic (multi-homing) in the base spec. > > > > > > > > I like Behcet's proposal to state that: support for > > multi-homing is > > out > > > > of scope of the document. This is simple and precise. > > > > > > I agree and I've been saying this is out-of-scope. I do not > > want this > > > argument to lead to a solution with some explicit restrictions on > > > inter-access handoffs (which comes naturally with the > > current spec). > > > If the text suggested by Genadi leads to any such > > restrictions, which > > > I did not analyze in detail, I'll not be in favour of this. > > My point > > > is, we dont go into the details for some thing that is out > > of scope. > > > Just have a note that there may be glitch, when multiple interfaces > > > are active in a single domain and leave it there. > > > > > > If every one agrees on this, we can suggest some text on this and > > > close this issue. > > > > > > Sri > > > > > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 02:07:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVTS-0002nZ-9T; Sat, 29 Sep 2007 02:06:46 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbVTR-0002nU-Fy for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 02:06:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVTR-0002mn-3Q for netlmm@ietf.org; Sat, 29 Sep 2007 02:06:45 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbVTK-0006oM-23 for netlmm@ietf.org; Sat, 29 Sep 2007 02:06:45 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8T66Kh8016678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2007 23:06:21 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8T65sC7003497; Fri, 28 Sep 2007 23:06:19 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 23:05:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 23:05:29 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAFIfSQAFTWoQAEIm9dMABNo5MA== References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Sri Gundavelli" , "Genadi Velev" X-OriginalArrivalTime: 29 Sep 2007 06:05:55.0522 (UTC) FILETIME=[CC250A20:01C8025E] X-Spam-Score: -4.0 (----) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Raj, I was using the interface being shut down as one example. Whether the interface is shut down or not, IP forwarding cannot be enabled on it with a duplicate address. So, from an IP point of view, that interface is not useful to the MN. So, the problem still exists, unless I'm missing something fundamental. =20 Thanks, Vidya > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, September 28, 2007 8:44 PM > To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev > Cc: ext Kilian Weniger; netlmm@ietf.org > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 >=20 > Hi Vidya, >=20 > I believe the behavior of a host in the case where the=20 > interfaces are configured with the same address (duplication=20 > of addresses assigned to the > interfaces) is implementation specific. > A host does not necessarily switch off an interface as a=20 > result of duplicate addresses on the interfaces. I discussed=20 > this offline with Ryuji and he is of the opinion that=20 > duplicate addresses on the interfaces do not cause the IF to=20 > be shut down. So I don't think we can conclude that an=20 > interface is shut down or unusable and causes disruption of=20 > IP connectivity to the MN. It is behavior that is variable. >=20 > Quoting Ryuji here: > " > RFC2462 says in '5.4.5. When Duplicate Address Detection Fails" > A tentative address that is determined to be a duplicate=20 > as Described above, MUST NOT be assigned to an interface and=20 > the node SHOULD log a system management error. If the=20 > address is a link-local address formed from an interface=20 > identifier, the interface SHOULD be disabled. > ' > So, according to the RFC, a node only shutdown when=20 > link-local address is duplicated.. Not for the global. > " >=20 > The route table entry and interface used for=20 > sending/receiving is again implementation specific. >=20 > Basically the point is that the issue of duplicate addresses=20 > being assigned to multi-homed hosts needs to be addressed in=20 > the IPv6 maintenance WG or elsewhere. Solving this problem is=20 > not in the scope of PMIP6 or the Netlmm WG. The problem of=20 > course arises in the PMI6 protocol scenario. But it is a=20 > generic IPv6 issue that needs to be dealt with elsewhere. >=20 > Rgds, > -Raj >=20 > On 9/27/07 3:10 PM, "ext Narayanan, Vidya"=20 > wrote: >=20 > > Hi Raj, > > In the example I wrote, the MN doesn't shut down both its=20 > interfaces. > > It thinks Interface 1 is operational and has shutdown=20 > Interface 2 due=20 > > to a duplicate address. However, the LMA only has a binding=20 > > corresponding to Interface 2 - so, the fact that the MN=20 > thinks it can=20 > > use Interface 1 is not useful, since it really cannot=20 > send/receive any=20 > > packets through it. As a result, the MN has no IP connectivity. > >=20 > > Hope that clarifies. > >=20 > > Vidya > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Thursday, September 27, 2007 10:38 AM > >> To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev > >> Cc: ext Kilian Weniger; netlmm@ietf.org > >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > >>=20 > >>=20 > >> Vidya, > >>=20 > >> Just for my education, can you please explain why the MN would=20 > >> shutdown both interfaces if it were to receive the same prefix on=20 > >> another interface on a multi-interface host? > >> I guess I could dig up the archives... But if you can explain the=20 > >> issue behind such behavior, I would appreciate it. > >>=20 > >> -Raj > >>=20 > >>=20 > >> On 9/27/07 12:31 PM, "ext Narayanan, Vidya" > >> wrote: > >>=20 > >>> Sri, > >>> You seem to be missing the point. We are not dealing with=20 > >>> multi-interface support issues in this thread. What we=20 > are dealing=20 > >>> with is the fact that an MN may not be able to use *any*=20 > interface=20 > >>> simply because it happens to have two interfaces. Unless > >> the MN knows > >>> that the network is using PMIP and hence, it can only use one=20 > >>> interface at a time, you are going to have regular IP nodes > >> that run into this problem. > >>>=20 > >>>=20 > >>> In a nutshell, the problem is about an MN ending up with no > >> IP service > >>> using even one of its interfaces. > >>>=20 > >>> I hope you can see that the problem doesn't relate to providing=20 > >>> multihoming to the MN; rather it relates to something far more=20 > >>> fundamental that this protocol is supposed to ensure - IP > >> connectivity > >>> to the MN. > >>>=20 > >>> Vidya > >>=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 02:10:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVXK-0000BU-8h; Sat, 29 Sep 2007 02:10:46 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbVXI-00009E-Et for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 02:10:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVXI-000096-3Y for netlmm@ietf.org; Sat, 29 Sep 2007 02:10:44 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbVXH-00015w-8E for netlmm@ietf.org; Sat, 29 Sep 2007 02:10:44 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8T6AXD0017278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2007 23:10:33 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8T6AVbW004169; Fri, 28 Sep 2007 23:10:32 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 23:10:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 23:10:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAFIfSQAFTWoQAEIm9dMABNo5MAAAIkcg References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Sri Gundavelli" , "Genadi Velev" X-OriginalArrivalTime: 29 Sep 2007 06:10:31.0691 (UTC) FILETIME=[70C115B0:01C8025F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org =20 Just to further clarify - as you quote below from RFC2462, the duplicate address is not assigned to the interface. So, the interface that the LMA is going to forward the packets to is not assigned the address in the example scenario I was quoting and hence, the MN will not accept packets on that link. The interface that is valid from MN's perspective is not acceptable to the LMA. The "shutdown" example I was using seems to have created a lot of confusion - essentially, I'm getting at the fact that IP connectivity to the MN is messed up in this case.=20 Vidya > -----Original Message----- > From: Narayanan, Vidya=20 > Sent: Friday, September 28, 2007 11:05 PM > To: 'Basavaraj Patil'; Sri Gundavelli; Genadi Velev > Cc: ext Kilian Weniger; netlmm@ietf.org > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 > Hi Raj, > I was using the interface being shut down as one example. =20 > Whether the interface is shut down or not, IP forwarding=20 > cannot be enabled on it with a duplicate address. So, from=20 > an IP point of view, that interface is not useful to the MN. =20 > So, the problem still exists, unless I'm missing something=20 > fundamental. =20 >=20 > Thanks, > Vidya >=20 > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Friday, September 28, 2007 8:44 PM > > To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev > > Cc: ext Kilian Weniger; netlmm@ietf.org > > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > >=20 > >=20 > > Hi Vidya, > >=20 > > I believe the behavior of a host in the case where the=20 > interfaces are=20 > > configured with the same address (duplication of addresses=20 > assigned to=20 > > the > > interfaces) is implementation specific. > > A host does not necessarily switch off an interface as a result of=20 > > duplicate addresses on the interfaces. I discussed this=20 > offline with=20 > > Ryuji and he is of the opinion that duplicate addresses on the=20 > > interfaces do not cause the IF to be shut down. So I don't think we=20 > > can conclude that an interface is shut down or unusable and causes=20 > > disruption of IP connectivity to the MN. It is behavior that is=20 > > variable. > >=20 > > Quoting Ryuji here: > > " > > RFC2462 says in '5.4.5. When Duplicate Address Detection Fails" > > A tentative address that is determined to be a duplicate as=20 > > Described above, MUST NOT be assigned to an interface and the node=20 > > SHOULD log a system management error. If the address is a=20 > link-local=20 > > address formed from an interface identifier, the interface=20 > SHOULD be=20 > > disabled. > > ' > > So, according to the RFC, a node only shutdown when=20 > link-local address=20 > > is duplicated.. Not for the global. > > " > >=20 > > The route table entry and interface used for sending/receiving is=20 > > again implementation specific. > >=20 > > Basically the point is that the issue of duplicate addresses being=20 > > assigned to multi-homed hosts needs to be addressed in the IPv6=20 > > maintenance WG or elsewhere. Solving this problem is not in=20 > the scope=20 > > of PMIP6 or the Netlmm WG. The problem of course arises in the PMI6=20 > > protocol scenario. But it is a generic IPv6 issue that needs to be=20 > > dealt with elsewhere. > >=20 > > Rgds, > > -Raj > >=20 > > On 9/27/07 3:10 PM, "ext Narayanan, Vidya"=20 > > wrote: > >=20 > > > Hi Raj, > > > In the example I wrote, the MN doesn't shut down both its > > interfaces. > > > It thinks Interface 1 is operational and has shutdown > > Interface 2 due > > > to a duplicate address. However, the LMA only has a binding=20 > > > corresponding to Interface 2 - so, the fact that the MN > > thinks it can > > > use Interface 1 is not useful, since it really cannot > > send/receive any > > > packets through it. As a result, the MN has no IP connectivity. > > >=20 > > > Hope that clarifies. > > >=20 > > > Vidya > > >=20 > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Thursday, September 27, 2007 10:38 AM > > >> To: Narayanan, Vidya; Sri Gundavelli; Genadi Velev > > >> Cc: ext Kilian Weniger; netlmm@ietf.org > > >> Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs > > >>=20 > > >>=20 > > >> Vidya, > > >>=20 > > >> Just for my education, can you please explain why the MN would=20 > > >> shutdown both interfaces if it were to receive the same=20 > prefix on=20 > > >> another interface on a multi-interface host? > > >> I guess I could dig up the archives... But if you can=20 > explain the=20 > > >> issue behind such behavior, I would appreciate it. > > >>=20 > > >> -Raj > > >>=20 > > >>=20 > > >> On 9/27/07 12:31 PM, "ext Narayanan, Vidya" > > >> wrote: > > >>=20 > > >>> Sri, > > >>> You seem to be missing the point. We are not dealing with=20 > > >>> multi-interface support issues in this thread. What we > > are dealing > > >>> with is the fact that an MN may not be able to use *any* > > interface > > >>> simply because it happens to have two interfaces. Unless > > >> the MN knows > > >>> that the network is using PMIP and hence, it can only use one=20 > > >>> interface at a time, you are going to have regular IP nodes > > >> that run into this problem. > > >>>=20 > > >>>=20 > > >>> In a nutshell, the problem is about an MN ending up with no > > >> IP service > > >>> using even one of its interfaces. > > >>>=20 > > >>> I hope you can see that the problem doesn't relate to providing=20 > > >>> multihoming to the MN; rather it relates to something far more=20 > > >>> fundamental that this protocol is supposed to ensure - IP > > >> connectivity > > >>> to the MN. > > >>>=20 > > >>> Vidya > > >>=20 > >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 02:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbViG-0006js-0B; Sat, 29 Sep 2007 02:22:04 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbViE-0006jT-5c for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 02:22:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbViD-0006hu-J0 for netlmm@ietf.org; Sat, 29 Sep 2007 02:22:01 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbVi7-0001M6-RP for netlmm@ietf.org; Sat, 29 Sep 2007 02:21:56 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8T6LI2s017736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2007 23:21:19 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8T6LHoe010994; Fri, 28 Sep 2007 23:21:17 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 23:21:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 23:21:15 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgB2hUdvbTtGdHSTqmQpprklkoYOwAC8wCAAAINLVcACWIVMAAOVr22AAS66nA= References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "ext Genadi Velev" , "Sri Gundavelli" X-OriginalArrivalTime: 29 Sep 2007 06:21:17.0214 (UTC) FILETIME=[F18413E0:01C80260] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Raj, > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Friday, September 28, 2007 8:58 PM > To: Narayanan, Vidya; ext Genadi Velev; Sri Gundavelli > Cc: ext Kilian Weniger; netlmm@ietf.org > Subject: Re: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 >=20 >=20 >=20 > On 9/28/07 4:16 PM, "ext Narayanan, Vidya"=20 > wrote: >=20 > Snip.. Snip.. >=20 >=20 > >=20 > >> An MN which attaches via different interfaces simultaneously to a=20 > >> PMIP6 domain will result in the LMA having a BCE for the last=20 > >> received PBU. Host behavior when multiple interfaces have the same=20 > >> address is unspecified and we can just leave it at that. In the=20 > >> context of this document, we do not need to solve it. > >>=20 > >=20 > > I don't get this part though. Given that there isn't a=20 > practical way=20 > > for the network to determine if the MN is attaching to=20 > multiple MAGs=20 > > or just one (I can imagine somewhat more complicated ways=20 > of figuring=20 > > that out with additional help from the lower layers, but, we can't=20 > > rely on that), if we left it unsolved, that just means that an MN=20 > > which happens to have multiple interfaces may suffer lack of IP=20 > > connectivity or toggling/intermittent connectivity. So, I=20 > think we do=20 > > need to state that the MN-ID used must be=20 > interface-specific. How a=20 > > system ensures that the ID used is interface-specific=20 > doesn't need to be mandated. >=20 > I agree that the LMA does not have a way of realizing if the=20 > PBU from MAG2 is a result of the MN doing a HO vs the MN=20 > attaching to MAG2 via an alternate interface. And as you=20 > state there can be out-of-band means to detect it but cannot=20 > be relied on being available in all networks. >=20 > I think that in the context of the base PMIP6 protocol it is=20 > acceptable to state that an MN may suffer IP connectivity=20 > loss in multi-homing cases. I think we are trying to solve a=20 > corner case here.=20 I'm not sure why this is a corner case. Multihomed devices are common today and they are only going to increase.=20 > Because the behavior of an MN which has=20 > duplicate addresses configured on its interfaces is=20 > implementation specific, we cannot really conclude that there=20 > is IP connectivity loss. Analyzing this further we (authors)=20 > concluded that the address configured on the interfaces will=20 > be a duplicate only in the case when RFC3041 type of=20 > addresses are generated based on the prefix in the RA. > If EUI64 or DHCP is used for address config, the addresses=20 > for the interfaces will be unique although the prefix in the=20 > RAs from both MAGs are identical.=20 Not true. If the MN used DHCP, in accordance with PMIP, wouldn't it get the same IP address? There is no requirement on the MN doing DHCP-PD. So, a regular MN would just be requesting an IP address, not a prefix. Also, in the IPv4 case, this is only an address. In the model where the MAG obtains the prefix from the LMA and serves as a DHCP server to the MN will provide the same address to the MN - in the IPv4 case, there is no other information available to the MAG, except for a single address. I'll also note that RFC3041-style addresses are not that uncommon. =20 Regards, Vidya > The LMA will however have=20 > only a single MAG in the BCE and this will be the one from=20 > which the most recent PBU was received. > There will be oscillation of the MAG address in the BCE=20 > (betwee MAG1 and > MAG2) as a result of the MAGs periodically sending PBUs to=20 > the LMA. However I do not think this is a problem that can be=20 > completely scoped or solved in the context of the base PMIP6=20 > protocol. It is best to acknowledge the issues and move=20 > forward. After all, there are many things that need to be=20 > specified in addition to the basic operation of PMIP6 to make=20 > this really work. This issue would be one of those topics. >=20 >=20 > -Raj >=20 > >=20 > > Vidya > >=20 > >> -Raj > >>=20 >=20 > >>=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 02:29:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVp6-0003Ab-NM; Sat, 29 Sep 2007 02:29:08 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbVp5-00038f-3e for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 02:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbVp4-00038T-QM for netlmm@ietf.org; Sat, 29 Sep 2007 02:29:06 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbVoy-0007Hh-Ie for netlmm@ietf.org; Sat, 29 Sep 2007 02:29:06 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8T6SPFO005691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2007 23:28:26 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8T6SORi011647; Fri, 28 Sep 2007 23:28:25 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 23:28:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 23:28:23 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgB2hUdvbTtGdHSTqmQpprklkoYOwAC8wCAAAINLVcACWIVMAAOkqQGAATvCTA= References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "ext Genadi Velev" , "Sri Gundavelli" X-OriginalArrivalTime: 29 Sep 2007 06:28:24.0668 (UTC) FILETIME=[F04C61C0:01C80261] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ext Kilian Weniger , netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Raj, =20 > Forgot one more thing.... > I don't think we want to take the route of making the MN-ID=20 > being interface specific. We can consider adding other hints=20 > to the LMA that can be used as a means to interpret that it=20 > is the same MN attaching via an alternate interface... But=20 > not change MN-ID to be interface specific. >=20 Any thoughts on what other hints we can use? I don't it is necessary to even correlate it to the same MN. It should be sufficient to distinguish the interfaces such that the LMA treats those as separate IP addresses and separate PMIP sessions.=20 Vidya > -Raj >=20 > >=20 > > Vidya > >=20 > >> -Raj > >>=20 >=20 > >>=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 02:42:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbW1j-0005PT-8N; Sat, 29 Sep 2007 02:42:11 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbW1h-0005PN-UT for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 02:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbW1h-0005PF-Kj for netlmm@ietf.org; Sat, 29 Sep 2007 02:42:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbW1b-0007gK-G8 for netlmm@ietf.org; Sat, 29 Sep 2007 02:42:09 -0400 X-IronPort-AV: E=Sophos;i="4.21,212,1188792000"; d="scan'208";a="133374808" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Sep 2007 02:41:58 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8T6fw2i027469; Sat, 29 Sep 2007 02:41:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8T6fvPA005910; Sat, 29 Sep 2007 06:41:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 02:41:57 -0400 Received: from sgundavewxp ([10.32.246.213]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Sep 2007 02:41:56 -0400 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" References: Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 23:42:01 -0700 Message-ID: <028301c80263$d8904310$1220fea9@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAFIfSQAFTWoQAEIm9dMABNo5MAAAM+YA X-OriginalArrivalTime: 29 Sep 2007 06:41:57.0100 (UTC) FILETIME=[D48BAAC0:01C80263] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1369; t=1191048118; x=1191912118; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[netlmm]=20Issue=3A=20Prefix=20allocation=20and=20mul tihomed=20MNs |Sender:=20 |To:=20=22'Narayanan,=20Vidya'=22=20; bh=Cg9UX3tmw5xnPDpp9x6nQxOzjLbVmK5HE+Fgnbb3OZ0=; b=ioXvDagi9TPioqUIvFotLIurx0AXjPkLfB8X6NRbAMqQtmsBLYxZVLB1eFSRswRmPOrVzRuQ 1kx+npWs7BBygUrBeyFomIHcKUqrKrGzAYGIYGF2Kc3Ks4byc8A3Kpec; Authentication-Results: rtp-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, > Hi Raj, > I was using the interface being shut down as one example. Whether the > interface is shut down or not, IP forwarding cannot be enabled on it > with a duplicate address. So, from an IP point of view, that > interface > is not useful to the MN. So, the problem still exists, unless I'm > missing something fundamental. > As I stated before.. A normal (unmodified) IPv6 stack, will not allow more than one interface to configure the same IPv6 address. I've verified this on Cisco's implementation. This is true for other popular platforms as well. HA(config)#int ethernet 0/1 HA(config-if)#ipv6 address abab::1/64 HA(config-if)#exit HA(config)#int ethernet 0/2 HA(config-if)#ipv6 address abab::1/64 %Ethernet0/2: Error: ABAB::1/64 is in use on Ethernet0/1 So, we are just discussing about some issue on the host when multihoming is enabled and that belongs to the work item that is not in scope of the charter. Why are we wasting our time on this multihoming issue ? And I dont see any *consensus* or even *remote interest* from any one in the WG on this issue. None of the other reviewers even talked about this issue, in their review comments. Please understand, we need to complete this work. This is really frustrating. If need be, this can be addressed in a different document. Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 02:47:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbW6s-0005wA-R0; Sat, 29 Sep 2007 02:47:30 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbW6r-0005w4-Os for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 02:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbW6n-0005ka-DW for netlmm@ietf.org; Sat, 29 Sep 2007 02:47:25 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbW6h-0007mS-2B for netlmm@ietf.org; Sat, 29 Sep 2007 02:47:25 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8T6km3G018830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 28 Sep 2007 23:46:48 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8T6klIP001523; Fri, 28 Sep 2007 23:46:47 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Sep 2007 23:46:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs Date: Fri, 28 Sep 2007 23:46:46 -0700 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A26663FC504$0001@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs Thread-Index: AcgCF/Q05tXmU6gmSZCYtQqBXYMxCgABDuegAAIWYAAADNYxoAACmVfg References: <4D35478224365146822AE9E3AD4A26663FC504$0001@exchtewks3.starentnetworks.com> From: "Narayanan, Vidya" To: "Chowdhury, Kuntal" X-OriginalArrivalTime: 29 Sep 2007 06:46:47.0335 (UTC) FILETIME=[818A0370:01C80264] X-Spam-Score: -4.0 (----) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: ext Kilian Weniger , netlmm@ietf.org, Genadi Velev X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Kuntal, I'm not referring to any implementation specific details. Please see my response to Raj - per the text quoted from RFC2462 by Raj, the MN won't configure a duplicate address on its interface and hence this problem exists. =20 Also, it is not similar to duplicate addresses in other situations - typically, if the MN is doing DHCP, it is either an error on the part of the MN (e.g., using the same client ID for two interfaces) or on the part of the DHCP server that it ends up with a duplicate address. Or, while using stateless autoconfiguration, the MN must violate RFC2462 to end up with duplicate addresses being assigned to multiple interfaces. The difference here is that it is neither an error from the MN perspective nor an error from a PMIP perspective and hence, the problem. Regards, Vidya > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Friday, September 28, 2007 10:35 PM > To: Narayanan, Vidya > Cc: ext Kilian Weniger; netlmm@ietf.org; Genadi Velev; Sri Gundavelli > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs >=20 >=20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Friday, September 28, 2007 6:23 PM > > To: Chowdhury, Kuntal; Sri Gundavelli > > Cc: ext Kilian Weniger; netlmm@ietf.org; Genadi Velev > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > >=20 > > Folks, > > It is not helping to keep insisting that stating multi-homing is out > of > > scope is sufficient. The situation at hand is really the following > and > > let's own up to it: > >=20 > > "This protocol, as currently specified, may result in=20 > unpredictable,=20 > > intermittent or no IP connectivity to a device that is multihomed, > over > > any of its interfaces." > >=20 > > This doesn't just mean multi-homing is not supported; it=20 > means that a=20 > > unmodified multi-homed IP device can't have stable IP access. > >=20 > [KC>] Well, how can you be so certain w/o getting into MN=20 > implementation discussion? Didn't we decide to stay away from=20 > discussing MN implementation? There are known ways to address=20 > the issue of IP address collision over different interfaces=20 > on a host or a router. But, let's not get into that discussion here. >=20 > BTW, why this is a PMIP6 specific issue? What happens in case=20 > of MIP6 when CoAs are non-unique over two interfaces of the MN? >=20 > Take the case of a laptop with WiFi and RJ-45 Ethernet port=20 > (pretty common laptop configuration). What happens when both=20 > the interfaces are active and both the interfaces configure=20 > the same IP address (possible because WiFi and LANs mostly=20 > use private address pools)?=20 >=20 > > If all this protocol is doing is providing IP connectivity over only > one > > interface of a multi-homed device, we won't be having this > conversation. > >=20 > [KC>] I think you have a very specific MN implementation in=20 > mind. Note, if the MN has uncoordinated interfaces and if the=20 > MN lacks the capability of hiding the interfaces from the IP=20 > stack, only then it will be forced to use only one interface. >=20 > >=20 > > I don't believe we can call this document done given the=20 > situation at=20 > > hand. So, please work towards solving the issue, rather than > repeatedly > > claiming it is out of scope. > >=20 > [KC>] Well, this issue is out-of-scope since it pertains to=20 > MN implementation. As I have mentioned in my examples above,=20 > this issue may arise in many situations regardless of the use=20 > of PMIP6. >=20 >=20 > > Thanks, > > Vidya > >=20 > > > -----Original Message----- > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > Sent: Friday, September 28, 2007 3:12 PM > > > To: Sri Gundavelli > > > Cc: ext Kilian Weniger; netlmm@ietf.org; Genadi Velev > > > Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs > > > > > > Sri, > > > > > > If we just add a note to say that: support for=20 > multi-homing is out=20 > > > of scope of the document, it should suffice. > > > > > > This topic is out of scope, and we should close this=20 > thread and move=20 > > > on. > > > > > > BR, > > > Kuntal > > > > > > > > > > -----Original Message----- > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > Sent: Friday, September 28, 2007 4:39 PM > > > > To: Chowdhury, Kuntal > > > > Cc: Genadi Velev; netlmm@ietf.org; ext Kilian Weniger > > > > Subject: RE: [netlmm] Issue: Prefix allocation and=20 > multihomed MNs > > > > > > > > Hi Kuntal, > > > > > > > > > > > > On Fri, 28 Sep 2007, Chowdhury, Kuntal wrote: > > > > > > > > > Dear All, > > > > > > > > > > I don't think any of these options make sense. Requiring > > > the MN to > > > > > associate different MN-IDs over different interfaces means we > are > > > > > imposing new requirements on the MN which we tried to avoid, > IMHO. > > > Also, > > > > > we cannot prevent the MN to attempt network access over more > than > > > one > > > > > interface. > > > > > > > > > > I do not believe that there will be any issue if the MN > > > attempts to > > > use > > > > > more than one interface. In the particular example given > > > before, if > > > the > > > > > MN chooses to use interface 2, everything will be good. If the > MN > > > > > chooses to use interface 1, there are ways to recover from a > > > momentary > > > > > glitch. However, I think we should stay out of this level > > > of detail > > > to > > > > > describe an out-of-scope topic (multi-homing) in the=20 > base spec. > > > > > > > > > > I like Behcet's proposal to state that: support for > > > multi-homing is > > > out > > > > > of scope of the document. This is simple and precise. > > > > > > > > I agree and I've been saying this is out-of-scope. I do not > > > want this > > > > argument to lead to a solution with some explicit=20 > restrictions on=20 > > > > inter-access handoffs (which comes naturally with the > > > current spec). > > > > If the text suggested by Genadi leads to any such > > > restrictions, which > > > > I did not analyze in detail, I'll not be in favour of this. > > > My point > > > > is, we dont go into the details for some thing that is out > > > of scope. > > > > Just have a note that there may be glitch, when multiple > interfaces > > > > are active in a single domain and leave it there. > > > > > > > > If every one agrees on this, we can suggest some text=20 > on this and=20 > > > > close this issue. > > > > > > > > Sri > > > > > > > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 >=20 > "This email message and any attachments are confidential=20 > information of Starent Networks, Corp. The information=20 > transmitted may not be used to create or change any=20 > contractual obligations of Starent Networks, Corp. Any=20 > review, retransmission, dissemination or other use of, or=20 > taking of any action in reliance upon this e-mail and its=20 > attachments by persons or entities other than the intended=20 > recipient is prohibited. If you are not the intended=20 > recipient, please notify the sender immediately -- by=20 > replying to this message or by sending an email to=20 > postmaster@starentnetworks.com -- and destroy all copies of=20 > this message and any attachments without reading or=20 > disclosing their contents. Thank you." >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 10:22:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbdCB-0005o7-Ml; Sat, 29 Sep 2007 10:21:27 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbdC9-0005o2-Ow for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 10:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbdC9-0005nu-FN for netlmm@ietf.org; Sat, 29 Sep 2007 10:21:25 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbdC4-0006Kv-83 for netlmm@ietf.org; Sat, 29 Sep 2007 10:21:25 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l8TEKkU02553; Sat, 29 Sep 2007 14:20:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) Date: Sat, 29 Sep 2007 09:20:41 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371170F03E3@zrc2hxm2.corp.nortel.com> In-Reply-To: <027601c8023a$a6bb9890$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB9VyUEAd/bxJDSgONgCCgghhYrwAASyfQAA0qlEAAA5FRAAAYxhHg References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DE18@zrc2hxm2.corp.nortel.com> <027601c8023a$a6bb9890$1220fea9@amer.cisco.com> From: "Ahmad Muhanna" To: "Sri Gundavelli" , "Narayanan, Vidya" , "Wassim Haddad" X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: DE JUAN HUARTE FEDERICO , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Sri/Vidya and All, I believe that we need to stay away from details of how this compromised MAG issue can be solved. The reason behind this is that, in the future, and after a thorough investigation of this issue, the final solution may contradict with the proposed details. Having said that I would recommend removing all examples and keep enough informative text which does the following: 1. Acknowledge the problem 2. Recognize that this issue is not a show stopper and can be addressed by future work item if at all necessary. 3. Provide informative text which capture the high level indication of a possible solution. Based on this, I would recommend the following text: " To eliminate the threats related to a compromised mobile access gateway, the local mobility anchor, before accepting a Proxy Binding Update message for a given mobile node, may ensure that the mobile node is definitely attached to the mobile access gateway that sent the proxy binding registration request. This may be accomplished by contacting a trusted entity which is able to track the mobile node current point of attachment or validate the provided mobile node signature. " Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Friday, September 28, 2007 8:47 PM > To: 'Narayanan, Vidya'; Muhanna, Ahmad (RICH1:2H10); 'Wassim Haddad' > Cc: 'DE JUAN HUARTE FEDERICO'; 'netlmm' > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) >=20 > It looks fine, except for the CGA part. The CGA generation=20 > requires the IPv6 subnet prefix and that the mobile node in a=20 > Proxy Mobile IPv6 domain would not have it before the=20 > signaling is complete. So, the mobile node would not be able=20 > to assert the address ownership or infact even generate an=20 > address until the MAG completes the signaling. This may work=20 > for subsequent registrations, but not during initial=20 > attachment in Proxy Mobile IPv6 domain. So, I suggest taking=20 > out the CGA part and close this issue.=20 >=20 > Thanks Ahmad for the text. >=20 >=20 > Sri >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Friday, September 28, 2007 5:03 PM > > To: Ahmad Muhanna; Wassim Haddad > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > Subject: RE: Text Proposal for Compromised MAG issue (was > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > >=20 > > All, > > The text proposed by Ahmad mostly looks fine to me,=20 > although it may be=20 > > worthwhile providing a hint for how one may do it in a=20 > non-AAA based=20 > > system. How about the following (I've taken Ahmad's text and made=20 > > some minor changes/additions): > >=20 > > "To deal with threats related to a compromised mobile=20 > access gateway,=20 > > the local mobility anchor, before accepting a Proxy Binding Update=20 > > message for a given mobile node, may choose to ensure that=20 > the mobile > > node is definitively attached to the mobile access=20 > gateway that sent > > the binding registration request. This may be done by contacting a=20 > > trusted entity which tracks the MN current point of=20 > attachment, e.g. a=20 > > AAA server (as a result of an authentication exchange with the MN). > > This may also be accomplished by verification of a live=20 > signature from=20 > > the MN, e.g., a CGA signature. Details of how such verification of=20 > > the MN's point of attachment is done is outside the scope of this=20 > > specification." > >=20 > > I've tried to stay away from any normative language in the text,=20 > > indicating that we are merely providing examples. > >=20 > > Thanks, > > Vidya > >=20 > > > -----Original Message----- > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > Sent: Friday, September 28, 2007 10:51 AM > > > To: Wassim Haddad > > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm]=20 > > > Reviewofdraft-ietf-netlmm-proxymip6-05) > > >=20 > > > Hi Wassim, > > >=20 > > > To be honest, the least to be said about all of this=20 > compromised MAG=20 > > > discussion/issue is: May be not necessary and probably a=20 > lot of time=20 > > > is wasted:-( I am sorry I misunderstood what you were=20 > trying to say=20 > > > earlier, But yes, I see it much clearer now. > > >=20 > > > One more comment inline. > > >=20 > > > Cheers:) > > >=20 > > > Regards, > > > Ahmad > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > > > > Sent: Friday, September 28, 2007 12:31 PM > > > > To: Muhanna, Ahmad (RICH1:2H10) > > > > Cc: DE JUAN HUARTE FEDERICO; Sri Gundavelli; netlmm > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > [netlmm] > > > > Review ofdraft-ietf-netlmm-proxymip6-05) > > > >=20 > > > > Hi Ahmad, > > > >=20 > > > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > > > >=20 > > > > > [Ahmad] > > > > > So, can I read this that you think it is impossible and > > > > does not make sense? > > > >=20 > > > > =3D> Not at all! Am saying that having the AAA involved to > > > tell the LMA > > > > about the MN's whereabouts paves the way to provide other > > features. > > > >=20 > > > > >> then you can simply let the LMA updates the MAG=20 > (instead of the > > > > >> opposite) > > > >=20 > > > > > but I am willing to listen to your theory in a=20 > separate thread! > > > >=20 > > > > =3D> Yes sure. But let summarize it again in few words: > > > > the AAA can tell the LMA where the MN is following a successful=20 > > > > authentication, i.e., at a very early stage, which in turn > > > enables the > > > > LMA to send a PBU to the MAG and updates it with what the > > > MAG needs to > > > > know. > > >=20 > > > [Ahmad] > > > Very interesting! > > >=20 > > > >=20 > > > > In the same PBU, the LMA can include a secret which can be > > > used by the > > > > MAG to provide SeND features to the MN without CGA (so you > > > don't need > > > > CGA). > > > >=20 > > > > > [Ahmad] > > > > > Just FYI: > > > > > 1. A detailed solution for the so called compromised MAG is > > > > out-of-scope. > > > >=20 > > > > =3D> Agree. But from the above you can see that we don't need > > > to create > > > > such problem from the beginning and then claim that it=20 > is out of=20 > > > > scope... > > > >=20 > > > > > 2. The text hint including the AAA has been proposed > > > several times > > > > > before on the ml by different people. > > > >=20 > > > > =3D> which I also agree with and am trying to strech its > > > impact on other > > > > features. > > > >=20 > > > >=20 > > > > Wassim H. > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > >=20 > >=20 > > _______________________________________________ > > netlmm mailing list > > netlmm@ietf.org > > https://www1.ietf.org/mailman/listinfo/netlmm >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 10:48:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbdbS-000453-Ee; Sat, 29 Sep 2007 10:47:34 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbdbR-00044x-Ap for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 10:47:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbdbR-0003e2-1B for netlmm@ietf.org; Sat, 29 Sep 2007 10:47:33 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbdbD-00074S-Gw for netlmm@ietf.org; Sat, 29 Sep 2007 10:47:26 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 5B16F2C020C05; Sat, 29 Sep 2007 17:47:09 +0300 (EEST) Date: Sat, 29 Sep 2007 17:47:09 +0300 (EEST) From: Wassim Haddad To: Ahmad Muhanna Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371170F03E3@zrc2hxm2.corp.nortel.com> Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DE18@zrc2hxm2.corp.nortel.com> <027601c8023a$a6bb9890$1220fea9@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F03E3@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: DE JUAN HUARTE FEDERICO , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, Looks fine to me. Hopefully in the future, "another" final solution will mitigate/eliminate the attack itself! Thanks, Wassim H. On Sat, 29 Sep 2007, Ahmad Muhanna wrote: > > Sri/Vidya and All, > > I believe that we need to stay away from details of how this compromised > MAG issue can be solved. The reason behind this is that, in the future, > and after a thorough investigation of this issue, the final solution may > contradict with the proposed details. Having said that I would recommend > removing all examples and keep enough informative text which does the > following: > > 1. Acknowledge the problem > 2. Recognize that this issue is not a show stopper and can be addressed > by future work item if at all necessary. > 3. Provide informative text which capture the high level indication of a > possible solution. > > Based on this, I would recommend the following text: > > " > To eliminate the threats related to a compromised mobile access > gateway, the local mobility anchor, before accepting a Proxy Binding > Update message for a given mobile node, may ensure that the mobile > node is definitely attached to the mobile access gateway that sent > the proxy binding registration request. This may be accomplished by > contacting a trusted entity which is able to track the mobile node > current point of attachment or validate the provided mobile node > signature. > " > > Thanks. > > Regards, > Ahmad > > >> -----Original Message----- >> From: Sri Gundavelli [mailto:sgundave@cisco.com] >> Sent: Friday, September 28, 2007 8:47 PM >> To: 'Narayanan, Vidya'; Muhanna, Ahmad (RICH1:2H10); 'Wassim Haddad' >> Cc: 'DE JUAN HUARTE FEDERICO'; 'netlmm' >> Subject: RE: Text Proposal for Compromised MAG issue (was >> [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) >> >> It looks fine, except for the CGA part. The CGA generation >> requires the IPv6 subnet prefix and that the mobile node in a >> Proxy Mobile IPv6 domain would not have it before the >> signaling is complete. So, the mobile node would not be able >> to assert the address ownership or infact even generate an >> address until the MAG completes the signaling. This may work >> for subsequent registrations, but not during initial >> attachment in Proxy Mobile IPv6 domain. So, I suggest taking >> out the CGA part and close this issue. >> >> Thanks Ahmad for the text. >> >> >> Sri >> >> >> >> >>> -----Original Message----- >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>> Sent: Friday, September 28, 2007 5:03 PM >>> To: Ahmad Muhanna; Wassim Haddad >>> Cc: DE JUAN HUARTE FEDERICO; netlmm >>> Subject: RE: Text Proposal for Compromised MAG issue (was >>> [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) >>> >>> All, >>> The text proposed by Ahmad mostly looks fine to me, >> although it may be >>> worthwhile providing a hint for how one may do it in a >> non-AAA based >>> system. How about the following (I've taken Ahmad's text and made >>> some minor changes/additions): >>> >>> "To deal with threats related to a compromised mobile >> access gateway, >>> the local mobility anchor, before accepting a Proxy Binding Update >>> message for a given mobile node, may choose to ensure that >> the mobile >>> node is definitively attached to the mobile access >> gateway that sent >>> the binding registration request. This may be done by contacting a >>> trusted entity which tracks the MN current point of >> attachment, e.g. a >>> AAA server (as a result of an authentication exchange with the MN). >>> This may also be accomplished by verification of a live >> signature from >>> the MN, e.g., a CGA signature. Details of how such verification of >>> the MN's point of attachment is done is outside the scope of this >>> specification." >>> >>> I've tried to stay away from any normative language in the text, >>> indicating that we are merely providing examples. >>> >>> Thanks, >>> Vidya >>> >>>> -----Original Message----- >>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >>>> Sent: Friday, September 28, 2007 10:51 AM >>>> To: Wassim Haddad >>>> Cc: DE JUAN HUARTE FEDERICO; netlmm >>>> Subject: RE: Text Proposal for Compromised MAG issue (was >> [netlmm] >>>> Reviewofdraft-ietf-netlmm-proxymip6-05) >>>> >>>> Hi Wassim, >>>> >>>> To be honest, the least to be said about all of this >> compromised MAG >>>> discussion/issue is: May be not necessary and probably a >> lot of time >>>> is wasted:-( I am sorry I misunderstood what you were >> trying to say >>>> earlier, But yes, I see it much clearer now. >>>> >>>> One more comment inline. >>>> >>>> Cheers:) >>>> >>>> Regards, >>>> Ahmad >>>> >>>> >>>>> -----Original Message----- >>>>> From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] >>>>> Sent: Friday, September 28, 2007 12:31 PM >>>>> To: Muhanna, Ahmad (RICH1:2H10) >>>>> Cc: DE JUAN HUARTE FEDERICO; Sri Gundavelli; netlmm >>>>> Subject: RE: Text Proposal for Compromised MAG issue (was >>> [netlmm] >>>>> Review ofdraft-ietf-netlmm-proxymip6-05) >>>>> >>>>> Hi Ahmad, >>>>> >>>>> On Fri, 28 Sep 2007, Ahmad Muhanna wrote: >>>>> >>>>>> [Ahmad] >>>>>> So, can I read this that you think it is impossible and >>>>> does not make sense? >>>>> >>>>> => Not at all! Am saying that having the AAA involved to >>>> tell the LMA >>>>> about the MN's whereabouts paves the way to provide other >>> features. >>>>> >>>>>>> then you can simply let the LMA updates the MAG >> (instead of the >>>>>>> opposite) >>>>> >>>>>> but I am willing to listen to your theory in a >> separate thread! >>>>> >>>>> => Yes sure. But let summarize it again in few words: >>>>> the AAA can tell the LMA where the MN is following a successful >>>>> authentication, i.e., at a very early stage, which in turn >>>> enables the >>>>> LMA to send a PBU to the MAG and updates it with what the >>>> MAG needs to >>>>> know. >>>> >>>> [Ahmad] >>>> Very interesting! >>>> >>>>> >>>>> In the same PBU, the LMA can include a secret which can be >>>> used by the >>>>> MAG to provide SeND features to the MN without CGA (so you >>>> don't need >>>>> CGA). >>>>> >>>>>> [Ahmad] >>>>>> Just FYI: >>>>>> 1. A detailed solution for the so called compromised MAG is >>>>> out-of-scope. >>>>> >>>>> => Agree. But from the above you can see that we don't need >>>> to create >>>>> such problem from the beginning and then claim that it >> is out of >>>>> scope... >>>>> >>>>>> 2. The text hint including the AAA has been proposed >>>> several times >>>>>> before on the ml by different people. >>>>> >>>>> => which I also agree with and am trying to strech its >>>> impact on other >>>>> features. >>>>> >>>>> >>>>> Wassim H. >>>>> >>>> >>>> >>>> _______________________________________________ >>>> netlmm mailing list >>>> netlmm@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/netlmm >>>> >>> >>> >>> _______________________________________________ >>> netlmm mailing list >>> netlmm@ietf.org >>> https://www1.ietf.org/mailman/listinfo/netlmm >> > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 12:08:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IberV-00078v-6P; Sat, 29 Sep 2007 12:08:13 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IberT-00077o-Kg for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 12:08:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IberT-00077b-8X for netlmm@ietf.org; Sat, 29 Sep 2007 12:08:11 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IberS-00011O-82 for netlmm@ietf.org; Sat, 29 Sep 2007 12:08:11 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8TG8249014723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 29 Sep 2007 09:08:03 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8TG81pQ006131; Sat, 29 Sep 2007 09:08:01 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Sep 2007 09:08:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) Date: Sat, 29 Sep 2007 09:08:00 -0700 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371170F03E3@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB9VyUEAd/bxJDSgONgCCgghhYrwAASyfQAA0qlEAAA5FRAAAYxhHgAAWAVTA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DE18@zrc2hxm2.corp.nortel.com> <027601c8023a$a6bb9890$1220fea9@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F03E3@zrc2hxm2.corp.nortel.com> From: "Narayanan, Vidya" To: "Ahmad Muhanna" , "Sri Gundavelli" , "Wassim Haddad" X-OriginalArrivalTime: 29 Sep 2007 16:08:00.0880 (UTC) FILETIME=[E8893700:01C802B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: DE JUAN HUARTE FEDERICO , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Ahmad, This text is fine with me. I'd still like to explicitly state the actual mechanisms are out of scope. One more minor nit in the text: s/eliminate the threat/deal with the threat - I don't believe we are eliminating the threat itself.. We are talking about mitigating the impact of the threat.=20 Thanks, Vidya > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Saturday, September 29, 2007 7:21 AM > To: Sri Gundavelli; Narayanan, Vidya; Wassim Haddad > Cc: DE JUAN HUARTE FEDERICO; netlmm > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) >=20 >=20 > Sri/Vidya and All, >=20 > I believe that we need to stay away from details of how this=20 > compromised MAG issue can be solved. The reason behind this=20 > is that, in the future, and after a thorough investigation of=20 > this issue, the final solution may contradict with the=20 > proposed details. Having said that I would recommend removing=20 > all examples and keep enough informative text which does the > following: >=20 > 1. Acknowledge the problem > 2. Recognize that this issue is not a show stopper and can be=20 > addressed by future work item if at all necessary. > 3. Provide informative text which capture the high level=20 > indication of a possible solution. >=20 > Based on this, I would recommend the following text: >=20 > " > To eliminate the threats related to a compromised mobile access > gateway, the local mobility anchor, before accepting a=20 > Proxy Binding > Update message for a given mobile node, may ensure that the mobile > node is definitely attached to the mobile access gateway that sent > the proxy binding registration request. This may be accomplished by > contacting a trusted entity which is able to track the mobile node > current point of attachment or validate the provided mobile node > signature. > " >=20 > Thanks. >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Friday, September 28, 2007 8:47 PM > > To: 'Narayanan, Vidya'; Muhanna, Ahmad (RICH1:2H10); 'Wassim Haddad' > > Cc: 'DE JUAN HUARTE FEDERICO'; 'netlmm' > > Subject: RE: Text Proposal for Compromised MAG issue (was > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > >=20 > > It looks fine, except for the CGA part. The CGA generation requires=20 > > the IPv6 subnet prefix and that the mobile node in a Proxy=20 > Mobile IPv6=20 > > domain would not have it before the signaling is complete. So, the=20 > > mobile node would not be able to assert the address ownership or=20 > > infact even generate an address until the MAG completes the=20 > signaling.=20 > > This may work for subsequent registrations, but not during initial=20 > > attachment in Proxy Mobile IPv6 domain. So, I suggest=20 > taking out the=20 > > CGA part and close this issue. > >=20 > > Thanks Ahmad for the text. > >=20 > >=20 > > Sri > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Friday, September 28, 2007 5:03 PM > > > To: Ahmad Muhanna; Wassim Haddad > > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > > >=20 > > > All, > > > The text proposed by Ahmad mostly looks fine to me, > > although it may be > > > worthwhile providing a hint for how one may do it in a > > non-AAA based > > > system. How about the following (I've taken Ahmad's text=20 > and made=20 > > > some minor changes/additions): > > >=20 > > > "To deal with threats related to a compromised mobile > > access gateway, > > > the local mobility anchor, before accepting a Proxy=20 > Binding Update=20 > > > message for a given mobile node, may choose to ensure that > > the mobile > > > node is definitively attached to the mobile access=20 > > gateway that sent > > > the binding registration request. This may be done by=20 > contacting a=20 > > > trusted entity which tracks the MN current point of > > attachment, e.g. a > > > AAA server (as a result of an authentication exchange=20 > with the MN). > > > This may also be accomplished by verification of a live > > signature from > > > the MN, e.g., a CGA signature. Details of how such=20 > verification of=20 > > > the MN's point of attachment is done is outside the scope of this=20 > > > specification." > > >=20 > > > I've tried to stay away from any normative language in the text,=20 > > > indicating that we are merely providing examples. > > >=20 > > > Thanks, > > > Vidya > > >=20 > > > > -----Original Message----- > > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > Sent: Friday, September 28, 2007 10:51 AM > > > > To: Wassim Haddad > > > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > [netlmm] > > > > Reviewofdraft-ietf-netlmm-proxymip6-05) > > > >=20 > > > > Hi Wassim, > > > >=20 > > > > To be honest, the least to be said about all of this > > compromised MAG > > > > discussion/issue is: May be not necessary and probably a > > lot of time > > > > is wasted:-( I am sorry I misunderstood what you were > > trying to say > > > > earlier, But yes, I see it much clearer now. > > > >=20 > > > > One more comment inline. > > > >=20 > > > > Cheers:) > > > >=20 > > > > Regards, > > > > Ahmad > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > > > > > Sent: Friday, September 28, 2007 12:31 PM > > > > > To: Muhanna, Ahmad (RICH1:2H10) > > > > > Cc: DE JUAN HUARTE FEDERICO; Sri Gundavelli; netlmm > > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > [netlmm] > > > > > Review ofdraft-ietf-netlmm-proxymip6-05) > > > > >=20 > > > > > Hi Ahmad, > > > > >=20 > > > > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > > > > >=20 > > > > > > [Ahmad] > > > > > > So, can I read this that you think it is impossible and > > > > > does not make sense? > > > > >=20 > > > > > =3D> Not at all! Am saying that having the AAA involved to > > > > tell the LMA > > > > > about the MN's whereabouts paves the way to provide other > > > features. > > > > >=20 > > > > > >> then you can simply let the LMA updates the MAG > > (instead of the > > > > > >> opposite) > > > > >=20 > > > > > > but I am willing to listen to your theory in a > > separate thread! > > > > >=20 > > > > > =3D> Yes sure. But let summarize it again in few words: > > > > > the AAA can tell the LMA where the MN is following a=20 > successful=20 > > > > > authentication, i.e., at a very early stage, which in turn > > > > enables the > > > > > LMA to send a PBU to the MAG and updates it with what the > > > > MAG needs to > > > > > know. > > > >=20 > > > > [Ahmad] > > > > Very interesting! > > > >=20 > > > > >=20 > > > > > In the same PBU, the LMA can include a secret which can be > > > > used by the > > > > > MAG to provide SeND features to the MN without CGA (so you > > > > don't need > > > > > CGA). > > > > >=20 > > > > > > [Ahmad] > > > > > > Just FYI: > > > > > > 1. A detailed solution for the so called compromised MAG is > > > > > out-of-scope. > > > > >=20 > > > > > =3D> Agree. But from the above you can see that we don't need > > > > to create > > > > > such problem from the beginning and then claim that it > > is out of > > > > > scope... > > > > >=20 > > > > > > 2. The text hint including the AAA has been proposed > > > > several times > > > > > > before on the ml by different people. > > > > >=20 > > > > > =3D> which I also agree with and am trying to strech its > > > > impact on other > > > > > features. > > > > >=20 > > > > >=20 > > > > > Wassim H. > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > netlmm mailing list > > > netlmm@ietf.org > > > https://www1.ietf.org/mailman/listinfo/netlmm > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 12:46:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbfSl-00087I-C8; Sat, 29 Sep 2007 12:46:43 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbfSk-00087D-A4 for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 12:46:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbfSk-00085i-0Q for netlmm@ietf.org; Sat, 29 Sep 2007 12:46:42 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbfSZ-0002px-Og for netlmm@ietf.org; Sat, 29 Sep 2007 12:46:37 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l8TGh6a11105; Sat, 29 Sep 2007 16:43:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) Date: Sat, 29 Sep 2007 11:45:34 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371170F0415@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB9VyUEAd/bxJDSgONgCCgghhYrwAASyfQAA0qlEAAA5FRAAAYxhHgAAWAVTAAAKXPcA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DE18@zrc2hxm2.corp.nortel.com> <027601c8023a$a6bb9890$1220fea9@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F03E3@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Sri Gundavelli" , "Wassim Haddad" X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: DE JUAN HUARTE FEDERICO , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Vidya, I do not see any problem in an explicit out-of-scope text. Here is the updated text: " To address the threat related to a compromised mobile access gateway, the local mobility anchor, before accepting a Proxy Binding Update message for a given mobile node, may ensure that the mobile node is definitely attached to the mobile access gateway that sent the proxy binding registration request. This may be accomplished by contacting a trusted entity which is able to track the mobile node current point of attachment or validate the provided mobile node signature. However, the details of actual mechanisms are out of scope. " Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Saturday, September 29, 2007 11:08 AM > To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli; Wassim Haddad > Cc: DE JUAN HUARTE FEDERICO; netlmm > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Ahmad, > This text is fine with me. I'd still like to explicitly state=20 > the actual mechanisms are out of scope. One more minor nit=20 > in the text: > s/eliminate the threat/deal with the threat - I don't believe=20 > we are eliminating the threat itself.. We are talking about=20 > mitigating the impact of the threat.=20 >=20 > Thanks, > Vidya >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Saturday, September 29, 2007 7:21 AM > > To: Sri Gundavelli; Narayanan, Vidya; Wassim Haddad > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > Subject: RE: Text Proposal for Compromised MAG issue (was > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > >=20 > >=20 > > Sri/Vidya and All, > >=20 > > I believe that we need to stay away from details of how this=20 > > compromised MAG issue can be solved. The reason behind this=20 > is that,=20 > > in the future, and after a thorough investigation of this=20 > issue, the=20 > > final solution may contradict with the proposed details.=20 > Having said=20 > > that I would recommend removing all examples and keep enough=20 > > informative text which does the > > following: > >=20 > > 1. Acknowledge the problem > > 2. Recognize that this issue is not a show stopper and can be=20 > > addressed by future work item if at all necessary. > > 3. Provide informative text which capture the high level=20 > indication of=20 > > a possible solution. > >=20 > > Based on this, I would recommend the following text: > >=20 > > " > > To eliminate the threats related to a compromised mobile access > > gateway, the local mobility anchor, before accepting a Proxy=20 > > Binding > > Update message for a given mobile node, may ensure that=20 > the mobile > > node is definitely attached to the mobile access gateway=20 > that sent > > the proxy binding registration request. This may be=20 > accomplished by > > contacting a trusted entity which is able to track the=20 > mobile node > > current point of attachment or validate the provided mobile node > > signature. > > " > >=20 > > Thanks. > >=20 > > Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Friday, September 28, 2007 8:47 PM > > > To: 'Narayanan, Vidya'; Muhanna, Ahmad (RICH1:2H10);=20 > 'Wassim Haddad' > > > Cc: 'DE JUAN HUARTE FEDERICO'; 'netlmm' > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > > >=20 > > > It looks fine, except for the CGA part. The CGA=20 > generation requires=20 > > > the IPv6 subnet prefix and that the mobile node in a Proxy > > Mobile IPv6 > > > domain would not have it before the signaling is=20 > complete. So, the=20 > > > mobile node would not be able to assert the address ownership or=20 > > > infact even generate an address until the MAG completes the > > signaling.=20 > > > This may work for subsequent registrations, but not=20 > during initial=20 > > > attachment in Proxy Mobile IPv6 domain. So, I suggest > > taking out the > > > CGA part and close this issue. > > >=20 > > > Thanks Ahmad for the text. > > >=20 > > >=20 > > > Sri > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > Sent: Friday, September 28, 2007 5:03 PM > > > > To: Ahmad Muhanna; Wassim Haddad > > > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > > > >=20 > > > > All, > > > > The text proposed by Ahmad mostly looks fine to me, > > > although it may be > > > > worthwhile providing a hint for how one may do it in a > > > non-AAA based > > > > system. How about the following (I've taken Ahmad's text > > and made > > > > some minor changes/additions): > > > >=20 > > > > "To deal with threats related to a compromised mobile > > > access gateway, > > > > the local mobility anchor, before accepting a Proxy > > Binding Update > > > > message for a given mobile node, may choose to ensure that > > > the mobile > > > > node is definitively attached to the mobile access=20 > > > gateway that sent > > > > the binding registration request. This may be done by > > contacting a > > > > trusted entity which tracks the MN current point of > > > attachment, e.g. a > > > > AAA server (as a result of an authentication exchange > > with the MN). > > > > This may also be accomplished by verification of a live > > > signature from > > > > the MN, e.g., a CGA signature. Details of how such > > verification of > > > > the MN's point of attachment is done is outside the=20 > scope of this=20 > > > > specification." > > > >=20 > > > > I've tried to stay away from any normative language in=20 > the text,=20 > > > > indicating that we are merely providing examples. > > > >=20 > > > > Thanks, > > > > Vidya > > > >=20 > > > > > -----Original Message----- > > > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > > Sent: Friday, September 28, 2007 10:51 AM > > > > > To: Wassim Haddad > > > > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > [netlmm] > > > > > Reviewofdraft-ietf-netlmm-proxymip6-05) > > > > >=20 > > > > > Hi Wassim, > > > > >=20 > > > > > To be honest, the least to be said about all of this > > > compromised MAG > > > > > discussion/issue is: May be not necessary and probably a > > > lot of time > > > > > is wasted:-( I am sorry I misunderstood what you were > > > trying to say > > > > > earlier, But yes, I see it much clearer now. > > > > >=20 > > > > > One more comment inline. > > > > >=20 > > > > > Cheers:) > > > > >=20 > > > > > Regards, > > > > > Ahmad > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > > > > > > Sent: Friday, September 28, 2007 12:31 PM > > > > > > To: Muhanna, Ahmad (RICH1:2H10) > > > > > > Cc: DE JUAN HUARTE FEDERICO; Sri Gundavelli; netlmm > > > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > > [netlmm] > > > > > > Review ofdraft-ietf-netlmm-proxymip6-05) > > > > > >=20 > > > > > > Hi Ahmad, > > > > > >=20 > > > > > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > > > > > >=20 > > > > > > > [Ahmad] > > > > > > > So, can I read this that you think it is impossible and > > > > > > does not make sense? > > > > > >=20 > > > > > > =3D> Not at all! Am saying that having the AAA involved to > > > > > tell the LMA > > > > > > about the MN's whereabouts paves the way to provide other > > > > features. > > > > > >=20 > > > > > > >> then you can simply let the LMA updates the MAG > > > (instead of the > > > > > > >> opposite) > > > > > >=20 > > > > > > > but I am willing to listen to your theory in a > > > separate thread! > > > > > >=20 > > > > > > =3D> Yes sure. But let summarize it again in few words: > > > > > > the AAA can tell the LMA where the MN is following a > > successful > > > > > > authentication, i.e., at a very early stage, which in turn > > > > > enables the > > > > > > LMA to send a PBU to the MAG and updates it with what the > > > > > MAG needs to > > > > > > know. > > > > >=20 > > > > > [Ahmad] > > > > > Very interesting! > > > > >=20 > > > > > >=20 > > > > > > In the same PBU, the LMA can include a secret which can be > > > > > used by the > > > > > > MAG to provide SeND features to the MN without CGA (so you > > > > > don't need > > > > > > CGA). > > > > > >=20 > > > > > > > [Ahmad] > > > > > > > Just FYI: > > > > > > > 1. A detailed solution for the so called=20 > compromised MAG is > > > > > > out-of-scope. > > > > > >=20 > > > > > > =3D> Agree. But from the above you can see that we don't = need > > > > > to create > > > > > > such problem from the beginning and then claim that it > > > is out of > > > > > > scope... > > > > > >=20 > > > > > > > 2. The text hint including the AAA has been proposed > > > > > several times > > > > > > > before on the ml by different people. > > > > > >=20 > > > > > > =3D> which I also agree with and am trying to strech its > > > > > impact on other > > > > > > features. > > > > > >=20 > > > > > >=20 > > > > > > Wassim H. > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > netlmm mailing list > > > > netlmm@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > >=20 > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 13:11:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibfqb-0006as-M8; Sat, 29 Sep 2007 13:11:21 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbfqZ-0006Zl-Ry for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 13:11:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbfqZ-0006We-H6 for netlmm@ietf.org; Sat, 29 Sep 2007 13:11:19 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbfqW-0002kb-Tp for netlmm@ietf.org; Sat, 29 Sep 2007 13:11:17 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8THBEI7018049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 29 Sep 2007 10:11:15 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8THBEZ3028701; Sat, 29 Sep 2007 10:11:14 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Sep 2007 10:11:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [netlmm] Issue: Prefix allocation and multihomed MNs (Problem Description Take 2) Date: Sat, 29 Sep 2007 10:11:13 -0700 Message-ID: In-Reply-To: <028301c80263$d8904310$1220fea9@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Issue: Prefix allocation and multihomed MNs (Problem Description Take 2) Thread-Index: AcgAgnO7q8W1xBQcQoq2l5PSIk/sWwAFAt1AAAPav7AABiTEQAAPtdxgAASDU/AABmLVoAAAItAwAACXaRAAAFIfSQAFTWoQAEIm9dMABNo5MAAAM+YAABYqVcA= References: <028301c80263$d8904310$1220fea9@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" X-OriginalArrivalTime: 29 Sep 2007 17:11:14.0092 (UTC) FILETIME=[BD776EC0:01C802BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: netlmm@ietf.org X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org All,=20 I think several people have understood the problem we are discussing here, but, there still seems to be some confusion. Here is a second attempt at describing the problem, this time in some more detail:=20 * MN has two interfaces attached to MAG1 and MAG2 under the same LMA * Let's say MAG1 first created the binding at the LMA and acquired a prefix/address for the MN, using MN-ID1 * MN obtains the prefix/address on Interface1; if the MN is using DHCP, it will only get an address (since there is no requirement on the MN to do DHCP-PD) * MAG2 now sends a PBU with MN-ID1 also (very possible when the ID is something like an NAI) * LMA thinks the MN moved, updates the binding and returns the same prefix for the MN to MAG2 * MN receives the same prefix/address via DHCP or RA over Interface2; MN detects a duplicate address and per RFC2462, does not configure that address on Interface2; Interface2 is now not enabled for IP forwarding;=20 * If the MN is using stateless autoconfiguration, it may end up with a different address for Interface2; in this case, Interface2 is enabled; the assigned prefix, however, is no longer just over a point-to-point link, although, the MAG thinks it is * The LMA has a binding for MAG2 (corresponding to Interface2) * If the MN never enabled Interface2 due to duplicate address issues, the MN will try to use Interface1, but, unsuccessfully, since the LMA will drop those packets; LMA will send packets to MAG2 (Interface2), which will not be received by the MN * If the MN has enabled Interface2 with a different address, depending on the implementation, the MN may use Interface1 or Interface2 (some OSs will just pick one); any communication attempted via Interface 1 will fail * In the meantime, the binding may keep toggling between MAG1 and MAG2 at the LMA, due to corresponding PBUs received; the MN may have intermittent connectivity as a result of this I've tried going through this issue with several developers and everyone agress that this problem exists for unmodified IP hosts. Several people have acknowledged that on this list as well (as part of this thread and also discussions back in early August). =20 Among those who believe there is no issue here, I'd appreciate if someone could walk through the steps and explain why this is not a technical issue and how the MN can use at least one interface for stable IP connectivity. =20 I'm as eager to close this thread as anyone. I don't see a solution other than ensuring that separate IP addresses/prefixes are assigned to each interface and that those are treated as separate PMIP sessions. I look forward to either hearing why this is not a problem or possible solutions to it.=20 Thanks, Vidya _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sat Sep 29 13:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbfrU-0007Zp-8K; Sat, 29 Sep 2007 13:12:16 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1IbfrS-0007XZ-Du for netlmm-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 13:12:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbfrR-0007XR-PK for netlmm@ietf.org; Sat, 29 Sep 2007 13:12:13 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbfrQ-0002ln-HZ for netlmm@ietf.org; Sat, 29 Sep 2007 13:12:13 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l8THC6sW005584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 29 Sep 2007 10:12:07 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l8THC5v2028782; Sat, 29 Sep 2007 10:12:05 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Sep 2007 10:12:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) Date: Sat, 29 Sep 2007 10:12:04 -0700 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371170F0415@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Text Proposal for Compromised MAG issue (was [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgB9VyUEAd/bxJDSgONgCCgghhYrwAASyfQAA0qlEAAA5FRAAAYxhHgAAWAVTAAAKXPcAABqq0Q References: <6FC4416DDE56C44DA0AEE67BC7CA43711704A52F@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399ADE@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711704A70E@zrc2hxm2.corp.nortel.com><319D54578EAC3147BA8CC78DAB5467A501399AF5@FRVELSMBS12.ad2.ad.alcatel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DC1B@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711709DE18@zrc2hxm2.corp.nortel.com> <027601c8023a$a6bb9890$1220fea9@amer.cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F03E3@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA4371170F0415@zrc2hxm2.corp.nortel.com> From: "Narayanan, Vidya" To: "Ahmad Muhanna" , "Sri Gundavelli" , "Wassim Haddad" X-OriginalArrivalTime: 29 Sep 2007 17:12:05.0689 (UTC) FILETIME=[DC388290:01C802BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: DE JUAN HUARTE FEDERICO , netlmm X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Thanks, Ahmad.=20 Regards, Vidya=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Saturday, September 29, 2007 9:46 AM > To: Narayanan, Vidya; Sri Gundavelli; Wassim Haddad > Cc: DE JUAN HUARTE FEDERICO; netlmm > Subject: RE: Text Proposal for Compromised MAG issue (was=20 > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) >=20 > Hi Vidya, >=20 > I do not see any problem in an explicit out-of-scope text.=20 > Here is the updated text: >=20 > " > To address the threat related to a compromised mobile=20 > access gateway, > the local mobility anchor, before accepting a Proxy Binding Update > message for a given mobile node, may ensure that the mobile node is > definitely attached to the mobile access gateway that sent=20 > the proxy > binding registration request. This may be accomplished by=20 > contacting > a trusted entity which is able to track the mobile node=20 > current point > of attachment or validate the provided mobile node signature. > However, the details of actual mechanisms are out of scope. > " >=20 > Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Saturday, September 29, 2007 11:08 AM > > To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli; Wassim Haddad > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > Subject: RE: Text Proposal for Compromised MAG issue (was > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > >=20 > > Hi Ahmad, > > This text is fine with me. I'd still like to explicitly state the=20 > > actual mechanisms are out of scope. One more minor nit in the text: > > s/eliminate the threat/deal with the threat - I don't=20 > believe we are=20 > > eliminating the threat itself.. We are talking about mitigating the=20 > > impact of the threat. > >=20 > > Thanks, > > Vidya > >=20 > > > -----Original Message----- > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > Sent: Saturday, September 29, 2007 7:21 AM > > > To: Sri Gundavelli; Narayanan, Vidya; Wassim Haddad > > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > > >=20 > > >=20 > > > Sri/Vidya and All, > > >=20 > > > I believe that we need to stay away from details of how this=20 > > > compromised MAG issue can be solved. The reason behind this > > is that, > > > in the future, and after a thorough investigation of this > > issue, the > > > final solution may contradict with the proposed details.=20 > > Having said > > > that I would recommend removing all examples and keep enough=20 > > > informative text which does the > > > following: > > >=20 > > > 1. Acknowledge the problem > > > 2. Recognize that this issue is not a show stopper and can be=20 > > > addressed by future work item if at all necessary. > > > 3. Provide informative text which capture the high level > > indication of > > > a possible solution. > > >=20 > > > Based on this, I would recommend the following text: > > >=20 > > > " > > > To eliminate the threats related to a compromised mobile access > > > gateway, the local mobility anchor, before accepting a Proxy=20 > > > Binding > > > Update message for a given mobile node, may ensure that > > the mobile > > > node is definitely attached to the mobile access gateway > > that sent > > > the proxy binding registration request. This may be > > accomplished by > > > contacting a trusted entity which is able to track the > > mobile node > > > current point of attachment or validate the provided=20 > mobile node > > > signature. > > > " > > >=20 > > > Thanks. > > >=20 > > > Regards, > > > Ahmad > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > Sent: Friday, September 28, 2007 8:47 PM > > > > To: 'Narayanan, Vidya'; Muhanna, Ahmad (RICH1:2H10); > > 'Wassim Haddad' > > > > Cc: 'DE JUAN HUARTE FEDERICO'; 'netlmm' > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > > > >=20 > > > > It looks fine, except for the CGA part. The CGA > > generation requires > > > > the IPv6 subnet prefix and that the mobile node in a Proxy > > > Mobile IPv6 > > > > domain would not have it before the signaling is > > complete. So, the > > > > mobile node would not be able to assert the address=20 > ownership or=20 > > > > infact even generate an address until the MAG completes the > > > signaling.=20 > > > > This may work for subsequent registrations, but not > > during initial > > > > attachment in Proxy Mobile IPv6 domain. So, I suggest > > > taking out the > > > > CGA part and close this issue. > > > >=20 > > > > Thanks Ahmad for the text. > > > >=20 > > > >=20 > > > > Sri > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > > Sent: Friday, September 28, 2007 5:03 PM > > > > > To: Ahmad Muhanna; Wassim Haddad > > > > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > > > [netlmm]Reviewofdraft-ietf-netlmm-proxymip6-05) > > > > >=20 > > > > > All, > > > > > The text proposed by Ahmad mostly looks fine to me, > > > > although it may be > > > > > worthwhile providing a hint for how one may do it in a > > > > non-AAA based > > > > > system. How about the following (I've taken Ahmad's text > > > and made > > > > > some minor changes/additions): > > > > >=20 > > > > > "To deal with threats related to a compromised mobile > > > > access gateway, > > > > > the local mobility anchor, before accepting a Proxy > > > Binding Update > > > > > message for a given mobile node, may choose to ensure that > > > > the mobile > > > > > node is definitively attached to the mobile access=20 > > > > gateway that sent > > > > > the binding registration request. This may be done by > > > contacting a > > > > > trusted entity which tracks the MN current point of > > > > attachment, e.g. a > > > > > AAA server (as a result of an authentication exchange > > > with the MN). > > > > > This may also be accomplished by verification of a live > > > > signature from > > > > > the MN, e.g., a CGA signature. Details of how such > > > verification of > > > > > the MN's point of attachment is done is outside the > > scope of this > > > > > specification." > > > > >=20 > > > > > I've tried to stay away from any normative language in > > the text, > > > > > indicating that we are merely providing examples. > > > > >=20 > > > > > Thanks, > > > > > Vidya > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > > > Sent: Friday, September 28, 2007 10:51 AM > > > > > > To: Wassim Haddad > > > > > > Cc: DE JUAN HUARTE FEDERICO; netlmm > > > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > > [netlmm] > > > > > > Reviewofdraft-ietf-netlmm-proxymip6-05) > > > > > >=20 > > > > > > Hi Wassim, > > > > > >=20 > > > > > > To be honest, the least to be said about all of this > > > > compromised MAG > > > > > > discussion/issue is: May be not necessary and probably a > > > > lot of time > > > > > > is wasted:-( I am sorry I misunderstood what you were > > > > trying to say > > > > > > earlier, But yes, I see it much clearer now. > > > > > >=20 > > > > > > One more comment inline. > > > > > >=20 > > > > > > Cheers:) > > > > > >=20 > > > > > > Regards, > > > > > > Ahmad > > > > > > =20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Wassim Haddad [mailto:whaddad@tcs.hut.fi] > > > > > > > Sent: Friday, September 28, 2007 12:31 PM > > > > > > > To: Muhanna, Ahmad (RICH1:2H10) > > > > > > > Cc: DE JUAN HUARTE FEDERICO; Sri Gundavelli; netlmm > > > > > > > Subject: RE: Text Proposal for Compromised MAG issue (was > > > > > [netlmm] > > > > > > > Review ofdraft-ietf-netlmm-proxymip6-05) > > > > > > >=20 > > > > > > > Hi Ahmad, > > > > > > >=20 > > > > > > > On Fri, 28 Sep 2007, Ahmad Muhanna wrote: > > > > > > >=20 > > > > > > > > [Ahmad] > > > > > > > > So, can I read this that you think it is impossible and > > > > > > > does not make sense? > > > > > > >=20 > > > > > > > =3D> Not at all! Am saying that having the AAA involved = to > > > > > > tell the LMA > > > > > > > about the MN's whereabouts paves the way to provide other > > > > > features. > > > > > > >=20 > > > > > > > >> then you can simply let the LMA updates the MAG > > > > (instead of the > > > > > > > >> opposite) > > > > > > >=20 > > > > > > > > but I am willing to listen to your theory in a > > > > separate thread! > > > > > > >=20 > > > > > > > =3D> Yes sure. But let summarize it again in few words: > > > > > > > the AAA can tell the LMA where the MN is following a > > > successful > > > > > > > authentication, i.e., at a very early stage, which in turn > > > > > > enables the > > > > > > > LMA to send a PBU to the MAG and updates it with what the > > > > > > MAG needs to > > > > > > > know. > > > > > >=20 > > > > > > [Ahmad] > > > > > > Very interesting! > > > > > >=20 > > > > > > >=20 > > > > > > > In the same PBU, the LMA can include a secret which can be > > > > > > used by the > > > > > > > MAG to provide SeND features to the MN without CGA (so you > > > > > > don't need > > > > > > > CGA). > > > > > > >=20 > > > > > > > > [Ahmad] > > > > > > > > Just FYI: > > > > > > > > 1. A detailed solution for the so called > > compromised MAG is > > > > > > > out-of-scope. > > > > > > >=20 > > > > > > > =3D> Agree. But from the above you can see that we=20 > don't need > > > > > > to create > > > > > > > such problem from the beginning and then claim that it > > > > is out of > > > > > > > scope... > > > > > > >=20 > > > > > > > > 2. The text hint including the AAA has been proposed > > > > > > several times > > > > > > > > before on the ml by different people. > > > > > > >=20 > > > > > > > =3D> which I also agree with and am trying to strech its > > > > > > impact on other > > > > > > > features. > > > > > > >=20 > > > > > > >=20 > > > > > > > Wassim H. > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > netlmm mailing list > > > > > > netlmm@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > netlmm mailing list > > > > > netlmm@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/netlmm > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sun Sep 30 18:32:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic7Jt-0007RO-6c; Sun, 30 Sep 2007 18:31:25 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ic7Js-0007RD-1C for netlmm-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 18:31:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic7Jr-0007Ph-La for netlmm@ietf.org; Sun, 30 Sep 2007 18:31:23 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ic7Jr-00067k-0U for netlmm@ietf.org; Sun, 30 Sep 2007 18:31:23 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8UMUeQX000481; Mon, 1 Oct 2007 01:31:09 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 01:31:02 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Sep 2007 17:30:59 -0500 Received: from 10.241.59.229 ([10.241.59.229]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Sep 2007 22:30:59 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sun, 30 Sep 2007 17:31:08 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Proposed text for resolving the multi-homed host issue Thread-Index: AcgDsZhX1vrDtG+kEdyWRQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Sep 2007 22:30:59.0689 (UTC) FILETIME=[9362F590:01C803B1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Vijay Devarapalli Subject: [netlmm] Proposed text for resolving the multi-homed host issue X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hello, Below is proposed text for resolving the current impasse on the multi-homed host issue. At this time, we do not seem to be making much headway on closing this issue. We (authors) recognize the issue... But we believe that a complete solution to the problem needs to be dealt with separately and hence it is perfectly okay to state that it is out-of-scope of this specification. The WG can decide to work on the issue as a separate effort. The proposed text will hopefully be sufficient to close this issue and move forward. Else we would like to request the chairs to get consensus from the WG on the proposed text. " Sec x.y TBD A mobile node which has multiple interfaces may attach to different MAGs in a Proxy Mobile IPv6 domain simultaneously. If the mobile node is identified by a common MN-ID, the LMA will receive multiple proxy Binding Updates from the MAGs to which the mobile node is attached to via its multiple interfaces. The LMA cannot differentiate whether the Proxy Binding Update from the second MAG is a result of: a. the mobile node performing a handoff or b. the mobile node attaching via a second interface to another MAG in the Proxy Mobile IPv6 domain. A host which receives the same prefix from different access routers (i.e MAGs) may end up with duplicate addresses being configured on the interfaces when IPv6 stateless address auto-configuration is used and not based on a unique ID such as an L2 identifier. The behavior of the mobile node in such a scenario is unpredictable as it depends on the implementation of how duplicate addresses on the interfaces of the host are handled. Therefore this behavior of a multi-homed host attaching to a Proxy Mobile IP6 domain via multiple interfaces is implementation dependent and out-of-scope for this document. As far as this document is concerned, the LMA maintains only a single binding cache entry for the mobile node at any given time. This binding cache will have the IP address of the MAG that last sent a successful Proxy Binding Update as the care-of address. Since the mobile node is attached to multiple MAGs, each MAG will keep attempting to refresh the binding cache entry in the LMA. This will cause the binding cache entry for the mobile node in the LMA to keep oscillating between MAGs. This situation becomes recoverable if the mobile node turns off one of the interfaces or if the LMA instructs one of the MAGs to stop sending proxy BUs for the mobile node. In the context of this document, where no changes or enhancements to the mobile node are possible, a complete solution for multi-homed hosts is considered to be out-of-scope. " -Raj _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sun Sep 30 18:41:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic7Tw-0000h4-7U; Sun, 30 Sep 2007 18:41:48 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ic7Tu-0000gN-D0 for netlmm-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 18:41:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic7Tu-0000gD-3U for netlmm@ietf.org; Sun, 30 Sep 2007 18:41:46 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic7To-0003i1-Km for netlmm@ietf.org; Sun, 30 Sep 2007 18:41:46 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8UMfLsf022008; Mon, 1 Oct 2007 01:41:22 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Oct 2007 01:40:56 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Sep 2007 17:40:53 -0500 Received: from 10.241.59.229 ([10.241.59.229]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Sep 2007 22:40:53 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Sun, 30 Sep 2007 17:41:02 -0500 Subject: Re: Default router and new MAG (Was: [netlmm] Suresh's review ofdraft-ietf-netlmm-proxymip6-05) From: Basavaraj Patil To: Sri Gundavelli , "'Julien Laganier'" , Message-ID: Thread-Topic: Default router and new MAG (Was: [netlmm] Suresh's review ofdraft-ietf-netlmm-proxymip6-05) Thread-Index: AcgBALsO/n3LKzJ9QkSVVvF8NxCxRwAEHRhQAAbWaZgAAAxPMAChkAXv In-Reply-To: <00bb01c8012d$96993c00$1220fea9@amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Sep 2007 22:40:53.0695 (UTC) FILETIME=[F57114F0:01C803B2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org On 9/27/07 12:41 PM, "ext Sri Gundavelli" wrote: > Raj, > >>> >>> Thanks. This is very important. I can add a reference to this. >>> Probably, a good reason to enable to DNAv6 on the MN. >> >> We cannot be having any requirements on the MN. So lets not >> start saying >> that the MN should enable DNAv6 or expect it to do anything >> new for it to >> work in a PMIP domain. >> > > > We are not mandating DNAv6. Its informational. If MN has DNAv6 > stack, it can flush the old AR entry immediatly. That is very > important. Do you see any issue, stating that point ? Nope... Its fine to mention it as long as it is not required or mandated. -Raj > > Sri _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm From netlmm-bounces@ietf.org Sun Sep 30 20:18:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic8yH-0001bf-N4; Sun, 30 Sep 2007 20:17:13 -0400 Received: from netlmm by megatron.ietf.org with local (Exim 4.43) id 1Ic8yH-0001ba-31 for netlmm-confirm+ok@megatron.ietf.org; Sun, 30 Sep 2007 20:17:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic8yG-0001av-KD for netlmm@ietf.org; Sun, 30 Sep 2007 20:17:12 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ic8yB-000098-MX for netlmm@ietf.org; Sun, 30 Sep 2007 20:17:08 -0400 Received: from [127.0.0.1] ([67.180.82.252]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Sep 2007 17:17:06 -0700 Message-ID: <47003C7F.30008@azairenet.com> Date: Sun, 30 Sep 2007 17:17:03 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2007 00:17:06.0532 (UTC) FILETIME=[66521A40:01C803C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: netlmm@ietf.org Subject: [netlmm] Re: Proposed text for resolving the multi-homed host issue X-BeenThere: netlmm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NETLMM working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: netlmm-bounces@ietf.org Hi Raj, Further changes. I don't think a typical host implementation would assign the same address to two different interfaces. Here is the new text. Folks, please comment on the following text. A mobile node which has multiple interfaces may attach to different MAGs in a Proxy Mobile IPv6 domain simultaneously. If the mobile node is identified by a common MN-ID, the LMA will receive multiple proxy Binding Updates from the MAGs to which the mobile node is attached to via its multiple interfaces. The LMA cannot differentiate whether the Proxy Binding Update from a given MAG is a result of the mobile node performing a handoff or if the mobile node attaching via a second interface to another MAG in the Proxy Mobile IPv6 domain. Since the mobile node is attached to the same Proxy Mobile IPv6 domain with both interfaces, it may receive the same prefix on both interfaces. Typical host implementations do not allow assigning the same address to two different interfaces. If the mobile node performs IPv6 stateless address auto-configuration using different interface identifiers, then it would end up with different addresses from the same prefix on the two interfaces. Then it becomes a multi-homed host in the Proxy Mobile IPv6 domain. As far as this document is concerned, the LMA maintains only a single binding cache entry for the mobile node at any given time. This binding cache entry will have the IP address of the MAG that last sent successful Proxy Binding Update as the care-of address. Since the mobile node is attached to multiple MAGs, each MAG will keep attempting to refresh the binding cache entry in the LMA. This will cause the binding cache entry for the mobile node in the LMA to keep oscillating between MAGs. This situation becomes recoverable if the mobile node turns of the one of the interfaces or if the LMA instructs one of the MAGs to stop sending proxy BUs for the mobile node. In the context of this document, where no changes or enhancements to the mobile node are possible, a complete solution for multi-homed hosts is considered to be out-of-scope. Vijay Basavaraj Patil wrote: > Hello, > > Below is proposed text for resolving the current impasse on the multi-homed > host issue. > > At this time, we do not seem to be making much headway on closing this > issue. We (authors) recognize the issue... But we believe that a complete > solution to the problem needs to be dealt with separately and hence it is > perfectly okay to state that it is out-of-scope of this specification. The > WG can decide to work on the issue as a separate effort. > > The proposed text will hopefully be sufficient to close this issue and move > forward. Else we would like to request the chairs to get consensus from the > WG on the proposed text. > > " > > Sec x.y TBD > > A mobile node which has multiple interfaces may attach to different > MAGs in a Proxy Mobile IPv6 domain simultaneously. If the mobile node > is identified by a common MN-ID, the LMA will receive multiple proxy > Binding Updates from the MAGs to which the mobile node is attached to > via its multiple interfaces. The LMA cannot differentiate whether the > Proxy Binding Update from the second MAG is a result of: > a. the mobile node performing a handoff or > b. the mobile node attaching via a second interface to another > MAG in the Proxy Mobile IPv6 domain. > > A host which receives the same prefix from different access routers > (i.e MAGs) may end up with duplicate addresses being configured on the > interfaces when IPv6 stateless address auto-configuration is used and > not based on a unique ID such as an L2 identifier. The behavior of the > mobile node in such a scenario is unpredictable as it depends on the > implementation of how duplicate addresses on the interfaces of the > host are handled. Therefore this behavior of a multi-homed host > attaching to a Proxy Mobile IP6 domain via multiple interfaces is > implementation dependent and out-of-scope for this document. > > As far as this document is concerned, the LMA maintains only a single > binding cache entry for the mobile node at any given time. This > binding cache will have the IP address of the MAG that last sent > a successful Proxy Binding Update as the care-of address. Since the > mobile node is attached to multiple MAGs, each MAG will keep > attempting to refresh the binding cache entry in the LMA. This will > cause the binding cache entry for the mobile node in the LMA to keep > oscillating between MAGs. This situation becomes recoverable if the > mobile node turns off one of the interfaces or if the LMA instructs > one of the MAGs to stop sending proxy BUs for the mobile node. > > In the context of this document, where no changes or enhancements to > the mobile node are possible, a complete solution for multi-homed > hosts is considered to be out-of-scope. > " > > -Raj > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm