From nemo-bounces@ietf.org Thu Dec 01 00:29:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehh0A-00083o-6w; Thu, 01 Dec 2005 00:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehh09-00083j-Lb for nemo@megatron.ietf.org; Thu, 01 Dec 2005 00:29:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20673 for ; Thu, 1 Dec 2005 00:28:15 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhhKW-0007Eh-1w for nemo@ietf.org; Thu, 01 Dec 2005 00:50:08 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 3271B4D83C for ; Thu, 1 Dec 2005 14:28:40 +0900 (JST) Date: Thu, 1 Dec 2005 14:28:29 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt Message-Id: <20051201142829.090c8b38.ernst@sfc.wide.ad.jp> In-Reply-To: <1132917036.11586.207.camel@localhost> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.camel@localhost> <20051125190058.7f5d24db.ernst@sfc.wide.ad.jp> <1132917036.11586.207.camel@localhost> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, > > > > because Mobile IPv6 defines its own Route Optimization > > > > mechanism in its base protocol suite as a standard, > > > > collaboration with this and NEMO brings various complexity. > > > > > > > > NEMO = NEMO Basic Support ? > > > > > > I don't so. I think the text's intent was to refer to NEMO RO > > > (and possibly Basic as well). > > > > So, you may write "NEMO RO" not just "NEMO". > > I need the co-author who wrote this text to confirm, but if the > intention was indeed to imply NEMO-RO and NEMO Basic, then I will keep > NEMO. If it was only one of them, of-course we would switch to that. But this would still not tell the reader if you are speaking about the "NEMO protocols" (taking all you may think about) or the NEMO concept, or the NEMO configurations, or just as a standalone term to describe a network that moves. I mean, I don't know what NEMO stands for in this sentence. > > > > 4.5. Detection of New Functionalities > > > > > > > > Is this an issue ? Isn't there a better place ? > > > > > > Like? > > > > For me it looks more like a requirement than an issue. > > > > I am unwillingly to write a "Requirements" section, for fear of being > accused trying to sneak in requirements for RO in a problem statement > draft. I would have it remained in the "Issues" section. If you feel > that "Issue" has a more specific meaning, then I would change the > title of this section to "General Considerations". This is a comment on naming the section "Issues" vs something else, not on section 4.5 specifically: OK with your comment, so another term could be"design goals" which is a smoother work for"requirements". But this is just an editorial suggestion, you guys kwow how it's the best for you to present things. I'm fine with both. > > > > 4.7. Mobility Transparency and Location Privacy > > > > > > > > One advantage of NEMO Basic Support is that the Correspondent > > > > Nodes and Mobile Network Nodes need not be aware of the > > > > actual location and mobility of the mobile network. With > > > > Route Optimization, it might be necessary to reveal the point > > > > of attachment of the Mobile Router to other nodes, such as > > > > the Mobile Network Nodes or their Correspondent Nodes. This > > > > may mean a tradeoff between location privacy [17] (and > > > > mobility transparency) and Route Optimization. > > > > > > > > Agree with location privacy, but mobility may still be > > > > transparent to MNNs. You shouldn't group these > > > > issues/requirements togethers. > > > > > > > > > > The previous sentence read "necessary to reveal ... such as the > > > MNNs or their CNs". For MNNs, its mobility transparency. For > > > CNs, its location privacy. We could of-course break it into two > > > parts, but they stamped from the same thing: requiring the MR > > > reveal its location to some other nodes. > > > > I don't buy that "location privacy" is defined the way you seem to > > define it. Location Privacy is about not providing my location to my > > peers, not about not knowing where I am ! > > I don't see the difference between your interpretation and mine. > > "Location Privacy is about not providing my location to my peers" is > equivalent to how I see it: "For CNs, its location privacy". > > "about not knowing where I am" is equivalent to how I see it "For MNN, > its mobility transparency". > > > I advocate an independent paragraph on "mobility transparency" with > > text taken from 4.7 and 4.3. > > > I could attempt a split and get back to you. My feeling is that the > text will be largely similar (which is why I made the editorial > decision not to split). Please note that we are NOT trying to say > location privacy = mobility transparency. They are clearly distinct > considerations. It is just that I feel that the text describing the > two has so much overlapping that I grouped them into one sub-section. > In the text, we have clearly use the terms location privacy and > mobility transparent distinctly so that it shouldn't create the > impression that they are the same thing (which apparently, we failed, > judging on your comments). I guess your definition of "mobility transparency" and yours are different. Mine is contained in draft-ietf-nemo-requiremnents 3.3. Network Mobility Support Transparency. A MNN can be aware of its location while "mobility transparency" is enforced. So, this is why I'm saying "mobility transparency" and "location privacy" are orthogonal and should be dealt with in distinct sections. > > > > Using the Mobile Network Prefix would usually mean that the > > > > initiator is the Mobile Router, and has the benefit of > > > > binding numerous Mobile Network Nodes with one signaling. > > > > However, it also means that if location privacy is > > > > compromised, the location privacy of an entire Mobile Network > > > > Prefix will be compromised. > > > > > > > > s / will / would > > > > > > > > > > That is subjective I think. But no harm changing :) > > > > Native English speakers will correct me if I'm wrong but I've learnt > > that the future tense cannot be used after words like "if, when, > > after,.." etc. > > > > I am not a native english speaker, but I think I have heard > expressions such as "if you XXX, I will kill you!" numerous times :). > I think your rule refers to the "XXX" part (e.g. there is no "If you > will do ..."), not the "then" part. Isn't it "if you XXXX, I kill you!" ? BTW, English being used by so many non-native English speakers in the world, I wouldn't be surprised to see the same mistake in loads of documents. I guess no native English speaker reads this tread, otherwise we would be fixed already ;-) > > > > 5.5. How is Mobile Network Node's Address Bound to Location? > > > > This approach has the advantage of keeping the > > > > implementations of Correspondent Nodes unchanged. > > > > However, it requires the root Mobile Router to act as a > > > > Neighbor Discovery proxy for all the Mobile Network Nodes > > > > that are directly or indirectly attached to it. This > > > > increases the processing load of the root Mobile Router. > > > > In addition, a change in the point of attachment of the > > > > root Mobile Router will require every nested Mobile Router > > > > (and possibly Visiting Mobile Nodes) to change their > > > > care-of addresses. Not only will this cause a burst of > > > > Binding Updates where every Mobile Router and every > > > > Visiting Mobile Node start sending Binding Updates to > > > > their Correspondent Entities, it will also cause a burst > > > > of Duplicate Address Discovery messages to be exchanged > > > > between the mobile network and the access network. > > > > Furthermore, route optimization for Local Fixed Nodes is > > > > not possible without new functionalities implemented on > > > > the Local Fixed Nodes. > > > > > > > > At LFNs, these are functionalities not related to mobility > > > > support. I think we need to draw a line between mobility-related > > > > functionalities and other. The other ones could be referred to > > > > as"requirements" to distinguish between the two. > > > > > > > > > > What are functionalities required for mobility support then? > > > > A mechanism to send a BU is a mobility support functionality. A > > DHCP functionality is not a mobility support functionality. DHCP is > > useful for any node, fixed or mobile, in a fixed network or a mobile > > network which needs a dynamic address. > > Agree, but the text is about mechanism to send BU for LFN. Sure , for > ND-proxy, you can always used DHCP or similar to have the LFN change > their addreses. That is not mobility. However, this defeats the > purpose of NEMO. The ideal of NEMO is so that MNNs can retain their > original source address. So, the LFN we have would need some mobility > management functionality in order to enjoy the benefits of RO, which > is precise what we meant by "Furthermore, route optimization for Local > Fixed Nodes is not possible without new functionalities implemented on > the Local Fixed Nodes". The text doens't say nor assumes that LFNs send BUs,. The MR sends the BU. So, what kind of mobility management functionality would be required at the LFN ? By the way, the text above mentions "careof address". In such a case, what would be the home address for the LFN ? > > It would be nice from solution draft authors cited in ROSA to > > provide a better published reference rather than for ROSA authors to > > seek for this by themselves. > > > Yes, authors please do so. Hope they do. Thierry. -- Thierry ERNST, PhD WIDE, Jun Murai Lab., Keio University, Japan Nautilus6 Chair: http://www.nautilus6.org Web: http://www.sfc.wide.ad.jp/~ernst/ T:+81-44-580-1600 F:+81-44-580-1437 -- From nemo-bounces@ietf.org Thu Dec 01 04:52:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehl7Z-0003TS-L9; Thu, 01 Dec 2005 04:52:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehl7Y-0003TN-3R for nemo@megatron.ietf.org; Thu, 01 Dec 2005 04:52:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13791 for ; Thu, 1 Dec 2005 04:52:09 -0500 (EST) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhlRz-00071U-Ok for nemo@ietf.org; Thu, 01 Dec 2005 05:14:04 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id jB19qQcq018161; Thu, 1 Dec 2005 18:52:26 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id jB19qRX03473; Thu, 1 Dec 2005 18:52:27 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id jB19qQ904049; Thu, 1 Dec 2005 18:52:26 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Dec 2005 17:49:15 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 01E0ED4550; Thu, 1 Dec 2005 17:57:54 +0800 (SGT) Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt From: Chan-Wah Ng To: Thierry Ernst In-Reply-To: <20051201142829.090c8b38.ernst@sfc.wide.ad.jp> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.camel@localhost> <20051125190058.7f5d24db.ernst@sfc.wide.ad.jp> <1132917036.11586.207.camel@localhost> <20051201142829.090c8b38.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 01 Dec 2005 17:57:53 +0800 Message-Id: <1133431073.16205.113.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 X-OriginalArrivalTime: 01 Dec 2005 09:49:15.0316 (UTC) FILETIME=[7D841740:01C5F65C] X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Thu, 2005-12-01 at 14:28 +0900, Thierry Ernst wrote: > Hi, > > > > > > because Mobile IPv6 defines its own Route Optimization > > > > > mechanism in its base protocol suite as a standard, > > > > > collaboration with this and NEMO brings various complexity. > > > > > > > > > > NEMO = NEMO Basic Support ? > > > > > > > > I don't so. I think the text's intent was to refer to NEMO RO > > > > (and possibly Basic as well). > > > > > > So, you may write "NEMO RO" not just "NEMO". > > > > I need the co-author who wrote this text to confirm, but if the > > intention was indeed to imply NEMO-RO and NEMO Basic, then I will keep > > NEMO. If it was only one of them, of-course we would switch to that. > > But this would still not tell the reader if you are speaking about the > "NEMO protocols" (taking all you may think about) or the NEMO concept, > or the NEMO configurations, or just as a standalone term to describe a > network that moves. I mean, I don't know what NEMO stands for in this > sentence. Ok, will add the word "Procotols", "Basic", or "Route Optimization" depending on context. > > > > > > > 4.5. Detection of New Functionalities > > > > > > > > > > Is this an issue ? Isn't there a better place ? > > > > > > > > Like? > > > > > > For me it looks more like a requirement than an issue. > > > > > > > I am unwillingly to write a "Requirements" section, for fear of being > > accused trying to sneak in requirements for RO in a problem statement > > draft. I would have it remained in the "Issues" section. If you feel > > that "Issue" has a more specific meaning, then I would change the > > title of this section to "General Considerations". > > This is a comment on naming the section "Issues" vs something else, not > on section 4.5 specifically: OK with your comment, so another term could > be"design goals" which is a smoother work for"requirements". But this is > just an editorial suggestion, you guys kwow how it's the best for you > to present things. I'm fine with both. > > > > > > > 4.7. Mobility Transparency and Location Privacy > > > > > > > > > > One advantage of NEMO Basic Support is that the Correspondent > > > > > Nodes and Mobile Network Nodes need not be aware of the > > > > > actual location and mobility of the mobile network. With > > > > > Route Optimization, it might be necessary to reveal the point > > > > > of attachment of the Mobile Router to other nodes, such as > > > > > the Mobile Network Nodes or their Correspondent Nodes. This > > > > > may mean a tradeoff between location privacy [17] (and > > > > > mobility transparency) and Route Optimization. > > > > > > > > > > Agree with location privacy, but mobility may still be > > > > > transparent to MNNs. You shouldn't group these > > > > > issues/requirements togethers. > > > > > > > > > > > > > The previous sentence read "necessary to reveal ... such as the > > > > MNNs or their CNs". For MNNs, its mobility transparency. For > > > > CNs, its location privacy. We could of-course break it into two > > > > parts, but they stamped from the same thing: requiring the MR > > > > reveal its location to some other nodes. > > > > > > I don't buy that "location privacy" is defined the way you seem to > > > define it. Location Privacy is about not providing my location to my > > > peers, not about not knowing where I am ! > > > > I don't see the difference between your interpretation and mine. > > > > "Location Privacy is about not providing my location to my peers" is > > equivalent to how I see it: "For CNs, its location privacy". > > > > "about not knowing where I am" is equivalent to how I see it "For MNN, > > its mobility transparency". > > > > > I advocate an independent paragraph on "mobility transparency" with > > > text taken from 4.7 and 4.3. > > > > > I could attempt a split and get back to you. My feeling is that the > > text will be largely similar (which is why I made the editorial > > decision not to split). Please note that we are NOT trying to say > > location privacy = mobility transparency. They are clearly distinct > > considerations. It is just that I feel that the text describing the > > two has so much overlapping that I grouped them into one sub-section. > > In the text, we have clearly use the terms location privacy and > > mobility transparent distinctly so that it shouldn't create the > > impression that they are the same thing (which apparently, we failed, > > judging on your comments). > > I guess your definition of "mobility transparency" and yours are > different. Mine is contained in draft-ietf-nemo-requiremnents 3.3. > Network Mobility Support Transparency. A MNN can be aware of its > location while "mobility transparency" is enforced. So, this is why I'm > saying "mobility transparency" and "location privacy" are orthogonal and > should be dealt with in distinct sections. > Here is the text from ietf-nemo-requirements: MNNs behind the MR(s) do not change their own physical point of attachment as a result of the mobile network's displacement in the Internet topology. Consequently, NEMO support is expected to be performed only be the MR(s). Specific support functions on any other node than the MR(s) would better be avoided. (BTW, there is a typo: "be" -> "by" in line 4). Ok, I will make some changes to the text in ROSA. > > > > > > Using the Mobile Network Prefix would usually mean that the > > > > > initiator is the Mobile Router, and has the benefit of > > > > > binding numerous Mobile Network Nodes with one signaling. > > > > > However, it also means that if location privacy is > > > > > compromised, the location privacy of an entire Mobile Network > > > > > Prefix will be compromised. > > > > > > > > > > s / will / would > > > > > > > > > > > > > That is subjective I think. But no harm changing :) > > > > > > Native English speakers will correct me if I'm wrong but I've learnt > > > that the future tense cannot be used after words like "if, when, > > > after,.." etc. > > > > > > > I am not a native english speaker, but I think I have heard > > expressions such as "if you XXX, I will kill you!" numerous times :). > > I think your rule refers to the "XXX" part (e.g. there is no "If you > > will do ..."), not the "then" part. > > Isn't it "if you XXXX, I kill you!" ? BTW, English being used by so many > non-native English speakers in the world, I wouldn't be surprised to see > the same mistake in loads of documents. > > I guess no native English speaker reads this tread, otherwise we would > be fixed already ;-) > > > > > > > 5.5. How is Mobile Network Node's Address Bound to Location? > > > > > > This approach has the advantage of keeping the > > > > > implementations of Correspondent Nodes unchanged. > > > > > However, it requires the root Mobile Router to act as a > > > > > Neighbor Discovery proxy for all the Mobile Network Nodes > > > > > that are directly or indirectly attached to it. This > > > > > increases the processing load of the root Mobile Router. > > > > > In addition, a change in the point of attachment of the > > > > > root Mobile Router will require every nested Mobile Router > > > > > (and possibly Visiting Mobile Nodes) to change their > > > > > care-of addresses. Not only will this cause a burst of > > > > > Binding Updates where every Mobile Router and every > > > > > Visiting Mobile Node start sending Binding Updates to > > > > > their Correspondent Entities, it will also cause a burst > > > > > of Duplicate Address Discovery messages to be exchanged > > > > > between the mobile network and the access network. > > > > > Furthermore, route optimization for Local Fixed Nodes is > > > > > not possible without new functionalities implemented on > > > > > the Local Fixed Nodes. > > > > > > > > > > At LFNs, these are functionalities not related to mobility > > > > > support. I think we need to draw a line between mobility-related > > > > > functionalities and other. The other ones could be referred to > > > > > as"requirements" to distinguish between the two. > > > > > > > > > > > > > What are functionalities required for mobility support then? > > > > > > A mechanism to send a BU is a mobility support functionality. A > > > DHCP functionality is not a mobility support functionality. DHCP is > > > useful for any node, fixed or mobile, in a fixed network or a mobile > > > network which needs a dynamic address. > > > > Agree, but the text is about mechanism to send BU for LFN. Sure , for > > ND-proxy, you can always used DHCP or similar to have the LFN change > > their addreses. That is not mobility. However, this defeats the > > purpose of NEMO. The ideal of NEMO is so that MNNs can retain their > > original source address. So, the LFN we have would need some mobility > > management functionality in order to enjoy the benefits of RO, which > > is precise what we meant by "Furthermore, route optimization for Local > > Fixed Nodes is not possible without new functionalities implemented on > > the Local Fixed Nodes". > > The text doens't say nor assumes that LFNs send BUs,. The MR sends the > BU. So, what kind of mobility management functionality would be > required at the LFN ? The text is on ND-Proxy, not MR-as-Proxy. So obviously MR is not sending BU on behalf of LFN. Instead, MR (or root-MR) is performing ND-Proxy for an address that is configured from the AR's prefix. For LFN to use this address, it means (a) LFN use this address as its source address; or (b) LFN implements mobility management and use this address as its CoA. For both (a) and (b), LFN needs functionality to understand that MR is performing ND-Proxy. For (b), LFN needs mobility management functionality. Thus, I see no need to change the text in 5.5.3. > > By the way, the text above mentions "careof address". In such a case, > what would be the home address for the LFN ? > When CoA is used, its has always been used with VMN or child-MR. If LFN is changed to use this as CoA, it is no longer a LFN but a LMN. /rgds /cwng From nemo-bounces@ietf.org Fri Dec 02 10:22:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiCjr-0008BX-HZ; Fri, 02 Dec 2005 10:22:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiCjq-0008B4-CO for nemo@megatron.ietf.org; Fri, 02 Dec 2005 10:22:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05792 for ; Fri, 2 Dec 2005 10:21:30 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiD4X-0002l1-JS for nemo@ietf.org; Fri, 02 Dec 2005 10:43:42 -0500 Received: from iseran.local (p8040-ipad28hodogaya.kanagawa.ocn.ne.jp [220.104.102.40]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 0B5F94D8D5 for ; Sat, 3 Dec 2005 00:21:40 +0900 (JST) Date: Sat, 3 Dec 2005 00:21:38 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Re: I-D ACTION:draft-ietf-nemo-ro-space-analysis-01.txt Message-Id: <20051203002138.33b7bb0d.ernst@sfc.wide.ad.jp> In-Reply-To: <1133431073.16205.113.camel@localhost> References: <1130764060.19589.13.camel@localhost> <1130929567.7004.5.camel@acorde> <20051124203213.024ec45b.ernst@sfc.wide.ad.jp> <1132838480.11586.90.camel@localhost> <20051125190058.7f5d24db.ernst@sfc.wide.ad.jp> <1132917036.11586.207.camel@localhost> <20051201142829.090c8b38.ernst@sfc.wide.ad.jp> <1133431073.16205.113.camel@localhost> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > > > > > > 4.7. Mobility Transparency and Location Privacy > > > I could attempt a split and get back to you. My feeling is that > > > the text will be largely similar (which is why I made the > > > editorial decision not to split). Please note that we are NOT > > > trying to say location privacy = mobility transparency. They are > > > clearly distinct considerations. It is just that I feel that the > > > text describing the two has so much overlapping that I grouped > > > them into one sub-section. In the text, we have clearly use the > > > terms location privacy and mobility transparent distinctly so that > > > it shouldn't create the impression that they are the same thing > > > (which apparently, we failed, judging on your comments). > > > > I guess your definition of "mobility transparency" and yours are > > different. Mine is contained in draft-ietf-nemo-requiremnents 3.3. > > Network Mobility Support Transparency. A MNN can be aware of its > > location while "mobility transparency" is enforced. So, this is why > > I'm saying "mobility transparency" and "location privacy" are > > orthogonal and should be dealt with in distinct sections. > > > > Here is the text from ietf-nemo-requirements: > > MNNs behind the MR(s) do not change their own physical point of > attachment as a result of the mobile network's displacement in the > Internet topology. Consequently, NEMO support is expected to be > performed only be the MR(s). Specific support functions on any > other node than the MR(s) would better be avoided. > > (BTW, there is a typo: "be" -> "by" in line 4). Good spot ! Shall I comment more on your draft so that you can spot typos on mine ? ;-) > > Ok, I will make some changes to the text in ROSA. > > > > > > 5.5. How is Mobile Network Node's Address Bound to > > > > > > Location? > > > > > > > > This approach has the advantage of keeping the > > > > > > implementations of Correspondent Nodes unchanged. > > > > > > However, it requires the root Mobile Router to act as > > > > > > a Neighbor Discovery proxy for all the Mobile Network > > > > > > Nodes that are directly or indirectly attached to it. > > > > > > This increases the processing load of the root Mobile > > > > > > Router. In addition, a change in the point of > > > > > > attachment of the root Mobile Router will require > > > > > > every nested Mobile Router(and possibly Visiting > > > > > > Mobile Nodes) to change their care-of addresses. Not > > > > > > only will this cause a burst of Binding Updates where > > > > > > every Mobile Router and every Visiting Mobile Node > > > > > > start sending Binding Updates to their Correspondent > > > > > > Entities, it will also cause a burst of Duplicate > > > > > > Address Discovery messages to be exchanged between the > > > > > > mobile network and the access network. Furthermore, > > > > > > route optimization for Local Fixed Nodes is not > > > > > > possible without new functionalities implemented on > > > > > > the Local Fixed Nodes. > > > > > > > > > > > > At LFNs, these are functionalities not related to mobility > > > > > > support. I think we need to draw a line between > > > > > > mobility-related functionalities and other. The other ones > > > > > > could be referred to as"requirements" to distinguish between > > > > > > the two. > > > > > > > > > > > > > > > > What are functionalities required for mobility support then? > > > > > > > > A mechanism to send a BU is a mobility support functionality. A > > > > DHCP functionality is not a mobility support functionality. DHCP > > > > is useful for any node, fixed or mobile, in a fixed network or a > > > > mobile network which needs a dynamic address. > > > > > > Agree, but the text is about mechanism to send BU for LFN. Sure , > > > for ND-proxy, you can always used DHCP or similar to have the LFN > > > change their addreses. That is not mobility. However, this > > > defeats the purpose of NEMO. The ideal of NEMO is so that MNNs > > > can retain their original source address. So, the LFN we have > > > would need some mobility management functionality in order to > > > enjoy the benefits of RO, which is precise what we meant by > > > "Furthermore, route optimization for Local Fixed Nodes is not > > > possible without new functionalities implemented on the Local > > > Fixed Nodes". > > > > The text doens't say nor assumes that LFNs send BUs,. The MR sends > > the BU. So, what kind of mobility management functionality would be > > required at the LFN ? > > The text is on ND-Proxy, not MR-as-Proxy. So obviously MR is not > sending BU on behalf of LFN. I think I was not in the right context then. > Instead, MR (or root-MR) is performing ND-Proxy for an address that is > configured from the AR's prefix. For LFN to use this address, it > means(a) LFN use this address as its source address; or (b) LFN > implements mobility management and use this address as its CoA. > > For both (a) and (b), LFN needs functionality to understand that MR is > performing ND-Proxy. OK, but it makes this functionality a "mobility support" functionality, or something else ? > For (b), LFN needs mobility management > functionality. Well, it's not a LFN anymore then ;-) > Thus, I see no need to change the text in 5.5.3. > > > > > By the way, the text above mentions "careof address". In such a > > case, what would be the home address for the LFN ? > > > > When CoA is used, its has always been used with VMN or child-MR. If > LFN is changed to use this as CoA, it is no longer a LFN but a LMN. It's right that you have mentioned Care-Of address in the context of a VMN, but I didn't notice this detail when I commented on this. So, fine. Thierry -- Thierry ERNST, PhD WIDE, Jun Murai Lab., Keio University, Japan Nautilus6 Chair: http://www.nautilus6.org Web: http://www.sfc.wide.ad.jp/~ernst/ T:+81-44-580-1600 F:+81-44-580-1437 -- From nemo-bounces@ietf.org Fri Dec 09 10:24:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekk74-0006vT-9x; Fri, 09 Dec 2005 10:24:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQMl-0008Ry-L7; Thu, 08 Dec 2005 13:19:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20433; Thu, 8 Dec 2005 13:18:35 -0500 (EST) Received: from thing1.cs.uvic.ca ([142.104.100.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkQMd-00033G-BN; Thu, 08 Dec 2005 13:19:31 -0500 Received: from yang (yang [142.104.100.105]) by thing1.cs.uvic.ca (8.12.10/8.12.8) with ESMTP id jB8IImWB001497; Thu, 8 Dec 2005 10:18:49 -0800 Date: Thu, 8 Dec 2005 10:18:48 -0800 (PST) From: Kui Wu X-X-Sender: wkui@yang To: multicomm@comsoc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-CS-Spam-Score: -7.4 () BAYES_00,CS_SCAM_5,CS_UVIC_1,CS_UVIC_2,CS_VGA_10 X-CS-Spam-Status: No X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-Mailman-Approved-At: Fri, 09 Dec 2005 10:24:43 -0500 Cc: Subject: [nemo] CFP:International Symposium on Wireless Local and Personal Area Networks X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org (My apologies if you receive multiple copies of this message) International Symposium on Wireless Local and Personal Area Networks (part of IWCMC 2006) Sheraton Wall Centre Vancouver, Canada July 3-6, 2006 Technical Support: IEEE TCPC, IEEE TCCC, IEEE RCC, IEEE MMC Scope and Topics of Interest Original papers are invited on emerging architectures and technologies in the design of wireless local area networks (WLANs) and wireless personal area networks (WPANs) with emphasis on the use of such networks in diverse areas of applications such as supporting ubiquitous mobile Internet access, and the design of ad-hoc networks, and sensor networks. The symposium solicits high quality and previously unpublished work in the field. Topics of interest include, but are not limited to: Wireless Mesh Networks Medium access techniques and protocols for WLANs/WPANs Emerging standards and testbeds for WLANs/WPANs WLANs/WPANs protocols for smart antennas Energy efficiency in protocol and systems design Resource assignment and sharing in WLANs/WPANs Self configuration in WLANs/WPANs Provisioning quality of service in WLANs/WPANs Multimedia networking architectures and protocols for WLANs/WPANs Integration and interoperability of WLANs/WPANs and 3G (and beyond)networks Interoperability issues between wireless standards/protocols and the Internet User mobility and workload modeling Security issues in WLANs/WPANs Paper Submission and Important Dates Please see the IWCMC'06 submission page (http://www.iwcmc2006.cs.wmich.edu/submissionguidelines.php) for guidelines. Note that all papers are limited to six pages, and must be in standard IEEE double-column format. All submissions will be handled electronically and must be in PDF format. The conference has designated best papers awards. Manuscript Submission: December 15, 2005 Acceptance Notification: April 15, 2006 Camera-Ready Papers Due: May 30, 2006 Organizing Committee Symposium Co-Chairs Ehab S. Elmallah Department of Computing Science, University of Alberta, Edmonton, Alberta Canada, T6G 2E8 Yang Xiao Computer Science Division The University of Memphis, 373 Dunn Hall, Memphis, TN 38152, USA yangxiao@ieee.org Publicity Co-Chairs Kui Wu Department of Computer Science University of Victoria Victoria, British Columbia Canada V8W 3P6 wkui@cs.uvic.ca Vincent Wong Department of Electrical and Computer Engineering The University of British Columbia 2356 Main Mall, Vancouver, BC, Canada, V6T 1Z4 vincentw@ece.ubc.ca Technical Program Committee Imad Aad, EPFL, Switzerland Giuseppe Bianchi, University of Roma Tor Vergata, Italy Azzedine Boukerche, SITE, University of Ottawa, Canada Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Liang Cheng, Lehigh University, USA Jing Deng, University of New Orleans, USA Christos Douligeris, University of Piraeus, Greece Xiaojiang (James) Du, North Dakota State University, USA Nelson Fonseca, State University of Campinas, Brazil Jose Rosario Gallardo, CICESE, Mexico Daqing Gu, MERL, USA Xingang Guo, Intel, USA Janelle Harms, University of Alberta, Canada Ekram Hossain, University of Manitoba, Canada Antonio Iera, University Mediterranea of Reggio Calabria, Italy Weijia Jia, City University of Hong Kong, Hong Kong Xiaohua Jia, City University of Hong Kong , Hong Kong Victor Leung, University of British Columbia, Canada Haizhon Li, University of Memphis, USA Ting-Yu Lin, National Chiao-Tung University, Taiwan Jiangchuan Liu, Simon Fraser University, Canada Xiang-Yang Li, Illinois Institute of Technology, USA Mike MacGregor, University of Alberta, Canada Jelena Misic, University of Manitoba, Canada Vojislav B Misic, University of Manitoba, Canada Qiang Ni, National University of Ireland, Ireland Ioanis Nikolaidis, University of Alberta, Canada Jianping Pan, NTT MCL, USA Pascal Pagani, France Telecom, France Yi Qian, University of Puerto Rico, USA Daji Qiao, Iowa State University, USA Bo Sun, Lamar University, USA Ilenia Tinnirello, University of Palermo, Italy Dimitrios Vergados, University of the Aegean, Greece Feiyi Wang, Cisco Systems Inc, USA Lan Wang, University of Memphis, USA Li-Chun Wang, National Chiao Tung University, Taiwan Wenye Wang, North Carolina State University, USA Xudong Wang, Kiyon Inc., USA Yu Wang, University of California, Santa Cruz, USA Vincent Wong, University of British Columbia, Canada Haitao Wu, Microsoft Research, China Hongyi Wu, University of Louisiana at Lafayette, USA Jie Wu, Florida Atlantic University, USA Kui Wu, University of Victoria, Canada Surong Zeng, Motorola, USA Hao Zhu, Florida International University, USA From nemo-bounces@ietf.org Thu Dec 15 08:09:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmsrU-0004yV-0e; Thu, 15 Dec 2005 08:09:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmsrS-0004uM-3J for nemo@megatron.ietf.org; Thu, 15 Dec 2005 08:09:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03707 for ; Thu, 15 Dec 2005 08:08:25 -0500 (EST) Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Emssl-0000yt-V9 for nemo@ietf.org; Thu, 15 Dec 2005 08:10:52 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama55.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBFD9LYX021819 for ; Thu, 15 Dec 2005 22:09:21 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBFD9KfF017031 for ; Thu, 15 Dec 2005 22:09:20 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBFD9KrK000766 for ; Thu, 15 Dec 2005 22:09:20 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBFD9JxJ002816 for ; Thu, 15 Dec 2005 22:09:19 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBFD9Jl2004059 for ; Thu, 15 Dec 2005 22:09:19 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (imj.m.ecl.ntt.co.jp [129.60.5.234]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBFD9IIT004056 for ; Thu, 15 Dec 2005 22:09:18 +0900 (JST) Received: from [129.60.10.37] ([129.60.10.37]) by imj.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jBFD9IpA009118 for ; Thu, 15 Dec 2005 22:09:18 +0900 (JST) Date: Thu, 15 Dec 2005 22:09:21 +0900 From: Takaaki Moriya To: nemo@ietf.org X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.054 Message-Id: <20051215220859.B9BE.MORIYA.TAKAAKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.22.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Subject: [nemo] IPsec for payload packets X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, I'm new of this mailing list. I have a question related to IPsec for payload packets. RFC3963 refers to RFC3776 concerning the use of IPsec to protect Mobile IPv6 signaling messages as follows. > All signaling messages between the Mobile Router and the Home Agent > MUST be authenticated by IPsec [8]. The use of IPsec to protect > Mobile IPv6 signaling messages is described in detail in the HA-MN > IPsec specification [2]. The signaling messages described in this > document extend Mobile IPv6 messages and do not require any changes > to what is described in [2]. As for payload packets, when ingress interface of Mobile Router is used for its Home Address, I think that SPD/SAD for payload packets are naturally configurated as follows. -------------------------------------------------- | SPD | | SRC | DST | --------------------------------------------------- | SA7 [MR -> HA] | Outer | MR_CoA | HA | | | Inner | MNP | any | -------------------------------------------------- | SA8 [HA -> MR] | Outer | HA | MR_CoA | | | Inner | any | MNP | -------------------------------------------------- However, when eggress interface of Mobile Router is used for its Home Address, I think that the following policies are needed in addition to the above SA7 and SA8. For example, they might be used when Mobile router itself sends some messages to CN. Is it correct ? -------------------------------------------------- | SPD | | SRC | DST | --------------------------------------------------- | SA9?[MR -> HA] | Outer | MR_CoA | HA | | | Inner | MR_HoA | any | -------------------------------------------------- | SA10?[HA -> MR] | Outer | HA | MR_CoA | | | Inner | any | MR_HoA | -------------------------------------------------- I wonder some implementations might not need these additional policies (SA9 and SA10), because they can cover these SA9 and SA10 just by using the existing SA7 and SA8. Thank you very much in advance. Best Regards, Takaaki Moriya ------------------------------------------------------------ Takaaki MORIYA NTT Network Service Systems Laboratories, NTT Corporation, Japan TEL: +81-422-59-2848 FAX: +81-422-59-5631 E-mail: moriya.takaaki@lab.ntt.co.jp From nemo-bounces@ietf.org Thu Dec 15 10:17:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmurG-0004Ml-LC; Thu, 15 Dec 2005 10:17:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmurE-0004KY-KH for nemo@megatron.ietf.org; Thu, 15 Dec 2005 10:17:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19608 for ; Thu, 15 Dec 2005 10:16:23 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmusY-0005lO-OU for nemo@ietf.org; Thu, 15 Dec 2005 10:18:49 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jBFFGq726428; Thu, 15 Dec 2005 16:16:52 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jBFFGqgI027397; Thu, 15 Dec 2005 16:16:52 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200512151516.jBFFGqgI027397@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Takaaki Moriya Subject: Re: [nemo] IPsec for payload packets In-reply-to: Your message of Thu, 15 Dec 2005 22:09:21 +0900. <20051215220859.B9BE.MORIYA.TAKAAKI@lab.ntt.co.jp> Date: Thu, 15 Dec 2005 16:16:52 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: I have a question related to IPsec for payload packets. RFC3963 refers to RFC3776 concerning the use of IPsec to protect Mobile IPv6 signaling messages as follows. => note you have at least 3 very different things: - what is possible in theory with RFC 2401 and IKEv1 (as these documents are not coherent and clearly incompatible, this can become a bit hairy :-) - what is possible in theory with 2401bis and IKEv2 (previous issues are supposed to have been fixed but) - what is possible in practice with the IPsec/IKE implementation you have (I consider you have the common Linux 2.6 (aka USAGI) / BSD (aka KAME) implementation which is well known). > All signaling messages between the Mobile Router and the Home Agent > MUST be authenticated by IPsec [8]. The use of IPsec to protect > Mobile IPv6 signaling messages is described in detail in the HA-MN > IPsec specification [2]. The signaling messages described in this > document extend Mobile IPv6 messages and do not require any changes > to what is described in [2]. => this is a quote from RFC 3963. As for payload packets, when ingress interface of Mobile Router is used for its Home Address, I think that SPD/SAD for payload packets => precision: "payload packets" are not always all/any protocol (in RFC 3776 section 5.2.4 for instance you have "proto = X") are naturally configurated as follows. -------------------------------------------------- | SPD | | SRC | DST | --------------------------------------------------- | SA7 [MR -> HA] | Outer | MR_CoA | HA | | | Inner | MNP | any | -------------------------------------------------- | SA8 [HA -> MR] | Outer | HA | MR_CoA | | | Inner | any | MNP | -------------------------------------------------- => these are tunnel mode SPD entries so the selectors are *only* on the inner header. To make this works, i.e., to take the outer header into account, the RFC 3776 uses the interface stuff (fortunately only in examples :-). However, when eggress interface of Mobile Router is used for its Home Address, I think that the following policies are needed in addition to the above SA7 and SA8. For example, they might be used when Mobile router itself sends some messages to CN. => you may have narrower SPD entries with a higher priority, in fact, if the traffic payload matches the signaling but with a lower security level, you must have them (i.e., 5.2.2 has to take precedence over 5.2.4, and 5.3.2 over 5.3.4). Note that the match here is true only when X = any (2401bis/IKEv2 is more complex but the requirement is the same). Is it correct ? => yes, you may have other SPD entries... -------------------------------------------------- | SPD | | SRC | DST | --------------------------------------------------- | SA9?[MR -> HA] | Outer | MR_CoA | HA | | | Inner | MR_HoA | any | -------------------------------------------------- | SA10?[HA -> MR] | Outer | HA | MR_CoA | | | Inner | any | MR_HoA | -------------------------------------------------- I wonder some implementations might not need these additional policies (SA9 and SA10), because they can cover these SA9 and SA10 just by using the existing SA7 and SA8. => I have to understand that "cover" can make things simpler but can break the security too. This is a basic issue in IPsec policies: when they overlap the strong one must be used for the intersection. Regards Francis.Dupont@enst-bretagne.fr From nemo-bounces@ietf.org Thu Dec 15 18:11:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2Fs-0008JP-DL; Thu, 15 Dec 2005 18:11:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2Fo-0008IG-SA for nemo@megatron.ietf.org; Thu, 15 Dec 2005 18:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29613 for ; Thu, 15 Dec 2005 18:10:18 -0500 (EST) Received: from web33504.mail.mud.yahoo.com ([68.142.206.153]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1En2HH-0002P7-F6 for nemo@ietf.org; Thu, 15 Dec 2005 18:12:49 -0500 Received: (qmail 75089 invoked by uid 60001); 15 Dec 2005 23:11:05 -0000 Message-ID: <20051215231105.75087.qmail@web33504.mail.mud.yahoo.com> Received: from [141.225.9.226] by web33504.mail.mud.yahoo.com via HTTP; Thu, 15 Dec 2005 15:11:05 PST X-RocketYMMF: yangxiao_acm Date: Thu, 15 Dec 2005 15:11:05 -0800 (PST) From: Yang Xiao To: nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA29613 Subject: [nemo] Journal Special issue on Theoretical and Algorithmic Aspects in Sensor Networks X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org International Journal of Sensor Networks (IJSNET) Call For papers Special Issue on: =93Theoretical and Algorithmic Aspects in Sensor Networks=94 http://www.inderscience.com/browse/callpaper.php?callID=3D315 Guest Editors: Dr. Xiuzhen (Susan) Cheng, The George Washington University, USA Dr. Yingshu Li, Georgia State University USA The marriage of sensor and network technologies provides many exciting applications of sensor networks. With their capabilities for monitoring and control, networked sensors are expected to be widely deployed. Theoretical and algorithmic approaches that address key issues in sensor networks have been playing a central role in these networks flourishing. Common theoretical and algorithmic issues in sensor networks include location management, topology control and coverage, security and privacy, scalable design, cross layer design, energy efficient message dissemination, QoS, to just name a few. Methods used to address these issues include computational geometry, graph theory, combinatorial optimisation, linear relaxation, stochastic and probability analysis, etc. The goal of the special issue is to publish the most recent results in the development of theoretical and algorithmic aspects of sensor networks. Researchers and practitioners working in this area are expected to take this opportunity to discuss and express their views on the current trends, challenges, and state of the art solutions addressing various issues in sensor networks. Subject Coverage Suitable topics include but are not limited to: Algorithmic methods and tools=20 Approximation algorithm design=20 Localization and tracking=20 Resource allocation=20 Quality of service=20 Topology control and coverage=20 Energy efficient routing protocols=20 Security and privacy=20 Distributed and localised solutions=20 Stochastic algorithms=20 Information processing=20 Scalability issues=20 Fault-tolerant issues Notes for Intending Authors Submitted papers should not have been previously published nor be currently under consideration for publication elsewhere All papers are refereed through a peer review process. A guide for authors, sample copies and other relevant information for submitting papers are available on the Papers Submission section under Author Guidelines To submit a paper, please go to Submission of Papers This is our preferred route for submitting papers; please use it if at all possible. However, if you experience any problems submitting papers in this way, an alternative route is suggested below Important Dates Manuscript due: 31 January, 2006 Acceptance/rejection notification: 30 April, 2006 Final manuscript due: 31 May, 2006 Editors and Notes As an alternative to using the Submission of Papers site, you may send one copy in the form of a PDF file attached to an e-mail (details in Author Guidelines) to the following: Dr. Xiuzhen (Susan) Cheng Department of Computer Science The George Washington University Washington, DC 20052 USA Tel: 202 994 9751 Fax: 202 994 4875 E-mail: cheng@gwu.edu with an email copy only to: Editor-in-Chief IEL Editorial Office E-mail: ijsnet@inderscience.com Please include in your submission the title of the Special Issue, the title of the Journal and the name of the Guest Editor =20 =20 =20 =BB Subject Coverage=20 =BB Notes for Intending Authors=20 =BB Important Dates=20 =BB Editors and Notes=20 =20 Give Us Your Feedback We welcome your comments about this Journal. =20 =20 =20 From nemo-bounces@ietf.org Thu Dec 15 18:12:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2HF-00009P-KQ; Thu, 15 Dec 2005 18:12:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2H5-00007Z-Hd for nemo@megatron.ietf.org; Thu, 15 Dec 2005 18:12:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29740 for ; Thu, 15 Dec 2005 18:11:36 -0500 (EST) Received: from web33504.mail.mud.yahoo.com ([68.142.206.153]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1En2IY-0002SG-7u for nemo@ietf.org; Thu, 15 Dec 2005 18:14:08 -0500 Received: (qmail 75493 invoked by uid 60001); 15 Dec 2005 23:12:24 -0000 Message-ID: <20051215231224.75491.qmail@web33504.mail.mud.yahoo.com> Received: from [141.225.9.226] by web33504.mail.mud.yahoo.com via HTTP; Thu, 15 Dec 2005 15:12:24 PST X-RocketYMMF: yangxiao_acm Date: Thu, 15 Dec 2005 15:12:24 -0800 (PST) From: Yang Xiao To: multicomm@comsoc.org, comm-theory@ieee.org, nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 8bit Cc: Subject: [nemo] Journal Special issue on Coverage Problems in Sensor Networks X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org International Journal of Sensor Networks (IJSNET) Call For papers Special Issue on: "Coverage Problems in Sensor Networks" http://www.inderscience.com/browse/callpaper.php?callID=322 Guest Editors : Dr. Maggie Cheng, University of Missouri-Rolla, USA Dr. Ding-Zhu Du, University of Texas at Dallas, USA Sensor networks have been an active research area in recent years. As more and more practical applications of sensor networks continue to emerge, the performance aspects of sensor networks start to attract new attentions. Among many others, the coverage of a sensor network, directly related to the surveillance capability, is intractably interleaved with other quality of service issues in sensor networks. In the literature, coverage problems have been addressed from different perspectives, mostly as standalone problems, and solution techniques evaluated in various context. Coverage is one of the fundamental problems in sensor networks. It is important to highlight the most important contributions in sensor network coverage research, especially those that lead to fundamental mathematical models, uniform performance metrics and standard assessment methods. The aim of this special issue is to provide a platform for sensor network researchers in industry and academia to present the state-of-the-art research that addresses the fundamental coverage problems in sensor networks, explore the relation of coverage to other practical performance metrics, and promote the research activity in sensor networks. Subject Coverage Areas of interest include but are not limited to the following topics: Coverage computation addressed from a statistical or deterministic point of view, especially leveraging graph theory and information theory Mathematical performance modelling of coverage Coverage metrics and monitoring---new criteria and evaluation methods Theoretical analysis addressing o the relation between coverage and network connectivity o the relation between coverage and network capacity Distributed and localized computation of coverage Distributed coordination and self-organization related to coverage Energy efficient algorithms and approaches related to coverage Power-saving modes of operation related to coverage Scheduling algorithms and protocols related to coverage Fault tolerant coverage configuration in sensor networks Application of formal methods to the assessment of sensor network coverage Notes for Intending Authors Submitted papers should not have been previously published nor be currently under consideration for publication elsewhere All papers are refereed through a peer review process. A guide for authors, sample copies and other relevant information for submitting papers are available on the Papers Submission section under Author Guidelines To submit a paper, please go to Submission of Papers This is our preferred route for submitting papers; please use it if at all possible. However, if you experience any problems submitting papers in this way, an alternative route is suggested below Submit the manuscript via e-mail to Dr. Maggie Cheng at chengm@umr.edu The acceptable manuscript format is PDF. Important Dates Manuscript due: 1 April 2006 Acceptance/rejection notification: 1 August 2006 Final manuscript due: 31 August 2006 Publication date: January 2007 Editors and Notes As an alternative to using the Submission of Papers site, you may send one copy in the form of a PDF file attached to an e-mail (details in Author Guidelines) to the following: Dr. Maggie Cheng University of Missouri-Rolla Tel: 573-341-7501 E-mail: chengm@umr.edu Dr. Ding-Zhu Du University of Texas at Dallas Tel: 972- 883-6615 E-mail: dxd056000@utdallas.edu with an email copy only to: Editor-in-Chief IEL Editorial Office E-mail: ijsnet@inderscience.com Please include in your submission the title of the Special Issue, the title of the Journal and the name of the Guest Editor From nemo-bounces@ietf.org Thu Dec 15 18:13:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2Hg-0000Ax-Bz; Thu, 15 Dec 2005 18:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2He-0000An-R1 for nemo@megatron.ietf.org; Thu, 15 Dec 2005 18:13:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29814 for ; Thu, 15 Dec 2005 18:12:12 -0500 (EST) Received: from web33512.mail.mud.yahoo.com ([68.142.206.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1En2J8-0002Tz-4o for nemo@ietf.org; Thu, 15 Dec 2005 18:14:43 -0500 Received: (qmail 74102 invoked by uid 60001); 15 Dec 2005 23:13:00 -0000 Message-ID: <20051215231300.74096.qmail@web33512.mail.mud.yahoo.com> Received: from [141.225.9.226] by web33512.mail.mud.yahoo.com via HTTP; Thu, 15 Dec 2005 15:13:00 PST X-RocketYMMF: yangxiao_acm Date: Thu, 15 Dec 2005 15:13:00 -0800 (PST) From: Yang Xiao To: multicomm@comsoc.org, comm-theory@ieee.org, nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA29814 Cc: Subject: [nemo] Journal Special issue on Cryptography in Networks X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org International Journal of Security and Networks (IJSN) Call For papers Special Issue on: =93Cryptography in Networks=94 http://www.inderscience.com/browse/callpaper.php?callID=3D313 Guest Editors: Liqun Chen, Hewlett-Packard Labs, UK Guang Gong, University of Waterloo, Canada Atsuko Miyaji, JAIST, Japan Phi Joong Lee, Pohang University of Science & Technology, Korea Yi Mu, University of Wollongong, Australia David Pointcheval, Ecole Normale Sup=E9rieure, France Josef Pieprzyk, Macquarie University, Australia Jennifer Seberry, University of Wollongong, Australia Tsuyoshi Takagi, Future University, Japan Willy Susilo, University of Wollongong, Australia Huaxiong Wang, Macquarie Uniersity, Australia Cryptography plays a key role in network security. Advances of cryptography can make computer networks more secure. Computer technologies have been pushing forward computer networks for high speed and broad bandwidth. Therefore, new cryptographic methods and tools must follow up in order to adapt to these new technologies. Recent attacks on computer networks, especially on IEEE 802.11 and IEEE 802.15, are increasing, since the underlying radio communication medium for wireless networks provides serious exposure to attacks against wireless networks. Security must be enforced to suit the emerging technologies. This Special Issue aims to provide a platform for security researchers to present their newly developed cryptographic technologies in network security. Subject Coverage Areas of interest for this special journal issue include, but are not limited to, the following topics: Ad hoc network security=20 Anonymity in networks=20 Authentication in network and wireless systems=20 Cryptographic algorithms and applications=20 Encryption in network and wireless systems=20 Email security=20 Data integrity=20 Fast cryptographic algorithms and their applications=20 Identity-based cryptography in network and mobile applications=20 IP security=20 Key management=20 Multicast security=20 Mobile and wireless system security=20 Privacy protection=20 Security group communications=20 Security in internet and WWW=20 Security in peer-to-peer networks=20 Secure routing protocols=20 Security in sensor networks Notes for Intending Authors Submitted papers should not have been previously published nor be currently under consideration for publication elsewhere All papers are refereed through a peer review process. A guide for authors, sample copies and other relevant information for submitting papers are available on the Papers Submission section under Author Guidelines To submit a paper, please go to Submission of Papers This is our preferred route for submitting papers; please use it if at all possible. However, if you experience any problems submitting papers in this way, an alternative route is suggested below Important Dates Manuscript submission deadline: 1 March, 2006 Notification due date: 1 June, 2006 Camera-ready manuscript due date: 1 August, 2006=20 Editors and Notes As an alternative to using the Submission of Papers site, you may send one copy in the form of a PDF file attached to an e-mail (details in Author Guidelines) to: ijsn_special_issue@uow.edu.au with an email copy only to: Editor-in-Chief IEL Editorial Office E-mail: ijsn@inderscience.com Please include in your submission the title of the Special Issue, the title of the Journal and the name of the Guest Editor. The submission must be anonymous, with no author names, affiliations, acknowledgments, or obvious references. Author information should be provided on the cover page. From nemo-bounces@ietf.org Thu Dec 15 18:13:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2ID-0000DQ-LF; Thu, 15 Dec 2005 18:13:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2IA-0000Cy-9g for nemo@megatron.ietf.org; Thu, 15 Dec 2005 18:13:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29846 for ; Thu, 15 Dec 2005 18:12:43 -0500 (EST) Received: from web33501.mail.mud.yahoo.com ([68.142.206.150]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1En2Jd-0002VK-PO for nemo@ietf.org; Thu, 15 Dec 2005 18:15:15 -0500 Received: (qmail 15466 invoked by uid 60001); 15 Dec 2005 23:13:31 -0000 Message-ID: <20051215231331.15464.qmail@web33501.mail.mud.yahoo.com> Received: from [141.225.9.226] by web33501.mail.mud.yahoo.com via HTTP; Thu, 15 Dec 2005 15:13:31 PST X-RocketYMMF: yangxiao_acm Date: Thu, 15 Dec 2005 15:13:31 -0800 (PST) From: Yang Xiao To: multicomm@comsoc.org, comm-theory@ieee.org, nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA29846 Cc: Subject: [nemo] CFP: Computer and Network Security Symposium X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Computer and Network Security Symposium International Wireless Communications & Mobile Computing Conference (IWCMC 2006) Sheraton Wall Centre, Vancouver, Canada July 3-6, 2006 =20 Computer and Network Security symposium of IWCMC 2006 is soliciting original papers describing state-of-the art research and development in the areas of computer and network security. Prospective authors are invited to submit original technical papers for oral presentations at IWCMC 2006 and publication in the Conference Proceeding. =20 =20 Symposium Co-Chairs:=20 Xiaojiang (James) Du, North Dakota State University , Xiaojiang.Du@ndsu.edu Yang Xiao, University of Memphis , yangxiao@ieee.org=20 Shigang Chen, University of Florida , sgchen@cise.ufl.edu =20 =20 The main purpose of this symposium is to promote further research interests and activities on computer and network security. It is also aimed at increasing the synergy between academic and industrial researchers working in this area. We are interested in theoretic, experimental, and systems-related papers in all aspects of computer and network security. =20 =20 Scope of the Computer and Network Security Symposium includes, but is not limited to: =20 * Novel and emerging secure architecture * Cryptographic algorithms and applications=20 * Study of attack strategies, attack modeling * Key management * Intrusion detection techniques * Intrusion response, alarm management, and correlation analysis * Study of tradeoffs between security and system performance * Intrusion tolerance systems * Denial of service * Distributed system security * Wireless network security (WiFi, WiMAX, WiMedia and others)=20 * Sensor network security=20 * Mobile ad hoc network security=20 =20 Papers should describe original, previously unpublished work, not currently under review by another conference, workshop, or journal. All papers are limited to 6 pages and must be in standard IEEE double-column format. All submissions will be handled electronically and must be in PDF format.=20 =20 Papers can be submitted through the EDAS web portal: http://www.edas.info/Conferences.cgi=20 =20 Accepted papers will appear in the IEEE IWCMC conference proceedings. =20 Selected best papers will be recommended for publications in International Journal of Security and Networks (IJSN).=20 =20 =20 =20 IMPORTANT DATES Paper Submission Deadline: December 15, 2005=B8 Postponed to January 15, 2006 (due to many requests) Paper Acceptance Notification: April 15, 2006 Camera-ready Paper Submissions: May 30, 2006 Symposium Date: July 3-6 2006 =20 Technical Committee Members=20 (Listed in the Alphabetic Order of Last Name) =20 Name Institution Country =20 Jemal Abawajy Deakin University=20 Australia =20 Ying Cai=20 Iowa State University=20 USA =20 Zhenfu Cao Shanghai Jiao Tong University China =20 Shigang Chen University of Florida=20 USA =20 Shu-Ching Chen Florida International University =20 USA =20 Xiuzhen Cheng George Washington University =20 USA =20 Xiaowen Chu Hong Kong Baptist University Hong Kong, China =20 Jun-Hong Cui =20 University of Connecticut=20 USA =20 Xiaojiang (James) Du North Dakota State University=20 USA =20 Qiang Duan University of Central Arkansas=20 USA =20 Zhenhai Duan Florida State University=20 USA =20 Arjan Durresi Louisiana State University=20 USA =20 Scott C. Evans GE Research=20 USA =20 Guangbin Fan =20 University of Mississippi USA =20 Christof Fetzer Dresden University of Technology=20 Germany =20 Xinwen Fu Dakota State University=20 USA =20 Susan Hinrichs University of Illinois at Urbana - Champaign=20 USA =20 Mehdi K. Khandani University of Maryland, College Park=20 USA =20 Seungjoo Kim Sungkyunkwan University Korea =20 Peter Langendoerfer ihp-microelectronics=20 Germany =20 Qun Li College of William and Mary=20 USA =20 Jian Raymond Li Cisco Systems Inc.=20 USA =20 Xiang-Yang Li Illinois Institute of Technology=20 USA =20 Qilian, Liang University of Texas, Dallas=20 USA =20 Bin Liu Tsinghua University, China USA =20 Yonghe Liu University of Texas, Dallas=20 USA =20 Chuang Lin Tsinghua University China =20 Yibei Ling Telcordia Technologies, Inc.=20 USA =20 Alex Zhaoyu Liu Univ. of North Carolina at Charlotte=20 USA =20 Lau Cheuk Lung Pontifical Catholic University of Paran=E1 Brazil =20 Jianhua Ma Hosei University Japan =20 Dan Massey Colorado State University=20 USA =20 Jason Moore United States Air Force Academy=20 USA =20 Yi Mu University of Wollongong=20 Australia =20 Maria S. Perez-Hernandez Facultad de Informatica=20 Spain =20 Yi Qian University of Puerto Rico at Mayaguez USA =20 Xiao Qin New Mexico Institute of Mining and Technology=20 USA =20 Jian Ren Michigan State University=20 USA =20 Kouichi Sakurai Kyushu University=20 Japan =20 Zili Shao Hong Kong Polytechnic University=20 Hong Kong, China =20 Wenzhan Song Washington State University=20 USA =20 Bo Sun Lamar University=20 USA =20 Willy Susilo University of Wollongong=20 Australia =20 Huaxiong Wang Macquarie University=20 Australia =20 Carlos Becker Westphall UFSC-CTC-INE-LRG=20 Brazil =20 Kui Wu University of Victoria=20 Canada =20 Ye Xia University of Florida=20 USA =20 Bin Xiao Hong Kong Polytechnic University=20 Hong Kong, China =20 Yang Xiao University of Memphis=20 USA =20 Cheng-Zhong Xu Wayne State University=20 USA =20 Laurence T. Yang St. Francis Xavier University=20 Canada =20 George Yee National Research Council Canada=20 Canada =20 Mohamed Younis University of Maryland, Baltimore County=20 USA =20 Lisa Zhang Bell Labs=20 USA =20 Ning Zhang University of Manchester=20 UK =20 Chi Zhou Florida International University=20 USA =20 Xukai Zou Purdue University at IUPUI=20 USA =20 From nemo-bounces@ietf.org Thu Dec 15 18:14:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2Ic-0000Fi-HO; Thu, 15 Dec 2005 18:14:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2Ib-0000Fd-03 for nemo@megatron.ietf.org; Thu, 15 Dec 2005 18:14:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29877 for ; Thu, 15 Dec 2005 18:13:10 -0500 (EST) Received: from web33502.mail.mud.yahoo.com ([68.142.206.151]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1En2K4-0002WS-A9 for nemo@ietf.org; Thu, 15 Dec 2005 18:15:41 -0500 Received: (qmail 7626 invoked by uid 60001); 15 Dec 2005 23:13:57 -0000 Message-ID: <20051215231357.7624.qmail@web33502.mail.mud.yahoo.com> Received: from [141.225.9.226] by web33502.mail.mud.yahoo.com via HTTP; Thu, 15 Dec 2005 15:13:57 PST X-RocketYMMF: yangxiao_acm Date: Thu, 15 Dec 2005 15:13:57 -0800 (PST) From: Yang Xiao To: multicomm@comsoc.org, comm-theory@ieee.org, nemo@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 8bit Cc: Subject: [nemo] CFP: Symposium on Wireless Local and Personal Area Networks X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Call For Papers International Symposium on Wireless Local and Personal Area Networks (part of IWCMC 2006) Sheraton Wall Centre Vancouver, Canada July 3-6, 2006 Technical Support: IEEE TCPC, IEEE TCCC, IEEE RCC, IEEE MMC Scope and Topics of Interest Original papers are invited on emerging architectures and technologies in the design of wireless local area networks (WLANs) and wireless personal area networks (WPANs) with emphasis on the use of such networks in diverse areas of applications such as supporting ubiquitous mobile Internet access, and the design of ad-hoc networks, and sensor networks. The symposium solicits high quality and previously unpublished work in the field. Topics of interest include, but are not limited to: Wireless Mesh Networks Medium access techniques and protocols for WLANs/WPANs Emerging standards and testbeds for WLANs/WPANs WLANs/WPANs protocols for smart antennas Energy efficiency in protocol and systems design Resource assignment and sharing in WLANs/WPANs Self configuration in WLANs/WPANs Provisioning quality of service in WLANs/WPANs Multimedia networking architectures and protocols for WLANs/WPANs Integration and interoperability of WLANs/WPANs and 3G (and beyond) networks Interoperability issues between wireless standards/protocols and the Internet User mobility and workload modeling Security issues in WLANs/WPANs Paper Submission and Important Dates Please see the IWCMC'06 submission page for guidelines. Note that all papers are limited to six pages, and must be in standard IEEE double-column format. All submissions will be handled electronically and must be in PDF format. The conference has designated best papers awards. Manuscript Submission: Jan. 15, 2005 Acceptance Notification: April 15, 2006 Camera-Ready Papers Due: May 30, 2006 Organizing Committee Symposium Co-Chairs Ehab S. Elmallah Department of Computing Science, University of Alberta, Edmonton, Alberta Canada, T6G 2E8 ehab@cs.ualberta.ca Yang Xiao Computer Science Division The University of Memphis, 373 Dunn Hall, Memphis, TN 38152, USA yangxiao@ieee.org Publicity Co-Chairs Kui Wu Department of Computer Science University of Victoria Victoria, British Columbia Canada V8W 3P6 wkui@cs.uvic.ca Vincent Wong Department of Electrical and Computer Engineering The University of British Columbia 2356 Main Mall, Vancouver, BC, Canada, V6T 1Z4 vincentw@ece.ubc.ca Technical Program Committee Imad Aad, EPFL, Switzerland Giuseppe Bianchi, University of Roma Tor Vergata, Italy Azzedine Boukerche, SITE, University of Ottawa, Canada Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Liang Cheng, Lehigh University, USA Jing Deng, University of New Orleans, USA Christos Douligeris, University of Piraeus, Greece Xiaojiang (James) Du, North Dakota State University, USA Nelson Fonseca, State University of Campinas, Brazil Jose Rosario Gallardo, CICESE, Mexico Daqing Gu, MERL, USA Xingang Guo, Intel, USA Janelle Harms, University of Alberta, Canada Ekram Hossain, University of Manitoba, Canada Antonio Iera, University Mediterranea of Reggio Calabria, Italy Weijia Jia, City University of Hong Kong, Hong Kong Xiaohua Jia, City University of Hong Kong , Hong Kong Victor Leung, University of British Columbia, Canada Haizhon Li, University of Memphis, USA Ting-Yu Lin, National Chiao-Tung University, Taiwan Jiangchuan Liu, Simon Fraser University, Canada Xiang-Yang Li, Illinois Institute of Technology, USA Mike MacGregor, University of Alberta, Canada Jelena Misic, University of Manitoba, Canada Vojislav B Misic, University of Manitoba, Canada Qiang Ni, National University of Ireland, Ireland Ioanis Nikolaidis, University of Alberta, Canada Jianping Pan, NTT MCL, USA Pascal Pagani, France Telecom, France Yi Qian, University of Puerto Rico, USA Daji Qiao, Iowa State University, USA Bo Sun, Lamar University, USA Ilenia Tinnirello, University of Palermo, Italy Dimitrios Vergados, University of the Aegean, Greece Feiyi Wang, Cisco Systems Inc, USA Lan Wang, University of Memphis, USA Li-Chun Wang, National Chiao Tung University, Taiwan Wenye Wang, North Carolina State University, USA Xudong Wang, Kiyon Inc., USA Yu Wang, University of California, Santa Cruz, USA Vincent Wong, University of British Columbia, Canada Haitao Wu, Microsoft Research, China Hongyi Wu, University of Louisiana at Lafayette, USA Jie Wu, Florida Atlantic University , USA Kui Wu, University of Victoria, Canada Surong Zeng, Motorola, USA Hao Zhu, Florida International University, USA From nemo-bounces@ietf.org Mon Dec 19 09:27:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoLzJ-00029g-7Q; Mon, 19 Dec 2005 09:27:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoLzH-00028j-Ga for nemo@megatron.ietf.org; Mon, 19 Dec 2005 09:27:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21812 for ; Mon, 19 Dec 2005 09:26:35 -0500 (EST) Received: from bugs.comnets.uni-bremen.de ([134.102.186.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoM1P-0007Id-2M for nemo@ietf.org; Mon, 19 Dec 2005 09:29:54 -0500 Received: from Fon (bugs.comnets.uni-bremen.de [134.102.155.1]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id jBJERTT09170 for ; Mon, 19 Dec 2005 15:27:29 +0100 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host bugs.comnets.uni-bremen.de [134.102.155.1] claimed to be Fon From: "Varaporn Pangboonyanon" To: Date: Mon, 19 Dec 2005 15:27:29 +0100 Message-ID: <000601c604a8$57559080$e73515ac@Fon> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO Basic support - Route optimization X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, I have a question regarding to RFC 3963 in 'Appendix A'. I think here in the NEMO basic support does not allow to have route optimization at the CN. In the example (Appendix A) fig. 2, when the MR moves away from HA_MR, route at HA_MR and CN_MR are set as 4::2 -> 7::2. This means whether MR performs route optimization to CN_MR or not? Best regards, Pangbooyanon V. ------ Varaporn Pangboonyanon University of Bremen, FB 1 - IKOM/ComNets Otto-Hahn-Allee NW 1, 28359 Bremen - Germany Tel.: +49 421 218 8264, Fax: +49 421 218 3601, Email: fon@comnets.uni-bremen.de From nemo-bounces@ietf.org Mon Dec 19 13:18:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoPaR-0001Ud-5e; Mon, 19 Dec 2005 13:18:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoPaP-0001UV-L6 for nemo@megatron.ietf.org; Mon, 19 Dec 2005 13:18:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22200 for ; Mon, 19 Dec 2005 13:17:10 -0500 (EST) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoPca-0007b4-4w for nemo@ietf.org; Mon, 19 Dec 2005 13:20:34 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 5EBD08ABAE6; Mon, 19 Dec 2005 10:16:50 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91041-04; Mon, 19 Dec 2005 10:16:49 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id B01C38ABAD6; Mon, 19 Dec 2005 10:16:49 -0800 (PST) X-Spam-Score: -2.7 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.103.16.119] (unknown [192.103.16.119]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 545768AB9B1; Mon, 19 Dec 2005 10:16:49 -0800 (PST) In-Reply-To: <000601c604a8$57559080$e73515ac@Fon> References: <000601c604a8$57559080$e73515ac@Fon> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D62B16F-567F-4929-9BE3-AB7B30846C4B@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] NEMO Basic support - Route optimization Date: Mon, 19 Dec 2005 10:17:51 -0800 To: Varaporn Pangboonyanon X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Dec 19, 2005, at 6:27 AM, Varaporn Pangboonyanon wrote: > I have a question regarding to RFC 3963 in 'Appendix A'. I think > here in > the NEMO basic support does not allow to have route optimization at > the > CN. In the example (Appendix A) fig. 2, when the MR moves away from > HA_MR, route at HA_MR and CN_MR are set as 4::2 -> 7::2. This means > whether MR performs route optimization to CN_MR or not? Correct. There is no route optimization in RFC 3963. TJ From nemo-bounces@ietf.org Mon Dec 19 14:20:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoQYt-0006b8-MI; Mon, 19 Dec 2005 14:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoQYs-0006aw-5F for nemo@megatron.ietf.org; Mon, 19 Dec 2005 14:20:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00043 for ; Mon, 19 Dec 2005 14:19:38 -0500 (EST) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoQb7-0001Dp-3W for nemo@ietf.org; Mon, 19 Dec 2005 14:23:02 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id jBJJKKK1029082; Mon, 19 Dec 2005 12:20:20 -0700 (MST) Received: from [10.181.33.230] (mvp-10-181-33-230.ea.mot.com [10.181.33.230]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id jBJJSZWd009421; Mon, 19 Dec 2005 13:28:36 -0600 (CST) Message-ID: <43A707F1.8030804@motorola.com> Date: Mon, 19 Dec 2005 20:20:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Varaporn Pangboonyanon Subject: Re: [nemo] NEMO Basic support - Route optimization References: <000601c604a8$57559080$e73515ac@Fon> In-Reply-To: <000601c604a8$57559080$e73515ac@Fon> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Varaporn Pangboonyanon wrote: > Dear all, > > I have a question regarding to RFC 3963 in 'Appendix A'. I think here > in the NEMO basic support does not allow to have route optimization > at the CN. In the example (Appendix A) fig. 2, when the MR moves away > from HA_MR, route at HA_MR and CN_MR are set as 4::2 -> 7::2. Text "4::2->7::2" designates a binding cache entry, not a "route". Meaning that CN_MR registers the Care-of Address of MR (7::2) as related to MR's Home Address (4::2). Not the Mobile Network Prefix, but the full /128 address. This is for when the MR acts as a Mobile Host, i.e. applications running on the MR may benefit of Route Optimization with the CN_MR (but not the applications running on LFN). > This means whether MR performs route optimization to CN_MR or not? Yes, MR may act as MH for its Home Address and Care-of Address, and subsequently do Return Routability tests for these two addresses (but not for LFNs or other MHs on the moving link(s). Alex From nemo-bounces@ietf.org Tue Dec 27 05:23:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErBzS-0003JR-0J; Tue, 27 Dec 2005 05:23:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErBzO-0003JH-BJ for nemo@megatron.ietf.org; Tue, 27 Dec 2005 05:23:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23091 for ; Tue, 27 Dec 2005 05:22:20 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErC3B-0004sa-Bl for nemo@ietf.org; Tue, 27 Dec 2005 05:27:27 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBRANLMi026689; Tue, 27 Dec 2005 19:23:21 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBRANKUO000065; Tue, 27 Dec 2005 19:23:20 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBRANJvd021879; Tue, 27 Dec 2005 19:23:19 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBRANJmx011007; Tue, 27 Dec 2005 19:23:19 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBRANCx2022328; Tue, 27 Dec 2005 19:23:12 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (imj.m.ecl.ntt.co.jp [129.60.5.234]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBRANChc022323; Tue, 27 Dec 2005 19:23:12 +0900 (JST) Received: from [129.60.10.37] ([129.60.10.37]) by imj.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jBRANBXJ019370; Tue, 27 Dec 2005 19:23:12 +0900 (JST) Date: Tue, 27 Dec 2005 19:23:15 +0900 From: Takaaki Moriya To: Francis Dupont Subject: Re: [nemo] IPsec for payload packets In-Reply-To: <200512151516.jBFFGqgI027397@givry.rennes.enst-bretagne.fr> References: <20051215220859.B9BE.MORIYA.TAKAAKI@lab.ntt.co.jp> <200512151516.jBFFGqgI027397@givry.rennes.enst-bretagne.fr> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.054 Message-Id: <20051227191919.F54E.MORIYA.TAKAAKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Francis, Thank you very much for your advice, and I am really sorry that I could not reply you sooner. I understand what you mean, but I have been considering this issue from the viewpoint of interoperability. Even though it is an instance, RFC 3776 section 5.2.4 mentions the payload packets as "proto = X". In this instance, I thought that such additional entries(i.e. "SA9 and SA10") may be needed if eggress interface of Mobile Router is used for its Home Address. I mean, since RFC3963 just refers to RFC3776 regarding IPsec, I wonder whether all the developers can expect the same (or equivalent) SPD entries. Some people might expect such "SA9 and SA10", and others might not. I would appreciate it if you would let me know or would advise me. Best Regards, Takaaki Moriya On Thu, 15 Dec 2005 16:16:52 +0100 Francis Dupont wrote: > In your previous mail you wrote: > > I have a question related to IPsec for payload packets. > > RFC3963 refers to RFC3776 concerning the use of IPsec to protect Mobile > IPv6 signaling messages as follows. > > => note you have at least 3 very different things: > - what is possible in theory with RFC 2401 and IKEv1 (as these > documents are not coherent and clearly incompatible, this can > become a bit hairy :-) > - what is possible in theory with 2401bis and IKEv2 (previous issues > are supposed to have been fixed but) > - what is possible in practice with the IPsec/IKE implementation > you have (I consider you have the common Linux 2.6 (aka USAGI) / > BSD (aka KAME) implementation which is well known). > > > All signaling messages between the Mobile Router and the Home Agent > > MUST be authenticated by IPsec [8]. The use of IPsec to protect > > Mobile IPv6 signaling messages is described in detail in the HA-MN > > IPsec specification [2]. The signaling messages described in this > > document extend Mobile IPv6 messages and do not require any changes > > to what is described in [2]. > > => this is a quote from RFC 3963. > > As for payload packets, when ingress interface of Mobile Router is used > for its Home Address, I think that SPD/SAD for payload packets > > => precision: "payload packets" are not always all/any protocol > (in RFC 3776 section 5.2.4 for instance you have "proto = X") > > are naturally configurated as follows. > > -------------------------------------------------- > | SPD | | SRC | DST | > --------------------------------------------------- > | SA7 [MR -> HA] | Outer | MR_CoA | HA | > | | Inner | MNP | any | > -------------------------------------------------- > | SA8 [HA -> MR] | Outer | HA | MR_CoA | > | | Inner | any | MNP | > -------------------------------------------------- > > => these are tunnel mode SPD entries so the selectors are *only* > on the inner header. To make this works, i.e., to take the > outer header into account, the RFC 3776 uses the interface stuff > (fortunately only in examples :-). > > However, when eggress interface of Mobile Router is used for its Home > Address, I think that the following policies are needed in addition to > the above SA7 and SA8. For example, they might be used when Mobile > router itself sends some messages to CN. > > => you may have narrower SPD entries with a higher priority, in fact, > if the traffic payload matches the signaling but with a lower security > level, you must have them (i.e., 5.2.2 has to take precedence over > 5.2.4, and 5.3.2 over 5.3.4). Note that the match here is true only > when X = any (2401bis/IKEv2 is more complex but the requirement is > the same). > > Is it correct ? > > => yes, you may have other SPD entries... > > -------------------------------------------------- > | SPD | | SRC | DST | > --------------------------------------------------- > | SA9?[MR -> HA] | Outer | MR_CoA | HA | > | | Inner | MR_HoA | any | > -------------------------------------------------- > | SA10?[HA -> MR] | Outer | HA | MR_CoA | > | | Inner | any | MR_HoA | > -------------------------------------------------- > > I wonder some implementations might not need these additional policies > (SA9 and SA10), because they can cover these SA9 and SA10 just by using > the existing SA7 and SA8. > > => I have to understand that "cover" can make things simpler but can > break the security too. This is a basic issue in IPsec policies: when > they overlap the strong one must be used for the intersection. > > Regards > > Francis.Dupont@enst-bretagne.fr -- Takaaki Moriya From nemo-bounces@ietf.org Wed Dec 28 03:52:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErX2w-0007ET-RQ; Wed, 28 Dec 2005 03:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErX2v-0007EO-3f for nemo@megatron.ietf.org; Wed, 28 Dec 2005 03:52:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09517 for ; Wed, 28 Dec 2005 03:51:22 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErX6u-0006Ji-CL for nemo@ietf.org; Wed, 28 Dec 2005 03:56:41 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBS8qIG3028015 for ; Wed, 28 Dec 2005 17:52:18 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBS8qH50022561 for ; Wed, 28 Dec 2005 17:52:17 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBS8qG2v015137 for ; Wed, 28 Dec 2005 17:52:16 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBS8qG9P029389 for ; Wed, 28 Dec 2005 17:52:16 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBS8qGwT021263 for ; Wed, 28 Dec 2005 17:52:16 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (imj.m.ecl.ntt.co.jp [129.60.5.234]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id jBS8qFa2021260 for ; Wed, 28 Dec 2005 17:52:15 +0900 (JST) Received: from [129.60.10.37] ([129.60.10.37]) by imj.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id jBS8qFna018137 for ; Wed, 28 Dec 2005 17:52:15 +0900 (JST) Date: Wed, 28 Dec 2005 17:52:18 +0900 From: Takaaki Moriya To: nemo@ietf.org X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.054 Message-Id: <20051228175147.0E8E.MORIYA.TAKAAKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [nemo] Home address of mobile router X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, I have a question concerning home address of mobile router. What RFC3963 (especially section 6.2) means is as follows ? Home address of mobile router can be A) configured with its ingress interface B) configured with its egress interface and then, mobile router supports either A) or B) for home registration and any other functions, while home agent must support both A) and B). Thank you very much in advance. Best Regards, -- Takaaki Moriya From nemo-bounces@ietf.org Wed Dec 28 15:50:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EriFs-00017w-7V; Wed, 28 Dec 2005 15:50:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EriFJ-0000uD-0W; Wed, 28 Dec 2005 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08319; Wed, 28 Dec 2005 15:48:54 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EriJO-00027n-2I; Wed, 28 Dec 2005 15:54:18 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EriFG-0002Zt-62; Wed, 28 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Dec 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-ro-problem-statement-02.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-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 Mobility Working Group of the IETF. Title : Network Mobility Route Optimization Problem Statement Author(s) : C. Ng. et al. Filename : draft-ietf-nemo-ro-problem-statement-02.txt Pages : 29 Date : 2005-12-28 With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems, and provides for the motivation behind Route Optimization (RO) for NEMO. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-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-nemo-ro-problem-statement-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-nemo-ro-problem-statement-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: <2005-12-28112445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-ro-problem-statement-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-ro-problem-statement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-28112445.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Sat Dec 31 05:59:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EseSi-0004Nl-TU; Sat, 31 Dec 2005 05:59:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EseSi-0004Ng-4c for nemo@megatron.ietf.org; Sat, 31 Dec 2005 05:59:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26509 for ; Sat, 31 Dec 2005 05:58:36 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EseXK-000253-BE for nemo@ietf.org; Sat, 31 Dec 2005 06:04:35 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jBVAxA720265; Sat, 31 Dec 2005 11:59:10 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jBVAx9qw054332; Sat, 31 Dec 2005 11:59:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200512311059.jBVAx9qw054332@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Takaaki Moriya Subject: Re: [nemo] IPsec for payload packets In-reply-to: Your message of Tue, 27 Dec 2005 19:23:15 +0900. <20051227191919.F54E.MORIYA.TAKAAKI@lab.ntt.co.jp> Date: Sat, 31 Dec 2005 11:59:09 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: I understand what you mean, but I have been considering this issue from the viewpoint of interoperability. => the answer is simple: the policies (I use this term because the formal SPD entries don't include common things like SA sharing control) must match or something will fail. So when there are possible choices (and when you consider SA sharing issues there are likely some) one must take care to configure compatible policies... I mean, since RFC3963 just refers to RFC3776 regarding IPsec, I wonder whether all the developers can expect the same (or equivalent) SPD entries. => no but all the developers should propose enough or it will be possible to find no compatible policies... Regards Francis.Dupont@point6.net