From mailman-owner@ietf.org Mon Apr 1 06:33:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19128 for ; Mon, 1 Apr 2002 06:33:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08723 for ; Mon, 1 Apr 2002 06:33:54 -0500 (EST) Date: Mon, 1 Apr 2002 06:33:54 -0500 (EST) Message-Id: <200204011133.GAA08723@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: manet-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, manet-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for manet-archive@lists.ietf.org: List Password // URL ---- -------- manet@ietf.org FtOz https://www1.ietf.org/mailman/options/manet/manet-archive@lists.ietf.org From manet-admin@ietf.org Mon Apr 1 11:57:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04983 for ; Mon, 1 Apr 2002 11:57:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19616; Mon, 1 Apr 2002 11:28:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19589 for ; Mon, 1 Apr 2002 11:28:29 -0500 (EST) Received: from uni03mr.unity.ncsu.edu (uni03mr.unity.ncsu.edu [152.1.1.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03884 for ; Mon, 1 Apr 2002 11:28:27 -0500 (EST) Received: from unity.ncsu.edu (uni02wi.unity.ncsu.edu [152.1.1.32]) by uni03mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with ESMTP id g31GSUQ04795 for ; Mon, 1 Apr 2002 11:28:31 -0500 (EST) Message-Id: <200204011628.g31GSUQ04795@uni03mr.unity.ncsu.edu> X-Originating-IP: [152.1.60.175] User-Agent: IMHO/0.97.1 (Webmail for Roxen) In-Reply-To: Content-Transfer-Encoding: 8bit From: Sudarshan N Raghavan To: manet@ietf.org Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Date: Mon, 01 Apr 2002 11:28:28 -500 Content-Transfer-Encoding: 8bit Subject: [manet] DSR - Expanding ring search Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, Has any work been done on evaluating the performance of the expanding ring search algorithm in DSR ? If yes, could someone forward me the relevant links ? Regards, Sudarshan Raghavan Computer Sc. Department NC State University _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 1 11:57:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04992 for ; Mon, 1 Apr 2002 11:57:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21776 for manet-archive@odin.ietf.org; Mon, 1 Apr 2002 11:57:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19616; Mon, 1 Apr 2002 11:28:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19589 for ; Mon, 1 Apr 2002 11:28:29 -0500 (EST) Received: from uni03mr.unity.ncsu.edu (uni03mr.unity.ncsu.edu [152.1.1.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03884 for ; Mon, 1 Apr 2002 11:28:27 -0500 (EST) Received: from unity.ncsu.edu (uni02wi.unity.ncsu.edu [152.1.1.32]) by uni03mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with ESMTP id g31GSUQ04795 for ; Mon, 1 Apr 2002 11:28:31 -0500 (EST) Message-Id: <200204011628.g31GSUQ04795@uni03mr.unity.ncsu.edu> X-Originating-IP: [152.1.60.175] User-Agent: IMHO/0.97.1 (Webmail for Roxen) In-Reply-To: Content-Transfer-Encoding: 8bit From: Sudarshan N Raghavan To: manet@ietf.org Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Date: Mon, 01 Apr 2002 11:28:28 -500 Content-Transfer-Encoding: 8bit Subject: [manet] DSR - Expanding ring search Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, Has any work been done on evaluating the performance of the expanding ring search algorithm in DSR ? If yes, could someone forward me the relevant links ? Regards, Sudarshan Raghavan Computer Sc. Department NC State University _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 1 13:03:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08329 for ; Mon, 1 Apr 2002 13:03:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26302; Mon, 1 Apr 2002 12:48:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26272 for ; Mon, 1 Apr 2002 12:48:01 -0500 (EST) Received: from peregrine.nps.navy.mil (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07504 for ; Mon, 1 Apr 2002 12:47:58 -0500 (EST) Received: from capella.nps.navy.mil by peregrine.nps.navy.mil via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 1 Apr 2002 17:50:42 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g31HjJ4B017316; Mon, 1 Apr 2002 09:45:20 -0800 (PST) Mime-Version: 1.0 X-Sender: budden@grasp.ad.nps.navy.mil Message-Id: In-Reply-To: References: Date: Mon, 1 Apr 2002 09:40:43 -0800 To: , From: Rex Buddenberg Subject: Re: [manet] Prior work on manets with ring topologies? Content-Type: multipart/alternative; boundary="============_-1194439112==_ma============" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --============_-1194439112==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" ;-) Well, the original Link 11 setup was what we'd today call a broadcast ring LAN. Vintage mid-1950s. Each participating unit took a number and each would send it's queue of track reports, followed by a token that was the cue for the next participating unit to send. The problem was that if any member of the ring missed the cue, not only did that participating unit not send, but the whole network crashed. This is not a Good Thing when you're under air attack. Upon discovery of this behavior, Link 11 was changed to a polled broadcast network. A network controller cues each participating unit in turn. If a unit misses two polls, the controller gives up in disgust and goes on to the next unit. This made the system much more robust against random receive failures, at the price of introduction of a single point of failure (the controller). This weakness, in turn, was offset by designation of a backup network controller. At 8:06 PM -0800 3/31/02, wrote: >Hi, > >Is there anybody currently (or in the past) who has worked on wireless >mobile ad hoc networks using ring topologies? > >Are there key papers on this topic of manets with ring topologies? > >Thank you and best regards, >Foo Chun Choong >Open Source Software Lab, >National University of Singapore >http://opensource.nus.edu.sg > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet -- b --============_-1194439112==_ma============ Content-Type: text/html; charset="us-ascii" Re: [manet] Prior work on manets with ring topologies?
;-)

Well, the original Link 11 setup was what we'd today call a broadcast ring LAN.

Vintage mid-1950s.  Each participating unit took a number and each would send it's queue of track reports, followed by a token that was the cue for the next participating unit to send.  The problem was that if any member of the ring missed the cue, not only did that participating unit not send, but the whole network crashed.  This is not a Good Thing when you're under air attack.

Upon discovery of this behavior, Link 11 was changed to a polled broadcast network.  A network controller cues each participating unit in turn.  If a unit misses two polls, the controller gives up in disgust and goes on to the next unit.  This made the system much more robust against random receive failures, at the price of introduction of a single point of failure (the controller).  This weakness, in turn, was offset by designation of a backup network controller.



At 8:06 PM -0800 3/31/02, <ccfoo@hawk.ece.nus.edu.sg> wrote:
Hi,
Is there anybody currently (or in the past) who has worked on wireless
mobile ad hoc networks using ring topologies?
Are there key papers on this topic of manets with ring topologies?
Thank you and best regards,
Foo Chun Choong
Open Source Software Lab,
National University of Singapore
http://opensource.nus.edu.sg

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


--
b
--============_-1194439112==_ma============-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 1 13:03:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08339 for ; Mon, 1 Apr 2002 13:03:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28285 for manet-archive@odin.ietf.org; Mon, 1 Apr 2002 13:04:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26302; Mon, 1 Apr 2002 12:48:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26272 for ; Mon, 1 Apr 2002 12:48:01 -0500 (EST) Received: from peregrine.nps.navy.mil (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07504 for ; Mon, 1 Apr 2002 12:47:58 -0500 (EST) Received: from capella.nps.navy.mil by peregrine.nps.navy.mil via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 1 Apr 2002 17:50:42 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g31HjJ4B017316; Mon, 1 Apr 2002 09:45:20 -0800 (PST) Mime-Version: 1.0 X-Sender: budden@grasp.ad.nps.navy.mil Message-Id: In-Reply-To: References: Date: Mon, 1 Apr 2002 09:40:43 -0800 To: , From: Rex Buddenberg Subject: Re: [manet] Prior work on manets with ring topologies? Content-Type: multipart/alternative; boundary="============_-1194439112==_ma============" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --============_-1194439112==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" ;-) Well, the original Link 11 setup was what we'd today call a broadcast ring LAN. Vintage mid-1950s. Each participating unit took a number and each would send it's queue of track reports, followed by a token that was the cue for the next participating unit to send. The problem was that if any member of the ring missed the cue, not only did that participating unit not send, but the whole network crashed. This is not a Good Thing when you're under air attack. Upon discovery of this behavior, Link 11 was changed to a polled broadcast network. A network controller cues each participating unit in turn. If a unit misses two polls, the controller gives up in disgust and goes on to the next unit. This made the system much more robust against random receive failures, at the price of introduction of a single point of failure (the controller). This weakness, in turn, was offset by designation of a backup network controller. At 8:06 PM -0800 3/31/02, wrote: >Hi, > >Is there anybody currently (or in the past) who has worked on wireless >mobile ad hoc networks using ring topologies? > >Are there key papers on this topic of manets with ring topologies? > >Thank you and best regards, >Foo Chun Choong >Open Source Software Lab, >National University of Singapore >http://opensource.nus.edu.sg > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet -- b --============_-1194439112==_ma============ Content-Type: text/html; charset="us-ascii" Re: [manet] Prior work on manets with ring topologies?
;-)

Well, the original Link 11 setup was what we'd today call a broadcast ring LAN.

Vintage mid-1950s.  Each participating unit took a number and each would send it's queue of track reports, followed by a token that was the cue for the next participating unit to send.  The problem was that if any member of the ring missed the cue, not only did that participating unit not send, but the whole network crashed.  This is not a Good Thing when you're under air attack.

Upon discovery of this behavior, Link 11 was changed to a polled broadcast network.  A network controller cues each participating unit in turn.  If a unit misses two polls, the controller gives up in disgust and goes on to the next unit.  This made the system much more robust against random receive failures, at the price of introduction of a single point of failure (the controller).  This weakness, in turn, was offset by designation of a backup network controller.



At 8:06 PM -0800 3/31/02, <ccfoo@hawk.ece.nus.edu.sg> wrote:
Hi,
Is there anybody currently (or in the past) who has worked on wireless
mobile ad hoc networks using ring topologies?
Are there key papers on this topic of manets with ring topologies?
Thank you and best regards,
Foo Chun Choong
Open Source Software Lab,
National University of Singapore
http://opensource.nus.edu.sg

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


--
b
--============_-1194439112==_ma============-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 1 13:15:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09015 for ; Mon, 1 Apr 2002 13:15:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27148; Mon, 1 Apr 2002 12:59:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27119 for ; Mon, 1 Apr 2002 12:59:06 -0500 (EST) Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08017 for ; Mon, 1 Apr 2002 12:59:01 -0500 (EST) Received: from [217.227.146.82] (helo=navayo) by smtp.web.de with esmtp (WEB.DE(Exim) 4.43 #48) id 16s64a-0000xE-00 for manet@ietf.org; Mon, 01 Apr 2002 19:58:28 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Frank Dinies Date: Mon, 1 Apr 2002 20:00:13 +0200 X-Mailer: KMail [version 1.4] To: manet@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204012000.13620.FrankDinies@web.de> Content-Transfer-Encoding: 8bit Subject: [manet] OMNeT++- Simulations Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, this is a call for everybody who is dealing with ad-hoc-routing protocols and OMNeT++. I, for myself, think it is difficult to proper evaluate an algorithmen without comparisons to as much as possible. ;-) So, it would be nice to have a testbed in which every algorithmen could compete (somehow similar to "Corewars" if somebody remembers). So,, hmm, what I want to say ,,,... I am working with such a kind of testbed, developed at the University of Karlsruhe in Germany. It makes it possible to integrate every kind of routing prortocol (either proactive and reactive). At the moment FSR and TORA were implemented there. So to my points: - OMNeT++ is freely availabe - our framework as well - there are protocols imlplemented, which showed, pro- or reactive ones could easily be integrated --> more to come ???? I would be happy to hear from everybody, willing to compete !!!! Regards and ad-hoc Frank Dinies _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 1 13:15:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09025 for ; Mon, 1 Apr 2002 13:15:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29454 for manet-archive@odin.ietf.org; Mon, 1 Apr 2002 13:15:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27148; Mon, 1 Apr 2002 12:59:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27119 for ; Mon, 1 Apr 2002 12:59:06 -0500 (EST) Received: from smtp.web.de (smtp02.web.de [217.72.192.151]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08017 for ; Mon, 1 Apr 2002 12:59:01 -0500 (EST) Received: from [217.227.146.82] (helo=navayo) by smtp.web.de with esmtp (WEB.DE(Exim) 4.43 #48) id 16s64a-0000xE-00 for manet@ietf.org; Mon, 01 Apr 2002 19:58:28 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Frank Dinies Date: Mon, 1 Apr 2002 20:00:13 +0200 X-Mailer: KMail [version 1.4] To: manet@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204012000.13620.FrankDinies@web.de> Content-Transfer-Encoding: 8bit Subject: [manet] OMNeT++- Simulations Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, this is a call for everybody who is dealing with ad-hoc-routing protocols and OMNeT++. I, for myself, think it is difficult to proper evaluate an algorithmen without comparisons to as much as possible. ;-) So, it would be nice to have a testbed in which every algorithmen could compete (somehow similar to "Corewars" if somebody remembers). So,, hmm, what I want to say ,,,... I am working with such a kind of testbed, developed at the University of Karlsruhe in Germany. It makes it possible to integrate every kind of routing prortocol (either proactive and reactive). At the moment FSR and TORA were implemented there. So to my points: - OMNeT++ is freely availabe - our framework as well - there are protocols imlplemented, which showed, pro- or reactive ones could easily be integrated --> more to come ???? I would be happy to hear from everybody, willing to compete !!!! Regards and ad-hoc Frank Dinies _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 1 13:35:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09814 for ; Mon, 1 Apr 2002 13:35:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29514; Mon, 1 Apr 2002 13:16:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29485 for ; Mon, 1 Apr 2002 13:16:20 -0500 (EST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09053 for ; Mon, 1 Apr 2002 13:16:02 -0500 (EST) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g31IFvO28565; Mon, 1 Apr 2002 10:15:57 -0800 (PST) Message-Id: <200204011815.g31IFvO28565@letters.cs.ucsb.edu> Date: Mon, 1 Apr 2002 10:15:57 -0800 (PST) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" Subject: Re: [manet] 1st AODV Interop a Success! To: paul@etri.re.kr Cc: manet@ietf.org, active@krv6.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bD+hmvM31yRVbzldknwcjQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Jaehoon, I don't know whether the two IPv6 implementations are publically available. To my knowledge they are not. However, the two developers of those implementations are on this list, so if the implementations are available I'm sure they will let you know. I have heard of people implementing MAODV, but I have not yet heard of any completed implementations. Does anyone out there have one? There are three available AODVv4 implementations on the AODV webpage (http://moment.cs.ucsb.edu/AODV/aodv.html). One more will be released very soon. Elizabeth ~> ~> I am Jaehoon, researcher of ETRI in Korea. ~> ETRI is under the development of IPv6 ad-hoc multicast application such as video-conferencing. ~> Because ETRI thought there are no implementation of IPv6 AODV and IPv6 MAODV, ~> ETRI planned to implement IPv6 AODV and IPv6 MAODV for itself. ~> We are pleased to hear the news from you. We would like to know if we can get IPv6 AODV ~> source code from anyone or any organization. We think the reference will be helpful for us. ~> I also wonder if IPv4 MAODV or IPv6 MAODV has been already implemented. ~> Thanks in advance. ~> ~> Regards, ~> Jaehoon ~> ~> ----- Original Message ----- ~> From: "Elizabeth M. Belding-Royer" ~> To: ; ~> Cc: ~> Sent: Thursday, March 28, 2002 7:45 AM ~> Subject: [manet] 1st AODV Interop a Success! ~> ~> ~> > ~> > We are pleased to announce a successful 1st AODV Interop. ~> > The event was held at the University of California, Santa Barbara ~> > on March 25 and 26th, 2002. Attending were four IPv4 implementations ~> > and two IPv6 implementations. ~> > ~> > Interoperation of the IPv4 implemenations was very successful. ~> > Operation was tested over wired Ethernet, over wireless links ~> > using ipTables to provide binary link connectivity, and over ~> > wireless links using obstacles to provide link disconnections. ~> > The latter test included nodes distributed throughout a building, ~> > and route discovery and web page retrieval over a four node path. ~> > Route discovery, link break detection, and subsequent route repair ~> > through a different intermediate node was tested with the four ~> > implementations and all successfully worked. Networks with as ~> > many as seven nodes were tested. ~> > ~> > The IPv6 implementations successfully interoperated with ~> > hello-based and reactive route discovery. A more limited set of ~> > tests (less than 3 hops) were performed with the IPv6 implementations, ~> > primarily due to lack of adequate filtering support for IPv6 on the ~> > tested platforms, and a smaller number of available implementations. ~> > These tests provided the first evidence that the same interoperation ~> > as with IPv4 is feasible using the IPv6 version of the protocol. ~> > ~> > Further details about the event are forthcoming, once post-processing ~> > is completed. ~> > ~> > Thanks to all who attended and helped plan the event! ~> > ~> > Elizabeth ~> > ~> > ~> > _______________________________________________ ~> > manet mailing list ~> > manet@ietf.org ~> > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 1 13:35:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09823 for ; Mon, 1 Apr 2002 13:35:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01859 for manet-archive@odin.ietf.org; Mon, 1 Apr 2002 13:35:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29514; Mon, 1 Apr 2002 13:16:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29485 for ; Mon, 1 Apr 2002 13:16:20 -0500 (EST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09053 for ; Mon, 1 Apr 2002 13:16:02 -0500 (EST) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g31IFvO28565; Mon, 1 Apr 2002 10:15:57 -0800 (PST) Message-Id: <200204011815.g31IFvO28565@letters.cs.ucsb.edu> Date: Mon, 1 Apr 2002 10:15:57 -0800 (PST) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" Subject: Re: [manet] 1st AODV Interop a Success! To: paul@etri.re.kr Cc: manet@ietf.org, active@krv6.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: bD+hmvM31yRVbzldknwcjQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Jaehoon, I don't know whether the two IPv6 implementations are publically available. To my knowledge they are not. However, the two developers of those implementations are on this list, so if the implementations are available I'm sure they will let you know. I have heard of people implementing MAODV, but I have not yet heard of any completed implementations. Does anyone out there have one? There are three available AODVv4 implementations on the AODV webpage (http://moment.cs.ucsb.edu/AODV/aodv.html). One more will be released very soon. Elizabeth ~> ~> I am Jaehoon, researcher of ETRI in Korea. ~> ETRI is under the development of IPv6 ad-hoc multicast application such as video-conferencing. ~> Because ETRI thought there are no implementation of IPv6 AODV and IPv6 MAODV, ~> ETRI planned to implement IPv6 AODV and IPv6 MAODV for itself. ~> We are pleased to hear the news from you. We would like to know if we can get IPv6 AODV ~> source code from anyone or any organization. We think the reference will be helpful for us. ~> I also wonder if IPv4 MAODV or IPv6 MAODV has been already implemented. ~> Thanks in advance. ~> ~> Regards, ~> Jaehoon ~> ~> ----- Original Message ----- ~> From: "Elizabeth M. Belding-Royer" ~> To: ; ~> Cc: ~> Sent: Thursday, March 28, 2002 7:45 AM ~> Subject: [manet] 1st AODV Interop a Success! ~> ~> ~> > ~> > We are pleased to announce a successful 1st AODV Interop. ~> > The event was held at the University of California, Santa Barbara ~> > on March 25 and 26th, 2002. Attending were four IPv4 implementations ~> > and two IPv6 implementations. ~> > ~> > Interoperation of the IPv4 implemenations was very successful. ~> > Operation was tested over wired Ethernet, over wireless links ~> > using ipTables to provide binary link connectivity, and over ~> > wireless links using obstacles to provide link disconnections. ~> > The latter test included nodes distributed throughout a building, ~> > and route discovery and web page retrieval over a four node path. ~> > Route discovery, link break detection, and subsequent route repair ~> > through a different intermediate node was tested with the four ~> > implementations and all successfully worked. Networks with as ~> > many as seven nodes were tested. ~> > ~> > The IPv6 implementations successfully interoperated with ~> > hello-based and reactive route discovery. A more limited set of ~> > tests (less than 3 hops) were performed with the IPv6 implementations, ~> > primarily due to lack of adequate filtering support for IPv6 on the ~> > tested platforms, and a smaller number of available implementations. ~> > These tests provided the first evidence that the same interoperation ~> > as with IPv4 is feasible using the IPv6 version of the protocol. ~> > ~> > Further details about the event are forthcoming, once post-processing ~> > is completed. ~> > ~> > Thanks to all who attended and helped plan the event! ~> > ~> > Elizabeth ~> > ~> > ~> > _______________________________________________ ~> > manet mailing list ~> > manet@ietf.org ~> > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 2 02:38:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08949 for ; Tue, 2 Apr 2002 02:38:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20433; Tue, 2 Apr 2002 01:48:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20400 for ; Tue, 2 Apr 2002 01:48:10 -0500 (EST) Received: from camars.kaist.ac.kr (camars.kaist.ac.kr [143.248.137.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29892 for ; Tue, 2 Apr 2002 01:48:07 -0500 (EST) Received: from capictor (capictor.kaist.ac.kr [143.248.150.112]) by camars.kaist.ac.kr (8.9.3/8.9.3) with SMTP id PAA07818 for ; Tue, 2 Apr 2002 15:37:00 +0900 (KST) Message-ID: <029c01c1da12$5751f520$7096f88f@capictor> From: "Seung-hak Lee" To: Date: Tue, 2 Apr 2002 15:48:04 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0299_01C1DA5D.C70A28B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] CFP: Extended Deadline for IWAHN2002 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0299_01C1DA5D.C70A28B0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQpNeSBhcG9sb2dpZXMgaWYgeW91IHJlY2VpdmUgdGhpcyBDRlAgZHVwbGljYXRlZC4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpOb3RlOiAgVGhlIGRlYWRsaW5lIGhhcyBiZWVuIGV4dGVuZGVkIHRvIEFwcmlsIDIwLg0K DQogU2luY2Ugc2V2ZXJhbCBpbnRlbmRpbmcgc3VibWl0dGVycyBoYXZlIGFza2VkIGZvciBleHRy YSB0aW1lLCANCg0KIGl0IHNlZW1zIGZhaXIgdG8gb2ZmZXIgaXQgZ2VuZXJhbGx5LiANCg0KIFBs ZWFzZSB0YWtlIGFkdmFudGFnZSBvZiB0aGlzIGV4dGVuc2lvbiB0byBzdWJtaXQgeW91ciBwYXBl ci4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KQ0ZQIGZvciBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIEFkIEhv YyBOZXR3b3JraW5nIChJV0FITjIwMDIpDQoNCkNBTEwgRk9SIFBBUEVSUw0KDQpJbnRlcm5hdGlv bmFsIFdvcmtzaG9wIG9uIEFkIEhvYyBOZXR3b3JraW5nIChJV0FITjIwMDIpDQp0byBiZSBoZWxk IGluIGNvbmp1bmN0aW9uIHdpdGggSUNQUC0yMDAyDQoNCkF1Z3VzdCAxOC0yMSwgMjAwMg0KVmFu Y291dmVyLCBCcml0aXNoIENvbHVtYmlhLCBDYW5hZGEgDQoNCmh0dHA6Ly9jYWxhYi5rYWlzdC5h Yy5rci9Db25mL0lXQUhOMjAwMi8NCg0KDQpUaGlzIHdvcmtzaG9wIHByb3ZpZGVzIGEgZm9ydW0g Zm9yIGVuZ2luZWVycyBhbmQgc2NpZW50aXN0cyBpbiBhY2FkZW1pYSwgaW5kdXN0cnkgYW5kIA0K Z292ZXJubWVudCB0byBwcmVzZW50IHRoZWlyIGxhdGVzdCByZXNlYXJjaCBmaW5kaW5ncyBpbiBh bnkgYXNwZWN0IG9mIGFkIGhvYyBuZXR3b3JraW5nLiBUb3BpY3MgDQpvZiBpbnRlcmVzdCBpbmNs dWRlLCBidXQgYXJlIG5vdCBsaW1pdGVkIHRvOg0KDQogLSBBZCBIb2MgUm91dGluZyBQcm90b2Nv bHMgICAgICAgICAgIA0KIC0gQWQgSG9jIE11bHRpY2FzdGluZw0KIC0gQWQgSG9jIFRyYW5zcG9y dCBMYXllciBJc3N1ZXMgICAgIA0KIC0gQWQgSG9jIE5ldHdvcmtpbmcgb3ZlciBCbHVldG9vdGgN CiAtIFF1YWxpdHkgb2YgU2VydmljZSBJc3N1ZXMgDQogLSBBZCBIb2MgTmV0d29yayBBcmNoaXRl Y3R1cmVzDQogLSBTZW5zb3IgYW5kIERhdGEgRnVzaW9uIEFkIEhvYyBOZXR3b3JrcyANCiAtIE1l ZGlhIEFjY2VzcyBUZWNobmlxdWVzIA0KIC0gQXBwbGljYXRpb25zIGZvciBBZCBIb2MgTmV0d29y a3MgDQogLSBQZWVyLXRvLVBlZXIgTmV0d29ya2luZw0KIC0gRGlzdHJpYnV0ZWQgQWxnb3JpdGht cyBmb3IgQWQgSG9jIE5ldHdvcmtzIA0KIC0gTW9iaWxlIElQIHdpdGggQWQgSG9jDQogLSBMb3cg UG93ZXIgYW5kIEVuZXJneS1FZmZpY2llbnQgQWxnb3JpdGhtIGFuZCBQcm90b2NvbCBEZXNpZ25z DQogLSBTZWN1cml0eSBhbmQgRmF1bHQtVG9sZXJhbmNlIElzc3VlcyBmb3IgQWQgSG9jIE5ldHdv cmtzDQoNClBhcGVyIFN1Ym1pc3Npb24gOg0KQXV0aG9ycyBhcmUgaW52aXRlZCB0byBzdWJtaXQg cmVzZWFyY2ggY29udHJpYnV0aW9ucyByZXByZXNlbnRpbmcgb3JpZ2luYWwsIHByZXZpb3VzbHkg DQp1bnB1Ymxpc2hlZCB3b3JrLiBTdWJtaXR0ZWQgcGFwZXJzIHdpbGwgYmUgY2FyZWZ1bGx5IGV2 YWx1YXRlZCBiYXNlZCBvbiBvcmlnaW5hbGl0eSwgDQpzaWduaWZpY2FuY2UsIHRlY2huaWNhbCBz b3VuZG5lc3MsIGFuZCBjbGFyaXR5IG9mIGV4cG9zaXRpb24uIEFsbCBwYXBlcnMgd2lsbCBiZSBy ZWZlcmVlZCBieSBhdCANCmxlYXN0IHR3byBtZW1iZXJzIG9mIHRoZSBwcm9ncmFtIGNvbW1pdHRl ZS4gQWNjZXB0ZWQgcGFwZXJzIHdpbGwgYmUgcHVibGlzaGVkIGFzIHByb2NlZWRpbmdzIG9mIA0K SUNQUC0yMDAyIHdvcmtzaG9wcy4gQWxsIHN1Ym1pdHRlZCBwYXBlcnMgTVVTVCBiZSBmb3JtYXR0 ZWQgYWNjb3JkaW5nIHRvIHRoZSBhdXRob3IgZ3VpZGVsaW5lcyANCnByb3ZpZGVkIGJ5IElDUFAt MjAwMiBhbmQgTVVTVCBOT1QgYmUgbG9uZ2VyIHRoYW4gNiBwYWdlcy4NCg0KU3VibWlzc2lvbiBE ZWFkbGluZSAgQXByaWwgMjAsIDIwMDIgKEV4dGVuZGVkKQ0KQXV0aG9yIE5vdGlmaWNhdGlvbiAg TWF5IDEsIDIwMDINCkZpbmFsIE1hbnVzY3JpcHQgRHVlICBKdW5lIDEsIDIwMDINCg0KRWxlY3Ry b25pYyBTdWJtaXNzaW9uIDoNClBsZWFzZSBlLW1haWwgb25lIFBERiBvciBQb3N0U2NyaXB0IHZl cnNpb24gb2YgeW91ciBwYXBlciB0byB0aGUgV29ya3Nob3AgUHJvZ3JhbSBDaGFpciBhdA0KaHlv b25AY2FsYWIua2Fpc3QuYWMua3INCg0KV29ya3Nob3AgQ28tQ2hhaXJzIDoNClByb2Zlc3NvciBI eXVuc29vIFlvb24gDQpEZXB0LiBvZiBFbGVjdHJpY2FsIEVuZ2luZWVyaW5nIGFuZCBDb21wdXRl ciBTY2llbmNlIA0KS29yZWEgQWR2YW5jZWQgSW5zdGl0dXRlIG9mIFNjaWVuY2UgYW5kIFRlY2hu b2xvZ3kgIA0KMzczLTEgS3Vzb25nLWRvbmcsIFl1c29uZy1rdSwgRGFlam9uLCBLb3JlYSANCkUt bWFpbDogaHlvb25AY2FsYWIua2Fpc3QuYWMua3IgDQpUZWw6ICs4Mi00Mi04NjktMzUyOSAgRmF4 OiArODItNDItODY5LTU1NjkgDQoNClByb2Zlc3NvciBKb29uZy1Tb28gTWEgDQpNb2JpbGUgTXVs dGltZWRpYSBSZXNlYXJjaCBDZW50ZXINCkluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9uIFVu aXZlcnNpdHkgKElDVSkNCjU4LTQsIEh3YWFtLURvbmcgWXVzb25nLUd1IERhZWpvbiBLb3JlYQ0K RS1tYWlsOiBqc21hQGljdS5hYy5rcg0KVGVsOiArODItNDItODY2LTYxMjQNCg0KUHJvZ3JhbSBD b21taXR0ZWUgTWVtYmVycyA6DQpDaGFybGVzIEUuIFBlcmtpbnMsIE5va2lhIFJlc2VhcmNoIENl bnRlciANCkRhdmlkIEIuIEpvaG5zb24sIERlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZSBS aWNlIFVuaXZlcnNpdHkNCkVsaXphYmV0aCBNLiBSb3llciwgVW5pdmVyc2l0eSBvZiBDYWxpZm9y bmlhIGF0IFNhbnRhIEJhcmJhcmEgDQpaeWdtdW50IEouIEhhYXMsIENvcm5lbGwgVW5pdmVyc2l0 eSANClN0ZWZhbm8gQmFzYWduaSwgVVQtRGFsbGFzICANCllvdW5nLUJhZSBLbywgSUJNIFQuSi4g V2F0c29uIFJlc2VhcmNoDQpTb25nd3UgTHUsIFVDTEEgDQpTdW5nLUp1IExlZSwgSGV3bGV0dC1Q YWNrYXJkIExhYnMgDQpBbmRyZXcgQ2FtcGJlbGwsIENvbHVtYmlhIFVuaXZlcnNpdHkgIA0KUmFt IFJhbWFuYXRoYW4sIEJCTiBUZWNoLg0KUmFtZXNoIEdvdmluZGFuLCBJQ1NJLCBUaGUgVW5pdmVy c2l0eSBvZiBDYWxpZm9ybmlhIGF0IEJlcmtlbGV5DQpEYXZpZCBNYWx0eiwgQU9OIE5ldHdvcmtz ICANCkplYW4tUGllcnJlIEh1YmF1eCwgU3dpc3MgRmVkZXJhbCBJbnN0aXR1dGUgb2YgVGVjaG5v bG9neSANClRpbmctQ2hhbyBIb3UsIE5hdGlvbmFsIENodW5nIENoZW5nIFVuaXZlcnNpdHksIFRh aXdhbiANCkd1bnRlciBIb21tZWwsIFRlY2huaWNhbCBVbml2ZXJzaXR5IG9mIEJlcmxpbiwgR2Vy bWFueQ0KQ2hyaXN0aWFuIEJvbm5ldCwgSW5zdGl0dXQgRXVyZWNvbSwgRnJhbmNlIA0KR2VyYWxk IFEuIE1hZ3VpcmUsIFJveWFsIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5LCBTd2VkZW4NClcuIEMu IFdvbmcsIE5hdGlvbmFsIFVuaXZlcnNpdHkgb2YgU2luZ2Fwb3JlIA0KQnJhaGltIEJlbnNhb3Us IEhvbmcgS29uZyBVbml2ZXJzaXR5IG9mIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3kNClByYXZpbiBC aGFnd2F0LCBVbml2ZXJzaXR5IG9mIE1hcnlsYW5kDQpBb3lhbWEgVG9tb25vcmksIE9zYWthIFVu aXZlcnNpdHksIEphcGFuDQpUYWthaGlybyBIQVJBLCBPc2FrYSBVbml2ZXJzaXR5LCBKYXBhbiAN CktBV0FJLCBNYWtvdG8sIEt5b3RvIFVuaXZlcnNpdHksIEphcGFuICANClN1bmdiYWUgRXVuLCBI YW5uYW0gVW5pdmVyc2l0eSwgS29yZWENCklram9vbiBZZW9tLCBLQUlTVCwgS29yZWENCkNob25n a3dvbiBLaW0sIFNlb3VsIE5hdGlvbmFsIFVuaXZlcnNpdHksIEtvcmVhDQpKb29ud29uIExlZSwg S0FJU1QsIEtvcmVhDQoNCg0K ------=_NextPart_000_0299_01C1DA5D.C70A28B0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTMuMTEwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPk15IGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2 ZSB0aGlzIENGUCANCmR1cGxpY2F0ZWQuPEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Ob3RlOiZuYnNwOyBUaGUgZGVhZGxpbmUgaGFz IGJlZW4gZXh0ZW5kZWQgdG8gQXByaWwgDQoyMC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7U2luY2Ugc2V2ZXJhbCBpbnRlbmRpbmcgc3Vi bWl0dGVycyBoYXZlIGFza2VkIGZvciBleHRyYSANCnRpbWUsIDwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDtpdCBzZWVtcyBmYWlyIHRvIG9m ZmVyIGl0IGdlbmVyYWxseS4gPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPiZuYnNwO1BsZWFzZSB0YWtlIGFkdmFudGFnZSBvZiB0aGlzIGV4dGVuc2lv biB0byBzdWJtaXQgeW91ciANCnBhcGVyLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ PEZPTlQgc2l6ZT0yPg0KPERJVj48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5DRlAgZm9yIEludGVybmF0aW9uYWwgV29ya3Nob3Agb24gQWQgSG9jIE5ldHdvcmtpbmcg KElXQUhOMjAwMik8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkNBTEwgRk9SIFBBUEVS UzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SW50ZXJuYXRpb25hbCBXb3Jrc2hvcCBv biBBZCBIb2MgTmV0d29ya2luZyAoSVdBSE4yMDAyKTxCUj50byBiZSBoZWxkIGluIA0KY29uanVu Y3Rpb24gd2l0aCBJQ1BQLTIwMDI8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkF1Z3Vz dCAxOC0yMSwgMjAwMjxCUj5WYW5jb3V2ZXIsIEJyaXRpc2ggQ29sdW1iaWEsIENhbmFkYSA8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxBIA0KaHJlZj0iaHR0cDovL2NhbGFiLmthaXN0 LmFjLmtyL0NvbmYvSVdBSE4yMDAyLyI+aHR0cDovL2NhbGFiLmthaXN0LmFjLmtyL0NvbmYvSVdB SE4yMDAyLzwvQT48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj5UaGlzIHdvcmtz aG9wIHByb3ZpZGVzIGEgZm9ydW0gZm9yIGVuZ2luZWVycyBhbmQgc2NpZW50aXN0cyBpbiANCmFj YWRlbWlhLCBpbmR1c3RyeSBhbmQgPEJSPmdvdmVybm1lbnQgdG8gcHJlc2VudCB0aGVpciBsYXRl c3QgcmVzZWFyY2ggZmluZGluZ3MgDQppbiBhbnkgYXNwZWN0IG9mIGFkIGhvYyBuZXR3b3JraW5n LiBUb3BpY3MgPEJSPm9mIGludGVyZXN0IGluY2x1ZGUsIGJ1dCBhcmUgbm90IA0KbGltaXRlZCB0 bzo8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOy0gQWQgSG9jIFJvdXRpbmcg DQpQcm90b2NvbHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7LSBBZCBIb2MgTXVsdGljYXN0aW5nPEJSPiZuYnNw Oy0gQWQgSG9jIFRyYW5zcG9ydCBMYXllciANCklzc3VlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8QlI+Jm5ic3A7LSBBZCBIb2MgTmV0d29ya2luZyBvdmVyIA0KQmx1ZXRvb3RoPEJSPiZuYnNw Oy0gUXVhbGl0eSBvZiBTZXJ2aWNlIElzc3VlcyA8QlI+Jm5ic3A7LSBBZCBIb2MgTmV0d29yayAN CkFyY2hpdGVjdHVyZXM8QlI+Jm5ic3A7LSBTZW5zb3IgYW5kIERhdGEgRnVzaW9uIEFkIEhvYyBO ZXR3b3JrcyA8QlI+Jm5ic3A7LSANCk1lZGlhIEFjY2VzcyBUZWNobmlxdWVzIDxCUj4mbmJzcDst IEFwcGxpY2F0aW9ucyBmb3IgQWQgSG9jIE5ldHdvcmtzIDxCUj4mbmJzcDstIA0KUGVlci10by1Q ZWVyIE5ldHdvcmtpbmc8QlI+Jm5ic3A7LSBEaXN0cmlidXRlZCBBbGdvcml0aG1zIGZvciBBZCBI b2MgTmV0d29ya3MgDQo8QlI+Jm5ic3A7LSBNb2JpbGUgSVAgd2l0aCBBZCBIb2M8QlI+Jm5ic3A7 LSBMb3cgUG93ZXIgYW5kIEVuZXJneS1FZmZpY2llbnQgDQpBbGdvcml0aG0gYW5kIFByb3RvY29s IERlc2lnbnM8QlI+Jm5ic3A7LSBTZWN1cml0eSBhbmQgRmF1bHQtVG9sZXJhbmNlIElzc3VlcyAN CmZvciBBZCBIb2MgTmV0d29ya3M8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlBhcGVy IFN1Ym1pc3Npb24gOjxCUj5BdXRob3JzIGFyZSBpbnZpdGVkIHRvIHN1Ym1pdCByZXNlYXJjaCBj b250cmlidXRpb25zIA0KcmVwcmVzZW50aW5nIG9yaWdpbmFsLCBwcmV2aW91c2x5IDxCUj51bnB1 Ymxpc2hlZCB3b3JrLiBTdWJtaXR0ZWQgcGFwZXJzIHdpbGwgYmUgDQpjYXJlZnVsbHkgZXZhbHVh dGVkIGJhc2VkIG9uIG9yaWdpbmFsaXR5LCA8QlI+c2lnbmlmaWNhbmNlLCB0ZWNobmljYWwgc291 bmRuZXNzLCANCmFuZCBjbGFyaXR5IG9mIGV4cG9zaXRpb24uIEFsbCBwYXBlcnMgd2lsbCBiZSBy ZWZlcmVlZCBieSBhdCA8QlI+bGVhc3QgdHdvIA0KbWVtYmVycyBvZiB0aGUgcHJvZ3JhbSBjb21t aXR0ZWUuIEFjY2VwdGVkIHBhcGVycyB3aWxsIGJlIHB1Ymxpc2hlZCBhcyANCnByb2NlZWRpbmdz IG9mIDxCUj5JQ1BQLTIwMDIgd29ya3Nob3BzLiBBbGwgc3VibWl0dGVkIHBhcGVycyBNVVNUIGJl IGZvcm1hdHRlZCANCmFjY29yZGluZyB0byB0aGUgYXV0aG9yIGd1aWRlbGluZXMgPEJSPnByb3Zp ZGVkIGJ5IElDUFAtMjAwMiBhbmQgTVVTVCBOT1QgYmUgDQpsb25nZXIgdGhhbiA2IHBhZ2VzLjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+U3VibWlzc2lvbiBEZWFkbGluZSZuYnNwOyBB cHJpbCAyMCwgMjAwMiAoRXh0ZW5kZWQpPEJSPkF1dGhvciANCk5vdGlmaWNhdGlvbiZuYnNwOyBN YXkgMSwgMjAwMjxCUj5GaW5hbCBNYW51c2NyaXB0IER1ZSZuYnNwOyBKdW5lIDEsIDIwMDI8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkVsZWN0cm9uaWMgU3VibWlzc2lvbiA6PEJSPlBs ZWFzZSBlLW1haWwgb25lIFBERiBvciBQb3N0U2NyaXB0IHZlcnNpb24gb2YgDQp5b3VyIHBhcGVy IHRvIHRoZSBXb3Jrc2hvcCBQcm9ncmFtIENoYWlyIGF0PEJSPjxBIA0KaHJlZj0ibWFpbHRvOmh5 b29uQGNhbGFiLmthaXN0LmFjLmtyIj5oeW9vbkBjYWxhYi5rYWlzdC5hYy5rcjwvQT48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPldvcmtzaG9wIENvLUNoYWlycyA6PEJSPlByb2Zlc3Nv ciBIeXVuc29vIFlvb24gPEJSPkRlcHQuIG9mIEVsZWN0cmljYWwgDQpFbmdpbmVlcmluZyBhbmQg Q29tcHV0ZXIgU2NpZW5jZSA8QlI+S29yZWEgQWR2YW5jZWQgSW5zdGl0dXRlIG9mIFNjaWVuY2Ug YW5kIA0KVGVjaG5vbG9neSZuYnNwOyA8QlI+MzczLTEgS3Vzb25nLWRvbmcsIFl1c29uZy1rdSwg RGFlam9uLCBLb3JlYSA8QlI+RS1tYWlsOiA8QSANCmhyZWY9Im1haWx0bzpoeW9vbkBjYWxhYi5r YWlzdC5hYy5rciI+aHlvb25AY2FsYWIua2Fpc3QuYWMua3I8L0E+IDxCUj5UZWw6IA0KKzgyLTQy LTg2OS0zNTI5Jm5ic3A7IEZheDogKzgyLTQyLTg2OS01NTY5IDwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+UHJvZmVzc29yIEpvb25nLVNvbyBNYSA8QlI+TW9iaWxlIE11bHRpbWVkaWEg UmVzZWFyY2ggQ2VudGVyPEJSPkluZm9ybWF0aW9uIA0KYW5kIENvbW11bmljYXRpb24gVW5pdmVy c2l0eSAoSUNVKTxCUj41OC00LCBId2FhbS1Eb25nIFl1c29uZy1HdSBEYWVqb24gDQpLb3JlYTxC Uj5FLW1haWw6IDxBIGhyZWY9Im1haWx0bzpqc21hQGljdS5hYy5rciI+anNtYUBpY3UuYWMua3I8 L0E+PEJSPlRlbDogDQorODItNDItODY2LTYxMjQ8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPlByb2dyYW0gQ29tbWl0dGVlIE1lbWJlcnMgOjxCUj5DaGFybGVzIEUuIFBlcmtpbnMsIE5v a2lhIFJlc2VhcmNoIENlbnRlciANCjxCUj5EYXZpZCBCLiBKb2huc29uLCBEZXBhcnRtZW50IG9m IENvbXB1dGVyIFNjaWVuY2UgUmljZSANClVuaXZlcnNpdHk8QlI+RWxpemFiZXRoIE0uIFJveWVy LCBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEgYXQgU2FudGEgQmFyYmFyYSANCjxCUj5aeWdtdW50 IEouIEhhYXMsIENvcm5lbGwgVW5pdmVyc2l0eSA8QlI+U3RlZmFubyBCYXNhZ25pLCBVVC1EYWxs YXMmbmJzcDsgDQo8QlI+WW91bmctQmFlIEtvLCBJQk0gVC5KLiBXYXRzb24gUmVzZWFyY2g8QlI+ U29uZ3d1IEx1LCBVQ0xBIDxCUj5TdW5nLUp1IExlZSwgDQpIZXdsZXR0LVBhY2thcmQgTGFicyA8 QlI+QW5kcmV3IENhbXBiZWxsLCBDb2x1bWJpYSBVbml2ZXJzaXR5Jm5ic3A7IDxCUj5SYW0gDQpS YW1hbmF0aGFuLCBCQk4gVGVjaC48QlI+UmFtZXNoIEdvdmluZGFuLCBJQ1NJLCBUaGUgVW5pdmVy c2l0eSBvZiBDYWxpZm9ybmlhIGF0IA0KQmVya2VsZXk8QlI+RGF2aWQgTWFsdHosIEFPTiBOZXR3 b3JrcyZuYnNwOyA8QlI+SmVhbi1QaWVycmUgSHViYXV4LCBTd2lzcyANCkZlZGVyYWwgSW5zdGl0 dXRlIG9mIFRlY2hub2xvZ3kgPEJSPlRpbmctQ2hhbyBIb3UsIE5hdGlvbmFsIENodW5nIENoZW5n IA0KVW5pdmVyc2l0eSwgVGFpd2FuIDxCUj5HdW50ZXIgSG9tbWVsLCBUZWNobmljYWwgVW5pdmVy c2l0eSBvZiBCZXJsaW4sIA0KR2VybWFueTxCUj5DaHJpc3RpYW4gQm9ubmV0LCBJbnN0aXR1dCBF dXJlY29tLCBGcmFuY2UgPEJSPkdlcmFsZCBRLiBNYWd1aXJlLCANClJveWFsIEluc3RpdHV0ZSBv ZiBUZWNobm9sb2d5LCBTd2VkZW48QlI+Vy4gQy4gV29uZywgTmF0aW9uYWwgVW5pdmVyc2l0eSBv ZiANClNpbmdhcG9yZSA8QlI+QnJhaGltIEJlbnNhb3UsIEhvbmcgS29uZyBVbml2ZXJzaXR5IG9m IFNjaWVuY2UgYW5kIA0KVGVjaG5vbG9neTxCUj5QcmF2aW4gQmhhZ3dhdCwgVW5pdmVyc2l0eSBv ZiBNYXJ5bGFuZDxCUj5Bb3lhbWEgVG9tb25vcmksIE9zYWthIA0KVW5pdmVyc2l0eSwgSmFwYW48 QlI+VGFrYWhpcm8gSEFSQSwgT3Nha2EgVW5pdmVyc2l0eSwgSmFwYW4gPEJSPktBV0FJLCBNYWtv dG8sIA0KS3lvdG8gVW5pdmVyc2l0eSwgSmFwYW4mbmJzcDsgPEJSPlN1bmdiYWUgRXVuLCBIYW5u YW0gVW5pdmVyc2l0eSwgDQpLb3JlYTxCUj5Ja2pvb24gWWVvbSwgS0FJU1QsIEtvcmVhPEJSPkNo b25na3dvbiBLaW0sIFNlb3VsIE5hdGlvbmFsIFVuaXZlcnNpdHksIA0KS29yZWE8QlI+Sm9vbndv biBMZWUsIEtBSVNULCBLb3JlYTxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0299_01C1DA5D.C70A28B0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 2 02:38:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08963 for ; Tue, 2 Apr 2002 02:38:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA23462 for manet-archive@odin.ietf.org; Tue, 2 Apr 2002 02:38:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20433; Tue, 2 Apr 2002 01:48:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20400 for ; Tue, 2 Apr 2002 01:48:10 -0500 (EST) Received: from camars.kaist.ac.kr (camars.kaist.ac.kr [143.248.137.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29892 for ; Tue, 2 Apr 2002 01:48:07 -0500 (EST) Received: from capictor (capictor.kaist.ac.kr [143.248.150.112]) by camars.kaist.ac.kr (8.9.3/8.9.3) with SMTP id PAA07818 for ; Tue, 2 Apr 2002 15:37:00 +0900 (KST) Message-ID: <029c01c1da12$5751f520$7096f88f@capictor> From: "Seung-hak Lee" To: Date: Tue, 2 Apr 2002 15:48:04 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0299_01C1DA5D.C70A28B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] CFP: Extended Deadline for IWAHN2002 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0299_01C1DA5D.C70A28B0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQpNeSBhcG9sb2dpZXMgaWYgeW91IHJlY2VpdmUgdGhpcyBDRlAgZHVwbGljYXRlZC4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpOb3RlOiAgVGhlIGRlYWRsaW5lIGhhcyBiZWVuIGV4dGVuZGVkIHRvIEFwcmlsIDIwLg0K DQogU2luY2Ugc2V2ZXJhbCBpbnRlbmRpbmcgc3VibWl0dGVycyBoYXZlIGFza2VkIGZvciBleHRy YSB0aW1lLCANCg0KIGl0IHNlZW1zIGZhaXIgdG8gb2ZmZXIgaXQgZ2VuZXJhbGx5LiANCg0KIFBs ZWFzZSB0YWtlIGFkdmFudGFnZSBvZiB0aGlzIGV4dGVuc2lvbiB0byBzdWJtaXQgeW91ciBwYXBl ci4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KQ0ZQIGZvciBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIEFkIEhv YyBOZXR3b3JraW5nIChJV0FITjIwMDIpDQoNCkNBTEwgRk9SIFBBUEVSUw0KDQpJbnRlcm5hdGlv bmFsIFdvcmtzaG9wIG9uIEFkIEhvYyBOZXR3b3JraW5nIChJV0FITjIwMDIpDQp0byBiZSBoZWxk IGluIGNvbmp1bmN0aW9uIHdpdGggSUNQUC0yMDAyDQoNCkF1Z3VzdCAxOC0yMSwgMjAwMg0KVmFu Y291dmVyLCBCcml0aXNoIENvbHVtYmlhLCBDYW5hZGEgDQoNCmh0dHA6Ly9jYWxhYi5rYWlzdC5h Yy5rci9Db25mL0lXQUhOMjAwMi8NCg0KDQpUaGlzIHdvcmtzaG9wIHByb3ZpZGVzIGEgZm9ydW0g Zm9yIGVuZ2luZWVycyBhbmQgc2NpZW50aXN0cyBpbiBhY2FkZW1pYSwgaW5kdXN0cnkgYW5kIA0K Z292ZXJubWVudCB0byBwcmVzZW50IHRoZWlyIGxhdGVzdCByZXNlYXJjaCBmaW5kaW5ncyBpbiBh bnkgYXNwZWN0IG9mIGFkIGhvYyBuZXR3b3JraW5nLiBUb3BpY3MgDQpvZiBpbnRlcmVzdCBpbmNs dWRlLCBidXQgYXJlIG5vdCBsaW1pdGVkIHRvOg0KDQogLSBBZCBIb2MgUm91dGluZyBQcm90b2Nv bHMgICAgICAgICAgIA0KIC0gQWQgSG9jIE11bHRpY2FzdGluZw0KIC0gQWQgSG9jIFRyYW5zcG9y dCBMYXllciBJc3N1ZXMgICAgIA0KIC0gQWQgSG9jIE5ldHdvcmtpbmcgb3ZlciBCbHVldG9vdGgN CiAtIFF1YWxpdHkgb2YgU2VydmljZSBJc3N1ZXMgDQogLSBBZCBIb2MgTmV0d29yayBBcmNoaXRl Y3R1cmVzDQogLSBTZW5zb3IgYW5kIERhdGEgRnVzaW9uIEFkIEhvYyBOZXR3b3JrcyANCiAtIE1l ZGlhIEFjY2VzcyBUZWNobmlxdWVzIA0KIC0gQXBwbGljYXRpb25zIGZvciBBZCBIb2MgTmV0d29y a3MgDQogLSBQZWVyLXRvLVBlZXIgTmV0d29ya2luZw0KIC0gRGlzdHJpYnV0ZWQgQWxnb3JpdGht cyBmb3IgQWQgSG9jIE5ldHdvcmtzIA0KIC0gTW9iaWxlIElQIHdpdGggQWQgSG9jDQogLSBMb3cg UG93ZXIgYW5kIEVuZXJneS1FZmZpY2llbnQgQWxnb3JpdGhtIGFuZCBQcm90b2NvbCBEZXNpZ25z DQogLSBTZWN1cml0eSBhbmQgRmF1bHQtVG9sZXJhbmNlIElzc3VlcyBmb3IgQWQgSG9jIE5ldHdv cmtzDQoNClBhcGVyIFN1Ym1pc3Npb24gOg0KQXV0aG9ycyBhcmUgaW52aXRlZCB0byBzdWJtaXQg cmVzZWFyY2ggY29udHJpYnV0aW9ucyByZXByZXNlbnRpbmcgb3JpZ2luYWwsIHByZXZpb3VzbHkg DQp1bnB1Ymxpc2hlZCB3b3JrLiBTdWJtaXR0ZWQgcGFwZXJzIHdpbGwgYmUgY2FyZWZ1bGx5IGV2 YWx1YXRlZCBiYXNlZCBvbiBvcmlnaW5hbGl0eSwgDQpzaWduaWZpY2FuY2UsIHRlY2huaWNhbCBz b3VuZG5lc3MsIGFuZCBjbGFyaXR5IG9mIGV4cG9zaXRpb24uIEFsbCBwYXBlcnMgd2lsbCBiZSBy ZWZlcmVlZCBieSBhdCANCmxlYXN0IHR3byBtZW1iZXJzIG9mIHRoZSBwcm9ncmFtIGNvbW1pdHRl ZS4gQWNjZXB0ZWQgcGFwZXJzIHdpbGwgYmUgcHVibGlzaGVkIGFzIHByb2NlZWRpbmdzIG9mIA0K SUNQUC0yMDAyIHdvcmtzaG9wcy4gQWxsIHN1Ym1pdHRlZCBwYXBlcnMgTVVTVCBiZSBmb3JtYXR0 ZWQgYWNjb3JkaW5nIHRvIHRoZSBhdXRob3IgZ3VpZGVsaW5lcyANCnByb3ZpZGVkIGJ5IElDUFAt MjAwMiBhbmQgTVVTVCBOT1QgYmUgbG9uZ2VyIHRoYW4gNiBwYWdlcy4NCg0KU3VibWlzc2lvbiBE ZWFkbGluZSAgQXByaWwgMjAsIDIwMDIgKEV4dGVuZGVkKQ0KQXV0aG9yIE5vdGlmaWNhdGlvbiAg TWF5IDEsIDIwMDINCkZpbmFsIE1hbnVzY3JpcHQgRHVlICBKdW5lIDEsIDIwMDINCg0KRWxlY3Ry b25pYyBTdWJtaXNzaW9uIDoNClBsZWFzZSBlLW1haWwgb25lIFBERiBvciBQb3N0U2NyaXB0IHZl cnNpb24gb2YgeW91ciBwYXBlciB0byB0aGUgV29ya3Nob3AgUHJvZ3JhbSBDaGFpciBhdA0KaHlv b25AY2FsYWIua2Fpc3QuYWMua3INCg0KV29ya3Nob3AgQ28tQ2hhaXJzIDoNClByb2Zlc3NvciBI eXVuc29vIFlvb24gDQpEZXB0LiBvZiBFbGVjdHJpY2FsIEVuZ2luZWVyaW5nIGFuZCBDb21wdXRl ciBTY2llbmNlIA0KS29yZWEgQWR2YW5jZWQgSW5zdGl0dXRlIG9mIFNjaWVuY2UgYW5kIFRlY2hu b2xvZ3kgIA0KMzczLTEgS3Vzb25nLWRvbmcsIFl1c29uZy1rdSwgRGFlam9uLCBLb3JlYSANCkUt bWFpbDogaHlvb25AY2FsYWIua2Fpc3QuYWMua3IgDQpUZWw6ICs4Mi00Mi04NjktMzUyOSAgRmF4 OiArODItNDItODY5LTU1NjkgDQoNClByb2Zlc3NvciBKb29uZy1Tb28gTWEgDQpNb2JpbGUgTXVs dGltZWRpYSBSZXNlYXJjaCBDZW50ZXINCkluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9uIFVu aXZlcnNpdHkgKElDVSkNCjU4LTQsIEh3YWFtLURvbmcgWXVzb25nLUd1IERhZWpvbiBLb3JlYQ0K RS1tYWlsOiBqc21hQGljdS5hYy5rcg0KVGVsOiArODItNDItODY2LTYxMjQNCg0KUHJvZ3JhbSBD b21taXR0ZWUgTWVtYmVycyA6DQpDaGFybGVzIEUuIFBlcmtpbnMsIE5va2lhIFJlc2VhcmNoIENl bnRlciANCkRhdmlkIEIuIEpvaG5zb24sIERlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZSBS aWNlIFVuaXZlcnNpdHkNCkVsaXphYmV0aCBNLiBSb3llciwgVW5pdmVyc2l0eSBvZiBDYWxpZm9y bmlhIGF0IFNhbnRhIEJhcmJhcmEgDQpaeWdtdW50IEouIEhhYXMsIENvcm5lbGwgVW5pdmVyc2l0 eSANClN0ZWZhbm8gQmFzYWduaSwgVVQtRGFsbGFzICANCllvdW5nLUJhZSBLbywgSUJNIFQuSi4g V2F0c29uIFJlc2VhcmNoDQpTb25nd3UgTHUsIFVDTEEgDQpTdW5nLUp1IExlZSwgSGV3bGV0dC1Q YWNrYXJkIExhYnMgDQpBbmRyZXcgQ2FtcGJlbGwsIENvbHVtYmlhIFVuaXZlcnNpdHkgIA0KUmFt IFJhbWFuYXRoYW4sIEJCTiBUZWNoLg0KUmFtZXNoIEdvdmluZGFuLCBJQ1NJLCBUaGUgVW5pdmVy c2l0eSBvZiBDYWxpZm9ybmlhIGF0IEJlcmtlbGV5DQpEYXZpZCBNYWx0eiwgQU9OIE5ldHdvcmtz ICANCkplYW4tUGllcnJlIEh1YmF1eCwgU3dpc3MgRmVkZXJhbCBJbnN0aXR1dGUgb2YgVGVjaG5v bG9neSANClRpbmctQ2hhbyBIb3UsIE5hdGlvbmFsIENodW5nIENoZW5nIFVuaXZlcnNpdHksIFRh aXdhbiANCkd1bnRlciBIb21tZWwsIFRlY2huaWNhbCBVbml2ZXJzaXR5IG9mIEJlcmxpbiwgR2Vy bWFueQ0KQ2hyaXN0aWFuIEJvbm5ldCwgSW5zdGl0dXQgRXVyZWNvbSwgRnJhbmNlIA0KR2VyYWxk IFEuIE1hZ3VpcmUsIFJveWFsIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5LCBTd2VkZW4NClcuIEMu IFdvbmcsIE5hdGlvbmFsIFVuaXZlcnNpdHkgb2YgU2luZ2Fwb3JlIA0KQnJhaGltIEJlbnNhb3Us IEhvbmcgS29uZyBVbml2ZXJzaXR5IG9mIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3kNClByYXZpbiBC aGFnd2F0LCBVbml2ZXJzaXR5IG9mIE1hcnlsYW5kDQpBb3lhbWEgVG9tb25vcmksIE9zYWthIFVu aXZlcnNpdHksIEphcGFuDQpUYWthaGlybyBIQVJBLCBPc2FrYSBVbml2ZXJzaXR5LCBKYXBhbiAN CktBV0FJLCBNYWtvdG8sIEt5b3RvIFVuaXZlcnNpdHksIEphcGFuICANClN1bmdiYWUgRXVuLCBI YW5uYW0gVW5pdmVyc2l0eSwgS29yZWENCklram9vbiBZZW9tLCBLQUlTVCwgS29yZWENCkNob25n a3dvbiBLaW0sIFNlb3VsIE5hdGlvbmFsIFVuaXZlcnNpdHksIEtvcmVhDQpKb29ud29uIExlZSwg S0FJU1QsIEtvcmVhDQoNCg0K ------=_NextPart_000_0299_01C1DA5D.C70A28B0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTMuMTEwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPk15IGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2 ZSB0aGlzIENGUCANCmR1cGxpY2F0ZWQuPEJSPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Ob3RlOiZuYnNwOyBUaGUgZGVhZGxpbmUgaGFz IGJlZW4gZXh0ZW5kZWQgdG8gQXByaWwgDQoyMC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7U2luY2Ugc2V2ZXJhbCBpbnRlbmRpbmcgc3Vi bWl0dGVycyBoYXZlIGFza2VkIGZvciBleHRyYSANCnRpbWUsIDwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDtpdCBzZWVtcyBmYWlyIHRvIG9m ZmVyIGl0IGdlbmVyYWxseS4gPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPiZuYnNwO1BsZWFzZSB0YWtlIGFkdmFudGFnZSBvZiB0aGlzIGV4dGVuc2lv biB0byBzdWJtaXQgeW91ciANCnBhcGVyLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ PEZPTlQgc2l6ZT0yPg0KPERJVj48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5DRlAgZm9yIEludGVybmF0aW9uYWwgV29ya3Nob3Agb24gQWQgSG9jIE5ldHdvcmtpbmcg KElXQUhOMjAwMik8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkNBTEwgRk9SIFBBUEVS UzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SW50ZXJuYXRpb25hbCBXb3Jrc2hvcCBv biBBZCBIb2MgTmV0d29ya2luZyAoSVdBSE4yMDAyKTxCUj50byBiZSBoZWxkIGluIA0KY29uanVu Y3Rpb24gd2l0aCBJQ1BQLTIwMDI8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkF1Z3Vz dCAxOC0yMSwgMjAwMjxCUj5WYW5jb3V2ZXIsIEJyaXRpc2ggQ29sdW1iaWEsIENhbmFkYSA8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxBIA0KaHJlZj0iaHR0cDovL2NhbGFiLmthaXN0 LmFjLmtyL0NvbmYvSVdBSE4yMDAyLyI+aHR0cDovL2NhbGFiLmthaXN0LmFjLmtyL0NvbmYvSVdB SE4yMDAyLzwvQT48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxCUj5UaGlzIHdvcmtz aG9wIHByb3ZpZGVzIGEgZm9ydW0gZm9yIGVuZ2luZWVycyBhbmQgc2NpZW50aXN0cyBpbiANCmFj YWRlbWlhLCBpbmR1c3RyeSBhbmQgPEJSPmdvdmVybm1lbnQgdG8gcHJlc2VudCB0aGVpciBsYXRl c3QgcmVzZWFyY2ggZmluZGluZ3MgDQppbiBhbnkgYXNwZWN0IG9mIGFkIGhvYyBuZXR3b3JraW5n LiBUb3BpY3MgPEJSPm9mIGludGVyZXN0IGluY2x1ZGUsIGJ1dCBhcmUgbm90IA0KbGltaXRlZCB0 bzo8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOy0gQWQgSG9jIFJvdXRpbmcg DQpQcm90b2NvbHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQo8QlI+Jm5ic3A7LSBBZCBIb2MgTXVsdGljYXN0aW5nPEJSPiZuYnNw Oy0gQWQgSG9jIFRyYW5zcG9ydCBMYXllciANCklzc3VlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8QlI+Jm5ic3A7LSBBZCBIb2MgTmV0d29ya2luZyBvdmVyIA0KQmx1ZXRvb3RoPEJSPiZuYnNw Oy0gUXVhbGl0eSBvZiBTZXJ2aWNlIElzc3VlcyA8QlI+Jm5ic3A7LSBBZCBIb2MgTmV0d29yayAN CkFyY2hpdGVjdHVyZXM8QlI+Jm5ic3A7LSBTZW5zb3IgYW5kIERhdGEgRnVzaW9uIEFkIEhvYyBO ZXR3b3JrcyA8QlI+Jm5ic3A7LSANCk1lZGlhIEFjY2VzcyBUZWNobmlxdWVzIDxCUj4mbmJzcDst IEFwcGxpY2F0aW9ucyBmb3IgQWQgSG9jIE5ldHdvcmtzIDxCUj4mbmJzcDstIA0KUGVlci10by1Q ZWVyIE5ldHdvcmtpbmc8QlI+Jm5ic3A7LSBEaXN0cmlidXRlZCBBbGdvcml0aG1zIGZvciBBZCBI b2MgTmV0d29ya3MgDQo8QlI+Jm5ic3A7LSBNb2JpbGUgSVAgd2l0aCBBZCBIb2M8QlI+Jm5ic3A7 LSBMb3cgUG93ZXIgYW5kIEVuZXJneS1FZmZpY2llbnQgDQpBbGdvcml0aG0gYW5kIFByb3RvY29s IERlc2lnbnM8QlI+Jm5ic3A7LSBTZWN1cml0eSBhbmQgRmF1bHQtVG9sZXJhbmNlIElzc3VlcyAN CmZvciBBZCBIb2MgTmV0d29ya3M8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlBhcGVy IFN1Ym1pc3Npb24gOjxCUj5BdXRob3JzIGFyZSBpbnZpdGVkIHRvIHN1Ym1pdCByZXNlYXJjaCBj b250cmlidXRpb25zIA0KcmVwcmVzZW50aW5nIG9yaWdpbmFsLCBwcmV2aW91c2x5IDxCUj51bnB1 Ymxpc2hlZCB3b3JrLiBTdWJtaXR0ZWQgcGFwZXJzIHdpbGwgYmUgDQpjYXJlZnVsbHkgZXZhbHVh dGVkIGJhc2VkIG9uIG9yaWdpbmFsaXR5LCA8QlI+c2lnbmlmaWNhbmNlLCB0ZWNobmljYWwgc291 bmRuZXNzLCANCmFuZCBjbGFyaXR5IG9mIGV4cG9zaXRpb24uIEFsbCBwYXBlcnMgd2lsbCBiZSBy ZWZlcmVlZCBieSBhdCA8QlI+bGVhc3QgdHdvIA0KbWVtYmVycyBvZiB0aGUgcHJvZ3JhbSBjb21t aXR0ZWUuIEFjY2VwdGVkIHBhcGVycyB3aWxsIGJlIHB1Ymxpc2hlZCBhcyANCnByb2NlZWRpbmdz IG9mIDxCUj5JQ1BQLTIwMDIgd29ya3Nob3BzLiBBbGwgc3VibWl0dGVkIHBhcGVycyBNVVNUIGJl IGZvcm1hdHRlZCANCmFjY29yZGluZyB0byB0aGUgYXV0aG9yIGd1aWRlbGluZXMgPEJSPnByb3Zp ZGVkIGJ5IElDUFAtMjAwMiBhbmQgTVVTVCBOT1QgYmUgDQpsb25nZXIgdGhhbiA2IHBhZ2VzLjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+U3VibWlzc2lvbiBEZWFkbGluZSZuYnNwOyBB cHJpbCAyMCwgMjAwMiAoRXh0ZW5kZWQpPEJSPkF1dGhvciANCk5vdGlmaWNhdGlvbiZuYnNwOyBN YXkgMSwgMjAwMjxCUj5GaW5hbCBNYW51c2NyaXB0IER1ZSZuYnNwOyBKdW5lIDEsIDIwMDI8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkVsZWN0cm9uaWMgU3VibWlzc2lvbiA6PEJSPlBs ZWFzZSBlLW1haWwgb25lIFBERiBvciBQb3N0U2NyaXB0IHZlcnNpb24gb2YgDQp5b3VyIHBhcGVy IHRvIHRoZSBXb3Jrc2hvcCBQcm9ncmFtIENoYWlyIGF0PEJSPjxBIA0KaHJlZj0ibWFpbHRvOmh5 b29uQGNhbGFiLmthaXN0LmFjLmtyIj5oeW9vbkBjYWxhYi5rYWlzdC5hYy5rcjwvQT48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPldvcmtzaG9wIENvLUNoYWlycyA6PEJSPlByb2Zlc3Nv ciBIeXVuc29vIFlvb24gPEJSPkRlcHQuIG9mIEVsZWN0cmljYWwgDQpFbmdpbmVlcmluZyBhbmQg Q29tcHV0ZXIgU2NpZW5jZSA8QlI+S29yZWEgQWR2YW5jZWQgSW5zdGl0dXRlIG9mIFNjaWVuY2Ug YW5kIA0KVGVjaG5vbG9neSZuYnNwOyA8QlI+MzczLTEgS3Vzb25nLWRvbmcsIFl1c29uZy1rdSwg RGFlam9uLCBLb3JlYSA8QlI+RS1tYWlsOiA8QSANCmhyZWY9Im1haWx0bzpoeW9vbkBjYWxhYi5r YWlzdC5hYy5rciI+aHlvb25AY2FsYWIua2Fpc3QuYWMua3I8L0E+IDxCUj5UZWw6IA0KKzgyLTQy LTg2OS0zNTI5Jm5ic3A7IEZheDogKzgyLTQyLTg2OS01NTY5IDwvRElWPg0KPERJVj4mbmJzcDs8 L0RJVj4NCjxESVY+UHJvZmVzc29yIEpvb25nLVNvbyBNYSA8QlI+TW9iaWxlIE11bHRpbWVkaWEg UmVzZWFyY2ggQ2VudGVyPEJSPkluZm9ybWF0aW9uIA0KYW5kIENvbW11bmljYXRpb24gVW5pdmVy c2l0eSAoSUNVKTxCUj41OC00LCBId2FhbS1Eb25nIFl1c29uZy1HdSBEYWVqb24gDQpLb3JlYTxC Uj5FLW1haWw6IDxBIGhyZWY9Im1haWx0bzpqc21hQGljdS5hYy5rciI+anNtYUBpY3UuYWMua3I8 L0E+PEJSPlRlbDogDQorODItNDItODY2LTYxMjQ8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPlByb2dyYW0gQ29tbWl0dGVlIE1lbWJlcnMgOjxCUj5DaGFybGVzIEUuIFBlcmtpbnMsIE5v a2lhIFJlc2VhcmNoIENlbnRlciANCjxCUj5EYXZpZCBCLiBKb2huc29uLCBEZXBhcnRtZW50IG9m IENvbXB1dGVyIFNjaWVuY2UgUmljZSANClVuaXZlcnNpdHk8QlI+RWxpemFiZXRoIE0uIFJveWVy LCBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEgYXQgU2FudGEgQmFyYmFyYSANCjxCUj5aeWdtdW50 IEouIEhhYXMsIENvcm5lbGwgVW5pdmVyc2l0eSA8QlI+U3RlZmFubyBCYXNhZ25pLCBVVC1EYWxs YXMmbmJzcDsgDQo8QlI+WW91bmctQmFlIEtvLCBJQk0gVC5KLiBXYXRzb24gUmVzZWFyY2g8QlI+ U29uZ3d1IEx1LCBVQ0xBIDxCUj5TdW5nLUp1IExlZSwgDQpIZXdsZXR0LVBhY2thcmQgTGFicyA8 QlI+QW5kcmV3IENhbXBiZWxsLCBDb2x1bWJpYSBVbml2ZXJzaXR5Jm5ic3A7IDxCUj5SYW0gDQpS YW1hbmF0aGFuLCBCQk4gVGVjaC48QlI+UmFtZXNoIEdvdmluZGFuLCBJQ1NJLCBUaGUgVW5pdmVy c2l0eSBvZiBDYWxpZm9ybmlhIGF0IA0KQmVya2VsZXk8QlI+RGF2aWQgTWFsdHosIEFPTiBOZXR3 b3JrcyZuYnNwOyA8QlI+SmVhbi1QaWVycmUgSHViYXV4LCBTd2lzcyANCkZlZGVyYWwgSW5zdGl0 dXRlIG9mIFRlY2hub2xvZ3kgPEJSPlRpbmctQ2hhbyBIb3UsIE5hdGlvbmFsIENodW5nIENoZW5n IA0KVW5pdmVyc2l0eSwgVGFpd2FuIDxCUj5HdW50ZXIgSG9tbWVsLCBUZWNobmljYWwgVW5pdmVy c2l0eSBvZiBCZXJsaW4sIA0KR2VybWFueTxCUj5DaHJpc3RpYW4gQm9ubmV0LCBJbnN0aXR1dCBF dXJlY29tLCBGcmFuY2UgPEJSPkdlcmFsZCBRLiBNYWd1aXJlLCANClJveWFsIEluc3RpdHV0ZSBv ZiBUZWNobm9sb2d5LCBTd2VkZW48QlI+Vy4gQy4gV29uZywgTmF0aW9uYWwgVW5pdmVyc2l0eSBv ZiANClNpbmdhcG9yZSA8QlI+QnJhaGltIEJlbnNhb3UsIEhvbmcgS29uZyBVbml2ZXJzaXR5IG9m IFNjaWVuY2UgYW5kIA0KVGVjaG5vbG9neTxCUj5QcmF2aW4gQmhhZ3dhdCwgVW5pdmVyc2l0eSBv ZiBNYXJ5bGFuZDxCUj5Bb3lhbWEgVG9tb25vcmksIE9zYWthIA0KVW5pdmVyc2l0eSwgSmFwYW48 QlI+VGFrYWhpcm8gSEFSQSwgT3Nha2EgVW5pdmVyc2l0eSwgSmFwYW4gPEJSPktBV0FJLCBNYWtv dG8sIA0KS3lvdG8gVW5pdmVyc2l0eSwgSmFwYW4mbmJzcDsgPEJSPlN1bmdiYWUgRXVuLCBIYW5u YW0gVW5pdmVyc2l0eSwgDQpLb3JlYTxCUj5Ja2pvb24gWWVvbSwgS0FJU1QsIEtvcmVhPEJSPkNo b25na3dvbiBLaW0sIFNlb3VsIE5hdGlvbmFsIFVuaXZlcnNpdHksIA0KS29yZWE8QlI+Sm9vbndv biBMZWUsIEtBSVNULCBLb3JlYTxCUj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0299_01C1DA5D.C70A28B0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 2 06:15:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11981 for ; Tue, 2 Apr 2002 06:15:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02481; Tue, 2 Apr 2002 05:52:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02375 for ; Tue, 2 Apr 2002 05:52:14 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11671 for ; Tue, 2 Apr 2002 05:52:10 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g32ApdJ13240; Tue, 2 Apr 2002 13:51:39 +0300 Date: Tue, 2 Apr 2002 13:51:39 +0300 (EEST) From: Pekka Savola To: Yih-Chun Hu cc: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Sat, 23 Feb 2002, Pekka Savola wrote: > I'll try to give more concrete feedback within some weeks but I'm not sure > if that's going to help any as the basic assumptions seem to vary quite a > bit. Hello, I promised I'd come back with more comments. Some are just my thoughts I tried to scribble down when reading the draft. Hope they help.. - I'm a bit unsure what happens if a packet which has a DSR header but also has piggybacked data is in send/maintenance queue. Is this possible? These could in some cases perhaps lead to data being delivered more than once to the destination. - I didn't get a good picture which DSR options can be seen in the same DSR header and which not. Also, as sections in chapter 5 list what IP header fields would look like when there are multiple options in a packet, the multi-option combinations seem to be less covered than their full counterparts. Some comments based on the text. 1. Introduction [...] Each data packet sent then carries in its header the complete, ordered list of nodes through which the packet will pass, allowing packet routing to be trivially loop-free and avoiding the need for up-to-date routing information in the intermediate nodes through which the packet is forwarded. [...] ==> the need for up-to-date information may not necessarily be a bad thing. Now the sources are in charge of that. Moreover, the sources are also in charge of the whole network, as their source routes will be cached and used for other communications. This is quite effective, but can be very dangerous in case of e.g. implementation bugs, unforeseen problems (e.g. a source getting out of sync, and "competing with the cache" with the rest of manet nodes) and such: one node can pretty much wreck the whole routing fabric without even trying hard. [...] For example, DSR does not use any periodic routing advertisement, link status sensing, or neighbor detection packets, and does not rely on these functions from any underlying protocols in the network. This entirely on-demand behavior and lack of periodic activity allows the number of overhead packets caused by DSR to scale all the way down to zero, [...] ==> I see DSR header functions rather equivalent to link status sensing (maintenance procedures, Send Queue, etc.) and others above. In response to a single Route Discovery (as well as through routing information from other packets overheard), a node may learn and cache multiple routes to any destination. ==> just a trivial comment: cache management strategies will be quite critical. 3.1. Basic DSR Route Discovery Node E could instead simply reverse the sequence of hops in the route record that it is trying to send in the Route Reply, and use this as the source route on the packet carrying the Route Reply itself. For MAC protocols such as IEEE 802.11 that require a bidirectional frame exchange as part of the MAC protocol [11], the discovered source route MUST be reversed in this way to return the Route Reply since it tests the discovered route to ensure it is bidirectional before the Route Discovery initiator begins using the route; this route reversal also avoids the overhead of a possible second Route Discovery. ==> This (and various other places in the text, e.g. Appendix A) assumes that the link-layer technology, at least from the point of view of directionality, must be the same all over the manet, or at least all manet nodes know the directionality of each device. This seems a rather big aasumption. When initiating a Route Discovery, the sending node saves a copy of the original packet (that triggered the Discovery) in a local buffer called the "Send Buffer". ==> might this create extra delays in the case of Route Discoveries failing too (e.g. link failure, no manet nodes/AP's temporarily in range, ...) ? 4.1. Route Cache - In DSR, the route returned in each Route Reply that is received by the initiator of a Route Discovery (or that is learned from the header of overhead packets, as described in Section 6.1.4) represents a complete path (a sequence of links) leading to the destination node. By caching each of these paths separately, a "path cache" organization for the Route Cache can be formed. A path cache is very simple to implement and easily guarantees that all routes are loop-free, since each individual route from a Route Reply or Route Request or used in a packet is loop-free. ==> as pointed above, this puts quite much trust on the sender's cache data/cache being up-to-date. A normal security procedure would be to verify received loop-freeness, but here normal security procedures might not apply... 5. DSR Header Format To add a DSR header to a packet, the DSR header is inserted following the packet's IP header, before any following header such as a traditional (e.g., TCP or UDP) transport layer header. Specifically, the Protocol field in the IP header is used to indicate that a DSR header follows the IP header, and the Next Header field in the DSR header is used to indicate the type of protocol header (such as a transport layer header) following the DSR header. ==> this has strong implications if packet filtering is perfomed. First, almost all packets will be discarded unless the packet filter/firewall supports DSR header processing and has some extra semantics on how to proceed past the first, DSR header. This is similar to issues associated with IPv6 packet filtering.. 6.2.2. Processing a Received Route Request Option - [...] If the node does not receive a Reply within some reasonable amount of time, MUST silently discard the Route Request packet. ==> perhaps this should be defined more precisely? o If the node does not return a cached Route Reply, then this node SHOULD link-layer re-broadcast this copy of the packet, with a short jitter delay before the broadcast is sent. The jitter period SHOULD be chosen as a random period, uniformly distributed between 0 and BroadcastJitter. ==> is it required that all possible media should support link-layer broadcasts? 6.3.6. Salvaging a Packet When an intermediate node forwarding a packet detects through Route Maintenance that the next-hop link along the route for that packet is broken (Section 6.3), if the node has another route to the packet's IP Destination Address in its Route Cache, the node SHOULD "salvage" the packet rather than discarding it. ==> s/discarding/discard/ ? 11. Security Considerations ==> nodes feeding wrong (out-of-date) information, acting by their best knowledge? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 2 06:15:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11990 for ; Tue, 2 Apr 2002 06:15:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA03990 for manet-archive@odin.ietf.org; Tue, 2 Apr 2002 06:15:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02481; Tue, 2 Apr 2002 05:52:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02375 for ; Tue, 2 Apr 2002 05:52:14 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11671 for ; Tue, 2 Apr 2002 05:52:10 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g32ApdJ13240; Tue, 2 Apr 2002 13:51:39 +0300 Date: Tue, 2 Apr 2002 13:51:39 +0300 (EEST) From: Pekka Savola To: Yih-Chun Hu cc: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Sat, 23 Feb 2002, Pekka Savola wrote: > I'll try to give more concrete feedback within some weeks but I'm not sure > if that's going to help any as the basic assumptions seem to vary quite a > bit. Hello, I promised I'd come back with more comments. Some are just my thoughts I tried to scribble down when reading the draft. Hope they help.. - I'm a bit unsure what happens if a packet which has a DSR header but also has piggybacked data is in send/maintenance queue. Is this possible? These could in some cases perhaps lead to data being delivered more than once to the destination. - I didn't get a good picture which DSR options can be seen in the same DSR header and which not. Also, as sections in chapter 5 list what IP header fields would look like when there are multiple options in a packet, the multi-option combinations seem to be less covered than their full counterparts. Some comments based on the text. 1. Introduction [...] Each data packet sent then carries in its header the complete, ordered list of nodes through which the packet will pass, allowing packet routing to be trivially loop-free and avoiding the need for up-to-date routing information in the intermediate nodes through which the packet is forwarded. [...] ==> the need for up-to-date information may not necessarily be a bad thing. Now the sources are in charge of that. Moreover, the sources are also in charge of the whole network, as their source routes will be cached and used for other communications. This is quite effective, but can be very dangerous in case of e.g. implementation bugs, unforeseen problems (e.g. a source getting out of sync, and "competing with the cache" with the rest of manet nodes) and such: one node can pretty much wreck the whole routing fabric without even trying hard. [...] For example, DSR does not use any periodic routing advertisement, link status sensing, or neighbor detection packets, and does not rely on these functions from any underlying protocols in the network. This entirely on-demand behavior and lack of periodic activity allows the number of overhead packets caused by DSR to scale all the way down to zero, [...] ==> I see DSR header functions rather equivalent to link status sensing (maintenance procedures, Send Queue, etc.) and others above. In response to a single Route Discovery (as well as through routing information from other packets overheard), a node may learn and cache multiple routes to any destination. ==> just a trivial comment: cache management strategies will be quite critical. 3.1. Basic DSR Route Discovery Node E could instead simply reverse the sequence of hops in the route record that it is trying to send in the Route Reply, and use this as the source route on the packet carrying the Route Reply itself. For MAC protocols such as IEEE 802.11 that require a bidirectional frame exchange as part of the MAC protocol [11], the discovered source route MUST be reversed in this way to return the Route Reply since it tests the discovered route to ensure it is bidirectional before the Route Discovery initiator begins using the route; this route reversal also avoids the overhead of a possible second Route Discovery. ==> This (and various other places in the text, e.g. Appendix A) assumes that the link-layer technology, at least from the point of view of directionality, must be the same all over the manet, or at least all manet nodes know the directionality of each device. This seems a rather big aasumption. When initiating a Route Discovery, the sending node saves a copy of the original packet (that triggered the Discovery) in a local buffer called the "Send Buffer". ==> might this create extra delays in the case of Route Discoveries failing too (e.g. link failure, no manet nodes/AP's temporarily in range, ...) ? 4.1. Route Cache - In DSR, the route returned in each Route Reply that is received by the initiator of a Route Discovery (or that is learned from the header of overhead packets, as described in Section 6.1.4) represents a complete path (a sequence of links) leading to the destination node. By caching each of these paths separately, a "path cache" organization for the Route Cache can be formed. A path cache is very simple to implement and easily guarantees that all routes are loop-free, since each individual route from a Route Reply or Route Request or used in a packet is loop-free. ==> as pointed above, this puts quite much trust on the sender's cache data/cache being up-to-date. A normal security procedure would be to verify received loop-freeness, but here normal security procedures might not apply... 5. DSR Header Format To add a DSR header to a packet, the DSR header is inserted following the packet's IP header, before any following header such as a traditional (e.g., TCP or UDP) transport layer header. Specifically, the Protocol field in the IP header is used to indicate that a DSR header follows the IP header, and the Next Header field in the DSR header is used to indicate the type of protocol header (such as a transport layer header) following the DSR header. ==> this has strong implications if packet filtering is perfomed. First, almost all packets will be discarded unless the packet filter/firewall supports DSR header processing and has some extra semantics on how to proceed past the first, DSR header. This is similar to issues associated with IPv6 packet filtering.. 6.2.2. Processing a Received Route Request Option - [...] If the node does not receive a Reply within some reasonable amount of time, MUST silently discard the Route Request packet. ==> perhaps this should be defined more precisely? o If the node does not return a cached Route Reply, then this node SHOULD link-layer re-broadcast this copy of the packet, with a short jitter delay before the broadcast is sent. The jitter period SHOULD be chosen as a random period, uniformly distributed between 0 and BroadcastJitter. ==> is it required that all possible media should support link-layer broadcasts? 6.3.6. Salvaging a Packet When an intermediate node forwarding a packet detects through Route Maintenance that the next-hop link along the route for that packet is broken (Section 6.3), if the node has another route to the packet's IP Destination Address in its Route Cache, the node SHOULD "salvage" the packet rather than discarding it. ==> s/discarding/discard/ ? 11. Security Considerations ==> nodes feeding wrong (out-of-date) information, acting by their best knowledge? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 2 07:34:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13122 for ; Tue, 2 Apr 2002 07:34:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06866; Tue, 2 Apr 2002 07:15:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06838 for ; Tue, 2 Apr 2002 07:15:25 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12438 for ; Tue, 2 Apr 2002 07:15:23 -0500 (EST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Tue, 2 Apr 2002 14:03:49 +0200 Message-ID: <0489A7888F080B4BA73B53F7E145F29A21AB57@LANMHS20.rd.francetelecom.fr> From: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN To: manet@ietf.org Cc: "'guernich@enst.fr'" Date: Tue, 2 Apr 2002 14:03:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b18ec298-4613-11d6-b1e9-00508b69ab48" Subject: [manet] what about ruting protocols and IP stack compatibility Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-b18ec298-4613-11d6-b1e9-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA3E.7527C49E" ------_=_NextPart_001_01C1DA3E.7527C49E Content-Type: text/plain hi everybody I will take some research about compatibilty between IP stack and Ad Hoc routing protocol and hope to find response to my question. when I study manet routing protocol I find them uncompatible with IP stack (please correct me if I am wrong), if we want to deply such protocols what's the proposed solution kind regards ------_=_NextPart_001_01C1DA3E.7527C49E Content-Type: text/html Content-Transfer-Encoding: quoted-printable what about ruting protocols and IP stack compatibility

hi everybody

I will take some research about compatibilty between = IP stack and Ad Hoc routing protocol and hope to find response to my = question. when I study manet routing protocol I find them uncompatible = with IP stack (please correct me if I am wrong), if we want to deply = such protocols what's the proposed solution

kind regards


------_=_NextPart_001_01C1DA3E.7527C49E-- ------=_NextPartTM-000-b18ec298-4613-11d6-b1e9-00508b69ab48-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 2 07:34:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13132 for ; Tue, 2 Apr 2002 07:34:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA08520 for manet-archive@odin.ietf.org; Tue, 2 Apr 2002 07:34:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06866; Tue, 2 Apr 2002 07:15:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06838 for ; Tue, 2 Apr 2002 07:15:25 -0500 (EST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12438 for ; Tue, 2 Apr 2002 07:15:23 -0500 (EST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Tue, 2 Apr 2002 14:03:49 +0200 Message-ID: <0489A7888F080B4BA73B53F7E145F29A21AB57@LANMHS20.rd.francetelecom.fr> From: MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN To: manet@ietf.org Cc: "'guernich@enst.fr'" Date: Tue, 2 Apr 2002 14:03:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-b18ec298-4613-11d6-b1e9-00508b69ab48" Subject: [manet] what about ruting protocols and IP stack compatibility Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-b18ec298-4613-11d6-b1e9-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DA3E.7527C49E" ------_=_NextPart_001_01C1DA3E.7527C49E Content-Type: text/plain hi everybody I will take some research about compatibilty between IP stack and Ad Hoc routing protocol and hope to find response to my question. when I study manet routing protocol I find them uncompatible with IP stack (please correct me if I am wrong), if we want to deply such protocols what's the proposed solution kind regards ------_=_NextPart_001_01C1DA3E.7527C49E Content-Type: text/html Content-Transfer-Encoding: quoted-printable what about ruting protocols and IP stack compatibility

hi everybody

I will take some research about compatibilty between = IP stack and Ad Hoc routing protocol and hope to find response to my = question. when I study manet routing protocol I find them uncompatible = with IP stack (please correct me if I am wrong), if we want to deply = such protocols what's the proposed solution

kind regards


------_=_NextPart_001_01C1DA3E.7527C49E-- ------=_NextPartTM-000-b18ec298-4613-11d6-b1e9-00508b69ab48-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 2 12:03:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23308 for ; Tue, 2 Apr 2002 12:03:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23573; Tue, 2 Apr 2002 11:43:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23543 for ; Tue, 2 Apr 2002 11:43:35 -0500 (EST) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22235; Tue, 2 Apr 2002 11:43:32 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA12222; Tue, 2 Apr 2002 11:41:40 -0500 (EST) Message-Id: <5.0.1.4.2.20020402114841.02dde500@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 02 Apr 2002 11:50:29 -0500 To: minutes@ietf.org From: Joe Macker Cc: manet@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] Minneapolis Minutes Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Minutes of the Mobile Ad-hoc Networks WG (manet) 53rd IETF Proceedings MONDAY, March 18 at 1930-2200 Minutes taken by Jorjeta Jetcheva ============================== CHAIRS: Joseph Macker M. Scott Corson (ABSENT) AGENDA: 1. Agenda Bashing (5 min) 2. Status of AODV EXPERIMENTAL Submission Progress (10 min) Updates of Current Drafts 3. DSR update: Johnson (Rice) (20 min) 4. TBRPF Update Ogier/Templin (SRI) (30 min) 5. OLSR update Clausen (INRIA) (30 min) New Discussions 6. Manet extensions to OSPF, Baker (CISCO) (20 min) 7. Redirects for MANET Templin (SRI) (20 min) , 8. Other Activity and Implementation Announcements (10 min) 9. Open Discussion Minutes ------- 1. Agenda bashing 2. Charlie Perkins presented AODV EXPERIMENTAL submission progress: - Changes since draft 09 (current draft version is 10) - New version of draft will be released before April which will incorporate late last call comments from Yih-Chun Hu, Manuel Zapata and input from the Routing ADs Bill Fenner and Alex Zinin. - AODV interoperability testing at UC Santa Barbara is taking place next week using seven different implementations of AODV. - AODV workshop after Mobihoc 2002 in Lausanne, Switzerland. The workshop is intended to "provide vision for the future evolution of AODV". 3. Yih-Chun Hu presented updates to the DSR draft (version 7) - Added black lists to enable routing in the presence of unidirectional links. - Added multiple interface support. - Specified fragmentation and reassembly for DSR based on existing standards. - Still to do: * Integrating Route Requests and Route Replies for CIDR blocks. * Would like to add the DSR flow state mechanism as an option to the DSR draft. * Applicability statement (up to 100 nodes; mobility up to 15 seconds per transmission radius). Discussion with the WG chairs regarding authors' desire to add flow state back into the DSR draft. QoS was removed from the flow state draft at the request of the WG chairs. The DSR authors suggested that flow state be included in DSR before DSR goes through WG last call. The WG Chairs suggested soliciting opinions from the mailing list on this issue before making a decision. 4. Richard Ogier presented an update to the TBRPF draft including the following: - Overview of TBRPF. - Changes from version 03 to version 05 - IPR Issues Raised: * Only protects SRI if TBRPF does not become an IETF standard. * If TBRPF (or any part of it) becomes a standard, anyone can use it for any purpose for free. * SRI will give licenses to people who would like to implement TBRPF before it becomes an IETF standard. Related to IPRs, a question was raised regarding IETF action on investigating potential AODV related IPR. The WG chair replied that (Bradner/Coya) had previously been consulted on process and appropriate IETF action was taken by Coya (IBM was contacted) based upon input from the WG chairs. - Clarification of the advantages of modular neighbor sensing. - Overview of TBRPF routing. - Some perceived drawbacks of using OLSR MPRs were presented. A comment was raised that the presentation of MPR disadvantages was misleading, because it discussed only a partial topology mode application of MPRs where several implementors have applied MPRs in a more flexible manner, including full topology modes. Also, it was noted that MPR advantages were not mentioned to balance out the arguments presented. A TBRPF document review by the WG chair suggested that OLSR references and references to non-static documents be avoided/removed from the TBRPF specification. There were numerous cross references and comparisons that were seen as not appropriate for a specification document. - Potential advantages of using differential topology updates were presented - It was pointed at that there was no link-layer notification OLSR implementation from INRIA yet In response, Joe Macker mentioned that NRL has an independently developed an ns- 2 OLSR v4 implementation that includes link-layer notification. - Support for multiple interfaces was recently added - IPv6 operation is discussed Joe Macker raised the question of whether declaring a link down as a result of a single link layer failure notifications in TBRPF and other protocols is a good idea. He suggested that this is a drastic measure given that time varying effects may cause such failure but is not an indication that the link is actually down. To minimize route flapping, etc further filtering on such signals was suggested. - The TBRPF flooding mechanism was reviewed - Simulation of OLSR and TBRPF: still trying to determine why different performance results are reported by different groups using the same code - TBRPF ns-2 and linux code is available from the SRI website. Thomas Clausen pointed out that his comments on the complexity of the TBRPF draft were made regarding the draft's readability rather than the complexity of the protocol itself. 5. Thomas Clausen presented updates to the OLSR draft - The OLSR draft is stable and mature: no core changes since version 00. - Updates from version 05 to version 06: no major changes - OLSR overview - Neighborhood management - Support for multiple interfaces - Generalized and discussed MPR heuristics - Graphs showing OLSR simulation results for MPR coverage for 50 and 100 nodes for the MPR mechanism in the 05 draft and the improved MPR mechanism which includes the new heuristics described in the 06 draft. - Fast rerouting with link-layer notification described Joe Macker raised the issue that the OLSR draft does not specify how packet duplicate detection is performed in the presence of packet aggregation. Thomas Clausen responded that possible implementations of duplicate detection in the context of packet aggregation will be discussed in future versions of the OLSR draft. 6. Fred Baker presented: OSPF v3 as a Manet Routing Protocol - Commercial manet protocols: what is important in the market place? * application-specific protocols may be of interest * ease of deployment is key - Issues with OSPF v2 - OSPF v3 was presented as a better potential framework for implementing a set of manet extensions - A Manet interface type was discussed and related implications to an OSPF extension - A number of approaches and scenarios relating to inter-Area mobility were presented as well Fred Templin raised the question of whether there will be too many prefixes to keep track of. Fred answered that this shouldn't be a big problem as the number of prefixes will not be too large. Dave Johnson pointed out that the concept of areas has been considered before in an ISPAN '99 paper published by the Rice/CMU Monarch project. Movement between areas is accomplished through Mobile IP. This mechanism has also been implemented and tested in a DSR testbed. - A link state metric equation was presented Richard Ogier suggested that path length should be included in the metric. Fred Baker agreed. - Installing IPv4 routes (OSPF v3 is an IPv6 protocol) The WG chair clarified that Fred Baker is not suggesting a replacement for the current proactive MANET protocol proposals, but that his proposal has likely application for a number of envisioned scenarios. Charlie Perkins argued that areas may not be applicable to all ad hoc network environments and to protocols advocating an on-demand approach to routing. A question is raised about whether OSPFv3 handles partitions. Fred Baker answered that it can be done but not easily. 7. Fred Templin presented ICMP redirect issues in MANET 8. Announcements and General WG discussion Yih-Chun Hu reported that a new implementation of DSR on Windows CE from the University of Dublin is now available. A new implementation of DSR under linux is also available. Contact yihchun@cs.cmu.edu for more information. Joe Macker announced that NRL has made available the OLSR Linux implementation with NRL modifications (this code is based upon INRIA v3 code). It has been applied in live testbeds with 10-20 mobile nodes. There is also a v4 based ns2 model which is being released. This model includes several optional modes including link layer notification and a full topology mode. The project releases can be found at . Dave Johnson advertised Mobihoc 2002 to be held in the summer of 2002 in Lausanne, Switzerland. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 2 12:03:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23318 for ; Tue, 2 Apr 2002 12:03:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26333 for manet-archive@odin.ietf.org; Tue, 2 Apr 2002 12:03:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23573; Tue, 2 Apr 2002 11:43:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23543 for ; Tue, 2 Apr 2002 11:43:35 -0500 (EST) Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22235; Tue, 2 Apr 2002 11:43:32 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA12222; Tue, 2 Apr 2002 11:41:40 -0500 (EST) Message-Id: <5.0.1.4.2.20020402114841.02dde500@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 02 Apr 2002 11:50:29 -0500 To: minutes@ietf.org From: Joe Macker Cc: manet@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] Minneapolis Minutes Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Minutes of the Mobile Ad-hoc Networks WG (manet) 53rd IETF Proceedings MONDAY, March 18 at 1930-2200 Minutes taken by Jorjeta Jetcheva ============================== CHAIRS: Joseph Macker M. Scott Corson (ABSENT) AGENDA: 1. Agenda Bashing (5 min) 2. Status of AODV EXPERIMENTAL Submission Progress (10 min) Updates of Current Drafts 3. DSR update: Johnson (Rice) (20 min) 4. TBRPF Update Ogier/Templin (SRI) (30 min) 5. OLSR update Clausen (INRIA) (30 min) New Discussions 6. Manet extensions to OSPF, Baker (CISCO) (20 min) 7. Redirects for MANET Templin (SRI) (20 min) , 8. Other Activity and Implementation Announcements (10 min) 9. Open Discussion Minutes ------- 1. Agenda bashing 2. Charlie Perkins presented AODV EXPERIMENTAL submission progress: - Changes since draft 09 (current draft version is 10) - New version of draft will be released before April which will incorporate late last call comments from Yih-Chun Hu, Manuel Zapata and input from the Routing ADs Bill Fenner and Alex Zinin. - AODV interoperability testing at UC Santa Barbara is taking place next week using seven different implementations of AODV. - AODV workshop after Mobihoc 2002 in Lausanne, Switzerland. The workshop is intended to "provide vision for the future evolution of AODV". 3. Yih-Chun Hu presented updates to the DSR draft (version 7) - Added black lists to enable routing in the presence of unidirectional links. - Added multiple interface support. - Specified fragmentation and reassembly for DSR based on existing standards. - Still to do: * Integrating Route Requests and Route Replies for CIDR blocks. * Would like to add the DSR flow state mechanism as an option to the DSR draft. * Applicability statement (up to 100 nodes; mobility up to 15 seconds per transmission radius). Discussion with the WG chairs regarding authors' desire to add flow state back into the DSR draft. QoS was removed from the flow state draft at the request of the WG chairs. The DSR authors suggested that flow state be included in DSR before DSR goes through WG last call. The WG Chairs suggested soliciting opinions from the mailing list on this issue before making a decision. 4. Richard Ogier presented an update to the TBRPF draft including the following: - Overview of TBRPF. - Changes from version 03 to version 05 - IPR Issues Raised: * Only protects SRI if TBRPF does not become an IETF standard. * If TBRPF (or any part of it) becomes a standard, anyone can use it for any purpose for free. * SRI will give licenses to people who would like to implement TBRPF before it becomes an IETF standard. Related to IPRs, a question was raised regarding IETF action on investigating potential AODV related IPR. The WG chair replied that (Bradner/Coya) had previously been consulted on process and appropriate IETF action was taken by Coya (IBM was contacted) based upon input from the WG chairs. - Clarification of the advantages of modular neighbor sensing. - Overview of TBRPF routing. - Some perceived drawbacks of using OLSR MPRs were presented. A comment was raised that the presentation of MPR disadvantages was misleading, because it discussed only a partial topology mode application of MPRs where several implementors have applied MPRs in a more flexible manner, including full topology modes. Also, it was noted that MPR advantages were not mentioned to balance out the arguments presented. A TBRPF document review by the WG chair suggested that OLSR references and references to non-static documents be avoided/removed from the TBRPF specification. There were numerous cross references and comparisons that were seen as not appropriate for a specification document. - Potential advantages of using differential topology updates were presented - It was pointed at that there was no link-layer notification OLSR implementation from INRIA yet In response, Joe Macker mentioned that NRL has an independently developed an ns- 2 OLSR v4 implementation that includes link-layer notification. - Support for multiple interfaces was recently added - IPv6 operation is discussed Joe Macker raised the question of whether declaring a link down as a result of a single link layer failure notifications in TBRPF and other protocols is a good idea. He suggested that this is a drastic measure given that time varying effects may cause such failure but is not an indication that the link is actually down. To minimize route flapping, etc further filtering on such signals was suggested. - The TBRPF flooding mechanism was reviewed - Simulation of OLSR and TBRPF: still trying to determine why different performance results are reported by different groups using the same code - TBRPF ns-2 and linux code is available from the SRI website. Thomas Clausen pointed out that his comments on the complexity of the TBRPF draft were made regarding the draft's readability rather than the complexity of the protocol itself. 5. Thomas Clausen presented updates to the OLSR draft - The OLSR draft is stable and mature: no core changes since version 00. - Updates from version 05 to version 06: no major changes - OLSR overview - Neighborhood management - Support for multiple interfaces - Generalized and discussed MPR heuristics - Graphs showing OLSR simulation results for MPR coverage for 50 and 100 nodes for the MPR mechanism in the 05 draft and the improved MPR mechanism which includes the new heuristics described in the 06 draft. - Fast rerouting with link-layer notification described Joe Macker raised the issue that the OLSR draft does not specify how packet duplicate detection is performed in the presence of packet aggregation. Thomas Clausen responded that possible implementations of duplicate detection in the context of packet aggregation will be discussed in future versions of the OLSR draft. 6. Fred Baker presented: OSPF v3 as a Manet Routing Protocol - Commercial manet protocols: what is important in the market place? * application-specific protocols may be of interest * ease of deployment is key - Issues with OSPF v2 - OSPF v3 was presented as a better potential framework for implementing a set of manet extensions - A Manet interface type was discussed and related implications to an OSPF extension - A number of approaches and scenarios relating to inter-Area mobility were presented as well Fred Templin raised the question of whether there will be too many prefixes to keep track of. Fred answered that this shouldn't be a big problem as the number of prefixes will not be too large. Dave Johnson pointed out that the concept of areas has been considered before in an ISPAN '99 paper published by the Rice/CMU Monarch project. Movement between areas is accomplished through Mobile IP. This mechanism has also been implemented and tested in a DSR testbed. - A link state metric equation was presented Richard Ogier suggested that path length should be included in the metric. Fred Baker agreed. - Installing IPv4 routes (OSPF v3 is an IPv6 protocol) The WG chair clarified that Fred Baker is not suggesting a replacement for the current proactive MANET protocol proposals, but that his proposal has likely application for a number of envisioned scenarios. Charlie Perkins argued that areas may not be applicable to all ad hoc network environments and to protocols advocating an on-demand approach to routing. A question is raised about whether OSPFv3 handles partitions. Fred Baker answered that it can be done but not easily. 7. Fred Templin presented ICMP redirect issues in MANET 8. Announcements and General WG discussion Yih-Chun Hu reported that a new implementation of DSR on Windows CE from the University of Dublin is now available. A new implementation of DSR under linux is also available. Contact yihchun@cs.cmu.edu for more information. Joe Macker announced that NRL has made available the OLSR Linux implementation with NRL modifications (this code is based upon INRIA v3 code). It has been applied in live testbeds with 10-20 mobile nodes. There is also a v4 based ns2 model which is being released. This model includes several optional modes including link layer notification and a full topology mode. The project releases can be found at . Dave Johnson advertised Mobihoc 2002 to be held in the summer of 2002 in Lausanne, Switzerland. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 2 16:04:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03417 for ; Tue, 2 Apr 2002 16:04:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11903; Tue, 2 Apr 2002 15:35:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11874 for ; Tue, 2 Apr 2002 15:35:48 -0500 (EST) Received: from mail.engr.ucsb.edu (mail.engr.ucsb.edu [128.111.27.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01972 for ; Tue, 2 Apr 2002 15:35:45 -0500 (EST) Received: from moment.cs.ucsb.edu ([128.111.40.94]) by mail.engr.ucsb.edu with esmtp (Exim 3.11 #2) id 16sV0F-000539-00; Tue, 02 Apr 2002 12:35:39 -0800 Received: from mesa (moment [128.111.40.94]) by moment.cs.ucsb.edu (8.11.6/8.11.6) with ESMTP id g32KZrx19795; Tue, 2 Apr 2002 12:35:53 -0800 From: "Ian Chakeres" To: "MANET mailing list" , Date: Tue, 2 Apr 2002 12:35:24 -0800 Message-ID: <003b01c1da85$eb1b3960$60286f80@cs.ucsb.edu> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [manet] UCSB AODV Implementation Release Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit We are releasing our AODV implementation. It is available at http://moment.cs.ucsb.edu/AODV/aodv.html, look for "UCSB Implementation (new 4/2/02)". - Runs on Linux 2.4.x kernels - AODV Draft v.10 - No kernel modifications; uses netfilter - Code is AODV-interop tested and verified. - Lots of command line options - all source provided Have fun, Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue Apr 2 16:04:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03430 for ; Tue, 2 Apr 2002 16:04:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13684 for manet-archive@odin.ietf.org; Tue, 2 Apr 2002 16:04:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11903; Tue, 2 Apr 2002 15:35:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11874 for ; Tue, 2 Apr 2002 15:35:48 -0500 (EST) Received: from mail.engr.ucsb.edu (mail.engr.ucsb.edu [128.111.27.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01972 for ; Tue, 2 Apr 2002 15:35:45 -0500 (EST) Received: from moment.cs.ucsb.edu ([128.111.40.94]) by mail.engr.ucsb.edu with esmtp (Exim 3.11 #2) id 16sV0F-000539-00; Tue, 02 Apr 2002 12:35:39 -0800 Received: from mesa (moment [128.111.40.94]) by moment.cs.ucsb.edu (8.11.6/8.11.6) with ESMTP id g32KZrx19795; Tue, 2 Apr 2002 12:35:53 -0800 From: "Ian Chakeres" To: "MANET mailing list" , Date: Tue, 2 Apr 2002 12:35:24 -0800 Message-ID: <003b01c1da85$eb1b3960$60286f80@cs.ucsb.edu> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [manet] UCSB AODV Implementation Release Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit We are releasing our AODV implementation. It is available at http://moment.cs.ucsb.edu/AODV/aodv.html, look for "UCSB Implementation (new 4/2/02)". - Runs on Linux 2.4.x kernels - AODV Draft v.10 - No kernel modifications; uses netfilter - Code is AODV-interop tested and verified. - Lots of command line options - all source provided Have fun, Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 4 00:23:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26342 for ; Thu, 4 Apr 2002 00:23:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21964; Wed, 3 Apr 2002 23:56:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21919 for ; Wed, 3 Apr 2002 23:56:45 -0500 (EST) Received: from patty.levels.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26014 for ; Wed, 3 Apr 2002 23:56:40 -0500 (EST) Received: from gurami.itr.unisa.edu.au (gurami [172.17.0.68]) by patty.levels.unisa.edu.au (8.12.2/8.12.2) with ESMTP id g344uhgq012110 for ; Thu, 4 Apr 2002 14:26:43 +0930 (CST) Received: from gurami (gurami [172.17.0.68]) by gurami.itr.unisa.edu.au (8.8.8+Sun/8.8.8) with SMTP id OAA16779 for ; Thu, 4 Apr 2002 14:26:42 +0930 (CST) Message-Id: <200204040456.OAA16779@gurami.itr.unisa.edu.au> Date: Thu, 4 Apr 2002 14:26:42 +0930 (CST) From: Peter Pham Reply-To: Peter Pham To: manet@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZCjwVamkoYBNCd2jZ/ztvA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Subject: [manet] (no subject) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org unsubcribe manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 4 00:23:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26356 for ; Thu, 4 Apr 2002 00:23:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA23505 for manet-archive@odin.ietf.org; Thu, 4 Apr 2002 00:23:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21964; Wed, 3 Apr 2002 23:56:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21919 for ; Wed, 3 Apr 2002 23:56:45 -0500 (EST) Received: from patty.levels.unisa.edu.au (patty.levels.unisa.edu.au [130.220.36.156]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26014 for ; Wed, 3 Apr 2002 23:56:40 -0500 (EST) Received: from gurami.itr.unisa.edu.au (gurami [172.17.0.68]) by patty.levels.unisa.edu.au (8.12.2/8.12.2) with ESMTP id g344uhgq012110 for ; Thu, 4 Apr 2002 14:26:43 +0930 (CST) Received: from gurami (gurami [172.17.0.68]) by gurami.itr.unisa.edu.au (8.8.8+Sun/8.8.8) with SMTP id OAA16779 for ; Thu, 4 Apr 2002 14:26:42 +0930 (CST) Message-Id: <200204040456.OAA16779@gurami.itr.unisa.edu.au> Date: Thu, 4 Apr 2002 14:26:42 +0930 (CST) From: Peter Pham Reply-To: Peter Pham To: manet@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZCjwVamkoYBNCd2jZ/ztvA== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Subject: [manet] (no subject) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org unsubcribe manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 4 04:26:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07628 for ; Thu, 4 Apr 2002 04:26:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14095; Thu, 4 Apr 2002 03:40:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14063 for ; Thu, 4 Apr 2002 03:40:11 -0500 (EST) Received: from ep_mailout2 ([203.254.224.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07047 for ; Thu, 4 Apr 2002 03:39:54 -0500 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GU100601BWJCL@mailout2.samsung.com> for manet@ietf.org; Thu, 04 Apr 2002 17:36:19 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GU1005CZBWJWN@mailout2.samsung.com> for manet@ietf.org; Thu, 04 Apr 2002 17:36:19 +0900 (KST) Received: from zbin ([75.2.45.234]) by mmp1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GU100LD3BX4YU@mmp1.samsung.com> for manet@ietf.org; Thu, 04 Apr 2002 17:36:41 +0900 (KST) Date: Thu, 04 Apr 2002 17:40:30 +0900 From: zb Subject: [manet] an AODV question To: manet@ietf.org Message-id: <004301c1dbb4$60be8760$ea2d024b@zbin> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5.0.1.4.2.20020402114841.02dde500@pop.itd.nrl.navy.mil> Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT hi all, Can anyboday tell me the difference between routing table and precursor list in AODV? Sorry to ask this stupid question if it is. I need to understand them in network formation. thanks, bin ************************************* Zhen Bin i-Networking lab, Samsung Advanced Institute of Technology, San14-1, NongSeo-ri, Kiheung-Eup, Yongin, Kyungki-do, 440600, Korea 82-31-2809569 (fax) 82-31-2809534 (o) 82-31-2122268 (h) ************************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 4 04:26:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07638 for ; Thu, 4 Apr 2002 04:26:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16111 for manet-archive@odin.ietf.org; Thu, 4 Apr 2002 04:26:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14095; Thu, 4 Apr 2002 03:40:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14063 for ; Thu, 4 Apr 2002 03:40:11 -0500 (EST) Received: from ep_mailout2 ([203.254.224.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07047 for ; Thu, 4 Apr 2002 03:39:54 -0500 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GU100601BWJCL@mailout2.samsung.com> for manet@ietf.org; Thu, 04 Apr 2002 17:36:19 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GU1005CZBWJWN@mailout2.samsung.com> for manet@ietf.org; Thu, 04 Apr 2002 17:36:19 +0900 (KST) Received: from zbin ([75.2.45.234]) by mmp1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GU100LD3BX4YU@mmp1.samsung.com> for manet@ietf.org; Thu, 04 Apr 2002 17:36:41 +0900 (KST) Date: Thu, 04 Apr 2002 17:40:30 +0900 From: zb Subject: [manet] an AODV question To: manet@ietf.org Message-id: <004301c1dbb4$60be8760$ea2d024b@zbin> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5.0.1.4.2.20020402114841.02dde500@pop.itd.nrl.navy.mil> Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT hi all, Can anyboday tell me the difference between routing table and precursor list in AODV? Sorry to ask this stupid question if it is. I need to understand them in network formation. thanks, bin ************************************* Zhen Bin i-Networking lab, Samsung Advanced Institute of Technology, San14-1, NongSeo-ri, Kiheung-Eup, Yongin, Kyungki-do, 440600, Korea 82-31-2809569 (fax) 82-31-2809534 (o) 82-31-2122268 (h) ************************************* _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 4 10:24:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18511 for ; Thu, 4 Apr 2002 10:24:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06582; Thu, 4 Apr 2002 10:00:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06298 for ; Thu, 4 Apr 2002 10:00:12 -0500 (EST) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17592 for ; Thu, 4 Apr 2002 10:00:02 -0500 (EST) Received: from antd.nist.gov (stratus.antd.nist.gov [129.6.50.8]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g34ExxCk002827; Thu, 4 Apr 2002 09:59:59 -0500 (EST) Message-ID: <3CAC6AAD.78502A93@antd.nist.gov> Date: Thu, 04 Apr 2002 10:01:01 -0500 From: Leonard Miller Organization: NIST X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: MANET email list CC: Nader Moayeri , Rusty Baldwin , Jason Ballah Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Improved DSR OPNET model Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit The NIST DSR OPNET model was downloaded by Jason T. Ballah, a student at the Air Force Institute of Technology in Dayton, Ohio. He upgraded the NIST model to a later version of the DSR protocol, with more features, and used it for his master's thesis on mutual authentication in MANETs. Jason's thesis and model files are available on our bibliography page under "Modeling and Simulation." Also available there is his Validation & Verification plan, which gives a summary of the changes he made to the NIST model and his methodology for verifying the model. All files accessible via http://w3.antd.nist.gov/wctg/prd_dsrfiles.html According to Jason, "The model now performs the same (within a 95% confidence interval) as the published data from the NS-2 models implemented by the research team at CMU. It is not the full implementation of the DSR specifications since it still does not perform piggy-backing operations or flow-state, but I believe it is much closer and could definitely be expanded and used by other researchers." NIST is happy to make this model available, but since it was developed at another agency, we cannot provide support for it. A limited amount of support is available from AFIT: contact Maj. Rusty Baldwin at rusty.baldwin@afit.edu -- L. E. Miller ._.. . _. __ .. ._.. ._.. . ._. ._ _ _. .. ... _ Leonard E. Miller, Wireless Commun. Technologies Group National Institute of Standards & Technology (NIST) 100 Bureau Drive Stop 8920, Bldg. 820, Room 445 Gaithersburg, Maryland 20899-8920 Phone: 301-975-8018 Fax: 301-590-0932 email: lmiller@antd.nist.gov, LenMiller42@cs.com http://w3.antd.nist.gov/wctg/ ._ _. ._ ._.. _.__ ... .. ... ._ _. _.. ... .. __ .._ ._.. ._ _ .. ___ _. ___... .__ .. ._. . ._.. . ... ... _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 4 11:24:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18524 for ; Thu, 4 Apr 2002 10:24:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08524 for manet-archive@odin.ietf.org; Thu, 4 Apr 2002 10:24:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06582; Thu, 4 Apr 2002 10:00:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06298 for ; Thu, 4 Apr 2002 10:00:12 -0500 (EST) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17592 for ; Thu, 4 Apr 2002 10:00:02 -0500 (EST) Received: from antd.nist.gov (stratus.antd.nist.gov [129.6.50.8]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g34ExxCk002827; Thu, 4 Apr 2002 09:59:59 -0500 (EST) Message-ID: <3CAC6AAD.78502A93@antd.nist.gov> Date: Thu, 04 Apr 2002 10:01:01 -0500 From: Leonard Miller Organization: NIST X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: MANET email list CC: Nader Moayeri , Rusty Baldwin , Jason Ballah Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Improved DSR OPNET model Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit The NIST DSR OPNET model was downloaded by Jason T. Ballah, a student at the Air Force Institute of Technology in Dayton, Ohio. He upgraded the NIST model to a later version of the DSR protocol, with more features, and used it for his master's thesis on mutual authentication in MANETs. Jason's thesis and model files are available on our bibliography page under "Modeling and Simulation." Also available there is his Validation & Verification plan, which gives a summary of the changes he made to the NIST model and his methodology for verifying the model. All files accessible via http://w3.antd.nist.gov/wctg/prd_dsrfiles.html According to Jason, "The model now performs the same (within a 95% confidence interval) as the published data from the NS-2 models implemented by the research team at CMU. It is not the full implementation of the DSR specifications since it still does not perform piggy-backing operations or flow-state, but I believe it is much closer and could definitely be expanded and used by other researchers." NIST is happy to make this model available, but since it was developed at another agency, we cannot provide support for it. A limited amount of support is available from AFIT: contact Maj. Rusty Baldwin at rusty.baldwin@afit.edu -- L. E. Miller ._.. . _. __ .. ._.. ._.. . ._. ._ _ _. .. ... _ Leonard E. Miller, Wireless Commun. Technologies Group National Institute of Standards & Technology (NIST) 100 Bureau Drive Stop 8920, Bldg. 820, Room 445 Gaithersburg, Maryland 20899-8920 Phone: 301-975-8018 Fax: 301-590-0932 email: lmiller@antd.nist.gov, LenMiller42@cs.com http://w3.antd.nist.gov/wctg/ ._ _. ._ ._.. _.__ ... .. ... ._ _. _.. ... .. __ .._ ._.. ._ _ .. ___ _. ___... .__ .. ._. . ._.. . ... ... _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 4 14:25:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05208 for ; Thu, 4 Apr 2002 14:25:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23635; Thu, 4 Apr 2002 13:44:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23602 for ; Thu, 4 Apr 2002 13:44:55 -0500 (EST) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03748 for ; Thu, 4 Apr 2002 13:44:36 -0500 (EST) Received: from vivi.cc.vt.edu (IDENT:mirapoint@vivi-lb.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g34IiU5293044 for ; Thu, 4 Apr 2002 13:44:30 -0500 (EST) Received: from zathras (zathras.cc.vt.edu [198.82.162.117]) by vivi.cc.vt.edu (Mirapoint) with ESMTP id AOM50160; Thu, 4 Apr 2002 13:44:29 -0500 (EST) X-WebMail-UserID: vdham Date: Thu, 4 Apr 2002 13:44:29 -0500 From: Vikram Dham To: manet@ietf.org X-EXP32-SerialNo: 00002964 Subject: RE: [manet] About IEEE802.11 model in OPNET] Message-ID: <3CB20277@zathras> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: WebMail (Hydra) SMTP v3.61 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi All. John is right in his observation regarding the OPNET WLAN model. There is work around for it. In order to account for interference you shouldn't use the receiver stat wire in wlan mac process model but create your own stat wire and use that to determine whether the channel is busy or free. I hope the above helps and you are able to use OPNET model for your simulations :) With Best Regards Vikram Dham Graduate Research Assistant Alexandria Research Institute Virginia Tech,USA > Aaron, > > I am sorry, not getting this message returned to me indicated I did not > send it to the manet list. There is more information on the > deficiencies of the current OPNET wlan_mac model for ad hoc network > modeling. The specific problem you are having is alluded to in the > text. OPNET uses the receiver busy stat to indicate the channel busy > condition. It is set early in the pipeline stages based solely on > whether the sender and the destination channels match. The result is > when one node transmits, all other nodes sense the channel busy > regardless of separation distance. This prevents spatial reuse and also > eliminates the problems encountered in ad hoc networking, i.e. hidden > node effects, exposed nodes, and the near far problem. Please note, > however, that a subsequent pipeline stage makes certain that you can > only communicate to a node up to the distance specified in the range > parameter that is set in the simulation attributes. You will see > packets fail based on separation distance. > > John > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 4 14:25:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05218 for ; Thu, 4 Apr 2002 14:25:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26080 for manet-archive@odin.ietf.org; Thu, 4 Apr 2002 14:25:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23635; Thu, 4 Apr 2002 13:44:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23602 for ; Thu, 4 Apr 2002 13:44:55 -0500 (EST) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03748 for ; Thu, 4 Apr 2002 13:44:36 -0500 (EST) Received: from vivi.cc.vt.edu (IDENT:mirapoint@vivi-lb.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g34IiU5293044 for ; Thu, 4 Apr 2002 13:44:30 -0500 (EST) Received: from zathras (zathras.cc.vt.edu [198.82.162.117]) by vivi.cc.vt.edu (Mirapoint) with ESMTP id AOM50160; Thu, 4 Apr 2002 13:44:29 -0500 (EST) X-WebMail-UserID: vdham Date: Thu, 4 Apr 2002 13:44:29 -0500 From: Vikram Dham To: manet@ietf.org X-EXP32-SerialNo: 00002964 Subject: RE: [manet] About IEEE802.11 model in OPNET] Message-ID: <3CB20277@zathras> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: WebMail (Hydra) SMTP v3.61 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi All. John is right in his observation regarding the OPNET WLAN model. There is work around for it. In order to account for interference you shouldn't use the receiver stat wire in wlan mac process model but create your own stat wire and use that to determine whether the channel is busy or free. I hope the above helps and you are able to use OPNET model for your simulations :) With Best Regards Vikram Dham Graduate Research Assistant Alexandria Research Institute Virginia Tech,USA > Aaron, > > I am sorry, not getting this message returned to me indicated I did not > send it to the manet list. There is more information on the > deficiencies of the current OPNET wlan_mac model for ad hoc network > modeling. The specific problem you are having is alluded to in the > text. OPNET uses the receiver busy stat to indicate the channel busy > condition. It is set early in the pipeline stages based solely on > whether the sender and the destination channels match. The result is > when one node transmits, all other nodes sense the channel busy > regardless of separation distance. This prevents spatial reuse and also > eliminates the problems encountered in ad hoc networking, i.e. hidden > node effects, exposed nodes, and the near far problem. Please note, > however, that a subsequent pipeline stage makes certain that you can > only communicate to a node up to the distance specified in the range > parameter that is set in the simulation attributes. You will see > packets fail based on separation distance. > > John > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Apr 6 16:19:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15639 for ; Sat, 6 Apr 2002 16:19:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03372; Sat, 6 Apr 2002 15:45:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03341 for ; Sat, 6 Apr 2002 15:45:47 -0500 (EST) Received: from cs.tamu.edu (IDENT:0@clavin.cs.tamu.edu [128.194.130.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15214 for ; Sat, 6 Apr 2002 15:45:43 -0500 (EST) Received: from dogbert.cs.tamu.edu (IDENT:6928@dogbert [128.194.130.18]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id g36Kjkg02275 for ; Sat, 6 Apr 2002 14:45:46 -0600 (CST) Received: from localhost (b0s6067@localhost) by dogbert.cs.tamu.edu (8.11.0/8.11.0) with ESMTP id g36KjjT20352 for ; Sat, 6 Apr 2002 14:45:45 -0600 (CST) X-Authentication-Warning: dogbert.cs.tamu.edu: b0s6067 owned process doing -bs Date: Sat, 6 Apr 2002 14:45:45 -0600 (CST) From: Bo - Sun X-Sender: b0s6067@dogbert To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] traffic characteristics Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org hi: Could someone recommend some papers about the traffic characteristics of ad hoc networks? Thanks, bo sun _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Sat Apr 6 16:19:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15650 for ; Sat, 6 Apr 2002 16:19:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04587 for manet-archive@odin.ietf.org; Sat, 6 Apr 2002 16:19:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03372; Sat, 6 Apr 2002 15:45:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03341 for ; Sat, 6 Apr 2002 15:45:47 -0500 (EST) Received: from cs.tamu.edu (IDENT:0@clavin.cs.tamu.edu [128.194.130.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15214 for ; Sat, 6 Apr 2002 15:45:43 -0500 (EST) Received: from dogbert.cs.tamu.edu (IDENT:6928@dogbert [128.194.130.18]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id g36Kjkg02275 for ; Sat, 6 Apr 2002 14:45:46 -0600 (CST) Received: from localhost (b0s6067@localhost) by dogbert.cs.tamu.edu (8.11.0/8.11.0) with ESMTP id g36KjjT20352 for ; Sat, 6 Apr 2002 14:45:45 -0600 (CST) X-Authentication-Warning: dogbert.cs.tamu.edu: b0s6067 owned process doing -bs Date: Sat, 6 Apr 2002 14:45:45 -0600 (CST) From: Bo - Sun X-Sender: b0s6067@dogbert To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] traffic characteristics Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org hi: Could someone recommend some papers about the traffic characteristics of ad hoc networks? Thanks, bo sun _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Apr 7 11:27:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27513 for ; Sun, 7 Apr 2002 11:27:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25510; Sun, 7 Apr 2002 11:01:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25471 for ; Sun, 7 Apr 2002 11:01:24 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27292 for ; Sun, 7 Apr 2002 11:01:20 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g37F0m707243; Sun, 7 Apr 2002 18:00:48 +0300 Date: Sun, 7 Apr 2002 18:00:48 +0300 (EEST) From: Pekka Savola To: charliep@iprg.nokia.com cc: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] AODV QoS incompatible with IPSEC Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, I just glanced through a summary of QoS for AODV and noticed the following in draft-perkins-manet-aodvqos-00.txt: --8<-- 5. Security Considerations This draft specifies mechanisms for handling quality of service. It does not introduce any special security considerations which were not already present in the AODV routing protocol [2]. --8<-- This is untrue, because: --8<-- Before forwarding the RREQ, an intermediate node MUST compare its NODE_TRAVERSAL_TIME to the (remaining) Delay indicated in the Maximum Delay Extension. If the Delay is less, the node MUST discard the RREQ and not process it any further. Otherwise, the node subtracts NODE_TRAVERSAL_TIME from the Delay value in the extension and continues processing the RREQ as specified in [2]. [...] Before forwarding the RREQ, an intermediate node MUST compare its approximate jitter to the (remaining) Jitter indicated in the Maximum Jitter Extension. If the Jitter is less, the node MUST discard the RREQ and not process it any further. Otherwise, the node subtracts --8<-- (note subtract above) Intermediate nodes modifying the packet for all practical purposes kills IPSEC except for an keys-shared-by-everyone method (only one applicable to e.g. DSR I think). IPSEC (to secure the routing messages) seems to be possible with AODV, but not with AODV QoS extensions. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun Apr 7 11:27:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27529 for ; Sun, 7 Apr 2002 11:27:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26491 for manet-archive@odin.ietf.org; Sun, 7 Apr 2002 11:27:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25510; Sun, 7 Apr 2002 11:01:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25471 for ; Sun, 7 Apr 2002 11:01:24 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27292 for ; Sun, 7 Apr 2002 11:01:20 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g37F0m707243; Sun, 7 Apr 2002 18:00:48 +0300 Date: Sun, 7 Apr 2002 18:00:48 +0300 (EEST) From: Pekka Savola To: charliep@iprg.nokia.com cc: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] AODV QoS incompatible with IPSEC Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, I just glanced through a summary of QoS for AODV and noticed the following in draft-perkins-manet-aodvqos-00.txt: --8<-- 5. Security Considerations This draft specifies mechanisms for handling quality of service. It does not introduce any special security considerations which were not already present in the AODV routing protocol [2]. --8<-- This is untrue, because: --8<-- Before forwarding the RREQ, an intermediate node MUST compare its NODE_TRAVERSAL_TIME to the (remaining) Delay indicated in the Maximum Delay Extension. If the Delay is less, the node MUST discard the RREQ and not process it any further. Otherwise, the node subtracts NODE_TRAVERSAL_TIME from the Delay value in the extension and continues processing the RREQ as specified in [2]. [...] Before forwarding the RREQ, an intermediate node MUST compare its approximate jitter to the (remaining) Jitter indicated in the Maximum Jitter Extension. If the Jitter is less, the node MUST discard the RREQ and not process it any further. Otherwise, the node subtracts --8<-- (note subtract above) Intermediate nodes modifying the packet for all practical purposes kills IPSEC except for an keys-shared-by-everyone method (only one applicable to e.g. DSR I think). IPSEC (to secure the routing messages) seems to be possible with AODV, but not with AODV QoS extensions. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Apr 7 21:09:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03019 for ; Sun, 7 Apr 2002 21:09:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16406; Sun, 7 Apr 2002 20:40:30 -0400 (EDT) Received: from orval (celis.cs.rice.edu [128.42.6.83]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id UAA16366 for manet@ietf.org; Sun, 7 Apr 2002 20:39:23 -0400 (EDT) Date: Sun, 7 Apr 2002 20:27:36 -0400 (EDT) From: Yih-Chun Hu To: Pekka Savola cc: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, Thanks for your comments. >- I'm a bit unsure what happens if a packet which has a DSR header but >also has piggybacked data is in send/maintenance queue. Is this possible? >These could in some cases perhaps lead to data being delivered more than >once to the destination. I guess I don't see how that (multiple data delivery) might happen. Obviously it's possible with salvaging, since you might not get the ACK even when the data gets through, but any local repair mechanism might have this problem. Even if it were to happen, we'd still be compliant with the semantics of IP... >- I didn't get a good picture which DSR options can be seen in the same >DSR header and which not. Also, as sections in chapter 5 list what IP >header fields would look like when there are multiple options in a packet, >the multi-option combinations seem to be less covered than their full >counterparts. Maybe we could point out in the draft which types could legally be present. Perhaps I don't understand the concern, since the concept is that anything can be piggybacked in anything. >1. Introduction > >[...] Each data packet sent then carries in its header the > complete, ordered list of nodes through which the packet will pass, > allowing packet routing to be trivially loop-free and avoiding the > need for up-to-date routing information in the intermediate nodes > through which the packet is forwarded. [...] > >==> the need for up-to-date information may not necessarily be a bad >thing. Now the sources are in charge of that. Moreover, the sources are >also in charge of the whole network, as their source routes will be cached >and used for other communications. > >This is quite effective, but can be very dangerous in case of e.g. >implementation bugs, unforeseen problems (e.g. a source getting out of >sync, and "competing with the cache" with the rest of manet nodes) and >such: one node can pretty much wreck the whole routing fabric without even >trying hard. The need for up-to-date information at each intermediate node is problematic, for example, if nodes turn themselves off periodically, effectively rebooting. Such nodes would not have state consistant with the rest of the network, and in certain routing protocols, this could cause routing loops. I just don't see how you could ever get a routing loop in DSR. Your cache determines the routes you add to packets. Those routes MUST be loop-free, since they're finite length, and include a current-address, which is monotone increasing. Since each packet carries its own route, it's route is entirely determined by the (by definition consistant) state at the sender, and no other node's state. >[...] For > example, DSR does not use any periodic routing advertisement, link > status sensing, or neighbor detection packets, and does not rely on > these functions from any underlying protocols in the network. This > entirely on-demand behavior and lack of periodic activity allows > the number of overhead packets caused by DSR to scale all the way > down to zero, [...] > >==> I see DSR header functions rather equivalent to link status sensing >(maintenance procedures, Send Queue, etc.) and others above. And they're all on-demand (not periodic). Maybe I don't understand what you're trying to say? > > In response to a single Route Discovery (as well as through routing > information from other packets overheard), a node may learn and cache > multiple routes to any destination. > >==> just a trivial comment: cache management strategies will be quite >critical. Very true. We recommend a specific cache management scheme, called Link-MaxLife. >3.1. Basic DSR Route Discovery > > Node E could instead simply reverse the sequence of hops in the route > record that it is trying to send in the Route Reply, and use this as > the source route on the packet carrying the Route Reply itself. For > MAC protocols such as IEEE 802.11 that require a bidirectional frame > exchange as part of the MAC protocol [11], the discovered source > route MUST be reversed in this way to return the Route Reply since it > tests the discovered route to ensure it is bidirectional before the > Route Discovery initiator begins using the route; this route reversal > also avoids the overhead of a possible second Route Discovery. > >==> This (and various other places in the text, e.g. Appendix A) assumes >that the link-layer technology, at least from the point of view of >directionality, must be the same all over the manet, or at least all manet >nodes know the directionality of each device. Not manet-wide. Yes, for your own interfaces, but this is flexibility over most existing manet routing protocols, which require bidirectionality at all interfaces. When you put in the special addresses indicating a bidirectionality switch, the receivers know the directionality of their receive interface, and can deduce which parts of a source route must be bidirectional and which ones can have unidirectional links. For example, when the route A->B->*->C->D->*->E is received at D, it knows whether it's interface is bidirectional or unidirectional. If it's unidirectional, it knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t out a bidirectional interface, it adds a * to the source route first. >This seems a rather big aasumption. It seems rather smaller than assuming that all interfaces are bidirectional. I don't really want to belabor this point, because I don't think DSR's unidirectional support is very well tuned, and because the commodity standard for wireless interfaces these days is 802.11, which does require bidirectionality. > When initiating a Route Discovery, the sending node saves a copy of > the original packet (that triggered the Discovery) in a local buffer > called the "Send Buffer". > >==> might this create extra delays in the case of Route Discoveries >failing too (e.g. link failure, no manet nodes/AP's temporarily in range, >...) ? Yes, that's the price you pay for an on-demand protocol. Discovery can fail. You may have to wait. AODV, ZRP, SSA, ABR, ... all share this problem. >4.1. Route Cache > > - In DSR, the route returned in each Route Reply that is received > by the initiator of a Route Discovery (or that is learned from > the header of overhead packets, as described in Section 6.1.4) > represents a complete path (a sequence of links) leading to the > destination node. By caching each of these paths separately, > a "path cache" organization for the Route Cache can be formed. > A path cache is very simple to implement and easily guarantees > that all routes are loop-free, since each individual route from > a Route Reply or Route Request or used in a packet is loop-free. > >==> as pointed above, this puts quite much trust on the sender's cache >data/cache being up-to-date. A normal security procedure would be to >verify received loop-freeness, but here normal security procedures might >not apply... No, it doesn't. You pick a route for the packet. You include the route in the packet. That route is loop-free, regardless of whether or not your cache is up-to-date. I also don't see why you couldn't verify loop-freedom if you really cared. If an address appears twice in the source route, then you've found a loop? >5. DSR Header Format > > To add a DSR header to a packet, the DSR header is inserted following > the packet's IP header, before any following header such as a > traditional (e.g., TCP or UDP) transport layer header. Specifically, > the Protocol field in the IP header is used to indicate that a DSR > header follows the IP header, and the Next Header field in the DSR > header is used to indicate the type of protocol header (such as a > transport layer header) following the DSR header. > >==> this has strong implications if packet filtering is perfomed. First, >almost all packets will be discarded unless the packet filter/firewall >supports DSR header processing and has some extra semantics on how to >proceed past the first, DSR header. This is similar to issues associated >with IPv6 packet filtering.. True, but that same firewall would also have to support DSR routing to know the next hop, just like the same firewall would have to support IPv6 routing. >6.2.2. Processing a Received Route Request Option > >- [...] If the node does > not receive a Reply within some reasonable amount of time, MUST > silently discard the Route Request packet. > >==> perhaps this should be defined more precisely? Agreed. > o If the node does not return a cached Route Reply, then this > node SHOULD link-layer re-broadcast this copy of the packet, > with a short jitter delay before the broadcast is sent. The > jitter period SHOULD be chosen as a random period, uniformly > distributed between 0 and BroadcastJitter. > >==> is it required that all possible media should support link-layer >broadcasts? How else do you do neighbor discovery? This seems like it should be taken up as a manet-wide issue. >6.3.6. Salvaging a Packet > > When an intermediate node forwarding a packet detects through Route > Maintenance that the next-hop link along the route for that packet is > broken (Section 6.3), if the node has another route to the packet's > IP Destination Address in its Route Cache, the node SHOULD "salvage" > the packet rather than discarding it. > >==> s/discarding/discard/ ? ? This is in the present tense; if I were to say "the node SHOULD discard the packet rather than salvage it," that doesn't sound quite right. >11. Security Considerations > >==> nodes feeding wrong (out-of-date) information, acting by their best >knowledge? What's the attacker model? Legitimate nodes failing in Byzantine ways? Multiple coordinated attackers with several compromised nodes? We specify that security considerations are out-of-scope, as in BGP (RFC1771). Security in manets are an active area of research... >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun Apr 7 21:09:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03029 for ; Sun, 7 Apr 2002 21:09:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA17873 for manet-archive@odin.ietf.org; Sun, 7 Apr 2002 21:09:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16406; Sun, 7 Apr 2002 20:40:30 -0400 (EDT) Received: from orval (celis.cs.rice.edu [128.42.6.83]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id UAA16366 for manet@ietf.org; Sun, 7 Apr 2002 20:39:23 -0400 (EDT) Date: Sun, 7 Apr 2002 20:27:36 -0400 (EDT) From: Yih-Chun Hu To: Pekka Savola cc: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, Thanks for your comments. >- I'm a bit unsure what happens if a packet which has a DSR header but >also has piggybacked data is in send/maintenance queue. Is this possible? >These could in some cases perhaps lead to data being delivered more than >once to the destination. I guess I don't see how that (multiple data delivery) might happen. Obviously it's possible with salvaging, since you might not get the ACK even when the data gets through, but any local repair mechanism might have this problem. Even if it were to happen, we'd still be compliant with the semantics of IP... >- I didn't get a good picture which DSR options can be seen in the same >DSR header and which not. Also, as sections in chapter 5 list what IP >header fields would look like when there are multiple options in a packet, >the multi-option combinations seem to be less covered than their full >counterparts. Maybe we could point out in the draft which types could legally be present. Perhaps I don't understand the concern, since the concept is that anything can be piggybacked in anything. >1. Introduction > >[...] Each data packet sent then carries in its header the > complete, ordered list of nodes through which the packet will pass, > allowing packet routing to be trivially loop-free and avoiding the > need for up-to-date routing information in the intermediate nodes > through which the packet is forwarded. [...] > >==> the need for up-to-date information may not necessarily be a bad >thing. Now the sources are in charge of that. Moreover, the sources are >also in charge of the whole network, as their source routes will be cached >and used for other communications. > >This is quite effective, but can be very dangerous in case of e.g. >implementation bugs, unforeseen problems (e.g. a source getting out of >sync, and "competing with the cache" with the rest of manet nodes) and >such: one node can pretty much wreck the whole routing fabric without even >trying hard. The need for up-to-date information at each intermediate node is problematic, for example, if nodes turn themselves off periodically, effectively rebooting. Such nodes would not have state consistant with the rest of the network, and in certain routing protocols, this could cause routing loops. I just don't see how you could ever get a routing loop in DSR. Your cache determines the routes you add to packets. Those routes MUST be loop-free, since they're finite length, and include a current-address, which is monotone increasing. Since each packet carries its own route, it's route is entirely determined by the (by definition consistant) state at the sender, and no other node's state. >[...] For > example, DSR does not use any periodic routing advertisement, link > status sensing, or neighbor detection packets, and does not rely on > these functions from any underlying protocols in the network. This > entirely on-demand behavior and lack of periodic activity allows > the number of overhead packets caused by DSR to scale all the way > down to zero, [...] > >==> I see DSR header functions rather equivalent to link status sensing >(maintenance procedures, Send Queue, etc.) and others above. And they're all on-demand (not periodic). Maybe I don't understand what you're trying to say? > > In response to a single Route Discovery (as well as through routing > information from other packets overheard), a node may learn and cache > multiple routes to any destination. > >==> just a trivial comment: cache management strategies will be quite >critical. Very true. We recommend a specific cache management scheme, called Link-MaxLife. >3.1. Basic DSR Route Discovery > > Node E could instead simply reverse the sequence of hops in the route > record that it is trying to send in the Route Reply, and use this as > the source route on the packet carrying the Route Reply itself. For > MAC protocols such as IEEE 802.11 that require a bidirectional frame > exchange as part of the MAC protocol [11], the discovered source > route MUST be reversed in this way to return the Route Reply since it > tests the discovered route to ensure it is bidirectional before the > Route Discovery initiator begins using the route; this route reversal > also avoids the overhead of a possible second Route Discovery. > >==> This (and various other places in the text, e.g. Appendix A) assumes >that the link-layer technology, at least from the point of view of >directionality, must be the same all over the manet, or at least all manet >nodes know the directionality of each device. Not manet-wide. Yes, for your own interfaces, but this is flexibility over most existing manet routing protocols, which require bidirectionality at all interfaces. When you put in the special addresses indicating a bidirectionality switch, the receivers know the directionality of their receive interface, and can deduce which parts of a source route must be bidirectional and which ones can have unidirectional links. For example, when the route A->B->*->C->D->*->E is received at D, it knows whether it's interface is bidirectional or unidirectional. If it's unidirectional, it knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t out a bidirectional interface, it adds a * to the source route first. >This seems a rather big aasumption. It seems rather smaller than assuming that all interfaces are bidirectional. I don't really want to belabor this point, because I don't think DSR's unidirectional support is very well tuned, and because the commodity standard for wireless interfaces these days is 802.11, which does require bidirectionality. > When initiating a Route Discovery, the sending node saves a copy of > the original packet (that triggered the Discovery) in a local buffer > called the "Send Buffer". > >==> might this create extra delays in the case of Route Discoveries >failing too (e.g. link failure, no manet nodes/AP's temporarily in range, >...) ? Yes, that's the price you pay for an on-demand protocol. Discovery can fail. You may have to wait. AODV, ZRP, SSA, ABR, ... all share this problem. >4.1. Route Cache > > - In DSR, the route returned in each Route Reply that is received > by the initiator of a Route Discovery (or that is learned from > the header of overhead packets, as described in Section 6.1.4) > represents a complete path (a sequence of links) leading to the > destination node. By caching each of these paths separately, > a "path cache" organization for the Route Cache can be formed. > A path cache is very simple to implement and easily guarantees > that all routes are loop-free, since each individual route from > a Route Reply or Route Request or used in a packet is loop-free. > >==> as pointed above, this puts quite much trust on the sender's cache >data/cache being up-to-date. A normal security procedure would be to >verify received loop-freeness, but here normal security procedures might >not apply... No, it doesn't. You pick a route for the packet. You include the route in the packet. That route is loop-free, regardless of whether or not your cache is up-to-date. I also don't see why you couldn't verify loop-freedom if you really cared. If an address appears twice in the source route, then you've found a loop? >5. DSR Header Format > > To add a DSR header to a packet, the DSR header is inserted following > the packet's IP header, before any following header such as a > traditional (e.g., TCP or UDP) transport layer header. Specifically, > the Protocol field in the IP header is used to indicate that a DSR > header follows the IP header, and the Next Header field in the DSR > header is used to indicate the type of protocol header (such as a > transport layer header) following the DSR header. > >==> this has strong implications if packet filtering is perfomed. First, >almost all packets will be discarded unless the packet filter/firewall >supports DSR header processing and has some extra semantics on how to >proceed past the first, DSR header. This is similar to issues associated >with IPv6 packet filtering.. True, but that same firewall would also have to support DSR routing to know the next hop, just like the same firewall would have to support IPv6 routing. >6.2.2. Processing a Received Route Request Option > >- [...] If the node does > not receive a Reply within some reasonable amount of time, MUST > silently discard the Route Request packet. > >==> perhaps this should be defined more precisely? Agreed. > o If the node does not return a cached Route Reply, then this > node SHOULD link-layer re-broadcast this copy of the packet, > with a short jitter delay before the broadcast is sent. The > jitter period SHOULD be chosen as a random period, uniformly > distributed between 0 and BroadcastJitter. > >==> is it required that all possible media should support link-layer >broadcasts? How else do you do neighbor discovery? This seems like it should be taken up as a manet-wide issue. >6.3.6. Salvaging a Packet > > When an intermediate node forwarding a packet detects through Route > Maintenance that the next-hop link along the route for that packet is > broken (Section 6.3), if the node has another route to the packet's > IP Destination Address in its Route Cache, the node SHOULD "salvage" > the packet rather than discarding it. > >==> s/discarding/discard/ ? ? This is in the present tense; if I were to say "the node SHOULD discard the packet rather than salvage it," that doesn't sound quite right. >11. Security Considerations > >==> nodes feeding wrong (out-of-date) information, acting by their best >knowledge? What's the attacker model? Legitimate nodes failing in Byzantine ways? Multiple coordinated attackers with several compromised nodes? We specify that security considerations are out-of-scope, as in BGP (RFC1771). Security in manets are an active area of research... >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 8 03:19:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16748 for ; Mon, 8 Apr 2002 03:19:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12709; Mon, 8 Apr 2002 02:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12682 for ; Mon, 8 Apr 2002 02:43:11 -0400 (EDT) Received: from web21208.mail.yahoo.com (web21208.mail.yahoo.com [216.136.175.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16327 for ; Mon, 8 Apr 2002 02:43:08 -0400 (EDT) Message-ID: <20020408064310.70438.qmail@web21208.mail.yahoo.com> Received: from [203.124.236.41] by web21208.mail.yahoo.com via HTTP; Sun, 07 Apr 2002 23:43:10 PDT Date: Sun, 7 Apr 2002 23:43:10 -0700 (PDT) From: Mohammed Mehkri To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Help Please Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Help please -- Is there any way to set TCP Window size and packet size in Glomosim? How do you get to know about the throughput at the destination every second? I need dimensions of about 1400 m, but I can view only 1000m in SImulation viewer, How do I increase the scale? Thanx M H M __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Apr 8 03:19:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16758 for ; Mon, 8 Apr 2002 03:19:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA14873 for manet-archive@odin.ietf.org; Mon, 8 Apr 2002 03:19:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12709; Mon, 8 Apr 2002 02:43:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12682 for ; Mon, 8 Apr 2002 02:43:11 -0400 (EDT) Received: from web21208.mail.yahoo.com (web21208.mail.yahoo.com [216.136.175.166]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16327 for ; Mon, 8 Apr 2002 02:43:08 -0400 (EDT) Message-ID: <20020408064310.70438.qmail@web21208.mail.yahoo.com> Received: from [203.124.236.41] by web21208.mail.yahoo.com via HTTP; Sun, 07 Apr 2002 23:43:10 PDT Date: Sun, 7 Apr 2002 23:43:10 -0700 (PDT) From: Mohammed Mehkri To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Help Please Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Help please -- Is there any way to set TCP Window size and packet size in Glomosim? How do you get to know about the throughput at the destination every second? I need dimensions of about 1400 m, but I can view only 1000m in SImulation viewer, How do I increase the scale? Thanx M H M __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 8 03:47:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17186 for ; Mon, 8 Apr 2002 03:47:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14652; Mon, 8 Apr 2002 03:16:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14622 for ; Mon, 8 Apr 2002 03:16:45 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16697 for ; Mon, 8 Apr 2002 03:16:41 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g387G2U14074; Mon, 8 Apr 2002 10:16:03 +0300 Date: Mon, 8 Apr 2002 10:16:02 +0300 (EEST) From: Pekka Savola To: Yih-Chun Hu cc: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, Additional comment I just noticed: 'ACK Destination Address' in Acknowledgment DSR Option seemed redundant to me, as the dstaddr in IP header seems to serve exactly the same purpose. Did I miss something? I'll respond to some issues below. On Sun, 7 Apr 2002, Yih-Chun Hu wrote: > >- I didn't get a good picture which DSR options can be seen in the same > >DSR header and which not. Also, as sections in chapter 5 list what IP > >header fields would look like when there are multiple options in a packet, > >the multi-option combinations seem to be less covered than their full > >counterparts. > > Maybe we could point out in the draft which types could legally be > present. Perhaps I don't understand the concern, since the concept is that > anything can be piggybacked in anything. .. except for a few exceptions. I don't see a concern as such here, but a thing perhaps worth clarifying ("the usual DSR header combinations" or whatnot). > >1. Introduction > > > >[...] Each data packet sent then carries in its header the > > complete, ordered list of nodes through which the packet will pass, > > allowing packet routing to be trivially loop-free and avoiding the > > need for up-to-date routing information in the intermediate nodes > > through which the packet is forwarded. [...] > > > >==> the need for up-to-date information may not necessarily be a bad > >thing. Now the sources are in charge of that. Moreover, the sources are > >also in charge of the whole network, as their source routes will be cached > >and used for other communications. > > > >This is quite effective, but can be very dangerous in case of e.g. > >implementation bugs, unforeseen problems (e.g. a source getting out of > >sync, and "competing with the cache" with the rest of manet nodes) and > >such: one node can pretty much wreck the whole routing fabric without even > >trying hard. > > The need for up-to-date information at each intermediate node is > problematic, for example, if nodes turn themselves off periodically, > effectively rebooting. Such nodes would not have state consistant with the > rest of the network, and in certain routing protocols, this could cause > routing loops. > > I just don't see how you could ever get a routing loop in DSR. Your cache > determines the routes you add to packets. Those routes MUST be loop-free, > since they're finite length, and include a current-address, which is > monotone increasing. > > Since each packet carries its own route, it's route is entirely determined > by the (by definition consistant) state at the sender, and no other node's > state. The last paragraph is not entirely true: the route can be affected by e.g. an intermediate node salvaging the packet, right? The maximal salvage count does limit how many times this can happen, so this couldn't result in an endless loop, but quite often that's a tranistory state in regular protocols too. > >[...] For > > example, DSR does not use any periodic routing advertisement, link > > status sensing, or neighbor detection packets, and does not rely on > > these functions from any underlying protocols in the network. This > > entirely on-demand behavior and lack of periodic activity allows > > the number of overhead packets caused by DSR to scale all the way > > down to zero, [...] > > > >==> I see DSR header functions rather equivalent to link status sensing > >(maintenance procedures, Send Queue, etc.) and others above. > > And they're all on-demand (not periodic). Maybe I don't understand what > you're trying to say? Well, I just think that periodicity, as an "only" criterion, is not necessarily an usable on. DSR does similar things like periodic activity, with overhead in the form of DSR header, anyway -- at least when there is traffic on the wire (e.g. network acknowledgements in route maintenance). > >3.1. Basic DSR Route Discovery > > > > Node E could instead simply reverse the sequence of hops in the route > > record that it is trying to send in the Route Reply, and use this as > > the source route on the packet carrying the Route Reply itself. For > > MAC protocols such as IEEE 802.11 that require a bidirectional frame > > exchange as part of the MAC protocol [11], the discovered source > > route MUST be reversed in this way to return the Route Reply since it > > tests the discovered route to ensure it is bidirectional before the > > Route Discovery initiator begins using the route; this route reversal > > also avoids the overhead of a possible second Route Discovery. > > > >==> This (and various other places in the text, e.g. Appendix A) assumes > >that the link-layer technology, at least from the point of view of > >directionality, must be the same all over the manet, or at least all manet > >nodes know the directionality of each device. > > Not manet-wide. Yes, for your own interfaces, but this is flexibility over > most existing manet routing protocols, which require bidirectionality at > all interfaces. See below. > When you put in the special addresses indicating a > bidirectionality switch, the receivers know the directionality of their > receive interface, and can deduce which parts of a source route must be > bidirectional and which ones can have unidirectional links. I have a failure to grasp this. Do you mean that addressing could be used to indicate bidirectionality? Well, this is one approach, but I don't recall this in the draft? > For example, > when the route A->B->*->C->D->*->E is received at D, it knows whether it's > interface is bidirectional or unidirectional. If it's unidirectional, it > knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t > out a bidirectional interface, it adds a * to the source route first. I'm not sure what you mean '*' here, so my comment may not be off the mark. I fail to see how D could conclude anything of A->B or B->C based on the bidirectionality of its own link? (Except if it knows the directionality based on addresses or similar, but that's one approach I was implicitly suggesting.) > >This seems a rather big aasumption. > > It seems rather smaller than assuming that all interfaces are > bidirectional. I disagree, on practical terms: it is a rather big assumption *when* one feature of DSR is exactly unidirectionality. If there is support, the support should work. If there is no support, people who have this as a requirement use different protocols. > I don't really want to belabor this point, because I don't > think DSR's unidirectional support is very well tuned, and because the > commodity standard for wireless interfaces these days is 802.11, which > does require bidirectionality. If this is a practical "non-issue", I wonder if it would make sense to try to define the main DSR proposal as bidirectional, and move unidirectional parts to a separate draft. > >4.1. Route Cache > > > > - In DSR, the route returned in each Route Reply that is received > > by the initiator of a Route Discovery (or that is learned from > > the header of overhead packets, as described in Section 6.1.4) > > represents a complete path (a sequence of links) leading to the > > destination node. By caching each of these paths separately, > > a "path cache" organization for the Route Cache can be formed. > > A path cache is very simple to implement and easily guarantees > > that all routes are loop-free, since each individual route from > > a Route Reply or Route Request or used in a packet is loop-free. > > > >==> as pointed above, this puts quite much trust on the sender's cache > >data/cache being up-to-date. A normal security procedure would be to > >verify received loop-freeness, but here normal security procedures might > >not apply... > > No, it doesn't. You pick a route for the packet. You include the route in > the packet. That route is loop-free, regardless of whether or not your > cache is up-to-date. > > I also don't see why you couldn't verify loop-freedom if you really cared. > If an address appears twice in the source route, then you've found a loop? True, for "loop-freeness" in the traditional meaning. If one includes "inserting too long, very suboptimal paths, which do not have a loop", this would be more difficult to verify. But I'm not sure of the threat model of this; my main worry was that if a source knows a sub-optimal path, and that path will be cached on intermediate nodes too, and that way it might be propagated to all nodes querying for that destination (replies from the cache). I'm not all that worried (except for severe implementation bugs) about loopfreeness as such, but rather unoptimal paths (which may be "almost loops") getting there. > >5. DSR Header Format > > > > To add a DSR header to a packet, the DSR header is inserted following > > the packet's IP header, before any following header such as a > > traditional (e.g., TCP or UDP) transport layer header. Specifically, > > the Protocol field in the IP header is used to indicate that a DSR > > header follows the IP header, and the Next Header field in the DSR > > header is used to indicate the type of protocol header (such as a > > transport layer header) following the DSR header. > > > >==> this has strong implications if packet filtering is perfomed. First, > >almost all packets will be discarded unless the packet filter/firewall > >supports DSR header processing and has some extra semantics on how to > >proceed past the first, DSR header. This is similar to issues associated > >with IPv6 packet filtering.. > > True, but that same firewall would also have to support DSR routing to > know the next hop, just like the same firewall would have to support IPv6 > routing. The firewall could also work in a bridging mode (which is a bit more rare, but we use one too), but you're right. I'd add a note in security considerations about this at least, though, because supporting DSR routing and supporting DSR header in the firewall software are two rather separate issues, and the connection may not be apparent. > >6.3.6. Salvaging a Packet > > > > When an intermediate node forwarding a packet detects through Route > > Maintenance that the next-hop link along the route for that packet is > > broken (Section 6.3), if the node has another route to the packet's > > IP Destination Address in its Route Cache, the node SHOULD "salvage" > > the packet rather than discarding it. > > > >==> s/discarding/discard/ ? > > ? This is in the present tense; if I were to say "the node SHOULD discard > the packet rather than salvage it," that doesn't sound quite right. I was suggesting like: 'the node SHOULD "salvage" the packet rather than discard it.' , because I find using the -ing form of the verb unnatural here when "salvage" does not use that. But I'm not a native speaker, so you're probably right if it sounds better. > >11. Security Considerations > > > >==> nodes feeding wrong (out-of-date) information, acting by their best > >knowledge? > > What's the attacker model? Legitimate nodes failing in Byzantine ways? > Multiple coordinated attackers with several compromised nodes? We specify > that security considerations are out-of-scope, as in BGP (RFC1771). > Security in manets are an active area of research... The attackers have many models, most of which are out of scope here, especially if one wants byzantine robustness in the case of a captured node feeding deliberately wrong information. One particular scenario I mentioned here was that a node that has old cached data keeps propagating that information to nodes which do route requests through it. Or salvage packets in non-optimal ways. This could lead to a security problem (denial of service). But perhaps this "cache freshness ensurance problem" needs to be addressed elsewhere. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Apr 8 03:47:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17200 for ; Mon, 8 Apr 2002 03:47:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16394 for manet-archive@odin.ietf.org; Mon, 8 Apr 2002 03:48:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14652; Mon, 8 Apr 2002 03:16:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14622 for ; Mon, 8 Apr 2002 03:16:45 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16697 for ; Mon, 8 Apr 2002 03:16:41 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g387G2U14074; Mon, 8 Apr 2002 10:16:03 +0300 Date: Mon, 8 Apr 2002 10:16:02 +0300 (EEST) From: Pekka Savola To: Yih-Chun Hu cc: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, Additional comment I just noticed: 'ACK Destination Address' in Acknowledgment DSR Option seemed redundant to me, as the dstaddr in IP header seems to serve exactly the same purpose. Did I miss something? I'll respond to some issues below. On Sun, 7 Apr 2002, Yih-Chun Hu wrote: > >- I didn't get a good picture which DSR options can be seen in the same > >DSR header and which not. Also, as sections in chapter 5 list what IP > >header fields would look like when there are multiple options in a packet, > >the multi-option combinations seem to be less covered than their full > >counterparts. > > Maybe we could point out in the draft which types could legally be > present. Perhaps I don't understand the concern, since the concept is that > anything can be piggybacked in anything. .. except for a few exceptions. I don't see a concern as such here, but a thing perhaps worth clarifying ("the usual DSR header combinations" or whatnot). > >1. Introduction > > > >[...] Each data packet sent then carries in its header the > > complete, ordered list of nodes through which the packet will pass, > > allowing packet routing to be trivially loop-free and avoiding the > > need for up-to-date routing information in the intermediate nodes > > through which the packet is forwarded. [...] > > > >==> the need for up-to-date information may not necessarily be a bad > >thing. Now the sources are in charge of that. Moreover, the sources are > >also in charge of the whole network, as their source routes will be cached > >and used for other communications. > > > >This is quite effective, but can be very dangerous in case of e.g. > >implementation bugs, unforeseen problems (e.g. a source getting out of > >sync, and "competing with the cache" with the rest of manet nodes) and > >such: one node can pretty much wreck the whole routing fabric without even > >trying hard. > > The need for up-to-date information at each intermediate node is > problematic, for example, if nodes turn themselves off periodically, > effectively rebooting. Such nodes would not have state consistant with the > rest of the network, and in certain routing protocols, this could cause > routing loops. > > I just don't see how you could ever get a routing loop in DSR. Your cache > determines the routes you add to packets. Those routes MUST be loop-free, > since they're finite length, and include a current-address, which is > monotone increasing. > > Since each packet carries its own route, it's route is entirely determined > by the (by definition consistant) state at the sender, and no other node's > state. The last paragraph is not entirely true: the route can be affected by e.g. an intermediate node salvaging the packet, right? The maximal salvage count does limit how many times this can happen, so this couldn't result in an endless loop, but quite often that's a tranistory state in regular protocols too. > >[...] For > > example, DSR does not use any periodic routing advertisement, link > > status sensing, or neighbor detection packets, and does not rely on > > these functions from any underlying protocols in the network. This > > entirely on-demand behavior and lack of periodic activity allows > > the number of overhead packets caused by DSR to scale all the way > > down to zero, [...] > > > >==> I see DSR header functions rather equivalent to link status sensing > >(maintenance procedures, Send Queue, etc.) and others above. > > And they're all on-demand (not periodic). Maybe I don't understand what > you're trying to say? Well, I just think that periodicity, as an "only" criterion, is not necessarily an usable on. DSR does similar things like periodic activity, with overhead in the form of DSR header, anyway -- at least when there is traffic on the wire (e.g. network acknowledgements in route maintenance). > >3.1. Basic DSR Route Discovery > > > > Node E could instead simply reverse the sequence of hops in the route > > record that it is trying to send in the Route Reply, and use this as > > the source route on the packet carrying the Route Reply itself. For > > MAC protocols such as IEEE 802.11 that require a bidirectional frame > > exchange as part of the MAC protocol [11], the discovered source > > route MUST be reversed in this way to return the Route Reply since it > > tests the discovered route to ensure it is bidirectional before the > > Route Discovery initiator begins using the route; this route reversal > > also avoids the overhead of a possible second Route Discovery. > > > >==> This (and various other places in the text, e.g. Appendix A) assumes > >that the link-layer technology, at least from the point of view of > >directionality, must be the same all over the manet, or at least all manet > >nodes know the directionality of each device. > > Not manet-wide. Yes, for your own interfaces, but this is flexibility over > most existing manet routing protocols, which require bidirectionality at > all interfaces. See below. > When you put in the special addresses indicating a > bidirectionality switch, the receivers know the directionality of their > receive interface, and can deduce which parts of a source route must be > bidirectional and which ones can have unidirectional links. I have a failure to grasp this. Do you mean that addressing could be used to indicate bidirectionality? Well, this is one approach, but I don't recall this in the draft? > For example, > when the route A->B->*->C->D->*->E is received at D, it knows whether it's > interface is bidirectional or unidirectional. If it's unidirectional, it > knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t > out a bidirectional interface, it adds a * to the source route first. I'm not sure what you mean '*' here, so my comment may not be off the mark. I fail to see how D could conclude anything of A->B or B->C based on the bidirectionality of its own link? (Except if it knows the directionality based on addresses or similar, but that's one approach I was implicitly suggesting.) > >This seems a rather big aasumption. > > It seems rather smaller than assuming that all interfaces are > bidirectional. I disagree, on practical terms: it is a rather big assumption *when* one feature of DSR is exactly unidirectionality. If there is support, the support should work. If there is no support, people who have this as a requirement use different protocols. > I don't really want to belabor this point, because I don't > think DSR's unidirectional support is very well tuned, and because the > commodity standard for wireless interfaces these days is 802.11, which > does require bidirectionality. If this is a practical "non-issue", I wonder if it would make sense to try to define the main DSR proposal as bidirectional, and move unidirectional parts to a separate draft. > >4.1. Route Cache > > > > - In DSR, the route returned in each Route Reply that is received > > by the initiator of a Route Discovery (or that is learned from > > the header of overhead packets, as described in Section 6.1.4) > > represents a complete path (a sequence of links) leading to the > > destination node. By caching each of these paths separately, > > a "path cache" organization for the Route Cache can be formed. > > A path cache is very simple to implement and easily guarantees > > that all routes are loop-free, since each individual route from > > a Route Reply or Route Request or used in a packet is loop-free. > > > >==> as pointed above, this puts quite much trust on the sender's cache > >data/cache being up-to-date. A normal security procedure would be to > >verify received loop-freeness, but here normal security procedures might > >not apply... > > No, it doesn't. You pick a route for the packet. You include the route in > the packet. That route is loop-free, regardless of whether or not your > cache is up-to-date. > > I also don't see why you couldn't verify loop-freedom if you really cared. > If an address appears twice in the source route, then you've found a loop? True, for "loop-freeness" in the traditional meaning. If one includes "inserting too long, very suboptimal paths, which do not have a loop", this would be more difficult to verify. But I'm not sure of the threat model of this; my main worry was that if a source knows a sub-optimal path, and that path will be cached on intermediate nodes too, and that way it might be propagated to all nodes querying for that destination (replies from the cache). I'm not all that worried (except for severe implementation bugs) about loopfreeness as such, but rather unoptimal paths (which may be "almost loops") getting there. > >5. DSR Header Format > > > > To add a DSR header to a packet, the DSR header is inserted following > > the packet's IP header, before any following header such as a > > traditional (e.g., TCP or UDP) transport layer header. Specifically, > > the Protocol field in the IP header is used to indicate that a DSR > > header follows the IP header, and the Next Header field in the DSR > > header is used to indicate the type of protocol header (such as a > > transport layer header) following the DSR header. > > > >==> this has strong implications if packet filtering is perfomed. First, > >almost all packets will be discarded unless the packet filter/firewall > >supports DSR header processing and has some extra semantics on how to > >proceed past the first, DSR header. This is similar to issues associated > >with IPv6 packet filtering.. > > True, but that same firewall would also have to support DSR routing to > know the next hop, just like the same firewall would have to support IPv6 > routing. The firewall could also work in a bridging mode (which is a bit more rare, but we use one too), but you're right. I'd add a note in security considerations about this at least, though, because supporting DSR routing and supporting DSR header in the firewall software are two rather separate issues, and the connection may not be apparent. > >6.3.6. Salvaging a Packet > > > > When an intermediate node forwarding a packet detects through Route > > Maintenance that the next-hop link along the route for that packet is > > broken (Section 6.3), if the node has another route to the packet's > > IP Destination Address in its Route Cache, the node SHOULD "salvage" > > the packet rather than discarding it. > > > >==> s/discarding/discard/ ? > > ? This is in the present tense; if I were to say "the node SHOULD discard > the packet rather than salvage it," that doesn't sound quite right. I was suggesting like: 'the node SHOULD "salvage" the packet rather than discard it.' , because I find using the -ing form of the verb unnatural here when "salvage" does not use that. But I'm not a native speaker, so you're probably right if it sounds better. > >11. Security Considerations > > > >==> nodes feeding wrong (out-of-date) information, acting by their best > >knowledge? > > What's the attacker model? Legitimate nodes failing in Byzantine ways? > Multiple coordinated attackers with several compromised nodes? We specify > that security considerations are out-of-scope, as in BGP (RFC1771). > Security in manets are an active area of research... The attackers have many models, most of which are out of scope here, especially if one wants byzantine robustness in the case of a captured node feeding deliberately wrong information. One particular scenario I mentioned here was that a node that has old cached data keeps propagating that information to nodes which do route requests through it. Or salvage packets in non-optimal ways. This could lead to a security problem (denial of service). But perhaps this "cache freshness ensurance problem" needs to be addressed elsewhere. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 8 09:38:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23211 for ; Mon, 8 Apr 2002 09:38:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02987; Mon, 8 Apr 2002 09:11:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02958 for ; Mon, 8 Apr 2002 09:11:37 -0400 (EDT) Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22451 for ; Mon, 8 Apr 2002 09:11:34 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id C3423640F2 for ; Mon, 8 Apr 2002 09:11:06 -0400 (EDT) Received: from doldham.lerc.nasa.gov (doldham.lerc.nasa.gov [139.88.102.106]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA17264 for ; Mon, 8 Apr 2002 09:11:06 -0400 (EDT) From: Daniel Oldham Date: Mon, 08 Apr 2002 13:11:13 GMT Message-ID: <20020408.13111300@doldham.lerc.nasa.gov> To: manet@ietf.org X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA02959 Subject: [manet] question on satellites in random orbits Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Fred: I read your paper "An outsider's view of MANET" and was wondering what is "to the behavior of satellites in random orbits"? All satellites seem to have well defined orbits. They use the principles of the two body equations with six orbital parameters to define their exact orbits. If you pick any two satellites in different orbits they repeat cycles after a period of time. There does not seem to be anything random about them. Would you please explain? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 8 09:38:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23221 for ; Mon, 8 Apr 2002 09:38:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05112 for manet-archive@odin.ietf.org; Mon, 8 Apr 2002 09:38:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02987; Mon, 8 Apr 2002 09:11:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02958 for ; Mon, 8 Apr 2002 09:11:37 -0400 (EDT) Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22451 for ; Mon, 8 Apr 2002 09:11:34 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id C3423640F2 for ; Mon, 8 Apr 2002 09:11:06 -0400 (EDT) Received: from doldham.lerc.nasa.gov (doldham.lerc.nasa.gov [139.88.102.106]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA17264 for ; Mon, 8 Apr 2002 09:11:06 -0400 (EDT) From: Daniel Oldham Date: Mon, 08 Apr 2002 13:11:13 GMT Message-ID: <20020408.13111300@doldham.lerc.nasa.gov> To: manet@ietf.org X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA02959 Subject: [manet] question on satellites in random orbits Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Fred: I read your paper "An outsider's view of MANET" and was wondering what is "to the behavior of satellites in random orbits"? All satellites seem to have well defined orbits. They use the principles of the two body equations with six orbital parameters to define their exact orbits. If you pick any two satellites in different orbits they repeat cycles after a period of time. There does not seem to be anything random about them. Would you please explain? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 8 10:25:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24914 for ; Mon, 8 Apr 2002 10:25:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06243; Mon, 8 Apr 2002 09:58:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06217 for ; Mon, 8 Apr 2002 09:58:17 -0400 (EDT) Received: from mail.fastwebnet.it (relay-1.fastweb.it [213.140.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23784 for ; Mon, 8 Apr 2002 09:58:14 -0400 (EDT) Received: from SARCIDIA (1.255.10.121) by mail.fastwebnet.it (6.0.040) id 3CAC1CE00005BA73 for manet@ietf.org; Mon, 8 Apr 2002 15:57:38 +0200 Message-ID: <001801c1df05$5ba9cdd0$790aff01@SARCIDIA> From: "samantha" To: Date: Mon, 8 Apr 2002 15:57:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C1DF16.1EE31E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] request for documentation about scatternet Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C1DF16.1EE31E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, i'm a Ph.D. student from Information Tecnology Department of Milan. I was looking for some documentations about scatternet formation and = routing. Could someone signal to me some links or documents about that? Thanks ------=_NextPart_000_0015_01C1DF16.1EE31E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
i'm a Ph.D.=20 student from Information Tecnology Department of = Milan.
I was looking for some documentations about scatternet formation = and=20 routing.
Could someone signal to me some links or documents about = that?
Thanks
 
------=_NextPart_000_0015_01C1DF16.1EE31E40-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 8 10:25:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24924 for ; Mon, 8 Apr 2002 10:25:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09035 for manet-archive@odin.ietf.org; Mon, 8 Apr 2002 10:25:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06243; Mon, 8 Apr 2002 09:58:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06217 for ; Mon, 8 Apr 2002 09:58:17 -0400 (EDT) Received: from mail.fastwebnet.it (relay-1.fastweb.it [213.140.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23784 for ; Mon, 8 Apr 2002 09:58:14 -0400 (EDT) Received: from SARCIDIA (1.255.10.121) by mail.fastwebnet.it (6.0.040) id 3CAC1CE00005BA73 for manet@ietf.org; Mon, 8 Apr 2002 15:57:38 +0200 Message-ID: <001801c1df05$5ba9cdd0$790aff01@SARCIDIA> From: "samantha" To: Date: Mon, 8 Apr 2002 15:57:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C1DF16.1EE31E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] request for documentation about scatternet Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C1DF16.1EE31E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, i'm a Ph.D. student from Information Tecnology Department of Milan. I was looking for some documentations about scatternet formation and = routing. Could someone signal to me some links or documents about that? Thanks ------=_NextPart_000_0015_01C1DF16.1EE31E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
i'm a Ph.D.=20 student from Information Tecnology Department of = Milan.
I was looking for some documentations about scatternet formation = and=20 routing.
Could someone signal to me some links or documents about = that?
Thanks
 
------=_NextPart_000_0015_01C1DF16.1EE31E40-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 8 10:49:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25838 for ; Mon, 8 Apr 2002 10:49:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08573; Mon, 8 Apr 2002 10:21:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08544 for ; Mon, 8 Apr 2002 10:21:26 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24731 for ; Mon, 8 Apr 2002 10:21:23 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g38ELFX08263; Mon, 8 Apr 2002 10:21:15 -0400 Date: Mon, 8 Apr 2002 10:21:10 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: samantha cc: manet@ietf.org Subject: Re: [manet] request for documentation about scatternet In-Reply-To: <001801c1df05$5ba9cdd0$790aff01@SARCIDIA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Samantha, Here is one of our reference on scatternet formation: Z. Wang, R.J. Thomas, and Z.J. Haas,"Bluenet - a New Scatternet Formation Scheme," 35th Hawaii International Conference on System Science (HICSS-35), Big Island, Hawaii, January 7-10, 2002 Please let me know if you need a soft copy. Best, Zygmunt. ==--=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Mon, 8 Apr 2002, samantha wrote: > hi, > i'm a Ph.D. student from Information Tecnology Department of Milan. > I was looking for some documentations about scatternet formation and routing. > Could someone signal to me some links or documents about that? > Thanks > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 8 10:49:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25852 for ; Mon, 8 Apr 2002 10:49:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11286 for manet-archive@odin.ietf.org; Mon, 8 Apr 2002 10:49:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08573; Mon, 8 Apr 2002 10:21:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08544 for ; Mon, 8 Apr 2002 10:21:26 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24731 for ; Mon, 8 Apr 2002 10:21:23 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g38ELFX08263; Mon, 8 Apr 2002 10:21:15 -0400 Date: Mon, 8 Apr 2002 10:21:10 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: samantha cc: manet@ietf.org Subject: Re: [manet] request for documentation about scatternet In-Reply-To: <001801c1df05$5ba9cdd0$790aff01@SARCIDIA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Samantha, Here is one of our reference on scatternet formation: Z. Wang, R.J. Thomas, and Z.J. Haas,"Bluenet - a New Scatternet Formation Scheme," 35th Hawaii International Conference on System Science (HICSS-35), Big Island, Hawaii, January 7-10, 2002 Please let me know if you need a soft copy. Best, Zygmunt. ==--=-===== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Mon, 8 Apr 2002, samantha wrote: > hi, > i'm a Ph.D. student from Information Tecnology Department of Milan. > I was looking for some documentations about scatternet formation and routing. > Could someone signal to me some links or documents about that? > Thanks > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 8 11:02:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26179 for ; Mon, 8 Apr 2002 11:02:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10780; Mon, 8 Apr 2002 10:43:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10751 for ; Mon, 8 Apr 2002 10:43:45 -0400 (EDT) Received: from techunix.technion.ac.il (techunix.technion.ac.il [132.68.1.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25603 for ; Mon, 8 Apr 2002 10:43:42 -0400 (EDT) Received: from tx.technion.ac.il (unknown [132.68.59.186]) by techunix.technion.ac.il (Postfix) with ESMTP id 7538F15383; Mon, 8 Apr 2002 17:43:44 +0300 (IDT) Message-ID: <3CB1BAB6.C0483613@tx.technion.ac.il> Date: Mon, 08 Apr 2002 17:43:50 +0200 From: Gil Zussman Organization: Technion X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: samantha Cc: manet@ietf.org Subject: Re: [manet] request for documentation about scatternet References: <001801c1df05$5ba9cdd0$790aff01@SARCIDIA> Content-Type: multipart/alternative; boundary="------------ACF11E27EC5D23F2A4E9A402" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------ACF11E27EC5D23F2A4E9A402 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Try the following link. They maintain a comprhensive list of publications. http://opensource.nus.edu.sg/projects/bluetooth/external.html Regards, Gil Zussman samantha wrote: > hi,i'm a Ph.D. student from Information Tecnology Department of > Milan.I was looking for some documentations about scatternet formation > and routing.Could someone signal to me some links or documents about > that?Thanks --------------ACF11E27EC5D23F2A4E9A402 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Try the following link. They maintain a comprhensive list of publications.

http://opensource.nus.edu.sg/projects/bluetooth/external.html

Regards,
Gil Zussman

samantha wrote:

hi,i'm a Ph.D. student from Information Tecnology Department of Milan.I was looking for some documentations about scatternet formation and routing.Could someone signal to me some links or documents about that?Thanks 
--------------ACF11E27EC5D23F2A4E9A402-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 8 11:02:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26189 for ; Mon, 8 Apr 2002 11:02:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12445 for manet-archive@odin.ietf.org; Mon, 8 Apr 2002 11:02:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10780; Mon, 8 Apr 2002 10:43:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10751 for ; Mon, 8 Apr 2002 10:43:45 -0400 (EDT) Received: from techunix.technion.ac.il (techunix.technion.ac.il [132.68.1.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25603 for ; Mon, 8 Apr 2002 10:43:42 -0400 (EDT) Received: from tx.technion.ac.il (unknown [132.68.59.186]) by techunix.technion.ac.il (Postfix) with ESMTP id 7538F15383; Mon, 8 Apr 2002 17:43:44 +0300 (IDT) Message-ID: <3CB1BAB6.C0483613@tx.technion.ac.il> Date: Mon, 08 Apr 2002 17:43:50 +0200 From: Gil Zussman Organization: Technion X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: samantha Cc: manet@ietf.org Subject: Re: [manet] request for documentation about scatternet References: <001801c1df05$5ba9cdd0$790aff01@SARCIDIA> Content-Type: multipart/alternative; boundary="------------ACF11E27EC5D23F2A4E9A402" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------ACF11E27EC5D23F2A4E9A402 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Try the following link. They maintain a comprhensive list of publications. http://opensource.nus.edu.sg/projects/bluetooth/external.html Regards, Gil Zussman samantha wrote: > hi,i'm a Ph.D. student from Information Tecnology Department of > Milan.I was looking for some documentations about scatternet formation > and routing.Could someone signal to me some links or documents about > that?Thanks --------------ACF11E27EC5D23F2A4E9A402 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Try the following link. They maintain a comprhensive list of publications.

http://opensource.nus.edu.sg/projects/bluetooth/external.html

Regards,
Gil Zussman

samantha wrote:

hi,i'm a Ph.D. student from Information Tecnology Department of Milan.I was looking for some documentations about scatternet formation and routing.Could someone signal to me some links or documents about that?Thanks 
--------------ACF11E27EC5D23F2A4E9A402-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 8 14:07:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01484 for ; Mon, 8 Apr 2002 14:07:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23914; Mon, 8 Apr 2002 13:31:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23857 for ; Mon, 8 Apr 2002 13:31:46 -0400 (EDT) Received: from sapo.pt (relay2.ptm.pt [194.65.79.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00557 for ; Mon, 8 Apr 2002 13:31:43 -0400 (EDT) Received: (qmail 17703 invoked from network); 8 Apr 2002 17:31:47 -0000 Received: from unknown (HELO sapo.pt) (194.65.79.63) by relay2.ptm.pt with SMTP; 8 Apr 2002 17:31:47 -0000 Received: (qmail 3522 invoked by alias); 8 Apr 2002 17:31:43 -0000 To: manet@ietf.org Message-ID: <1018287103.3cb1d3ff86911@webmail.sapo.pt> Date: Mon, 08 Apr 2002 18:31:43 +0100 (WEST) From: Paulo Fernando Viegas Nunes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: PT Multimedia Webmail program X-Originating-IP: 195.23.166.65 Content-Transfer-Encoding: 8bit Subject: [manet] Request for documentation about Military Networks Routing Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, I'm a Ph.D. student and I'm working on the use of MANETs in Military Tactical Networks, namely, in the routing area. I am looking for some documentations about this subjects. Could someone signal to me some links or documents about that? Thanks -------------------------------------------- Webmail da rede SAPO - http://webmail.sapo.pt/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 8 14:07:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01495 for ; Mon, 8 Apr 2002 14:07:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26424 for manet-archive@odin.ietf.org; Mon, 8 Apr 2002 14:07:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23914; Mon, 8 Apr 2002 13:31:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23857 for ; Mon, 8 Apr 2002 13:31:46 -0400 (EDT) Received: from sapo.pt (relay2.ptm.pt [194.65.79.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00557 for ; Mon, 8 Apr 2002 13:31:43 -0400 (EDT) Received: (qmail 17703 invoked from network); 8 Apr 2002 17:31:47 -0000 Received: from unknown (HELO sapo.pt) (194.65.79.63) by relay2.ptm.pt with SMTP; 8 Apr 2002 17:31:47 -0000 Received: (qmail 3522 invoked by alias); 8 Apr 2002 17:31:43 -0000 To: manet@ietf.org Message-ID: <1018287103.3cb1d3ff86911@webmail.sapo.pt> Date: Mon, 08 Apr 2002 18:31:43 +0100 (WEST) From: Paulo Fernando Viegas Nunes MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: PT Multimedia Webmail program X-Originating-IP: 195.23.166.65 Content-Transfer-Encoding: 8bit Subject: [manet] Request for documentation about Military Networks Routing Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, I'm a Ph.D. student and I'm working on the use of MANETs in Military Tactical Networks, namely, in the routing area. I am looking for some documentations about this subjects. Could someone signal to me some links or documents about that? Thanks -------------------------------------------- Webmail da rede SAPO - http://webmail.sapo.pt/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 8 16:14:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04997 for ; Mon, 8 Apr 2002 16:14:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02833; Mon, 8 Apr 2002 15:36:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20475 for ; Tue, 2 Apr 2002 18:00:16 -0500 (EST) Received: from stash.attlabs.att.com (mpfg.attlabs.net [12.106.35.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07005; Tue, 2 Apr 2002 18:00:12 -0500 (EST) Received: from stash.attlabs.att.com (localhost [127.0.0.1]) by stash.attlabs.att.com (8.12.2/8.12.2) with ESMTP id g32Mo9I2044819; Tue, 2 Apr 2002 14:50:09 -0800 (PST) (envelope-from fenner@stash.attlabs.att.com) Received: (from fenner@localhost) by stash.attlabs.att.com (8.12.2/8.12.2/Submit) id g32Mo757044817; Tue, 2 Apr 2002 14:50:07 -0800 (PST) Date: Tue, 2 Apr 2002 14:50:07 -0800 (PST) Message-Id: <200204022250.g32Mo757044817@stash.attlabs.att.com> To: routing-discussion@ietf.org From: Bill Fenner Subject: [manet] routing-discussion mailing list resurrected Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear Routing Area participants, Alex and I have resurrected the routing-discussion mailing list, routing-discussion@ietf.org (routing-discussion-request@ietf.org to subscribe, or https://www1.ietf.org/mailman/listinfo/routing-discussion). This list is intended for use for general routing area issues, especially routing-related items that cross multiple working groups or do not fall specifically within a given group's charter. It will also be used for cross-area coordination of routing issues. Please sign up for the list if you are interested. Thanks, Bill and Alex. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 8 16:14:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05019 for ; Mon, 8 Apr 2002 16:14:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07110 for manet-archive@odin.ietf.org; Mon, 8 Apr 2002 16:14:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02730; Mon, 8 Apr 2002 15:36:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07556 for ; Tue, 2 Apr 2002 14:30:05 -0500 (EST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29100 for ; Tue, 2 Apr 2002 14:30:02 -0500 (EST) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g32JTue16072; Tue, 2 Apr 2002 21:29:56 +0200 (CEST) Received: from h11n2fls31o848.telia.com (h11n2fls31o848.telia.com [213.67.152.11]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g32JTt115740; Tue, 2 Apr 2002 21:29:55 +0200 (CEST) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: MANET LIST , AODV Implementors list Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 Date: 02 Apr 2002 21:29:24 +0200 Message-Id: <1017775765.2549.120.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA07557 Subject: [manet] New version 0.3 of AODV-UU available! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Just a quick note that I just uploaded a new version of our GPL'd AODV implementation (AODV-UU) to our website. From the CHANGELOG: 0.3: * New timer code to fix obscure crashes (very stable now). * Multiple network interfaces support. * Fixed bug which caused some RERRs to not be sent. * HELLO message jittering. * Code is AODV-interop tested and verified. * Updated README. * New command line parsing, and options. * Added command line option to disable wait on reboot (maybe Manel will stop whining about the 15 secs delay now ;-). Download here: http://www.docs.uu.se/~henrikl/aodv/ Enjoy! Erik Nordström, Uppsala University. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 8 16:14:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05011 for ; Mon, 8 Apr 2002 16:14:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07099 for manet-archive@odin.ietf.org; Mon, 8 Apr 2002 16:14:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02833; Mon, 8 Apr 2002 15:36:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20475 for ; Tue, 2 Apr 2002 18:00:16 -0500 (EST) Received: from stash.attlabs.att.com (mpfg.attlabs.net [12.106.35.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07005; Tue, 2 Apr 2002 18:00:12 -0500 (EST) Received: from stash.attlabs.att.com (localhost [127.0.0.1]) by stash.attlabs.att.com (8.12.2/8.12.2) with ESMTP id g32Mo9I2044819; Tue, 2 Apr 2002 14:50:09 -0800 (PST) (envelope-from fenner@stash.attlabs.att.com) Received: (from fenner@localhost) by stash.attlabs.att.com (8.12.2/8.12.2/Submit) id g32Mo757044817; Tue, 2 Apr 2002 14:50:07 -0800 (PST) Date: Tue, 2 Apr 2002 14:50:07 -0800 (PST) Message-Id: <200204022250.g32Mo757044817@stash.attlabs.att.com> To: routing-discussion@ietf.org From: Bill Fenner Subject: [manet] routing-discussion mailing list resurrected Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear Routing Area participants, Alex and I have resurrected the routing-discussion mailing list, routing-discussion@ietf.org (routing-discussion-request@ietf.org to subscribe, or https://www1.ietf.org/mailman/listinfo/routing-discussion). This list is intended for use for general routing area issues, especially routing-related items that cross multiple working groups or do not fall specifically within a given group's charter. It will also be used for cross-area coordination of routing issues. Please sign up for the list if you are interested. Thanks, Bill and Alex. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 8 17:09:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05001 for ; Mon, 8 Apr 2002 16:14:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02730; Mon, 8 Apr 2002 15:36:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07556 for ; Tue, 2 Apr 2002 14:30:05 -0500 (EST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29100 for ; Tue, 2 Apr 2002 14:30:02 -0500 (EST) Received: from d1o848.telia.com (d1o848.telia.com [213.66.32.241]) by maile.telia.com (8.11.6/8.11.6) with ESMTP id g32JTue16072; Tue, 2 Apr 2002 21:29:56 +0200 (CEST) Received: from h11n2fls31o848.telia.com (h11n2fls31o848.telia.com [213.67.152.11]) by d1o848.telia.com (8.10.2/8.10.1) with ESMTP id g32JTt115740; Tue, 2 Apr 2002 21:29:55 +0200 (CEST) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: MANET LIST , AODV Implementors list Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 Date: 02 Apr 2002 21:29:24 +0200 Message-Id: <1017775765.2549.120.camel@Replicator> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA07557 Subject: [manet] New version 0.3 of AODV-UU available! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Just a quick note that I just uploaded a new version of our GPL'd AODV implementation (AODV-UU) to our website. From the CHANGELOG: 0.3: * New timer code to fix obscure crashes (very stable now). * Multiple network interfaces support. * Fixed bug which caused some RERRs to not be sent. * HELLO message jittering. * Code is AODV-interop tested and verified. * Updated README. * New command line parsing, and options. * Added command line option to disable wait on reboot (maybe Manel will stop whining about the 15 secs delay now ;-). Download here: http://www.docs.uu.se/~henrikl/aodv/ Enjoy! Erik Nordström, Uppsala University. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 9 21:30:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27250 for ; Tue, 9 Apr 2002 21:30:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02116; Tue, 9 Apr 2002 20:53:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02084 for ; Tue, 9 Apr 2002 20:53:18 -0400 (EDT) Received: from hotmail.com (f95.law11.hotmail.com [64.4.17.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26719 for ; Tue, 9 Apr 2002 20:53:16 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Apr 2002 17:52:48 -0700 Received: from 129.110.34.2 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 10 Apr 2002 00:52:47 GMT X-Originating-IP: [129.110.34.2] From: "meyyappan sv" To: manet@ietf.org Date: Wed, 10 Apr 2002 00:52:47 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Apr 2002 00:52:48.0054 (UTC) FILETIME=[08986D60:01C1E02A] Subject: [manet] Specifications Required Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi guys, Im simulating TSMA MAC protocol in OPNET. I want know the transmission power, bandwidth and transmission frequency normally used in ad hoc simualtions. Could someone please help me in this. meyyappan. University Of Texas at Dallas Richardson _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 9 21:30:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27260 for ; Tue, 9 Apr 2002 21:30:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA04017 for manet-archive@odin.ietf.org; Tue, 9 Apr 2002 21:30:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02116; Tue, 9 Apr 2002 20:53:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02084 for ; Tue, 9 Apr 2002 20:53:18 -0400 (EDT) Received: from hotmail.com (f95.law11.hotmail.com [64.4.17.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26719 for ; Tue, 9 Apr 2002 20:53:16 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Apr 2002 17:52:48 -0700 Received: from 129.110.34.2 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 10 Apr 2002 00:52:47 GMT X-Originating-IP: [129.110.34.2] From: "meyyappan sv" To: manet@ietf.org Date: Wed, 10 Apr 2002 00:52:47 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Apr 2002 00:52:48.0054 (UTC) FILETIME=[08986D60:01C1E02A] Subject: [manet] Specifications Required Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi guys, Im simulating TSMA MAC protocol in OPNET. I want know the transmission power, bandwidth and transmission frequency normally used in ad hoc simualtions. Could someone please help me in this. meyyappan. University Of Texas at Dallas Richardson _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 10 20:18:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05816 for ; Wed, 10 Apr 2002 20:18:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28241; Wed, 10 Apr 2002 19:55:21 -0400 (EDT) Received: from orval.cs.rice.edu (orval.cs.rice.edu [128.42.6.80]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id TAA28185 for manet@ietf.org; Wed, 10 Apr 2002 19:54:00 -0400 (EDT) Date: Wed, 10 Apr 2002 19:49:47 -0400 (EDT) From: Yih-Chun Hu To: Pekka Savola cc: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org >Additional comment I just noticed: 'ACK Destination Address' in >Acknowledgment DSR Option seemed redundant to me, as the dstaddr in IP >header seems to serve exactly the same purpose. Did I miss something? Yep, you can technically piggyback it on something. Same deal with Route Error Destination Addresses. >> Maybe we could point out in the draft which types could legally be >> present. Perhaps I don't understand the concern, since the concept is that >> anything can be piggybacked in anything. > >.. except for a few exceptions. I don't see a concern as such here, but a >thing perhaps worth clarifying ("the usual DSR header combinations" or >whatnot). I guess I should think very carefully about "the prohibited DSR header combinations." I don't know that there are any; even bizzare things like source-routed route requests could be interesting (route request up to a point, where you know the rest of the route from there, or source route a request out to a certain point, then blossom it from there). >> Since each packet carries its own route, it's route is entirely determined >> by the (by definition consistant) state at the sender, and no other node's >> state. > >The last paragraph is not entirely true: the route can be affected by e.g. >an intermediate node salvaging the packet, right? The maximal salvage >count does limit how many times this can happen, so this couldn't result >in an endless loop, but quite often that's a tranistory state in regular >protocols too. Granted. We could prohibit a path from ever looping, but that would also prohibit backtracking. We don't allow looping (same path over and over again); we allow backtracking. >> >==> I see DSR header functions rather equivalent to link status sensing >> >(maintenance procedures, Send Queue, etc.) and others above. >> >> And they're all on-demand (not periodic). Maybe I don't understand what >> you're trying to say? > >Well, I just think that periodicity, as an "only" criterion, is not >necessarily an usable on. DSR does similar things like periodic activity, >with overhead in the form of DSR header, anyway -- at least when there is >traffic on the wire (e.g. network acknowledgements in route maintenance). There are things that other protocols do periodically: neighbor sense, route discovery, route maintenance, etc. But it does them ONLY when there's traffic on the wire. We say these are performed "on-demand" as a characterization of their frequency and efficiency. We also argue why we think on-demand protocols may be better in certain situations. >> When you put in the special addresses indicating a >> bidirectionality switch, the receivers know the directionality of their >> receive interface, and can deduce which parts of a source route must be >> bidirectional and which ones can have unidirectional links. > >I have a failure to grasp this. Do you mean that addressing could be used >to indicate bidirectionality? Well, this is one approach, but I don't >recall this in the draft? Section 7. It's new in -07. (Sorry) >> For example, >> when the route A->B->*->C->D->*->E is received at D, it knows whether it's >> interface is bidirectional or unidirectional. If it's unidirectional, it >> knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t >> out a bidirectional interface, it adds a * to the source route first. > >I'm not sure what you mean '*' here, so my comment may not be off the >mark. I fail to see how D could conclude anything of A->B or B->C based >on the bidirectionality of its own link? (Except if it knows the >directionality based on addresses or similar, but that's one approach I >was implicitly suggesting.) * is a "magic" address. So, looking at a source route backwards E<-*<-D<-C<-*<-B<-A E knows that the directionality of the c->d segment is different from the directionality of the d->e segment. Similarly, c knows that the directionality of the a->b segment is different from the directionality of the b->c segment. >> >This seems a rather big aasumption. >> It seems rather smaller than assuming that all interfaces are >> bidirectional. >I disagree, on practical terms: it is a rather big assumption *when* one >feature of DSR is exactly unidirectionality. If there is support, the >support should work. If there is no support, people who have this as a >requirement use different protocols. Hmm. Well, since you have to write a driver for an interface, I don't think that's a huge assumption that you know the directionality of one of your interfaces. You'd need to know that to decide whether or not you could even use one of the other protocols. >> I don't really want to belabor this point, because I don't >> think DSR's unidirectional support is very well tuned, and because the >> commodity standard for wireless interfaces these days is 802.11, which >> does require bidirectionality. > >If this is a practical "non-issue", I wonder if it would make sense to try >to define the main DSR proposal as bidirectional, and move unidirectional >parts to a separate draft. That's an "I" as a person, not an "I" speaking on behalf of all draft authors. >> No, it doesn't. You pick a route for the packet. You include the route in >> the packet. That route is loop-free, regardless of whether or not your >> cache is up-to-date. >> >> I also don't see why you couldn't verify loop-freedom if you really cared. >> If an address appears twice in the source route, then you've found a loop? > >True, for "loop-freeness" in the traditional meaning. If one includes >"inserting too long, very suboptimal paths, which do not have a loop", >this would be more difficult to verify. > >But I'm not sure of the threat model of this; my main worry was that if a >source knows a sub-optimal path, and that path will be cached on >intermediate nodes too, and that way it might be propagated to all nodes >querying for that destination (replies from the cache). If you're worried about malicious nodes being "stupid" and using long routes, I can assure you that there are many worse things that could be used as attacks. Automatic Route Shortening helps reduce the length of stale, long routes. Promiscuous overhearing works pretty well too. We have yet to find a reason that drives us to periodic path discovery to ensure freshness. >I'm not all that worried (except for severe implementation bugs) about >loopfreeness as such, but rather unoptimal paths (which may be "almost >loops") getting there. Any on-demand protocol without a periodic rediscovery mechanism has the same problem; once you set up a route, you don't really bother to look for a better one. >I'd add a note in security considerations about this at least, though, >because supporting DSR routing and supporting DSR header in the firewall >software are two rather separate issues, and the connection may not be >apparent. That's a good idea. >> What's the attacker model? Legitimate nodes failing in Byzantine ways? >> Multiple coordinated attackers with several compromised nodes? We specify >> that security considerations are out-of-scope, as in BGP (RFC1771). >> Security in manets are an active area of research... > >The attackers have many models, most of which are out of scope here, >especially if one wants byzantine robustness in the case of a captured >node feeding deliberately wrong information. > >One particular scenario I mentioned here was that a node that has old >cached data keeps propagating that information to nodes which do route >requests through it. Or salvage packets in non-optimal ways. This could >lead to a security problem (denial of service). But perhaps this "cache >freshness ensurance problem" needs to be addressed elsewhere. You'd eventually get route errors that flush out your cache if you're returning bogus routes on requests. For example, suppose A has two disjoint bogus routes to B in its cache, and C does a discovery for B. A returns a bogus route, C uses it, B forwards the corresponding route error. Now A only has one disjoint bogus route. Also, with the cache specified in appendix A, routes not actively in use are eventually timed out. Thanks for the comments, Yih-Chun > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Apr 10 20:18:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05826 for ; Wed, 10 Apr 2002 20:18:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA29483 for manet-archive@odin.ietf.org; Wed, 10 Apr 2002 20:18:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28241; Wed, 10 Apr 2002 19:55:21 -0400 (EDT) Received: from orval.cs.rice.edu (orval.cs.rice.edu [128.42.6.80]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id TAA28185 for manet@ietf.org; Wed, 10 Apr 2002 19:54:00 -0400 (EDT) Date: Wed, 10 Apr 2002 19:49:47 -0400 (EDT) From: Yih-Chun Hu To: Pekka Savola cc: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org >Additional comment I just noticed: 'ACK Destination Address' in >Acknowledgment DSR Option seemed redundant to me, as the dstaddr in IP >header seems to serve exactly the same purpose. Did I miss something? Yep, you can technically piggyback it on something. Same deal with Route Error Destination Addresses. >> Maybe we could point out in the draft which types could legally be >> present. Perhaps I don't understand the concern, since the concept is that >> anything can be piggybacked in anything. > >.. except for a few exceptions. I don't see a concern as such here, but a >thing perhaps worth clarifying ("the usual DSR header combinations" or >whatnot). I guess I should think very carefully about "the prohibited DSR header combinations." I don't know that there are any; even bizzare things like source-routed route requests could be interesting (route request up to a point, where you know the rest of the route from there, or source route a request out to a certain point, then blossom it from there). >> Since each packet carries its own route, it's route is entirely determined >> by the (by definition consistant) state at the sender, and no other node's >> state. > >The last paragraph is not entirely true: the route can be affected by e.g. >an intermediate node salvaging the packet, right? The maximal salvage >count does limit how many times this can happen, so this couldn't result >in an endless loop, but quite often that's a tranistory state in regular >protocols too. Granted. We could prohibit a path from ever looping, but that would also prohibit backtracking. We don't allow looping (same path over and over again); we allow backtracking. >> >==> I see DSR header functions rather equivalent to link status sensing >> >(maintenance procedures, Send Queue, etc.) and others above. >> >> And they're all on-demand (not periodic). Maybe I don't understand what >> you're trying to say? > >Well, I just think that periodicity, as an "only" criterion, is not >necessarily an usable on. DSR does similar things like periodic activity, >with overhead in the form of DSR header, anyway -- at least when there is >traffic on the wire (e.g. network acknowledgements in route maintenance). There are things that other protocols do periodically: neighbor sense, route discovery, route maintenance, etc. But it does them ONLY when there's traffic on the wire. We say these are performed "on-demand" as a characterization of their frequency and efficiency. We also argue why we think on-demand protocols may be better in certain situations. >> When you put in the special addresses indicating a >> bidirectionality switch, the receivers know the directionality of their >> receive interface, and can deduce which parts of a source route must be >> bidirectional and which ones can have unidirectional links. > >I have a failure to grasp this. Do you mean that addressing could be used >to indicate bidirectionality? Well, this is one approach, but I don't >recall this in the draft? Section 7. It's new in -07. (Sorry) >> For example, >> when the route A->B->*->C->D->*->E is received at D, it knows whether it's >> interface is bidirectional or unidirectional. If it's unidirectional, it >> knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t >> out a bidirectional interface, it adds a * to the source route first. > >I'm not sure what you mean '*' here, so my comment may not be off the >mark. I fail to see how D could conclude anything of A->B or B->C based >on the bidirectionality of its own link? (Except if it knows the >directionality based on addresses or similar, but that's one approach I >was implicitly suggesting.) * is a "magic" address. So, looking at a source route backwards E<-*<-D<-C<-*<-B<-A E knows that the directionality of the c->d segment is different from the directionality of the d->e segment. Similarly, c knows that the directionality of the a->b segment is different from the directionality of the b->c segment. >> >This seems a rather big aasumption. >> It seems rather smaller than assuming that all interfaces are >> bidirectional. >I disagree, on practical terms: it is a rather big assumption *when* one >feature of DSR is exactly unidirectionality. If there is support, the >support should work. If there is no support, people who have this as a >requirement use different protocols. Hmm. Well, since you have to write a driver for an interface, I don't think that's a huge assumption that you know the directionality of one of your interfaces. You'd need to know that to decide whether or not you could even use one of the other protocols. >> I don't really want to belabor this point, because I don't >> think DSR's unidirectional support is very well tuned, and because the >> commodity standard for wireless interfaces these days is 802.11, which >> does require bidirectionality. > >If this is a practical "non-issue", I wonder if it would make sense to try >to define the main DSR proposal as bidirectional, and move unidirectional >parts to a separate draft. That's an "I" as a person, not an "I" speaking on behalf of all draft authors. >> No, it doesn't. You pick a route for the packet. You include the route in >> the packet. That route is loop-free, regardless of whether or not your >> cache is up-to-date. >> >> I also don't see why you couldn't verify loop-freedom if you really cared. >> If an address appears twice in the source route, then you've found a loop? > >True, for "loop-freeness" in the traditional meaning. If one includes >"inserting too long, very suboptimal paths, which do not have a loop", >this would be more difficult to verify. > >But I'm not sure of the threat model of this; my main worry was that if a >source knows a sub-optimal path, and that path will be cached on >intermediate nodes too, and that way it might be propagated to all nodes >querying for that destination (replies from the cache). If you're worried about malicious nodes being "stupid" and using long routes, I can assure you that there are many worse things that could be used as attacks. Automatic Route Shortening helps reduce the length of stale, long routes. Promiscuous overhearing works pretty well too. We have yet to find a reason that drives us to periodic path discovery to ensure freshness. >I'm not all that worried (except for severe implementation bugs) about >loopfreeness as such, but rather unoptimal paths (which may be "almost >loops") getting there. Any on-demand protocol without a periodic rediscovery mechanism has the same problem; once you set up a route, you don't really bother to look for a better one. >I'd add a note in security considerations about this at least, though, >because supporting DSR routing and supporting DSR header in the firewall >software are two rather separate issues, and the connection may not be >apparent. That's a good idea. >> What's the attacker model? Legitimate nodes failing in Byzantine ways? >> Multiple coordinated attackers with several compromised nodes? We specify >> that security considerations are out-of-scope, as in BGP (RFC1771). >> Security in manets are an active area of research... > >The attackers have many models, most of which are out of scope here, >especially if one wants byzantine robustness in the case of a captured >node feeding deliberately wrong information. > >One particular scenario I mentioned here was that a node that has old >cached data keeps propagating that information to nodes which do route >requests through it. Or salvage packets in non-optimal ways. This could >lead to a security problem (denial of service). But perhaps this "cache >freshness ensurance problem" needs to be addressed elsewhere. You'd eventually get route errors that flush out your cache if you're returning bogus routes on requests. For example, suppose A has two disjoint bogus routes to B in its cache, and C does a discovery for B. A returns a bogus route, C uses it, B forwards the corresponding route error. Now A only has one disjoint bogus route. Also, with the cache specified in appendix A, routes not actively in use are eventually timed out. Thanks for the comments, Yih-Chun > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 10 22:37:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09283 for ; Wed, 10 Apr 2002 22:37:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04554; Wed, 10 Apr 2002 22:08:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04526 for ; Wed, 10 Apr 2002 22:08:07 -0400 (EDT) Received: from amber.ccs.neu.edu (postfix@amber.ccs.neu.edu [129.10.116.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08046 for ; Wed, 10 Apr 2002 22:07:59 -0400 (EDT) Received: from CASABLANCA.ccs.neu.edu (denali.ccs.neu.edu [129.10.116.200]) by amber.ccs.neu.edu (Postfix) with ESMTP id 12F131AA36; Wed, 10 Apr 2002 22:07:57 -0400 (EDT) Message-Id: <5.0.2.1.0.20020410215920.02faeea8@localhost> X-Sender: noubir@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Apr 2002 21:59:41 -0400 To: manet@ietf.org From: "G. Noubir" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] CFP: Workshop on Wireless Security (in conjunction with MobiCom 2002) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 20, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Apr 10 22:37:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09290 for ; Wed, 10 Apr 2002 22:37:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA05939 for manet-archive@odin.ietf.org; Wed, 10 Apr 2002 22:37:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04554; Wed, 10 Apr 2002 22:08:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04526 for ; Wed, 10 Apr 2002 22:08:07 -0400 (EDT) Received: from amber.ccs.neu.edu (postfix@amber.ccs.neu.edu [129.10.116.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08046 for ; Wed, 10 Apr 2002 22:07:59 -0400 (EDT) Received: from CASABLANCA.ccs.neu.edu (denali.ccs.neu.edu [129.10.116.200]) by amber.ccs.neu.edu (Postfix) with ESMTP id 12F131AA36; Wed, 10 Apr 2002 22:07:57 -0400 (EDT) Message-Id: <5.0.2.1.0.20020410215920.02faeea8@localhost> X-Sender: noubir@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 10 Apr 2002 21:59:41 -0400 To: manet@ietf.org From: "G. Noubir" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] CFP: Workshop on Wireless Security (in conjunction with MobiCom 2002) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 20, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 11 02:59:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21030 for ; Thu, 11 Apr 2002 02:59:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26258; Thu, 11 Apr 2002 02:28:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26226 for ; Thu, 11 Apr 2002 02:28:50 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20708 for ; Thu, 11 Apr 2002 02:28:46 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3B6SDY02573; Thu, 11 Apr 2002 09:28:13 +0300 Date: Thu, 11 Apr 2002 09:28:12 +0300 (EEST) From: Pekka Savola To: Yih-Chun Hu cc: manet@ietf.org Subject: Re: [manet] Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, Btw, in section 5: The placement of DSR options following the fixed portion of the DSR header MAY be padded for alignment. However, due to the typically limited available wireless bandwidth in ad hoc networks, this padding is not required, and receiving nodes MUST NOT expect options within a DSR header to be aligned. ==> is the wording about the recipient be supposed to be that strict? IMO it's OK to _expect_ the header to be aligned, but the recipient definitely MUST NOT _require_ it? On Wed, 10 Apr 2002, Yih-Chun Hu wrote: > >Additional comment I just noticed: 'ACK Destination Address' in > >Acknowledgment DSR Option seemed redundant to me, as the dstaddr in IP > >header seems to serve exactly the same purpose. Did I miss something? > > Yep, you can technically piggyback it on something. Same deal with Route > Error Destination Addresses. Ok, perhaps these could be clarified, depending on how similar "duplicated data due to piggybacking" is currently discussed. After reading, it wsn't obvious to me you could piggyback data _to multiple destinations_ in all packets. Often piggubacking is only used to mean a multiplex transport between two nodes. DST_I = destination in IP header DST_A = destination in acknowledgement What are the rules for piggybacking? I assume that from the direction of the source, DST_A must be on the path to DST_I, or DST_I? What if DST_A moves off the path, or isn't on the path to begin with? An intermediate node should "remove" piggybacking and send two separate packets? Piggybacking when the destination is not the same seems like a potentially troublesome concept. > >> Maybe we could point out in the draft which types could legally be > >> present. Perhaps I don't understand the concern, since the concept is that > >> anything can be piggybacked in anything. > > > >.. except for a few exceptions. I don't see a concern as such here, but a > >thing perhaps worth clarifying ("the usual DSR header combinations" or > >whatnot). > > I guess I should think very carefully about "the prohibited DSR header > combinations." I don't know that there are any; even bizzare things like > source-routed route requests could be interesting (route request up to a > point, where you know the rest of the route from there, or source route a > request out to a certain point, then blossom it from there). Well, at least some cannot be used more than once. There are probably some practical ways how it's usually done. Just a thought. > >> When you put in the special addresses indicating a > >> bidirectionality switch, the receivers know the directionality of their > >> receive interface, and can deduce which parts of a source route must be > >> bidirectional and which ones can have unidirectional links. > > > >I have a failure to grasp this. Do you mean that addressing could be used > >to indicate bidirectionality? Well, this is one approach, but I don't > >recall this in the draft? > > Section 7. It's new in -07. (Sorry) Hmm. Perhaps this is isn't clear to me as from traditional routing background, one always assumes more than one interface. But isn't this issue more generic than one for multiple interfaces only? > > >> For example, > >> when the route A->B->*->C->D->*->E is received at D, it knows whether it's > >> interface is bidirectional or unidirectional. If it's unidirectional, it > >> knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t > >> out a bidirectional interface, it adds a * to the source route first. > > > >I'm not sure what you mean '*' here, so my comment may not be off the > >mark. I fail to see how D could conclude anything of A->B or B->C based > >on the bidirectionality of its own link? (Except if it knows the > >directionality based on addresses or similar, but that's one approach I > >was implicitly suggesting.) > > * is a "magic" address. So, looking at a source route backwards > E<-*<-D<-C<-*<-B<-A > E knows that the directionality of the c->d segment is different from the > directionality of the d->e segment. Similarly, c knows that the > directionality of the a->b segment is different from the directionality of > the b->c segment. I don't recall the discussion on how the magic address changes the processing of nodes which don't have multiple addresses, btw. What about the scenario where there are no magic addresses: every node in the path has only one interface? It is clear that the interface must be "generally" bidirectional, else it could not do any traffic, but it may not need to be birectional to all the neighbors in the range. > >> >This seems a rather big aasumption. > >> It seems rather smaller than assuming that all interfaces are > >> bidirectional. > >I disagree, on practical terms: it is a rather big assumption *when* one > >feature of DSR is exactly unidirectionality. If there is support, the > >support should work. If there is no support, people who have this as a > >requirement use different protocols. > > Hmm. Well, since you have to write a driver for an interface, I don't > think that's a huge assumption that you know the directionality of one of > your interfaces. You'd need to know that to decide whether or not you > could even use one of the other protocols. IP layer should be separate from this kind of decisions, but anyway, people deploying a MANET and people writing MANET protocols and people writing the interface drivers may be very very different. > >True, for "loop-freeness" in the traditional meaning. If one includes > >"inserting too long, very suboptimal paths, which do not have a loop", > >this would be more difficult to verify. > > > >But I'm not sure of the threat model of this; my main worry was that if a > >source knows a sub-optimal path, and that path will be cached on > >intermediate nodes too, and that way it might be propagated to all nodes > >querying for that destination (replies from the cache). > > If you're worried about malicious nodes being "stupid" and using long > routes, I can assure you that there are many worse things that could be > used as attacks. As said, there are much more viable attacks than this. But my worry is non-malicious, but still "stupid" nodes doing something. > >I'm not all that worried (except for severe implementation bugs) about > >loopfreeness as such, but rather unoptimal paths (which may be "almost > >loops") getting there. > > Any on-demand protocol without a periodic rediscovery mechanism has the > same problem; once you set up a route, you don't really bother to look for > a better one. In some cases it might be very useful, ie. to find fresh new paths before your current path fails. But I guess that's more of an ideological issue.. > >> What's the attacker model? Legitimate nodes failing in Byzantine ways? > >> Multiple coordinated attackers with several compromised nodes? We specify > >> that security considerations are out-of-scope, as in BGP (RFC1771). > >> Security in manets are an active area of research... > > > >The attackers have many models, most of which are out of scope here, > >especially if one wants byzantine robustness in the case of a captured > >node feeding deliberately wrong information. > > > >One particular scenario I mentioned here was that a node that has old > >cached data keeps propagating that information to nodes which do route > >requests through it. Or salvage packets in non-optimal ways. This could > >lead to a security problem (denial of service). But perhaps this "cache > >freshness ensurance problem" needs to be addressed elsewhere. > > You'd eventually get route errors that flush out your cache if you're > returning bogus routes on requests. For example, suppose A has two > disjoint bogus routes to B in its cache, and C does a discovery for B. A > returns a bogus route, C uses it, B forwards the corresponding route > error. Now A only has one disjoint bogus route. Good clarification. > Also, with the cache specified in appendix A, routes not actively in use > are eventually timed out. Note that this behaviour seems different than original ARP behaviour from which Route Req/Route Maintenance originated: with ARP, you re-perform ARP *even if* the entry is being used. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 11 02:59:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21041 for ; Thu, 11 Apr 2002 02:59:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA27731 for manet-archive@odin.ietf.org; Thu, 11 Apr 2002 02:59:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26258; Thu, 11 Apr 2002 02:28:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26226 for ; Thu, 11 Apr 2002 02:28:50 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20708 for ; Thu, 11 Apr 2002 02:28:46 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3B6SDY02573; Thu, 11 Apr 2002 09:28:13 +0300 Date: Thu, 11 Apr 2002 09:28:12 +0300 (EEST) From: Pekka Savola To: Yih-Chun Hu cc: manet@ietf.org Subject: Re: [manet] Re: New DSR Draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, Btw, in section 5: The placement of DSR options following the fixed portion of the DSR header MAY be padded for alignment. However, due to the typically limited available wireless bandwidth in ad hoc networks, this padding is not required, and receiving nodes MUST NOT expect options within a DSR header to be aligned. ==> is the wording about the recipient be supposed to be that strict? IMO it's OK to _expect_ the header to be aligned, but the recipient definitely MUST NOT _require_ it? On Wed, 10 Apr 2002, Yih-Chun Hu wrote: > >Additional comment I just noticed: 'ACK Destination Address' in > >Acknowledgment DSR Option seemed redundant to me, as the dstaddr in IP > >header seems to serve exactly the same purpose. Did I miss something? > > Yep, you can technically piggyback it on something. Same deal with Route > Error Destination Addresses. Ok, perhaps these could be clarified, depending on how similar "duplicated data due to piggybacking" is currently discussed. After reading, it wsn't obvious to me you could piggyback data _to multiple destinations_ in all packets. Often piggubacking is only used to mean a multiplex transport between two nodes. DST_I = destination in IP header DST_A = destination in acknowledgement What are the rules for piggybacking? I assume that from the direction of the source, DST_A must be on the path to DST_I, or DST_I? What if DST_A moves off the path, or isn't on the path to begin with? An intermediate node should "remove" piggybacking and send two separate packets? Piggybacking when the destination is not the same seems like a potentially troublesome concept. > >> Maybe we could point out in the draft which types could legally be > >> present. Perhaps I don't understand the concern, since the concept is that > >> anything can be piggybacked in anything. > > > >.. except for a few exceptions. I don't see a concern as such here, but a > >thing perhaps worth clarifying ("the usual DSR header combinations" or > >whatnot). > > I guess I should think very carefully about "the prohibited DSR header > combinations." I don't know that there are any; even bizzare things like > source-routed route requests could be interesting (route request up to a > point, where you know the rest of the route from there, or source route a > request out to a certain point, then blossom it from there). Well, at least some cannot be used more than once. There are probably some practical ways how it's usually done. Just a thought. > >> When you put in the special addresses indicating a > >> bidirectionality switch, the receivers know the directionality of their > >> receive interface, and can deduce which parts of a source route must be > >> bidirectional and which ones can have unidirectional links. > > > >I have a failure to grasp this. Do you mean that addressing could be used > >to indicate bidirectionality? Well, this is one approach, but I don't > >recall this in the draft? > > Section 7. It's new in -07. (Sorry) Hmm. Perhaps this is isn't clear to me as from traditional routing background, one always assumes more than one interface. But isn't this issue more generic than one for multiple interfaces only? > > >> For example, > >> when the route A->B->*->C->D->*->E is received at D, it knows whether it's > >> interface is bidirectional or unidirectional. If it's unidirectional, it > >> knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t > >> out a bidirectional interface, it adds a * to the source route first. > > > >I'm not sure what you mean '*' here, so my comment may not be off the > >mark. I fail to see how D could conclude anything of A->B or B->C based > >on the bidirectionality of its own link? (Except if it knows the > >directionality based on addresses or similar, but that's one approach I > >was implicitly suggesting.) > > * is a "magic" address. So, looking at a source route backwards > E<-*<-D<-C<-*<-B<-A > E knows that the directionality of the c->d segment is different from the > directionality of the d->e segment. Similarly, c knows that the > directionality of the a->b segment is different from the directionality of > the b->c segment. I don't recall the discussion on how the magic address changes the processing of nodes which don't have multiple addresses, btw. What about the scenario where there are no magic addresses: every node in the path has only one interface? It is clear that the interface must be "generally" bidirectional, else it could not do any traffic, but it may not need to be birectional to all the neighbors in the range. > >> >This seems a rather big aasumption. > >> It seems rather smaller than assuming that all interfaces are > >> bidirectional. > >I disagree, on practical terms: it is a rather big assumption *when* one > >feature of DSR is exactly unidirectionality. If there is support, the > >support should work. If there is no support, people who have this as a > >requirement use different protocols. > > Hmm. Well, since you have to write a driver for an interface, I don't > think that's a huge assumption that you know the directionality of one of > your interfaces. You'd need to know that to decide whether or not you > could even use one of the other protocols. IP layer should be separate from this kind of decisions, but anyway, people deploying a MANET and people writing MANET protocols and people writing the interface drivers may be very very different. > >True, for "loop-freeness" in the traditional meaning. If one includes > >"inserting too long, very suboptimal paths, which do not have a loop", > >this would be more difficult to verify. > > > >But I'm not sure of the threat model of this; my main worry was that if a > >source knows a sub-optimal path, and that path will be cached on > >intermediate nodes too, and that way it might be propagated to all nodes > >querying for that destination (replies from the cache). > > If you're worried about malicious nodes being "stupid" and using long > routes, I can assure you that there are many worse things that could be > used as attacks. As said, there are much more viable attacks than this. But my worry is non-malicious, but still "stupid" nodes doing something. > >I'm not all that worried (except for severe implementation bugs) about > >loopfreeness as such, but rather unoptimal paths (which may be "almost > >loops") getting there. > > Any on-demand protocol without a periodic rediscovery mechanism has the > same problem; once you set up a route, you don't really bother to look for > a better one. In some cases it might be very useful, ie. to find fresh new paths before your current path fails. But I guess that's more of an ideological issue.. > >> What's the attacker model? Legitimate nodes failing in Byzantine ways? > >> Multiple coordinated attackers with several compromised nodes? We specify > >> that security considerations are out-of-scope, as in BGP (RFC1771). > >> Security in manets are an active area of research... > > > >The attackers have many models, most of which are out of scope here, > >especially if one wants byzantine robustness in the case of a captured > >node feeding deliberately wrong information. > > > >One particular scenario I mentioned here was that a node that has old > >cached data keeps propagating that information to nodes which do route > >requests through it. Or salvage packets in non-optimal ways. This could > >lead to a security problem (denial of service). But perhaps this "cache > >freshness ensurance problem" needs to be addressed elsewhere. > > You'd eventually get route errors that flush out your cache if you're > returning bogus routes on requests. For example, suppose A has two > disjoint bogus routes to B in its cache, and C does a discovery for B. A > returns a bogus route, C uses it, B forwards the corresponding route > error. Now A only has one disjoint bogus route. Good clarification. > Also, with the cache specified in appendix A, routes not actively in use > are eventually timed out. Note that this behaviour seems different than original ARP behaviour from which Route Req/Route Maintenance originated: with ARP, you re-perform ARP *even if* the entry is being used. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 11 16:13:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12514 for ; Thu, 11 Apr 2002 16:13:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07058; Thu, 11 Apr 2002 15:09:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06974 for ; Thu, 11 Apr 2002 15:09:22 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09964 for ; Thu, 11 Apr 2002 15:09:14 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA26452 for ; Thu, 11 Apr 2002 12:09:25 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA03481 for ; Thu, 11 Apr 2002 12:09:15 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g3BJ9Dt10092 for ; Thu, 11 Apr 2002 12:09:14 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <22H9CTFH>; Thu, 11 Apr 2002 12:09:10 -0700 Message-ID: From: "Nast, Douglas P" To: manet@ietf.org Date: Thu, 11 Apr 2002 12:09:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] backup routes Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Do any of the proposed pro-active manet routing protocols support an idea analogous to the feasible successor concept in EIGRP? That is, a guaranteed loop-free backup route is maintained in a topology database for immediate use when the link to the best path goes down? Doug Nast _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 11 16:13:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12530 for ; Thu, 11 Apr 2002 16:13:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10323 for manet-archive@odin.ietf.org; Thu, 11 Apr 2002 16:13:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07058; Thu, 11 Apr 2002 15:09:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06974 for ; Thu, 11 Apr 2002 15:09:22 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09964 for ; Thu, 11 Apr 2002 15:09:14 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA26452 for ; Thu, 11 Apr 2002 12:09:25 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA03481 for ; Thu, 11 Apr 2002 12:09:15 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g3BJ9Dt10092 for ; Thu, 11 Apr 2002 12:09:14 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <22H9CTFH>; Thu, 11 Apr 2002 12:09:10 -0700 Message-ID: From: "Nast, Douglas P" To: manet@ietf.org Date: Thu, 11 Apr 2002 12:09:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] backup routes Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Do any of the proposed pro-active manet routing protocols support an idea analogous to the feasible successor concept in EIGRP? That is, a guaranteed loop-free backup route is maintained in a topology database for immediate use when the link to the best path goes down? Doug Nast _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 11 20:10:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20822 for ; Thu, 11 Apr 2002 20:10:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24416; Thu, 11 Apr 2002 19:20:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24384 for ; Thu, 11 Apr 2002 19:20:50 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19806 for ; Thu, 11 Apr 2002 19:20:46 -0400 (EDT) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g3BNKjO13449; Thu, 11 Apr 2002 16:20:45 -0700 (PDT) Message-Id: <200204112320.g3BNKjO13449@letters.cs.ucsb.edu> Date: Thu, 11 Apr 2002 16:20:45 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: manet@ietf.org Cc: mobihoc@cs.ucsb.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: clKJjEkJvXCK7BvEIvFJWw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [manet] Mobihoc 2002: Early Registration Deadline Approaching! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Please note: The early registration deadline is *April 22nd*. Register now to guarantee the reduced registration fee! --------------------------------------------------------------------------- ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiHoc 2002 The Third ACM International Symposium on Mobile Ad Hoc Networking and Computing Lausanne, Switzerland June 9-11, 2002 http://www.acm.org/sigmobile/mobihoc/2002/ Sponsored by ACM SIGMOBILE http://www.acm.org/sigmobile/ MobiHoc 2002 is the third of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 in Long Beach, California, and now in 2002 in Lausanne, Switzerland. Topics of interest include all areas of mobile and wireless ad hoc networking (above the physical layer), ad hoc computing, and sensor networks. PAPERS: There will be approximately seven technical paper sessions on a wide range of ad hoc networking topics. The list of accepted papers can be found at http://www.acm.org/sigmobile/mobihoc/2002/program.html. Paper topics include routing, sensor networks, scalability, multicast, energy consumption, TCP, and priority scheduling. POSTERS: There will also be a poster session, describing innovative and recent research on ad hoc networks. TUTORIALS: This year there is a new component to MobiHoc: technical tutorials. On June 9th there will be two tutorials. "Design and Modeling of Medium Access Control Protocols for Wireless Ad Hoc Networks" will be held in the morning, and "Routing & Multicasting in Ad hoc Networks" will be held in the afternoon. HOTEL and REGISTRATION: Hotel information is currently available on-line, and the symposium is open for registration. Register by April 22, 2002 to get the early registration rates. IMPORTANT DATES: Early Registration Deadline: April 22, 2002 Tutorials: June 9, 2002 Conference: June 10-11, 2002 FOR MORE INFORMATION: Please visit the MobiHoc 2002 Home Page at http://www.acm.org/sigmobile/mobihoc/2002/ or send email to mobihoc@epfl.ch for any questions or for more information about the symposium. ORGANIZING COMMITTEE: General Chair Jean-Pierre Hubaux EPFL (CH) jean-pierre.hubaux@epfl.ch Program Co-Chairs J.J. Garcia-Luna-Aceves David B. Johnson Univ. California, Santa Cruz (US) Rice University (US) jj@cs.ucsc.edu dbj@cs.rice.edu Tutorials Co-Chairs Adam Wolisz Mario Gerla Technical Univ. of Berlin (DE) Univ. California, Los Angeles (US) wolisz@ee.tu-berlin.de gerla@cs.ucla.edu Finance Chair Local Arrangements Chair Rachid Guerraoui Silvia Giordano EPFL (CH) EPFL (CH) rachid.guerraoui@epfl.ch silvia.giordano@epfl.ch Publicity Chair Publication Chair Elizabeth M. Belding-Royer Robin Kravets Univ. Calif., Santa Barbara (US) Univ. Illinois, Urbana-Champaign (US) ebelding@cs.ucsb.edu rhk@cs.uiuc.edu Registration Chair Srdjan Capkun EPFL (CH) srdan.capkun@epfl.ch Steering Committee Andrew T. Campbell Charles E. Perkins J.J. Garcia-Luna-Aceves Ram Ramanathan Mario Gerla Martha Steenstrup Joseph P. Macker Nitin H. Vaidya ACM Program Director Ginger Ignatoff --------------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 11 20:10:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20833 for ; Thu, 11 Apr 2002 20:10:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA27084 for manet-archive@odin.ietf.org; Thu, 11 Apr 2002 20:10:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24416; Thu, 11 Apr 2002 19:20:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24384 for ; Thu, 11 Apr 2002 19:20:50 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19806 for ; Thu, 11 Apr 2002 19:20:46 -0400 (EDT) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g3BNKjO13449; Thu, 11 Apr 2002 16:20:45 -0700 (PDT) Message-Id: <200204112320.g3BNKjO13449@letters.cs.ucsb.edu> Date: Thu, 11 Apr 2002 16:20:45 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: manet@ietf.org Cc: mobihoc@cs.ucsb.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: clKJjEkJvXCK7BvEIvFJWw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [manet] Mobihoc 2002: Early Registration Deadline Approaching! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Please note: The early registration deadline is *April 22nd*. Register now to guarantee the reduced registration fee! --------------------------------------------------------------------------- ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiHoc 2002 The Third ACM International Symposium on Mobile Ad Hoc Networking and Computing Lausanne, Switzerland June 9-11, 2002 http://www.acm.org/sigmobile/mobihoc/2002/ Sponsored by ACM SIGMOBILE http://www.acm.org/sigmobile/ MobiHoc 2002 is the third of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 in Long Beach, California, and now in 2002 in Lausanne, Switzerland. Topics of interest include all areas of mobile and wireless ad hoc networking (above the physical layer), ad hoc computing, and sensor networks. PAPERS: There will be approximately seven technical paper sessions on a wide range of ad hoc networking topics. The list of accepted papers can be found at http://www.acm.org/sigmobile/mobihoc/2002/program.html. Paper topics include routing, sensor networks, scalability, multicast, energy consumption, TCP, and priority scheduling. POSTERS: There will also be a poster session, describing innovative and recent research on ad hoc networks. TUTORIALS: This year there is a new component to MobiHoc: technical tutorials. On June 9th there will be two tutorials. "Design and Modeling of Medium Access Control Protocols for Wireless Ad Hoc Networks" will be held in the morning, and "Routing & Multicasting in Ad hoc Networks" will be held in the afternoon. HOTEL and REGISTRATION: Hotel information is currently available on-line, and the symposium is open for registration. Register by April 22, 2002 to get the early registration rates. IMPORTANT DATES: Early Registration Deadline: April 22, 2002 Tutorials: June 9, 2002 Conference: June 10-11, 2002 FOR MORE INFORMATION: Please visit the MobiHoc 2002 Home Page at http://www.acm.org/sigmobile/mobihoc/2002/ or send email to mobihoc@epfl.ch for any questions or for more information about the symposium. ORGANIZING COMMITTEE: General Chair Jean-Pierre Hubaux EPFL (CH) jean-pierre.hubaux@epfl.ch Program Co-Chairs J.J. Garcia-Luna-Aceves David B. Johnson Univ. California, Santa Cruz (US) Rice University (US) jj@cs.ucsc.edu dbj@cs.rice.edu Tutorials Co-Chairs Adam Wolisz Mario Gerla Technical Univ. of Berlin (DE) Univ. California, Los Angeles (US) wolisz@ee.tu-berlin.de gerla@cs.ucla.edu Finance Chair Local Arrangements Chair Rachid Guerraoui Silvia Giordano EPFL (CH) EPFL (CH) rachid.guerraoui@epfl.ch silvia.giordano@epfl.ch Publicity Chair Publication Chair Elizabeth M. Belding-Royer Robin Kravets Univ. Calif., Santa Barbara (US) Univ. Illinois, Urbana-Champaign (US) ebelding@cs.ucsb.edu rhk@cs.uiuc.edu Registration Chair Srdjan Capkun EPFL (CH) srdan.capkun@epfl.ch Steering Committee Andrew T. Campbell Charles E. Perkins J.J. Garcia-Luna-Aceves Ram Ramanathan Mario Gerla Martha Steenstrup Joseph P. Macker Nitin H. Vaidya ACM Program Director Ginger Ignatoff --------------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 11 21:25:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24618 for ; Thu, 11 Apr 2002 21:25:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27133; Thu, 11 Apr 2002 20:11:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27103 for ; Thu, 11 Apr 2002 20:11:10 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20855 for ; Thu, 11 Apr 2002 20:11:06 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id RAA13489; Thu, 11 Apr 2002 17:08:33 -0700 (PDT) Message-Id: <200204120008.RAA13489@pit.erg.sri.com> To: "Nast, Douglas P" cc: manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] backup routes In-reply-to: Your message of "Thu, 11 Apr 2002 12:09:03 PDT." Date: Thu, 11 Apr 2002 17:08:32 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > > Do any of the proposed pro-active manet routing protocols support an idea > analogous to the feasible successor concept in EIGRP? That is, a > guaranteed loop-free backup route is maintained in a topology database for > immediate use when the link to the best path goes down? > > Doug Nast Doug, In TBRPF, when a route fails, the source tree and routing table are updated immediately, based on the topology database, to provide immediate rerouting (even if the new path is longer, unlike EIGRP as explained below). Since TBRPF is a link-state protocol, the source node knows the entire path (and therefore knows that it is loop free). EIGRP is a distance-vector protocol, and must send "query" messages if the distance to some destination increases, to ensure loop freedom. EIGRP is not being considered for MANETs. DSDV is another distance-vector protocol that is a better candidate for MANETs. Richard > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 11 21:25:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24629 for ; Thu, 11 Apr 2002 21:25:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA00487 for manet-archive@odin.ietf.org; Thu, 11 Apr 2002 21:25:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27133; Thu, 11 Apr 2002 20:11:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27103 for ; Thu, 11 Apr 2002 20:11:10 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20855 for ; Thu, 11 Apr 2002 20:11:06 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id RAA13489; Thu, 11 Apr 2002 17:08:33 -0700 (PDT) Message-Id: <200204120008.RAA13489@pit.erg.sri.com> To: "Nast, Douglas P" cc: manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] backup routes In-reply-to: Your message of "Thu, 11 Apr 2002 12:09:03 PDT." Date: Thu, 11 Apr 2002 17:08:32 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > > Do any of the proposed pro-active manet routing protocols support an idea > analogous to the feasible successor concept in EIGRP? That is, a > guaranteed loop-free backup route is maintained in a topology database for > immediate use when the link to the best path goes down? > > Doug Nast Doug, In TBRPF, when a route fails, the source tree and routing table are updated immediately, based on the topology database, to provide immediate rerouting (even if the new path is longer, unlike EIGRP as explained below). Since TBRPF is a link-state protocol, the source node knows the entire path (and therefore knows that it is loop free). EIGRP is a distance-vector protocol, and must send "query" messages if the distance to some destination increases, to ensure loop freedom. EIGRP is not being considered for MANETs. DSDV is another distance-vector protocol that is a better candidate for MANETs. Richard > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 12 01:03:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21800 for ; Fri, 12 Apr 2002 01:03:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08441; Fri, 12 Apr 2002 00:13:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08408 for ; Fri, 12 Apr 2002 00:13:17 -0400 (EDT) Received: from ziz.its.uow.edu.au (ziz.its.uow.edu.au [130.130.68.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16034 for ; Fri, 12 Apr 2002 00:13:15 -0400 (EDT) Received: from inti.its.uow.edu.au (inti.its.uow.edu.au [130.130.68.6]) by ziz.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id OAA00706 for ; Fri, 12 Apr 2002 14:13:08 +1000 (EST) Received: (from webmail@localhost) by inti.its.uow.edu.au (8.9.3/8.9.3) id OAA19511; Fri, 12 Apr 2002 14:13:07 +1000 (EST) Message-Id: <200204120413.OAA19511@inti.its.uow.edu.au> Content-Transfer-Encoding: 8bit From: Gaurav Srivastava X-Originating-IP: [130.130.12.111] To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 12 Apr 2002 14:13:06 +1000 User-Agent: IMHO/0.97.1 (Webmail for Roxen) In-Reply-To: Content-Transfer-Encoding: 8bit Subject: [manet] collisions Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, I was performing a simple simulation in glomosim 2.02. A static 25 node network, with nodes arranged in a grid topology with grid spacing of 200 m. The transmission range of every node is 376 m I had set up CBR traffice bitween nodes 0 1, 1 2, 0 2, 2 1, 2 0. I am using static routes. When I looked at the collisions metric, I found that there are a lot of collisions on node 5 6 7 8. This is very odd as they are not involved in the communication an are not used for routing. I changed the MAC protocol form 802.11 to CSMA but still there are a large number of collisions noticed at node 5 6 7 8. I decreased the CBR traffic on nodes 0 1 2 and sent only about 8 packets per node. The collisions on node 5 6 7 8 were still there and a were very large. Is this a bug in glomosim, Can some one help ??? Gaurav _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Apr 12 01:04:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21808 for ; Fri, 12 Apr 2002 01:04:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA10911 for manet-archive@odin.ietf.org; Fri, 12 Apr 2002 01:04:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08441; Fri, 12 Apr 2002 00:13:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA08408 for ; Fri, 12 Apr 2002 00:13:17 -0400 (EDT) Received: from ziz.its.uow.edu.au (ziz.its.uow.edu.au [130.130.68.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16034 for ; Fri, 12 Apr 2002 00:13:15 -0400 (EDT) Received: from inti.its.uow.edu.au (inti.its.uow.edu.au [130.130.68.6]) by ziz.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id OAA00706 for ; Fri, 12 Apr 2002 14:13:08 +1000 (EST) Received: (from webmail@localhost) by inti.its.uow.edu.au (8.9.3/8.9.3) id OAA19511; Fri, 12 Apr 2002 14:13:07 +1000 (EST) Message-Id: <200204120413.OAA19511@inti.its.uow.edu.au> Content-Transfer-Encoding: 8bit From: Gaurav Srivastava X-Originating-IP: [130.130.12.111] To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 12 Apr 2002 14:13:06 +1000 User-Agent: IMHO/0.97.1 (Webmail for Roxen) In-Reply-To: Content-Transfer-Encoding: 8bit Subject: [manet] collisions Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, I was performing a simple simulation in glomosim 2.02. A static 25 node network, with nodes arranged in a grid topology with grid spacing of 200 m. The transmission range of every node is 376 m I had set up CBR traffice bitween nodes 0 1, 1 2, 0 2, 2 1, 2 0. I am using static routes. When I looked at the collisions metric, I found that there are a lot of collisions on node 5 6 7 8. This is very odd as they are not involved in the communication an are not used for routing. I changed the MAC protocol form 802.11 to CSMA but still there are a large number of collisions noticed at node 5 6 7 8. I decreased the CBR traffic on nodes 0 1 2 and sent only about 8 packets per node. The collisions on node 5 6 7 8 were still there and a were very large. Is this a bug in glomosim, Can some one help ??? Gaurav _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 12 12:00:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10515 for ; Fri, 12 Apr 2002 12:00:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21290; Fri, 12 Apr 2002 11:10:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21261 for ; Fri, 12 Apr 2002 11:10:38 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04318 for ; Fri, 12 Apr 2002 11:10:34 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA12753; Fri, 12 Apr 2002 08:10:45 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA23971; Fri, 12 Apr 2002 08:10:34 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g3CFAXt27356; Fri, 12 Apr 2002 08:10:33 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <22H91J97>; Fri, 12 Apr 2002 08:10:32 -0700 Message-ID: From: "Nast, Douglas P" To: "'ogier@erg.sri.com'" Cc: manet@ietf.org Subject: RE: [manet] backup routes Date: Fri, 12 Apr 2002 08:10:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Thanks Richard. I am interested any feasible manet DVs, and noted that EIGRP claims convergence comparable to link state because it retains backup routes. I was wondering if anyone thought this idea worth exploiting in Manet protocols. As you say, with link states replicated topology database discovering loop-free alternates is not an issue. I will take a look at DSDV. Doug Nast -----Original Message----- From: ogier@erg.sri.com [mailto:ogier@erg.sri.com] Sent: Thursday, April 11, 2002 5:09 PM To: Nast, Douglas P Cc: manet@ietf.org Subject: Re: [manet] backup routes > > Do any of the proposed pro-active manet routing protocols support an idea > analogous to the feasible successor concept in EIGRP? That is, a > guaranteed loop-free backup route is maintained in a topology database for > immediate use when the link to the best path goes down? > > Doug Nast Doug, In TBRPF, when a route fails, the source tree and routing table are updated immediately, based on the topology database, to provide immediate rerouting (even if the new path is longer, unlike EIGRP as explained below). Since TBRPF is a link-state protocol, the source node knows the entire path (and therefore knows that it is loop free). EIGRP is a distance-vector protocol, and must send "query" messages if the distance to some destination increases, to ensure loop freedom. EIGRP is not being considered for MANETs. DSDV is another distance-vector protocol that is a better candidate for MANETs. Richard > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 12 12:00:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10529 for ; Fri, 12 Apr 2002 12:00:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24812 for manet-archive@odin.ietf.org; Fri, 12 Apr 2002 12:00:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21290; Fri, 12 Apr 2002 11:10:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21261 for ; Fri, 12 Apr 2002 11:10:38 -0400 (EDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04318 for ; Fri, 12 Apr 2002 11:10:34 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id IAA12753; Fri, 12 Apr 2002 08:10:45 -0700 (PDT) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id IAA23971; Fri, 12 Apr 2002 08:10:34 -0700 (PDT) Received: from xch-nwbh-02.nw.nos.boeing.com (xch-nwbh-02.nw.nos.boeing.com [192.54.12.28]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g3CFAXt27356; Fri, 12 Apr 2002 08:10:33 -0700 (PDT) Received: by xch-nwbh-02.nw.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <22H91J97>; Fri, 12 Apr 2002 08:10:32 -0700 Message-ID: From: "Nast, Douglas P" To: "'ogier@erg.sri.com'" Cc: manet@ietf.org Subject: RE: [manet] backup routes Date: Fri, 12 Apr 2002 08:10:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Thanks Richard. I am interested any feasible manet DVs, and noted that EIGRP claims convergence comparable to link state because it retains backup routes. I was wondering if anyone thought this idea worth exploiting in Manet protocols. As you say, with link states replicated topology database discovering loop-free alternates is not an issue. I will take a look at DSDV. Doug Nast -----Original Message----- From: ogier@erg.sri.com [mailto:ogier@erg.sri.com] Sent: Thursday, April 11, 2002 5:09 PM To: Nast, Douglas P Cc: manet@ietf.org Subject: Re: [manet] backup routes > > Do any of the proposed pro-active manet routing protocols support an idea > analogous to the feasible successor concept in EIGRP? That is, a > guaranteed loop-free backup route is maintained in a topology database for > immediate use when the link to the best path goes down? > > Doug Nast Doug, In TBRPF, when a route fails, the source tree and routing table are updated immediately, based on the topology database, to provide immediate rerouting (even if the new path is longer, unlike EIGRP as explained below). Since TBRPF is a link-state protocol, the source node knows the entire path (and therefore knows that it is loop free). EIGRP is a distance-vector protocol, and must send "query" messages if the distance to some destination increases, to ensure loop freedom. EIGRP is not being considered for MANETs. DSDV is another distance-vector protocol that is a better candidate for MANETs. Richard > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 12 15:08:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00839 for ; Fri, 12 Apr 2002 15:08:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01837; Fri, 12 Apr 2002 14:02:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01800 for ; Fri, 12 Apr 2002 14:02:20 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27131 for ; Fri, 12 Apr 2002 14:02:13 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3CI1hL23098 for ; Fri, 12 Apr 2002 20:01:44 +0200 (MET DST) Message-ID: <007301c1e24e$f7b75c00$3ac033c1@inria.fr> From: "Philippe Jacquet" To: References: Subject: Re: [manet] backup routes Date: Fri, 12 Apr 2002 20:22:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Dear Doug, OLSR provides natural route back-up because of link state knowledge of the network. The links that are advertized througout the network are the MPR links that reduce the overhead of link state control. Their number can be tuned to increase path redundancy if necessary. It is a priori not necessary to compute the back-up route in parallel with the main route, since recomputation will be triggered by link breakage. However if you feel that recomputation may take time, it could be done in anticipation for fast rerouting purpose (implementation issue). Philippe ----- Original Message ----- From: Nast, Douglas P To: Sent: Thursday, April 11, 2002 9:09 PM Subject: [manet] backup routes > > Do any of the proposed pro-active manet routing protocols support an idea > analogous to the feasible successor concept in EIGRP? That is, a > guaranteed loop-free backup route is maintained in a topology database for > immediate use when the link to the best path goes down? > > Doug Nast > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 12 15:08:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00856 for ; Fri, 12 Apr 2002 15:08:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06028 for manet-archive@odin.ietf.org; Fri, 12 Apr 2002 15:08:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01837; Fri, 12 Apr 2002 14:02:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01800 for ; Fri, 12 Apr 2002 14:02:20 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27131 for ; Fri, 12 Apr 2002 14:02:13 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3CI1hL23098 for ; Fri, 12 Apr 2002 20:01:44 +0200 (MET DST) Message-ID: <007301c1e24e$f7b75c00$3ac033c1@inria.fr> From: "Philippe Jacquet" To: References: Subject: Re: [manet] backup routes Date: Fri, 12 Apr 2002 20:22:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Dear Doug, OLSR provides natural route back-up because of link state knowledge of the network. The links that are advertized througout the network are the MPR links that reduce the overhead of link state control. Their number can be tuned to increase path redundancy if necessary. It is a priori not necessary to compute the back-up route in parallel with the main route, since recomputation will be triggered by link breakage. However if you feel that recomputation may take time, it could be done in anticipation for fast rerouting purpose (implementation issue). Philippe ----- Original Message ----- From: Nast, Douglas P To: Sent: Thursday, April 11, 2002 9:09 PM Subject: [manet] backup routes > > Do any of the proposed pro-active manet routing protocols support an idea > analogous to the feasible successor concept in EIGRP? That is, a > guaranteed loop-free backup route is maintained in a topology database for > immediate use when the link to the best path goes down? > > Doug Nast > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Apr 13 23:32:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04908 for ; Sat, 13 Apr 2002 23:32:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28622; Sat, 13 Apr 2002 23:04:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28596 for ; Sat, 13 Apr 2002 23:04:49 -0400 (EDT) Received: from sunlight (SUNLIGHT.WICHITA.EDU [156.26.1.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04298 for ; Sat, 13 Apr 2002 23:04:44 -0400 (EDT) Received: from CONVERSION-DAEMON.sunlight.wichita.edu by sunlight.wichita.edu (PMDF V6.1 #39562) id <0GUJ00301F7N1G@sunlight.wichita.edu> for manet@ietf.org; Sat, 13 Apr 2002 22:04:35 -0500 (CDT) Received: from webmail.wichita.edu (BIERSTADT.UC.TWSU.EDU [156.26.1.165]) by sunlight.wichita.edu (PMDF V6.1 #39562) with ESMTP id <0GUJ0026TF7NUV@sunlight.wichita.edu> for manet@ietf.org; Sat, 13 Apr 2002 22:04:35 -0500 (CDT) Date: Sat, 13 Apr 2002 22:04:46 -0500 From: fxbaloch To: manet@ietf.org Message-id: <3CB7686C@webmail.wichita.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.62 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-WebMail-UserID: fxbaloch@wichita.edu X-EXP32-SerialNo: 00003023 Content-Transfer-Encoding: 7bit Subject: [manet] Frame Formats Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Can any one tell me where can I find frame formats for different routing protocols used in ad hoc networks? Thanks Fariha Baloch _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sat Apr 13 23:32:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04922 for ; Sat, 13 Apr 2002 23:32:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA00015 for manet-archive@odin.ietf.org; Sat, 13 Apr 2002 23:32:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28622; Sat, 13 Apr 2002 23:04:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28596 for ; Sat, 13 Apr 2002 23:04:49 -0400 (EDT) Received: from sunlight (SUNLIGHT.WICHITA.EDU [156.26.1.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04298 for ; Sat, 13 Apr 2002 23:04:44 -0400 (EDT) Received: from CONVERSION-DAEMON.sunlight.wichita.edu by sunlight.wichita.edu (PMDF V6.1 #39562) id <0GUJ00301F7N1G@sunlight.wichita.edu> for manet@ietf.org; Sat, 13 Apr 2002 22:04:35 -0500 (CDT) Received: from webmail.wichita.edu (BIERSTADT.UC.TWSU.EDU [156.26.1.165]) by sunlight.wichita.edu (PMDF V6.1 #39562) with ESMTP id <0GUJ0026TF7NUV@sunlight.wichita.edu> for manet@ietf.org; Sat, 13 Apr 2002 22:04:35 -0500 (CDT) Date: Sat, 13 Apr 2002 22:04:46 -0500 From: fxbaloch To: manet@ietf.org Message-id: <3CB7686C@webmail.wichita.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.62 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-WebMail-UserID: fxbaloch@wichita.edu X-EXP32-SerialNo: 00003023 Content-Transfer-Encoding: 7bit Subject: [manet] Frame Formats Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Can any one tell me where can I find frame formats for different routing protocols used in ad hoc networks? Thanks Fariha Baloch _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Apr 13 23:43:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05090 for ; Sat, 13 Apr 2002 23:43:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29223; Sat, 13 Apr 2002 23:23:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29183 for ; Sat, 13 Apr 2002 23:23:27 -0400 (EDT) Received: from web11804.mail.yahoo.com (web11804.mail.yahoo.com [216.136.172.158]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04468 for ; Sat, 13 Apr 2002 23:23:24 -0400 (EDT) Message-ID: <20020414032323.67158.qmail@web11804.mail.yahoo.com> Received: from [130.126.136.80] by web11804.mail.yahoo.com via HTTP; Sat, 13 Apr 2002 20:23:23 PDT Date: Sat, 13 Apr 2002 20:23:23 -0700 (PDT) From: Vamshidhar Kommineni To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Request about gpsr Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I am not sure if this is the right place to post this, but I had a question about Greedy Perimeter Stateless Routing (gpsr) and was hoping someone could help me. I am trying to get the ns-2 simulation code of gpsr working under ns-2 from the snapshot available from Dr.Karp's page http://www.icir.org/bkarp/gpsr/gpsr.html. Unfortunately I cannot get it to compile with either ns-2.1b6 or 2.1b7. I was wondering if anyone got this code to work properly under either ns-2 version b6 or preferably b8. If so, some directions or help in obtaining a working tarball would be greatly appreciated. Thanks, Vamshidhar. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sat Apr 13 23:43:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05101 for ; Sat, 13 Apr 2002 23:43:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA00365 for manet-archive@odin.ietf.org; Sat, 13 Apr 2002 23:43:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29223; Sat, 13 Apr 2002 23:23:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA29183 for ; Sat, 13 Apr 2002 23:23:27 -0400 (EDT) Received: from web11804.mail.yahoo.com (web11804.mail.yahoo.com [216.136.172.158]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04468 for ; Sat, 13 Apr 2002 23:23:24 -0400 (EDT) Message-ID: <20020414032323.67158.qmail@web11804.mail.yahoo.com> Received: from [130.126.136.80] by web11804.mail.yahoo.com via HTTP; Sat, 13 Apr 2002 20:23:23 PDT Date: Sat, 13 Apr 2002 20:23:23 -0700 (PDT) From: Vamshidhar Kommineni To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Request about gpsr Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, I am not sure if this is the right place to post this, but I had a question about Greedy Perimeter Stateless Routing (gpsr) and was hoping someone could help me. I am trying to get the ns-2 simulation code of gpsr working under ns-2 from the snapshot available from Dr.Karp's page http://www.icir.org/bkarp/gpsr/gpsr.html. Unfortunately I cannot get it to compile with either ns-2.1b6 or 2.1b7. I was wondering if anyone got this code to work properly under either ns-2 version b6 or preferably b8. If so, some directions or help in obtaining a working tarball would be greatly appreciated. Thanks, Vamshidhar. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Apr 14 21:30:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24541 for ; Sun, 14 Apr 2002 21:30:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23354; Sun, 14 Apr 2002 21:00:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23296 for ; Sun, 14 Apr 2002 21:00:52 -0400 (EDT) Received: from 263.net ([202.96.44.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24259 for ; Sun, 14 Apr 2002 21:00:44 -0400 (EDT) From: ggfmusjc@263.net Received: by 263.net (Postfix, from userid 60001) id 8070F1C6DCA1B; Mon, 15 Apr 2002 08:57:18 +0800 (CST) MIME-Version: 1.0 Message-ID: <3CBA256E.000021.27783@mta1> Date: Mon, 15 Apr 2002 08:57:18 +0800 (CST) To: manet@ietf.org X-Priority: 3 X-Originating-IP: [202.115.65.227] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Subject: [manet] =?gb2312?B?SG93IHRvIGNvdW50IGVuZCB0byBlbmQncyBkZWxheSA=?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I am a student,now I'm simultating mobile ad hoc whith ns2.I need to compare the performance of some routing protocols,such as AODV,DSR,TORA and etc.One important performance parameter is the end to end's delay.As a fresh man in using ns2,I'm not aware of how to count the end to end's delay with the trace file.If you know,please do me a favour.Thanks a lot. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun Apr 14 21:30:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24551 for ; Sun, 14 Apr 2002 21:30:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA24640 for manet-archive@odin.ietf.org; Sun, 14 Apr 2002 21:30:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23354; Sun, 14 Apr 2002 21:00:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA23296 for ; Sun, 14 Apr 2002 21:00:52 -0400 (EDT) Received: from 263.net ([202.96.44.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24259 for ; Sun, 14 Apr 2002 21:00:44 -0400 (EDT) From: ggfmusjc@263.net Received: by 263.net (Postfix, from userid 60001) id 8070F1C6DCA1B; Mon, 15 Apr 2002 08:57:18 +0800 (CST) MIME-Version: 1.0 Message-ID: <3CBA256E.000021.27783@mta1> Date: Mon, 15 Apr 2002 08:57:18 +0800 (CST) To: manet@ietf.org X-Priority: 3 X-Originating-IP: [202.115.65.227] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 Subject: [manet] =?gb2312?B?SG93IHRvIGNvdW50IGVuZCB0byBlbmQncyBkZWxheSA=?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org I am a student,now I'm simultating mobile ad hoc whith ns2.I need to compare the performance of some routing protocols,such as AODV,DSR,TORA and etc.One important performance parameter is the end to end's delay.As a fresh man in using ns2,I'm not aware of how to count the end to end's delay with the trace file.If you know,please do me a favour.Thanks a lot. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 15 10:35:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19131 for ; Mon, 15 Apr 2002 10:35:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14858; Mon, 15 Apr 2002 10:12:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28099 for ; Wed, 10 Apr 2002 19:50:15 -0400 (EDT) Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05518 for ; Wed, 10 Apr 2002 19:50:06 -0400 (EDT) Date: Wed, 10 Apr 2002 19:49:47 -0400 (EDT) From: Yih-Chun Hu X-Sender: yihchun@ux6.sp.cs.cmu.edu To: Pekka Savola cc: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org >Additional comment I just noticed: 'ACK Destination Address' in >Acknowledgment DSR Option seemed redundant to me, as the dstaddr in IP >header seems to serve exactly the same purpose. Did I miss something? Yep, you can technically piggyback it on something. Same deal with Route Error Destination Addresses. >> Maybe we could point out in the draft which types could legally be >> present. Perhaps I don't understand the concern, since the concept is that >> anything can be piggybacked in anything. > >.. except for a few exceptions. I don't see a concern as such here, but a >thing perhaps worth clarifying ("the usual DSR header combinations" or >whatnot). I guess I should think very carefully about "the prohibited DSR header combinations." I don't know that there are any; even bizzare things like source-routed route requests could be interesting (route request up to a point, where you know the rest of the route from there, or source route a request out to a certain point, then blossom it from there). >> Since each packet carries its own route, it's route is entirely determined >> by the (by definition consistant) state at the sender, and no other node's >> state. > >The last paragraph is not entirely true: the route can be affected by e.g. >an intermediate node salvaging the packet, right? The maximal salvage >count does limit how many times this can happen, so this couldn't result >in an endless loop, but quite often that's a tranistory state in regular >protocols too. Granted. We could prohibit a path from ever looping, but that would also prohibit backtracking. We don't allow looping (same path over and over again); we allow backtracking. >> >==> I see DSR header functions rather equivalent to link status sensing >> >(maintenance procedures, Send Queue, etc.) and others above. >> >> And they're all on-demand (not periodic). Maybe I don't understand what >> you're trying to say? > >Well, I just think that periodicity, as an "only" criterion, is not >necessarily an usable on. DSR does similar things like periodic activity, >with overhead in the form of DSR header, anyway -- at least when there is >traffic on the wire (e.g. network acknowledgements in route maintenance). There are things that other protocols do periodically: neighbor sense, route discovery, route maintenance, etc. But it does them ONLY when there's traffic on the wire. We say these are performed "on-demand" as a characterization of their frequency and efficiency. We also argue why we think on-demand protocols may be better in certain situations. >> When you put in the special addresses indicating a >> bidirectionality switch, the receivers know the directionality of their >> receive interface, and can deduce which parts of a source route must be >> bidirectional and which ones can have unidirectional links. > >I have a failure to grasp this. Do you mean that addressing could be used >to indicate bidirectionality? Well, this is one approach, but I don't >recall this in the draft? Section 7. It's new in -07. (Sorry) >> For example, >> when the route A->B->*->C->D->*->E is received at D, it knows whether it's >> interface is bidirectional or unidirectional. If it's unidirectional, it >> knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t >> out a bidirectional interface, it adds a * to the source route first. > >I'm not sure what you mean '*' here, so my comment may not be off the >mark. I fail to see how D could conclude anything of A->B or B->C based >on the bidirectionality of its own link? (Except if it knows the >directionality based on addresses or similar, but that's one approach I >was implicitly suggesting.) * is a "magic" address. So, looking at a source route backwards E<-*<-D<-C<-*<-B<-A E knows that the directionality of the c->d segment is different from the directionality of the d->e segment. Similarly, c knows that the directionality of the a->b segment is different from the directionality of the b->c segment. >> >This seems a rather big aasumption. >> It seems rather smaller than assuming that all interfaces are >> bidirectional. >I disagree, on practical terms: it is a rather big assumption *when* one >feature of DSR is exactly unidirectionality. If there is support, the >support should work. If there is no support, people who have this as a >requirement use different protocols. Hmm. Well, since you have to write a driver for an interface, I don't think that's a huge assumption that you know the directionality of one of your interfaces. You'd need to know that to decide whether or not you could even use one of the other protocols. >> I don't really want to belabor this point, because I don't >> think DSR's unidirectional support is very well tuned, and because the >> commodity standard for wireless interfaces these days is 802.11, which >> does require bidirectionality. > >If this is a practical "non-issue", I wonder if it would make sense to try >to define the main DSR proposal as bidirectional, and move unidirectional >parts to a separate draft. That's an "I" as a person, not an "I" speaking on behalf of all draft authors. >> No, it doesn't. You pick a route for the packet. You include the route in >> the packet. That route is loop-free, regardless of whether or not your >> cache is up-to-date. >> >> I also don't see why you couldn't verify loop-freedom if you really cared. >> If an address appears twice in the source route, then you've found a loop? > >True, for "loop-freeness" in the traditional meaning. If one includes >"inserting too long, very suboptimal paths, which do not have a loop", >this would be more difficult to verify. > >But I'm not sure of the threat model of this; my main worry was that if a >source knows a sub-optimal path, and that path will be cached on >intermediate nodes too, and that way it might be propagated to all nodes >querying for that destination (replies from the cache). If you're worried about malicious nodes being "stupid" and using long routes, I can assure you that there are many worse things that could be used as attacks. Automatic Route Shortening helps reduce the length of stale, long routes. Promiscuous overhearing works pretty well too. We have yet to find a reason that drives us to periodic path discovery to ensure freshness. >I'm not all that worried (except for severe implementation bugs) about >loopfreeness as such, but rather unoptimal paths (which may be "almost >loops") getting there. Any on-demand protocol without a periodic rediscovery mechanism has the same problem; once you set up a route, you don't really bother to look for a better one. >I'd add a note in security considerations about this at least, though, >because supporting DSR routing and supporting DSR header in the firewall >software are two rather separate issues, and the connection may not be >apparent. That's a good idea. >> What's the attacker model? Legitimate nodes failing in Byzantine ways? >> Multiple coordinated attackers with several compromised nodes? We specify >> that security considerations are out-of-scope, as in BGP (RFC1771). >> Security in manets are an active area of research... > >The attackers have many models, most of which are out of scope here, >especially if one wants byzantine robustness in the case of a captured >node feeding deliberately wrong information. > >One particular scenario I mentioned here was that a node that has old >cached data keeps propagating that information to nodes which do route >requests through it. Or salvage packets in non-optimal ways. This could >lead to a security problem (denial of service). But perhaps this "cache >freshness ensurance problem" needs to be addressed elsewhere. You'd eventually get route errors that flush out your cache if you're returning bogus routes on requests. For example, suppose A has two disjoint bogus routes to B in its cache, and C does a discovery for B. A returns a bogus route, C uses it, B forwards the corresponding route error. Now A only has one disjoint bogus route. Also, with the cache specified in appendix A, routes not actively in use are eventually timed out. Thanks for the comments, Yih-Chun > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 15 10:35:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19139 for ; Mon, 15 Apr 2002 10:35:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17295 for manet-archive@odin.ietf.org; Mon, 15 Apr 2002 10:35:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14858; Mon, 15 Apr 2002 10:12:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28099 for ; Wed, 10 Apr 2002 19:50:15 -0400 (EDT) Received: from ux6.sp.cs.cmu.edu (UX6.SP.CS.CMU.EDU [128.2.181.250]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05518 for ; Wed, 10 Apr 2002 19:50:06 -0400 (EDT) Date: Wed, 10 Apr 2002 19:49:47 -0400 (EDT) From: Yih-Chun Hu X-Sender: yihchun@ux6.sp.cs.cmu.edu To: Pekka Savola cc: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: New DSR Draft Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org >Additional comment I just noticed: 'ACK Destination Address' in >Acknowledgment DSR Option seemed redundant to me, as the dstaddr in IP >header seems to serve exactly the same purpose. Did I miss something? Yep, you can technically piggyback it on something. Same deal with Route Error Destination Addresses. >> Maybe we could point out in the draft which types could legally be >> present. Perhaps I don't understand the concern, since the concept is that >> anything can be piggybacked in anything. > >.. except for a few exceptions. I don't see a concern as such here, but a >thing perhaps worth clarifying ("the usual DSR header combinations" or >whatnot). I guess I should think very carefully about "the prohibited DSR header combinations." I don't know that there are any; even bizzare things like source-routed route requests could be interesting (route request up to a point, where you know the rest of the route from there, or source route a request out to a certain point, then blossom it from there). >> Since each packet carries its own route, it's route is entirely determined >> by the (by definition consistant) state at the sender, and no other node's >> state. > >The last paragraph is not entirely true: the route can be affected by e.g. >an intermediate node salvaging the packet, right? The maximal salvage >count does limit how many times this can happen, so this couldn't result >in an endless loop, but quite often that's a tranistory state in regular >protocols too. Granted. We could prohibit a path from ever looping, but that would also prohibit backtracking. We don't allow looping (same path over and over again); we allow backtracking. >> >==> I see DSR header functions rather equivalent to link status sensing >> >(maintenance procedures, Send Queue, etc.) and others above. >> >> And they're all on-demand (not periodic). Maybe I don't understand what >> you're trying to say? > >Well, I just think that periodicity, as an "only" criterion, is not >necessarily an usable on. DSR does similar things like periodic activity, >with overhead in the form of DSR header, anyway -- at least when there is >traffic on the wire (e.g. network acknowledgements in route maintenance). There are things that other protocols do periodically: neighbor sense, route discovery, route maintenance, etc. But it does them ONLY when there's traffic on the wire. We say these are performed "on-demand" as a characterization of their frequency and efficiency. We also argue why we think on-demand protocols may be better in certain situations. >> When you put in the special addresses indicating a >> bidirectionality switch, the receivers know the directionality of their >> receive interface, and can deduce which parts of a source route must be >> bidirectional and which ones can have unidirectional links. > >I have a failure to grasp this. Do you mean that addressing could be used >to indicate bidirectionality? Well, this is one approach, but I don't >recall this in the draft? Section 7. It's new in -07. (Sorry) >> For example, >> when the route A->B->*->C->D->*->E is received at D, it knows whether it's >> interface is bidirectional or unidirectional. If it's unidirectional, it >> knows A->B is bidirectional, B->C->D is unidirectional. When it sendsi t >> out a bidirectional interface, it adds a * to the source route first. > >I'm not sure what you mean '*' here, so my comment may not be off the >mark. I fail to see how D could conclude anything of A->B or B->C based >on the bidirectionality of its own link? (Except if it knows the >directionality based on addresses or similar, but that's one approach I >was implicitly suggesting.) * is a "magic" address. So, looking at a source route backwards E<-*<-D<-C<-*<-B<-A E knows that the directionality of the c->d segment is different from the directionality of the d->e segment. Similarly, c knows that the directionality of the a->b segment is different from the directionality of the b->c segment. >> >This seems a rather big aasumption. >> It seems rather smaller than assuming that all interfaces are >> bidirectional. >I disagree, on practical terms: it is a rather big assumption *when* one >feature of DSR is exactly unidirectionality. If there is support, the >support should work. If there is no support, people who have this as a >requirement use different protocols. Hmm. Well, since you have to write a driver for an interface, I don't think that's a huge assumption that you know the directionality of one of your interfaces. You'd need to know that to decide whether or not you could even use one of the other protocols. >> I don't really want to belabor this point, because I don't >> think DSR's unidirectional support is very well tuned, and because the >> commodity standard for wireless interfaces these days is 802.11, which >> does require bidirectionality. > >If this is a practical "non-issue", I wonder if it would make sense to try >to define the main DSR proposal as bidirectional, and move unidirectional >parts to a separate draft. That's an "I" as a person, not an "I" speaking on behalf of all draft authors. >> No, it doesn't. You pick a route for the packet. You include the route in >> the packet. That route is loop-free, regardless of whether or not your >> cache is up-to-date. >> >> I also don't see why you couldn't verify loop-freedom if you really cared. >> If an address appears twice in the source route, then you've found a loop? > >True, for "loop-freeness" in the traditional meaning. If one includes >"inserting too long, very suboptimal paths, which do not have a loop", >this would be more difficult to verify. > >But I'm not sure of the threat model of this; my main worry was that if a >source knows a sub-optimal path, and that path will be cached on >intermediate nodes too, and that way it might be propagated to all nodes >querying for that destination (replies from the cache). If you're worried about malicious nodes being "stupid" and using long routes, I can assure you that there are many worse things that could be used as attacks. Automatic Route Shortening helps reduce the length of stale, long routes. Promiscuous overhearing works pretty well too. We have yet to find a reason that drives us to periodic path discovery to ensure freshness. >I'm not all that worried (except for severe implementation bugs) about >loopfreeness as such, but rather unoptimal paths (which may be "almost >loops") getting there. Any on-demand protocol without a periodic rediscovery mechanism has the same problem; once you set up a route, you don't really bother to look for a better one. >I'd add a note in security considerations about this at least, though, >because supporting DSR routing and supporting DSR header in the firewall >software are two rather separate issues, and the connection may not be >apparent. That's a good idea. >> What's the attacker model? Legitimate nodes failing in Byzantine ways? >> Multiple coordinated attackers with several compromised nodes? We specify >> that security considerations are out-of-scope, as in BGP (RFC1771). >> Security in manets are an active area of research... > >The attackers have many models, most of which are out of scope here, >especially if one wants byzantine robustness in the case of a captured >node feeding deliberately wrong information. > >One particular scenario I mentioned here was that a node that has old >cached data keeps propagating that information to nodes which do route >requests through it. Or salvage packets in non-optimal ways. This could >lead to a security problem (denial of service). But perhaps this "cache >freshness ensurance problem" needs to be addressed elsewhere. You'd eventually get route errors that flush out your cache if you're returning bogus routes on requests. For example, suppose A has two disjoint bogus routes to B in its cache, and C does a discovery for B. A returns a bogus route, C uses it, B forwards the corresponding route error. Now A only has one disjoint bogus route. Also, with the cache specified in appendix A, routes not actively in use are eventually timed out. Thanks for the comments, Yih-Chun > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 15 10:37:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19199 for ; Mon, 15 Apr 2002 10:37:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14921; Mon, 15 Apr 2002 10:12:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29115 for ; Wed, 10 Apr 2002 20:04:16 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05663 for ; Wed, 10 Apr 2002 20:04:11 -0400 (EDT) Received: from blind (blind [128.111.49.140]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3B049O13153; Wed, 10 Apr 2002 17:04:09 -0700 (PDT) Date: Wed, 10 Apr 2002 17:04:09 -0700 (PDT) From: MobiHoc 2002 X-Sender: mobihoc@blind To: MobiHoc 2002 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Mobihoc 2002: Early Registration Deadline Approaching! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Please note: The early registration deadline is *April 22nd*. Register now to guarantee the reduced registration fee! --------------------------------------------------------------------------- ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiHoc 2002 The Third ACM International Symposium on Mobile Ad Hoc Networking and Computing Lausanne, Switzerland June 9-11, 2002 http://www.acm.org/sigmobile/mobihoc/2002/ Sponsored by ACM SIGMOBILE http://www.acm.org/sigmobile/ MobiHoc 2002 is the third of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 in Long Beach, California, and now in 2002 in Lausanne, Switzerland. Topics of interest include all areas of mobile and wireless ad hoc networking (above the physical layer), ad hoc computing, and sensor networks. PAPERS: There will be approximately seven technical paper sessions on a wide range of ad hoc networking topics. The list of accepted papers can be found at http://www.acm.org/sigmobile/mobihoc/2002/program.html. Paper topics include routing, sensor networks, scalability, multicast, energy consumption, TCP, and priority scheduling. POSTERS: There will also be a poster session, describing innovative and recent research on ad hoc networks. TUTORIALS: This year there is a new component to MobiHoc: technical tutorials. On June 9th there will be two tutorials. "Design and Modeling of Medium Access Control Protocols for Wireless Ad Hoc Networks" will be held in the morning, and "Routing & Multicasting in Ad hoc Networks" will be held in the afternoon. HOTEL and REGISTRATION: Hotel information is currently available on-line, and the symposium is open for registration. Register by April 22, 2002 to get the early registration rates. IMPORTANT DATES: Early Registration Deadline: April 22, 2002 Tutorials: June 9, 2002 Conference: June 10-11, 2002 FOR MORE INFORMATION: Please visit the MobiHoc 2002 Home Page at http://www.acm.org/sigmobile/mobihoc/2002/ or send email to mobihoc@epfl.ch for any questions or for more information about the symposium. ORGANIZING COMMITTEE: General Chair Jean-Pierre Hubaux EPFL (CH) jean-pierre.hubaux@epfl.ch Program Co-Chairs J.J. Garcia-Luna-Aceves David B. Johnson Univ. California, Santa Cruz (US) Rice University (US) jj@cs.ucsc.edu dbj@cs.rice.edu Tutorials Co-Chairs Adam Wolisz Mario Gerla Technical Univ. of Berlin (DE) Univ. California, Los Angeles (US) wolisz@ee.tu-berlin.de gerla@cs.ucla.edu Finance Chair Local Arrangements Chair Rachid Guerraoui Silvia Giordano EPFL (CH) EPFL (CH) rachid.guerraoui@epfl.ch silvia.giordano@epfl.ch Publicity Chair Publication Chair Elizabeth M. Belding-Royer Robin Kravets Univ. Calif., Santa Barbara (US) Univ. Illinois, Urbana-Champaign (US) ebelding@cs.ucsb.edu rhk@cs.uiuc.edu Registration Chair Srdjan Capkun EPFL (CH) srdan.capkun@epfl.ch Steering Committee Andrew T. Campbell Charles E. Perkins J.J. Garcia-Luna-Aceves Ram Ramanathan Mario Gerla Martha Steenstrup Joseph P. Macker Nitin H. Vaidya ACM Program Director Ginger Ignatoff --------------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 15 10:37:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19208 for ; Mon, 15 Apr 2002 10:37:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17433 for manet-archive@odin.ietf.org; Mon, 15 Apr 2002 10:37:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14921; Mon, 15 Apr 2002 10:12:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29115 for ; Wed, 10 Apr 2002 20:04:16 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05663 for ; Wed, 10 Apr 2002 20:04:11 -0400 (EDT) Received: from blind (blind [128.111.49.140]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3B049O13153; Wed, 10 Apr 2002 17:04:09 -0700 (PDT) Date: Wed, 10 Apr 2002 17:04:09 -0700 (PDT) From: MobiHoc 2002 X-Sender: mobihoc@blind To: MobiHoc 2002 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Mobihoc 2002: Early Registration Deadline Approaching! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Please note: The early registration deadline is *April 22nd*. Register now to guarantee the reduced registration fee! --------------------------------------------------------------------------- ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiHoc 2002 The Third ACM International Symposium on Mobile Ad Hoc Networking and Computing Lausanne, Switzerland June 9-11, 2002 http://www.acm.org/sigmobile/mobihoc/2002/ Sponsored by ACM SIGMOBILE http://www.acm.org/sigmobile/ MobiHoc 2002 is the third of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 in Long Beach, California, and now in 2002 in Lausanne, Switzerland. Topics of interest include all areas of mobile and wireless ad hoc networking (above the physical layer), ad hoc computing, and sensor networks. PAPERS: There will be approximately seven technical paper sessions on a wide range of ad hoc networking topics. The list of accepted papers can be found at http://www.acm.org/sigmobile/mobihoc/2002/program.html. Paper topics include routing, sensor networks, scalability, multicast, energy consumption, TCP, and priority scheduling. POSTERS: There will also be a poster session, describing innovative and recent research on ad hoc networks. TUTORIALS: This year there is a new component to MobiHoc: technical tutorials. On June 9th there will be two tutorials. "Design and Modeling of Medium Access Control Protocols for Wireless Ad Hoc Networks" will be held in the morning, and "Routing & Multicasting in Ad hoc Networks" will be held in the afternoon. HOTEL and REGISTRATION: Hotel information is currently available on-line, and the symposium is open for registration. Register by April 22, 2002 to get the early registration rates. IMPORTANT DATES: Early Registration Deadline: April 22, 2002 Tutorials: June 9, 2002 Conference: June 10-11, 2002 FOR MORE INFORMATION: Please visit the MobiHoc 2002 Home Page at http://www.acm.org/sigmobile/mobihoc/2002/ or send email to mobihoc@epfl.ch for any questions or for more information about the symposium. ORGANIZING COMMITTEE: General Chair Jean-Pierre Hubaux EPFL (CH) jean-pierre.hubaux@epfl.ch Program Co-Chairs J.J. Garcia-Luna-Aceves David B. Johnson Univ. California, Santa Cruz (US) Rice University (US) jj@cs.ucsc.edu dbj@cs.rice.edu Tutorials Co-Chairs Adam Wolisz Mario Gerla Technical Univ. of Berlin (DE) Univ. California, Los Angeles (US) wolisz@ee.tu-berlin.de gerla@cs.ucla.edu Finance Chair Local Arrangements Chair Rachid Guerraoui Silvia Giordano EPFL (CH) EPFL (CH) rachid.guerraoui@epfl.ch silvia.giordano@epfl.ch Publicity Chair Publication Chair Elizabeth M. Belding-Royer Robin Kravets Univ. Calif., Santa Barbara (US) Univ. Illinois, Urbana-Champaign (US) ebelding@cs.ucsb.edu rhk@cs.uiuc.edu Registration Chair Srdjan Capkun EPFL (CH) srdan.capkun@epfl.ch Steering Committee Andrew T. Campbell Charles E. Perkins J.J. Garcia-Luna-Aceves Ram Ramanathan Mario Gerla Martha Steenstrup Joseph P. Macker Nitin H. Vaidya ACM Program Director Ginger Ignatoff --------------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 15 16:22:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05696 for ; Mon, 15 Apr 2002 16:22:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08779; Mon, 15 Apr 2002 15:42:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08752 for ; Mon, 15 Apr 2002 15:42:50 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04404 for ; Mon, 15 Apr 2002 15:42:46 -0400 (EDT) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g3FJgiO24382; Mon, 15 Apr 2002 12:42:44 -0700 (PDT) Message-Id: <200204151942.g3FJgiO24382@letters.cs.ucsb.edu> Date: Mon, 15 Apr 2002 12:42:44 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: manet@ietf.org, aodvimpl-public@lists.sourceforge.net Cc: eroyer@cs.ucsb.edu, charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uR7ipLUkzrKsADhIFfKniw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [manet] AODV Next Generation (AODVng) 2002 Workshop Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org We are pleased to announce the AODV Next Generation (AODVng) 2002 Workshop, the first workshop on the Ad hoc On-Demand Distance Vector (AODV) routing protocol. AODVng 2002, held in conjunction with the Third ACM International Symposium on Mobile Ad Hoc Networking and Computing (Mobihoc) 2002, will bring together researchers and engineers who have experience working with AODV, to discuss future directions and enhancements for AODV. The workshop will include presentations by participants, as well as a discussion session on suggested extensions to the basic AODV protocol. The setting of the workshop is informal, and will take place at Ecole Polytechnique Federale de Lausanne (EPFL), the same site as Mobihoc. Date: June 8, 2002 Location: Lausanne, Switzerland We invite one-page abstracts describing recent work related to AODV. If your abstract is accepted, you will be asked to give a presentation on this work at the workshop. There will be no formal proceedings from the workshop, although during the workshop we may decide on some avenue for a publication describing the event. Participation in the workshop is by invitation only. Because of the limited time available, there are currently no plans for interoperability testing at this event. If there is interest, we can use part of the workshop time to plan the next such event. Also, informal interoperability testing may be possible. Topics of interest include, but are not limited to: - Quality of Service - Multi-path routing - Security - Uni-directional links - Implementation and test-bed experience - Energy usage - Scalability - Interoperability testing and future events - Freely available implementations and simulations - Location-aware routing - Scatternet formation - Limiting rebroadcasts for flooding (broadcast backbones) - Parameter selection for specific mobility and traffic scenarios - Service discovery Note that the topic must be related to the AODV protocol, and geared towards future improvement. Submission Instructions: All submissions will be handled electronically and must be in ASCII text, PDF or PostScript format. Submissions must be in the form of an abstract and must not exceed *500 words*. Because there will not be any formal proceedings, the work may be previously published elsewhere. The proposal may also be a work-in-progress, although meaningful results must be included. Please send submissions to Charles E. Perkins at charliep@iprg.nokia.com. Submission Deadline: *April 30, 2002* Notification of Acceptance: May 10, 2002 For more information, visit the AODVng Workshop homepage at http://moment.cs.ucsb.edu/AODV/workshop.html, or send email to Charles Perkins (charliep@iprg.nokia.com) or Elizabeth Belding-Royer (ebelding@cs.ucsb.edu) for any questions or more information. Organizers: Charles E. Perkins, Nokia Research Center Elizabeth M. Belding-Royer, UC Santa Barbara _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Apr 15 16:22:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05708 for ; Mon, 15 Apr 2002 16:22:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11377 for manet-archive@odin.ietf.org; Mon, 15 Apr 2002 16:22:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08779; Mon, 15 Apr 2002 15:42:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08752 for ; Mon, 15 Apr 2002 15:42:50 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04404 for ; Mon, 15 Apr 2002 15:42:46 -0400 (EDT) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g3FJgiO24382; Mon, 15 Apr 2002 12:42:44 -0700 (PDT) Message-Id: <200204151942.g3FJgiO24382@letters.cs.ucsb.edu> Date: Mon, 15 Apr 2002 12:42:44 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: manet@ietf.org, aodvimpl-public@lists.sourceforge.net Cc: eroyer@cs.ucsb.edu, charliep@iprg.nokia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uR7ipLUkzrKsADhIFfKniw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [manet] AODV Next Generation (AODVng) 2002 Workshop Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org We are pleased to announce the AODV Next Generation (AODVng) 2002 Workshop, the first workshop on the Ad hoc On-Demand Distance Vector (AODV) routing protocol. AODVng 2002, held in conjunction with the Third ACM International Symposium on Mobile Ad Hoc Networking and Computing (Mobihoc) 2002, will bring together researchers and engineers who have experience working with AODV, to discuss future directions and enhancements for AODV. The workshop will include presentations by participants, as well as a discussion session on suggested extensions to the basic AODV protocol. The setting of the workshop is informal, and will take place at Ecole Polytechnique Federale de Lausanne (EPFL), the same site as Mobihoc. Date: June 8, 2002 Location: Lausanne, Switzerland We invite one-page abstracts describing recent work related to AODV. If your abstract is accepted, you will be asked to give a presentation on this work at the workshop. There will be no formal proceedings from the workshop, although during the workshop we may decide on some avenue for a publication describing the event. Participation in the workshop is by invitation only. Because of the limited time available, there are currently no plans for interoperability testing at this event. If there is interest, we can use part of the workshop time to plan the next such event. Also, informal interoperability testing may be possible. Topics of interest include, but are not limited to: - Quality of Service - Multi-path routing - Security - Uni-directional links - Implementation and test-bed experience - Energy usage - Scalability - Interoperability testing and future events - Freely available implementations and simulations - Location-aware routing - Scatternet formation - Limiting rebroadcasts for flooding (broadcast backbones) - Parameter selection for specific mobility and traffic scenarios - Service discovery Note that the topic must be related to the AODV protocol, and geared towards future improvement. Submission Instructions: All submissions will be handled electronically and must be in ASCII text, PDF or PostScript format. Submissions must be in the form of an abstract and must not exceed *500 words*. Because there will not be any formal proceedings, the work may be previously published elsewhere. The proposal may also be a work-in-progress, although meaningful results must be included. Please send submissions to Charles E. Perkins at charliep@iprg.nokia.com. Submission Deadline: *April 30, 2002* Notification of Acceptance: May 10, 2002 For more information, visit the AODVng Workshop homepage at http://moment.cs.ucsb.edu/AODV/workshop.html, or send email to Charles Perkins (charliep@iprg.nokia.com) or Elizabeth Belding-Royer (ebelding@cs.ucsb.edu) for any questions or more information. Organizers: Charles E. Perkins, Nokia Research Center Elizabeth M. Belding-Royer, UC Santa Barbara _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 16 07:08:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29043 for ; Tue, 16 Apr 2002 07:08:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02665; Tue, 16 Apr 2002 06:12:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02595 for ; Tue, 16 Apr 2002 06:12:33 -0400 (EDT) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28210 for ; Tue, 16 Apr 2002 06:12:28 -0400 (EDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.cluster.oleane.net with SMTP id g3GACQ305086 for ; Tue, 16 Apr 2002 12:12:26 +0200 (CEST) Message-ID: <005e01c1e52f$bc28d220$0701a8c0@oleane.com> From: "Peter Lewis" To: Date: Tue, 16 Apr 2002 12:16:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C1E540.7F5614A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [manet] "WLAN Security 2002" conference Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C1E540.7F5614A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The "WLAN Security 2002" conference, to take place June 25-28 in Paris, = will feature the most eminent specialists in the domain of security = applied to wireless local area networks.=20 The conference will serve as an occasion to clearly distinguish between = the various technical solutions proposed today, and identify the = weaknesses of each in terms of security: Bluetooth, IEEE802.11a/b, = IEEE1394.=20 All details at: http://www.upperside.fr/wlansecu/wlansecintro.htm ------=_NextPart_000_005B_01C1E540.7F5614A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The "WLAN Security = 2002"=20 conference, to take place June 25-28 in Paris, will feature the most = eminent=20 specialists in the domain of security applied to wireless local area = networks.=20

The conference will serve as an occasion to clearly distinguish = between=20 the various technical solutions proposed today, and identify the = weaknesses of=20 each in terms of security: Bluetooth, IEEE802.11a/b, IEEE1394. =

All=20 details at:
http://www.upp= erside.fr/wlansecu/wlansecintro.htm
 
 
------=_NextPart_000_005B_01C1E540.7F5614A0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 16 07:08:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29052 for ; Tue, 16 Apr 2002 07:08:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05402 for manet-archive@odin.ietf.org; Tue, 16 Apr 2002 07:08:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02665; Tue, 16 Apr 2002 06:12:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02595 for ; Tue, 16 Apr 2002 06:12:33 -0400 (EDT) Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28210 for ; Tue, 16 Apr 2002 06:12:28 -0400 (EDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.cluster.oleane.net with SMTP id g3GACQ305086 for ; Tue, 16 Apr 2002 12:12:26 +0200 (CEST) Message-ID: <005e01c1e52f$bc28d220$0701a8c0@oleane.com> From: "Peter Lewis" To: Date: Tue, 16 Apr 2002 12:16:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C1E540.7F5614A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [manet] "WLAN Security 2002" conference Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C1E540.7F5614A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The "WLAN Security 2002" conference, to take place June 25-28 in Paris, = will feature the most eminent specialists in the domain of security = applied to wireless local area networks.=20 The conference will serve as an occasion to clearly distinguish between = the various technical solutions proposed today, and identify the = weaknesses of each in terms of security: Bluetooth, IEEE802.11a/b, = IEEE1394.=20 All details at: http://www.upperside.fr/wlansecu/wlansecintro.htm ------=_NextPart_000_005B_01C1E540.7F5614A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The "WLAN Security = 2002"=20 conference, to take place June 25-28 in Paris, will feature the most = eminent=20 specialists in the domain of security applied to wireless local area = networks.=20

The conference will serve as an occasion to clearly distinguish = between=20 the various technical solutions proposed today, and identify the = weaknesses of=20 each in terms of security: Bluetooth, IEEE802.11a/b, IEEE1394. =

All=20 details at:
http://www.upp= erside.fr/wlansecu/wlansecintro.htm
 
 
------=_NextPart_000_005B_01C1E540.7F5614A0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 17 19:22:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10705 for ; Wed, 17 Apr 2002 19:22:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23963; Wed, 17 Apr 2002 18:46:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23932 for ; Wed, 17 Apr 2002 18:46:48 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10077 for ; Wed, 17 Apr 2002 18:46:45 -0400 (EDT) Received: (qmail 32562 invoked by uid 0); 17 Apr 2002 22:46:13 -0000 Received: from meitner.wh.uni-dortmund.de (HELO dennisboelting) (129.217.129.133) by mail.gmx.net (mp014-rz3) with SMTP; 17 Apr 2002 22:46:13 -0000 From: =?iso-8859-1?Q?Dennis_B=F6lting?= To: Date: Thu, 18 Apr 2002 00:46:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 8bit Subject: [manet] MAODV and NS-2 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, please let me know if anyone of you has implemented the AODV multicast extension (MAODV) on the ns. I want to develop some reliable multicast protocol for ad hoc networks, and for the multicast tree construction, I wish to use MAODV. I shall therefore be needing the source files for MAODV. Maybe you can help me. Regards Dennis --- Cand.-Inf. Dennis Bölting Meitnerweg 8 Zimmer 222 44227 Dortmund Tel: 0231/7950660 ICQ: 71370496 Email: Dennis.Boelting@gmx.de _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Apr 17 19:22:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10716 for ; Wed, 17 Apr 2002 19:22:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26247 for manet-archive@odin.ietf.org; Wed, 17 Apr 2002 19:22:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23963; Wed, 17 Apr 2002 18:46:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23932 for ; Wed, 17 Apr 2002 18:46:48 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10077 for ; Wed, 17 Apr 2002 18:46:45 -0400 (EDT) Received: (qmail 32562 invoked by uid 0); 17 Apr 2002 22:46:13 -0000 Received: from meitner.wh.uni-dortmund.de (HELO dennisboelting) (129.217.129.133) by mail.gmx.net (mp014-rz3) with SMTP; 17 Apr 2002 22:46:13 -0000 From: =?iso-8859-1?Q?Dennis_B=F6lting?= To: Date: Thu, 18 Apr 2002 00:46:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 8bit Subject: [manet] MAODV and NS-2 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi, please let me know if anyone of you has implemented the AODV multicast extension (MAODV) on the ns. I want to develop some reliable multicast protocol for ad hoc networks, and for the multicast tree construction, I wish to use MAODV. I shall therefore be needing the source files for MAODV. Maybe you can help me. Regards Dennis --- Cand.-Inf. Dennis Bölting Meitnerweg 8 Zimmer 222 44227 Dortmund Tel: 0231/7950660 ICQ: 71370496 Email: Dennis.Boelting@gmx.de _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 18 03:45:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28279 for ; Thu, 18 Apr 2002 03:45:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01567; Thu, 18 Apr 2002 03:18:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01540 for ; Thu, 18 Apr 2002 03:18:04 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27722 for ; Thu, 18 Apr 2002 03:17:59 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3I7HQd16609; Thu, 18 Apr 2002 10:17:26 +0300 Date: Thu, 18 Apr 2002 10:17:26 +0300 (EEST) From: Pekka Savola To: Pete Sholander cc: charliep@iprg.nokia.com, Subject: Re: [manet] AODV QoS incompatible with IPSEC In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Mon, 8 Apr 2002, Pete Sholander wrote: > Pekka ... It's well-known the QoS signaling protocols typically require > hop-by-hop security. The ATM Forum's work on S-PNNI is one practical > example. I don't dispute this; as you note, I was complaining about the fact that AODV QoS draft does not mention this "well-known fact"; the security considerations are not the same as with AODV, as stated in the draft. > >>> Pekka Savola 04/07/02 11:00AM >>> > Hi, > > I just glanced through a summary of QoS for AODV and noticed the > following in draft-perkins-manet-aodvqos-00.txt: > > --8<-- > 5. Security Considerations > > This draft specifies mechanisms for handling quality of service. It > does not introduce any special security considerations which were not > already present in the AODV routing protocol [2]. > --8<-- > > This is untrue, because: > > --8<-- > Before forwarding the RREQ, an intermediate node MUST compare its > NODE_TRAVERSAL_TIME to the (remaining) Delay indicated in the Maximum > Delay Extension. If the Delay is less, the node MUST discard the > RREQ and not process it any further. Otherwise, the node subtracts > NODE_TRAVERSAL_TIME from the Delay value in the extension and > continues processing the RREQ as specified in [2]. > > [...] > > Before forwarding the RREQ, an intermediate node MUST compare its > approximate jitter to the (remaining) Jitter indicated in the Maximum > Jitter Extension. If the Jitter is less, the node MUST discard the > RREQ and not process it any further. Otherwise, the node subtracts > --8<-- > (note subtract above) > > Intermediate nodes modifying the packet for all practical purposes kills > IPSEC except for an keys-shared-by-everyone method (only one applicable to > e.g. DSR I think). > > IPSEC (to secure the routing messages) seems to be possible with AODV, but > not with AODV QoS extensions. > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 18 03:45:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28296 for ; Thu, 18 Apr 2002 03:45:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA03879 for manet-archive@odin.ietf.org; Thu, 18 Apr 2002 03:45:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01567; Thu, 18 Apr 2002 03:18:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01540 for ; Thu, 18 Apr 2002 03:18:04 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27722 for ; Thu, 18 Apr 2002 03:17:59 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3I7HQd16609; Thu, 18 Apr 2002 10:17:26 +0300 Date: Thu, 18 Apr 2002 10:17:26 +0300 (EEST) From: Pekka Savola To: Pete Sholander cc: charliep@iprg.nokia.com, Subject: Re: [manet] AODV QoS incompatible with IPSEC In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Mon, 8 Apr 2002, Pete Sholander wrote: > Pekka ... It's well-known the QoS signaling protocols typically require > hop-by-hop security. The ATM Forum's work on S-PNNI is one practical > example. I don't dispute this; as you note, I was complaining about the fact that AODV QoS draft does not mention this "well-known fact"; the security considerations are not the same as with AODV, as stated in the draft. > >>> Pekka Savola 04/07/02 11:00AM >>> > Hi, > > I just glanced through a summary of QoS for AODV and noticed the > following in draft-perkins-manet-aodvqos-00.txt: > > --8<-- > 5. Security Considerations > > This draft specifies mechanisms for handling quality of service. It > does not introduce any special security considerations which were not > already present in the AODV routing protocol [2]. > --8<-- > > This is untrue, because: > > --8<-- > Before forwarding the RREQ, an intermediate node MUST compare its > NODE_TRAVERSAL_TIME to the (remaining) Delay indicated in the Maximum > Delay Extension. If the Delay is less, the node MUST discard the > RREQ and not process it any further. Otherwise, the node subtracts > NODE_TRAVERSAL_TIME from the Delay value in the extension and > continues processing the RREQ as specified in [2]. > > [...] > > Before forwarding the RREQ, an intermediate node MUST compare its > approximate jitter to the (remaining) Jitter indicated in the Maximum > Jitter Extension. If the Jitter is less, the node MUST discard the > RREQ and not process it any further. Otherwise, the node subtracts > --8<-- > (note subtract above) > > Intermediate nodes modifying the packet for all practical purposes kills > IPSEC except for an keys-shared-by-everyone method (only one applicable to > e.g. DSR I think). > > IPSEC (to secure the routing messages) seems to be possible with AODV, but > not with AODV QoS extensions. > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 18 03:50:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28360 for ; Thu, 18 Apr 2002 03:50:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02498; Thu, 18 Apr 2002 03:30:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02455 for ; Thu, 18 Apr 2002 03:30:03 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27954 for ; Thu, 18 Apr 2002 03:29:58 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3I7TV016672 for ; Thu, 18 Apr 2002 10:29:31 +0300 Date: Thu, 18 Apr 2002 10:29:31 +0300 (EEST) From: Pekka Savola To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Security Considerations of AODV Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, The first paragraph of the AODV security considerations basically says the AODV packets should be authenticated. The second paragraph seems to suggest that the _data_ sent between the nodes could be authenticated. This appears to be the case. This could also be interpreted to mean about AODV control packets, which would be wrong. Where is the discussion about securing AODV control messages? If it cannot be done, it should also be stated. From Hop Count and other values which seem to be modifiable in transit it appears that "hop-by-hop" security associations, every node having to trust its neighbors (thus expanding the ring of trust) would be necessary: security of AODV protocol between non-neighbor AODV nodes does not appear to be possible. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 18 03:50:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28373 for ; Thu, 18 Apr 2002 03:50:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA04160 for manet-archive@odin.ietf.org; Thu, 18 Apr 2002 03:50:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02498; Thu, 18 Apr 2002 03:30:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02455 for ; Thu, 18 Apr 2002 03:30:03 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27954 for ; Thu, 18 Apr 2002 03:29:58 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3I7TV016672 for ; Thu, 18 Apr 2002 10:29:31 +0300 Date: Thu, 18 Apr 2002 10:29:31 +0300 (EEST) From: Pekka Savola To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Security Considerations of AODV Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello, The first paragraph of the AODV security considerations basically says the AODV packets should be authenticated. The second paragraph seems to suggest that the _data_ sent between the nodes could be authenticated. This appears to be the case. This could also be interpreted to mean about AODV control packets, which would be wrong. Where is the discussion about securing AODV control messages? If it cannot be done, it should also be stated. From Hop Count and other values which seem to be modifiable in transit it appears that "hop-by-hop" security associations, every node having to trust its neighbors (thus expanding the ring of trust) would be necessary: security of AODV protocol between non-neighbor AODV nodes does not appear to be possible. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 18 04:53:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29227 for ; Thu, 18 Apr 2002 04:53:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06732; Thu, 18 Apr 2002 04:27:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06708 for ; Thu, 18 Apr 2002 04:27:13 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28863 for ; Thu, 18 Apr 2002 04:27:08 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3I8RTF17114 for ; Thu, 18 Apr 2002 11:27:29 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Apr 2002 11:27:10 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 18 Apr 2002 11:27:10 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA12270; Thu, 18 Apr 2002 11:27:09 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CBE830C.1090505@nokia.com> Date: Thu, 18 Apr 2002 11:25:48 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Pekka Savola CC: manet@ietf.org Subject: Re: [manet] Security Considerations of AODV References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2002 08:27:10.0201 (UTC) FILETIME=[D567EE90:01C1E6B2] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Moi Pekka, Securing AODV messages is possible. I recomend you to take a look to my SAODV draft: http://ant.eupvg.upc.es/~tarom/draft-tarom-manet-saodv-00.txt You have pointed out one of the biggest problems I had when designing SAODV: the mutable fields (i.e. hop count). Luckily Asokan came with the proposal of using hash chains to secure the hop count. And, although there are certain possible attacks against the authentication of the hop count, I'm pretty satisfied about the overall security that SAODV is now providing. (Except maybe in the RERR messages, where more work still needs to be done) BR/ManelG ext Pekka Savola wrote: > Hello, > > The first paragraph of the AODV security considerations basically says the > AODV packets should be authenticated. > > The second paragraph seems to suggest that the _data_ sent between the > nodes could be authenticated. This appears to be the case. This could > also be interpreted to mean about AODV control packets, which would be > wrong. > > Where is the discussion about securing AODV control messages? If it > cannot be done, it should also be stated. > > From Hop Count and other values which seem to be modifiable in transit it > appears that "hop-by-hop" security associations, every node having to > trust its neighbors (thus expanding the ring of trust) would be necessary: > security of AODV protocol between non-neighbor AODV nodes does not appear > to be possible. > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 18 04:53:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29238 for ; Thu, 18 Apr 2002 04:53:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA08984 for manet-archive@odin.ietf.org; Thu, 18 Apr 2002 04:53:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06732; Thu, 18 Apr 2002 04:27:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06708 for ; Thu, 18 Apr 2002 04:27:13 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28863 for ; Thu, 18 Apr 2002 04:27:08 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3I8RTF17114 for ; Thu, 18 Apr 2002 11:27:29 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Apr 2002 11:27:10 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 18 Apr 2002 11:27:10 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA12270; Thu, 18 Apr 2002 11:27:09 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CBE830C.1090505@nokia.com> Date: Thu, 18 Apr 2002 11:25:48 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Pekka Savola CC: manet@ietf.org Subject: Re: [manet] Security Considerations of AODV References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2002 08:27:10.0201 (UTC) FILETIME=[D567EE90:01C1E6B2] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Moi Pekka, Securing AODV messages is possible. I recomend you to take a look to my SAODV draft: http://ant.eupvg.upc.es/~tarom/draft-tarom-manet-saodv-00.txt You have pointed out one of the biggest problems I had when designing SAODV: the mutable fields (i.e. hop count). Luckily Asokan came with the proposal of using hash chains to secure the hop count. And, although there are certain possible attacks against the authentication of the hop count, I'm pretty satisfied about the overall security that SAODV is now providing. (Except maybe in the RERR messages, where more work still needs to be done) BR/ManelG ext Pekka Savola wrote: > Hello, > > The first paragraph of the AODV security considerations basically says the > AODV packets should be authenticated. > > The second paragraph seems to suggest that the _data_ sent between the > nodes could be authenticated. This appears to be the case. This could > also be interpreted to mean about AODV control packets, which would be > wrong. > > Where is the discussion about securing AODV control messages? If it > cannot be done, it should also be stated. > > From Hop Count and other values which seem to be modifiable in transit it > appears that "hop-by-hop" security associations, every node having to > trust its neighbors (thus expanding the ring of trust) would be necessary: > security of AODV protocol between non-neighbor AODV nodes does not appear > to be possible. > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 18 11:59:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12053 for ; Thu, 18 Apr 2002 11:59:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05195; Thu, 18 Apr 2002 11:29:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05164 for ; Thu, 18 Apr 2002 11:29:25 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10646 for ; Thu, 18 Apr 2002 11:29:15 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3IFSCR21859; Thu, 18 Apr 2002 17:28:13 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3IFSDX15005; Thu, 18 Apr 2002 17:28:13 +0200 (MEST) Message-ID: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "Manel Guerrero Zapata" Cc: Subject: Re: [manet] Security Considerations of AODV Date: Thu, 18 Apr 2002 17:11:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello Manel, If i understand well the hash chains mechanism described in your draft prevents a bad guy from modifying the HopCount field, right? But why prevents a bad guy from not performing the hash of the HopCount and just forwarding the packet as it is? As a result, the path might appear shorter that what it really is and might end-up being selected (this might be the goal of the attacker..)? Did i miss something? thanks in advance for the clarification, Claude. -----Message d'origine----- De : Manel Guerrero Zapata À : ext Pekka Savola Cc : manet@ietf.org Date : jeudi 18 avril 2002 10:28 Objet : Re: [manet] Security Considerations of AODV >Moi Pekka, > >Securing AODV messages is possible. >I recomend you to take a look to my SAODV draft: >http://ant.eupvg.upc.es/~tarom/draft-tarom-manet-saodv-00.txt > >You have pointed out one of the biggest problems I had when designing >SAODV: the mutable fields (i.e. hop count). Luckily Asokan came with >the proposal of using hash chains to secure the hop count. And, >although there are certain possible attacks against the authentication >of the hop count, I'm pretty satisfied about the overall security >that SAODV is now providing. (Except maybe in the RERR messages, where >more work still needs to be done) > >BR/ManelG > > >ext Pekka Savola wrote: >> Hello, >> >> The first paragraph of the AODV security considerations basically says the >> AODV packets should be authenticated. >> >> The second paragraph seems to suggest that the _data_ sent between the >> nodes could be authenticated. This appears to be the case. This could >> also be interpreted to mean about AODV control packets, which would be >> wrong. >> >> Where is the discussion about securing AODV control messages? If it >> cannot be done, it should also be stated. >> >> From Hop Count and other values which seem to be modifiable in transit it >> appears that "hop-by-hop" security associations, every node having to >> trust its neighbors (thus expanding the ring of trust) would be necessary: >> security of AODV protocol between non-neighbor AODV nodes does not appear >> to be possible. >> >> > > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 18 11:59:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12068 for ; Thu, 18 Apr 2002 11:59:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08855 for manet-archive@odin.ietf.org; Thu, 18 Apr 2002 11:59:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05195; Thu, 18 Apr 2002 11:29:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05164 for ; Thu, 18 Apr 2002 11:29:25 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10646 for ; Thu, 18 Apr 2002 11:29:15 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3IFSCR21859; Thu, 18 Apr 2002 17:28:13 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3IFSDX15005; Thu, 18 Apr 2002 17:28:13 +0200 (MEST) Message-ID: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "Manel Guerrero Zapata" Cc: Subject: Re: [manet] Security Considerations of AODV Date: Thu, 18 Apr 2002 17:11:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello Manel, If i understand well the hash chains mechanism described in your draft prevents a bad guy from modifying the HopCount field, right? But why prevents a bad guy from not performing the hash of the HopCount and just forwarding the packet as it is? As a result, the path might appear shorter that what it really is and might end-up being selected (this might be the goal of the attacker..)? Did i miss something? thanks in advance for the clarification, Claude. -----Message d'origine----- De : Manel Guerrero Zapata À : ext Pekka Savola Cc : manet@ietf.org Date : jeudi 18 avril 2002 10:28 Objet : Re: [manet] Security Considerations of AODV >Moi Pekka, > >Securing AODV messages is possible. >I recomend you to take a look to my SAODV draft: >http://ant.eupvg.upc.es/~tarom/draft-tarom-manet-saodv-00.txt > >You have pointed out one of the biggest problems I had when designing >SAODV: the mutable fields (i.e. hop count). Luckily Asokan came with >the proposal of using hash chains to secure the hop count. And, >although there are certain possible attacks against the authentication >of the hop count, I'm pretty satisfied about the overall security >that SAODV is now providing. (Except maybe in the RERR messages, where >more work still needs to be done) > >BR/ManelG > > >ext Pekka Savola wrote: >> Hello, >> >> The first paragraph of the AODV security considerations basically says the >> AODV packets should be authenticated. >> >> The second paragraph seems to suggest that the _data_ sent between the >> nodes could be authenticated. This appears to be the case. This could >> also be interpreted to mean about AODV control packets, which would be >> wrong. >> >> Where is the discussion about securing AODV control messages? If it >> cannot be done, it should also be stated. >> >> From Hop Count and other values which seem to be modifiable in transit it >> appears that "hop-by-hop" security associations, every node having to >> trust its neighbors (thus expanding the ring of trust) would be necessary: >> security of AODV protocol between non-neighbor AODV nodes does not appear >> to be possible. >> >> > > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 18 11:59:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12095 for ; Thu, 18 Apr 2002 11:59:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04800; Thu, 18 Apr 2002 11:25:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04769 for ; Thu, 18 Apr 2002 11:25:40 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10478 for ; Thu, 18 Apr 2002 11:25:35 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA20879; Thu, 18 Apr 2002 08:25:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3IFP7t23865; Thu, 18 Apr 2002 08:25:07 -0700 X-mProtect: <200204181525> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNSsRhc; Thu, 18 Apr 2002 08:25:05 PDT Message-ID: <3CBEE552.B32E5866@iprg.nokia.com> Date: Thu, 18 Apr 2002 08:25:06 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: manet@ietf.org Subject: Re: [manet] AODV QoS incompatible with IPSEC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Pekka Savola wrote: > --8<-- > 5. Security Considerations > > This draft specifies mechanisms for handling quality of service. It > does not introduce any special security considerations which were not > already present in the AODV routing protocol [2]. > --8<-- > > This is untrue, because: > > --8<-- > Before forwarding the RREQ, an intermediate node MUST compare its > NODE_TRAVERSAL_TIME to the (remaining) Delay indicated in the Maximum > Delay Extension. If the Delay is less, the node MUST discard the > RREQ and not process it any further. Otherwise, the node subtracts > NODE_TRAVERSAL_TIME from the Delay value in the extension and > continues processing the RREQ as specified in [2]. > > [...] > > Before forwarding the RREQ, an intermediate node MUST compare its > approximate jitter to the (remaining) Jitter indicated in the Maximum > Jitter Extension. If the Jitter is less, the node MUST discard the > RREQ and not process it any further. Otherwise, the node subtracts > --8<-- > (note subtract above) > > Intermediate nodes modifying the packet for all practical purposes kills > IPSEC except for an keys-shared-by-everyone method (only one applicable to > e.g. DSR I think). Maybe IPsec won't be a good solution for ad hoc networking protocols. It seems to be totally inflexible, and we need more flexibility. > IPSEC (to secure the routing messages) seems to be possible with AODV, but > not with AODV QoS extensions. Whether or not this is true, the argument about QoS should not have any effect. If you claim that AODV with QoS is less secure than AODV, for the reason that useless messages MUST be discarded, then I think that you must be using a wrong model of security to start with. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 18 11:59:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12108 for ; Thu, 18 Apr 2002 11:59:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08898 for manet-archive@odin.ietf.org; Thu, 18 Apr 2002 11:59:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04800; Thu, 18 Apr 2002 11:25:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04769 for ; Thu, 18 Apr 2002 11:25:40 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10478 for ; Thu, 18 Apr 2002 11:25:35 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA20879; Thu, 18 Apr 2002 08:25:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3IFP7t23865; Thu, 18 Apr 2002 08:25:07 -0700 X-mProtect: <200204181525> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNSsRhc; Thu, 18 Apr 2002 08:25:05 PDT Message-ID: <3CBEE552.B32E5866@iprg.nokia.com> Date: Thu, 18 Apr 2002 08:25:06 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: manet@ietf.org Subject: Re: [manet] AODV QoS incompatible with IPSEC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Pekka Savola wrote: > --8<-- > 5. Security Considerations > > This draft specifies mechanisms for handling quality of service. It > does not introduce any special security considerations which were not > already present in the AODV routing protocol [2]. > --8<-- > > This is untrue, because: > > --8<-- > Before forwarding the RREQ, an intermediate node MUST compare its > NODE_TRAVERSAL_TIME to the (remaining) Delay indicated in the Maximum > Delay Extension. If the Delay is less, the node MUST discard the > RREQ and not process it any further. Otherwise, the node subtracts > NODE_TRAVERSAL_TIME from the Delay value in the extension and > continues processing the RREQ as specified in [2]. > > [...] > > Before forwarding the RREQ, an intermediate node MUST compare its > approximate jitter to the (remaining) Jitter indicated in the Maximum > Jitter Extension. If the Jitter is less, the node MUST discard the > RREQ and not process it any further. Otherwise, the node subtracts > --8<-- > (note subtract above) > > Intermediate nodes modifying the packet for all practical purposes kills > IPSEC except for an keys-shared-by-everyone method (only one applicable to > e.g. DSR I think). Maybe IPsec won't be a good solution for ad hoc networking protocols. It seems to be totally inflexible, and we need more flexibility. > IPSEC (to secure the routing messages) seems to be possible with AODV, but > not with AODV QoS extensions. Whether or not this is true, the argument about QoS should not have any effect. If you claim that AODV with QoS is less secure than AODV, for the reason that useless messages MUST be discarded, then I think that you must be using a wrong model of security to start with. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 18 12:38:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13931 for ; Thu, 18 Apr 2002 12:38:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12138; Thu, 18 Apr 2002 12:17:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12110 for ; Thu, 18 Apr 2002 12:17:31 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13087 for ; Thu, 18 Apr 2002 12:17:25 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3IGIYJ18253 for ; Thu, 18 Apr 2002 19:18:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Apr 2002 19:17:28 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 18 Apr 2002 19:17:28 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id TAA21249; Thu, 18 Apr 2002 19:17:27 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CBEF145.8050706@nokia.com> Date: Thu, 18 Apr 2002 19:16:05 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Claude Castelluccia CC: manet@ietf.org Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Apr 2002 16:17:28.0056 (UTC) FILETIME=[888EE780:01C1E6F4] Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Claude, you didn't miss anything ;) That's why I said: "although there are certain possible attacks against the authentication of the hop count"... That is exactly the attack you can perform: Bad guys can avoid the increasing of the hop count when they forward the packet. So the first part of a composed attack would be to try that enough bad guys get in one of the paths the RREQ travels through and try to be close enough to the optimal path so the difference that they cheat is enough to be selected as best path. That is not as easy as you might thing. If nodes move you have to have a lot of bad guys moving close to the best path, or just a huge amount of bad guys (people accept that if a 1/3 of the guys are bad there is not much you can do). I thing that in the real world the probability that the bad guys get the path going through them is not much higher than if the they wouldn't be cheating (because if you put a lot of bad guys close to the best path, even if they do account for the hop count they also get the possibility to be in the best path). Therefore I thing hash chains are pretty reasonable, and _very very cheap_! There are other mechanisms to protect the hop count but they are so much more expensive that they are not really feasible ones. But if you (or somebody else) come with a better idea, I'll be glad to study it. Regards, Manel P.D.: Another way to do the attack is that no matter how close they are to the path, but be one hop away from src & dst and have a whole path of bad guy no matter how long it is. (but then you need more bad boys than hops has the optimal path and being just one hop away form src & dst) So I thing bad guys will have a hard time doing this (now: imagine all nodes moving). ext Claude Castelluccia wrote: > Hello Manel, > > If i understand well the hash chains mechanism described in your > draft prevents a bad guy from modifying the HopCount field, right? > But why prevents a bad guy from not performing the hash of the HopCount > and just forwarding the packet as it is? As a result, the path might appear > shorter that what it really is and might end-up being selected (this might > be the goal of the attacker..)? > Did i miss something? > thanks in advance for the clarification, > Claude. > > -----Message d'origine----- > De : Manel Guerrero Zapata > À : ext Pekka Savola > Cc : manet@ietf.org > Date : jeudi 18 avril 2002 10:28 > Objet : Re: [manet] Security Considerations of AODV > > > >>Moi Pekka, >> >>Securing AODV messages is possible. >>I recomend you to take a look to my SAODV draft: >>http://ant.eupvg.upc.es/~tarom/draft-tarom-manet-saodv-00.txt >> >>You have pointed out one of the biggest problems I had when designing >>SAODV: the mutable fields (i.e. hop count). Luckily Asokan came with >>the proposal of using hash chains to secure the hop count. And, >>although there are certain possible attacks against the authentication >>of the hop count, I'm pretty satisfied about the overall security >>that SAODV is now providing. (Except maybe in the RERR messages, where >>more work still needs to be done) >> >>BR/ManelG >> >> >>ext Pekka Savola wrote: >> >>>Hello, >>> >>>The first paragraph of the AODV security considerations basically says >>> > the > >>>AODV packets should be authenticated. >>> >>>The second paragraph seems to suggest that the _data_ sent between the >>>nodes could be authenticated. This appears to be the case. This could >>>also be interpreted to mean about AODV control packets, which would be >>>wrong. >>> >>>Where is the discussion about securing AODV control messages? If it >>>cannot be done, it should also be stated. >>> >>>From Hop Count and other values which seem to be modifiable in transit it >>>appears that "hop-by-hop" security associations, every node having to >>>trust its neighbors (thus expanding the ring of trust) would be >>> > necessary: > >>>security of AODV protocol between non-neighbor AODV nodes does not appear >>>to be possible. >>> >>> >>> >> >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> >> > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 18 12:39:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13948 for ; Thu, 18 Apr 2002 12:38:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14035 for manet-archive@odin.ietf.org; Thu, 18 Apr 2002 12:38:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12138; Thu, 18 Apr 2002 12:17:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12110 for ; Thu, 18 Apr 2002 12:17:31 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13087 for ; Thu, 18 Apr 2002 12:17:25 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3IGIYJ18253 for ; Thu, 18 Apr 2002 19:18:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Apr 2002 19:17:28 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 18 Apr 2002 19:17:28 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id TAA21249; Thu, 18 Apr 2002 19:17:27 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CBEF145.8050706@nokia.com> Date: Thu, 18 Apr 2002 19:16:05 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Claude Castelluccia CC: manet@ietf.org Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 18 Apr 2002 16:17:28.0056 (UTC) FILETIME=[888EE780:01C1E6F4] Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Claude, you didn't miss anything ;) That's why I said: "although there are certain possible attacks against the authentication of the hop count"... That is exactly the attack you can perform: Bad guys can avoid the increasing of the hop count when they forward the packet. So the first part of a composed attack would be to try that enough bad guys get in one of the paths the RREQ travels through and try to be close enough to the optimal path so the difference that they cheat is enough to be selected as best path. That is not as easy as you might thing. If nodes move you have to have a lot of bad guys moving close to the best path, or just a huge amount of bad guys (people accept that if a 1/3 of the guys are bad there is not much you can do). I thing that in the real world the probability that the bad guys get the path going through them is not much higher than if the they wouldn't be cheating (because if you put a lot of bad guys close to the best path, even if they do account for the hop count they also get the possibility to be in the best path). Therefore I thing hash chains are pretty reasonable, and _very very cheap_! There are other mechanisms to protect the hop count but they are so much more expensive that they are not really feasible ones. But if you (or somebody else) come with a better idea, I'll be glad to study it. Regards, Manel P.D.: Another way to do the attack is that no matter how close they are to the path, but be one hop away from src & dst and have a whole path of bad guy no matter how long it is. (but then you need more bad boys than hops has the optimal path and being just one hop away form src & dst) So I thing bad guys will have a hard time doing this (now: imagine all nodes moving). ext Claude Castelluccia wrote: > Hello Manel, > > If i understand well the hash chains mechanism described in your > draft prevents a bad guy from modifying the HopCount field, right? > But why prevents a bad guy from not performing the hash of the HopCount > and just forwarding the packet as it is? As a result, the path might appear > shorter that what it really is and might end-up being selected (this might > be the goal of the attacker..)? > Did i miss something? > thanks in advance for the clarification, > Claude. > > -----Message d'origine----- > De : Manel Guerrero Zapata > À : ext Pekka Savola > Cc : manet@ietf.org > Date : jeudi 18 avril 2002 10:28 > Objet : Re: [manet] Security Considerations of AODV > > > >>Moi Pekka, >> >>Securing AODV messages is possible. >>I recomend you to take a look to my SAODV draft: >>http://ant.eupvg.upc.es/~tarom/draft-tarom-manet-saodv-00.txt >> >>You have pointed out one of the biggest problems I had when designing >>SAODV: the mutable fields (i.e. hop count). Luckily Asokan came with >>the proposal of using hash chains to secure the hop count. And, >>although there are certain possible attacks against the authentication >>of the hop count, I'm pretty satisfied about the overall security >>that SAODV is now providing. (Except maybe in the RERR messages, where >>more work still needs to be done) >> >>BR/ManelG >> >> >>ext Pekka Savola wrote: >> >>>Hello, >>> >>>The first paragraph of the AODV security considerations basically says >>> > the > >>>AODV packets should be authenticated. >>> >>>The second paragraph seems to suggest that the _data_ sent between the >>>nodes could be authenticated. This appears to be the case. This could >>>also be interpreted to mean about AODV control packets, which would be >>>wrong. >>> >>>Where is the discussion about securing AODV control messages? If it >>>cannot be done, it should also be stated. >>> >>>From Hop Count and other values which seem to be modifiable in transit it >>>appears that "hop-by-hop" security associations, every node having to >>>trust its neighbors (thus expanding the ring of trust) would be >>> > necessary: > >>>security of AODV protocol between non-neighbor AODV nodes does not appear >>>to be possible. >>> >>> >>> >> >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> >> > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 18 17:23:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23367 for ; Thu, 18 Apr 2002 17:23:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03201; Thu, 18 Apr 2002 17:05:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03170 for ; Thu, 18 Apr 2002 17:05:44 -0400 (EDT) Received: from godel.crhc.uiuc.edu (godel.crhc.uiuc.edu [130.126.142.156]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22901 for ; Thu, 18 Apr 2002 17:05:39 -0400 (EDT) Received: from localhost (nhv@localhost) by godel.crhc.uiuc.edu (8.11.6/8.11.6) with ESMTP id g3IL59105566; Thu, 18 Apr 2002 16:05:09 -0500 Date: Thu, 18 Apr 2002 16:05:09 -0500 (CDT) From: Nitin H Vaidya To: cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] tutorial proposals for MobiCom Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Call for Tutorials ACM MobiCom 2002 http://www.acm.org/sigmobile/mobicom/2002 *********** Proposals due: May 1, 2002 ************* ACM MobiCom will be held at Atlanta in September 2002. As a part of MobiCom, tutorials will be scheduled on September 23 and 24. Proposals for tutorials on topics related to mobile computing and networking are solicited. The tutorials may be half-day or full-day durations. Potential instructors should send their proposals to Tutorial Co-Chairs Catherine Rosenberg (cath@ecn.purdue.edu) and Nitin Vaidya (nhv@crhc.uiuc.edu) by May 1, 2002. Please use plain-text, postscript or PDF formats. Each proposal, not exceeding 5 pages, should include * tutorial title * contact information for the presenter(s) * proposed duration (half-day or full-day) * tutorial outline * target audience * assumed background of attendees * information on any previous presentations of the tutorial * special requirements of audio-visual equipment * biography of the presenter(s) MobiCom Tutorial Co-Chairs Catherine Rosenberg (cath@ecn.purdue.edu) and Nitin Vaidya (nhv@crhc.uiuc.edu) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 18 17:23:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23376 for ; Thu, 18 Apr 2002 17:23:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04460 for manet-archive@odin.ietf.org; Thu, 18 Apr 2002 17:23:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03201; Thu, 18 Apr 2002 17:05:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03170 for ; Thu, 18 Apr 2002 17:05:44 -0400 (EDT) Received: from godel.crhc.uiuc.edu (godel.crhc.uiuc.edu [130.126.142.156]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22901 for ; Thu, 18 Apr 2002 17:05:39 -0400 (EDT) Received: from localhost (nhv@localhost) by godel.crhc.uiuc.edu (8.11.6/8.11.6) with ESMTP id g3IL59105566; Thu, 18 Apr 2002 16:05:09 -0500 Date: Thu, 18 Apr 2002 16:05:09 -0500 (CDT) From: Nitin H Vaidya To: cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] tutorial proposals for MobiCom Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Call for Tutorials ACM MobiCom 2002 http://www.acm.org/sigmobile/mobicom/2002 *********** Proposals due: May 1, 2002 ************* ACM MobiCom will be held at Atlanta in September 2002. As a part of MobiCom, tutorials will be scheduled on September 23 and 24. Proposals for tutorials on topics related to mobile computing and networking are solicited. The tutorials may be half-day or full-day durations. Potential instructors should send their proposals to Tutorial Co-Chairs Catherine Rosenberg (cath@ecn.purdue.edu) and Nitin Vaidya (nhv@crhc.uiuc.edu) by May 1, 2002. Please use plain-text, postscript or PDF formats. Each proposal, not exceeding 5 pages, should include * tutorial title * contact information for the presenter(s) * proposed duration (half-day or full-day) * tutorial outline * target audience * assumed background of attendees * information on any previous presentations of the tutorial * special requirements of audio-visual equipment * biography of the presenter(s) MobiCom Tutorial Co-Chairs Catherine Rosenberg (cath@ecn.purdue.edu) and Nitin Vaidya (nhv@crhc.uiuc.edu) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 18 18:05:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24162 for ; Thu, 18 Apr 2002 18:05:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06134; Thu, 18 Apr 2002 17:45:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06104 for ; Thu, 18 Apr 2002 17:45:45 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23878 for ; Thu, 18 Apr 2002 17:45:39 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3ILj6I26718; Fri, 19 Apr 2002 00:45:06 +0300 Date: Fri, 19 Apr 2002 00:45:06 +0300 (EEST) From: Pekka Savola To: "Charles E. Perkins" cc: manet@ietf.org Subject: Re: [manet] AODV QoS incompatible with IPSEC In-Reply-To: <3CBEE552.B32E5866@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Thu, 18 Apr 2002, Charles E. Perkins wrote: > > Intermediate nodes modifying the packet for all practical purposes kills > > IPSEC except for an keys-shared-by-everyone method (only one applicable to > > e.g. DSR I think). > > Maybe IPsec won't be a good solution for ad hoc networking protocols. > It seems to be totally inflexible, and we need more flexibility. Perhaps, perhaps not. That's not the point. > > IPSEC (to secure the routing messages) seems to be possible with AODV, but > > not with AODV QoS extensions. > > Whether or not this is true, the argument about QoS should not have > any effect. > > If you claim that AODV with QoS is less secure than AODV, for the reason > that useless messages MUST be discarded, then I think that you must > be using a wrong model of security to start with. One particular (and probably the only currently viable) mechanism is to use IPSEC. (Please don't mention IEEE 802.11 :-). I'm not discussing security models here, I'm arguing against the wording which is basically "AODV QoS does not make security any more difficult and creates no new problems". This is clearly false, especially in the light that AODV messages are recommended to be authenticated etc. (AODV QoS may or may not make it more difficult, depending on the mechanism; probably will) considering the limited scope of current mechanisms of securing AODV. The wording in the main AODV draft makes one assume that it is probably talking about protecting the data packets, not AODV. But as IPSEC was mentioned there, one would usually assume it could be used to some extent with AODV packets too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 18 18:05:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24172 for ; Thu, 18 Apr 2002 18:05:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07568 for manet-archive@odin.ietf.org; Thu, 18 Apr 2002 18:05:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06134; Thu, 18 Apr 2002 17:45:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06104 for ; Thu, 18 Apr 2002 17:45:45 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23878 for ; Thu, 18 Apr 2002 17:45:39 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3ILj6I26718; Fri, 19 Apr 2002 00:45:06 +0300 Date: Fri, 19 Apr 2002 00:45:06 +0300 (EEST) From: Pekka Savola To: "Charles E. Perkins" cc: manet@ietf.org Subject: Re: [manet] AODV QoS incompatible with IPSEC In-Reply-To: <3CBEE552.B32E5866@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Thu, 18 Apr 2002, Charles E. Perkins wrote: > > Intermediate nodes modifying the packet for all practical purposes kills > > IPSEC except for an keys-shared-by-everyone method (only one applicable to > > e.g. DSR I think). > > Maybe IPsec won't be a good solution for ad hoc networking protocols. > It seems to be totally inflexible, and we need more flexibility. Perhaps, perhaps not. That's not the point. > > IPSEC (to secure the routing messages) seems to be possible with AODV, but > > not with AODV QoS extensions. > > Whether or not this is true, the argument about QoS should not have > any effect. > > If you claim that AODV with QoS is less secure than AODV, for the reason > that useless messages MUST be discarded, then I think that you must > be using a wrong model of security to start with. One particular (and probably the only currently viable) mechanism is to use IPSEC. (Please don't mention IEEE 802.11 :-). I'm not discussing security models here, I'm arguing against the wording which is basically "AODV QoS does not make security any more difficult and creates no new problems". This is clearly false, especially in the light that AODV messages are recommended to be authenticated etc. (AODV QoS may or may not make it more difficult, depending on the mechanism; probably will) considering the limited scope of current mechanisms of securing AODV. The wording in the main AODV draft makes one assume that it is probably talking about protecting the data packets, not AODV. But as IPSEC was mentioned there, one would usually assume it could be used to some extent with AODV packets too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 18 18:22:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24551 for ; Thu, 18 Apr 2002 18:22:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07818; Thu, 18 Apr 2002 18:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07791 for ; Thu, 18 Apr 2002 18:08:23 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24301 for ; Thu, 18 Apr 2002 18:08:17 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA13836; Thu, 18 Apr 2002 15:07:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3IM7ow25110; Thu, 18 Apr 2002 15:07:50 -0700 X-mProtect: <200204182207> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQ3g8Nq; Thu, 18 Apr 2002 15:07:48 PDT Message-ID: <3CBF43B5.A0C85D13@iprg.nokia.com> Date: Thu, 18 Apr 2002 15:07:49 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: manet@ietf.org Subject: Re: [manet] AODV QoS incompatible with IPSEC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Pekka Savola wrote: >> If you claim that AODV with QoS is less secure than AODV, for the reason >> that useless messages MUST be discarded, then I think that you must >> be using a wrong model of security to start with. > > One particular (and probably the only currently viable) mechanism is to > use IPSEC. (Please don't mention IEEE 802.11 :-). > > I'm not discussing security models here, I'm arguing against the wording > which is basically "AODV QoS does not make security any more difficult > and creates no new problems". But I didn't yet see what the new problem is... > This is clearly false, especially in the light that AODV messages are > recommended to be authenticated etc. (AODV QoS may or may not make it more > difficult, depending on the mechanism; probably will) considering the > limited scope of current mechanisms of securing AODV. How does one resolve "clearly false" with "may or may not make it more difficult"? > The wording in the main AODV draft makes one assume that it is probably > talking about protecting the data packets, not AODV. But as IPSEC was > mentioned there, one would usually assume it could be used to some extent > with AODV packets too. I'd like to take a look at this. I don't remember any place in the AODV draft that was intended to discuss securing data packets. If you can point to these places, or better yet suggest ways of removing the confusing, that would be helpful. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 18 18:22:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24561 for ; Thu, 18 Apr 2002 18:22:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08575 for manet-archive@odin.ietf.org; Thu, 18 Apr 2002 18:22:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07818; Thu, 18 Apr 2002 18:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07791 for ; Thu, 18 Apr 2002 18:08:23 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24301 for ; Thu, 18 Apr 2002 18:08:17 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA13836; Thu, 18 Apr 2002 15:07:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3IM7ow25110; Thu, 18 Apr 2002 15:07:50 -0700 X-mProtect: <200204182207> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQ3g8Nq; Thu, 18 Apr 2002 15:07:48 PDT Message-ID: <3CBF43B5.A0C85D13@iprg.nokia.com> Date: Thu, 18 Apr 2002 15:07:49 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: manet@ietf.org Subject: Re: [manet] AODV QoS incompatible with IPSEC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Pekka Savola wrote: >> If you claim that AODV with QoS is less secure than AODV, for the reason >> that useless messages MUST be discarded, then I think that you must >> be using a wrong model of security to start with. > > One particular (and probably the only currently viable) mechanism is to > use IPSEC. (Please don't mention IEEE 802.11 :-). > > I'm not discussing security models here, I'm arguing against the wording > which is basically "AODV QoS does not make security any more difficult > and creates no new problems". But I didn't yet see what the new problem is... > This is clearly false, especially in the light that AODV messages are > recommended to be authenticated etc. (AODV QoS may or may not make it more > difficult, depending on the mechanism; probably will) considering the > limited scope of current mechanisms of securing AODV. How does one resolve "clearly false" with "may or may not make it more difficult"? > The wording in the main AODV draft makes one assume that it is probably > talking about protecting the data packets, not AODV. But as IPSEC was > mentioned there, one would usually assume it could be used to some extent > with AODV packets too. I'd like to take a look at this. I don't remember any place in the AODV draft that was intended to discuss securing data packets. If you can point to these places, or better yet suggest ways of removing the confusing, that would be helpful. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 19 04:43:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13552 for ; Fri, 19 Apr 2002 04:43:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22131; Fri, 19 Apr 2002 04:25:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22084 for ; Fri, 19 Apr 2002 04:25:17 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13356 for ; Fri, 19 Apr 2002 04:25:14 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3J8OaR31122; Fri, 19 Apr 2002 11:24:36 +0300 Date: Fri, 19 Apr 2002 11:24:36 +0300 (EEST) From: Pekka Savola To: "Charles E. Perkins" cc: manet@ietf.org Subject: Re: [manet] AODV QoS incompatible with IPSEC In-Reply-To: <3CBF43B5.A0C85D13@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Thu, 18 Apr 2002, Charles E. Perkins wrote: > > This is clearly false, especially in the light that AODV messages are > > recommended to be authenticated etc. (AODV QoS may or may not make it more > > difficult, depending on the mechanism; probably will) considering the > > limited scope of current mechanisms of securing AODV. > > How does one resolve "clearly false" with "may or may not make it > more difficult"? Basically the only real securing mechanism for something like this today is IPSEC. Unless otherwise stated, it's IMO fairly safe to assume it would be used. > > The wording in the main AODV draft makes one assume that it is probably > > talking about protecting the data packets, not AODV. But as IPSEC was > > mentioned there, one would usually assume it could be used to some extent > > with AODV packets too. > > I'd like to take a look at this. I don't remember any place > in the AODV draft that was intended to discuss securing data > packets. If you can point to these places, or better yet suggest > ways of removing the confusing, that would be helpful. Security Considerations say: --8<-- Since AODV does not make any assumption about the nature of the address assignment to the mobile nodes except that they are presumed to have unique IP addresses, no definite statements can be made about the applicability of IPsec authentication headers or key exchange mechanisms. However, if the mobile nodes in the ad hoc network have pre-established security associations, they should be able to use the same authentication mechanisms based on their IP addresses as they would have used otherwise. --8<-- I assumed that this applies to the data packets, as otherwise it would be wrong: due to Hop Count and such, which may be modified in transit, IPSEC would not be all that usable to secure AODV control packets without further elaboration. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 19 04:43:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13563 for ; Fri, 19 Apr 2002 04:43:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23570 for manet-archive@odin.ietf.org; Fri, 19 Apr 2002 04:43:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22131; Fri, 19 Apr 2002 04:25:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22084 for ; Fri, 19 Apr 2002 04:25:17 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13356 for ; Fri, 19 Apr 2002 04:25:14 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3J8OaR31122; Fri, 19 Apr 2002 11:24:36 +0300 Date: Fri, 19 Apr 2002 11:24:36 +0300 (EEST) From: Pekka Savola To: "Charles E. Perkins" cc: manet@ietf.org Subject: Re: [manet] AODV QoS incompatible with IPSEC In-Reply-To: <3CBF43B5.A0C85D13@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Thu, 18 Apr 2002, Charles E. Perkins wrote: > > This is clearly false, especially in the light that AODV messages are > > recommended to be authenticated etc. (AODV QoS may or may not make it more > > difficult, depending on the mechanism; probably will) considering the > > limited scope of current mechanisms of securing AODV. > > How does one resolve "clearly false" with "may or may not make it > more difficult"? Basically the only real securing mechanism for something like this today is IPSEC. Unless otherwise stated, it's IMO fairly safe to assume it would be used. > > The wording in the main AODV draft makes one assume that it is probably > > talking about protecting the data packets, not AODV. But as IPSEC was > > mentioned there, one would usually assume it could be used to some extent > > with AODV packets too. > > I'd like to take a look at this. I don't remember any place > in the AODV draft that was intended to discuss securing data > packets. If you can point to these places, or better yet suggest > ways of removing the confusing, that would be helpful. Security Considerations say: --8<-- Since AODV does not make any assumption about the nature of the address assignment to the mobile nodes except that they are presumed to have unique IP addresses, no definite statements can be made about the applicability of IPsec authentication headers or key exchange mechanisms. However, if the mobile nodes in the ad hoc network have pre-established security associations, they should be able to use the same authentication mechanisms based on their IP addresses as they would have used otherwise. --8<-- I assumed that this applies to the data packets, as otherwise it would be wrong: due to Hop Count and such, which may be modified in transit, IPSEC would not be all that usable to secure AODV control packets without further elaboration. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 19 10:54:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22283 for ; Fri, 19 Apr 2002 10:54:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12924; Fri, 19 Apr 2002 10:26:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12892 for ; Fri, 19 Apr 2002 10:26:41 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21334 for ; Fri, 19 Apr 2002 10:26:35 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY18NC; Fri, 19 Apr 2002 10:26:29 -0400 Message-ID: <003f01c1e7ae$324d0a40$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: Cc: Date: Fri, 19 Apr 2002 10:26:29 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Questions on draft-ietf-manet-aodv-10.txt Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Some Nitpicks... 1). Page 3, second to last paragraph. Grammar. ... containing the IP address for each [of] its neighbors ... ^ | Add word "of" 2). All. Document organization. When trying to implement the draft, one would find it particularly convenient if all the references on how to handle the reception of a particular message i.e. RREQ, RREP, etc. were in the same subsection. I would prefer four new sections be aggregated into the draft, with subsection titles of: "Handling RREQ Messages" "Handling RREP Messages", etc... i.e. for each AODV message type. An implementation question... 3). AODV specifies the creation of its own route table structure. RFC 1396 (IP Forwarding Table MIB) specifies the format for route tables that are used in many device implementations, for example, the Microsoft Windows route table. Is there any reason, why AODV does not specify the interaction between its route table and the route table that may be present on the host (and conflicting with) it. Also, would it not be advisable to modify RFC 1396 to accomodate MANET protocols? This way we could get down to one route table on host and router platforms right? The precusror list does not necessarily need to be in there. Also, the route table could be treated like a relational database indexed on IP destination addr so the redundant information could be put into the "real route table". This is particularly important on embedded devices. Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 19 10:54:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22293 for ; Fri, 19 Apr 2002 10:54:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15596 for manet-archive@odin.ietf.org; Fri, 19 Apr 2002 10:54:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12924; Fri, 19 Apr 2002 10:26:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12892 for ; Fri, 19 Apr 2002 10:26:41 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21334 for ; Fri, 19 Apr 2002 10:26:35 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY18NC; Fri, 19 Apr 2002 10:26:29 -0400 Message-ID: <003f01c1e7ae$324d0a40$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: Cc: Date: Fri, 19 Apr 2002 10:26:29 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Questions on draft-ietf-manet-aodv-10.txt Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Some Nitpicks... 1). Page 3, second to last paragraph. Grammar. ... containing the IP address for each [of] its neighbors ... ^ | Add word "of" 2). All. Document organization. When trying to implement the draft, one would find it particularly convenient if all the references on how to handle the reception of a particular message i.e. RREQ, RREP, etc. were in the same subsection. I would prefer four new sections be aggregated into the draft, with subsection titles of: "Handling RREQ Messages" "Handling RREP Messages", etc... i.e. for each AODV message type. An implementation question... 3). AODV specifies the creation of its own route table structure. RFC 1396 (IP Forwarding Table MIB) specifies the format for route tables that are used in many device implementations, for example, the Microsoft Windows route table. Is there any reason, why AODV does not specify the interaction between its route table and the route table that may be present on the host (and conflicting with) it. Also, would it not be advisable to modify RFC 1396 to accomodate MANET protocols? This way we could get down to one route table on host and router platforms right? The precusror list does not necessarily need to be in there. Also, the route table could be treated like a relational database indexed on IP destination addr so the redundant information could be put into the "real route table". This is particularly important on embedded devices. Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 19 10:54:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22329 for ; Fri, 19 Apr 2002 10:54:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13941; Fri, 19 Apr 2002 10:32:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13905 for ; Fri, 19 Apr 2002 10:32:07 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21577 for ; Fri, 19 Apr 2002 10:32:01 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY18NM; Fri, 19 Apr 2002 10:32:01 -0400 Message-ID: <004d01c1e7ae$f849b3b0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: References: <003f01c1e7ae$324d0a40$6200000a@meshnetworks.com> Subject: Re: [manet] Questions on draft-ietf-manet-aodv-10.txt Date: Fri, 19 Apr 2002 10:32:01 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Sorry replace 1396 with 1354 in previous mailing > > 3). AODV specifies the creation of its own route table structure. RFC 1354 > (IP Forwarding Table MIB) specifies the format for route tables that > are used in many device implementations, for example, the Microsoft Windows > route table. Is there any reason, why AODV does not specify the interaction > between its route table and the route table that may be present on the host > (and conflicting with) it. Also, would it not be advisable to modify RFC 1354 to > accomodate MANET protocols? This way we could get down to one route > table on host and router platforms right? The precusror list does not necessarily > need to be in there. Also, the route table could be treated like a relational > database indexed on IP destination addr so the redundant information could > be put into the "real route table". This is particularly important on embedded > devices. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 19 10:54:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22340 for ; Fri, 19 Apr 2002 10:54:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15739 for manet-archive@odin.ietf.org; Fri, 19 Apr 2002 10:54:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13941; Fri, 19 Apr 2002 10:32:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13905 for ; Fri, 19 Apr 2002 10:32:07 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21577 for ; Fri, 19 Apr 2002 10:32:01 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY18NM; Fri, 19 Apr 2002 10:32:01 -0400 Message-ID: <004d01c1e7ae$f849b3b0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: References: <003f01c1e7ae$324d0a40$6200000a@meshnetworks.com> Subject: Re: [manet] Questions on draft-ietf-manet-aodv-10.txt Date: Fri, 19 Apr 2002 10:32:01 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Sorry replace 1396 with 1354 in previous mailing > > 3). AODV specifies the creation of its own route table structure. RFC 1354 > (IP Forwarding Table MIB) specifies the format for route tables that > are used in many device implementations, for example, the Microsoft Windows > route table. Is there any reason, why AODV does not specify the interaction > between its route table and the route table that may be present on the host > (and conflicting with) it. Also, would it not be advisable to modify RFC 1354 to > accomodate MANET protocols? This way we could get down to one route > table on host and router platforms right? The precusror list does not necessarily > need to be in there. Also, the route table could be treated like a relational > database indexed on IP destination addr so the redundant information could > be put into the "real route table". This is particularly important on embedded > devices. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 19 11:15:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23209 for ; Fri, 19 Apr 2002 11:15:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15485; Fri, 19 Apr 2002 10:53:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15459 for ; Fri, 19 Apr 2002 10:53:35 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22267 for ; Fri, 19 Apr 2002 10:53:31 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3JEsdJ02008 for ; Fri, 19 Apr 2002 17:54:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Apr 2002 17:53:32 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 19 Apr 2002 17:53:32 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id RAA21253; Fri, 19 Apr 2002 17:53:28 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC02F14.6010707@nokia.com> Date: Fri, 19 Apr 2002 17:52:04 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Casey Carter CC: ext Claude Castelluccia , manet@ietf.org Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2002 14:53:32.0572 (UTC) FILETIME=[F996C5C0:01C1E7B1] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Casey, That is a very good observation. Because if two nodes simulate that they have a link, it is very complicated to detect that they actualy don't have a link (even with misbehavior detection schemes). I've been thinking about the whole problem for a while and I realized about a funny thing: I usually thing about AODV route discovery assuming that it returns the shortest path between originator and destination. But that's not really true. Is it? It returns the shortest path among the paths through which the RREQ traveled faster from the originator to each final or intermediate node that has the route to the destination. (Or just the fastest one, in the case no intermediate nodes know a route to de destination). And that's the selected path in AODV. 8<------------------------------------------------- 6.5. Processing and Forwarding Route Requests When a node receives a RREQ, it first checks to determine whether it has received a RREQ with the same Originator IP Address and RREQ ID within at least the last PATH_TRAVERSAL_TIME milliseconds. If such a RREQ has been received, the node silently discards the newly received RREQ. The rest of this subsection describes actions taken for RREQs that are not discarded. ------------------------------------------------->8 According to this ... A-----B------C------D \ / --E--F--G-- ... if A initiates a route discovery to D, and C receives first the RREQ from G than from B the discovered route will be this one: A E F G C D and not: A B C D. Because when C receives the RREQ from B, C "silently discards" the packet. So for the attack you are suggesting to succeed, they would have to manage that the RREQ forwarded by the second bad guy (with the faked hop count) will be the fastest one to reach one of those nodes who can issue a RREP back (because they are intermediate nodes that have a route to the destination, or because they are the destination). And that is not easy because that means that they actually have to be the fastest path (acording to AODV policy of RREQ forwarding) to at least that intermediate node. Or, just the fastest path if there are no intermediate nodes (And in SAODV you can tell intermediate nodes not to respond RREQs if you want more security by sacrificing performance in route discovery. That is by using Single Signature Extensions (SSE) instead of Double Signature Extensions (DSE)). So actually with the increase level of security provide by SAODV when we don't allow intermediate nodes to reply (SSE); the attakers should be in the best path (acording to AODV way of selecting the path) to succeed to make the system believe that they are in the best path ;) So they are achieving nothing. And even in Double Signature Extensions, the attackers should manage to be the fast ones to arrive to one of the intermediate nodes to succeed. I should have thought about this before, because now if we look to the attack that Claude was proposing it is even less feaseble (for the same reason) that what I was originaly thinking. It does not matter that they lie about the hop count, they still have to be the fastest ones (therefore they have to be the path that would be picked up by AODV anyway). Best regards, Manel P.D.: If I'm missing something or you come up with new possible attacks, please, let me know. ext Casey Carter wrote: > Manel Guerrero Zapata wrote: > >> Hi Claude, >> >> you didn't miss anything ;) >> That's why I said: "although there are certain possible attacks against >> the authentication of the hop count"... >> That is exactly the attack you can perform: >> Bad guys can avoid the increasing of the hop count when they >> forward the packet. >> >> So the first part of a composed attack would be to try >> that enough bad guys get in one of the paths the RREQ travels through >> and try to be close enough to the optimal path so the difference that >> they cheat is enough to be selected as best path. >> That is not as easy as you might thing. >> If nodes move you have to have a lot of bad guys moving close to the best >> path, or just a huge amount of bad guys (people accept that if a 1/3 of >> the guys are bad there is not much you can do). >> I thing that in the real world the probability that the bad guys get the >> path going through them is not much higher than if the they wouldn't >> be cheating >> (because if you put a lot of bad guys close to the best path, even if >> they >> do account for the hop count they also get the possibility to be in the >> best path). >> >> Therefore I thing hash chains are pretty reasonable, and _very very >> cheap_! >> There are other mechanisms to protect the hop count but they are so >> much more >> expensive that they are not really feasible ones. >> But if you (or somebody else) come with a better idea, I'll be glad to >> study it. >> >> Regards, >> >> Manel >> >> >> P.D.: Another way to do the attack is that no matter how close they >> are to the path, >> but be one hop away from src & dst and have a whole path of bad guy >> no matter how long it is. (but then you need more bad boys than hops >> has the optimal path and being just one hop away form src & dst) >> So I thing bad guys will have a hard time doing this (now: imagine all >> nodes >> moving). >> > Or, have one bad guy next to the source, and one next to the > destination. The two bad guys collude by tunneling route requests/route > replies between src and dst to make it appear that the bad guys know a > three-hop route between them. Only requires two bad guys to divert > traffic. > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 19 11:15:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23220 for ; Fri, 19 Apr 2002 11:15:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17692 for manet-archive@odin.ietf.org; Fri, 19 Apr 2002 11:15:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15485; Fri, 19 Apr 2002 10:53:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA15459 for ; Fri, 19 Apr 2002 10:53:35 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22267 for ; Fri, 19 Apr 2002 10:53:31 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3JEsdJ02008 for ; Fri, 19 Apr 2002 17:54:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Apr 2002 17:53:32 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 19 Apr 2002 17:53:32 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id RAA21253; Fri, 19 Apr 2002 17:53:28 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC02F14.6010707@nokia.com> Date: Fri, 19 Apr 2002 17:52:04 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Casey Carter CC: ext Claude Castelluccia , manet@ietf.org Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2002 14:53:32.0572 (UTC) FILETIME=[F996C5C0:01C1E7B1] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Casey, That is a very good observation. Because if two nodes simulate that they have a link, it is very complicated to detect that they actualy don't have a link (even with misbehavior detection schemes). I've been thinking about the whole problem for a while and I realized about a funny thing: I usually thing about AODV route discovery assuming that it returns the shortest path between originator and destination. But that's not really true. Is it? It returns the shortest path among the paths through which the RREQ traveled faster from the originator to each final or intermediate node that has the route to the destination. (Or just the fastest one, in the case no intermediate nodes know a route to de destination). And that's the selected path in AODV. 8<------------------------------------------------- 6.5. Processing and Forwarding Route Requests When a node receives a RREQ, it first checks to determine whether it has received a RREQ with the same Originator IP Address and RREQ ID within at least the last PATH_TRAVERSAL_TIME milliseconds. If such a RREQ has been received, the node silently discards the newly received RREQ. The rest of this subsection describes actions taken for RREQs that are not discarded. ------------------------------------------------->8 According to this ... A-----B------C------D \ / --E--F--G-- ... if A initiates a route discovery to D, and C receives first the RREQ from G than from B the discovered route will be this one: A E F G C D and not: A B C D. Because when C receives the RREQ from B, C "silently discards" the packet. So for the attack you are suggesting to succeed, they would have to manage that the RREQ forwarded by the second bad guy (with the faked hop count) will be the fastest one to reach one of those nodes who can issue a RREP back (because they are intermediate nodes that have a route to the destination, or because they are the destination). And that is not easy because that means that they actually have to be the fastest path (acording to AODV policy of RREQ forwarding) to at least that intermediate node. Or, just the fastest path if there are no intermediate nodes (And in SAODV you can tell intermediate nodes not to respond RREQs if you want more security by sacrificing performance in route discovery. That is by using Single Signature Extensions (SSE) instead of Double Signature Extensions (DSE)). So actually with the increase level of security provide by SAODV when we don't allow intermediate nodes to reply (SSE); the attakers should be in the best path (acording to AODV way of selecting the path) to succeed to make the system believe that they are in the best path ;) So they are achieving nothing. And even in Double Signature Extensions, the attackers should manage to be the fast ones to arrive to one of the intermediate nodes to succeed. I should have thought about this before, because now if we look to the attack that Claude was proposing it is even less feaseble (for the same reason) that what I was originaly thinking. It does not matter that they lie about the hop count, they still have to be the fastest ones (therefore they have to be the path that would be picked up by AODV anyway). Best regards, Manel P.D.: If I'm missing something or you come up with new possible attacks, please, let me know. ext Casey Carter wrote: > Manel Guerrero Zapata wrote: > >> Hi Claude, >> >> you didn't miss anything ;) >> That's why I said: "although there are certain possible attacks against >> the authentication of the hop count"... >> That is exactly the attack you can perform: >> Bad guys can avoid the increasing of the hop count when they >> forward the packet. >> >> So the first part of a composed attack would be to try >> that enough bad guys get in one of the paths the RREQ travels through >> and try to be close enough to the optimal path so the difference that >> they cheat is enough to be selected as best path. >> That is not as easy as you might thing. >> If nodes move you have to have a lot of bad guys moving close to the best >> path, or just a huge amount of bad guys (people accept that if a 1/3 of >> the guys are bad there is not much you can do). >> I thing that in the real world the probability that the bad guys get the >> path going through them is not much higher than if the they wouldn't >> be cheating >> (because if you put a lot of bad guys close to the best path, even if >> they >> do account for the hop count they also get the possibility to be in the >> best path). >> >> Therefore I thing hash chains are pretty reasonable, and _very very >> cheap_! >> There are other mechanisms to protect the hop count but they are so >> much more >> expensive that they are not really feasible ones. >> But if you (or somebody else) come with a better idea, I'll be glad to >> study it. >> >> Regards, >> >> Manel >> >> >> P.D.: Another way to do the attack is that no matter how close they >> are to the path, >> but be one hop away from src & dst and have a whole path of bad guy >> no matter how long it is. (but then you need more bad boys than hops >> has the optimal path and being just one hop away form src & dst) >> So I thing bad guys will have a hard time doing this (now: imagine all >> nodes >> moving). >> > Or, have one bad guy next to the source, and one next to the > destination. The two bad guys collude by tunneling route requests/route > replies between src and dst to make it appear that the bad guys know a > three-hop route between them. Only requires two bad guys to divert > traffic. > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 19 13:32:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07923 for ; Fri, 19 Apr 2002 13:32:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26695; Fri, 19 Apr 2002 13:08:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26663 for ; Fri, 19 Apr 2002 13:08:25 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04838 for ; Fri, 19 Apr 2002 13:08:23 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28935; Fri, 19 Apr 2002 10:07:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3JH7rh11461; Fri, 19 Apr 2002 10:07:53 -0700 X-mProtect: <200204191707> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcnvIl4; Fri, 19 Apr 2002 10:07:50 PDT Message-ID: <3CC04EE3.A628C858@iprg.nokia.com> Date: Fri, 19 Apr 2002 10:07:47 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Questions on draft-ietf-manet-aodv-10.txt References: <003f01c1e7ae$324d0a40$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Thanks for your comments! Phil Neumiller wrote: > 2). All. Document organization. When trying to implement the draft, one would > find it particularly convenient if all the references on how to handle the reception > of a particular message i.e. RREQ, RREP, etc. were in the same subsection. > I would prefer four new sections be aggregated into the draft, with subsection > titles of: > > "Handling RREQ Messages" > "Handling RREP Messages", etc... i.e. for each AODV message type. This is quite ambitious for a document that is almost "finished"! Maybe it would be better to delay such a reorganization for some future revision past Experimental? (I hope!) > An implementation question... > > 3). AODV specifies the creation of its own route table structure. .... > Is there any reason, why AODV does not specify the interaction > between its route table and the route table that may be present on the host > (and conflicting with) it. I think it should be better to cast any discussion in the AODV specification in such a way that it is NOT interpreted as creation of a new route table. AODV needs more things than are in a vanilla route table, but they can be adjuncts to a route table -- or, with more complexity, a mirror of the route table that is consulted in conjuction with route table accesses. It's really a platform issue, and I believe the protocol specification has to be kept separate from considerations about structure of a route table. Surely kernel programmers don't have to restrict their route table interface routines to using only the variables defined in some MIB. > Also, would it not be advisable to modify RFC 1396 to > accomodate MANET protocols? This way we could get down to one route > table on host and router platforms right? The precusror list does not necessarily > need to be in there. Also, the route table could be treated like a relational > database indexed on IP destination addr so the redundant information could > be put into the "real route table". This is particularly important on embedded > devices. Presumably, this is not suggested as part of AODV. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 19 13:32:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07934 for ; Fri, 19 Apr 2002 13:32:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28551 for manet-archive@odin.ietf.org; Fri, 19 Apr 2002 13:32:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26695; Fri, 19 Apr 2002 13:08:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26663 for ; Fri, 19 Apr 2002 13:08:25 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04838 for ; Fri, 19 Apr 2002 13:08:23 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28935; Fri, 19 Apr 2002 10:07:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3JH7rh11461; Fri, 19 Apr 2002 10:07:53 -0700 X-mProtect: <200204191707> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcnvIl4; Fri, 19 Apr 2002 10:07:50 PDT Message-ID: <3CC04EE3.A628C858@iprg.nokia.com> Date: Fri, 19 Apr 2002 10:07:47 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Questions on draft-ietf-manet-aodv-10.txt References: <003f01c1e7ae$324d0a40$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Thanks for your comments! Phil Neumiller wrote: > 2). All. Document organization. When trying to implement the draft, one would > find it particularly convenient if all the references on how to handle the reception > of a particular message i.e. RREQ, RREP, etc. were in the same subsection. > I would prefer four new sections be aggregated into the draft, with subsection > titles of: > > "Handling RREQ Messages" > "Handling RREP Messages", etc... i.e. for each AODV message type. This is quite ambitious for a document that is almost "finished"! Maybe it would be better to delay such a reorganization for some future revision past Experimental? (I hope!) > An implementation question... > > 3). AODV specifies the creation of its own route table structure. .... > Is there any reason, why AODV does not specify the interaction > between its route table and the route table that may be present on the host > (and conflicting with) it. I think it should be better to cast any discussion in the AODV specification in such a way that it is NOT interpreted as creation of a new route table. AODV needs more things than are in a vanilla route table, but they can be adjuncts to a route table -- or, with more complexity, a mirror of the route table that is consulted in conjuction with route table accesses. It's really a platform issue, and I believe the protocol specification has to be kept separate from considerations about structure of a route table. Surely kernel programmers don't have to restrict their route table interface routines to using only the variables defined in some MIB. > Also, would it not be advisable to modify RFC 1396 to > accomodate MANET protocols? This way we could get down to one route > table on host and router platforms right? The precusror list does not necessarily > need to be in there. Also, the route table could be treated like a relational > database indexed on IP destination addr so the redundant information could > be put into the "real route table". This is particularly important on embedded > devices. Presumably, this is not suggested as part of AODV. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 19 16:38:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00410 for ; Fri, 19 Apr 2002 16:38:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07406; Fri, 19 Apr 2002 16:13:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07373 for ; Fri, 19 Apr 2002 16:13:01 -0400 (EDT) Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27758 for ; Fri, 19 Apr 2002 16:12:57 -0400 (EDT) Received: from uta.edu (gergo.uta.edu [129.107.69.51]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id PAA07043 for ; Fri, 19 Apr 2002 15:14:46 -0500 (CDT) Message-ID: <3CC07A41.87564159@uta.edu> Date: Fri, 19 Apr 2002 15:12:50 -0500 From: Gergely Zaruba X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "'manet@ietf.org'" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] CFP: 5th ACM Workshop on Wireless Mobile Multimedia (WoWMoM2002), papers due: June 25, 2002 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit [Our apologies if you receive multiple copies of this CFP.] ANNOUNCEMENT AND CALL FOR PAPERS WoWMoM 2002 The Fifth ACM International Workshop on Wireless Mobile Multimedia September 28, 2002 - Atlanta, Georgia (in conjunction with MobiCom'2002) http://www.ing.unipi.it/wowmom2002 WoWMoM is the premier international forum for discussions between researchers, practitioners and students interested in the symbiosis of mobile computers, wireless networks, and multimedia systems. WoWMoM 2002 is the fifth workshop of this series, and is sponsored by ACM SIGMOBILE. The WoWMoM 2002 technical program committee is soliciting papers describing original, previously unpublished, completed or on-going research, on topics including, but not limited to, the following: - Mobile and Wireless Multimedia Applications - Mobile Web Access - Pervasive computing - QoS in the Mobile and Wireless Networks - Caching and delivery of streaming media over wireless networks - Real-time voice/video over mobile and wireless networks - Mobile and Wireless Multimedia Networks - IP-based Mobile Networks - Mobility Management - Multicasting in Wireless Services - Ad hoc sensor networks - Mobile ad hoc networks - Wireless BAN, PAN and LAN - Third and Fourth Generation Systems - 3G/WLAN internetworking - Performance evaluation of wireless and mobile multimedia systems PAPERS SUBMISSION AND PUBLICATION =============================== Papers should neither have been published elsewhere nor currently under review by another conference or journal. For papers submission, please follow the submission instructions: http://www.ing.unipi.it/wowmom2002 All papers will be reviewed by the program committee members. Accepted papers will appear in the workshop proceedings published by ACM. IMPORTANT DATES =============== Full papers due: June 25, 2002 Notification: July 25, 2002 Camera Ready due: August 5, 2002 EXECUTIVE COMMITTEE =================== GENERAL Chair: Sajal K. Das, The University of Texas at Arlington, USA GENERAL Vice-Chair: Kalyan Basu, The University of Texas at Arlington, USA TECHNICAL PROGRAM Co-chairs: Marco Conti, National Research Council, Italy Dipankar Raychaudhuri WINLAB/Rutgers University, USA FINANCE Chair: Mohan Kumar, The University of Texas at Arlington, USA PUBLICITY Co-chairs: Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Andrea Passarella, University of Pisa, Italy Gergely Zaruba, The University of Texas at Arlington, USA STEERING COMMITTEE Members: Ian F. Akyildiz, Georgia Institute of Technology, USA Kalyan Basu, The University of Texas at Arlington, USA Imrich Chlamtac, The University of Texas at Dallas, USA Sajal K. Das, The University of Texas at Arlington, USA (Chair) Randy Katz, University of California at Berkeley, USA Mahmoud Naghshineh, IBM T.J. Watson Research Center, USA Christopher Rose, Rutgers University, USA Satish K. Tripathi, University of California at Riverside, USA TECHNICAL PROGRAM COMMITTEE Members: To be announced http://www.ing.unipi.it/wowmom2002/prog-committee.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 19 16:38:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00429 for ; Fri, 19 Apr 2002 16:38:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA08939 for manet-archive@odin.ietf.org; Fri, 19 Apr 2002 16:38:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07406; Fri, 19 Apr 2002 16:13:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07373 for ; Fri, 19 Apr 2002 16:13:01 -0400 (EDT) Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27758 for ; Fri, 19 Apr 2002 16:12:57 -0400 (EDT) Received: from uta.edu (gergo.uta.edu [129.107.69.51]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id PAA07043 for ; Fri, 19 Apr 2002 15:14:46 -0500 (CDT) Message-ID: <3CC07A41.87564159@uta.edu> Date: Fri, 19 Apr 2002 15:12:50 -0500 From: Gergely Zaruba X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "'manet@ietf.org'" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] CFP: 5th ACM Workshop on Wireless Mobile Multimedia (WoWMoM2002), papers due: June 25, 2002 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit [Our apologies if you receive multiple copies of this CFP.] ANNOUNCEMENT AND CALL FOR PAPERS WoWMoM 2002 The Fifth ACM International Workshop on Wireless Mobile Multimedia September 28, 2002 - Atlanta, Georgia (in conjunction with MobiCom'2002) http://www.ing.unipi.it/wowmom2002 WoWMoM is the premier international forum for discussions between researchers, practitioners and students interested in the symbiosis of mobile computers, wireless networks, and multimedia systems. WoWMoM 2002 is the fifth workshop of this series, and is sponsored by ACM SIGMOBILE. The WoWMoM 2002 technical program committee is soliciting papers describing original, previously unpublished, completed or on-going research, on topics including, but not limited to, the following: - Mobile and Wireless Multimedia Applications - Mobile Web Access - Pervasive computing - QoS in the Mobile and Wireless Networks - Caching and delivery of streaming media over wireless networks - Real-time voice/video over mobile and wireless networks - Mobile and Wireless Multimedia Networks - IP-based Mobile Networks - Mobility Management - Multicasting in Wireless Services - Ad hoc sensor networks - Mobile ad hoc networks - Wireless BAN, PAN and LAN - Third and Fourth Generation Systems - 3G/WLAN internetworking - Performance evaluation of wireless and mobile multimedia systems PAPERS SUBMISSION AND PUBLICATION =============================== Papers should neither have been published elsewhere nor currently under review by another conference or journal. For papers submission, please follow the submission instructions: http://www.ing.unipi.it/wowmom2002 All papers will be reviewed by the program committee members. Accepted papers will appear in the workshop proceedings published by ACM. IMPORTANT DATES =============== Full papers due: June 25, 2002 Notification: July 25, 2002 Camera Ready due: August 5, 2002 EXECUTIVE COMMITTEE =================== GENERAL Chair: Sajal K. Das, The University of Texas at Arlington, USA GENERAL Vice-Chair: Kalyan Basu, The University of Texas at Arlington, USA TECHNICAL PROGRAM Co-chairs: Marco Conti, National Research Council, Italy Dipankar Raychaudhuri WINLAB/Rutgers University, USA FINANCE Chair: Mohan Kumar, The University of Texas at Arlington, USA PUBLICITY Co-chairs: Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Andrea Passarella, University of Pisa, Italy Gergely Zaruba, The University of Texas at Arlington, USA STEERING COMMITTEE Members: Ian F. Akyildiz, Georgia Institute of Technology, USA Kalyan Basu, The University of Texas at Arlington, USA Imrich Chlamtac, The University of Texas at Dallas, USA Sajal K. Das, The University of Texas at Arlington, USA (Chair) Randy Katz, University of California at Berkeley, USA Mahmoud Naghshineh, IBM T.J. Watson Research Center, USA Christopher Rose, Rutgers University, USA Satish K. Tripathi, University of California at Riverside, USA TECHNICAL PROGRAM COMMITTEE Members: To be announced http://www.ing.unipi.it/wowmom2002/prog-committee.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Apr 20 14:26:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05613 for ; Sat, 20 Apr 2002 14:26:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05672; Sat, 20 Apr 2002 12:42:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05643 for ; Sat, 20 Apr 2002 12:42:45 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04287 for ; Sat, 20 Apr 2002 12:42:42 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3KGHpR12228 for ; Sat, 20 Apr 2002 18:17:51 +0200 (MEST) Received: from charmette (home6.inrialpes.fr [194.199.17.134]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3KGHpX26400 for ; Sat, 20 Apr 2002 18:17:51 +0200 (MEST) Message-ID: <001a01c1e887$4fd9fe40$8611c7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: Date: Sat, 20 Apr 2002 18:18:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C1E897.BEEB9360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [manet] -simple AODV question- Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C1E897.BEEB9360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello , How can a host A that sends a RREQ for host B specify that it only wants to receive RREP from host B and won'' t accept any RREP from intermediate nodes.. is that possible? thanks, Claude. ------=_NextPart_000_0016_01C1E897.BEEB9360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello ,
 
How can a host A that sends a RREQ = for host B=20 specify that it
only wants to = receive RREP=20 from host B and won'' t accept any RREP
from intermediate nodes.. is = that=20 possible?
 
thanks,
Claude.
------=_NextPart_000_0016_01C1E897.BEEB9360-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Sat Apr 20 14:26:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05623 for ; Sat, 20 Apr 2002 14:26:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09899 for manet-archive@odin.ietf.org; Sat, 20 Apr 2002 14:26:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05672; Sat, 20 Apr 2002 12:42:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05643 for ; Sat, 20 Apr 2002 12:42:45 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04287 for ; Sat, 20 Apr 2002 12:42:42 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3KGHpR12228 for ; Sat, 20 Apr 2002 18:17:51 +0200 (MEST) Received: from charmette (home6.inrialpes.fr [194.199.17.134]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3KGHpX26400 for ; Sat, 20 Apr 2002 18:17:51 +0200 (MEST) Message-ID: <001a01c1e887$4fd9fe40$8611c7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: Date: Sat, 20 Apr 2002 18:18:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C1E897.BEEB9360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [manet] -simple AODV question- Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C1E897.BEEB9360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello , How can a host A that sends a RREQ for host B specify that it only wants to receive RREP from host B and won'' t accept any RREP from intermediate nodes.. is that possible? thanks, Claude. ------=_NextPart_000_0016_01C1E897.BEEB9360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello ,
 
How can a host A that sends a RREQ = for host B=20 specify that it
only wants to = receive RREP=20 from host B and won'' t accept any RREP
from intermediate nodes.. is = that=20 possible?
 
thanks,
Claude.
------=_NextPart_000_0016_01C1E897.BEEB9360-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Apr 21 16:16:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01182 for ; Sun, 21 Apr 2002 16:16:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13979; Sun, 21 Apr 2002 15:18:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13932 for ; Sun, 21 Apr 2002 15:18:20 -0400 (EDT) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00563 for ; Sun, 21 Apr 2002 15:18:13 -0400 (EDT) Received: from onr8 (ts16-112.dialup.bol.ucla.edu [164.67.26.121]) by kiwi.cs.ucla.edu (8.10.2+Sun/8.10.2/UCLACS-5.1) with SMTP id g3LJHbi04539; Sun, 21 Apr 2002 12:17:37 -0700 (PDT) Message-ID: <00d101c1e968$b3c1d5e0$791a43a4@onr8> From: "Mario Gerla" To: Cc: "mario gerla" Date: Sun, 21 Apr 2002 12:14:03 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01C1E92E.068B89A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [manet] Re: AINS 2002, Call for Participation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01C1E92E.068B89A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies if you receive multiple copies of this announcement=20 -------------------------------------------------------------------------= ----------------------------------- The First Autonomous Intelligent Networks and Systems (AINS) = Symposium Sponsored by ONR and IEEE May 8 - 9 , 2002 UCLA, Los Angeles, California http://www.ains.cs.ucla.edu =20 CALL FOR PARTICIPATION Registration, advance program and information on local arrangements are = now available=20 on the web page. Early registration is advised. ------=_NextPart_000_00CE_01C1E92E.068B89A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Apologies if you receive multiple = copies of this=20 announcement=20
 
----------------------------------------------------------------= --------------------------------------------
    The First Autonomous = Intelligent=20 Networks and Systems (AINS) Symposium
          &nbs= p;            = ;  =20 Sponsored by ONR and IEEE
          &nbs= p;            = ;      =20 May 8 - 9 ,=20 2002
           = ;            = UCLA,=20 Los=20 Angeles, California

       = ;            =     =20 http://www.ains.cs.ucla.edu
 
          &nbs= p;           CALL = FOR PARTICIPATION


Registration, advance program and = information on=20 local arrangements are now available
on the web page. Early registration is=20 advised.
------=_NextPart_000_00CE_01C1E92E.068B89A0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun Apr 21 16:16:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01193 for ; Sun, 21 Apr 2002 16:16:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16871 for manet-archive@odin.ietf.org; Sun, 21 Apr 2002 16:16:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13979; Sun, 21 Apr 2002 15:18:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13932 for ; Sun, 21 Apr 2002 15:18:20 -0400 (EDT) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00563 for ; Sun, 21 Apr 2002 15:18:13 -0400 (EDT) Received: from onr8 (ts16-112.dialup.bol.ucla.edu [164.67.26.121]) by kiwi.cs.ucla.edu (8.10.2+Sun/8.10.2/UCLACS-5.1) with SMTP id g3LJHbi04539; Sun, 21 Apr 2002 12:17:37 -0700 (PDT) Message-ID: <00d101c1e968$b3c1d5e0$791a43a4@onr8> From: "Mario Gerla" To: Cc: "mario gerla" Date: Sun, 21 Apr 2002 12:14:03 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CE_01C1E92E.068B89A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [manet] Re: AINS 2002, Call for Participation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01C1E92E.068B89A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies if you receive multiple copies of this announcement=20 -------------------------------------------------------------------------= ----------------------------------- The First Autonomous Intelligent Networks and Systems (AINS) = Symposium Sponsored by ONR and IEEE May 8 - 9 , 2002 UCLA, Los Angeles, California http://www.ains.cs.ucla.edu =20 CALL FOR PARTICIPATION Registration, advance program and information on local arrangements are = now available=20 on the web page. Early registration is advised. ------=_NextPart_000_00CE_01C1E92E.068B89A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Apologies if you receive multiple = copies of this=20 announcement=20
 
----------------------------------------------------------------= --------------------------------------------
    The First Autonomous = Intelligent=20 Networks and Systems (AINS) Symposium
          &nbs= p;            = ;  =20 Sponsored by ONR and IEEE
          &nbs= p;            = ;      =20 May 8 - 9 ,=20 2002
           = ;            = UCLA,=20 Los=20 Angeles, California

       = ;            =     =20 http://www.ains.cs.ucla.edu
 
          &nbs= p;           CALL = FOR PARTICIPATION


Registration, advance program and = information on=20 local arrangements are now available
on the web page. Early registration is=20 advised.
------=_NextPart_000_00CE_01C1E92E.068B89A0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 04:40:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19241 for ; Mon, 22 Apr 2002 04:40:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26495; Mon, 22 Apr 2002 04:20:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26466 for ; Mon, 22 Apr 2002 04:20:38 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18942 for ; Mon, 22 Apr 2002 04:20:34 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3M8KrF17522 for ; Mon, 22 Apr 2002 11:20:53 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 11:20:35 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 11:20:35 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA12605; Mon, 22 Apr 2002 11:20:34 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC3C777.1050900@nokia.com> Date: Mon, 22 Apr 2002 11:19:03 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Pete Sholander CC: manet@ietf.org Subject: Re: [manet] Security Considerations of AODV References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2002 08:20:35.0659 (UTC) FILETIME=[93E499B0:01C1E9D6] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Pete, If Attackers broadcast the packets correctly and also do the tunneling thing the watchdog won't detect anything so the pathrater won't change its metrics. So no, theses kind of misbehaving detection schemes do not detect attacks that use tunneling. BR/Manel ext Pete Sholander wrote: > Couldn't techniques like Mary Baker's "path rater algorithm" (she's a Stanford prof?) protect against this attack if nodes are using broadcast channels. Other nodes would notice the bad nodes and vote to exclude them? > > >>>>Manel Guerrero Zapata 04/18/02 12:16PM >>> >>>> > Hi Claude, > > you didn't miss anything ;) > That's why I said: "although there are certain possible attacks against > the authentication of the hop count"... > That is exactly the attack you can perform: > Bad guys can avoid the increasing of the hop count when they > forward the packet. > > So the first part of a composed attack would be to try > that enough bad guys get in one of the paths the RREQ travels through > and try to be close enough to the optimal path so the difference that > they cheat is enough to be selected as best path. > That is not as easy as you might thing. > If nodes move you have to have a lot of bad guys moving close to the best > path, or just a huge amount of bad guys (people accept that if a 1/3 of > the guys are bad there is not much you can do). > I thing that in the real world the probability that the bad guys get the > path going through them is not much higher than if the they wouldn't be cheating > (because if you put a lot of bad guys close to the best path, even if they > do account for the hop count they also get the possibility to be in the > best path). > > Therefore I thing hash chains are pretty reasonable, and _very very cheap_! > There are other mechanisms to protect the hop count but they are so much more > expensive that they are not really feasible ones. > But if you (or somebody else) come with a better idea, I'll be glad to > study it. > > Regards, > > Manel > > > P.D.: Another way to do the attack is that no matter how close they are to the path, > but be one hop away from src & dst and have a whole path of bad guy > no matter how long it is. (but then you need more bad boys than hops > has the optimal path and being just one hop away form src & dst) > So I thing bad guys will have a hard time doing this (now: imagine all nodes > moving). > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Mon Apr 22 04:40:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19252 for ; Mon, 22 Apr 2002 04:40:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA28495 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 04:40:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26495; Mon, 22 Apr 2002 04:20:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26466 for ; Mon, 22 Apr 2002 04:20:38 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18942 for ; Mon, 22 Apr 2002 04:20:34 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3M8KrF17522 for ; Mon, 22 Apr 2002 11:20:53 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 11:20:35 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 11:20:35 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA12605; Mon, 22 Apr 2002 11:20:34 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC3C777.1050900@nokia.com> Date: Mon, 22 Apr 2002 11:19:03 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Pete Sholander CC: manet@ietf.org Subject: Re: [manet] Security Considerations of AODV References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2002 08:20:35.0659 (UTC) FILETIME=[93E499B0:01C1E9D6] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Pete, If Attackers broadcast the packets correctly and also do the tunneling thing the watchdog won't detect anything so the pathrater won't change its metrics. So no, theses kind of misbehaving detection schemes do not detect attacks that use tunneling. BR/Manel ext Pete Sholander wrote: > Couldn't techniques like Mary Baker's "path rater algorithm" (she's a Stanford prof?) protect against this attack if nodes are using broadcast channels. Other nodes would notice the bad nodes and vote to exclude them? > > >>>>Manel Guerrero Zapata 04/18/02 12:16PM >>> >>>> > Hi Claude, > > you didn't miss anything ;) > That's why I said: "although there are certain possible attacks against > the authentication of the hop count"... > That is exactly the attack you can perform: > Bad guys can avoid the increasing of the hop count when they > forward the packet. > > So the first part of a composed attack would be to try > that enough bad guys get in one of the paths the RREQ travels through > and try to be close enough to the optimal path so the difference that > they cheat is enough to be selected as best path. > That is not as easy as you might thing. > If nodes move you have to have a lot of bad guys moving close to the best > path, or just a huge amount of bad guys (people accept that if a 1/3 of > the guys are bad there is not much you can do). > I thing that in the real world the probability that the bad guys get the > path going through them is not much higher than if the they wouldn't be cheating > (because if you put a lot of bad guys close to the best path, even if they > do account for the hop count they also get the possibility to be in the > best path). > > Therefore I thing hash chains are pretty reasonable, and _very very cheap_! > There are other mechanisms to protect the hop count but they are so much more > expensive that they are not really feasible ones. > But if you (or somebody else) come with a better idea, I'll be glad to > study it. > > Regards, > > Manel > > > P.D.: Another way to do the attack is that no matter how close they are to the path, > but be one hop away from src & dst and have a whole path of bad guy > no matter how long it is. (but then you need more bad boys than hops > has the optimal path and being just one hop away form src & dst) > So I thing bad guys will have a hard time doing this (now: imagine all nodes > moving). > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 12:36:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01636 for ; Mon, 22 Apr 2002 12:36:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25777; Mon, 22 Apr 2002 12:10:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25748 for ; Mon, 22 Apr 2002 12:10:37 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00798 for ; Mon, 22 Apr 2002 12:10:32 -0400 (EDT) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g3MGA7O24554; Mon, 22 Apr 2002 09:10:07 -0700 (PDT) Message-Id: <200204221610.g3MGA7O24554@letters.cs.ucsb.edu> Date: Mon, 22 Apr 2002 09:10:07 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" Subject: Re: [manet] -simple AODV question- To: claude.castelluccia@inrialpes.fr Cc: manet@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MTwu+6hvFgkovzowutbuqA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Claude, At this time, no, it is not possible, although it would be an easy addition if there were sufficient reason. Elizabeth ~> ~> How can a host A that sends a RREQ for host B specify that it ~> only wants to receive RREP from host B and won'' t accept any RREP ~> from intermediate nodes.. is that possible? ~> ~> thanks, ~> Claude. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 12:36:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01645 for ; Mon, 22 Apr 2002 12:36:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27771 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 12:36:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25777; Mon, 22 Apr 2002 12:10:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25748 for ; Mon, 22 Apr 2002 12:10:37 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00798 for ; Mon, 22 Apr 2002 12:10:32 -0400 (EDT) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g3MGA7O24554; Mon, 22 Apr 2002 09:10:07 -0700 (PDT) Message-Id: <200204221610.g3MGA7O24554@letters.cs.ucsb.edu> Date: Mon, 22 Apr 2002 09:10:07 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" Subject: Re: [manet] -simple AODV question- To: claude.castelluccia@inrialpes.fr Cc: manet@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MTwu+6hvFgkovzowutbuqA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Claude, At this time, no, it is not possible, although it would be an easy addition if there were sufficient reason. Elizabeth ~> ~> How can a host A that sends a RREQ for host B specify that it ~> only wants to receive RREP from host B and won'' t accept any RREP ~> from intermediate nodes.. is that possible? ~> ~> thanks, ~> Claude. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 13:30:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03964 for ; Mon, 22 Apr 2002 13:30:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29535; Mon, 22 Apr 2002 13:02:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29505 for ; Mon, 22 Apr 2002 13:02:55 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02703 for ; Mon, 22 Apr 2002 13:02:51 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MH30F00722 for ; Mon, 22 Apr 2002 20:03:09 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 20:02:42 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 20:02:42 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id UAA22549; Mon, 22 Apr 2002 20:02:39 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC441D3.5020905@nokia.com> Date: Mon, 22 Apr 2002 20:01:07 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Casey Carter CC: ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2002 17:02:42.0813 (UTC) FILETIME=[8454F2D0:01C1EA1F] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Casey, Comments bellow. ext Casey Carter wrote: > Manel Guerrero Zapata wrote: > >> Hi Casey, >> [...] >> So for the attack you are suggesting to succeed, they would have to >> manage that >> the RREQ forwarded by the second bad guy (with the faked hop count) will >> be the fastest one to reach one of those nodes who can issue a RREP back >> (because they are intermediate nodes that have a route to the >> destination, >> or because they are the destination). >> And that is not easy because that means that they actually have to be the >> fastest path (acording to AODV policy of RREQ forwarding) to at least >> that >> intermediate node. Or, just the fastest path if there are no >> intermediate nodes > > > Unfortunately, you have to assume that the attacker always knows what he > is doing; we replace the notion "shortest" with "fastest". Yes, but my point here is that it is not so important that there is some possible attack to the hop count integrity, because that is not a key element to get a route selected among others. It does not give a real benefit to the attackers. > Although I > can't find anything on the subject in the draft, it is well known among > implementors of ad hoc routing protocols that immediate rebroadcast of > flooded packets (e.g., route requests) is a bad idea: the synchronized > broadcasts from multiple nodes cause extremely high contention, and > (especially in simulations) lots of collisions.The solution for this > problem is for each node to choose a small random backoff timer to > better distribute the rebroadcasts. I thing this is something you find only in the simulation world (that if you broadcast a RREQ all your neighbors will rebroadcast it at the very same time and all the packets will collide). But in the real world, if you use some wireless card they already have (like the ethernet cards) this small random backoff, to avoid collisions, for every packet they send. > The consequence of this is that a > route request travels slower through the MANET than regular unicast > traffic. So if my attackers have a clue, they will maintain an active > route between them to support the packet tunnel. This tunnel will > deliver the route request from the source's tail to the destination's > tail slightly before the route request flood reaches the destination's > region of the MANET, and the first route request the destination > receives will be through the "magic" link. Since there is no added delay for rebroadcasting, the attackers have more or less the same chances to be the fastest as if they wouldn't be bad boys. So tunneling and breaking the hop count does not give any advantage to the attackers in order to get the traffic going between them. > The attackers can coordinate > to make sure that they are on or near the shortest path between the > source and destination, so this attack should be quite effective in > denying communication betweem source and dest. The attack is assisted > by expanding ring search (Section 6.4 in draft 10), since the attackers > can probably tail the source and destination fairly closely. In this > case, the attackers need only be "close" to the fastest path. If people are using expanding ring, then the attackers have a big chance to be the fastest. But in scenarios more security demanding the originator of the RREQ could decide not to use the expanding ring search technique. And that's it. There is no attack then. > If the attackers have more resources at their disposal, they can improve > upon this margin. The attackers can purchase better radios than what is > commonly used in the MANET, so that they actually DO have the fastest, > shortest link across the MANET. AODV/DSR/whatever will then choose the > path through the attackers as the shortest path. The gist of this > argument is that simply authenticating the RREQ/RREPs is not sufficent > to preserve availability of communication between source and > destination, but only to verify that a route exists. Well, if attackers just by having better radios than the rest able to be in the faster/shorter path. They don't need to misbehave to be in the path. So then they are just as good boys which happend to have better radios. So their route should be selected. And if an attacker can put himself _in_ the fastest path, then he is in the fastest path. Although that is not so easy if nodes are moving. From experiences with real implementations (not simulations) a communication between two nodes does not happen through the same path all the time, it is changing the route quite a lot. I have never stated than SAODV is able to "preserve availability of communication between source and destination". Actually in the abstract of the draft it says: 8<--------------------------------------------------------------------- The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension of the AODV routing protocol that can be used to protect the route discovery mechanism providing security features like integrity, authentication and non-repudiation. --------------------------------------------------------------------->8 But I don't say anything about Denial of Service. If an attacker wants to do a DoS it will probably find easier to flood the network with packets or to send a packet every time it detects one it's being sent (so they'll collide) or just emit interferences with the max power it can. Then, not even simetric cryptosystems will save you. Regards, Manel Guerrero _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 13:30:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03975 for ; Mon, 22 Apr 2002 13:30:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01914 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 13:30:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29535; Mon, 22 Apr 2002 13:02:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29505 for ; Mon, 22 Apr 2002 13:02:55 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02703 for ; Mon, 22 Apr 2002 13:02:51 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MH30F00722 for ; Mon, 22 Apr 2002 20:03:09 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 20:02:42 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 20:02:42 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id UAA22549; Mon, 22 Apr 2002 20:02:39 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC441D3.5020905@nokia.com> Date: Mon, 22 Apr 2002 20:01:07 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Casey Carter CC: ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2002 17:02:42.0813 (UTC) FILETIME=[8454F2D0:01C1EA1F] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Casey, Comments bellow. ext Casey Carter wrote: > Manel Guerrero Zapata wrote: > >> Hi Casey, >> [...] >> So for the attack you are suggesting to succeed, they would have to >> manage that >> the RREQ forwarded by the second bad guy (with the faked hop count) will >> be the fastest one to reach one of those nodes who can issue a RREP back >> (because they are intermediate nodes that have a route to the >> destination, >> or because they are the destination). >> And that is not easy because that means that they actually have to be the >> fastest path (acording to AODV policy of RREQ forwarding) to at least >> that >> intermediate node. Or, just the fastest path if there are no >> intermediate nodes > > > Unfortunately, you have to assume that the attacker always knows what he > is doing; we replace the notion "shortest" with "fastest". Yes, but my point here is that it is not so important that there is some possible attack to the hop count integrity, because that is not a key element to get a route selected among others. It does not give a real benefit to the attackers. > Although I > can't find anything on the subject in the draft, it is well known among > implementors of ad hoc routing protocols that immediate rebroadcast of > flooded packets (e.g., route requests) is a bad idea: the synchronized > broadcasts from multiple nodes cause extremely high contention, and > (especially in simulations) lots of collisions.The solution for this > problem is for each node to choose a small random backoff timer to > better distribute the rebroadcasts. I thing this is something you find only in the simulation world (that if you broadcast a RREQ all your neighbors will rebroadcast it at the very same time and all the packets will collide). But in the real world, if you use some wireless card they already have (like the ethernet cards) this small random backoff, to avoid collisions, for every packet they send. > The consequence of this is that a > route request travels slower through the MANET than regular unicast > traffic. So if my attackers have a clue, they will maintain an active > route between them to support the packet tunnel. This tunnel will > deliver the route request from the source's tail to the destination's > tail slightly before the route request flood reaches the destination's > region of the MANET, and the first route request the destination > receives will be through the "magic" link. Since there is no added delay for rebroadcasting, the attackers have more or less the same chances to be the fastest as if they wouldn't be bad boys. So tunneling and breaking the hop count does not give any advantage to the attackers in order to get the traffic going between them. > The attackers can coordinate > to make sure that they are on or near the shortest path between the > source and destination, so this attack should be quite effective in > denying communication betweem source and dest. The attack is assisted > by expanding ring search (Section 6.4 in draft 10), since the attackers > can probably tail the source and destination fairly closely. In this > case, the attackers need only be "close" to the fastest path. If people are using expanding ring, then the attackers have a big chance to be the fastest. But in scenarios more security demanding the originator of the RREQ could decide not to use the expanding ring search technique. And that's it. There is no attack then. > If the attackers have more resources at their disposal, they can improve > upon this margin. The attackers can purchase better radios than what is > commonly used in the MANET, so that they actually DO have the fastest, > shortest link across the MANET. AODV/DSR/whatever will then choose the > path through the attackers as the shortest path. The gist of this > argument is that simply authenticating the RREQ/RREPs is not sufficent > to preserve availability of communication between source and > destination, but only to verify that a route exists. Well, if attackers just by having better radios than the rest able to be in the faster/shorter path. They don't need to misbehave to be in the path. So then they are just as good boys which happend to have better radios. So their route should be selected. And if an attacker can put himself _in_ the fastest path, then he is in the fastest path. Although that is not so easy if nodes are moving. From experiences with real implementations (not simulations) a communication between two nodes does not happen through the same path all the time, it is changing the route quite a lot. I have never stated than SAODV is able to "preserve availability of communication between source and destination". Actually in the abstract of the draft it says: 8<--------------------------------------------------------------------- The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension of the AODV routing protocol that can be used to protect the route discovery mechanism providing security features like integrity, authentication and non-repudiation. --------------------------------------------------------------------->8 But I don't say anything about Denial of Service. If an attacker wants to do a DoS it will probably find easier to flood the network with packets or to send a packet every time it detects one it's being sent (so they'll collide) or just emit interferences with the max power it can. Then, not even simetric cryptosystems will save you. Regards, Manel Guerrero _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 13:48:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04866 for ; Mon, 22 Apr 2002 13:48:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01101; Mon, 22 Apr 2002 13:21:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00950 for ; Mon, 22 Apr 2002 13:20:59 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03481 for ; Mon, 22 Apr 2002 13:20:54 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY10A2; Mon, 22 Apr 2002 13:20:45 -0400 Message-ID: <000901c1ea22$09c90080$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Manel Guerrero Zapata" , "ext Casey Carter" Cc: "ext Claude Castelluccia" , , "Seung Yi" References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> Date: Mon, 22 Apr 2002 13:20:45 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Re Security considerations in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Can we agree to simple premises for MANET security? A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is deployed with trusted fixed infrastructure that shares the MANET algorithm. B). This means key management is the only REAL issue. C). There are plenty of research papers on key management issues for ad hoc networks, I suggest the security enthusiests read these. D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network a good solution for key management does not yet exist. Please find one. It is silly to talk about what parts of MANET (in this case AODV) messages are vulnerable. All messages (payload and control) MUST be encrypted. Thanks, Phil ----- Original Message ----- From: "Manel Guerrero Zapata" To: "ext Casey Carter" Cc: "ext Claude Castelluccia" ; ; "Seung Yi" Sent: Monday, April 22, 2002 1:01 PM Subject: Re: [manet] Security Considerations of AODV > Hi Casey, > > Comments bellow. > > ext Casey Carter wrote: > > Manel Guerrero Zapata wrote: > > > >> Hi Casey, > >> > > [...] > > >> So for the attack you are suggesting to succeed, they would have to > >> manage that > >> the RREQ forwarded by the second bad guy (with the faked hop count) will > >> be the fastest one to reach one of those nodes who can issue a RREP back > >> (because they are intermediate nodes that have a route to the > >> destination, > >> or because they are the destination). > >> And that is not easy because that means that they actually have to be the > >> fastest path (acording to AODV policy of RREQ forwarding) to at least > >> that > >> intermediate node. Or, just the fastest path if there are no > >> intermediate nodes > > > > > > Unfortunately, you have to assume that the attacker always knows what he > > is doing; we replace the notion "shortest" with "fastest". > > > Yes, but my point here is that it is not so important that there > is some possible attack to the hop count integrity, because that is not a key > element to get a route selected among others. It does not give a real benefit > to the attackers. > > > > Although I > > can't find anything on the subject in the draft, it is well known among > > implementors of ad hoc routing protocols that immediate rebroadcast of > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > broadcasts from multiple nodes cause extremely high contention, and > > (especially in simulations) lots of collisions.The solution for this > > problem is for each node to choose a small random backoff timer to > > better distribute the rebroadcasts. > > > I thing this is something you find only in the simulation world (that if > you broadcast a RREQ all your neighbors will rebroadcast it at the very > same time and all the packets will collide). > But in the real world, if you use some wireless card they already have > (like the ethernet cards) this small random backoff, > to avoid collisions, for every packet they send. > > > > The consequence of this is that a > > route request travels slower through the MANET than regular unicast > > traffic. So if my attackers have a clue, they will maintain an active > > route between them to support the packet tunnel. This tunnel will > > deliver the route request from the source's tail to the destination's > > tail slightly before the route request flood reaches the destination's > > region of the MANET, and the first route request the destination > > receives will be through the "magic" link. > > > Since there is no added delay for rebroadcasting, the attackers > have more or less the same chances to be the fastest as if they wouldn't > be bad boys. So tunneling and breaking the hop count does not give > any advantage to the attackers in order to get the traffic going between > them. > > > > The attackers can coordinate > > to make sure that they are on or near the shortest path between the > > source and destination, so this attack should be quite effective in > > denying communication betweem source and dest. The attack is assisted > > by expanding ring search (Section 6.4 in draft 10), since the attackers > > can probably tail the source and destination fairly closely. In this > > case, the attackers need only be "close" to the fastest path. > > > If people are using expanding ring, then the attackers have a big chance > to be the fastest. But in scenarios more security demanding the originator > of the RREQ could decide not to use the expanding ring search technique. > And that's it. There is no attack then. > > > > If the attackers have more resources at their disposal, they can improve > > upon this margin. The attackers can purchase better radios than what is > > commonly used in the MANET, so that they actually DO have the fastest, > > shortest link across the MANET. AODV/DSR/whatever will then choose the > > path through the attackers as the shortest path. The gist of this > > argument is that simply authenticating the RREQ/RREPs is not sufficent > > to preserve availability of communication between source and > > destination, but only to verify that a route exists. > > > Well, if attackers just by having better radios than the rest able to be in the > faster/shorter path. They don't need to misbehave to be in the path. So then > they are just as good boys which happend to have better radios. > So their route should be selected. > > And if an attacker can put himself _in_ the fastest path, then he is in > the fastest path. Although that is not so easy if nodes are moving. > From experiences with real implementations (not simulations) a communication > between two nodes does not happen through the same path all the time, > it is changing the route quite a lot. > > I have never stated than SAODV is able to "preserve availability of > communication between source and destination". Actually in the abstract of > the draft it says: > > 8<--------------------------------------------------------------------- > The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension > of the AODV routing protocol that can be used to protect the route > discovery mechanism providing security features like integrity, > authentication and non-repudiation. > --------------------------------------------------------------------->8 > > But I don't say anything about Denial of Service. If an attacker wants > to do a DoS it will probably find easier to flood the network with > packets or to send a packet every time it detects one it's being sent > (so they'll collide) or just emit interferences with the max power it can. > Then, not even simetric cryptosystems will save you. > > > Regards, > > Manel Guerrero > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 13:48:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04877 for ; Mon, 22 Apr 2002 13:48:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03349 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 13:48:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01101; Mon, 22 Apr 2002 13:21:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00950 for ; Mon, 22 Apr 2002 13:20:59 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03481 for ; Mon, 22 Apr 2002 13:20:54 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY10A2; Mon, 22 Apr 2002 13:20:45 -0400 Message-ID: <000901c1ea22$09c90080$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Manel Guerrero Zapata" , "ext Casey Carter" Cc: "ext Claude Castelluccia" , , "Seung Yi" References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> Date: Mon, 22 Apr 2002 13:20:45 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Re Security considerations in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Can we agree to simple premises for MANET security? A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is deployed with trusted fixed infrastructure that shares the MANET algorithm. B). This means key management is the only REAL issue. C). There are plenty of research papers on key management issues for ad hoc networks, I suggest the security enthusiests read these. D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network a good solution for key management does not yet exist. Please find one. It is silly to talk about what parts of MANET (in this case AODV) messages are vulnerable. All messages (payload and control) MUST be encrypted. Thanks, Phil ----- Original Message ----- From: "Manel Guerrero Zapata" To: "ext Casey Carter" Cc: "ext Claude Castelluccia" ; ; "Seung Yi" Sent: Monday, April 22, 2002 1:01 PM Subject: Re: [manet] Security Considerations of AODV > Hi Casey, > > Comments bellow. > > ext Casey Carter wrote: > > Manel Guerrero Zapata wrote: > > > >> Hi Casey, > >> > > [...] > > >> So for the attack you are suggesting to succeed, they would have to > >> manage that > >> the RREQ forwarded by the second bad guy (with the faked hop count) will > >> be the fastest one to reach one of those nodes who can issue a RREP back > >> (because they are intermediate nodes that have a route to the > >> destination, > >> or because they are the destination). > >> And that is not easy because that means that they actually have to be the > >> fastest path (acording to AODV policy of RREQ forwarding) to at least > >> that > >> intermediate node. Or, just the fastest path if there are no > >> intermediate nodes > > > > > > Unfortunately, you have to assume that the attacker always knows what he > > is doing; we replace the notion "shortest" with "fastest". > > > Yes, but my point here is that it is not so important that there > is some possible attack to the hop count integrity, because that is not a key > element to get a route selected among others. It does not give a real benefit > to the attackers. > > > > Although I > > can't find anything on the subject in the draft, it is well known among > > implementors of ad hoc routing protocols that immediate rebroadcast of > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > broadcasts from multiple nodes cause extremely high contention, and > > (especially in simulations) lots of collisions.The solution for this > > problem is for each node to choose a small random backoff timer to > > better distribute the rebroadcasts. > > > I thing this is something you find only in the simulation world (that if > you broadcast a RREQ all your neighbors will rebroadcast it at the very > same time and all the packets will collide). > But in the real world, if you use some wireless card they already have > (like the ethernet cards) this small random backoff, > to avoid collisions, for every packet they send. > > > > The consequence of this is that a > > route request travels slower through the MANET than regular unicast > > traffic. So if my attackers have a clue, they will maintain an active > > route between them to support the packet tunnel. This tunnel will > > deliver the route request from the source's tail to the destination's > > tail slightly before the route request flood reaches the destination's > > region of the MANET, and the first route request the destination > > receives will be through the "magic" link. > > > Since there is no added delay for rebroadcasting, the attackers > have more or less the same chances to be the fastest as if they wouldn't > be bad boys. So tunneling and breaking the hop count does not give > any advantage to the attackers in order to get the traffic going between > them. > > > > The attackers can coordinate > > to make sure that they are on or near the shortest path between the > > source and destination, so this attack should be quite effective in > > denying communication betweem source and dest. The attack is assisted > > by expanding ring search (Section 6.4 in draft 10), since the attackers > > can probably tail the source and destination fairly closely. In this > > case, the attackers need only be "close" to the fastest path. > > > If people are using expanding ring, then the attackers have a big chance > to be the fastest. But in scenarios more security demanding the originator > of the RREQ could decide not to use the expanding ring search technique. > And that's it. There is no attack then. > > > > If the attackers have more resources at their disposal, they can improve > > upon this margin. The attackers can purchase better radios than what is > > commonly used in the MANET, so that they actually DO have the fastest, > > shortest link across the MANET. AODV/DSR/whatever will then choose the > > path through the attackers as the shortest path. The gist of this > > argument is that simply authenticating the RREQ/RREPs is not sufficent > > to preserve availability of communication between source and > > destination, but only to verify that a route exists. > > > Well, if attackers just by having better radios than the rest able to be in the > faster/shorter path. They don't need to misbehave to be in the path. So then > they are just as good boys which happend to have better radios. > So their route should be selected. > > And if an attacker can put himself _in_ the fastest path, then he is in > the fastest path. Although that is not so easy if nodes are moving. > From experiences with real implementations (not simulations) a communication > between two nodes does not happen through the same path all the time, > it is changing the route quite a lot. > > I have never stated than SAODV is able to "preserve availability of > communication between source and destination". Actually in the abstract of > the draft it says: > > 8<--------------------------------------------------------------------- > The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension > of the AODV routing protocol that can be used to protect the route > discovery mechanism providing security features like integrity, > authentication and non-repudiation. > --------------------------------------------------------------------->8 > > But I don't say anything about Denial of Service. If an attacker wants > to do a DoS it will probably find easier to flood the network with > packets or to send a packet every time it detects one it's being sent > (so they'll collide) or just emit interferences with the max power it can. > Then, not even simetric cryptosystems will save you. > > > Regards, > > Manel Guerrero > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 14:20:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06681 for ; Mon, 22 Apr 2002 14:20:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04045; Mon, 22 Apr 2002 13:59:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04018 for ; Mon, 22 Apr 2002 13:59:06 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05438 for ; Mon, 22 Apr 2002 13:59:02 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05757; Mon, 22 Apr 2002 10:58:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MHwYQ31770; Mon, 22 Apr 2002 10:58:34 -0700 X-mProtect: <200204221758> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6nxKCK; Mon, 22 Apr 2002 10:58:32 PDT Message-ID: <3CC44F48.81BB9AB9@iprg.nokia.com> Date: Mon, 22 Apr 2002 10:58:32 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Re Security considerations in MANET References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetw Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, I cannot agree to your premises. I am confident that a reasonable approach can exist, that does not rely on a trusted fixed infrastructure. I also do not believe that all data needs to be encrypted. Some data is just not that important. I also do not think that all control messages need to be encrypted. In the case of control messages, however, many of them would be appropriate for verification by way of authentication data. Of course, this is also true for a lot of data. None of this should be interpreted to mean that I am against privacy, for applications and protocols where it is desirable. But that is a far different assertion than (A) below. Regards, Charlie P. Phil Neumiller wrote: > > Can we agree to simple premises for MANET security? > > A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is > deployed with trusted fixed infrastructure that shares the MANET algorithm. > B). This means key management is the only REAL issue. > C). There are plenty of research papers on key management issues for ad hoc > networks, I suggest the security enthusiests read these. > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. > > It is silly to talk about what parts of MANET (in this case AODV) messages are > vulnerable. All messages (payload and control) MUST be encrypted. > > Thanks, > > Phil > ----- Original Message ----- > From: "Manel Guerrero Zapata" > To: "ext Casey Carter" > Cc: "ext Claude Castelluccia" ; ; "Seung Yi" > Sent: Monday, April 22, 2002 1:01 PM > Subject: Re: [manet] Security Considerations of AODV > > > Hi Casey, > > > > Comments bellow. > > > > ext Casey Carter wrote: > > > Manel Guerrero Zapata wrote: > > > > > >> Hi Casey, > > >> > > > > [...] > > > > >> So for the attack you are suggesting to succeed, they would have to > > >> manage that > > >> the RREQ forwarded by the second bad guy (with the faked hop count) will > > >> be the fastest one to reach one of those nodes who can issue a RREP back > > >> (because they are intermediate nodes that have a route to the > > >> destination, > > >> or because they are the destination). > > >> And that is not easy because that means that they actually have to be the > > >> fastest path (acording to AODV policy of RREQ forwarding) to at least > > >> that > > >> intermediate node. Or, just the fastest path if there are no > > >> intermediate nodes > > > > > > > > > Unfortunately, you have to assume that the attacker always knows what he > > > is doing; we replace the notion "shortest" with "fastest". > > > > > > Yes, but my point here is that it is not so important that there > > is some possible attack to the hop count integrity, because that is not a key > > element to get a route selected among others. It does not give a real benefit > > to the attackers. > > > > > > > Although I > > > can't find anything on the subject in the draft, it is well known among > > > implementors of ad hoc routing protocols that immediate rebroadcast of > > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > > broadcasts from multiple nodes cause extremely high contention, and > > > (especially in simulations) lots of collisions.The solution for this > > > problem is for each node to choose a small random backoff timer to > > > better distribute the rebroadcasts. > > > > > > I thing this is something you find only in the simulation world (that if > > you broadcast a RREQ all your neighbors will rebroadcast it at the very > > same time and all the packets will collide). > > But in the real world, if you use some wireless card they already have > > (like the ethernet cards) this small random backoff, > > to avoid collisions, for every packet they send. > > > > > > > The consequence of this is that a > > > route request travels slower through the MANET than regular unicast > > > traffic. So if my attackers have a clue, they will maintain an active > > > route between them to support the packet tunnel. This tunnel will > > > deliver the route request from the source's tail to the destination's > > > tail slightly before the route request flood reaches the destination's > > > region of the MANET, and the first route request the destination > > > receives will be through the "magic" link. > > > > > > Since there is no added delay for rebroadcasting, the attackers > > have more or less the same chances to be the fastest as if they wouldn't > > be bad boys. So tunneling and breaking the hop count does not give > > any advantage to the attackers in order to get the traffic going between > > them. > > > > > > > The attackers can coordinate > > > to make sure that they are on or near the shortest path between the > > > source and destination, so this attack should be quite effective in > > > denying communication betweem source and dest. The attack is assisted > > > by expanding ring search (Section 6.4 in draft 10), since the attackers > > > can probably tail the source and destination fairly closely. In this > > > case, the attackers need only be "close" to the fastest path. > > > > > > If people are using expanding ring, then the attackers have a big chance > > to be the fastest. But in scenarios more security demanding the originator > > of the RREQ could decide not to use the expanding ring search technique. > > And that's it. There is no attack then. > > > > > > > If the attackers have more resources at their disposal, they can improve > > > upon this margin. The attackers can purchase better radios than what is > > > commonly used in the MANET, so that they actually DO have the fastest, > > > shortest link across the MANET. AODV/DSR/whatever will then choose the > > > path through the attackers as the shortest path. The gist of this > > > argument is that simply authenticating the RREQ/RREPs is not sufficent > > > to preserve availability of communication between source and > > > destination, but only to verify that a route exists. > > > > > > Well, if attackers just by having better radios than the rest able to be in the > > faster/shorter path. They don't need to misbehave to be in the path. So then > > they are just as good boys which happend to have better radios. > > So their route should be selected. > > > > And if an attacker can put himself _in_ the fastest path, then he is in > > the fastest path. Although that is not so easy if nodes are moving. > > From experiences with real implementations (not simulations) a communication > > between two nodes does not happen through the same path all the time, > > it is changing the route quite a lot. > > > > I have never stated than SAODV is able to "preserve availability of > > communication between source and destination". Actually in the abstract of > > the draft it says: > > > > 8<--------------------------------------------------------------------- > > The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension > > of the AODV routing protocol that can be used to protect the route > > discovery mechanism providing security features like integrity, > > authentication and non-repudiation. > > --------------------------------------------------------------------->8 > > > > But I don't say anything about Denial of Service. If an attacker wants > > to do a DoS it will probably find easier to flood the network with > > packets or to send a packet every time it detects one it's being sent > > (so they'll collide) or just emit interferences with the max power it can. > > Then, not even simetric cryptosystems will save you. > > > > > > Regards, > > > > Manel Guerrero > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 14:20:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06692 for ; Mon, 22 Apr 2002 14:20:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06561 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 14:20:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04045; Mon, 22 Apr 2002 13:59:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04018 for ; Mon, 22 Apr 2002 13:59:06 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05438 for ; Mon, 22 Apr 2002 13:59:02 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05757; Mon, 22 Apr 2002 10:58:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MHwYQ31770; Mon, 22 Apr 2002 10:58:34 -0700 X-mProtect: <200204221758> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6nxKCK; Mon, 22 Apr 2002 10:58:32 PDT Message-ID: <3CC44F48.81BB9AB9@iprg.nokia.com> Date: Mon, 22 Apr 2002 10:58:32 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Re Security considerations in MANET References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetw Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, I cannot agree to your premises. I am confident that a reasonable approach can exist, that does not rely on a trusted fixed infrastructure. I also do not believe that all data needs to be encrypted. Some data is just not that important. I also do not think that all control messages need to be encrypted. In the case of control messages, however, many of them would be appropriate for verification by way of authentication data. Of course, this is also true for a lot of data. None of this should be interpreted to mean that I am against privacy, for applications and protocols where it is desirable. But that is a far different assertion than (A) below. Regards, Charlie P. Phil Neumiller wrote: > > Can we agree to simple premises for MANET security? > > A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is > deployed with trusted fixed infrastructure that shares the MANET algorithm. > B). This means key management is the only REAL issue. > C). There are plenty of research papers on key management issues for ad hoc > networks, I suggest the security enthusiests read these. > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. > > It is silly to talk about what parts of MANET (in this case AODV) messages are > vulnerable. All messages (payload and control) MUST be encrypted. > > Thanks, > > Phil > ----- Original Message ----- > From: "Manel Guerrero Zapata" > To: "ext Casey Carter" > Cc: "ext Claude Castelluccia" ; ; "Seung Yi" > Sent: Monday, April 22, 2002 1:01 PM > Subject: Re: [manet] Security Considerations of AODV > > > Hi Casey, > > > > Comments bellow. > > > > ext Casey Carter wrote: > > > Manel Guerrero Zapata wrote: > > > > > >> Hi Casey, > > >> > > > > [...] > > > > >> So for the attack you are suggesting to succeed, they would have to > > >> manage that > > >> the RREQ forwarded by the second bad guy (with the faked hop count) will > > >> be the fastest one to reach one of those nodes who can issue a RREP back > > >> (because they are intermediate nodes that have a route to the > > >> destination, > > >> or because they are the destination). > > >> And that is not easy because that means that they actually have to be the > > >> fastest path (acording to AODV policy of RREQ forwarding) to at least > > >> that > > >> intermediate node. Or, just the fastest path if there are no > > >> intermediate nodes > > > > > > > > > Unfortunately, you have to assume that the attacker always knows what he > > > is doing; we replace the notion "shortest" with "fastest". > > > > > > Yes, but my point here is that it is not so important that there > > is some possible attack to the hop count integrity, because that is not a key > > element to get a route selected among others. It does not give a real benefit > > to the attackers. > > > > > > > Although I > > > can't find anything on the subject in the draft, it is well known among > > > implementors of ad hoc routing protocols that immediate rebroadcast of > > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > > broadcasts from multiple nodes cause extremely high contention, and > > > (especially in simulations) lots of collisions.The solution for this > > > problem is for each node to choose a small random backoff timer to > > > better distribute the rebroadcasts. > > > > > > I thing this is something you find only in the simulation world (that if > > you broadcast a RREQ all your neighbors will rebroadcast it at the very > > same time and all the packets will collide). > > But in the real world, if you use some wireless card they already have > > (like the ethernet cards) this small random backoff, > > to avoid collisions, for every packet they send. > > > > > > > The consequence of this is that a > > > route request travels slower through the MANET than regular unicast > > > traffic. So if my attackers have a clue, they will maintain an active > > > route between them to support the packet tunnel. This tunnel will > > > deliver the route request from the source's tail to the destination's > > > tail slightly before the route request flood reaches the destination's > > > region of the MANET, and the first route request the destination > > > receives will be through the "magic" link. > > > > > > Since there is no added delay for rebroadcasting, the attackers > > have more or less the same chances to be the fastest as if they wouldn't > > be bad boys. So tunneling and breaking the hop count does not give > > any advantage to the attackers in order to get the traffic going between > > them. > > > > > > > The attackers can coordinate > > > to make sure that they are on or near the shortest path between the > > > source and destination, so this attack should be quite effective in > > > denying communication betweem source and dest. The attack is assisted > > > by expanding ring search (Section 6.4 in draft 10), since the attackers > > > can probably tail the source and destination fairly closely. In this > > > case, the attackers need only be "close" to the fastest path. > > > > > > If people are using expanding ring, then the attackers have a big chance > > to be the fastest. But in scenarios more security demanding the originator > > of the RREQ could decide not to use the expanding ring search technique. > > And that's it. There is no attack then. > > > > > > > If the attackers have more resources at their disposal, they can improve > > > upon this margin. The attackers can purchase better radios than what is > > > commonly used in the MANET, so that they actually DO have the fastest, > > > shortest link across the MANET. AODV/DSR/whatever will then choose the > > > path through the attackers as the shortest path. The gist of this > > > argument is that simply authenticating the RREQ/RREPs is not sufficent > > > to preserve availability of communication between source and > > > destination, but only to verify that a route exists. > > > > > > Well, if attackers just by having better radios than the rest able to be in the > > faster/shorter path. They don't need to misbehave to be in the path. So then > > they are just as good boys which happend to have better radios. > > So their route should be selected. > > > > And if an attacker can put himself _in_ the fastest path, then he is in > > the fastest path. Although that is not so easy if nodes are moving. > > From experiences with real implementations (not simulations) a communication > > between two nodes does not happen through the same path all the time, > > it is changing the route quite a lot. > > > > I have never stated than SAODV is able to "preserve availability of > > communication between source and destination". Actually in the abstract of > > the draft it says: > > > > 8<--------------------------------------------------------------------- > > The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension > > of the AODV routing protocol that can be used to protect the route > > discovery mechanism providing security features like integrity, > > authentication and non-repudiation. > > --------------------------------------------------------------------->8 > > > > But I don't say anything about Denial of Service. If an attacker wants > > to do a DoS it will probably find easier to flood the network with > > packets or to send a packet every time it detects one it's being sent > > (so they'll collide) or just emit interferences with the max power it can. > > Then, not even simetric cryptosystems will save you. > > > > > > Regards, > > > > Manel Guerrero > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 14:35:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07526 for ; Mon, 22 Apr 2002 14:35:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05757; Mon, 22 Apr 2002 14:15:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05725 for ; Mon, 22 Apr 2002 14:15:31 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06438 for ; Mon, 22 Apr 2002 14:15:28 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY10DV; Mon, 22 Apr 2002 14:15:28 -0400 Message-ID: <001b01c1ea29$aedde160$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetw <3CC44F48.81BB9AB9@iprg.nokia.com> Subject: Re: [manet] Re Security considerations in MANET Date: Mon, 22 Apr 2002 14:15:28 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Charlie, ----- Original Message ----- From: "Charles E. Perkins" > Hello Phil, > > I cannot agree to your premises. > That's OK, I just want to reduce the polution on the list. I must advocate STRONGLY that even if you don't have a PKI or fixed infrastructure to rely on, all messages MUST be encrypted. I see no other way to guarantee against dozens of potential attacks that could occupy this list from now until eternity. Also, messages must be authenticated, and this implies that a portable authenticator must be running on hosts that are pure ad hoc, and for foreign nodes, they must be treated as suspect (untrusted) until a manual intervention by the MANET group is provided (or contact with a trusted certificate authenticator is made). I have thought about this for a bit and and it makes absolutely no sense to put control or any other message in the clear on a MANET (specifically a wireless one). This just invites too many known attacks. > I am confident that a reasonable approach can exist, > that does not rely on a trusted fixed infrastructure. Statements like this can hinder the commercial deployment of MANETs. We can deploy MANETs with trusted infrastrucute peppered in and have pretty darn secure networks. I advocate we specify how to do THIS first, before we go off waiting for a "known research topic" to materialize into something useful. In fact your recent draft for global IPv6 hints at this. > > I also do not believe that all data needs to be > encrypted. Some data is just not that important. So you can turn off encryption when your are playing games. Otherwise, most things MUST be encrypted. People expected wired equivalent privacy from 802.11b for a very good reason (they didn't get it but they expected it). > I also do not think that all control messages need > to be encrypted. IITM, replay, message insertion, stack smashing, should I go? In a commercial implementation of a MANET, where people are paying for a level of service, ALL packets MUST be encrypted and authenticated. > In the case of control messages, > however, many of them would be appropriate for > verification by way of authentication data. Of > course, this is also true for a lot of data. Yes, I agree, however, the encryption is not as heavy weight in general as the authentication right? > > None of this should be interpreted to mean that I am > against privacy, for applications and protocols where > it is desirable. But that is a far different assertion > than (A) below. So I will qualify A below to mean "in commercially deployed MANETs" > Phil Neumiller wrote: > > > > Can we agree to simple premises for MANET security? > > > > A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is > > deployed with trusted fixed infrastructure that shares the MANET algorithm. > > B). This means key management is the only REAL issue. > > C). There are plenty of research papers on key management issues for ad hoc > > networks, I suggest the security enthusiests read these. > > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > > a good solution for key management does not yet exist. Please find one. > > > > It is silly to talk about what parts of MANET (in this case AODV) messages are > > vulnerable. All messages (payload and control) MUST be encrypted. > > > > Thanks, > > > > Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 14:35:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07536 for ; Mon, 22 Apr 2002 14:35:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA08152 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 14:35:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05757; Mon, 22 Apr 2002 14:15:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05725 for ; Mon, 22 Apr 2002 14:15:31 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06438 for ; Mon, 22 Apr 2002 14:15:28 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY10DV; Mon, 22 Apr 2002 14:15:28 -0400 Message-ID: <001b01c1ea29$aedde160$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetw <3CC44F48.81BB9AB9@iprg.nokia.com> Subject: Re: [manet] Re Security considerations in MANET Date: Mon, 22 Apr 2002 14:15:28 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Charlie, ----- Original Message ----- From: "Charles E. Perkins" > Hello Phil, > > I cannot agree to your premises. > That's OK, I just want to reduce the polution on the list. I must advocate STRONGLY that even if you don't have a PKI or fixed infrastructure to rely on, all messages MUST be encrypted. I see no other way to guarantee against dozens of potential attacks that could occupy this list from now until eternity. Also, messages must be authenticated, and this implies that a portable authenticator must be running on hosts that are pure ad hoc, and for foreign nodes, they must be treated as suspect (untrusted) until a manual intervention by the MANET group is provided (or contact with a trusted certificate authenticator is made). I have thought about this for a bit and and it makes absolutely no sense to put control or any other message in the clear on a MANET (specifically a wireless one). This just invites too many known attacks. > I am confident that a reasonable approach can exist, > that does not rely on a trusted fixed infrastructure. Statements like this can hinder the commercial deployment of MANETs. We can deploy MANETs with trusted infrastrucute peppered in and have pretty darn secure networks. I advocate we specify how to do THIS first, before we go off waiting for a "known research topic" to materialize into something useful. In fact your recent draft for global IPv6 hints at this. > > I also do not believe that all data needs to be > encrypted. Some data is just not that important. So you can turn off encryption when your are playing games. Otherwise, most things MUST be encrypted. People expected wired equivalent privacy from 802.11b for a very good reason (they didn't get it but they expected it). > I also do not think that all control messages need > to be encrypted. IITM, replay, message insertion, stack smashing, should I go? In a commercial implementation of a MANET, where people are paying for a level of service, ALL packets MUST be encrypted and authenticated. > In the case of control messages, > however, many of them would be appropriate for > verification by way of authentication data. Of > course, this is also true for a lot of data. Yes, I agree, however, the encryption is not as heavy weight in general as the authentication right? > > None of this should be interpreted to mean that I am > against privacy, for applications and protocols where > it is desirable. But that is a far different assertion > than (A) below. So I will qualify A below to mean "in commercially deployed MANETs" > Phil Neumiller wrote: > > > > Can we agree to simple premises for MANET security? > > > > A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is > > deployed with trusted fixed infrastructure that shares the MANET algorithm. > > B). This means key management is the only REAL issue. > > C). There are plenty of research papers on key management issues for ad hoc > > networks, I suggest the security enthusiests read these. > > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > > a good solution for key management does not yet exist. Please find one. > > > > It is silly to talk about what parts of MANET (in this case AODV) messages are > > vulnerable. All messages (payload and control) MUST be encrypted. > > > > Thanks, > > > > Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 14:35:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07568 for ; Mon, 22 Apr 2002 14:35:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05967; Mon, 22 Apr 2002 14:15:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05781 for ; Mon, 22 Apr 2002 14:15:44 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06451 for ; Mon, 22 Apr 2002 14:15:39 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MIFwF23745 for ; Mon, 22 Apr 2002 21:15:58 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 21:15:40 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 21:15:40 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id VAA23775; Mon, 22 Apr 2002 21:15:39 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC452EF.1060403@nokia.com> Date: Mon, 22 Apr 2002 21:14:07 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: ext Casey Carter , ext Claude Castelluccia , manet@ietf.org, Seung Yi References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2002 18:15:40.0348 (UTC) FILETIME=[B58BC7C0:01C1EA29] Content-Transfer-Encoding: 7bit Subject: [manet] Re: Re Security considerations in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Phil, I'm gonna try to explain why I don't thing that encrypting everything is the right thing to do in manet in all kind of scenarios. If in a MANET network all routing messages are encrypted with a symmetric cryptosystem, it means that everybody that we want to be able to participate in the network has to know the key. That is not a big problem if we are a 'team' of persons that meet to let every member of the team to know the 'team-key' and then we go to play on the ground creating a MANET network. A member of the team trust the other members of the team, so they assume that a member of the team won't do anything nasty to the manet communications. They trust and authorize the other members to change their routing tables. Maybe this is the best thing to do for military scenarios (besides the problem of the compromissed nodes and some others). But now, let's thing that we want to create a MANET network where everybody can participate. Maybe in a convention, in a meeting room, in a campus, or in our neighborhood. Then we have a problem, we don't trust the others. We are not a team. So what do we do now? How do we force everybody to be honest? Maybe what we can do is to only believe a routing information if the originator of such information is the destination of the route (in such a way that if you lie (since you can only lie about yourself) the only _benefit_ you get is that people is not able to communicate with you. From this starting point, for me, the direction is to use an asymetric cryptosystem (with public an private key pairs) so that the originator of the route messages signs the message. We don't need to encrypt it because it is not a secret. What we want is that people will be able to detect forged routing messages. When you do that, the main problem you have is that this RREQ or RREP that you originate and that travels hop to hop has mutable fields. Mutable fields are the fields or routing messages which value changes during its transmision. And in manet, the typical one is the hop count. So we cannot sign the hop count because when we originate the message, it is zero, but after one hop it will be one and the signature will be broken. Luckily, hop count changes, but it does in a monotonical way, so still we can find some ways to secure it (till certain extend) hash chains in the case of SAODV. Besides all this, encryption is not costless, so one should only encrypt what he or she only wants to be readed by the ones who have the key. So I thing the: "All messages (payload and control) MUST be encrypted" is quite a strong afirmation, and not correct for most of the possible manet scenarios. Best regards, Manel Guerrero ext Phil Neumiller wrote: > Can we agree to simple premises for MANET security? > > A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is > deployed with trusted fixed infrastructure that shares the MANET algorithm. > B). This means key management is the only REAL issue. > C). There are plenty of research papers on key management issues for ad hoc > networks, I suggest the security enthusiests read these. > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. > > It is silly to talk about what parts of MANET (in this case AODV) messages are > vulnerable. All messages (payload and control) MUST be encrypted. > > Thanks, > > Phil [...] _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 14:36:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07579 for ; Mon, 22 Apr 2002 14:35:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA08167 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 14:36:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05967; Mon, 22 Apr 2002 14:15:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05781 for ; Mon, 22 Apr 2002 14:15:44 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06451 for ; Mon, 22 Apr 2002 14:15:39 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3MIFwF23745 for ; Mon, 22 Apr 2002 21:15:58 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Apr 2002 21:15:40 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 22 Apr 2002 21:15:40 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id VAA23775; Mon, 22 Apr 2002 21:15:39 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC452EF.1060403@nokia.com> Date: Mon, 22 Apr 2002 21:14:07 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: ext Casey Carter , ext Claude Castelluccia , manet@ietf.org, Seung Yi References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2002 18:15:40.0348 (UTC) FILETIME=[B58BC7C0:01C1EA29] Content-Transfer-Encoding: 7bit Subject: [manet] Re: Re Security considerations in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Phil, I'm gonna try to explain why I don't thing that encrypting everything is the right thing to do in manet in all kind of scenarios. If in a MANET network all routing messages are encrypted with a symmetric cryptosystem, it means that everybody that we want to be able to participate in the network has to know the key. That is not a big problem if we are a 'team' of persons that meet to let every member of the team to know the 'team-key' and then we go to play on the ground creating a MANET network. A member of the team trust the other members of the team, so they assume that a member of the team won't do anything nasty to the manet communications. They trust and authorize the other members to change their routing tables. Maybe this is the best thing to do for military scenarios (besides the problem of the compromissed nodes and some others). But now, let's thing that we want to create a MANET network where everybody can participate. Maybe in a convention, in a meeting room, in a campus, or in our neighborhood. Then we have a problem, we don't trust the others. We are not a team. So what do we do now? How do we force everybody to be honest? Maybe what we can do is to only believe a routing information if the originator of such information is the destination of the route (in such a way that if you lie (since you can only lie about yourself) the only _benefit_ you get is that people is not able to communicate with you. From this starting point, for me, the direction is to use an asymetric cryptosystem (with public an private key pairs) so that the originator of the route messages signs the message. We don't need to encrypt it because it is not a secret. What we want is that people will be able to detect forged routing messages. When you do that, the main problem you have is that this RREQ or RREP that you originate and that travels hop to hop has mutable fields. Mutable fields are the fields or routing messages which value changes during its transmision. And in manet, the typical one is the hop count. So we cannot sign the hop count because when we originate the message, it is zero, but after one hop it will be one and the signature will be broken. Luckily, hop count changes, but it does in a monotonical way, so still we can find some ways to secure it (till certain extend) hash chains in the case of SAODV. Besides all this, encryption is not costless, so one should only encrypt what he or she only wants to be readed by the ones who have the key. So I thing the: "All messages (payload and control) MUST be encrypted" is quite a strong afirmation, and not correct for most of the possible manet scenarios. Best regards, Manel Guerrero ext Phil Neumiller wrote: > Can we agree to simple premises for MANET security? > > A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is > deployed with trusted fixed infrastructure that shares the MANET algorithm. > B). This means key management is the only REAL issue. > C). There are plenty of research papers on key management issues for ad hoc > networks, I suggest the security enthusiests read these. > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. > > It is silly to talk about what parts of MANET (in this case AODV) messages are > vulnerable. All messages (payload and control) MUST be encrypted. > > Thanks, > > Phil [...] _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 14:55:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08408 for ; Mon, 22 Apr 2002 14:55:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08078; Mon, 22 Apr 2002 14:34:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08050 for ; Mon, 22 Apr 2002 14:34:19 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07477 for ; Mon, 22 Apr 2002 14:34:15 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY1017; Mon, 22 Apr 2002 14:34:15 -0400 Message-ID: <003301c1ea2c$4e404520$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Manel Guerrero Zapata" Cc: "ext Casey Carter" , "ext Claude Castelluccia" , , "Seung Yi" References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetworks.com> <3CC452EF.1060403@nokia.com> Date: Mon, 22 Apr 2002 14:34:15 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Re: Re Security considerations in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Manel, Thanks for the rebuttal. I respond below. ----- Original Message ----- From: "Manel Guerrero Zapata" > Hi Phil, > > I'm gonna try to explain why I don't thing that encrypting everything is the > right thing to do in manet in all kind of scenarios. Would you agree its the thing to do in commercial money making scenarios where people are paying for service on a MANET? Would you agree its the thing to do when hots spots allow MANETs in public venues like airports, hotels, busses, and restaurants? > > If in a MANET network all routing messages are encrypted with a symmetric cryptosystem, > it means that everybody that we want to be able to participate in the network has to > know the key. Not necessarily. It could mean that each node has a "born on certificate" that is stamped into tamper resistant storage by the OEM. It could mean that the unit has to periodically reathenticate to use services besides E911. It could also be possible to re-imprint the certificate when the unit is stolen lost or has been black listed for some reason. > That is not a big problem if we are a 'team' of persons that meet > to let every member of the team to know the 'team-key' and then we go to > play on the ground creating a MANET network. A member of the team trust the other > members of the team, so they assume that a member of the team won't do anything > nasty to the manet communications. They trust and authorize the other members to change > their routing tables. This doesn't scale to well. It would be far better to have an OEM key that is unique and have routing use that, i.e. all units that agree to some standard, can talk (they can't talk anyway if they are not standardized right?). > > Maybe this is the best thing to do for military scenarios (besides the problem > of the compromissed nodes and some others). Its the best thing for everything, except gaming, and casual use of devices. If MANETs are to succeed, they must succeed in the business world, and this means really REALLY good security. > > But now, let's thing that we want to create a MANET network where everybody can participate. > Maybe in a convention, in a meeting room, in a campus, or in our neighborhood. > Then we have a problem, we don't trust the others. We are not a team. > So what do we do now? If there is a host causing trouble, it had to have a certificate providing non-reduiation so the source can identified and black listed by all other nodes, possibly via flooding a black list request and acheiving group consensus. > How do we force everybody to be honest? Not possible, best bet is to required authentication and non-repudiation. > Maybe what we can do is to only believe a routing information if the > originator of such information is the destination of the route > (in such a way that if you lie (since you can only lie about yourself) the only > _benefit_ you get is that people is not able to communicate with you. Better, yet, use the OEM key to encrypt all control messages including the routing messages. > > From this starting point, for me, the direction is to use an asymetric > cryptosystem (with public an private key pairs) so that the originator > of the route messages signs the message. We don't need to encrypt it because > it is not a secret. What we want is that people will be able to detect forged > routing messages. Routing messages do reveal things. They reveal who is communicatig to who. That is simply too much. They also reveal sequence numbers. The overhead for digital signatures is far higher than for block or stream ciphers in embedded devices right? > > When you do that, the main problem you have is that this RREQ or RREP that > you originate and that travels hop to hop has mutable fields. Mutable fields > are the fields or routing messages which value changes during its transmision. > And in manet, the typical one is the hop count. So we cannot sign the hop count > because when we originate the message, it is zero, but after one hop it will > be one and the signature will be broken. Encrypt the message and CRC it if you wish, then this is not a problem. > > Luckily, hop count changes, but it does in a monotonical way, so still > we can find some ways to secure it (till certain extend) hash chains > in the case of SAODV. Encrypt the messages! > > > Besides all this, encryption is not costless, so one should only encrypt > what he or she only wants to be readed by the ones who have the key. Is what is being proposed going to cost less or more than encryption? I would like to see the analysis on this. > So I thing the: "All messages (payload and control) MUST be encrypted" > is quite a strong afirmation, and not correct for most of the possible > manet scenarios. It is probably the only correct solution for "profitable" MANET scenarios, which are the type I am interested in, since I work for one of the few companies on the planet attempting to commercialize MANET technologies! Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 14:55:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08418 for ; Mon, 22 Apr 2002 14:55:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10060 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 14:55:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08078; Mon, 22 Apr 2002 14:34:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08050 for ; Mon, 22 Apr 2002 14:34:19 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07477 for ; Mon, 22 Apr 2002 14:34:15 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY1017; Mon, 22 Apr 2002 14:34:15 -0400 Message-ID: <003301c1ea2c$4e404520$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Manel Guerrero Zapata" Cc: "ext Casey Carter" , "ext Claude Castelluccia" , , "Seung Yi" References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetworks.com> <3CC452EF.1060403@nokia.com> Date: Mon, 22 Apr 2002 14:34:15 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Re: Re Security considerations in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Manel, Thanks for the rebuttal. I respond below. ----- Original Message ----- From: "Manel Guerrero Zapata" > Hi Phil, > > I'm gonna try to explain why I don't thing that encrypting everything is the > right thing to do in manet in all kind of scenarios. Would you agree its the thing to do in commercial money making scenarios where people are paying for service on a MANET? Would you agree its the thing to do when hots spots allow MANETs in public venues like airports, hotels, busses, and restaurants? > > If in a MANET network all routing messages are encrypted with a symmetric cryptosystem, > it means that everybody that we want to be able to participate in the network has to > know the key. Not necessarily. It could mean that each node has a "born on certificate" that is stamped into tamper resistant storage by the OEM. It could mean that the unit has to periodically reathenticate to use services besides E911. It could also be possible to re-imprint the certificate when the unit is stolen lost or has been black listed for some reason. > That is not a big problem if we are a 'team' of persons that meet > to let every member of the team to know the 'team-key' and then we go to > play on the ground creating a MANET network. A member of the team trust the other > members of the team, so they assume that a member of the team won't do anything > nasty to the manet communications. They trust and authorize the other members to change > their routing tables. This doesn't scale to well. It would be far better to have an OEM key that is unique and have routing use that, i.e. all units that agree to some standard, can talk (they can't talk anyway if they are not standardized right?). > > Maybe this is the best thing to do for military scenarios (besides the problem > of the compromissed nodes and some others). Its the best thing for everything, except gaming, and casual use of devices. If MANETs are to succeed, they must succeed in the business world, and this means really REALLY good security. > > But now, let's thing that we want to create a MANET network where everybody can participate. > Maybe in a convention, in a meeting room, in a campus, or in our neighborhood. > Then we have a problem, we don't trust the others. We are not a team. > So what do we do now? If there is a host causing trouble, it had to have a certificate providing non-reduiation so the source can identified and black listed by all other nodes, possibly via flooding a black list request and acheiving group consensus. > How do we force everybody to be honest? Not possible, best bet is to required authentication and non-repudiation. > Maybe what we can do is to only believe a routing information if the > originator of such information is the destination of the route > (in such a way that if you lie (since you can only lie about yourself) the only > _benefit_ you get is that people is not able to communicate with you. Better, yet, use the OEM key to encrypt all control messages including the routing messages. > > From this starting point, for me, the direction is to use an asymetric > cryptosystem (with public an private key pairs) so that the originator > of the route messages signs the message. We don't need to encrypt it because > it is not a secret. What we want is that people will be able to detect forged > routing messages. Routing messages do reveal things. They reveal who is communicatig to who. That is simply too much. They also reveal sequence numbers. The overhead for digital signatures is far higher than for block or stream ciphers in embedded devices right? > > When you do that, the main problem you have is that this RREQ or RREP that > you originate and that travels hop to hop has mutable fields. Mutable fields > are the fields or routing messages which value changes during its transmision. > And in manet, the typical one is the hop count. So we cannot sign the hop count > because when we originate the message, it is zero, but after one hop it will > be one and the signature will be broken. Encrypt the message and CRC it if you wish, then this is not a problem. > > Luckily, hop count changes, but it does in a monotonical way, so still > we can find some ways to secure it (till certain extend) hash chains > in the case of SAODV. Encrypt the messages! > > > Besides all this, encryption is not costless, so one should only encrypt > what he or she only wants to be readed by the ones who have the key. Is what is being proposed going to cost less or more than encryption? I would like to see the analysis on this. > So I thing the: "All messages (payload and control) MUST be encrypted" > is quite a strong afirmation, and not correct for most of the possible > manet scenarios. It is probably the only correct solution for "profitable" MANET scenarios, which are the type I am interested in, since I work for one of the few companies on the planet attempting to commercialize MANET technologies! Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 15:06:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08812 for ; Mon, 22 Apr 2002 15:06:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09026; Mon, 22 Apr 2002 14:46:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08993 for ; Mon, 22 Apr 2002 14:46:03 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07985 for ; Mon, 22 Apr 2002 14:45:55 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA09904; Mon, 22 Apr 2002 11:45:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MIjQR07718; Mon, 22 Apr 2002 11:45:26 -0700 X-mProtect: <200204221845> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6pkYJi; Mon, 22 Apr 2002 11:45:24 PDT Message-ID: <3CC45A45.6603090C@iprg.nokia.com> Date: Mon, 22 Apr 2002 11:45:25 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Re Security considerations in MANET References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetw Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > .................. I must advocate > STRONGLY that even if you don't have a PKI or fixed infrastructure to > rely on, all messages MUST be encrypted. I see no other way to guarantee > against dozens of potential attacks that could occupy this list from now until > eternity. ........... If I'm getting something for free, and it would cost $0.10/minute to encrypt it, and the data isn't worth that much (e.g. webcam cows), I don't want to be required to buy the encryption. >> I am confident that a reasonable approach can exist, >> that does not rely on a trusted fixed infrastructure. > > Statements like this can hinder the commercial deployment of MANETs. We can > deploy MANETs with trusted infrastrucute peppered in and have pretty > darn secure networks. I advocate we specify how to do THIS first, before > we go off waiting for a "known research topic" to materialize into something > useful. In fact your recent draft for global IPv6 hints at this. If you offer a solution today that relies on fixed infrastructure, and people are willing to pay, then that's fine. My statement is in no way adversary to your solution. However, I hope I'm allowed to believe that other better solutions can exist, even if I don't have one ready to sell. I'm realy at a loss to understand what I said that you find objectionable. >> I also do not believe that all data needs to be >> encrypted. Some data is just not that important. > > So you can turn off encryption when your are playing games. Otherwise, > most things MUST be encrypted. People expected wired equivalent > privacy from 802.11b for a very good reason (they didn't get it but they > expected it). I'd say instead that most things do NOT need to be encrypted. In fact, I'd say that the way encryption is used in the Internet today represents a good model for the way things ought to eventually be for ad hoc networks. Further, I'd say that as things evolve in the Internet, we can notice the reasons why. Those reasons will also probably apply to ad hoc networks, at least for some applications. >> I also do not think that all control messages need >> to be encrypted. > > IITM, replay, message insertion, stack smashing, should I go? In a > commercial implementation of a MANET, where people are paying for > a level of service, ALL packets MUST be encrypted and authenticated. I didn't parse IITM. And, commercial implementation doesn't equal encryption, nor paid service. In fact, I'd hope we could have ad hoc radio programming on campus, with zero encryption and cost. There are so many possibilities! >> In the case of control messages, >> however, many of them would be appropriate for >> verification by way of authentication data. Of >> course, this is also true for a lot of data. > > Yes, I agree, however, the encryption is not as heavy weight in general > as the authentication right? I guess it depends on hardware and algorithm. > > None of this should be interpreted to mean that I am > > against privacy, for applications and protocols where > > it is desirable. But that is a far different assertion > > than (A) below. > > So I will qualify A below to mean "in commercially deployed MANETs" From the above, I guess you can tell I still believe this is too restrictive. I might want to make a commercially viable MANET that does not enforce encryption for all services. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 15:06:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08822 for ; Mon, 22 Apr 2002 15:06:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11184 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 15:06:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09026; Mon, 22 Apr 2002 14:46:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08993 for ; Mon, 22 Apr 2002 14:46:03 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07985 for ; Mon, 22 Apr 2002 14:45:55 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA09904; Mon, 22 Apr 2002 11:45:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3MIjQR07718; Mon, 22 Apr 2002 11:45:26 -0700 X-mProtect: <200204221845> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6pkYJi; Mon, 22 Apr 2002 11:45:24 PDT Message-ID: <3CC45A45.6603090C@iprg.nokia.com> Date: Mon, 22 Apr 2002 11:45:25 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: manet@ietf.org Subject: Re: [manet] Re Security considerations in MANET References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <000901c1ea22$09c90080$6200000a@meshnetw Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > .................. I must advocate > STRONGLY that even if you don't have a PKI or fixed infrastructure to > rely on, all messages MUST be encrypted. I see no other way to guarantee > against dozens of potential attacks that could occupy this list from now until > eternity. ........... If I'm getting something for free, and it would cost $0.10/minute to encrypt it, and the data isn't worth that much (e.g. webcam cows), I don't want to be required to buy the encryption. >> I am confident that a reasonable approach can exist, >> that does not rely on a trusted fixed infrastructure. > > Statements like this can hinder the commercial deployment of MANETs. We can > deploy MANETs with trusted infrastrucute peppered in and have pretty > darn secure networks. I advocate we specify how to do THIS first, before > we go off waiting for a "known research topic" to materialize into something > useful. In fact your recent draft for global IPv6 hints at this. If you offer a solution today that relies on fixed infrastructure, and people are willing to pay, then that's fine. My statement is in no way adversary to your solution. However, I hope I'm allowed to believe that other better solutions can exist, even if I don't have one ready to sell. I'm realy at a loss to understand what I said that you find objectionable. >> I also do not believe that all data needs to be >> encrypted. Some data is just not that important. > > So you can turn off encryption when your are playing games. Otherwise, > most things MUST be encrypted. People expected wired equivalent > privacy from 802.11b for a very good reason (they didn't get it but they > expected it). I'd say instead that most things do NOT need to be encrypted. In fact, I'd say that the way encryption is used in the Internet today represents a good model for the way things ought to eventually be for ad hoc networks. Further, I'd say that as things evolve in the Internet, we can notice the reasons why. Those reasons will also probably apply to ad hoc networks, at least for some applications. >> I also do not think that all control messages need >> to be encrypted. > > IITM, replay, message insertion, stack smashing, should I go? In a > commercial implementation of a MANET, where people are paying for > a level of service, ALL packets MUST be encrypted and authenticated. I didn't parse IITM. And, commercial implementation doesn't equal encryption, nor paid service. In fact, I'd hope we could have ad hoc radio programming on campus, with zero encryption and cost. There are so many possibilities! >> In the case of control messages, >> however, many of them would be appropriate for >> verification by way of authentication data. Of >> course, this is also true for a lot of data. > > Yes, I agree, however, the encryption is not as heavy weight in general > as the authentication right? I guess it depends on hardware and algorithm. > > None of this should be interpreted to mean that I am > > against privacy, for applications and protocols where > > it is desirable. But that is a far different assertion > > than (A) below. > > So I will qualify A below to mean "in commercially deployed MANETs" From the above, I guess you can tell I still believe this is too restrictive. I might want to make a commercially viable MANET that does not enforce encryption for all services. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 15:08:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08906 for ; Mon, 22 Apr 2002 15:08:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09390; Mon, 22 Apr 2002 14:49:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09364 for ; Mon, 22 Apr 2002 14:49:00 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08177 for ; Mon, 22 Apr 2002 14:48:56 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3MIlrX07184; Mon, 22 Apr 2002 21:47:53 +0300 Date: Mon, 22 Apr 2002 21:47:53 +0300 (EEST) From: Pekka Savola To: Phil Neumiller cc: Manel Guerrero Zapata , ext Casey Carter , ext Claude Castelluccia , , Seung Yi Subject: Re: [manet] Re Security considerations in MANET In-Reply-To: <000901c1ea22$09c90080$6200000a@meshnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Mon, 22 Apr 2002, Phil Neumiller wrote: > Can we agree to simple premises for MANET security? > > A). Its best to run all messages encrypted, [...] In some cases, it may be. In some others, maybe not. Nevertheless, it is a very valuable capability of being able to do that if necessary. > B). This means key management is the only REAL issue. I don't see how B follows from A. With most MANET protocols, encrypting data -- end to end -- is not problematic with proper key management. Being able to encrypt control data is usually a more difficult problem, even with key management. That is not all to the security: in some cases even byzantine robustness (e.g. a military application) might be desirable. Encryption and such do not solve the problems with trust, e.g. prevent someone from blackholing all traffic. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 15:08:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08922 for ; Mon, 22 Apr 2002 15:08:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA11316 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 15:08:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09390; Mon, 22 Apr 2002 14:49:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09364 for ; Mon, 22 Apr 2002 14:49:00 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08177 for ; Mon, 22 Apr 2002 14:48:56 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g3MIlrX07184; Mon, 22 Apr 2002 21:47:53 +0300 Date: Mon, 22 Apr 2002 21:47:53 +0300 (EEST) From: Pekka Savola To: Phil Neumiller cc: Manel Guerrero Zapata , ext Casey Carter , ext Claude Castelluccia , , Seung Yi Subject: Re: [manet] Re Security considerations in MANET In-Reply-To: <000901c1ea22$09c90080$6200000a@meshnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org On Mon, 22 Apr 2002, Phil Neumiller wrote: > Can we agree to simple premises for MANET security? > > A). Its best to run all messages encrypted, [...] In some cases, it may be. In some others, maybe not. Nevertheless, it is a very valuable capability of being able to do that if necessary. > B). This means key management is the only REAL issue. I don't see how B follows from A. With most MANET protocols, encrypting data -- end to end -- is not problematic with proper key management. Being able to encrypt control data is usually a more difficult problem, even with key management. That is not all to the security: in some cases even byzantine robustness (e.g. a military application) might be desirable. Encryption and such do not solve the problems with trust, e.g. prevent someone from blackholing all traffic. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 16:04:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11013 for ; Mon, 22 Apr 2002 16:04:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13492; Mon, 22 Apr 2002 15:35:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13464 for ; Mon, 22 Apr 2002 15:35:04 -0400 (EDT) Received: from peregrine.nps.navy.mil (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09935 for ; Mon, 22 Apr 2002 15:34:57 -0400 (EDT) Received: from capella.nps.navy.mil by peregrine.nps.navy.mil via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 22 Apr 2002 19:37:54 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g3MJVI4Y018175; Mon, 22 Apr 2002 12:31:19 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@grasp.ad.nps.navy.mil Message-Id: In-Reply-To: <003301c1ea2c$4e404520$6200000a@meshnetworks.com> References: <003301c1ea2c$4e404520$6200000a@meshnetworks.com> Date: Mon, 22 Apr 2002 12:37:30 -0700 To: "Phil Neumiller" , manet@ietf.org From: Rex Buddenberg Subject: [manet] Re: Re Security considerations in MANET Content-Type: multipart/alternative; boundary="============_-1192618238==_ma============" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --============_-1192618238==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Time for some term clarity. You get two major items out of security at this level: - confidentiality - authenticity (which is a superset of integrity). Now, divide the traffic on a MANET into two parts: one is the application data. Set it aside; not part of this discussion. The other is all the routing information. The routing information needs authenticity as a matter of course. > I also do not think that all control messages need > to be encrypted. So this statement is partially correct. If it said 'digitally signed' instead of 'encrypted' I'd fully agree. I can easily envision situations where I'd want the routing information to be fairly openly available and others where I'd want it encrypted. But I cannot envision situations (of any scale) where I'd want it unauthenticable. Situation A. We have a multinational laydown for peacekeeping operations -- a lot of infrastructure is contributed by numerous coalition partners. We want to be able to advertise the MANET structure to them all (and are willing to risk the Bad Guys cribbing the data). But, while we're willing to let the Bad Guys know what our topology is, we're not willing to let them disrupt it by spoofing. Therefore, all the data is authenticated via digital signature (for which we have a PKI to support). Authentication failures result in doubt about authenticity but not loss of the data, so the consumer of the routing data is in the caveat emptor position -- it might be a lesser contributor to the coalition who hasn't got act completely together. Situation B might be another multinational laydown, but this time for combat operations. In this case, topology is a protected asset (it would have useful order-of-battle information, somewhat similar to what you could get from traffic analysis) and it's shared with a smaller number of coalition partners. In this case I'd want the encryption for confidentiality in addition to the digital signature. (Note that the PKI overhead is a sunk cost -- I had to buy that for the authenticity part of the problem). In situation A, inability to authenticate doesn't render the data unusable, just of doubtful origin. In this situation, inability to decrypt would result in inability to use the MANET. -- b --============_-1192618238==_ma============ Content-Type: text/html; charset="us-ascii" [manet] Re: Re Security considerations in MANET
Time for some term clarity.

You get two major items out of security at this level:
- confidentiality
- authenticity (which is a superset of integrity).

Now, divide the traffic on a MANET into two parts: one is the application data.  Set it aside; not part of this discussion.  The other is all the routing information.

The routing information needs authenticity as a matter of course.
> I also do not think that all control messages need
> to be encrypted.
So this statement is partially correct.  If it said 'digitally signed' instead of 'encrypted' I'd fully agree.
     I can easily envision situations where I'd want the routing information to be fairly openly available and others where I'd want it encrypted.  But I cannot envision situations (of any scale) where I'd want it unauthenticable.

Situation A.  We have a multinational laydown for peacekeeping operations -- a lot of infrastructure is contributed by numerous coalition partners.  We want to be able to advertise the MANET structure to them all (and are willing to risk the Bad Guys cribbing the data).  But, while we're willing to let the Bad Guys know what our topology is, we're not willing to let them disrupt it by spoofing.  Therefore, all the data is authenticated via digital signature (for which we have a PKI to support).  Authentication failures result in doubt about authenticity but not loss of the data, so the consumer of the routing data is in the caveat emptor position -- it might be a lesser contributor to the coalition who hasn't got act completely together.

Situation B might be another multinational laydown, but this time for combat operations.  In this case, topology is a protected asset (it would have useful order-of-battle information, somewhat similar to what you could get from traffic analysis) and it's shared with a smaller number of coalition partners.  In this case I'd want the encryption for confidentiality in addition to the digital signature.  (Note that the PKI overhead is a sunk cost -- I had to buy that for the authenticity part of the problem).  In situation A, inability to authenticate doesn't render the data unusable, just of doubtful origin.  In this situation, inability to decrypt would result in inability to use the MANET.  

--
b
--============_-1192618238==_ma============-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 16:04:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11028 for ; Mon, 22 Apr 2002 16:04:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16003 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 16:04:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13492; Mon, 22 Apr 2002 15:35:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13464 for ; Mon, 22 Apr 2002 15:35:04 -0400 (EDT) Received: from peregrine.nps.navy.mil (capella.nps.navy.mil [131.120.254.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09935 for ; Mon, 22 Apr 2002 15:34:57 -0400 (EDT) Received: from capella.nps.navy.mil by peregrine.nps.navy.mil via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 22 Apr 2002 19:37:54 UT Received: from [131.120.179.253] (budden.ro.nps.navy.mil [131.120.179.253]) by capella.nps.navy.mil (8.12.2/8.12.2) with ESMTP id g3MJVI4Y018175; Mon, 22 Apr 2002 12:31:19 -0700 (PDT) Mime-Version: 1.0 X-Sender: budden@grasp.ad.nps.navy.mil Message-Id: In-Reply-To: <003301c1ea2c$4e404520$6200000a@meshnetworks.com> References: <003301c1ea2c$4e404520$6200000a@meshnetworks.com> Date: Mon, 22 Apr 2002 12:37:30 -0700 To: "Phil Neumiller" , manet@ietf.org From: Rex Buddenberg Subject: [manet] Re: Re Security considerations in MANET Content-Type: multipart/alternative; boundary="============_-1192618238==_ma============" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --============_-1192618238==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Time for some term clarity. You get two major items out of security at this level: - confidentiality - authenticity (which is a superset of integrity). Now, divide the traffic on a MANET into two parts: one is the application data. Set it aside; not part of this discussion. The other is all the routing information. The routing information needs authenticity as a matter of course. > I also do not think that all control messages need > to be encrypted. So this statement is partially correct. If it said 'digitally signed' instead of 'encrypted' I'd fully agree. I can easily envision situations where I'd want the routing information to be fairly openly available and others where I'd want it encrypted. But I cannot envision situations (of any scale) where I'd want it unauthenticable. Situation A. We have a multinational laydown for peacekeeping operations -- a lot of infrastructure is contributed by numerous coalition partners. We want to be able to advertise the MANET structure to them all (and are willing to risk the Bad Guys cribbing the data). But, while we're willing to let the Bad Guys know what our topology is, we're not willing to let them disrupt it by spoofing. Therefore, all the data is authenticated via digital signature (for which we have a PKI to support). Authentication failures result in doubt about authenticity but not loss of the data, so the consumer of the routing data is in the caveat emptor position -- it might be a lesser contributor to the coalition who hasn't got act completely together. Situation B might be another multinational laydown, but this time for combat operations. In this case, topology is a protected asset (it would have useful order-of-battle information, somewhat similar to what you could get from traffic analysis) and it's shared with a smaller number of coalition partners. In this case I'd want the encryption for confidentiality in addition to the digital signature. (Note that the PKI overhead is a sunk cost -- I had to buy that for the authenticity part of the problem). In situation A, inability to authenticate doesn't render the data unusable, just of doubtful origin. In this situation, inability to decrypt would result in inability to use the MANET. -- b --============_-1192618238==_ma============ Content-Type: text/html; charset="us-ascii" [manet] Re: Re Security considerations in MANET
Time for some term clarity.

You get two major items out of security at this level:
- confidentiality
- authenticity (which is a superset of integrity).

Now, divide the traffic on a MANET into two parts: one is the application data.  Set it aside; not part of this discussion.  The other is all the routing information.

The routing information needs authenticity as a matter of course.
> I also do not think that all control messages need
> to be encrypted.
So this statement is partially correct.  If it said 'digitally signed' instead of 'encrypted' I'd fully agree.
     I can easily envision situations where I'd want the routing information to be fairly openly available and others where I'd want it encrypted.  But I cannot envision situations (of any scale) where I'd want it unauthenticable.

Situation A.  We have a multinational laydown for peacekeeping operations -- a lot of infrastructure is contributed by numerous coalition partners.  We want to be able to advertise the MANET structure to them all (and are willing to risk the Bad Guys cribbing the data).  But, while we're willing to let the Bad Guys know what our topology is, we're not willing to let them disrupt it by spoofing.  Therefore, all the data is authenticated via digital signature (for which we have a PKI to support).  Authentication failures result in doubt about authenticity but not loss of the data, so the consumer of the routing data is in the caveat emptor position -- it might be a lesser contributor to the coalition who hasn't got act completely together.

Situation B might be another multinational laydown, but this time for combat operations.  In this case, topology is a protected asset (it would have useful order-of-battle information, somewhat similar to what you could get from traffic analysis) and it's shared with a smaller number of coalition partners.  In this case I'd want the encryption for confidentiality in addition to the digital signature.  (Note that the PKI overhead is a sunk cost -- I had to buy that for the authenticity part of the problem).  In situation A, inability to authenticate doesn't render the data unusable, just of doubtful origin.  In this situation, inability to decrypt would result in inability to use the MANET.  

--
b
--============_-1192618238==_ma============-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 17:26:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14103 for ; Mon, 22 Apr 2002 17:26:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20316; Mon, 22 Apr 2002 17:02:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20285 for ; Mon, 22 Apr 2002 17:02:02 -0400 (EDT) Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13024 for ; Mon, 22 Apr 2002 17:01:57 -0400 (EDT) Received: (cpmta 6006 invoked from network); 22 Apr 2002 14:01:29 -0700 Received: from 12.221.64.123 (HELO uiuc.edu) by smtp.carter.net (209.228.32.64) with SMTP; 22 Apr 2002 14:01:29 -0700 X-Sent: 22 Apr 2002 21:01:29 GMT Message-ID: <3CC47934.1080101@uiuc.edu> Date: Mon, 22 Apr 2002 15:57:24 -0500 From: Casey Carter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manel Guerrero Zapata CC: ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Manel Guerrero Zapata wrote: > Hi Casey, > > Comments bellow. > well, there's no need to bellow. ;) [snip] > I have never stated than SAODV is able to "preserve availability of > communication between source and destination". Actually in the > abstract of > the draft it says: > > 8<--------------------------------------------------------------------- > The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension > of the AODV routing protocol that can be used to protect the route > discovery mechanism providing security features like integrity, > authentication and non-repudiation. > --------------------------------------------------------------------->8 > > But I don't say anything about Denial of Service. If an attacker wants > to do a DoS it will probably find easier to flood the network with > packets or to send a packet every time it detects one it's being sent > (so they'll collide) or just emit interferences with the max power it > can. > Then, not even simetric cryptosystems will save you. This attack is slightly more powerful than denial of service: the attacker is forcing the source to route through him, so there's some traffic stealing going on here that is not possible with a pure DoS jamming attack at a lower layer. Not having any kind of a security background (except for some petty shoplifting when I was a kid) I guess I just don't see the point. What is the advantage in a providing authentication, integrity and non-repudiation if an attacker can still trick you into routing where he wants you to? What exactly are the goals that SAODV is trying to achieve with these mechanisms? > > > Regards, > > Manel Guerrero > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 17:26:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14114 for ; Mon, 22 Apr 2002 17:26:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21759 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 17:26:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20316; Mon, 22 Apr 2002 17:02:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20285 for ; Mon, 22 Apr 2002 17:02:02 -0400 (EDT) Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13024 for ; Mon, 22 Apr 2002 17:01:57 -0400 (EDT) Received: (cpmta 6006 invoked from network); 22 Apr 2002 14:01:29 -0700 Received: from 12.221.64.123 (HELO uiuc.edu) by smtp.carter.net (209.228.32.64) with SMTP; 22 Apr 2002 14:01:29 -0700 X-Sent: 22 Apr 2002 21:01:29 GMT Message-ID: <3CC47934.1080101@uiuc.edu> Date: Mon, 22 Apr 2002 15:57:24 -0500 From: Casey Carter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manel Guerrero Zapata CC: ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Manel Guerrero Zapata wrote: > Hi Casey, > > Comments bellow. > well, there's no need to bellow. ;) [snip] > I have never stated than SAODV is able to "preserve availability of > communication between source and destination". Actually in the > abstract of > the draft it says: > > 8<--------------------------------------------------------------------- > The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension > of the AODV routing protocol that can be used to protect the route > discovery mechanism providing security features like integrity, > authentication and non-repudiation. > --------------------------------------------------------------------->8 > > But I don't say anything about Denial of Service. If an attacker wants > to do a DoS it will probably find easier to flood the network with > packets or to send a packet every time it detects one it's being sent > (so they'll collide) or just emit interferences with the max power it > can. > Then, not even simetric cryptosystems will save you. This attack is slightly more powerful than denial of service: the attacker is forcing the source to route through him, so there's some traffic stealing going on here that is not possible with a pure DoS jamming attack at a lower layer. Not having any kind of a security background (except for some petty shoplifting when I was a kid) I guess I just don't see the point. What is the advantage in a providing authentication, integrity and non-repudiation if an attacker can still trick you into routing where he wants you to? What exactly are the goals that SAODV is trying to achieve with these mechanisms? > > > Regards, > > Manel Guerrero > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 22 19:58:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18610 for ; Mon, 22 Apr 2002 19:58:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00198; Mon, 22 Apr 2002 19:37:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00163 for ; Mon, 22 Apr 2002 19:37:50 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18066 for ; Mon, 22 Apr 2002 19:37:46 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g3MNbe101387; Mon, 22 Apr 2002 19:37:40 -0400 Date: Mon, 22 Apr 2002 19:37:34 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: Phil Neumiller cc: Manel Guerrero Zapata , ext Casey Carter , ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Re Security considerations in MANET In-Reply-To: <000901c1ea22$09c90080$6200000a@meshnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Phil, > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. A good approach (well, at least in my opinion (;-)) is that of distributed trust through threshold cryptography. One of our early references on this topic is: L. Zhou and Z.J. Haas, "Securing Ad Hoc Networks," IEEE Network Magazine, vol. 13, no.6, November/December 1999 Zygmunt. ==--====== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Mon, 22 Apr 2002, Phil Neumiller wrote: > Can we agree to simple premises for MANET security? > > A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is > deployed with trusted fixed infrastructure that shares the MANET algorithm. > B). This means key management is the only REAL issue. > C). There are plenty of research papers on key management issues for ad hoc > networks, I suggest the security enthusiests read these. > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. > > It is silly to talk about what parts of MANET (in this case AODV) messages are > vulnerable. All messages (payload and control) MUST be encrypted. > > Thanks, > > Phil > ----- Original Message ----- > From: "Manel Guerrero Zapata" > To: "ext Casey Carter" > Cc: "ext Claude Castelluccia" ; ; "Seung Yi" > Sent: Monday, April 22, 2002 1:01 PM > Subject: Re: [manet] Security Considerations of AODV > > > > Hi Casey, > > > > Comments bellow. > > > > ext Casey Carter wrote: > > > Manel Guerrero Zapata wrote: > > > > > >> Hi Casey, > > >> > > > > [...] > > > > >> So for the attack you are suggesting to succeed, they would have to > > >> manage that > > >> the RREQ forwarded by the second bad guy (with the faked hop count) will > > >> be the fastest one to reach one of those nodes who can issue a RREP back > > >> (because they are intermediate nodes that have a route to the > > >> destination, > > >> or because they are the destination). > > >> And that is not easy because that means that they actually have to be the > > >> fastest path (acording to AODV policy of RREQ forwarding) to at least > > >> that > > >> intermediate node. Or, just the fastest path if there are no > > >> intermediate nodes > > > > > > > > > Unfortunately, you have to assume that the attacker always knows what he > > > is doing; we replace the notion "shortest" with "fastest". > > > > > > Yes, but my point here is that it is not so important that there > > is some possible attack to the hop count integrity, because that is not a key > > element to get a route selected among others. It does not give a real benefit > > to the attackers. > > > > > > > Although I > > > can't find anything on the subject in the draft, it is well known among > > > implementors of ad hoc routing protocols that immediate rebroadcast of > > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > > broadcasts from multiple nodes cause extremely high contention, and > > > (especially in simulations) lots of collisions.The solution for this > > > problem is for each node to choose a small random backoff timer to > > > better distribute the rebroadcasts. > > > > > > I thing this is something you find only in the simulation world (that if > > you broadcast a RREQ all your neighbors will rebroadcast it at the very > > same time and all the packets will collide). > > But in the real world, if you use some wireless card they already have > > (like the ethernet cards) this small random backoff, > > to avoid collisions, for every packet they send. > > > > > > > The consequence of this is that a > > > route request travels slower through the MANET than regular unicast > > > traffic. So if my attackers have a clue, they will maintain an active > > > route between them to support the packet tunnel. This tunnel will > > > deliver the route request from the source's tail to the destination's > > > tail slightly before the route request flood reaches the destination's > > > region of the MANET, and the first route request the destination > > > receives will be through the "magic" link. > > > > > > Since there is no added delay for rebroadcasting, the attackers > > have more or less the same chances to be the fastest as if they wouldn't > > be bad boys. So tunneling and breaking the hop count does not give > > any advantage to the attackers in order to get the traffic going between > > them. > > > > > > > The attackers can coordinate > > > to make sure that they are on or near the shortest path between the > > > source and destination, so this attack should be quite effective in > > > denying communication betweem source and dest. The attack is assisted > > > by expanding ring search (Section 6.4 in draft 10), since the attackers > > > can probably tail the source and destination fairly closely. In this > > > case, the attackers need only be "close" to the fastest path. > > > > > > If people are using expanding ring, then the attackers have a big chance > > to be the fastest. But in scenarios more security demanding the originator > > of the RREQ could decide not to use the expanding ring search technique. > > And that's it. There is no attack then. > > > > > > > If the attackers have more resources at their disposal, they can improve > > > upon this margin. The attackers can purchase better radios than what is > > > commonly used in the MANET, so that they actually DO have the fastest, > > > shortest link across the MANET. AODV/DSR/whatever will then choose the > > > path through the attackers as the shortest path. The gist of this > > > argument is that simply authenticating the RREQ/RREPs is not sufficent > > > to preserve availability of communication between source and > > > destination, but only to verify that a route exists. > > > > > > Well, if attackers just by having better radios than the rest able to be in the > > faster/shorter path. They don't need to misbehave to be in the path. So then > > they are just as good boys which happend to have better radios. > > So their route should be selected. > > > > And if an attacker can put himself _in_ the fastest path, then he is in > > the fastest path. Although that is not so easy if nodes are moving. > > From experiences with real implementations (not simulations) a communication > > between two nodes does not happen through the same path all the time, > > it is changing the route quite a lot. > > > > I have never stated than SAODV is able to "preserve availability of > > communication between source and destination". Actually in the abstract of > > the draft it says: > > > > 8<--------------------------------------------------------------------- > > The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension > > of the AODV routing protocol that can be used to protect the route > > discovery mechanism providing security features like integrity, > > authentication and non-repudiation. > > --------------------------------------------------------------------->8 > > > > But I don't say anything about Denial of Service. If an attacker wants > > to do a DoS it will probably find easier to flood the network with > > packets or to send a packet every time it detects one it's being sent > > (so they'll collide) or just emit interferences with the max power it can. > > Then, not even simetric cryptosystems will save you. > > > > > > Regards, > > > > Manel Guerrero > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 22 19:58:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18624 for ; Mon, 22 Apr 2002 19:58:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01664 for manet-archive@odin.ietf.org; Mon, 22 Apr 2002 19:58:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00198; Mon, 22 Apr 2002 19:37:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00163 for ; Mon, 22 Apr 2002 19:37:50 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18066 for ; Mon, 22 Apr 2002 19:37:46 -0400 (EDT) From: haas@ece.cornell.edu Received: from verdi.ee.cornell.edu (verdi.ee.cornell.edu [128.84.240.71]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g3MNbe101387; Mon, 22 Apr 2002 19:37:40 -0400 Date: Mon, 22 Apr 2002 19:37:34 -0400 (EDT) X-Sender: haas@verdi.ee.cornell.edu To: Phil Neumiller cc: Manel Guerrero Zapata , ext Casey Carter , ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Re Security considerations in MANET In-Reply-To: <000901c1ea22$09c90080$6200000a@meshnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Phil, > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. A good approach (well, at least in my opinion (;-)) is that of distributed trust through threshold cryptography. One of our early references on this topic is: L. Zhou and Z.J. Haas, "Securing Ad Hoc Networks," IEEE Network Magazine, vol. 13, no.6, November/December 1999 Zygmunt. ==--====== ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas Wireless Networks Laboratory http://wnl.ece.cornell.edu School of Electrical Engineering Cornell University tel: +1-607-255-3454 323 Frank Rhodes Hall fax: +1-607-255-9072 Ithaca, NY 14853 e-mail: haas@ece.cornell.edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On Mon, 22 Apr 2002, Phil Neumiller wrote: > Can we agree to simple premises for MANET security? > > A). Its best to run all messages encrypted, i.e. provide a PKI for a MANET that is > deployed with trusted fixed infrastructure that shares the MANET algorithm. > B). This means key management is the only REAL issue. > C). There are plenty of research papers on key management issues for ad hoc > networks, I suggest the security enthusiests read these. > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. > > It is silly to talk about what parts of MANET (in this case AODV) messages are > vulnerable. All messages (payload and control) MUST be encrypted. > > Thanks, > > Phil > ----- Original Message ----- > From: "Manel Guerrero Zapata" > To: "ext Casey Carter" > Cc: "ext Claude Castelluccia" ; ; "Seung Yi" > Sent: Monday, April 22, 2002 1:01 PM > Subject: Re: [manet] Security Considerations of AODV > > > > Hi Casey, > > > > Comments bellow. > > > > ext Casey Carter wrote: > > > Manel Guerrero Zapata wrote: > > > > > >> Hi Casey, > > >> > > > > [...] > > > > >> So for the attack you are suggesting to succeed, they would have to > > >> manage that > > >> the RREQ forwarded by the second bad guy (with the faked hop count) will > > >> be the fastest one to reach one of those nodes who can issue a RREP back > > >> (because they are intermediate nodes that have a route to the > > >> destination, > > >> or because they are the destination). > > >> And that is not easy because that means that they actually have to be the > > >> fastest path (acording to AODV policy of RREQ forwarding) to at least > > >> that > > >> intermediate node. Or, just the fastest path if there are no > > >> intermediate nodes > > > > > > > > > Unfortunately, you have to assume that the attacker always knows what he > > > is doing; we replace the notion "shortest" with "fastest". > > > > > > Yes, but my point here is that it is not so important that there > > is some possible attack to the hop count integrity, because that is not a key > > element to get a route selected among others. It does not give a real benefit > > to the attackers. > > > > > > > Although I > > > can't find anything on the subject in the draft, it is well known among > > > implementors of ad hoc routing protocols that immediate rebroadcast of > > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > > broadcasts from multiple nodes cause extremely high contention, and > > > (especially in simulations) lots of collisions.The solution for this > > > problem is for each node to choose a small random backoff timer to > > > better distribute the rebroadcasts. > > > > > > I thing this is something you find only in the simulation world (that if > > you broadcast a RREQ all your neighbors will rebroadcast it at the very > > same time and all the packets will collide). > > But in the real world, if you use some wireless card they already have > > (like the ethernet cards) this small random backoff, > > to avoid collisions, for every packet they send. > > > > > > > The consequence of this is that a > > > route request travels slower through the MANET than regular unicast > > > traffic. So if my attackers have a clue, they will maintain an active > > > route between them to support the packet tunnel. This tunnel will > > > deliver the route request from the source's tail to the destination's > > > tail slightly before the route request flood reaches the destination's > > > region of the MANET, and the first route request the destination > > > receives will be through the "magic" link. > > > > > > Since there is no added delay for rebroadcasting, the attackers > > have more or less the same chances to be the fastest as if they wouldn't > > be bad boys. So tunneling and breaking the hop count does not give > > any advantage to the attackers in order to get the traffic going between > > them. > > > > > > > The attackers can coordinate > > > to make sure that they are on or near the shortest path between the > > > source and destination, so this attack should be quite effective in > > > denying communication betweem source and dest. The attack is assisted > > > by expanding ring search (Section 6.4 in draft 10), since the attackers > > > can probably tail the source and destination fairly closely. In this > > > case, the attackers need only be "close" to the fastest path. > > > > > > If people are using expanding ring, then the attackers have a big chance > > to be the fastest. But in scenarios more security demanding the originator > > of the RREQ could decide not to use the expanding ring search technique. > > And that's it. There is no attack then. > > > > > > > If the attackers have more resources at their disposal, they can improve > > > upon this margin. The attackers can purchase better radios than what is > > > commonly used in the MANET, so that they actually DO have the fastest, > > > shortest link across the MANET. AODV/DSR/whatever will then choose the > > > path through the attackers as the shortest path. The gist of this > > > argument is that simply authenticating the RREQ/RREPs is not sufficent > > > to preserve availability of communication between source and > > > destination, but only to verify that a route exists. > > > > > > Well, if attackers just by having better radios than the rest able to be in the > > faster/shorter path. They don't need to misbehave to be in the path. So then > > they are just as good boys which happend to have better radios. > > So their route should be selected. > > > > And if an attacker can put himself _in_ the fastest path, then he is in > > the fastest path. Although that is not so easy if nodes are moving. > > From experiences with real implementations (not simulations) a communication > > between two nodes does not happen through the same path all the time, > > it is changing the route quite a lot. > > > > I have never stated than SAODV is able to "preserve availability of > > communication between source and destination". Actually in the abstract of > > the draft it says: > > > > 8<--------------------------------------------------------------------- > > The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension > > of the AODV routing protocol that can be used to protect the route > > discovery mechanism providing security features like integrity, > > authentication and non-repudiation. > > --------------------------------------------------------------------->8 > > > > But I don't say anything about Denial of Service. If an attacker wants > > to do a DoS it will probably find easier to flood the network with > > packets or to send a packet every time it detects one it's being sent > > (so they'll collide) or just emit interferences with the max power it can. > > Then, not even simetric cryptosystems will save you. > > > > > > Regards, > > > > Manel Guerrero > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 23 06:25:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10595 for ; Tue, 23 Apr 2002 06:25:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13474; Tue, 23 Apr 2002 06:06:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13359 for ; Tue, 23 Apr 2002 06:05:53 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10301 for ; Tue, 23 Apr 2002 06:05:45 -0400 (EDT) Received: from golf.een.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 23 Apr 2002 11:04:09 +0100 Received: from een9097.een.bris.ac.uk (een9097.een.bris.ac.uk [137.222.189.97]) by golf.een.bris.ac.uk (8.9.3/8.9.3) with ESMTP id LAA09589 for ; Tue, 23 Apr 2002 11:02:58 +0100 (BST) From: "D Kothris, Electrical & Electronic Engineering" Date: Tue, 23 Apr 2002 11:02:58 +0100 To: manet@ietf.org Message-ID: Priority: NORMAL X-Mailer: Execmail for Win32 Version 5.0.1 Build (55) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Subject: [manet] Complexity VS enhanced functionality & flexibility Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear co-workers, I'm fairly new in this research area (about a year), and I am investigating ad hoc routing mechanisms. A kind of dilemma that has risen in my mind has driven me to put forward this question so that I can capture the general trend that exists within the MANET research community. I am interested to find out whether complexity is thought of a just means to achieve further or improved functionality. I am pondering that the answer to this is not one sided, so if the answer is "gray", would it be possible to get some suggestions of cases where simplicity in design might be sacrificed for a better performance trade-off. I fear that if i give an example some people might stick to that, but nevertheless I will give one just to be more colorful: The use of a Neural network with multiple input feeds might be used as a part of a classification system, in order to decide upon the suitability of routing paths. This could only be one of many complex approaches that may exist within a routing protocol solution. Please feel free to drop your comments. I would appreciate it a lot. Thanks Dimosthenis (Dimos) _________________________________________________________________ ***************************************************************** Dimosthenis Kothris Centre for Communications Research, University of Bristol, Network & Protocols group Address: Contact numbers: _________________________________________________________________ Network & Protocols Center for Communcations research Merchant Venturers Building Tel : +44 117 903 1104 Woodland Road Fax : +44 117 954 5206 Bristol BS8 1UB Mobile: +44 7779 40 48 42 United Kingdom Email : d.kothris@bristol.ac.uk ***************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 23 06:25:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10605 for ; Tue, 23 Apr 2002 06:25:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA14554 for manet-archive@odin.ietf.org; Tue, 23 Apr 2002 06:26:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13474; Tue, 23 Apr 2002 06:06:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13359 for ; Tue, 23 Apr 2002 06:05:53 -0400 (EDT) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10301 for ; Tue, 23 Apr 2002 06:05:45 -0400 (EDT) Received: from golf.een.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 23 Apr 2002 11:04:09 +0100 Received: from een9097.een.bris.ac.uk (een9097.een.bris.ac.uk [137.222.189.97]) by golf.een.bris.ac.uk (8.9.3/8.9.3) with ESMTP id LAA09589 for ; Tue, 23 Apr 2002 11:02:58 +0100 (BST) From: "D Kothris, Electrical & Electronic Engineering" Date: Tue, 23 Apr 2002 11:02:58 +0100 To: manet@ietf.org Message-ID: Priority: NORMAL X-Mailer: Execmail for Win32 Version 5.0.1 Build (55) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Subject: [manet] Complexity VS enhanced functionality & flexibility Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Dear co-workers, I'm fairly new in this research area (about a year), and I am investigating ad hoc routing mechanisms. A kind of dilemma that has risen in my mind has driven me to put forward this question so that I can capture the general trend that exists within the MANET research community. I am interested to find out whether complexity is thought of a just means to achieve further or improved functionality. I am pondering that the answer to this is not one sided, so if the answer is "gray", would it be possible to get some suggestions of cases where simplicity in design might be sacrificed for a better performance trade-off. I fear that if i give an example some people might stick to that, but nevertheless I will give one just to be more colorful: The use of a Neural network with multiple input feeds might be used as a part of a classification system, in order to decide upon the suitability of routing paths. This could only be one of many complex approaches that may exist within a routing protocol solution. Please feel free to drop your comments. I would appreciate it a lot. Thanks Dimosthenis (Dimos) _________________________________________________________________ ***************************************************************** Dimosthenis Kothris Centre for Communications Research, University of Bristol, Network & Protocols group Address: Contact numbers: _________________________________________________________________ Network & Protocols Center for Communcations research Merchant Venturers Building Tel : +44 117 903 1104 Woodland Road Fax : +44 117 954 5206 Bristol BS8 1UB Mobile: +44 7779 40 48 42 United Kingdom Email : d.kothris@bristol.ac.uk ***************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 23 06:34:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10800 for ; Tue, 23 Apr 2002 06:34:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13962; Tue, 23 Apr 2002 06:14:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13933 for ; Tue, 23 Apr 2002 06:14:44 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10455 for ; Tue, 23 Apr 2002 06:14:38 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3NAF1F10527 for ; Tue, 23 Apr 2002 13:15:01 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Apr 2002 13:14:41 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 23 Apr 2002 13:14:41 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id NAA16546; Tue, 23 Apr 2002 13:14:40 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC533B2.20507@nokia.com> Date: Tue, 23 Apr 2002 13:13:06 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Casey Carter CC: ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <3CC47934.1080101@uiuc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2002 10:14:41.0463 (UTC) FILETIME=[AEB92470:01C1EAAF] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Casey, I don't see that you have a feasible way to build an attack against SAODV more powerful than DoS. In the part you have [sniped] in your reply is where one by one I've been showing why the different attacks you where suggesting are not feasible. The only feasible way than an attacker has to make the traffic go through him is that the chosen path (without misbehaving nodes) would be through him anyway (so I don't see a big deal with that). And if a node has bigger antena and that makes him to get more chances to get the path, that has nothing to do with misbehaving. And if you don't want this node to listen to your conversations with another node, what you should use is encryption for the data packets. SAODV protects routing, not data. Thanks, Manel ext Casey Carter wrote: > Manel Guerrero Zapata wrote: > >> Hi Casey, >> >> Comments bellow. >> > well, there's no need to bellow. ;) > > [snip] > >> I have never stated than SAODV is able to "preserve availability of >> communication between source and destination". Actually in the >> abstract of >> the draft it says: >> >> 8<--------------------------------------------------------------------- >> The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension >> of the AODV routing protocol that can be used to protect the route >> discovery mechanism providing security features like integrity, >> authentication and non-repudiation. >> --------------------------------------------------------------------->8 >> >> But I don't say anything about Denial of Service. If an attacker wants >> to do a DoS it will probably find easier to flood the network with >> packets or to send a packet every time it detects one it's being sent >> (so they'll collide) or just emit interferences with the max power it >> can. >> Then, not even simetric cryptosystems will save you. > > > This attack is slightly more powerful than denial of service: the > attacker is forcing the source to route through him, so there's some > traffic stealing going on here that is not possible with a pure DoS > jamming attack at a lower layer. Not having any kind of a security > background (except for some petty shoplifting when I was a kid) I guess > I just don't see the point. What is the advantage in a providing > authentication, integrity and non-repudiation if an attacker can still > trick you into routing where he wants you to? What exactly are the > goals that SAODV is trying to achieve with these mechanisms? > >> >> >> Regards, >> >> Manel Guerrero >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 23 06:34:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10812 for ; Tue, 23 Apr 2002 06:34:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA15524 for manet-archive@odin.ietf.org; Tue, 23 Apr 2002 06:34:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13962; Tue, 23 Apr 2002 06:14:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13933 for ; Tue, 23 Apr 2002 06:14:44 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10455 for ; Tue, 23 Apr 2002 06:14:38 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3NAF1F10527 for ; Tue, 23 Apr 2002 13:15:01 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 23 Apr 2002 13:14:41 +0300 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 23 Apr 2002 13:14:41 +0300 Received: from nokia.com (manet.research.nokia.com [172.21.37.112]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id NAA16546; Tue, 23 Apr 2002 13:14:40 +0300 (EETDST) X-Authentication-Warning: mgw.research.nokia.com: Host manet.research.nokia.com [172.21.37.112] claimed to be nokia.com Message-ID: <3CC533B2.20507@nokia.com> Date: Tue, 23 Apr 2002 13:13:06 +0300 From: Manel Guerrero Zapata User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: en MIME-Version: 1.0 To: ext Casey Carter CC: ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <3CC47934.1080101@uiuc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2002 10:14:41.0463 (UTC) FILETIME=[AEB92470:01C1EAAF] Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Casey, I don't see that you have a feasible way to build an attack against SAODV more powerful than DoS. In the part you have [sniped] in your reply is where one by one I've been showing why the different attacks you where suggesting are not feasible. The only feasible way than an attacker has to make the traffic go through him is that the chosen path (without misbehaving nodes) would be through him anyway (so I don't see a big deal with that). And if a node has bigger antena and that makes him to get more chances to get the path, that has nothing to do with misbehaving. And if you don't want this node to listen to your conversations with another node, what you should use is encryption for the data packets. SAODV protects routing, not data. Thanks, Manel ext Casey Carter wrote: > Manel Guerrero Zapata wrote: > >> Hi Casey, >> >> Comments bellow. >> > well, there's no need to bellow. ;) > > [snip] > >> I have never stated than SAODV is able to "preserve availability of >> communication between source and destination". Actually in the >> abstract of >> the draft it says: >> >> 8<--------------------------------------------------------------------- >> The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension >> of the AODV routing protocol that can be used to protect the route >> discovery mechanism providing security features like integrity, >> authentication and non-repudiation. >> --------------------------------------------------------------------->8 >> >> But I don't say anything about Denial of Service. If an attacker wants >> to do a DoS it will probably find easier to flood the network with >> packets or to send a packet every time it detects one it's being sent >> (so they'll collide) or just emit interferences with the max power it >> can. >> Then, not even simetric cryptosystems will save you. > > > This attack is slightly more powerful than denial of service: the > attacker is forcing the source to route through him, so there's some > traffic stealing going on here that is not possible with a pure DoS > jamming attack at a lower layer. Not having any kind of a security > background (except for some petty shoplifting when I was a kid) I guess > I just don't see the point. What is the advantage in a providing > authentication, integrity and non-repudiation if an attacker can still > trick you into routing where he wants you to? What exactly are the > goals that SAODV is trying to achieve with these mechanisms? > >> >> >> Regards, >> >> Manel Guerrero >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 23 09:10:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16203 for ; Tue, 23 Apr 2002 09:10:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26657; Tue, 23 Apr 2002 08:42:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26623 for ; Tue, 23 Apr 2002 08:42:21 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14972 for ; Tue, 23 Apr 2002 08:42:17 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY1063; Tue, 23 Apr 2002 08:42:19 -0400 Message-ID: <003101c1eac4$4d8e3720$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: Cc: "Manel Guerrero Zapata" , "ext Casey Carter" , "ext Claude Castelluccia" , , "Seung Yi" References: Subject: Re: [manet] Re Security considerations in MANET Date: Tue, 23 Apr 2002 08:42:17 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Dr. Haas, Yes I have read this paper and many of the others. Fascinating stuff, except I see some holes here. For instance if I am the first in a conference room and wish to access the projector, presumably in a PAN/MANET like fashion, I have no fellows to imply that I am trusted right? Maybe I am misunderstanding something about thresholding though. ----- Original Message ----- From: To: "Phil Neumiller" Cc: "Manel Guerrero Zapata" ; "ext Casey Carter" ; "ext Claude Castelluccia" ; ; "Seung Yi" Sent: Monday, April 22, 2002 7:37 PM Subject: Re: [manet] Re Security considerations in MANET > Hi Phil, > > > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > > a good solution for key management does not yet exist. Please find one. > > A good approach (well, at least in my opinion (;-)) is that of distributed > trust through threshold cryptography. One of our early references on this > topic is: > > L. Zhou and Z.J. Haas, "Securing Ad Hoc Networks," IEEE Network Magazine, > vol. 13, no.6, November/December 1999 > > Zygmunt. > ==--====== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue Apr 23 09:10:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16217 for ; Tue, 23 Apr 2002 09:10:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28754 for manet-archive@odin.ietf.org; Tue, 23 Apr 2002 09:10:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26657; Tue, 23 Apr 2002 08:42:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26623 for ; Tue, 23 Apr 2002 08:42:21 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14972 for ; Tue, 23 Apr 2002 08:42:17 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSY1063; Tue, 23 Apr 2002 08:42:19 -0400 Message-ID: <003101c1eac4$4d8e3720$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: Cc: "Manel Guerrero Zapata" , "ext Casey Carter" , "ext Claude Castelluccia" , , "Seung Yi" References: Subject: Re: [manet] Re Security considerations in MANET Date: Tue, 23 Apr 2002 08:42:17 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Dr. Haas, Yes I have read this paper and many of the others. Fascinating stuff, except I see some holes here. For instance if I am the first in a conference room and wish to access the projector, presumably in a PAN/MANET like fashion, I have no fellows to imply that I am trusted right? Maybe I am misunderstanding something about thresholding though. ----- Original Message ----- From: To: "Phil Neumiller" Cc: "Manel Guerrero Zapata" ; "ext Casey Carter" ; "ext Claude Castelluccia" ; ; "Seung Yi" Sent: Monday, April 22, 2002 7:37 PM Subject: Re: [manet] Re Security considerations in MANET > Hi Phil, > > > D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > > a good solution for key management does not yet exist. Please find one. > > A good approach (well, at least in my opinion (;-)) is that of distributed > trust through threshold cryptography. One of our early references on this > topic is: > > L. Zhou and Z.J. Haas, "Securing Ad Hoc Networks," IEEE Network Magazine, > vol. 13, no.6, November/December 1999 > > Zygmunt. > ==--====== > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- > Prof. Zygmunt J. Haas http://people.ece.cornell.edu/haas > Wireless Networks Laboratory http://wnl.ece.cornell.edu > School of Electrical Engineering > Cornell University tel: +1-607-255-3454 > 323 Frank Rhodes Hall fax: +1-607-255-9072 > Ithaca, NY 14853 e-mail: haas@ece.cornell.edu > U.S.A > WNL web page: http://wnl.ece.cornell.edu > ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue Apr 23 11:44:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24087 for ; Tue, 23 Apr 2002 11:44:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09375 for manet-archive@odin.ietf.org; Tue, 23 Apr 2002 11:45:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07317; Tue, 23 Apr 2002 11:15:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07288 for ; Tue, 23 Apr 2002 11:15:34 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22243 for ; Tue, 23 Apr 2002 11:15:28 -0400 (EDT) Received: from sarnoff.com ([130.33.10.103]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GV117300.3X8 for ; Tue, 23 Apr 2002 11:18:39 -0400 Message-ID: <3CC57A73.A6C4B3E6@sarnoff.com> Date: Tue, 23 Apr 2002 11:14:59 -0400 From: Jim Kaba Reply-To: jkaba@sarnoff.com Organization: Advanced Networks and Computing Group X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] packet rebroadcasts Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Manel, This reply is not related to the security discussion (thus, the subject change). It has to do with the packet rebroadcast comments in the previous post. Manel Guerrero Zapata wrote: > > Hi Casey, > > Comments bellow. > > ext Casey Carter wrote: > > Manel Guerrero Zapata wrote: > > > >> Hi Casey, 8<--------------------------------------------------------------------------- > > Although I > > can't find anything on the subject in the draft, it is well known among > > implementors of ad hoc routing protocols that immediate rebroadcast of > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > broadcasts from multiple nodes cause extremely high contention, and > > (especially in simulations) lots of collisions.The solution for this > > problem is for each node to choose a small random backoff timer to > > better distribute the rebroadcasts. > > I thing this is something you find only in the simulation world (that if > you broadcast a RREQ all your neighbors will rebroadcast it at the very > same time and all the packets will collide). > But in the real world, if you use some wireless card they already have > (like the ethernet cards) this small random backoff, > to avoid collisions, for every packet they send. I have seen this in the real world--specifically with Orinoco 802.11b cards in ad hoc mode. (I'm talking specifically about the "pseudo-IBSS" mode, where the nodes are truly peer-to-peer.) When the network is lightly loaded, the rebroadcasts (and subsequent replies) are highly synchronized and are extremely likely to collide unless additional jitter is added. I haven't looked at the 802.11 spec in quite a while, but I recall discovering that the backoff mechanism is only enabled _after_ contention has been discovered. If the cards aren't already in contention mode (from previous traffic), they will just do the usual collision avoidance: they will all do a carrier sense (synchronized), see no traffic (synchronized), and transmit their packets (synchronized-------->COLLISION!). That is, if they don't sense traffic and aren't already in contention mode, they transmit immediately. Note: even if I have misinterpreted the spec (which is easy to do), I did see synchronized retransmissions and corrected them with jitter. Jim -- -------------------------------------------------------------- James T. Kaba Sarnoff Corporation Time flies like an arrow... jkaba@sarnoff.com ...Fruit flies like a banana! 609-734-2246 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 23 12:41:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24076 for ; Tue, 23 Apr 2002 11:44:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07317; Tue, 23 Apr 2002 11:15:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07288 for ; Tue, 23 Apr 2002 11:15:34 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22243 for ; Tue, 23 Apr 2002 11:15:28 -0400 (EDT) Received: from sarnoff.com ([130.33.10.103]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GV117300.3X8 for ; Tue, 23 Apr 2002 11:18:39 -0400 Message-ID: <3CC57A73.A6C4B3E6@sarnoff.com> Date: Tue, 23 Apr 2002 11:14:59 -0400 From: Jim Kaba Reply-To: jkaba@sarnoff.com Organization: Advanced Networks and Computing Group X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] packet rebroadcasts Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Manel, This reply is not related to the security discussion (thus, the subject change). It has to do with the packet rebroadcast comments in the previous post. Manel Guerrero Zapata wrote: > > Hi Casey, > > Comments bellow. > > ext Casey Carter wrote: > > Manel Guerrero Zapata wrote: > > > >> Hi Casey, 8<--------------------------------------------------------------------------- > > Although I > > can't find anything on the subject in the draft, it is well known among > > implementors of ad hoc routing protocols that immediate rebroadcast of > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > broadcasts from multiple nodes cause extremely high contention, and > > (especially in simulations) lots of collisions.The solution for this > > problem is for each node to choose a small random backoff timer to > > better distribute the rebroadcasts. > > I thing this is something you find only in the simulation world (that if > you broadcast a RREQ all your neighbors will rebroadcast it at the very > same time and all the packets will collide). > But in the real world, if you use some wireless card they already have > (like the ethernet cards) this small random backoff, > to avoid collisions, for every packet they send. I have seen this in the real world--specifically with Orinoco 802.11b cards in ad hoc mode. (I'm talking specifically about the "pseudo-IBSS" mode, where the nodes are truly peer-to-peer.) When the network is lightly loaded, the rebroadcasts (and subsequent replies) are highly synchronized and are extremely likely to collide unless additional jitter is added. I haven't looked at the 802.11 spec in quite a while, but I recall discovering that the backoff mechanism is only enabled _after_ contention has been discovered. If the cards aren't already in contention mode (from previous traffic), they will just do the usual collision avoidance: they will all do a carrier sense (synchronized), see no traffic (synchronized), and transmit their packets (synchronized-------->COLLISION!). That is, if they don't sense traffic and aren't already in contention mode, they transmit immediately. Note: even if I have misinterpreted the spec (which is easy to do), I did see synchronized retransmissions and corrected them with jitter. Jim -- -------------------------------------------------------------- James T. Kaba Sarnoff Corporation Time flies like an arrow... jkaba@sarnoff.com ...Fruit flies like a banana! 609-734-2246 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 23 13:35:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28683 for ; Tue, 23 Apr 2002 13:35:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15978; Tue, 23 Apr 2002 13:05:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15946 for ; Tue, 23 Apr 2002 13:04:55 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27743 for ; Tue, 23 Apr 2002 13:04:51 -0400 (EDT) Received: from Sior_Panagakhs.cornell.edu (dhcp28-224.ece.cornell.edu [128.84.224.139]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g3NH4p122876; Tue, 23 Apr 2002 13:04:51 -0400 Message-Id: <5.1.0.14.2.20020423125559.00b949c0@memphis.ece.cornell.edu> X-Sender: papadp@memphis.ece.cornell.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 13:06:26 -0400 To: manet@ietf.org From: Panos Papadimitratos Subject: Re: [manet] Re Security considerations in MANET Cc: haas@ece.cornell.edu, Phil Neumiller , Manel Guerrero Zapata , ext Casey Carter , ext Claude Castelluccia , Seung Yi , "Charles E. Perkins" , Pekka Savola In-Reply-To: References: <000901c1ea22$09c90080$6200000a@meshnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA15947 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dear fellow “security enthusiasts”, (:-) a few things I would like to contribute to your interesting discussion: First, it is important to realize that not all security solutions can be applied in all ad hoc networking environments. At one extreme, the conference room resources can use location authentication, i.e., no access constraint other than the mobile device location (e.g., short range IR of RF connectivity). At the other extreme, a MANET of trusted military devices, can be capable to perform expensive cryptographic operations and have all the infrastructure support we can imagine. In short, the interaction between nodes is the one that dictates how to do the trust management. Second, the point of crucial importance for the securing MANET, at least as far as I am concerned, is to make clear distinction between: -Security of the MANET-based application. -Security of the basic networking services. The challenge is exactly to achieve the latter. And, it has to be done for the wide range of network instances between the two above-mentioned extremes. And, it has to be done in a way that “understands” the MANET paradigm, and does not transplant secure Internet routing solutions. This is what seems to be happening with most of the secure routing solutions for MANET, as we explain in: P.Papadimitratos and Z.J. Haas, "Secure Routing for Mobile Ad Hoc Networks," SCS Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31, 2002. The rationale behind the Secure Routing Protocol (SRP) in a few lines is: Even if you have the appropriate distributed CA instantiation (which you can have - see Zhou & Haas), it is not feasible to cryptographically validate every single in-transit control packet, even with the upcoming commercial mobile devices. Even if you have a service- or group- based distribution of credentials, the basic network functionality will not be supported only by your trusted peers. Even if you have a heavy-weight crypto-based solution, how do you deal with a node that does not comply with a protocol? That is, correct operation equals correct connectivity information. And SRP does exactly this, avoiding the pitfall of ‘correct is whatever is cryptographically ok’. (BTW, that’s the main issue in Internet secure routing s well…) For clarifications, or if you want to hear some possible attacks on the discussed protocols (:-), please, don’t hesitate… Cheers, Panos _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue Apr 23 13:35:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28693 for ; Tue, 23 Apr 2002 13:35:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18099 for manet-archive@odin.ietf.org; Tue, 23 Apr 2002 13:35:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15978; Tue, 23 Apr 2002 13:05:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15946 for ; Tue, 23 Apr 2002 13:04:55 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27743 for ; Tue, 23 Apr 2002 13:04:51 -0400 (EDT) Received: from Sior_Panagakhs.cornell.edu (dhcp28-224.ece.cornell.edu [128.84.224.139]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g3NH4p122876; Tue, 23 Apr 2002 13:04:51 -0400 Message-Id: <5.1.0.14.2.20020423125559.00b949c0@memphis.ece.cornell.edu> X-Sender: papadp@memphis.ece.cornell.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 13:06:26 -0400 To: manet@ietf.org From: Panos Papadimitratos Subject: Re: [manet] Re Security considerations in MANET Cc: haas@ece.cornell.edu, Phil Neumiller , Manel Guerrero Zapata , ext Casey Carter , ext Claude Castelluccia , Seung Yi , "Charles E. Perkins" , Pekka Savola In-Reply-To: References: <000901c1ea22$09c90080$6200000a@meshnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA15947 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Dear fellow “security enthusiasts”, (:-) a few things I would like to contribute to your interesting discussion: First, it is important to realize that not all security solutions can be applied in all ad hoc networking environments. At one extreme, the conference room resources can use location authentication, i.e., no access constraint other than the mobile device location (e.g., short range IR of RF connectivity). At the other extreme, a MANET of trusted military devices, can be capable to perform expensive cryptographic operations and have all the infrastructure support we can imagine. In short, the interaction between nodes is the one that dictates how to do the trust management. Second, the point of crucial importance for the securing MANET, at least as far as I am concerned, is to make clear distinction between: -Security of the MANET-based application. -Security of the basic networking services. The challenge is exactly to achieve the latter. And, it has to be done for the wide range of network instances between the two above-mentioned extremes. And, it has to be done in a way that “understands” the MANET paradigm, and does not transplant secure Internet routing solutions. This is what seems to be happening with most of the secure routing solutions for MANET, as we explain in: P.Papadimitratos and Z.J. Haas, "Secure Routing for Mobile Ad Hoc Networks," SCS Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31, 2002. The rationale behind the Secure Routing Protocol (SRP) in a few lines is: Even if you have the appropriate distributed CA instantiation (which you can have - see Zhou & Haas), it is not feasible to cryptographically validate every single in-transit control packet, even with the upcoming commercial mobile devices. Even if you have a service- or group- based distribution of credentials, the basic network functionality will not be supported only by your trusted peers. Even if you have a heavy-weight crypto-based solution, how do you deal with a node that does not comply with a protocol? That is, correct operation equals correct connectivity information. And SRP does exactly this, avoiding the pitfall of ‘correct is whatever is cryptographically ok’. (BTW, that’s the main issue in Internet secure routing s well…) For clarifications, or if you want to hear some possible attacks on the discussed protocols (:-), please, don’t hesitate… Cheers, Panos _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 23 18:35:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08467 for ; Tue, 23 Apr 2002 18:35:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03205; Tue, 23 Apr 2002 18:01:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03119 for ; Tue, 23 Apr 2002 18:00:55 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07813 for ; Tue, 23 Apr 2002 18:00:49 -0400 (EDT) Received: from vagrant.research.telcordia.com (vagrant [192.4.18.172]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g3NM0GG2018133 for ; Tue, 23 Apr 2002 18:00:17 -0400 (EDT) Received: (from rrt@localhost) by vagrant.research.telcordia.com (8.8.8/8.8.8) id SAA22393 for manet@ietf.org; Tue, 23 Apr 2002 18:00:16 -0400 (EDT) From: Rajesh Talpade Message-Id: <200204232200.SAA22393@vagrant.research.telcordia.com> To: manet@ietf.org Date: Tue, 23 Apr 2002 18:00:16 -0400 (EDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Transfer-Encoding: 7bit Subject: [manet] adhoc routing products ? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi This may be slightly off-topic, but I would appreciate learning about COTS equipment supporting adhoc routing protocols currently being pursued in this working group. Thanks. Rajesh. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Tue Apr 23 18:35:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08478 for ; Tue, 23 Apr 2002 18:35:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05365 for manet-archive@odin.ietf.org; Tue, 23 Apr 2002 18:35:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03205; Tue, 23 Apr 2002 18:01:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03119 for ; Tue, 23 Apr 2002 18:00:55 -0400 (EDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07813 for ; Tue, 23 Apr 2002 18:00:49 -0400 (EDT) Received: from vagrant.research.telcordia.com (vagrant [192.4.18.172]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g3NM0GG2018133 for ; Tue, 23 Apr 2002 18:00:17 -0400 (EDT) Received: (from rrt@localhost) by vagrant.research.telcordia.com (8.8.8/8.8.8) id SAA22393 for manet@ietf.org; Tue, 23 Apr 2002 18:00:16 -0400 (EDT) From: Rajesh Talpade Message-Id: <200204232200.SAA22393@vagrant.research.telcordia.com> To: manet@ietf.org Date: Tue, 23 Apr 2002 18:00:16 -0400 (EDT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Transfer-Encoding: 7bit Subject: [manet] adhoc routing products ? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi This may be slightly off-topic, but I would appreciate learning about COTS equipment supporting adhoc routing protocols currently being pursued in this working group. Thanks. Rajesh. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 24 04:09:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27047 for ; Wed, 24 Apr 2002 04:09:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10267; Wed, 24 Apr 2002 03:45:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10236 for ; Wed, 24 Apr 2002 03:45:24 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26625 for ; Wed, 24 Apr 2002 03:45:21 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3O7gsR01876; Wed, 24 Apr 2002 09:42:54 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3O7grX03489; Wed, 24 Apr 2002 09:42:53 +0200 (MEST) Message-ID: <000801c1eb64$013b3940$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: , "Panos Papadimitratos" Cc: , "Phil Neumiller" , "Manel Guerrero Zapata" , "ext Casey Carter" , "Seung Yi" , "Charles E. Perkins" , "Pekka Savola" Subject: Re: [manet] Re Security considerations in MANET Date: Wed, 24 Apr 2002 09:45:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello Panos, -----Message d'origine----- De : Panos Papadimitratos À : manet@ietf.org Cc : haas@ece.cornell.edu ; Phil Neumiller ; Manel Guerrero Zapata ; ext Casey Carter ; ext Claude Castelluccia ; Seung Yi ; Charles E. Perkins ; Pekka Savola Date : mardi 23 avril 2002 19:05 Objet : Re: [manet] Re Security considerations in MANET >Dear fellow “security enthusiasts”, (:-) > >a few things I would like to contribute to your interesting discussion: > >First, it is important to realize that not all security solutions can be >applied in all ad hoc networking environments. At one extreme, the >conference room resources can use location authentication, i.e., no access >constraint other than the mobile device location (e.g., short range IR of i am not convinced that this is enough...sometimes you don't want everbody in the conference room being able to play with your presentation ;-) >RF connectivity). At the other extreme, a MANET of trusted military >devices, can be capable to perform expensive cryptographic operations and >have all the infrastructure support we can imagine. In short, the >interaction between nodes is the one that dictates how to do the trust >management. > >Second, the point of crucial importance for the securing MANET, at least as >far as I am concerned, is to make clear distinction between: >-Security of the MANET-based application. >-Security of the basic networking services. I do not quite agree with this distinction: the security of the MANET-based application *depends* on the security of the basic networking services as least as DoS attacks are concerned... If the networking services can not protect you from DoS attacks there is not much you can do at the application level...isn't it? >The challenge is exactly to achieve the latter. And, it has to be done for >the wide range of network instances between the two above-mentioned >extremes. And, it has to be done in a way that “understands” the MANET >paradigm, and does not transplant secure Internet routing solutions. i agree. >This is what seems to be happening with most of the secure routing >solutions for MANET, as we explain in: > >P.Papadimitratos and Z.J. Haas, "Secure Routing for Mobile Ad Hoc >Networks," SCS Communication Networks and Distributed Systems Modeling and >Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31, 2002. > >The rationale behind the Secure Routing Protocol (SRP) in a few lines is: > >Even if you have the appropriate distributed CA instantiation (which you >can have - see Zhou & Haas), it is not feasible to cryptographically >validate every single in-transit control packet, even with the upcoming >commercial mobile devices. > this might be true but i am not convinced about that statement yet especially if you consider new low-cost authentication schemes such as Biba, Tesla and others... probably some more work is required in this area .... >Even if you have a service- or group- based distribution of credentials, >the basic network functionality will not be supported only by your trusted >peers. > >Even if you have a heavy-weight crypto-based solution, how do you deal with >a node that does not comply with a protocol? That is, correct operation >equals correct connectivity information. And SRP does exactly this, >avoiding the pitfall of ‘correct is whatever is cryptographically ok’. >(BTW, that’s the main issue in Internet secure routing s well…) that's right : crypto is not enough but helps... >For clarifications, or if you want to hear some possible attacks on the >discussed protocols (:-), please, don’t hesitate… i'd like very much to hear about those attacks... thanks, regards, Claude. >Cheers, > >Panos > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Apr 24 04:09:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27058 for ; Wed, 24 Apr 2002 04:09:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11831 for manet-archive@odin.ietf.org; Wed, 24 Apr 2002 04:09:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10267; Wed, 24 Apr 2002 03:45:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10236 for ; Wed, 24 Apr 2002 03:45:24 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26625 for ; Wed, 24 Apr 2002 03:45:21 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3O7gsR01876; Wed, 24 Apr 2002 09:42:54 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3O7grX03489; Wed, 24 Apr 2002 09:42:53 +0200 (MEST) Message-ID: <000801c1eb64$013b3940$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: , "Panos Papadimitratos" Cc: , "Phil Neumiller" , "Manel Guerrero Zapata" , "ext Casey Carter" , "Seung Yi" , "Charles E. Perkins" , "Pekka Savola" Subject: Re: [manet] Re Security considerations in MANET Date: Wed, 24 Apr 2002 09:45:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello Panos, -----Message d'origine----- De : Panos Papadimitratos À : manet@ietf.org Cc : haas@ece.cornell.edu ; Phil Neumiller ; Manel Guerrero Zapata ; ext Casey Carter ; ext Claude Castelluccia ; Seung Yi ; Charles E. Perkins ; Pekka Savola Date : mardi 23 avril 2002 19:05 Objet : Re: [manet] Re Security considerations in MANET >Dear fellow “security enthusiasts”, (:-) > >a few things I would like to contribute to your interesting discussion: > >First, it is important to realize that not all security solutions can be >applied in all ad hoc networking environments. At one extreme, the >conference room resources can use location authentication, i.e., no access >constraint other than the mobile device location (e.g., short range IR of i am not convinced that this is enough...sometimes you don't want everbody in the conference room being able to play with your presentation ;-) >RF connectivity). At the other extreme, a MANET of trusted military >devices, can be capable to perform expensive cryptographic operations and >have all the infrastructure support we can imagine. In short, the >interaction between nodes is the one that dictates how to do the trust >management. > >Second, the point of crucial importance for the securing MANET, at least as >far as I am concerned, is to make clear distinction between: >-Security of the MANET-based application. >-Security of the basic networking services. I do not quite agree with this distinction: the security of the MANET-based application *depends* on the security of the basic networking services as least as DoS attacks are concerned... If the networking services can not protect you from DoS attacks there is not much you can do at the application level...isn't it? >The challenge is exactly to achieve the latter. And, it has to be done for >the wide range of network instances between the two above-mentioned >extremes. And, it has to be done in a way that “understands” the MANET >paradigm, and does not transplant secure Internet routing solutions. i agree. >This is what seems to be happening with most of the secure routing >solutions for MANET, as we explain in: > >P.Papadimitratos and Z.J. Haas, "Secure Routing for Mobile Ad Hoc >Networks," SCS Communication Networks and Distributed Systems Modeling and >Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31, 2002. > >The rationale behind the Secure Routing Protocol (SRP) in a few lines is: > >Even if you have the appropriate distributed CA instantiation (which you >can have - see Zhou & Haas), it is not feasible to cryptographically >validate every single in-transit control packet, even with the upcoming >commercial mobile devices. > this might be true but i am not convinced about that statement yet especially if you consider new low-cost authentication schemes such as Biba, Tesla and others... probably some more work is required in this area .... >Even if you have a service- or group- based distribution of credentials, >the basic network functionality will not be supported only by your trusted >peers. > >Even if you have a heavy-weight crypto-based solution, how do you deal with >a node that does not comply with a protocol? That is, correct operation >equals correct connectivity information. And SRP does exactly this, >avoiding the pitfall of ‘correct is whatever is cryptographically ok’. >(BTW, that’s the main issue in Internet secure routing s well…) that's right : crypto is not enough but helps... >For clarifications, or if you want to hear some possible attacks on the >discussed protocols (:-), please, don’t hesitate… i'd like very much to hear about those attacks... thanks, regards, Claude. >Cheers, > >Panos > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 24 09:05:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02670 for ; Wed, 24 Apr 2002 09:05:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26226; Wed, 24 Apr 2002 08:38:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26180 for ; Wed, 24 Apr 2002 08:37:53 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01687 for ; Wed, 24 Apr 2002 08:37:48 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3OCZxR12364; Wed, 24 Apr 2002 14:35:59 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3OCZwX22112; Wed, 24 Apr 2002 14:35:58 +0200 (MEST) Message-ID: <006601c1eb8c$f279c560$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "Phil Neumiller" , "Manel Guerrero Zapata" , "ext Casey Carter" Cc: , "Seung Yi" Date: Wed, 24 Apr 2002 14:38:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 7bit Subject: [manet] Re: Re Security considerations in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit -----Message d'origine----- >D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. Hello Phil, We've actually found one;-) Our proposal focuses on AODV but actually could be used with any other MANET protocol. It is basically a scheme to establish an authenticated secret key between two hosts that does not have access to an infrastructure (PKI, or others...). Protecting AODV against Impersonation attacks (or how to establish a secure tunnel between 2 hosts on a MANET) ============================================= Claude Castelluccia and Gabriel Montenegro. April 2002. 1 *Problem statement: -------------------- - How to protect AODV from impersonation attack: i.e. how can host H1 that is communicating with H2 over an insecure Adhoc network that uses AODV have the assurance that when they receive packets from H2 they actually come from H2 and not for an impersonator even if the routing insfracture/protocol is insecure... In current AODV, H1 establishes a route to H2 by sending a RREQ to H2 that will then replies with a RREP. But actually anyone (a malicious host on the path or not) can reply to the RREQ and redirect the packets addressed to H2 to him (eventhough H1 thinks it is communicating with H2). Furthermore if H1 receives several RREP, how can it select the right one? The basic solution is: - the node uses a CGA (Crypto Generated Addresses) or CGI (Crypto. Generated Identifiers) [SUCV,CAM] as address (a CGI is a identifier is defined as a hash of a public key). - whenever a host H2 sends packets to H1, it must disclosed its public key and it musts signed its packets (by setting the mutable field ie hop counts to zero or as specified in sAODV) with its CGA private key... As a result, the destination, H1, can verified that the packets have actually been sent by H2 . This is achieved by verifying that the CGA ou CGI was generated from the public key and that the signatures are valid. This solution is not very efficient and requires one signature generation/ verification per packets. This is definetly not acceptable. A Better solution is: - H1 and H2 established a secure channel (tunnel) and then encrypt or authenticated (with a HMAC) their packets with the symetric key that was generated. Therefore the problem can now be stated as follows: - how can two hosts H1 and H2, identified by their address, establish a secure (IPSec) tunnel over an insecure adhoc network that uses AODV. 2 * Proposal description: --------------------------------- 2.1 + requirements: - H1 and H2 uses CGA or CGI (CGI_H1 and CGI_H2) i.e CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) or 128 (for CGI). and CGI_H2 = hashx(PublicKey_H2, counter_H2) Note: it is not clear today if a IPv6 address is really needed in MANET. If this is the case then CGA must be used otherwise CGI (128 bit identifier) is better since they are cryptographically stronger. 2.2 + protocol description: - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, g^x.modp (i.e. a DH value) and an nonce N1 (RREQ id could be used instead) , and signs the whole message with its PrivateKey_H1. The RREQ must have the newly defined D flag (see Section 2.3). set. This flag specifies that only H2 is allowed to reply to this RREQ with a RREP. - When H2 receives the RREQ, it verifies that H1 owns its address and replies with a RREP that contains PublicKey_H2, counter_H2, g^y. modp, N1 (i.e. RREQ id), and signs the whole message with its PrivateKey_H2. H2 also derives the secret key, Ke that would be used to establish a secure channel between CGI_H1 and CGI_H2. For example, Ke could be defined as follows: Ke = hash_x(g^xy mod p) (where x is the size of the generated key). - When H2 receives RREP, it verifies that H2 owns its address and derives the secret Key, Ke. From then on, the "standard" AODV protocol is used until the SA needs to be refreshed. As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel (i.e. an authenticated symetric key) is established between CGI_H1 and CGI_H2 that can be use to secure (authenticate + encrypt) control or data traffic. 2.3 + the "D" flag -The D (Destination) flag has been added in the RREQ because in the above protocol, when H1 sends a RREQ, it wants to make sure that it gets a reply from H2 itself and not from an intermediate host that has an active route to H2 (as this is possible in current AODV draft). In fact, RREQ and RREP carries information (DH exponentiation value) that is used to establish a symetric key between H1 and H2. If an intermediate node replies, H2 won't be able to derive the symetric key and the protocol will fail. Route Request (RREQ) Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G|D| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Flooded Packet ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Destination IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 + Conclusion -------------- We propose a protocol that allows two hosts H1 and H2 to establish a secure tunnel over an insecure Adhoc network that uses AODV. Our solution relies on CGI and the definition of a new flag (the D flag) in the RREQ packet format. Our proposal does not use any certificate (and therefore PKI) and does not require any TTP support. It is therefore well adapted to adhoc environment and very scalable. Note that since the routing infrascture is insecure, our proposol does not protect H1 and H2 against DoS attacks. In fact, in our proposal, as in AODV, an attacker can easily redirect/hijacked the packets from H1 or H2. Protecting from these DoS attacks is a different (or very complex) issue that can potentially solved by securing the routing infrastructure or by using schemes that use redundancy (i.e several paths). However, even under DoS attacks, when H1 (and resp. H2) receives a packet from H2 (resp. H1) it has the assurance that it was not sent by an impersonator. That was the goal of our work. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Apr 24 09:05:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02684 for ; Wed, 24 Apr 2002 09:05:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28317 for manet-archive@odin.ietf.org; Wed, 24 Apr 2002 09:05:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26226; Wed, 24 Apr 2002 08:38:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26180 for ; Wed, 24 Apr 2002 08:37:53 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01687 for ; Wed, 24 Apr 2002 08:37:48 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3OCZxR12364; Wed, 24 Apr 2002 14:35:59 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3OCZwX22112; Wed, 24 Apr 2002 14:35:58 +0200 (MEST) Message-ID: <006601c1eb8c$f279c560$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "Phil Neumiller" , "Manel Guerrero Zapata" , "ext Casey Carter" Cc: , "Seung Yi" Date: Wed, 24 Apr 2002 14:38:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 7bit Subject: [manet] Re: Re Security considerations in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit -----Message d'origine----- >D). In the case that the network has no fixed infrastructure, i.e. a pure ad hoc network > a good solution for key management does not yet exist. Please find one. Hello Phil, We've actually found one;-) Our proposal focuses on AODV but actually could be used with any other MANET protocol. It is basically a scheme to establish an authenticated secret key between two hosts that does not have access to an infrastructure (PKI, or others...). Protecting AODV against Impersonation attacks (or how to establish a secure tunnel between 2 hosts on a MANET) ============================================= Claude Castelluccia and Gabriel Montenegro. April 2002. 1 *Problem statement: -------------------- - How to protect AODV from impersonation attack: i.e. how can host H1 that is communicating with H2 over an insecure Adhoc network that uses AODV have the assurance that when they receive packets from H2 they actually come from H2 and not for an impersonator even if the routing insfracture/protocol is insecure... In current AODV, H1 establishes a route to H2 by sending a RREQ to H2 that will then replies with a RREP. But actually anyone (a malicious host on the path or not) can reply to the RREQ and redirect the packets addressed to H2 to him (eventhough H1 thinks it is communicating with H2). Furthermore if H1 receives several RREP, how can it select the right one? The basic solution is: - the node uses a CGA (Crypto Generated Addresses) or CGI (Crypto. Generated Identifiers) [SUCV,CAM] as address (a CGI is a identifier is defined as a hash of a public key). - whenever a host H2 sends packets to H1, it must disclosed its public key and it musts signed its packets (by setting the mutable field ie hop counts to zero or as specified in sAODV) with its CGA private key... As a result, the destination, H1, can verified that the packets have actually been sent by H2 . This is achieved by verifying that the CGA ou CGI was generated from the public key and that the signatures are valid. This solution is not very efficient and requires one signature generation/ verification per packets. This is definetly not acceptable. A Better solution is: - H1 and H2 established a secure channel (tunnel) and then encrypt or authenticated (with a HMAC) their packets with the symetric key that was generated. Therefore the problem can now be stated as follows: - how can two hosts H1 and H2, identified by their address, establish a secure (IPSec) tunnel over an insecure adhoc network that uses AODV. 2 * Proposal description: --------------------------------- 2.1 + requirements: - H1 and H2 uses CGA or CGI (CGI_H1 and CGI_H2) i.e CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) or 128 (for CGI). and CGI_H2 = hashx(PublicKey_H2, counter_H2) Note: it is not clear today if a IPv6 address is really needed in MANET. If this is the case then CGA must be used otherwise CGI (128 bit identifier) is better since they are cryptographically stronger. 2.2 + protocol description: - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, g^x.modp (i.e. a DH value) and an nonce N1 (RREQ id could be used instead) , and signs the whole message with its PrivateKey_H1. The RREQ must have the newly defined D flag (see Section 2.3). set. This flag specifies that only H2 is allowed to reply to this RREQ with a RREP. - When H2 receives the RREQ, it verifies that H1 owns its address and replies with a RREP that contains PublicKey_H2, counter_H2, g^y. modp, N1 (i.e. RREQ id), and signs the whole message with its PrivateKey_H2. H2 also derives the secret key, Ke that would be used to establish a secure channel between CGI_H1 and CGI_H2. For example, Ke could be defined as follows: Ke = hash_x(g^xy mod p) (where x is the size of the generated key). - When H2 receives RREP, it verifies that H2 owns its address and derives the secret Key, Ke. From then on, the "standard" AODV protocol is used until the SA needs to be refreshed. As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel (i.e. an authenticated symetric key) is established between CGI_H1 and CGI_H2 that can be use to secure (authenticate + encrypt) control or data traffic. 2.3 + the "D" flag -The D (Destination) flag has been added in the RREQ because in the above protocol, when H1 sends a RREQ, it wants to make sure that it gets a reply from H2 itself and not from an intermediate host that has an active route to H2 (as this is possible in current AODV draft). In fact, RREQ and RREP carries information (DH exponentiation value) that is used to establish a symetric key between H1 and H2. If an intermediate node replies, H2 won't be able to derive the symetric key and the protocol will fail. Route Request (RREQ) Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G|D| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Flooded Packet ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Destination IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 + Conclusion -------------- We propose a protocol that allows two hosts H1 and H2 to establish a secure tunnel over an insecure Adhoc network that uses AODV. Our solution relies on CGI and the definition of a new flag (the D flag) in the RREQ packet format. Our proposal does not use any certificate (and therefore PKI) and does not require any TTP support. It is therefore well adapted to adhoc environment and very scalable. Note that since the routing infrascture is insecure, our proposol does not protect H1 and H2 against DoS attacks. In fact, in our proposal, as in AODV, an attacker can easily redirect/hijacked the packets from H1 or H2. Protecting from these DoS attacks is a different (or very complex) issue that can potentially solved by securing the routing infrastructure or by using schemes that use redundancy (i.e several paths). However, even under DoS attacks, when H1 (and resp. H2) receives a packet from H2 (resp. H1) it has the assurance that it was not sent by an impersonator. That was the goal of our work. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 24 09:55:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06505 for ; Wed, 24 Apr 2002 09:55:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29571; Wed, 24 Apr 2002 09:29:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29538 for ; Wed, 24 Apr 2002 09:29:34 -0400 (EDT) Received: from urano.cdtn.br (urano.cdtn.br [200.17.181.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03642 for ; Wed, 24 Apr 2002 09:29:30 -0400 (EDT) Received: from perseus (perseus.cdtn.br [200.17.181.136]) by urano.cdtn.br (8.10.0/) with SMTP id g3ODVR329801 for ; Wed, 24 Apr 2002 10:31:27 -0300 (EST) Message-ID: <003101c1eb94$a156ec00$88b511c8@cdtn.br> From: "Marcos Flavio de Oliveira" To: Date: Wed, 24 Apr 2002 10:33:33 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C1EB7B.7BA4FEC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] Bluetooth and Energy Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C1EB7B.7BA4FEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I need simulate Bluetooth. Does ns2 include an energy model? Are there any simulator that include energy in Bluetooth? []s ------=_NextPart_000_002E_01C1EB7B.7BA4FEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
    I need=20 simulate Bluetooth.
    Does ns2 = include an energy=20 model?
    Are there any = simulator that=20 include energy in Bluetooth?
 
[]s
------=_NextPart_000_002E_01C1EB7B.7BA4FEC0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Apr 24 09:55:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06515 for ; Wed, 24 Apr 2002 09:55:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA01704 for manet-archive@odin.ietf.org; Wed, 24 Apr 2002 09:55:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29571; Wed, 24 Apr 2002 09:29:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29538 for ; Wed, 24 Apr 2002 09:29:34 -0400 (EDT) Received: from urano.cdtn.br (urano.cdtn.br [200.17.181.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03642 for ; Wed, 24 Apr 2002 09:29:30 -0400 (EDT) Received: from perseus (perseus.cdtn.br [200.17.181.136]) by urano.cdtn.br (8.10.0/) with SMTP id g3ODVR329801 for ; Wed, 24 Apr 2002 10:31:27 -0300 (EST) Message-ID: <003101c1eb94$a156ec00$88b511c8@cdtn.br> From: "Marcos Flavio de Oliveira" To: Date: Wed, 24 Apr 2002 10:33:33 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C1EB7B.7BA4FEC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] Bluetooth and Energy Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C1EB7B.7BA4FEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I need simulate Bluetooth. Does ns2 include an energy model? Are there any simulator that include energy in Bluetooth? []s ------=_NextPart_000_002E_01C1EB7B.7BA4FEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
    I need=20 simulate Bluetooth.
    Does ns2 = include an energy=20 model?
    Are there any = simulator that=20 include energy in Bluetooth?
 
[]s
------=_NextPart_000_002E_01C1EB7B.7BA4FEC0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 24 10:36:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10579 for ; Wed, 24 Apr 2002 10:36:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02657; Wed, 24 Apr 2002 10:07:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02626 for ; Wed, 24 Apr 2002 10:07:44 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07874 for ; Wed, 24 Apr 2002 10:07:40 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3OE5qR15968; Wed, 24 Apr 2002 16:05:52 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3OE5sX07454; Wed, 24 Apr 2002 16:05:54 +0200 (MEST) Message-ID: <004001c1eb99$80c67d20$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "Claude Castelluccia" , "Phil Neumiller" , "Manel Guerrero Zapata" , "ext Casey Carter" Cc: , "Seung Yi" Subject: Re: [manet] Re: Re Security considerations in MANET Date: Wed, 24 Apr 2002 16:08:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit -----Message d'origine----- De : Claude Castelluccia À : Phil Neumiller ; Manel Guerrero Zapata ; ext Casey Carter Cc : manet@ietf.org ; Seung Yi Date : mercredi 24 avril 2002 14:38 Objet : [manet] Re: Re Security considerations in MANET > >-----Message d'origine----- >>D). In the case that the network has no fixed infrastructure, i.e. a pure >ad hoc network >> a good solution for key management does not yet exist. Please find >one. > > >Hello Phil, > >We've actually found one;-) > >Our proposal focuses on AODV but >actually could be used with any other MANET protocol. It is >basically a scheme to establish an authenticated secret key between two >hosts that does not have access to an infrastructure (PKI, or others...). > > >Protecting AODV against Impersonation attacks (or how >to establish a secure tunnel between 2 hosts on a MANET) >============================================= >Claude Castelluccia and Gabriel Montenegro. >April 2002. oups, i have just realized that i've sent an old (very drafty) version of the draft. Please ignore my previous email and consider the draft attached to this email...sorry about that... regards, Claude. PS: FYI i'll be travelling for the next 10 days and not sure whether i'll have an Internet access...but Gabriel (my co-author) will reply to your comments (or i'll reply when i'll be back...) PS: BTW we plan to submit this draft to the AODV workshop in Lausanne (after MobiHoc) the submission deadline is April 30th...it would be great to have your comments before this deadline to possibly integrate them in the draft...thanks in advance. Claude. ----------8><---------------------------8><-------------------------------- Protecting AODV against Impersonation attacks (or how to establish a secure tunnel between 2 hosts on a MANET) ====================================================== Claude Castelluccia and Gabriel Montenegro. April 2002. 1 *Problem statement: -------------------- - How to protect AODV from the impersonation attack: i.e. how can a host H1 that is communicating with a host H2 over an insecure Adhoc network that uses AODV has the assurance that when it receives packets from H2 they actually come from H2 and not from an impersonator even if the routing insfracture/protocol is insecure... In current AODV [AODV,AODV6], H1 establishes a route to H2 by sending a RREQ message to H2 that will then replies with a RREP. But actually anyone (ecen a malicious host, on the path or not) can reply to the RREQ and redirect the packets addressed to H2 to him (eventhough H1 thinks it is communicating with H2). Furthermore if H1 receives several RREP, how can it select the right one? The basic solution is: - the node H2 uses a CGA (Crypto Generated Address) or CGI (Crypto. Generated Identifier) [SUCV,CAM] as address (a CGI is an identifier that is defined as the hash of a public key). - whenever a H2 sends packets to H1, it must disclosed its public key and sign its packets (by setting the mutable fields (ie hop counts) to zero or as specified in sAODV [SAODV]) with its CGA private key... As a result, the destination, H1, can verify that the packets have actually been sent by H2 . This is achieved by verifying that the CGA or CGI was generated from the public key and that the signatures are valid. This solution solves the problem but is not very efficient because it requires one signature generation/verification per packets. This is not acceptable. A Better solution is: - H1 and H2 establish a secure channel (tunnel) and then encrypt or authenticate (with a HMAC) their packets with the symetric key that was generated. Therefore the problem can now be stated as follows: - how can two hosts H1 and H2, identified by their address, establish a secure (IPSec) tunnel over an insecure adhoc network that uses AODV. 2 * Proposal description: --------------------------------- 2.1 + requirements: Both H1 and H2 define a CGA or CGI, respectively CGI_H1 and CGI_H2 as follows: -CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) or 128 (for CGI). -CGI_H2 = hashx(PublicKey_H2, counter_H2) where PublicKey_H1 (resp. PublicKey_H2) is a public key associated with H1 (resp. H2). Note: it is not clear today if a IPv6 address is really needed in MANET. If this is the case then CGA must be used otherwise CGI (128 bit identifier) is better since they are cryptographically stronger. 2.2 + protocol description: - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, g^x.modp (i.e. a DH exponentiation value) and an nonce N1 (RREQ id could be used instead), and signs the whole message with its PrivateKey_H1. The RREQ must have the newly defined D flag (see Section 2.3). set. This flag specifies that only H2 is allowed to reply to this RREQ. - When H2 receives the RREQ, it verifies that H1 owns its address (i.e. CGI_H2 was generated from PublicKey_H2 and the signature is valid). It then replies with a RREP that contains PublicKey_H2, counter_H2, g^y. modp, N1 (i.e. RREQid), and signs the whole message with its PrivateKey_H2. H2 also derives the secret key, Ke that would be used to establish a secure channel between CGI_H1 and CGI_H2. For example, Ke could be defined as follows: Ke = hash_x(g^xy mod p) (where x is the size of the generated key). - When H1 receives RREP, it verifies that H2 owns its address and derives the secret Key, Ke. From then on, the "standard" AODV protocol is used until the SA needs to be refreshed. As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel (i.e. an authenticated symetric key) is established between CGI_H1 and CGI_H2 that can be used to secure (authenticate + encrypt) control or data traffic. 2.3 + the "D" flag -The D (Destination) flag has been added to the RREQ packet format because in our proposal, when H1 sends a RREQ it wants to make sure that it gets a reply from H2 itself and not from an intermediate host that may have an active route to H2 (as this is possible in current AODV draft). In fact, RREQ and RREP carry information (DH exponentiation value) that are used to establish the symetric key between H1 and H2. If an intermediate node replies, H2 won't be able to derive the symetric key and the protocol will fail. Route Request (RREQ) Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G|D| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Flooded Packet ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Destination IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 + Conclusion -------------- We propose a protocol that allows two random hosts H1 and H2 to establish a secure tunnel over an insecure Adhoc network that uses AODV. Our solution relies on CGI and the definition of a new flag (the D flag) in the RREQ packet format. Our proposal does not use any certificate (and therefore PKI) and does not require any TTP support. It is therefore well adapted to adhoc environments and very scalable. Note that since the routing infrasstructure is insecure, our proposol does not protect H1 and H2 against DoS attacks. In fact, in our proposal, as in AODV, an attacker can easily redirect/hijacked the packets from H1 or H2. Protecting from these DoS attacks is a different (or very complex) issue that can potentially solved by securing the routing infrastructure or by using schemes that use redundancy (i.e several paths). However, even under DoS attacks, whenever H1 (and resp. H2) receives a packet from H2 (resp. H1) it has the assurance that it was not sent by an impersonator. That is the goal of our proposal. References: ---------- [AODV] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc On Demand Distance Vector (AODV) Routing, draft-ietf-manet-aodv-10.txt, March 2002. [AODV6] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc On Demand Distance Vector (AODV) Routing for IPv6, draft-ietf-manet-aodv6-01.txt, March 2002. [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 (CAM)", ACM Computer Communication Review, April 2001. [SAODV] Manel Zapata, Secure Ad hoc On-Demand Vector (SAODV) Routing, draft-guerrero-manet-saodv-00.txt, August 2001. [SUCV] Gabriel Montenegro and Claude Castelluccia, "Statistical Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses", in NDSS02, February 2002. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Apr 24 10:36:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10597 for ; Wed, 24 Apr 2002 10:36:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04526 for manet-archive@odin.ietf.org; Wed, 24 Apr 2002 10:36:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02657; Wed, 24 Apr 2002 10:07:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02626 for ; Wed, 24 Apr 2002 10:07:44 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07874 for ; Wed, 24 Apr 2002 10:07:40 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3OE5qR15968; Wed, 24 Apr 2002 16:05:52 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3OE5sX07454; Wed, 24 Apr 2002 16:05:54 +0200 (MEST) Message-ID: <004001c1eb99$80c67d20$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "Claude Castelluccia" , "Phil Neumiller" , "Manel Guerrero Zapata" , "ext Casey Carter" Cc: , "Seung Yi" Subject: Re: [manet] Re: Re Security considerations in MANET Date: Wed, 24 Apr 2002 16:08:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit -----Message d'origine----- De : Claude Castelluccia À : Phil Neumiller ; Manel Guerrero Zapata ; ext Casey Carter Cc : manet@ietf.org ; Seung Yi Date : mercredi 24 avril 2002 14:38 Objet : [manet] Re: Re Security considerations in MANET > >-----Message d'origine----- >>D). In the case that the network has no fixed infrastructure, i.e. a pure >ad hoc network >> a good solution for key management does not yet exist. Please find >one. > > >Hello Phil, > >We've actually found one;-) > >Our proposal focuses on AODV but >actually could be used with any other MANET protocol. It is >basically a scheme to establish an authenticated secret key between two >hosts that does not have access to an infrastructure (PKI, or others...). > > >Protecting AODV against Impersonation attacks (or how >to establish a secure tunnel between 2 hosts on a MANET) >============================================= >Claude Castelluccia and Gabriel Montenegro. >April 2002. oups, i have just realized that i've sent an old (very drafty) version of the draft. Please ignore my previous email and consider the draft attached to this email...sorry about that... regards, Claude. PS: FYI i'll be travelling for the next 10 days and not sure whether i'll have an Internet access...but Gabriel (my co-author) will reply to your comments (or i'll reply when i'll be back...) PS: BTW we plan to submit this draft to the AODV workshop in Lausanne (after MobiHoc) the submission deadline is April 30th...it would be great to have your comments before this deadline to possibly integrate them in the draft...thanks in advance. Claude. ----------8><---------------------------8><-------------------------------- Protecting AODV against Impersonation attacks (or how to establish a secure tunnel between 2 hosts on a MANET) ====================================================== Claude Castelluccia and Gabriel Montenegro. April 2002. 1 *Problem statement: -------------------- - How to protect AODV from the impersonation attack: i.e. how can a host H1 that is communicating with a host H2 over an insecure Adhoc network that uses AODV has the assurance that when it receives packets from H2 they actually come from H2 and not from an impersonator even if the routing insfracture/protocol is insecure... In current AODV [AODV,AODV6], H1 establishes a route to H2 by sending a RREQ message to H2 that will then replies with a RREP. But actually anyone (ecen a malicious host, on the path or not) can reply to the RREQ and redirect the packets addressed to H2 to him (eventhough H1 thinks it is communicating with H2). Furthermore if H1 receives several RREP, how can it select the right one? The basic solution is: - the node H2 uses a CGA (Crypto Generated Address) or CGI (Crypto. Generated Identifier) [SUCV,CAM] as address (a CGI is an identifier that is defined as the hash of a public key). - whenever a H2 sends packets to H1, it must disclosed its public key and sign its packets (by setting the mutable fields (ie hop counts) to zero or as specified in sAODV [SAODV]) with its CGA private key... As a result, the destination, H1, can verify that the packets have actually been sent by H2 . This is achieved by verifying that the CGA or CGI was generated from the public key and that the signatures are valid. This solution solves the problem but is not very efficient because it requires one signature generation/verification per packets. This is not acceptable. A Better solution is: - H1 and H2 establish a secure channel (tunnel) and then encrypt or authenticate (with a HMAC) their packets with the symetric key that was generated. Therefore the problem can now be stated as follows: - how can two hosts H1 and H2, identified by their address, establish a secure (IPSec) tunnel over an insecure adhoc network that uses AODV. 2 * Proposal description: --------------------------------- 2.1 + requirements: Both H1 and H2 define a CGA or CGI, respectively CGI_H1 and CGI_H2 as follows: -CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) or 128 (for CGI). -CGI_H2 = hashx(PublicKey_H2, counter_H2) where PublicKey_H1 (resp. PublicKey_H2) is a public key associated with H1 (resp. H2). Note: it is not clear today if a IPv6 address is really needed in MANET. If this is the case then CGA must be used otherwise CGI (128 bit identifier) is better since they are cryptographically stronger. 2.2 + protocol description: - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, g^x.modp (i.e. a DH exponentiation value) and an nonce N1 (RREQ id could be used instead), and signs the whole message with its PrivateKey_H1. The RREQ must have the newly defined D flag (see Section 2.3). set. This flag specifies that only H2 is allowed to reply to this RREQ. - When H2 receives the RREQ, it verifies that H1 owns its address (i.e. CGI_H2 was generated from PublicKey_H2 and the signature is valid). It then replies with a RREP that contains PublicKey_H2, counter_H2, g^y. modp, N1 (i.e. RREQid), and signs the whole message with its PrivateKey_H2. H2 also derives the secret key, Ke that would be used to establish a secure channel between CGI_H1 and CGI_H2. For example, Ke could be defined as follows: Ke = hash_x(g^xy mod p) (where x is the size of the generated key). - When H1 receives RREP, it verifies that H2 owns its address and derives the secret Key, Ke. From then on, the "standard" AODV protocol is used until the SA needs to be refreshed. As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel (i.e. an authenticated symetric key) is established between CGI_H1 and CGI_H2 that can be used to secure (authenticate + encrypt) control or data traffic. 2.3 + the "D" flag -The D (Destination) flag has been added to the RREQ packet format because in our proposal, when H1 sends a RREQ it wants to make sure that it gets a reply from H2 itself and not from an intermediate host that may have an active route to H2 (as this is possible in current AODV draft). In fact, RREQ and RREP carry information (DH exponentiation value) that are used to establish the symetric key between H1 and H2. If an intermediate node replies, H2 won't be able to derive the symetric key and the protocol will fail. Route Request (RREQ) Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |J|R|G|D| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Flooded Packet ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Destination IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IP Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 + Conclusion -------------- We propose a protocol that allows two random hosts H1 and H2 to establish a secure tunnel over an insecure Adhoc network that uses AODV. Our solution relies on CGI and the definition of a new flag (the D flag) in the RREQ packet format. Our proposal does not use any certificate (and therefore PKI) and does not require any TTP support. It is therefore well adapted to adhoc environments and very scalable. Note that since the routing infrasstructure is insecure, our proposol does not protect H1 and H2 against DoS attacks. In fact, in our proposal, as in AODV, an attacker can easily redirect/hijacked the packets from H1 or H2. Protecting from these DoS attacks is a different (or very complex) issue that can potentially solved by securing the routing infrastructure or by using schemes that use redundancy (i.e several paths). However, even under DoS attacks, whenever H1 (and resp. H2) receives a packet from H2 (resp. H1) it has the assurance that it was not sent by an impersonator. That is the goal of our proposal. References: ---------- [AODV] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc On Demand Distance Vector (AODV) Routing, draft-ietf-manet-aodv-10.txt, March 2002. [AODV6] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc On Demand Distance Vector (AODV) Routing for IPv6, draft-ietf-manet-aodv6-01.txt, March 2002. [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 (CAM)", ACM Computer Communication Review, April 2001. [SAODV] Manel Zapata, Secure Ad hoc On-Demand Vector (SAODV) Routing, draft-guerrero-manet-saodv-00.txt, August 2001. [SUCV] Gabriel Montenegro and Claude Castelluccia, "Statistical Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses", in NDSS02, February 2002. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 24 11:20:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18246 for ; Wed, 24 Apr 2002 11:20:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06024; Wed, 24 Apr 2002 10:55:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05914 for ; Wed, 24 Apr 2002 10:54:59 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17225 for ; Wed, 24 Apr 2002 10:54:55 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3OEsP121654; Wed, 24 Apr 2002 16:54:25 +0200 (MET DST) Message-ID: <00dd01c1eba2$d7e7b340$3ac033c1@inria.fr> From: "Philippe Jacquet" To: , References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <3CC57A73.A6C4B3E6@sarnoff.com> Subject: Re: [manet] packet rebroadcasts Date: Wed, 24 Apr 2002 17:15:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Jim, I agree with you, jitter is important. The IEEE 802.11 can support some traffic burstiness but it is limited (it prefers poisson traffic). The routing protocol should avoid to stress the MAC protocol with too bursty traffics. Philippe ----- Original Message ----- From: Jim Kaba To: Sent: Tuesday, April 23, 2002 5:14 PM Subject: [manet] packet rebroadcasts > Hi Manel, > This reply is not related to the security discussion (thus, the subject > change). It has to do with the packet rebroadcast comments in the previous > post. > > Manel Guerrero Zapata wrote: > > > > Hi Casey, > > > > Comments bellow. > > > > ext Casey Carter wrote: > > > Manel Guerrero Zapata wrote: > > > > > >> Hi Casey, > > 8<-------------------------------------------------------------------------- - > > > > Although I > > > can't find anything on the subject in the draft, it is well known among > > > implementors of ad hoc routing protocols that immediate rebroadcast of > > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > > broadcasts from multiple nodes cause extremely high contention, and > > > (especially in simulations) lots of collisions.The solution for this > > > problem is for each node to choose a small random backoff timer to > > > better distribute the rebroadcasts. > > > > I thing this is something you find only in the simulation world (that if > > you broadcast a RREQ all your neighbors will rebroadcast it at the very > > same time and all the packets will collide). > > But in the real world, if you use some wireless card they already have > > (like the ethernet cards) this small random backoff, > > to avoid collisions, for every packet they send. > > I have seen this in the real world--specifically with Orinoco 802.11b cards > in ad hoc mode. (I'm talking specifically about the "pseudo-IBSS" mode, > where the nodes are truly peer-to-peer.) When the network is lightly > loaded, the rebroadcasts (and subsequent replies) are highly synchronized > and are extremely likely to collide unless additional jitter is added. > > I haven't looked at the 802.11 spec in quite a while, but I recall > discovering that the backoff mechanism is only enabled _after_ contention > has been discovered. If the cards aren't already in contention mode (from > previous traffic), they will just do the usual collision avoidance: they > will all do a carrier sense (synchronized), see no traffic (synchronized), > and transmit their packets (synchronized-------->COLLISION!). That is, if > they don't sense traffic and aren't already in contention mode, they > transmit immediately. > > Note: even if I have misinterpreted the spec (which is easy to do), I did > see synchronized retransmissions and corrected them with jitter. > > Jim > > > -- > -------------------------------------------------------------- > James T. Kaba > Sarnoff Corporation Time flies like an arrow... > jkaba@sarnoff.com ...Fruit flies like a banana! > 609-734-2246 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Apr 24 11:20:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18259 for ; Wed, 24 Apr 2002 11:20:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07973 for manet-archive@odin.ietf.org; Wed, 24 Apr 2002 11:20:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06024; Wed, 24 Apr 2002 10:55:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05914 for ; Wed, 24 Apr 2002 10:54:59 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17225 for ; Wed, 24 Apr 2002 10:54:55 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3OEsP121654; Wed, 24 Apr 2002 16:54:25 +0200 (MET DST) Message-ID: <00dd01c1eba2$d7e7b340$3ac033c1@inria.fr> From: "Philippe Jacquet" To: , References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <3CC57A73.A6C4B3E6@sarnoff.com> Subject: Re: [manet] packet rebroadcasts Date: Wed, 24 Apr 2002 17:15:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Jim, I agree with you, jitter is important. The IEEE 802.11 can support some traffic burstiness but it is limited (it prefers poisson traffic). The routing protocol should avoid to stress the MAC protocol with too bursty traffics. Philippe ----- Original Message ----- From: Jim Kaba To: Sent: Tuesday, April 23, 2002 5:14 PM Subject: [manet] packet rebroadcasts > Hi Manel, > This reply is not related to the security discussion (thus, the subject > change). It has to do with the packet rebroadcast comments in the previous > post. > > Manel Guerrero Zapata wrote: > > > > Hi Casey, > > > > Comments bellow. > > > > ext Casey Carter wrote: > > > Manel Guerrero Zapata wrote: > > > > > >> Hi Casey, > > 8<-------------------------------------------------------------------------- - > > > > Although I > > > can't find anything on the subject in the draft, it is well known among > > > implementors of ad hoc routing protocols that immediate rebroadcast of > > > flooded packets (e.g., route requests) is a bad idea: the synchronized > > > broadcasts from multiple nodes cause extremely high contention, and > > > (especially in simulations) lots of collisions.The solution for this > > > problem is for each node to choose a small random backoff timer to > > > better distribute the rebroadcasts. > > > > I thing this is something you find only in the simulation world (that if > > you broadcast a RREQ all your neighbors will rebroadcast it at the very > > same time and all the packets will collide). > > But in the real world, if you use some wireless card they already have > > (like the ethernet cards) this small random backoff, > > to avoid collisions, for every packet they send. > > I have seen this in the real world--specifically with Orinoco 802.11b cards > in ad hoc mode. (I'm talking specifically about the "pseudo-IBSS" mode, > where the nodes are truly peer-to-peer.) When the network is lightly > loaded, the rebroadcasts (and subsequent replies) are highly synchronized > and are extremely likely to collide unless additional jitter is added. > > I haven't looked at the 802.11 spec in quite a while, but I recall > discovering that the backoff mechanism is only enabled _after_ contention > has been discovered. If the cards aren't already in contention mode (from > previous traffic), they will just do the usual collision avoidance: they > will all do a carrier sense (synchronized), see no traffic (synchronized), > and transmit their packets (synchronized-------->COLLISION!). That is, if > they don't sense traffic and aren't already in contention mode, they > transmit immediately. > > Note: even if I have misinterpreted the spec (which is easy to do), I did > see synchronized retransmissions and corrected them with jitter. > > Jim > > > -- > -------------------------------------------------------------- > James T. Kaba > Sarnoff Corporation Time flies like an arrow... > jkaba@sarnoff.com ...Fruit flies like a banana! > 609-734-2246 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 24 12:23:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21378 for ; Wed, 24 Apr 2002 12:23:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10331; Wed, 24 Apr 2002 11:55:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10300 for ; Wed, 24 Apr 2002 11:55:27 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19964 for ; Wed, 24 Apr 2002 11:55:23 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3OFso124532; Wed, 24 Apr 2002 17:54:50 +0200 (MET DST) Message-ID: <00ef01c1ebab$47c4cf60$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Claude Castelluccia" , References: <004001c1eb99$80c67d20$1d1fc7c2@charmette.inrialpes.fr> Subject: Re: [manet] Re: Re Security considerations in MANET Date: Wed, 24 Apr 2002 18:15:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Claude, Nice stuff. I am relatively new in security considerations, sorry if I ask naive questions. Why H1 and H2 must exchange their public keys and signatures in RREQ and RREP messages. It cannot be done in simple data packets after route discovery? I don't see the plus of involving the routing protocol. Philippe ----- Original Message ----- From: Claude Castelluccia To: Claude Castelluccia ; Phil Neumiller ; Manel Guerrero Zapata ; ext Casey Carter Cc: ; Seung Yi Sent: Wednesday, April 24, 2002 4:08 PM Subject: Re: [manet] Re: Re Security considerations in MANET > > -----Message d'origine----- > De : Claude Castelluccia > À : Phil Neumiller ; Manel Guerrero Zapata > ; ext Casey Carter > Cc : manet@ietf.org ; Seung Yi > Date : mercredi 24 avril 2002 14:38 > Objet : [manet] Re: Re Security considerations in MANET > > > > > >-----Message d'origine----- > >>D). In the case that the network has no fixed infrastructure, i.e. a pure > >ad hoc network > >> a good solution for key management does not yet exist. Please find > >one. > > > > > >Hello Phil, > > > >We've actually found one;-) > > > >Our proposal focuses on AODV but > >actually could be used with any other MANET protocol. It is > >basically a scheme to establish an authenticated secret key between two > >hosts that does not have access to an infrastructure (PKI, or others...). > > > > > >Protecting AODV against Impersonation attacks (or how > >to establish a secure tunnel between 2 hosts on a MANET) > >============================================= > >Claude Castelluccia and Gabriel Montenegro. > >April 2002. > > > > oups, i have just realized that i've sent an old (very drafty) > version of the draft. > Please ignore my previous email and consider the draft attached to > this email...sorry about that... > regards, > Claude. > > PS: FYI i'll be travelling for the next 10 days and not sure whether i'll > have an Internet access...but Gabriel (my co-author) will reply to > your comments (or i'll reply when i'll be back...) > > PS: BTW we plan to submit this draft to the AODV workshop in Lausanne > (after MobiHoc) > the submission deadline is April 30th...it would be great to have your > comments > before this deadline to possibly integrate them in the draft...thanks in > advance. > > Claude. > > > ----------8><---------------------------8><------------------------------- - > > Protecting AODV against Impersonation attacks (or how > to establish a secure tunnel between 2 hosts on a MANET) > ====================================================== > Claude Castelluccia and Gabriel Montenegro. > April 2002. > > 1 *Problem statement: > -------------------- > - How to protect AODV from the impersonation attack: i.e. > how can a host H1 that is communicating with a host H2 over an > insecure Adhoc network that uses AODV has the assurance that when > it receives packets from H2 they actually come from H2 and not from > an impersonator even if the routing insfracture/protocol is insecure... > > In current AODV [AODV,AODV6], H1 establishes a route to H2 by sending > a RREQ message to H2 that will then replies with a RREP. But actually anyone > (ecen a malicious host, on the path or not) can reply to the RREQ and > redirect the packets addressed to H2 to him (eventhough H1 thinks > it is communicating with H2). Furthermore if H1 receives several RREP, > how can it select the right one? > > The basic solution is: > - the node H2 uses a CGA (Crypto Generated Address) or CGI > (Crypto. Generated Identifier) [SUCV,CAM] as address (a CGI is > an identifier that is defined as the hash of a public key). > - whenever a H2 sends packets to H1, it must disclosed its public key > and sign its packets (by setting > the mutable fields (ie hop counts) to zero or as specified in sAODV [SAODV]) > with its CGA private key... > > As a result, the destination, H1, can verify that the packets have > actually been sent by H2 . This is achieved by verifying that the CGA > or CGI was generated from the public key and that the signatures > are valid. > > This solution solves the problem but is not very efficient because > it requires one signature generation/verification per packets. > This is not acceptable. > > A Better solution is: > - H1 and H2 establish a secure channel (tunnel) and then encrypt or > authenticate (with a HMAC) their packets with the symetric key that > was generated. > > Therefore the problem can now be stated as follows: > - how can two hosts H1 and H2, identified by their address, > establish a secure (IPSec) tunnel over an insecure adhoc network > that uses AODV. > > > 2 * Proposal description: > --------------------------------- > 2.1 + requirements: > > Both H1 and H2 define a CGA or CGI, respectively CGI_H1 and > CGI_H2 as follows: > -CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) > or 128 (for CGI). > -CGI_H2 = hashx(PublicKey_H2, counter_H2) > > where PublicKey_H1 (resp. PublicKey_H2) is a public key > associated with H1 (resp. H2). > > Note: it is not clear today if a IPv6 address is really needed in > MANET. > If this is the case then CGA must be used otherwise CGI > (128 bit identifier) is better since they are cryptographically > stronger. > > 2.2 + protocol description: > > - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, > g^x.modp (i.e. a DH exponentiation value) and an nonce N1 (RREQ id > could be used instead), and signs the whole message with its > PrivateKey_H1. > The RREQ must have the newly defined D flag (see Section 2.3). > set. This flag specifies that only H2 is allowed to reply to this > RREQ. > > - When H2 receives the RREQ, it verifies that H1 owns its address > (i.e. CGI_H2 was generated from PublicKey_H2 and the signature is valid). > It then replies with a RREP that contains PublicKey_H2, counter_H2, > g^y. modp, N1 (i.e. RREQid), and signs the whole message with its > PrivateKey_H2. H2 also derives the secret key, Ke that would > be used to establish a secure channel between CGI_H1 and CGI_H2. > For example, Ke could be defined as follows: > Ke = hash_x(g^xy mod p) (where x is the size of the generated key). > > - When H1 receives RREP, it verifies that H2 owns its address and > derives the secret Key, Ke. > > From then on, the "standard" AODV protocol is used until the SA > needs to be refreshed. > > As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance > that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel > (i.e. an authenticated symetric key) is established between > CGI_H1 and CGI_H2 that can be used to secure (authenticate + encrypt) > control or data traffic. > > 2.3 + the "D" flag > > -The D (Destination) flag has been added to the RREQ packet format > because in our proposal, when H1 sends a RREQ it wants to make sure > that it gets a reply from H2 itself and not from an intermediate host > that may have an active route to H2 (as this is possible in current > AODV draft). In fact, RREQ and RREP carry information (DH > exponentiation value) that are used to establish the symetric key > between H1 and H2. If an intermediate node replies, H2 won't be able > to derive the symetric key and the protocol will fail. > > > > Route Request (RREQ) Message Format > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type |J|R|G|D| Reserved | Hop Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 32-bit Flooded Packet ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 32-bit Destination Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 32-bit Source Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : 128-bit Destination IP Address : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : 128-bit Source IP Address : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 3 + Conclusion > -------------- > We propose a protocol that allows two random hosts H1 and H2 to > establish a secure tunnel over an insecure Adhoc network that uses > AODV. Our solution relies on CGI and the definition of a new flag > (the D flag) in the RREQ packet format. > > Our proposal does not use any certificate (and therefore PKI) and > does not require any TTP support. It is therefore well adapted to > adhoc environments and very scalable. > > Note that since the routing infrasstructure is insecure, our proposol > does not protect H1 and H2 against DoS attacks. In fact, in our > proposal, as in AODV, an attacker can easily redirect/hijacked the > packets from H1 or H2. Protecting from these DoS attacks is a > different (or very complex) issue that can potentially solved by > securing the routing infrastructure or by using schemes that use > redundancy (i.e several paths). > However, even under DoS attacks, whenever H1 (and resp. H2) > receives a packet from H2 (resp. H1) it has the assurance that it > was not sent by an impersonator. That is the goal of our proposal. > > > References: > ---------- > > [AODV] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc > On Demand Distance Vector (AODV) Routing, draft-ietf-manet-aodv-10.txt, > March 2002. > > [AODV6] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc > On Demand Distance Vector (AODV) Routing for IPv6, > draft-ietf-manet-aodv6-01.txt, March 2002. > > > [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 > (CAM)", ACM Computer Communication Review, April 2001. > > [SAODV] Manel Zapata, Secure Ad hoc On-Demand Vector (SAODV) Routing, > draft-guerrero-manet-saodv-00.txt, August 2001. > > [SUCV] Gabriel Montenegro and Claude Castelluccia, "Statistical Unique and > Cryptographically Verifiable (SUCV) Identifiers and Addresses", in NDSS02, > February 2002. > > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Wed Apr 24 12:23:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21390 for ; Wed, 24 Apr 2002 12:23:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13553 for manet-archive@odin.ietf.org; Wed, 24 Apr 2002 12:23:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10331; Wed, 24 Apr 2002 11:55:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10300 for ; Wed, 24 Apr 2002 11:55:27 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19964 for ; Wed, 24 Apr 2002 11:55:23 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3OFso124532; Wed, 24 Apr 2002 17:54:50 +0200 (MET DST) Message-ID: <00ef01c1ebab$47c4cf60$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Claude Castelluccia" , References: <004001c1eb99$80c67d20$1d1fc7c2@charmette.inrialpes.fr> Subject: Re: [manet] Re: Re Security considerations in MANET Date: Wed, 24 Apr 2002 18:15:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Claude, Nice stuff. I am relatively new in security considerations, sorry if I ask naive questions. Why H1 and H2 must exchange their public keys and signatures in RREQ and RREP messages. It cannot be done in simple data packets after route discovery? I don't see the plus of involving the routing protocol. Philippe ----- Original Message ----- From: Claude Castelluccia To: Claude Castelluccia ; Phil Neumiller ; Manel Guerrero Zapata ; ext Casey Carter Cc: ; Seung Yi Sent: Wednesday, April 24, 2002 4:08 PM Subject: Re: [manet] Re: Re Security considerations in MANET > > -----Message d'origine----- > De : Claude Castelluccia > À : Phil Neumiller ; Manel Guerrero Zapata > ; ext Casey Carter > Cc : manet@ietf.org ; Seung Yi > Date : mercredi 24 avril 2002 14:38 > Objet : [manet] Re: Re Security considerations in MANET > > > > > >-----Message d'origine----- > >>D). In the case that the network has no fixed infrastructure, i.e. a pure > >ad hoc network > >> a good solution for key management does not yet exist. Please find > >one. > > > > > >Hello Phil, > > > >We've actually found one;-) > > > >Our proposal focuses on AODV but > >actually could be used with any other MANET protocol. It is > >basically a scheme to establish an authenticated secret key between two > >hosts that does not have access to an infrastructure (PKI, or others...). > > > > > >Protecting AODV against Impersonation attacks (or how > >to establish a secure tunnel between 2 hosts on a MANET) > >============================================= > >Claude Castelluccia and Gabriel Montenegro. > >April 2002. > > > > oups, i have just realized that i've sent an old (very drafty) > version of the draft. > Please ignore my previous email and consider the draft attached to > this email...sorry about that... > regards, > Claude. > > PS: FYI i'll be travelling for the next 10 days and not sure whether i'll > have an Internet access...but Gabriel (my co-author) will reply to > your comments (or i'll reply when i'll be back...) > > PS: BTW we plan to submit this draft to the AODV workshop in Lausanne > (after MobiHoc) > the submission deadline is April 30th...it would be great to have your > comments > before this deadline to possibly integrate them in the draft...thanks in > advance. > > Claude. > > > ----------8><---------------------------8><------------------------------- - > > Protecting AODV against Impersonation attacks (or how > to establish a secure tunnel between 2 hosts on a MANET) > ====================================================== > Claude Castelluccia and Gabriel Montenegro. > April 2002. > > 1 *Problem statement: > -------------------- > - How to protect AODV from the impersonation attack: i.e. > how can a host H1 that is communicating with a host H2 over an > insecure Adhoc network that uses AODV has the assurance that when > it receives packets from H2 they actually come from H2 and not from > an impersonator even if the routing insfracture/protocol is insecure... > > In current AODV [AODV,AODV6], H1 establishes a route to H2 by sending > a RREQ message to H2 that will then replies with a RREP. But actually anyone > (ecen a malicious host, on the path or not) can reply to the RREQ and > redirect the packets addressed to H2 to him (eventhough H1 thinks > it is communicating with H2). Furthermore if H1 receives several RREP, > how can it select the right one? > > The basic solution is: > - the node H2 uses a CGA (Crypto Generated Address) or CGI > (Crypto. Generated Identifier) [SUCV,CAM] as address (a CGI is > an identifier that is defined as the hash of a public key). > - whenever a H2 sends packets to H1, it must disclosed its public key > and sign its packets (by setting > the mutable fields (ie hop counts) to zero or as specified in sAODV [SAODV]) > with its CGA private key... > > As a result, the destination, H1, can verify that the packets have > actually been sent by H2 . This is achieved by verifying that the CGA > or CGI was generated from the public key and that the signatures > are valid. > > This solution solves the problem but is not very efficient because > it requires one signature generation/verification per packets. > This is not acceptable. > > A Better solution is: > - H1 and H2 establish a secure channel (tunnel) and then encrypt or > authenticate (with a HMAC) their packets with the symetric key that > was generated. > > Therefore the problem can now be stated as follows: > - how can two hosts H1 and H2, identified by their address, > establish a secure (IPSec) tunnel over an insecure adhoc network > that uses AODV. > > > 2 * Proposal description: > --------------------------------- > 2.1 + requirements: > > Both H1 and H2 define a CGA or CGI, respectively CGI_H1 and > CGI_H2 as follows: > -CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) > or 128 (for CGI). > -CGI_H2 = hashx(PublicKey_H2, counter_H2) > > where PublicKey_H1 (resp. PublicKey_H2) is a public key > associated with H1 (resp. H2). > > Note: it is not clear today if a IPv6 address is really needed in > MANET. > If this is the case then CGA must be used otherwise CGI > (128 bit identifier) is better since they are cryptographically > stronger. > > 2.2 + protocol description: > > - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, > g^x.modp (i.e. a DH exponentiation value) and an nonce N1 (RREQ id > could be used instead), and signs the whole message with its > PrivateKey_H1. > The RREQ must have the newly defined D flag (see Section 2.3). > set. This flag specifies that only H2 is allowed to reply to this > RREQ. > > - When H2 receives the RREQ, it verifies that H1 owns its address > (i.e. CGI_H2 was generated from PublicKey_H2 and the signature is valid). > It then replies with a RREP that contains PublicKey_H2, counter_H2, > g^y. modp, N1 (i.e. RREQid), and signs the whole message with its > PrivateKey_H2. H2 also derives the secret key, Ke that would > be used to establish a secure channel between CGI_H1 and CGI_H2. > For example, Ke could be defined as follows: > Ke = hash_x(g^xy mod p) (where x is the size of the generated key). > > - When H1 receives RREP, it verifies that H2 owns its address and > derives the secret Key, Ke. > > From then on, the "standard" AODV protocol is used until the SA > needs to be refreshed. > > As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance > that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel > (i.e. an authenticated symetric key) is established between > CGI_H1 and CGI_H2 that can be used to secure (authenticate + encrypt) > control or data traffic. > > 2.3 + the "D" flag > > -The D (Destination) flag has been added to the RREQ packet format > because in our proposal, when H1 sends a RREQ it wants to make sure > that it gets a reply from H2 itself and not from an intermediate host > that may have an active route to H2 (as this is possible in current > AODV draft). In fact, RREQ and RREP carry information (DH > exponentiation value) that are used to establish the symetric key > between H1 and H2. If an intermediate node replies, H2 won't be able > to derive the symetric key and the protocol will fail. > > > > Route Request (RREQ) Message Format > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type |J|R|G|D| Reserved | Hop Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 32-bit Flooded Packet ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 32-bit Destination Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 32-bit Source Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : 128-bit Destination IP Address : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : 128-bit Source IP Address : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 3 + Conclusion > -------------- > We propose a protocol that allows two random hosts H1 and H2 to > establish a secure tunnel over an insecure Adhoc network that uses > AODV. Our solution relies on CGI and the definition of a new flag > (the D flag) in the RREQ packet format. > > Our proposal does not use any certificate (and therefore PKI) and > does not require any TTP support. It is therefore well adapted to > adhoc environments and very scalable. > > Note that since the routing infrasstructure is insecure, our proposol > does not protect H1 and H2 against DoS attacks. In fact, in our > proposal, as in AODV, an attacker can easily redirect/hijacked the > packets from H1 or H2. Protecting from these DoS attacks is a > different (or very complex) issue that can potentially solved by > securing the routing infrastructure or by using schemes that use > redundancy (i.e several paths). > However, even under DoS attacks, whenever H1 (and resp. H2) > receives a packet from H2 (resp. H1) it has the assurance that it > was not sent by an impersonator. That is the goal of our proposal. > > > References: > ---------- > > [AODV] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc > On Demand Distance Vector (AODV) Routing, draft-ietf-manet-aodv-10.txt, > March 2002. > > [AODV6] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc > On Demand Distance Vector (AODV) Routing for IPv6, > draft-ietf-manet-aodv6-01.txt, March 2002. > > > [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 > (CAM)", ACM Computer Communication Review, April 2001. > > [SAODV] Manel Zapata, Secure Ad hoc On-Demand Vector (SAODV) Routing, > draft-guerrero-manet-saodv-00.txt, August 2001. > > [SUCV] Gabriel Montenegro and Claude Castelluccia, "Statistical Unique and > Cryptographically Verifiable (SUCV) Identifiers and Addresses", in NDSS02, > February 2002. > > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 24 14:02:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02775 for ; Wed, 24 Apr 2002 14:02:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19146; Wed, 24 Apr 2002 13:41:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19118 for ; Wed, 24 Apr 2002 13:41:01 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00494 for ; Wed, 24 Apr 2002 13:40:58 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFBLF; Wed, 24 Apr 2002 13:40:59 -0400 Message-ID: <013501c1ebb7$30bf4af0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Philippe Jacquet" , , References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <3CC57A73.A6C4B3E6@sarnoff.com> <00dd01c1eba2$d7e7b340$3ac033c1@inria.fr> Subject: Re: [manet] packet rebroadcasts Date: Wed, 24 Apr 2002 13:40:57 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit > Hi Jim, > > I agree with you, jitter is important. The IEEE 802.11 can support some > traffic burstiness but it is limited (it prefers poisson traffic). The > routing protocol should avoid to stress the MAC protocol with too bursty > traffics. Well, the MAC is going to experience high burstiness anyway (self-similar fractal patterned data) if its carrying IP traffic. I don't see the burstiness of the routing packets affecting this one way or another. To me its the chattiness (frequency of route control messages) is what the bigger affect on performance (at least according to my traffic models, routing overhead is only a small percentage of the traffic when the MANET is not too big). I agree that in large MANETs this could get to be an issue but you are more like to run out of bandwidth before you smash your queues with bursty route messags. -Phil -Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Apr 24 14:02:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02787 for ; Wed, 24 Apr 2002 14:02:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20836 for manet-archive@odin.ietf.org; Wed, 24 Apr 2002 14:02:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19146; Wed, 24 Apr 2002 13:41:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19118 for ; Wed, 24 Apr 2002 13:41:01 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00494 for ; Wed, 24 Apr 2002 13:40:58 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFBLF; Wed, 24 Apr 2002 13:40:59 -0400 Message-ID: <013501c1ebb7$30bf4af0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Philippe Jacquet" , , References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <3CC57A73.A6C4B3E6@sarnoff.com> <00dd01c1eba2$d7e7b340$3ac033c1@inria.fr> Subject: Re: [manet] packet rebroadcasts Date: Wed, 24 Apr 2002 13:40:57 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit > Hi Jim, > > I agree with you, jitter is important. The IEEE 802.11 can support some > traffic burstiness but it is limited (it prefers poisson traffic). The > routing protocol should avoid to stress the MAC protocol with too bursty > traffics. Well, the MAC is going to experience high burstiness anyway (self-similar fractal patterned data) if its carrying IP traffic. I don't see the burstiness of the routing packets affecting this one way or another. To me its the chattiness (frequency of route control messages) is what the bigger affect on performance (at least according to my traffic models, routing overhead is only a small percentage of the traffic when the MANET is not too big). I agree that in large MANETs this could get to be an issue but you are more like to run out of bandwidth before you smash your queues with bursty route messags. -Phil -Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Wed Apr 24 15:27:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04472 for ; Wed, 24 Apr 2002 15:27:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23220; Wed, 24 Apr 2002 14:46:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23189 for ; Wed, 24 Apr 2002 14:46:07 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18296 for ; Wed, 24 Apr 2002 14:46:03 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA28596; Wed, 24 Apr 2002 11:43:39 -0700 (PDT) Message-Id: <200204241843.LAA28596@pit.erg.sri.com> To: fred@cisco.com CC: manet@ietf.org From: ogier@erg.sri.com Reply-to: ogier@erg.sri.com Date: Wed, 24 Apr 2002 11:43:39 -0700 Subject: [manet] IPR issue for TBRPF Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Fred, Your draft titled "An outsider's view of MANET" , contains the following paragraph: TBRPF is interesting, and should work correctly, although the operational utility of some of its optimizations may be open to question in a given network. SRI has aggressively marketed TBRPF and its IPRs to the working group. The fact that a patent has been applied for on certain aspects is, however, severely limiting politically. If there is any way in which the IETF is absolutely predictable, it is that when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one. Your statement "SRI has aggressively marketed TBRPF and its IPRs to the working group" seems to imply that SRI wants to retain IP rights even if TBRPF becomes an IETF standard. That is not true. As per our Patent Rights Statement in the TBRPF draft, we will relinquish all patent rights if TBRPF becomes a standard. In addition, anyone may implement TBRPF, or use our software, for purposes related to IETF standardization. (This is true even if TBRPF is placed on "experimental track" for an arbitrarily long period of time.) The purpose of SRI's patent application is to retain IP rights if TBRPF does NOT become a standard. Why should SRI give up its rights to TBRPF if it is not accepted by the IETF, but nonetheless is useful in some situations and a valuable asset to the company? Does your statement "when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one", still apply when all IP rights are to be relinquished upon standardization? If so, can you give me an example? Under these conditions, I would not say we have "agressively marketed" TBPRF, but we have agressively demonstrated the benefits of TBRPF versus other protocols, as part of our obligations to our government clients, who requested that we work toward the standardization of a higher performance protocol for military networks. Richard ----------------------- Richard Ogier Sr. Research Engineer SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 Tel: 650-859-4216 Fax: 650-859-4812 Email: ogier@erg.sri.com TBRPF web site: http://www.erg.sri.com/projects/tbrpf/ ------------------------ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Wed Apr 24 15:27:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04484 for ; Wed, 24 Apr 2002 15:27:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25738 for manet-archive@odin.ietf.org; Wed, 24 Apr 2002 15:27:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23220; Wed, 24 Apr 2002 14:46:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23189 for ; Wed, 24 Apr 2002 14:46:07 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18296 for ; Wed, 24 Apr 2002 14:46:03 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA28596; Wed, 24 Apr 2002 11:43:39 -0700 (PDT) Message-Id: <200204241843.LAA28596@pit.erg.sri.com> To: fred@cisco.com CC: manet@ietf.org From: ogier@erg.sri.com Reply-to: ogier@erg.sri.com Date: Wed, 24 Apr 2002 11:43:39 -0700 Subject: [manet] IPR issue for TBRPF Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Fred, Your draft titled "An outsider's view of MANET" , contains the following paragraph: TBRPF is interesting, and should work correctly, although the operational utility of some of its optimizations may be open to question in a given network. SRI has aggressively marketed TBRPF and its IPRs to the working group. The fact that a patent has been applied for on certain aspects is, however, severely limiting politically. If there is any way in which the IETF is absolutely predictable, it is that when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one. Your statement "SRI has aggressively marketed TBRPF and its IPRs to the working group" seems to imply that SRI wants to retain IP rights even if TBRPF becomes an IETF standard. That is not true. As per our Patent Rights Statement in the TBRPF draft, we will relinquish all patent rights if TBRPF becomes a standard. In addition, anyone may implement TBRPF, or use our software, for purposes related to IETF standardization. (This is true even if TBRPF is placed on "experimental track" for an arbitrarily long period of time.) The purpose of SRI's patent application is to retain IP rights if TBRPF does NOT become a standard. Why should SRI give up its rights to TBRPF if it is not accepted by the IETF, but nonetheless is useful in some situations and a valuable asset to the company? Does your statement "when confronted with a choice between a proposal encumbered with IPR issues and an unencumbered proposal, it will choose the unencumbered one", still apply when all IP rights are to be relinquished upon standardization? If so, can you give me an example? Under these conditions, I would not say we have "agressively marketed" TBPRF, but we have agressively demonstrated the benefits of TBRPF versus other protocols, as part of our obligations to our government clients, who requested that we work toward the standardization of a higher performance protocol for military networks. Richard ----------------------- Richard Ogier Sr. Research Engineer SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 Tel: 650-859-4216 Fax: 650-859-4812 Email: ogier@erg.sri.com TBRPF web site: http://www.erg.sri.com/projects/tbrpf/ ------------------------ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 04:38:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29337 for ; Thu, 25 Apr 2002 04:38:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14045; Thu, 25 Apr 2002 03:41:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14018 for ; Thu, 25 Apr 2002 03:41:01 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28461 for ; Thu, 25 Apr 2002 03:40:46 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3P7VbR03450; Thu, 25 Apr 2002 09:31:37 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3P7VbX02923; Thu, 25 Apr 2002 09:31:37 +0200 (MEST) Message-ID: <00bc01c1ec2b$95a8c8a0$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "Philippe Jacquet" , Subject: Re: [manet] Re: Re Security considerations in MANET Date: Thu, 25 Apr 2002 09:29:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Salut Philippe, There are at least two good reasons for combining it with the routing protocol: 1- It might help to solve some DoS attacks.... For exemple, let's say H1 sends a RREQ for H2 and receives 10 RREPs (9 malicious one and on legitimate one)...how can he select the right one?? With our approach H1 will be able to identify the right RREP because it is signed by H2...and will therefore be able to perform the route discovery correctly... (note that possibly the intermediate may also verify the RREP validity before updatin their routing table...) 2- It is more efficient is term of bandwidth utilization...We use 2 messages instead of 4 messages.... voila, Regards, Claude. -----Message d'origine----- De : Philippe Jacquet À : Claude Castelluccia ; manet@ietf.org Date : mercredi 24 avril 2002 17:54 Objet : Re: [manet] Re: Re Security considerations in MANET >Claude, > >Nice stuff. I am relatively new in security considerations, sorry if I ask >naive questions. Why H1 and H2 must exchange their public keys and >signatures in RREQ and RREP messages. It cannot be done in simple data >packets after route discovery? I don't see the plus of involving the routing >protocol. > >Philippe >----- Original Message ----- >From: Claude Castelluccia >To: Claude Castelluccia ; Phil Neumiller >; Manel Guerrero Zapata >; ext Casey Carter >Cc: ; Seung Yi >Sent: Wednesday, April 24, 2002 4:08 PM >Subject: Re: [manet] Re: Re Security considerations in MANET > > >> >> -----Message d'origine----- >> De : Claude Castelluccia >> À : Phil Neumiller ; Manel Guerrero Zapata >> ; ext Casey Carter >> Cc : manet@ietf.org ; Seung Yi >> Date : mercredi 24 avril 2002 14:38 >> Objet : [manet] Re: Re Security considerations in MANET >> >> >> > >> >-----Message d'origine----- >> >>D). In the case that the network has no fixed infrastructure, i.e. a >pure >> >ad hoc network >> >> a good solution for key management does not yet exist. Please >find >> >one. >> > >> > >> >Hello Phil, >> > >> >We've actually found one;-) >> > >> >Our proposal focuses on AODV but >> >actually could be used with any other MANET protocol. It is >> >basically a scheme to establish an authenticated secret key between two >> >hosts that does not have access to an infrastructure (PKI, or others...). >> > >> > >> >Protecting AODV against Impersonation attacks (or how >> >to establish a secure tunnel between 2 hosts on a MANET) >> >============================================= >> >Claude Castelluccia and Gabriel Montenegro. >> >April 2002. >> >> >> >> oups, i have just realized that i've sent an old (very drafty) >> version of the draft. >> Please ignore my previous email and consider the draft attached to >> this email...sorry about that... >> regards, >> Claude. >> >> PS: FYI i'll be travelling for the next 10 days and not sure whether i'll >> have an Internet access...but Gabriel (my co-author) will reply to >> your comments (or i'll reply when i'll be back...) >> >> PS: BTW we plan to submit this draft to the AODV workshop in Lausanne >> (after MobiHoc) >> the submission deadline is April 30th...it would be great to have your >> comments >> before this deadline to possibly integrate them in the draft...thanks in >> advance. >> >> Claude. >> >> >> ----------8><---------------------------8><------------------------------ - >- >> >> Protecting AODV against Impersonation attacks (or how >> to establish a secure tunnel between 2 hosts on a MANET) >> ====================================================== >> Claude Castelluccia and Gabriel Montenegro. >> April 2002. >> >> 1 *Problem statement: >> -------------------- >> - How to protect AODV from the impersonation attack: i.e. >> how can a host H1 that is communicating with a host H2 over an >> insecure Adhoc network that uses AODV has the assurance that when >> it receives packets from H2 they actually come from H2 and not from >> an impersonator even if the routing insfracture/protocol is insecure... >> >> In current AODV [AODV,AODV6], H1 establishes a route to H2 by sending >> a RREQ message to H2 that will then replies with a RREP. But actually >anyone >> (ecen a malicious host, on the path or not) can reply to the RREQ and >> redirect the packets addressed to H2 to him (eventhough H1 thinks >> it is communicating with H2). Furthermore if H1 receives several RREP, >> how can it select the right one? >> >> The basic solution is: >> - the node H2 uses a CGA (Crypto Generated Address) or CGI >> (Crypto. Generated Identifier) [SUCV,CAM] as address (a CGI is >> an identifier that is defined as the hash of a public key). >> - whenever a H2 sends packets to H1, it must disclosed its public key >> and sign its packets (by setting >> the mutable fields (ie hop counts) to zero or as specified in sAODV >[SAODV]) >> with its CGA private key... >> >> As a result, the destination, H1, can verify that the packets have >> actually been sent by H2 . This is achieved by verifying that the CGA >> or CGI was generated from the public key and that the signatures >> are valid. >> >> This solution solves the problem but is not very efficient because >> it requires one signature generation/verification per packets. >> This is not acceptable. >> >> A Better solution is: >> - H1 and H2 establish a secure channel (tunnel) and then encrypt or >> authenticate (with a HMAC) their packets with the symetric key that >> was generated. >> >> Therefore the problem can now be stated as follows: >> - how can two hosts H1 and H2, identified by their address, >> establish a secure (IPSec) tunnel over an insecure adhoc network >> that uses AODV. >> >> >> 2 * Proposal description: >> --------------------------------- >> 2.1 + requirements: >> >> Both H1 and H2 define a CGA or CGI, respectively CGI_H1 and >> CGI_H2 as follows: >> -CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) >> or 128 (for CGI). >> -CGI_H2 = hashx(PublicKey_H2, counter_H2) >> >> where PublicKey_H1 (resp. PublicKey_H2) is a public key >> associated with H1 (resp. H2). >> >> Note: it is not clear today if a IPv6 address is really needed in >> MANET. >> If this is the case then CGA must be used otherwise CGI >> (128 bit identifier) is better since they are cryptographically >> stronger. >> >> 2.2 + protocol description: >> >> - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, >> g^x.modp (i.e. a DH exponentiation value) and an nonce N1 (RREQ id >> could be used instead), and signs the whole message with its >> PrivateKey_H1. >> The RREQ must have the newly defined D flag (see Section 2.3). >> set. This flag specifies that only H2 is allowed to reply to this >> RREQ. >> >> - When H2 receives the RREQ, it verifies that H1 owns its address >> (i.e. CGI_H2 was generated from PublicKey_H2 and the signature is valid). >> It then replies with a RREP that contains PublicKey_H2, counter_H2, >> g^y. modp, N1 (i.e. RREQid), and signs the whole message with its >> PrivateKey_H2. H2 also derives the secret key, Ke that would >> be used to establish a secure channel between CGI_H1 and CGI_H2. >> For example, Ke could be defined as follows: >> Ke = hash_x(g^xy mod p) (where x is the size of the generated key). >> >> - When H1 receives RREP, it verifies that H2 owns its address and >> derives the secret Key, Ke. >> >> From then on, the "standard" AODV protocol is used until the SA >> needs to be refreshed. >> >> As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance >> that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel >> (i.e. an authenticated symetric key) is established between >> CGI_H1 and CGI_H2 that can be used to secure (authenticate + encrypt) >> control or data traffic. >> >> 2.3 + the "D" flag >> >> -The D (Destination) flag has been added to the RREQ packet format >> because in our proposal, when H1 sends a RREQ it wants to make sure >> that it gets a reply from H2 itself and not from an intermediate host >> that may have an active route to H2 (as this is possible in current >> AODV draft). In fact, RREQ and RREP carry information (DH >> exponentiation value) that are used to establish the symetric key >> between H1 and H2. If an intermediate node replies, H2 won't be able >> to derive the symetric key and the protocol will fail. >> >> >> >> Route Request (RREQ) Message Format >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type |J|R|G|D| Reserved | Hop Count | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 32-bit Flooded Packet ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 32-bit Destination Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 32-bit Source Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> : 128-bit Destination IP Address : >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> : 128-bit Source IP Address : >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> 3 + Conclusion >> -------------- >> We propose a protocol that allows two random hosts H1 and H2 to >> establish a secure tunnel over an insecure Adhoc network that uses >> AODV. Our solution relies on CGI and the definition of a new flag >> (the D flag) in the RREQ packet format. >> >> Our proposal does not use any certificate (and therefore PKI) and >> does not require any TTP support. It is therefore well adapted to >> adhoc environments and very scalable. >> >> Note that since the routing infrasstructure is insecure, our proposol >> does not protect H1 and H2 against DoS attacks. In fact, in our >> proposal, as in AODV, an attacker can easily redirect/hijacked the >> packets from H1 or H2. Protecting from these DoS attacks is a >> different (or very complex) issue that can potentially solved by >> securing the routing infrastructure or by using schemes that use >> redundancy (i.e several paths). >> However, even under DoS attacks, whenever H1 (and resp. H2) >> receives a packet from H2 (resp. H1) it has the assurance that it >> was not sent by an impersonator. That is the goal of our proposal. >> >> >> References: >> ---------- >> >> [AODV] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc >> On Demand Distance Vector (AODV) Routing, draft-ietf-manet-aodv-10.txt, >> March 2002. >> >> [AODV6] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc >> On Demand Distance Vector (AODV) Routing for IPv6, >> draft-ietf-manet-aodv6-01.txt, March 2002. >> >> >> [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 >> (CAM)", ACM Computer Communication Review, April 2001. >> >> [SAODV] Manel Zapata, Secure Ad hoc On-Demand Vector (SAODV) Routing, >> draft-guerrero-manet-saodv-00.txt, August 2001. >> >> [SUCV] Gabriel Montenegro and Claude Castelluccia, "Statistical Unique and >> Cryptographically Verifiable (SUCV) Identifiers and Addresses", in NDSS02, >> February 2002. >> >> >> >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 25 04:38:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29348 for ; Thu, 25 Apr 2002 04:38:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18087 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 04:38:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14045; Thu, 25 Apr 2002 03:41:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14018 for ; Thu, 25 Apr 2002 03:41:01 -0400 (EDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28461 for ; Thu, 25 Apr 2002 03:40:46 -0400 (EDT) Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g3P7VbR03450; Thu, 25 Apr 2002 09:31:37 +0200 (MEST) Received: from charmette (charmette.inrialpes.fr [194.199.31.29]) by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with SMTP id g3P7VbX02923; Thu, 25 Apr 2002 09:31:37 +0200 (MEST) Message-ID: <00bc01c1ec2b$95a8c8a0$1d1fc7c2@charmette.inrialpes.fr> From: "Claude Castelluccia" To: "Philippe Jacquet" , Subject: Re: [manet] Re: Re Security considerations in MANET Date: Thu, 25 Apr 2002 09:29:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Salut Philippe, There are at least two good reasons for combining it with the routing protocol: 1- It might help to solve some DoS attacks.... For exemple, let's say H1 sends a RREQ for H2 and receives 10 RREPs (9 malicious one and on legitimate one)...how can he select the right one?? With our approach H1 will be able to identify the right RREP because it is signed by H2...and will therefore be able to perform the route discovery correctly... (note that possibly the intermediate may also verify the RREP validity before updatin their routing table...) 2- It is more efficient is term of bandwidth utilization...We use 2 messages instead of 4 messages.... voila, Regards, Claude. -----Message d'origine----- De : Philippe Jacquet À : Claude Castelluccia ; manet@ietf.org Date : mercredi 24 avril 2002 17:54 Objet : Re: [manet] Re: Re Security considerations in MANET >Claude, > >Nice stuff. I am relatively new in security considerations, sorry if I ask >naive questions. Why H1 and H2 must exchange their public keys and >signatures in RREQ and RREP messages. It cannot be done in simple data >packets after route discovery? I don't see the plus of involving the routing >protocol. > >Philippe >----- Original Message ----- >From: Claude Castelluccia >To: Claude Castelluccia ; Phil Neumiller >; Manel Guerrero Zapata >; ext Casey Carter >Cc: ; Seung Yi >Sent: Wednesday, April 24, 2002 4:08 PM >Subject: Re: [manet] Re: Re Security considerations in MANET > > >> >> -----Message d'origine----- >> De : Claude Castelluccia >> À : Phil Neumiller ; Manel Guerrero Zapata >> ; ext Casey Carter >> Cc : manet@ietf.org ; Seung Yi >> Date : mercredi 24 avril 2002 14:38 >> Objet : [manet] Re: Re Security considerations in MANET >> >> >> > >> >-----Message d'origine----- >> >>D). In the case that the network has no fixed infrastructure, i.e. a >pure >> >ad hoc network >> >> a good solution for key management does not yet exist. Please >find >> >one. >> > >> > >> >Hello Phil, >> > >> >We've actually found one;-) >> > >> >Our proposal focuses on AODV but >> >actually could be used with any other MANET protocol. It is >> >basically a scheme to establish an authenticated secret key between two >> >hosts that does not have access to an infrastructure (PKI, or others...). >> > >> > >> >Protecting AODV against Impersonation attacks (or how >> >to establish a secure tunnel between 2 hosts on a MANET) >> >============================================= >> >Claude Castelluccia and Gabriel Montenegro. >> >April 2002. >> >> >> >> oups, i have just realized that i've sent an old (very drafty) >> version of the draft. >> Please ignore my previous email and consider the draft attached to >> this email...sorry about that... >> regards, >> Claude. >> >> PS: FYI i'll be travelling for the next 10 days and not sure whether i'll >> have an Internet access...but Gabriel (my co-author) will reply to >> your comments (or i'll reply when i'll be back...) >> >> PS: BTW we plan to submit this draft to the AODV workshop in Lausanne >> (after MobiHoc) >> the submission deadline is April 30th...it would be great to have your >> comments >> before this deadline to possibly integrate them in the draft...thanks in >> advance. >> >> Claude. >> >> >> ----------8><---------------------------8><------------------------------ - >- >> >> Protecting AODV against Impersonation attacks (or how >> to establish a secure tunnel between 2 hosts on a MANET) >> ====================================================== >> Claude Castelluccia and Gabriel Montenegro. >> April 2002. >> >> 1 *Problem statement: >> -------------------- >> - How to protect AODV from the impersonation attack: i.e. >> how can a host H1 that is communicating with a host H2 over an >> insecure Adhoc network that uses AODV has the assurance that when >> it receives packets from H2 they actually come from H2 and not from >> an impersonator even if the routing insfracture/protocol is insecure... >> >> In current AODV [AODV,AODV6], H1 establishes a route to H2 by sending >> a RREQ message to H2 that will then replies with a RREP. But actually >anyone >> (ecen a malicious host, on the path or not) can reply to the RREQ and >> redirect the packets addressed to H2 to him (eventhough H1 thinks >> it is communicating with H2). Furthermore if H1 receives several RREP, >> how can it select the right one? >> >> The basic solution is: >> - the node H2 uses a CGA (Crypto Generated Address) or CGI >> (Crypto. Generated Identifier) [SUCV,CAM] as address (a CGI is >> an identifier that is defined as the hash of a public key). >> - whenever a H2 sends packets to H1, it must disclosed its public key >> and sign its packets (by setting >> the mutable fields (ie hop counts) to zero or as specified in sAODV >[SAODV]) >> with its CGA private key... >> >> As a result, the destination, H1, can verify that the packets have >> actually been sent by H2 . This is achieved by verifying that the CGA >> or CGI was generated from the public key and that the signatures >> are valid. >> >> This solution solves the problem but is not very efficient because >> it requires one signature generation/verification per packets. >> This is not acceptable. >> >> A Better solution is: >> - H1 and H2 establish a secure channel (tunnel) and then encrypt or >> authenticate (with a HMAC) their packets with the symetric key that >> was generated. >> >> Therefore the problem can now be stated as follows: >> - how can two hosts H1 and H2, identified by their address, >> establish a secure (IPSec) tunnel over an insecure adhoc network >> that uses AODV. >> >> >> 2 * Proposal description: >> --------------------------------- >> 2.1 + requirements: >> >> Both H1 and H2 define a CGA or CGI, respectively CGI_H1 and >> CGI_H2 as follows: >> -CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) >> or 128 (for CGI). >> -CGI_H2 = hashx(PublicKey_H2, counter_H2) >> >> where PublicKey_H1 (resp. PublicKey_H2) is a public key >> associated with H1 (resp. H2). >> >> Note: it is not clear today if a IPv6 address is really needed in >> MANET. >> If this is the case then CGA must be used otherwise CGI >> (128 bit identifier) is better since they are cryptographically >> stronger. >> >> 2.2 + protocol description: >> >> - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, >> g^x.modp (i.e. a DH exponentiation value) and an nonce N1 (RREQ id >> could be used instead), and signs the whole message with its >> PrivateKey_H1. >> The RREQ must have the newly defined D flag (see Section 2.3). >> set. This flag specifies that only H2 is allowed to reply to this >> RREQ. >> >> - When H2 receives the RREQ, it verifies that H1 owns its address >> (i.e. CGI_H2 was generated from PublicKey_H2 and the signature is valid). >> It then replies with a RREP that contains PublicKey_H2, counter_H2, >> g^y. modp, N1 (i.e. RREQid), and signs the whole message with its >> PrivateKey_H2. H2 also derives the secret key, Ke that would >> be used to establish a secure channel between CGI_H1 and CGI_H2. >> For example, Ke could be defined as follows: >> Ke = hash_x(g^xy mod p) (where x is the size of the generated key). >> >> - When H1 receives RREP, it verifies that H2 owns its address and >> derives the secret Key, Ke. >> >> From then on, the "standard" AODV protocol is used until the SA >> needs to be refreshed. >> >> As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance >> that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel >> (i.e. an authenticated symetric key) is established between >> CGI_H1 and CGI_H2 that can be used to secure (authenticate + encrypt) >> control or data traffic. >> >> 2.3 + the "D" flag >> >> -The D (Destination) flag has been added to the RREQ packet format >> because in our proposal, when H1 sends a RREQ it wants to make sure >> that it gets a reply from H2 itself and not from an intermediate host >> that may have an active route to H2 (as this is possible in current >> AODV draft). In fact, RREQ and RREP carry information (DH >> exponentiation value) that are used to establish the symetric key >> between H1 and H2. If an intermediate node replies, H2 won't be able >> to derive the symetric key and the protocol will fail. >> >> >> >> Route Request (RREQ) Message Format >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type |J|R|G|D| Reserved | Hop Count | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 32-bit Flooded Packet ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 32-bit Destination Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 32-bit Source Sequence Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> : 128-bit Destination IP Address : >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> : 128-bit Source IP Address : >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> 3 + Conclusion >> -------------- >> We propose a protocol that allows two random hosts H1 and H2 to >> establish a secure tunnel over an insecure Adhoc network that uses >> AODV. Our solution relies on CGI and the definition of a new flag >> (the D flag) in the RREQ packet format. >> >> Our proposal does not use any certificate (and therefore PKI) and >> does not require any TTP support. It is therefore well adapted to >> adhoc environments and very scalable. >> >> Note that since the routing infrasstructure is insecure, our proposol >> does not protect H1 and H2 against DoS attacks. In fact, in our >> proposal, as in AODV, an attacker can easily redirect/hijacked the >> packets from H1 or H2. Protecting from these DoS attacks is a >> different (or very complex) issue that can potentially solved by >> securing the routing infrastructure or by using schemes that use >> redundancy (i.e several paths). >> However, even under DoS attacks, whenever H1 (and resp. H2) >> receives a packet from H2 (resp. H1) it has the assurance that it >> was not sent by an impersonator. That is the goal of our proposal. >> >> >> References: >> ---------- >> >> [AODV] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc >> On Demand Distance Vector (AODV) Routing, draft-ietf-manet-aodv-10.txt, >> March 2002. >> >> [AODV6] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc >> On Demand Distance Vector (AODV) Routing for IPv6, >> draft-ietf-manet-aodv6-01.txt, March 2002. >> >> >> [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 >> (CAM)", ACM Computer Communication Review, April 2001. >> >> [SAODV] Manel Zapata, Secure Ad hoc On-Demand Vector (SAODV) Routing, >> draft-guerrero-manet-saodv-00.txt, August 2001. >> >> [SUCV] Gabriel Montenegro and Claude Castelluccia, "Statistical Unique and >> Cryptographically Verifiable (SUCV) Identifiers and Addresses", in NDSS02, >> February 2002. >> >> >> >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 08:27:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03205 for ; Thu, 25 Apr 2002 08:27:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28985; Thu, 25 Apr 2002 07:45:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28954 for ; Thu, 25 Apr 2002 07:45:23 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01711 for ; Thu, 25 Apr 2002 07:45:20 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3PBioT28926; Thu, 25 Apr 2002 13:44:50 +0200 (MET DST) Message-ID: <002101c1ec51$890fba60$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Phil Neumiller" , References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <3CC57A73.A6C4B3E6@sarnoff.com> <00dd01c1eba2$d7e7b340$3ac033c1@inria.fr> <013501c1ebb7$30bf4af0$6200000a@meshnetworks.com> Subject: Re: [manet] packet rebroadcasts Date: Thu, 25 Apr 2002 14:05:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Phil, I think the burstiness caused by fractal patterns of traffic (TCP for example) is by far much much smoother than the burstiness incurred when 10 nodes or more strive to rebroadcast at the same time (1000% peak). CSMA/CA hates that kind of traffic and lot of packets may be lost due to collisions. This is not a traffic percentage that matter with this respect but the concentration of traffic on very small periods of time. And since it is control traffic, it may impact on the reliability of the routing protocol itself even if at the end, the control traffic average may be low. Philippe ----- Original Message ----- From: Phil Neumiller To: Philippe Jacquet ; ; Sent: Wednesday, April 24, 2002 7:40 PM Subject: Re: [manet] packet rebroadcasts > > > > Hi Jim, > > > > I agree with you, jitter is important. The IEEE 802.11 can support some > > traffic burstiness but it is limited (it prefers poisson traffic). The > > routing protocol should avoid to stress the MAC protocol with too bursty > > traffics. > > Well, the MAC is going to experience high burstiness anyway (self-similar > fractal patterned data) if its carrying IP traffic. I don't see the burstiness of > the routing packets affecting this one way or another. To me its the chattiness > (frequency of route control messages) is what the bigger affect on performance > (at least according to my traffic models, routing overhead is only a small > percentage of the traffic when the MANET is not too big). I agree that in > large MANETs this could get to be an issue but you are more like to run > out of bandwidth before you smash your queues with bursty route messags. > > -Phil > > -Phil > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 25 08:27:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03216 for ; Thu, 25 Apr 2002 08:27:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02263 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 08:27:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28985; Thu, 25 Apr 2002 07:45:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28954 for ; Thu, 25 Apr 2002 07:45:23 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01711 for ; Thu, 25 Apr 2002 07:45:20 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3PBioT28926; Thu, 25 Apr 2002 13:44:50 +0200 (MET DST) Message-ID: <002101c1ec51$890fba60$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Phil Neumiller" , References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> <3CC09928.5030206@Carter.net> <3CC441D3.5020905@nokia.com> <3CC57A73.A6C4B3E6@sarnoff.com> <00dd01c1eba2$d7e7b340$3ac033c1@inria.fr> <013501c1ebb7$30bf4af0$6200000a@meshnetworks.com> Subject: Re: [manet] packet rebroadcasts Date: Thu, 25 Apr 2002 14:05:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Phil, I think the burstiness caused by fractal patterns of traffic (TCP for example) is by far much much smoother than the burstiness incurred when 10 nodes or more strive to rebroadcast at the same time (1000% peak). CSMA/CA hates that kind of traffic and lot of packets may be lost due to collisions. This is not a traffic percentage that matter with this respect but the concentration of traffic on very small periods of time. And since it is control traffic, it may impact on the reliability of the routing protocol itself even if at the end, the control traffic average may be low. Philippe ----- Original Message ----- From: Phil Neumiller To: Philippe Jacquet ; ; Sent: Wednesday, April 24, 2002 7:40 PM Subject: Re: [manet] packet rebroadcasts > > > > Hi Jim, > > > > I agree with you, jitter is important. The IEEE 802.11 can support some > > traffic burstiness but it is limited (it prefers poisson traffic). The > > routing protocol should avoid to stress the MAC protocol with too bursty > > traffics. > > Well, the MAC is going to experience high burstiness anyway (self-similar > fractal patterned data) if its carrying IP traffic. I don't see the burstiness of > the routing packets affecting this one way or another. To me its the chattiness > (frequency of route control messages) is what the bigger affect on performance > (at least according to my traffic models, routing overhead is only a small > percentage of the traffic when the MANET is not too big). I agree that in > large MANETs this could get to be an issue but you are more like to run > out of bandwidth before you smash your queues with bursty route messags. > > -Phil > > -Phil > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 08:44:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03732 for ; Thu, 25 Apr 2002 08:44:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00964; Thu, 25 Apr 2002 08:12:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00839 for ; Thu, 25 Apr 2002 08:12:28 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02390 for ; Thu, 25 Apr 2002 08:12:25 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3PCBbT00201; Thu, 25 Apr 2002 14:11:37 +0200 (MET DST) Message-ID: <003b01c1ec55$46d935a0$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Claude Castelluccia" , References: <00bc01c1ec2b$95a8c8a0$1d1fc7c2@charmette.inrialpes.fr> Subject: Re: [manet] Re: Re Security considerations in MANET Date: Thu, 25 Apr 2002 14:32:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Salut Claude, I thought the aim of your proposal was limited to opening a secure tunnel through an unsecure ad hoc network. Now I understand that you may want to secure the ad hoc network itself, and in this case it makes sense to authenticate the control traffic with public key and signature. If the intermediate nodes must also check signature of each RREP and RREQ this may take some more resources but much less than if it were to be done on a per data packet basis. There is still something I probably miss, what does prevent an intruder to have a public key and a private key as well? Regards, Philippe ----- Original Message ----- From: Claude Castelluccia To: Philippe Jacquet ; Sent: Thursday, April 25, 2002 9:29 AM Subject: Re: [manet] Re: Re Security considerations in MANET > Salut Philippe, > > There are at least two good reasons for combining it with the routing > protocol: > 1- It might help to solve some DoS attacks.... > For exemple, let's say H1 sends a RREQ for H2 and receives > 10 RREPs (9 malicious one and on legitimate one)...how can > he select the right one?? With our approach H1 will be able to > identify the right RREP because it is signed by H2...and will therefore > be able to perform the route discovery correctly... > > (note that possibly the intermediate may also verify the RREP validity > before updatin their routing table...) > 2- It is more efficient is term of bandwidth utilization...We use 2 messages > instead > of 4 messages.... > > voila, > Regards, > Claude. > > > > -----Message d'origine----- > De : Philippe Jacquet > À : Claude Castelluccia ; manet@ietf.org > > Date : mercredi 24 avril 2002 17:54 > Objet : Re: [manet] Re: Re Security considerations in MANET > > > >Claude, > > > >Nice stuff. I am relatively new in security considerations, sorry if I ask > >naive questions. Why H1 and H2 must exchange their public keys and > >signatures in RREQ and RREP messages. It cannot be done in simple data > >packets after route discovery? I don't see the plus of involving the > routing > >protocol. > > > >Philippe > >----- Original Message ----- > >From: Claude Castelluccia > >To: Claude Castelluccia ; Phil Neumiller > >; Manel Guerrero Zapata > >; ext Casey Carter > >Cc: ; Seung Yi > >Sent: Wednesday, April 24, 2002 4:08 PM > >Subject: Re: [manet] Re: Re Security considerations in MANET > > > > > >> > >> -----Message d'origine----- > >> De : Claude Castelluccia > >> À : Phil Neumiller ; Manel Guerrero Zapata > >> ; ext Casey Carter > >> Cc : manet@ietf.org ; Seung Yi > >> Date : mercredi 24 avril 2002 14:38 > >> Objet : [manet] Re: Re Security considerations in MANET > >> > >> > >> > > >> >-----Message d'origine----- > >> >>D). In the case that the network has no fixed infrastructure, i.e. a > >pure > >> >ad hoc network > >> >> a good solution for key management does not yet exist. Please > >find > >> >one. > >> > > >> > > >> >Hello Phil, > >> > > >> >We've actually found one;-) > >> > > >> >Our proposal focuses on AODV but > >> >actually could be used with any other MANET protocol. It is > >> >basically a scheme to establish an authenticated secret key between two > >> >hosts that does not have access to an infrastructure (PKI, or > others...). > >> > > >> > > >> >Protecting AODV against Impersonation attacks (or how > >> >to establish a secure tunnel between 2 hosts on a MANET) > >> >============================================= > >> >Claude Castelluccia and Gabriel Montenegro. > >> >April 2002. > >> > >> > >> > >> oups, i have just realized that i've sent an old (very drafty) > >> version of the draft. > >> Please ignore my previous email and consider the draft attached to > >> this email...sorry about that... > >> regards, > >> Claude. > >> > >> PS: FYI i'll be travelling for the next 10 days and not sure whether i'll > >> have an Internet access...but Gabriel (my co-author) will reply to > >> your comments (or i'll reply when i'll be back...) > >> > >> PS: BTW we plan to submit this draft to the AODV workshop in Lausanne > >> (after MobiHoc) > >> the submission deadline is April 30th...it would be great to have your > >> comments > >> before this deadline to possibly integrate them in the draft...thanks in > >> advance. > >> > >> Claude. > >> > >> > >> ----------8><---------------------------8><------------------------------ > - > >- > >> > >> Protecting AODV against Impersonation attacks (or how > >> to establish a secure tunnel between 2 hosts on a MANET) > >> ====================================================== > >> Claude Castelluccia and Gabriel Montenegro. > >> April 2002. > >> > >> 1 *Problem statement: > >> -------------------- > >> - How to protect AODV from the impersonation attack: i.e. > >> how can a host H1 that is communicating with a host H2 over an > >> insecure Adhoc network that uses AODV has the assurance that when > >> it receives packets from H2 they actually come from H2 and not from > >> an impersonator even if the routing insfracture/protocol is insecure... > >> > >> In current AODV [AODV,AODV6], H1 establishes a route to H2 by sending > >> a RREQ message to H2 that will then replies with a RREP. But actually > >anyone > >> (ecen a malicious host, on the path or not) can reply to the RREQ and > >> redirect the packets addressed to H2 to him (eventhough H1 thinks > >> it is communicating with H2). Furthermore if H1 receives several RREP, > >> how can it select the right one? > >> > >> The basic solution is: > >> - the node H2 uses a CGA (Crypto Generated Address) or CGI > >> (Crypto. Generated Identifier) [SUCV,CAM] as address (a CGI is > >> an identifier that is defined as the hash of a public key). > >> - whenever a H2 sends packets to H1, it must disclosed its public key > >> and sign its packets (by setting > >> the mutable fields (ie hop counts) to zero or as specified in sAODV > >[SAODV]) > >> with its CGA private key... > >> > >> As a result, the destination, H1, can verify that the packets have > >> actually been sent by H2 . This is achieved by verifying that the CGA > >> or CGI was generated from the public key and that the signatures > >> are valid. > >> > >> This solution solves the problem but is not very efficient because > >> it requires one signature generation/verification per packets. > >> This is not acceptable. > >> > >> A Better solution is: > >> - H1 and H2 establish a secure channel (tunnel) and then encrypt or > >> authenticate (with a HMAC) their packets with the symetric key that > >> was generated. > >> > >> Therefore the problem can now be stated as follows: > >> - how can two hosts H1 and H2, identified by their address, > >> establish a secure (IPSec) tunnel over an insecure adhoc network > >> that uses AODV. > >> > >> > >> 2 * Proposal description: > >> --------------------------------- > >> 2.1 + requirements: > >> > >> Both H1 and H2 define a CGA or CGI, respectively CGI_H1 and > >> CGI_H2 as follows: > >> -CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) > >> or 128 (for CGI). > >> -CGI_H2 = hashx(PublicKey_H2, counter_H2) > >> > >> where PublicKey_H1 (resp. PublicKey_H2) is a public key > >> associated with H1 (resp. H2). > >> > >> Note: it is not clear today if a IPv6 address is really needed in > >> MANET. > >> If this is the case then CGA must be used otherwise CGI > >> (128 bit identifier) is better since they are cryptographically > >> stronger. > >> > >> 2.2 + protocol description: > >> > >> - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, > >> g^x.modp (i.e. a DH exponentiation value) and an nonce N1 (RREQ id > >> could be used instead), and signs the whole message with its > >> PrivateKey_H1. > >> The RREQ must have the newly defined D flag (see Section 2.3). > >> set. This flag specifies that only H2 is allowed to reply to this > >> RREQ. > >> > >> - When H2 receives the RREQ, it verifies that H1 owns its address > >> (i.e. CGI_H2 was generated from PublicKey_H2 and the signature is valid). > >> It then replies with a RREP that contains PublicKey_H2, counter_H2, > >> g^y. modp, N1 (i.e. RREQid), and signs the whole message with its > >> PrivateKey_H2. H2 also derives the secret key, Ke that would > >> be used to establish a secure channel between CGI_H1 and CGI_H2. > >> For example, Ke could be defined as follows: > >> Ke = hash_x(g^xy mod p) (where x is the size of the generated key). > >> > >> - When H1 receives RREP, it verifies that H2 owns its address and > >> derives the secret Key, Ke. > >> > >> From then on, the "standard" AODV protocol is used until the SA > >> needs to be refreshed. > >> > >> As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance > >> that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel > >> (i.e. an authenticated symetric key) is established between > >> CGI_H1 and CGI_H2 that can be used to secure (authenticate + encrypt) > >> control or data traffic. > >> > >> 2.3 + the "D" flag > >> > >> -The D (Destination) flag has been added to the RREQ packet format > >> because in our proposal, when H1 sends a RREQ it wants to make sure > >> that it gets a reply from H2 itself and not from an intermediate host > >> that may have an active route to H2 (as this is possible in current > >> AODV draft). In fact, RREQ and RREP carry information (DH > >> exponentiation value) that are used to establish the symetric key > >> between H1 and H2. If an intermediate node replies, H2 won't be able > >> to derive the symetric key and the protocol will fail. > >> > >> > >> > >> Route Request (RREQ) Message Format > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type |J|R|G|D| Reserved | Hop Count | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 32-bit Flooded Packet ID | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 32-bit Destination Sequence Number | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 32-bit Source Sequence Number | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> : 128-bit Destination IP Address : > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> : 128-bit Source IP Address : > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> > >> 3 + Conclusion > >> -------------- > >> We propose a protocol that allows two random hosts H1 and H2 to > >> establish a secure tunnel over an insecure Adhoc network that uses > >> AODV. Our solution relies on CGI and the definition of a new flag > >> (the D flag) in the RREQ packet format. > >> > >> Our proposal does not use any certificate (and therefore PKI) and > >> does not require any TTP support. It is therefore well adapted to > >> adhoc environments and very scalable. > >> > >> Note that since the routing infrasstructure is insecure, our proposol > >> does not protect H1 and H2 against DoS attacks. In fact, in our > >> proposal, as in AODV, an attacker can easily redirect/hijacked the > >> packets from H1 or H2. Protecting from these DoS attacks is a > >> different (or very complex) issue that can potentially solved by > >> securing the routing infrastructure or by using schemes that use > >> redundancy (i.e several paths). > >> However, even under DoS attacks, whenever H1 (and resp. H2) > >> receives a packet from H2 (resp. H1) it has the assurance that it > >> was not sent by an impersonator. That is the goal of our proposal. > >> > >> > >> References: > >> ---------- > >> > >> [AODV] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc > >> On Demand Distance Vector (AODV) Routing, draft-ietf-manet-aodv-10.txt, > >> March 2002. > >> > >> [AODV6] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc > >> On Demand Distance Vector (AODV) Routing for IPv6, > >> draft-ietf-manet-aodv6-01.txt, March 2002. > >> > >> > >> [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 > >> (CAM)", ACM Computer Communication Review, April 2001. > >> > >> [SAODV] Manel Zapata, Secure Ad hoc On-Demand Vector (SAODV) Routing, > >> draft-guerrero-manet-saodv-00.txt, August 2001. > >> > >> [SUCV] Gabriel Montenegro and Claude Castelluccia, "Statistical Unique > and > >> Cryptographically Verifiable (SUCV) Identifiers and Addresses", in > NDSS02, > >> February 2002. > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www1.ietf.org/mailman/listinfo/manet > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 25 09:41:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03739 for ; Thu, 25 Apr 2002 08:44:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03684 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 08:44:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00964; Thu, 25 Apr 2002 08:12:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00839 for ; Thu, 25 Apr 2002 08:12:28 -0400 (EDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02390 for ; Thu, 25 Apr 2002 08:12:25 -0400 (EDT) Received: from zephyrin (zephyrin-wi.inria.fr [193.51.192.58]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g3PCBbT00201; Thu, 25 Apr 2002 14:11:37 +0200 (MET DST) Message-ID: <003b01c1ec55$46d935a0$3ac033c1@inria.fr> From: "Philippe Jacquet" To: "Claude Castelluccia" , References: <00bc01c1ec2b$95a8c8a0$1d1fc7c2@charmette.inrialpes.fr> Subject: Re: [manet] Re: Re Security considerations in MANET Date: Thu, 25 Apr 2002 14:32:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Salut Claude, I thought the aim of your proposal was limited to opening a secure tunnel through an unsecure ad hoc network. Now I understand that you may want to secure the ad hoc network itself, and in this case it makes sense to authenticate the control traffic with public key and signature. If the intermediate nodes must also check signature of each RREP and RREQ this may take some more resources but much less than if it were to be done on a per data packet basis. There is still something I probably miss, what does prevent an intruder to have a public key and a private key as well? Regards, Philippe ----- Original Message ----- From: Claude Castelluccia To: Philippe Jacquet ; Sent: Thursday, April 25, 2002 9:29 AM Subject: Re: [manet] Re: Re Security considerations in MANET > Salut Philippe, > > There are at least two good reasons for combining it with the routing > protocol: > 1- It might help to solve some DoS attacks.... > For exemple, let's say H1 sends a RREQ for H2 and receives > 10 RREPs (9 malicious one and on legitimate one)...how can > he select the right one?? With our approach H1 will be able to > identify the right RREP because it is signed by H2...and will therefore > be able to perform the route discovery correctly... > > (note that possibly the intermediate may also verify the RREP validity > before updatin their routing table...) > 2- It is more efficient is term of bandwidth utilization...We use 2 messages > instead > of 4 messages.... > > voila, > Regards, > Claude. > > > > -----Message d'origine----- > De : Philippe Jacquet > À : Claude Castelluccia ; manet@ietf.org > > Date : mercredi 24 avril 2002 17:54 > Objet : Re: [manet] Re: Re Security considerations in MANET > > > >Claude, > > > >Nice stuff. I am relatively new in security considerations, sorry if I ask > >naive questions. Why H1 and H2 must exchange their public keys and > >signatures in RREQ and RREP messages. It cannot be done in simple data > >packets after route discovery? I don't see the plus of involving the > routing > >protocol. > > > >Philippe > >----- Original Message ----- > >From: Claude Castelluccia > >To: Claude Castelluccia ; Phil Neumiller > >; Manel Guerrero Zapata > >; ext Casey Carter > >Cc: ; Seung Yi > >Sent: Wednesday, April 24, 2002 4:08 PM > >Subject: Re: [manet] Re: Re Security considerations in MANET > > > > > >> > >> -----Message d'origine----- > >> De : Claude Castelluccia > >> À : Phil Neumiller ; Manel Guerrero Zapata > >> ; ext Casey Carter > >> Cc : manet@ietf.org ; Seung Yi > >> Date : mercredi 24 avril 2002 14:38 > >> Objet : [manet] Re: Re Security considerations in MANET > >> > >> > >> > > >> >-----Message d'origine----- > >> >>D). In the case that the network has no fixed infrastructure, i.e. a > >pure > >> >ad hoc network > >> >> a good solution for key management does not yet exist. Please > >find > >> >one. > >> > > >> > > >> >Hello Phil, > >> > > >> >We've actually found one;-) > >> > > >> >Our proposal focuses on AODV but > >> >actually could be used with any other MANET protocol. It is > >> >basically a scheme to establish an authenticated secret key between two > >> >hosts that does not have access to an infrastructure (PKI, or > others...). > >> > > >> > > >> >Protecting AODV against Impersonation attacks (or how > >> >to establish a secure tunnel between 2 hosts on a MANET) > >> >============================================= > >> >Claude Castelluccia and Gabriel Montenegro. > >> >April 2002. > >> > >> > >> > >> oups, i have just realized that i've sent an old (very drafty) > >> version of the draft. > >> Please ignore my previous email and consider the draft attached to > >> this email...sorry about that... > >> regards, > >> Claude. > >> > >> PS: FYI i'll be travelling for the next 10 days and not sure whether i'll > >> have an Internet access...but Gabriel (my co-author) will reply to > >> your comments (or i'll reply when i'll be back...) > >> > >> PS: BTW we plan to submit this draft to the AODV workshop in Lausanne > >> (after MobiHoc) > >> the submission deadline is April 30th...it would be great to have your > >> comments > >> before this deadline to possibly integrate them in the draft...thanks in > >> advance. > >> > >> Claude. > >> > >> > >> ----------8><---------------------------8><------------------------------ > - > >- > >> > >> Protecting AODV against Impersonation attacks (or how > >> to establish a secure tunnel between 2 hosts on a MANET) > >> ====================================================== > >> Claude Castelluccia and Gabriel Montenegro. > >> April 2002. > >> > >> 1 *Problem statement: > >> -------------------- > >> - How to protect AODV from the impersonation attack: i.e. > >> how can a host H1 that is communicating with a host H2 over an > >> insecure Adhoc network that uses AODV has the assurance that when > >> it receives packets from H2 they actually come from H2 and not from > >> an impersonator even if the routing insfracture/protocol is insecure... > >> > >> In current AODV [AODV,AODV6], H1 establishes a route to H2 by sending > >> a RREQ message to H2 that will then replies with a RREP. But actually > >anyone > >> (ecen a malicious host, on the path or not) can reply to the RREQ and > >> redirect the packets addressed to H2 to him (eventhough H1 thinks > >> it is communicating with H2). Furthermore if H1 receives several RREP, > >> how can it select the right one? > >> > >> The basic solution is: > >> - the node H2 uses a CGA (Crypto Generated Address) or CGI > >> (Crypto. Generated Identifier) [SUCV,CAM] as address (a CGI is > >> an identifier that is defined as the hash of a public key). > >> - whenever a H2 sends packets to H1, it must disclosed its public key > >> and sign its packets (by setting > >> the mutable fields (ie hop counts) to zero or as specified in sAODV > >[SAODV]) > >> with its CGA private key... > >> > >> As a result, the destination, H1, can verify that the packets have > >> actually been sent by H2 . This is achieved by verifying that the CGA > >> or CGI was generated from the public key and that the signatures > >> are valid. > >> > >> This solution solves the problem but is not very efficient because > >> it requires one signature generation/verification per packets. > >> This is not acceptable. > >> > >> A Better solution is: > >> - H1 and H2 establish a secure channel (tunnel) and then encrypt or > >> authenticate (with a HMAC) their packets with the symetric key that > >> was generated. > >> > >> Therefore the problem can now be stated as follows: > >> - how can two hosts H1 and H2, identified by their address, > >> establish a secure (IPSec) tunnel over an insecure adhoc network > >> that uses AODV. > >> > >> > >> 2 * Proposal description: > >> --------------------------------- > >> 2.1 + requirements: > >> > >> Both H1 and H2 define a CGA or CGI, respectively CGI_H1 and > >> CGI_H2 as follows: > >> -CGI_H1 = hashx(PublicKey_H1, counter_H1) x=64 (for CGA) > >> or 128 (for CGI). > >> -CGI_H2 = hashx(PublicKey_H2, counter_H2) > >> > >> where PublicKey_H1 (resp. PublicKey_H2) is a public key > >> associated with H1 (resp. H2). > >> > >> Note: it is not clear today if a IPv6 address is really needed in > >> MANET. > >> If this is the case then CGA must be used otherwise CGI > >> (128 bit identifier) is better since they are cryptographically > >> stronger. > >> > >> 2.2 + protocol description: > >> > >> - H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1, > >> g^x.modp (i.e. a DH exponentiation value) and an nonce N1 (RREQ id > >> could be used instead), and signs the whole message with its > >> PrivateKey_H1. > >> The RREQ must have the newly defined D flag (see Section 2.3). > >> set. This flag specifies that only H2 is allowed to reply to this > >> RREQ. > >> > >> - When H2 receives the RREQ, it verifies that H1 owns its address > >> (i.e. CGI_H2 was generated from PublicKey_H2 and the signature is valid). > >> It then replies with a RREP that contains PublicKey_H2, counter_H2, > >> g^y. modp, N1 (i.e. RREQid), and signs the whole message with its > >> PrivateKey_H2. H2 also derives the secret key, Ke that would > >> be used to establish a secure channel between CGI_H1 and CGI_H2. > >> For example, Ke could be defined as follows: > >> Ke = hash_x(g^xy mod p) (where x is the size of the generated key). > >> > >> - When H1 receives RREP, it verifies that H2 owns its address and > >> derives the secret Key, Ke. > >> > >> From then on, the "standard" AODV protocol is used until the SA > >> needs to be refreshed. > >> > >> As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance > >> that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel > >> (i.e. an authenticated symetric key) is established between > >> CGI_H1 and CGI_H2 that can be used to secure (authenticate + encrypt) > >> control or data traffic. > >> > >> 2.3 + the "D" flag > >> > >> -The D (Destination) flag has been added to the RREQ packet format > >> because in our proposal, when H1 sends a RREQ it wants to make sure > >> that it gets a reply from H2 itself and not from an intermediate host > >> that may have an active route to H2 (as this is possible in current > >> AODV draft). In fact, RREQ and RREP carry information (DH > >> exponentiation value) that are used to establish the symetric key > >> between H1 and H2. If an intermediate node replies, H2 won't be able > >> to derive the symetric key and the protocol will fail. > >> > >> > >> > >> Route Request (RREQ) Message Format > >> 0 1 2 3 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Type |J|R|G|D| Reserved | Hop Count | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 32-bit Flooded Packet ID | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 32-bit Destination Sequence Number | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 32-bit Source Sequence Number | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> : 128-bit Destination IP Address : > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> : 128-bit Source IP Address : > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> > >> 3 + Conclusion > >> -------------- > >> We propose a protocol that allows two random hosts H1 and H2 to > >> establish a secure tunnel over an insecure Adhoc network that uses > >> AODV. Our solution relies on CGI and the definition of a new flag > >> (the D flag) in the RREQ packet format. > >> > >> Our proposal does not use any certificate (and therefore PKI) and > >> does not require any TTP support. It is therefore well adapted to > >> adhoc environments and very scalable. > >> > >> Note that since the routing infrasstructure is insecure, our proposol > >> does not protect H1 and H2 against DoS attacks. In fact, in our > >> proposal, as in AODV, an attacker can easily redirect/hijacked the > >> packets from H1 or H2. Protecting from these DoS attacks is a > >> different (or very complex) issue that can potentially solved by > >> securing the routing infrastructure or by using schemes that use > >> redundancy (i.e several paths). > >> However, even under DoS attacks, whenever H1 (and resp. H2) > >> receives a packet from H2 (resp. H1) it has the assurance that it > >> was not sent by an impersonator. That is the goal of our proposal. > >> > >> > >> References: > >> ---------- > >> > >> [AODV] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc > >> On Demand Distance Vector (AODV) Routing, draft-ietf-manet-aodv-10.txt, > >> March 2002. > >> > >> [AODV6] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc > >> On Demand Distance Vector (AODV) Routing for IPv6, > >> draft-ietf-manet-aodv6-01.txt, March 2002. > >> > >> > >> [CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6 > >> (CAM)", ACM Computer Communication Review, April 2001. > >> > >> [SAODV] Manel Zapata, Secure Ad hoc On-Demand Vector (SAODV) Routing, > >> draft-guerrero-manet-saodv-00.txt, August 2001. > >> > >> [SUCV] Gabriel Montenegro and Claude Castelluccia, "Statistical Unique > and > >> Cryptographically Verifiable (SUCV) Identifiers and Addresses", in > NDSS02, > >> February 2002. > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www1.ietf.org/mailman/listinfo/manet > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 12:27:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26363 for ; Thu, 25 Apr 2002 12:27:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14182; Thu, 25 Apr 2002 11:28:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14153 for ; Thu, 25 Apr 2002 11:27:44 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23238 for ; Thu, 25 Apr 2002 11:27:40 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFCGX; Thu, 25 Apr 2002 11:27:42 -0400 Message-ID: <007501c1ec6d$be341800$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , Cc: , "Ryuji Wakikawa" , , , Date: Thu, 25 Apr 2002 11:27:42 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit NOTE: This comment has been cross posted to NEMO/MANET, so be careful with responses. The draft draft-wakikawa-manet-globalv6-00.txt advocates adding an M-bit to the router solicitation message which allows source IPv6 DAD'd addresses for link local addresses to be forwarded over a MANET to an Internet gateway. Rather than mucking with the solicitation and advertisements, an alternative might be the following. At least this seems to work for me. 1). Allow the host to own a globally routable MIPv6 home address (possibly with its own DNS entry). 2). The mobile MUST use this home address when forming a MANET. 3). The mobile MUST be a MIPv6 client. 4). In the mobile's HA coverage area, assuming a set of fixed MANET wireless routers supply this, the node will be reachable. 5). When the node wanders to a foreign MANET coverage area with a different subnet, it may acquire a COA from DHCPv6, and be routable on that MANET subnet under that gateway. 6). Let's postpone the inevitable security discussion for the moment. It seems to me, that this has the desired effect of global connectivity for MANETs, does not require any new messages, can be built today, and solves the NEMO problem as well as the MANET global connectivity problem. But then again, I could be missing something. Gentlefolk, start your flame throwers!!! Thanks, Phil Neumiller _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 25 12:27:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26374 for ; Thu, 25 Apr 2002 12:27:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19972 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 12:27:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14182; Thu, 25 Apr 2002 11:28:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14153 for ; Thu, 25 Apr 2002 11:27:44 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23238 for ; Thu, 25 Apr 2002 11:27:40 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFCGX; Thu, 25 Apr 2002 11:27:42 -0400 Message-ID: <007501c1ec6d$be341800$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , Cc: , "Ryuji Wakikawa" , , , Date: Thu, 25 Apr 2002 11:27:42 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit NOTE: This comment has been cross posted to NEMO/MANET, so be careful with responses. The draft draft-wakikawa-manet-globalv6-00.txt advocates adding an M-bit to the router solicitation message which allows source IPv6 DAD'd addresses for link local addresses to be forwarded over a MANET to an Internet gateway. Rather than mucking with the solicitation and advertisements, an alternative might be the following. At least this seems to work for me. 1). Allow the host to own a globally routable MIPv6 home address (possibly with its own DNS entry). 2). The mobile MUST use this home address when forming a MANET. 3). The mobile MUST be a MIPv6 client. 4). In the mobile's HA coverage area, assuming a set of fixed MANET wireless routers supply this, the node will be reachable. 5). When the node wanders to a foreign MANET coverage area with a different subnet, it may acquire a COA from DHCPv6, and be routable on that MANET subnet under that gateway. 6). Let's postpone the inevitable security discussion for the moment. It seems to me, that this has the desired effect of global connectivity for MANETs, does not require any new messages, can be built today, and solves the NEMO problem as well as the MANET global connectivity problem. But then again, I could be missing something. Gentlefolk, start your flame throwers!!! Thanks, Phil Neumiller _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 14:18:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00651 for ; Thu, 25 Apr 2002 14:18:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26095; Thu, 25 Apr 2002 13:42:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26064 for ; Thu, 25 Apr 2002 13:42:19 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28959 for ; Thu, 25 Apr 2002 13:42:16 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFCMA; Thu, 25 Apr 2002 13:42:14 -0400 Message-ID: <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: , References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt Date: Thu, 25 Apr 2002 13:42:13 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit > > 2). The mobile MUST use this home address when forming a MANET. > > I don't think this is acceptable, nor in the spirit of IPv6 address > autoconfiguration. I have always thought that any IPv6 node should > be able to use any address that it can successfully (and correcctly) > configure. Aaaw, why not? It seems that *if* the MN has this MIPv6 home address in its hip pocket doing nothing, it COULD be used for MANET addressing since it is guaranteed to be unique. NOTE: I am not suggesting precluding the autoconfigured address, just suggesting the use of the MIPv6 home address as a viable option. > > > 3). The mobile MUST be a MIPv6 client. > > What if it doesn't want to use its home address, and just wants > to use a fixed address in the foreign domain that happens to be > extended at some wireless access point into an ad hoc network? Yes, and that is LIKELY to be be COA *if* the MN is indeed a MIPv6 client right? Furthermore, the COA is likely to be gotten from DHCPv6 right? > > 4). In the mobile's HA coverage area, assuming a set of fixed MANET > > wireless routers supply this, the node will be reachable. > > I could not quite parse this. I guess it supposes that there is a > home agent with a wireless interface. I also guess that you are > setting the stage for (5). For NEMO: My assumption is that you either have a mobile network with a gateway node that speaks MANET on the inside and MAY speak OSPF or BGP (throwing Jim a bone) on the outside of the NEMO. Alternatively, it may simply be a BOOTp/DHCP relay that acquires its address from DHCPv6 and routes packets to the MANET inside the NEMO. Either way you slice that it comes out allowing global connectivity of the MNNs or MNs or whatever you want to call the hosts. BTW, we should also consider the situation where the transceiver (assuming wireless) has its own IP address (MANET routable) and the host either has the MIPv6 home address or COA. > > > 5). When the node wanders to a foreign MANET coverage area with a different subnet, > > it may acquire a COA from DHCPv6, and be routable on that MANET subnet under > > that gateway. > > Ahh! Finally we have total agreement :-) Except for the fact that I like the idea of using the COA as the MANET routing address as well... > > It is our purpose to provide for stateless autoconfiguration > as well as stateful autoconfiguration. So, I reckon that > both have to be specified. I also guess that eventually we > will need some pretty simple text about DHCPv6 operation in > the Globalv6 draft. OK, so what you are saying is that M-bit is still needed for stateless autoconfiguration. What is the advantage of stateless autoconfiguraion to a MANET? Isn't DaD going to be a lot harder? Also, it seems that when the MN is handing off between domains it may have to go into an expanded ring search. This is pretty yucky for smooth/seamless/ soft/fluffy handovers. I prefer my stateful method for this reason for MANET's that provide infrastructures. What say you? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 25 14:18:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00675 for ; Thu, 25 Apr 2002 14:18:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29472 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 14:18:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26095; Thu, 25 Apr 2002 13:42:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26064 for ; Thu, 25 Apr 2002 13:42:19 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28959 for ; Thu, 25 Apr 2002 13:42:16 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFCMA; Thu, 25 Apr 2002 13:42:14 -0400 Message-ID: <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: , References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt Date: Thu, 25 Apr 2002 13:42:13 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit > > 2). The mobile MUST use this home address when forming a MANET. > > I don't think this is acceptable, nor in the spirit of IPv6 address > autoconfiguration. I have always thought that any IPv6 node should > be able to use any address that it can successfully (and correcctly) > configure. Aaaw, why not? It seems that *if* the MN has this MIPv6 home address in its hip pocket doing nothing, it COULD be used for MANET addressing since it is guaranteed to be unique. NOTE: I am not suggesting precluding the autoconfigured address, just suggesting the use of the MIPv6 home address as a viable option. > > > 3). The mobile MUST be a MIPv6 client. > > What if it doesn't want to use its home address, and just wants > to use a fixed address in the foreign domain that happens to be > extended at some wireless access point into an ad hoc network? Yes, and that is LIKELY to be be COA *if* the MN is indeed a MIPv6 client right? Furthermore, the COA is likely to be gotten from DHCPv6 right? > > 4). In the mobile's HA coverage area, assuming a set of fixed MANET > > wireless routers supply this, the node will be reachable. > > I could not quite parse this. I guess it supposes that there is a > home agent with a wireless interface. I also guess that you are > setting the stage for (5). For NEMO: My assumption is that you either have a mobile network with a gateway node that speaks MANET on the inside and MAY speak OSPF or BGP (throwing Jim a bone) on the outside of the NEMO. Alternatively, it may simply be a BOOTp/DHCP relay that acquires its address from DHCPv6 and routes packets to the MANET inside the NEMO. Either way you slice that it comes out allowing global connectivity of the MNNs or MNs or whatever you want to call the hosts. BTW, we should also consider the situation where the transceiver (assuming wireless) has its own IP address (MANET routable) and the host either has the MIPv6 home address or COA. > > > 5). When the node wanders to a foreign MANET coverage area with a different subnet, > > it may acquire a COA from DHCPv6, and be routable on that MANET subnet under > > that gateway. > > Ahh! Finally we have total agreement :-) Except for the fact that I like the idea of using the COA as the MANET routing address as well... > > It is our purpose to provide for stateless autoconfiguration > as well as stateful autoconfiguration. So, I reckon that > both have to be specified. I also guess that eventually we > will need some pretty simple text about DHCPv6 operation in > the Globalv6 draft. OK, so what you are saying is that M-bit is still needed for stateless autoconfiguration. What is the advantage of stateless autoconfiguraion to a MANET? Isn't DaD going to be a lot harder? Also, it seems that when the MN is handing off between domains it may have to go into an expanded ring search. This is pretty yucky for smooth/seamless/ soft/fluffy handovers. I prefer my stateful method for this reason for MANET's that provide infrastructures. What say you? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 14:36:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01315 for ; Thu, 25 Apr 2002 14:36:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17403; Thu, 25 Apr 2002 12:00:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17117 for ; Thu, 25 Apr 2002 12:00:29 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24735 for ; Thu, 25 Apr 2002 12:00:23 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA11533; Thu, 25 Apr 2002 08:59:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PFxsM15958; Thu, 25 Apr 2002 08:59:54 -0700 X-mProtect: <200204251559> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvPJdmt; Thu, 25 Apr 2002 08:59:52 PDT Message-ID: <3CC827F8.C347C2B2@iprg.nokia.com> Date: Thu, 25 Apr 2002 08:59:53 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: monet@nal.motlabs.com, manet@ietf.org Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, You can use "charles.perkins@nokia.com", but "cperkins@nokia.com" probably didn't work... Phil Neumiller wrote: > The draft draft-wakikawa-manet-globalv6-00.txt advocates adding an M-bit to the > router solicitation message which allows source IPv6 DAD'd addresses for link > local addresses to be forwarded over a MANET to an Internet gateway. > > Rather than mucking with the solicitation and advertisements, an alternative might be > the following. At least this seems to work for me. > > 1). Allow the host to own a globally routable MIPv6 home address (possibly with its > own DNS entry). Surely, this is always allowed, even preferred. > 2). The mobile MUST use this home address when forming a MANET. I don't think this is acceptable, nor in the spirit of IPv6 address autoconfiguration. I have always thought that any IPv6 node should be able to use any address that it can successfully (and correcctly) configure. > 3). The mobile MUST be a MIPv6 client. What if it doesn't want to use its home address, and just wants to use a fixed address in the foreign domain that happens to be extended at some wireless access point into an ad hoc network? > 4). In the mobile's HA coverage area, assuming a set of fixed MANET > wireless routers supply this, the node will be reachable. I could not quite parse this. I guess it supposes that there is a home agent with a wireless interface. I also guess that you are setting the stage for (5). > 5). When the node wanders to a foreign MANET coverage area with a different subnet, > it may acquire a COA from DHCPv6, and be routable on that MANET subnet under > that gateway. Ahh! Finally we have total agreement :-) It is our purpose to provide for stateless autoconfiguration as well as stateful autoconfiguration. So, I reckon that both have to be specified. I also guess that eventually we will need some pretty simple text about DHCPv6 operation in the Globalv6 draft. > 6). Let's postpone the inevitable security discussion for the moment. > > It seems to me, that this has the desired effect of global connectivity for MANETs, does > not require any new messages, can be built today, and solves the NEMO problem as > well as the MANET global connectivity problem. But then again, I could be missing > something. Gentlefolk, start your flame throwers!!! ... darn, mine wouldn't start ... Got any gas? Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 25 14:36:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01327 for ; Thu, 25 Apr 2002 14:36:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01105 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 14:36:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17403; Thu, 25 Apr 2002 12:00:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17117 for ; Thu, 25 Apr 2002 12:00:29 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24735 for ; Thu, 25 Apr 2002 12:00:23 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA11533; Thu, 25 Apr 2002 08:59:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PFxsM15958; Thu, 25 Apr 2002 08:59:54 -0700 X-mProtect: <200204251559> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvPJdmt; Thu, 25 Apr 2002 08:59:52 PDT Message-ID: <3CC827F8.C347C2B2@iprg.nokia.com> Date: Thu, 25 Apr 2002 08:59:53 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: monet@nal.motlabs.com, manet@ietf.org Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, You can use "charles.perkins@nokia.com", but "cperkins@nokia.com" probably didn't work... Phil Neumiller wrote: > The draft draft-wakikawa-manet-globalv6-00.txt advocates adding an M-bit to the > router solicitation message which allows source IPv6 DAD'd addresses for link > local addresses to be forwarded over a MANET to an Internet gateway. > > Rather than mucking with the solicitation and advertisements, an alternative might be > the following. At least this seems to work for me. > > 1). Allow the host to own a globally routable MIPv6 home address (possibly with its > own DNS entry). Surely, this is always allowed, even preferred. > 2). The mobile MUST use this home address when forming a MANET. I don't think this is acceptable, nor in the spirit of IPv6 address autoconfiguration. I have always thought that any IPv6 node should be able to use any address that it can successfully (and correcctly) configure. > 3). The mobile MUST be a MIPv6 client. What if it doesn't want to use its home address, and just wants to use a fixed address in the foreign domain that happens to be extended at some wireless access point into an ad hoc network? > 4). In the mobile's HA coverage area, assuming a set of fixed MANET > wireless routers supply this, the node will be reachable. I could not quite parse this. I guess it supposes that there is a home agent with a wireless interface. I also guess that you are setting the stage for (5). > 5). When the node wanders to a foreign MANET coverage area with a different subnet, > it may acquire a COA from DHCPv6, and be routable on that MANET subnet under > that gateway. Ahh! Finally we have total agreement :-) It is our purpose to provide for stateless autoconfiguration as well as stateful autoconfiguration. So, I reckon that both have to be specified. I also guess that eventually we will need some pretty simple text about DHCPv6 operation in the Globalv6 draft. > 6). Let's postpone the inevitable security discussion for the moment. > > It seems to me, that this has the desired effect of global connectivity for MANETs, does > not require any new messages, can be built today, and solves the NEMO problem as > well as the MANET global connectivity problem. But then again, I could be missing > something. Gentlefolk, start your flame throwers!!! ... darn, mine wouldn't start ... Got any gas? Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 15:06:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02248 for ; Thu, 25 Apr 2002 15:06:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29772; Thu, 25 Apr 2002 14:21:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29717 for ; Thu, 25 Apr 2002 14:21:21 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00846 for ; Thu, 25 Apr 2002 14:21:17 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA21437; Thu, 25 Apr 2002 11:20:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PIKlm28924; Thu, 25 Apr 2002 11:20:47 -0700 X-mProtect: <200204251820> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVmVdND; Thu, 25 Apr 2002 11:20:45 PDT Message-ID: <3CC848FE.166D2E8A@iprg.nokia.com> Date: Thu, 25 Apr 2002 11:20:46 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: monet@nal.motlabs.com, manet@ietf.org Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > > > > 2). The mobile MUST use this home address when forming a MANET. > > > > I don't think this is acceptable, nor in the spirit of IPv6 address > > autoconfiguration. I have always thought that any IPv6 node should > > be able to use any address that it can successfully (and correcctly) > > configure. > > Aaaw, why not? It seems that *if* the MN has this MIPv6 home address in its > hip pocket doing nothing, it COULD be used for MANET addressing since it > is guaranteed to be unique. NOTE: I am not suggesting precluding the > autoconfigured address, just suggesting the use of the MIPv6 home address as > a viable option. I certainly agree that it should be a viable, and even preferred, option. I was only reacting to your "MUST". > > > 3). The mobile MUST be a MIPv6 client. > > > > What if it doesn't want to use its home address, and just wants > > to use a fixed address in the foreign domain that happens to be > > extended at some wireless access point into an ad hoc network? > > Yes, and that is LIKELY to be be COA *if* the MN is indeed a MIPv6 client > right? Furthermore, the COA is likely to be gotten from DHCPv6 right? I agree with your first statement. More on the second one down below. > > > 4). In the mobile's HA coverage area, assuming a set of fixed MANET > > > wireless routers supply this, the node will be reachable. > > > > I could not quite parse this. I guess it supposes that there is a > > home agent with a wireless interface. I also guess that you are > > setting the stage for (5). > > For NEMO: > My assumption is that you either have a mobile network with a gateway node > that speaks MANET on the inside and MAY speak OSPF or BGP (throwing > Jim a bone) on the outside of the NEMO. Alternatively, it may simply be a > BOOTp/DHCP relay that acquires its address from DHCPv6 and routes packets > to the MANET inside the NEMO. This is all fine with me. > Either way you slice that it comes out allowing global connectivity of the MNNs > or MNs or whatever you want to call the hosts. BTW, we should also consider > the situation where the transceiver (assuming wireless) has its own IP address > (MANET routable) and the host either has the MIPv6 home address or COA. This is also all fine with me. >>> 5). When the node wanders to a foreign MANET coverage area with a different >>> subnet, it may acquire a COA from DHCPv6, and be routable on that MANET >>> subnet under that gateway. >> >> Ahh! Finally we have total agreement :-) > > Except for the fact that I like the idea of using the COA as the MANET > routing address as well... Of course, I like this idea also! In fact, if the mobile node has a care-of address and is using Mobile IP, then this is almost definitional. > > It is our purpose to provide for stateless autoconfiguration > > as well as stateful autoconfiguration. So, I reckon that > > both have to be specified. I also guess that eventually we > > will need some pretty simple text about DHCPv6 operation in > > the Globalv6 draft. > > OK, so what you are saying is that M-bit is still needed for stateless > autoconfiguration. > What is the advantage of stateless autoconfiguraion to a MANET? The advantage is that it can work completely without infrastructure, including without DHCP. I think that DHCP is infrastructure. > Isn't DaD going to be a lot harder? Well, it's certainly a lot more error-prone. But since we're expecting it to be unnecessary with probability (1 - 2^(-64)), the problem is not SO severe as it might be otherwise. And, DAD will work whenever the network can reasonably support it (by, for instance, being connected). > Also, it seems that when the MN is handing off between domains it > may have to go into an expanded ring search. This is pretty yucky for smooth/seamless/ > soft/fluffy handovers. I prefer my stateful method for this reason for MANET's that > provide infrastructures. What say you? It could well be that stateful is better in many situations, but that is a lot different than saying it has to be mandated in all situations. And, I still like the idea of infrastructureless operation. What happens when such an infrastructureless network finally makes contact with a gateway? Here, it's debatable about what to do with applications that are already running using an address which was statelessly autoconfigured before the contact was made. DHCP almost certainly can't be the whole answer. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 25 15:06:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02259 for ; Thu, 25 Apr 2002 15:06:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03061 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 15:06:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29772; Thu, 25 Apr 2002 14:21:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29717 for ; Thu, 25 Apr 2002 14:21:21 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00846 for ; Thu, 25 Apr 2002 14:21:17 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA21437; Thu, 25 Apr 2002 11:20:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PIKlm28924; Thu, 25 Apr 2002 11:20:47 -0700 X-mProtect: <200204251820> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVmVdND; Thu, 25 Apr 2002 11:20:45 PDT Message-ID: <3CC848FE.166D2E8A@iprg.nokia.com> Date: Thu, 25 Apr 2002 11:20:46 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: monet@nal.motlabs.com, manet@ietf.org Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > > > > 2). The mobile MUST use this home address when forming a MANET. > > > > I don't think this is acceptable, nor in the spirit of IPv6 address > > autoconfiguration. I have always thought that any IPv6 node should > > be able to use any address that it can successfully (and correcctly) > > configure. > > Aaaw, why not? It seems that *if* the MN has this MIPv6 home address in its > hip pocket doing nothing, it COULD be used for MANET addressing since it > is guaranteed to be unique. NOTE: I am not suggesting precluding the > autoconfigured address, just suggesting the use of the MIPv6 home address as > a viable option. I certainly agree that it should be a viable, and even preferred, option. I was only reacting to your "MUST". > > > 3). The mobile MUST be a MIPv6 client. > > > > What if it doesn't want to use its home address, and just wants > > to use a fixed address in the foreign domain that happens to be > > extended at some wireless access point into an ad hoc network? > > Yes, and that is LIKELY to be be COA *if* the MN is indeed a MIPv6 client > right? Furthermore, the COA is likely to be gotten from DHCPv6 right? I agree with your first statement. More on the second one down below. > > > 4). In the mobile's HA coverage area, assuming a set of fixed MANET > > > wireless routers supply this, the node will be reachable. > > > > I could not quite parse this. I guess it supposes that there is a > > home agent with a wireless interface. I also guess that you are > > setting the stage for (5). > > For NEMO: > My assumption is that you either have a mobile network with a gateway node > that speaks MANET on the inside and MAY speak OSPF or BGP (throwing > Jim a bone) on the outside of the NEMO. Alternatively, it may simply be a > BOOTp/DHCP relay that acquires its address from DHCPv6 and routes packets > to the MANET inside the NEMO. This is all fine with me. > Either way you slice that it comes out allowing global connectivity of the MNNs > or MNs or whatever you want to call the hosts. BTW, we should also consider > the situation where the transceiver (assuming wireless) has its own IP address > (MANET routable) and the host either has the MIPv6 home address or COA. This is also all fine with me. >>> 5). When the node wanders to a foreign MANET coverage area with a different >>> subnet, it may acquire a COA from DHCPv6, and be routable on that MANET >>> subnet under that gateway. >> >> Ahh! Finally we have total agreement :-) > > Except for the fact that I like the idea of using the COA as the MANET > routing address as well... Of course, I like this idea also! In fact, if the mobile node has a care-of address and is using Mobile IP, then this is almost definitional. > > It is our purpose to provide for stateless autoconfiguration > > as well as stateful autoconfiguration. So, I reckon that > > both have to be specified. I also guess that eventually we > > will need some pretty simple text about DHCPv6 operation in > > the Globalv6 draft. > > OK, so what you are saying is that M-bit is still needed for stateless > autoconfiguration. > What is the advantage of stateless autoconfiguraion to a MANET? The advantage is that it can work completely without infrastructure, including without DHCP. I think that DHCP is infrastructure. > Isn't DaD going to be a lot harder? Well, it's certainly a lot more error-prone. But since we're expecting it to be unnecessary with probability (1 - 2^(-64)), the problem is not SO severe as it might be otherwise. And, DAD will work whenever the network can reasonably support it (by, for instance, being connected). > Also, it seems that when the MN is handing off between domains it > may have to go into an expanded ring search. This is pretty yucky for smooth/seamless/ > soft/fluffy handovers. I prefer my stateful method for this reason for MANET's that > provide infrastructures. What say you? It could well be that stateful is better in many situations, but that is a lot different than saying it has to be mandated in all situations. And, I still like the idea of infrastructureless operation. What happens when such an infrastructureless network finally makes contact with a gateway? Here, it's debatable about what to do with applications that are already running using an address which was statelessly autoconfigured before the contact was made. DHCP almost certainly can't be the whole answer. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 15:26:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03123 for ; Thu, 25 Apr 2002 15:26:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01579; Thu, 25 Apr 2002 14:45:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01548 for ; Thu, 25 Apr 2002 14:45:26 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01688 for ; Thu, 25 Apr 2002 14:45:23 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFCPJ; Thu, 25 Apr 2002 14:45:24 -0400 Message-ID: <002a01c1ec89$5c2d1e60$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: , References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> <3CC848FE.166D2E8A@iprg.nokia.com> Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt Date: Thu, 25 Apr 2002 14:45:24 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit > Charles E. Perkins wrote: > It could well be that stateful is better in many situations, but that > is a lot different than saying it has to be mandated in all situations. > And, I still like the idea of infrastructureless operation. What happens > when such an infrastructureless network finally makes contact with a > gateway? Here is where we differ. We could make it a MUST to be a MIPv6 client to be globally connectable and NEMO'able (I can hear the moans!). If we did that... then when MNs are operating in an infrastructureless MANET, they simply use their MIPv6 home addresses for their address. Now when this infrastructureless MN wanders into its home network its all ready to route both as a MANET node and as a MIPv6 client. If it happens to wander into a foreign network, it by definition MUST acquire its COA, and it must now route MANET wise with the COA rather than the home address. Did I mention DHCP anywhere here? :-) DHCPCOULD be used to acquire the COA and that would be convenient. Howz that sound? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Thu Apr 25 15:26:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03134 for ; Thu, 25 Apr 2002 15:26:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04210 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 15:26:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01579; Thu, 25 Apr 2002 14:45:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01548 for ; Thu, 25 Apr 2002 14:45:26 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01688 for ; Thu, 25 Apr 2002 14:45:23 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFCPJ; Thu, 25 Apr 2002 14:45:24 -0400 Message-ID: <002a01c1ec89$5c2d1e60$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: , References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> <3CC848FE.166D2E8A@iprg.nokia.com> Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt Date: Thu, 25 Apr 2002 14:45:24 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit > Charles E. Perkins wrote: > It could well be that stateful is better in many situations, but that > is a lot different than saying it has to be mandated in all situations. > And, I still like the idea of infrastructureless operation. What happens > when such an infrastructureless network finally makes contact with a > gateway? Here is where we differ. We could make it a MUST to be a MIPv6 client to be globally connectable and NEMO'able (I can hear the moans!). If we did that... then when MNs are operating in an infrastructureless MANET, they simply use their MIPv6 home addresses for their address. Now when this infrastructureless MN wanders into its home network its all ready to route both as a MANET node and as a MIPv6 client. If it happens to wander into a foreign network, it by definition MUST acquire its COA, and it must now route MANET wise with the COA rather than the home address. Did I mention DHCP anywhere here? :-) DHCPCOULD be used to acquire the COA and that would be convenient. Howz that sound? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 16:21:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04787 for ; Thu, 25 Apr 2002 16:21:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04933; Thu, 25 Apr 2002 15:33:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04904 for ; Thu, 25 Apr 2002 15:33:09 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03380 for ; Thu, 25 Apr 2002 15:33:05 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA25614; Thu, 25 Apr 2002 12:32:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PJWaA19285; Thu, 25 Apr 2002 12:32:36 -0700 X-mProtect: <200204251932> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeJ78XF; Thu, 25 Apr 2002 12:32:34 PDT Message-ID: <3CC859D2.BDEC4DDB@iprg.nokia.com> Date: Thu, 25 Apr 2002 12:32:34 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: monet@nal.motlabs.com, manet@ietf.org Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> <3CC848FE.166D2E8A@iprg.nokia.com> <002a01c1ec89$5c2d1e60$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > Here is where we differ. We could make it a MUST to be a MIPv6 > client to be globally connectable and NEMO'able (I can hear the moans!). > If we did that... then when MNs are operating in an infrastructureless > MANET, they simply use their MIPv6 home addresses for their address. > Now when this infrastructureless MN wanders into its home network its > all ready to route both as a MANET node and as a MIPv6 client. > If it happens to wander into a foreign network, it by definition MUST acquire > its COA, and it must now route MANET wise with the COA rather than > the home address. Did I mention DHCP anywhere here? :-) DHCPCOULD > be used to acquire the COA and that would be convenient. Howz that > sound? If you can sell it, then it's fine with me. The more Mobile IPv6, the better. However, I think it is very helpful to understand at a very deep level that address autoconfiguration is different than Mobile IPv6, and also that Internet Gateway operation for mobile ad-hoc networks is also different than Mobile IPv6. Similarly, I would be very leery of making extensions to Mobile IPv6 to support ad hoc networks. I wouldn't categorically reject the idea, but it would require a lot of justification. Plus, my example about transient connection to the Internet by a previously autoconfigured ad-hoc network needs to fit into whatever scheme is eventually devised. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Apr 25 16:21:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04799 for ; Thu, 25 Apr 2002 16:21:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07632 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 16:21:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04933; Thu, 25 Apr 2002 15:33:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04904 for ; Thu, 25 Apr 2002 15:33:09 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03380 for ; Thu, 25 Apr 2002 15:33:05 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA25614; Thu, 25 Apr 2002 12:32:37 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g3PJWaA19285; Thu, 25 Apr 2002 12:32:36 -0700 X-mProtect: <200204251932> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeJ78XF; Thu, 25 Apr 2002 12:32:34 PDT Message-ID: <3CC859D2.BDEC4DDB@iprg.nokia.com> Date: Thu, 25 Apr 2002 12:32:34 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: monet@nal.motlabs.com, manet@ietf.org Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> <3CC848FE.166D2E8A@iprg.nokia.com> <002a01c1ec89$5c2d1e60$6200000a@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > Here is where we differ. We could make it a MUST to be a MIPv6 > client to be globally connectable and NEMO'able (I can hear the moans!). > If we did that... then when MNs are operating in an infrastructureless > MANET, they simply use their MIPv6 home addresses for their address. > Now when this infrastructureless MN wanders into its home network its > all ready to route both as a MANET node and as a MIPv6 client. > If it happens to wander into a foreign network, it by definition MUST acquire > its COA, and it must now route MANET wise with the COA rather than > the home address. Did I mention DHCP anywhere here? :-) DHCPCOULD > be used to acquire the COA and that would be convenient. Howz that > sound? If you can sell it, then it's fine with me. The more Mobile IPv6, the better. However, I think it is very helpful to understand at a very deep level that address autoconfiguration is different than Mobile IPv6, and also that Internet Gateway operation for mobile ad-hoc networks is also different than Mobile IPv6. Similarly, I would be very leery of making extensions to Mobile IPv6 to support ad hoc networks. I wouldn't categorically reject the idea, but it would require a lot of justification. Plus, my example about transient connection to the Internet by a previously autoconfigured ad-hoc network needs to fit into whatever scheme is eventually devised. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 19:43:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09146 for ; Thu, 25 Apr 2002 19:43:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17892; Thu, 25 Apr 2002 19:06:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17864 for ; Thu, 25 Apr 2002 19:06:24 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08655 for ; Thu, 25 Apr 2002 19:06:21 -0400 (EDT) Received: from Sior_Panagakhs.cornell.edu (dhcp28-224.ece.cornell.edu [128.84.224.139]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g3PN6K111279; Thu, 25 Apr 2002 19:06:20 -0400 Message-Id: <5.1.0.14.2.20020425173754.02a9f5c8@memphis.ece.cornell.edu> X-Sender: papadp@memphis.ece.cornell.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 19:07:59 -0400 To: "Claude Castelluccia" From: Panos Papadimitratos Subject: Re: [manet] Re: Re Security considerations in MANET Cc: manet@ietf.org In-Reply-To: <00bc01c1ec2b$95a8c8a0$1d1fc7c2@charmette.inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA17865 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Claude, >Hello Panos, > >>First, it is important to realize that not all security solutions can be >>applied in all ad hoc networking environments. At one extreme, the >>conference room resources can use location authentication, i.e., no access >>constraint other than the mobile device location (e.g., short range IR of >i am not convinced that this is enough...sometimes you don't want everbody >in the conference room being able to play with your presentation ;-) Right, I will keep the audience beyond the transmission range of the projector. :-) I chose this example as an extreme case... We could shift a little, by considering passwords, PINs, etc. >>Second, the point of crucial importance for the securing MANET, at least as >>far as I am concerned, is to make clear distinction between: >>-Security of the MANET-based application. >>-Security of the basic networking services. >I do not quite agree with this distinction: the security of the MANET-based >application *depends* on the security of the basic networking services as least as DoS attacks are >concerned... If the networking services can not protect you from DoS attacks there is not >much you can do at the application level...isn't it? I mean that they are two different things. A declaration of independence was not my intention :-). The differentiation is important in MANET, because there is no fixed infrastructure that can be expected to operate correctly, making security solutions from the transport layer and above a reasonable choice. So, of course, it's much easier to abuse the MANET routing protocol and cause a DoS, than attacking SSH. >>The challenge is exactly to achieve the latter. And, it has to be done for >>the wide range of network instances between the two above-mentioned >>extremes. And, it has to be done in a way that “understands” the MANET >>paradigm, and does not transplant secure Internet routing solutions. > >i agree. > >>This is what seems to be happening with most of the secure routing >>solutions for MANET, as we explain in: >> >>P.Papadimitratos and Z.J. Haas, "Secure Routing for Mobile Ad Hoc >>Networks," SCS Communication Networks and Distributed Systems Modeling and >>Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31, 2002. >> >>The rationale behind the Secure Routing Protocol (SRP) in a few lines is: >> >>Even if you have the appropriate distributed CA instantiation (which you >>can have - see Zhou & Haas), it is not feasible to cryptographically >>validate every single in-transit control packet, even with the upcoming >>commercial mobile devices. > >this might be true but i am not convinced about that statement yet >especially if you consider new low-cost authentication schemes such as Biba, Tesla and >others... probably some more work is required in this area .... Such protocols, developed to authenticate multicast streams, have specific assumptions and requirements that have to 'fit' (or forced to fit...) in the specific MANET instance, and that's something I am not sure we can do. >>For clarifications, or if you want to hear some possible attacks on the >>discussed protocols (:-), please, don’t hesitate… > >i'd like very much to hear about those attacks... Ok, let me try a simple one on S-AODV, and let me know what you think. For example, every intermediate node (IN) that overheard a fresh enough RREP to a destination (D) can reply to a query from S (with RREQ destination sequence number <=) claiming an arbitrary IN -> D hop count. In our case, it's best for the malicious node to make this as short as possible, i.e., 1. S will most probably accept this reply, which was returned fast, it is fresh, and it will deter other RREP's with the correct but higher hop count. > > >thanks, >regards, >Claude. Thanks for your comments, Panos _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Apr 25 19:43:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09157 for ; Thu, 25 Apr 2002 19:43:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA19610 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 19:43:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17892; Thu, 25 Apr 2002 19:06:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17864 for ; Thu, 25 Apr 2002 19:06:24 -0400 (EDT) Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08655 for ; Thu, 25 Apr 2002 19:06:21 -0400 (EDT) Received: from Sior_Panagakhs.cornell.edu (dhcp28-224.ece.cornell.edu [128.84.224.139]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id g3PN6K111279; Thu, 25 Apr 2002 19:06:20 -0400 Message-Id: <5.1.0.14.2.20020425173754.02a9f5c8@memphis.ece.cornell.edu> X-Sender: papadp@memphis.ece.cornell.edu X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Apr 2002 19:07:59 -0400 To: "Claude Castelluccia" From: Panos Papadimitratos Subject: Re: [manet] Re: Re Security considerations in MANET Cc: manet@ietf.org In-Reply-To: <00bc01c1ec2b$95a8c8a0$1d1fc7c2@charmette.inrialpes.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA17865 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hi Claude, >Hello Panos, > >>First, it is important to realize that not all security solutions can be >>applied in all ad hoc networking environments. At one extreme, the >>conference room resources can use location authentication, i.e., no access >>constraint other than the mobile device location (e.g., short range IR of >i am not convinced that this is enough...sometimes you don't want everbody >in the conference room being able to play with your presentation ;-) Right, I will keep the audience beyond the transmission range of the projector. :-) I chose this example as an extreme case... We could shift a little, by considering passwords, PINs, etc. >>Second, the point of crucial importance for the securing MANET, at least as >>far as I am concerned, is to make clear distinction between: >>-Security of the MANET-based application. >>-Security of the basic networking services. >I do not quite agree with this distinction: the security of the MANET-based >application *depends* on the security of the basic networking services as least as DoS attacks are >concerned... If the networking services can not protect you from DoS attacks there is not >much you can do at the application level...isn't it? I mean that they are two different things. A declaration of independence was not my intention :-). The differentiation is important in MANET, because there is no fixed infrastructure that can be expected to operate correctly, making security solutions from the transport layer and above a reasonable choice. So, of course, it's much easier to abuse the MANET routing protocol and cause a DoS, than attacking SSH. >>The challenge is exactly to achieve the latter. And, it has to be done for >>the wide range of network instances between the two above-mentioned >>extremes. And, it has to be done in a way that “understands” the MANET >>paradigm, and does not transplant secure Internet routing solutions. > >i agree. > >>This is what seems to be happening with most of the secure routing >>solutions for MANET, as we explain in: >> >>P.Papadimitratos and Z.J. Haas, "Secure Routing for Mobile Ad Hoc >>Networks," SCS Communication Networks and Distributed Systems Modeling and >>Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31, 2002. >> >>The rationale behind the Secure Routing Protocol (SRP) in a few lines is: >> >>Even if you have the appropriate distributed CA instantiation (which you >>can have - see Zhou & Haas), it is not feasible to cryptographically >>validate every single in-transit control packet, even with the upcoming >>commercial mobile devices. > >this might be true but i am not convinced about that statement yet >especially if you consider new low-cost authentication schemes such as Biba, Tesla and >others... probably some more work is required in this area .... Such protocols, developed to authenticate multicast streams, have specific assumptions and requirements that have to 'fit' (or forced to fit...) in the specific MANET instance, and that's something I am not sure we can do. >>For clarifications, or if you want to hear some possible attacks on the >>discussed protocols (:-), please, don’t hesitate… > >i'd like very much to hear about those attacks... Ok, let me try a simple one on S-AODV, and let me know what you think. For example, every intermediate node (IN) that overheard a fresh enough RREP to a destination (D) can reply to a query from S (with RREQ destination sequence number <=) claiming an arbitrary IN -> D hop count. In our case, it's best for the malicious node to make this as short as possible, i.e., 1. S will most probably accept this reply, which was returned fast, it is fresh, and it will deter other RREP's with the correct but higher hop count. > > >thanks, >regards, >Claude. Thanks for your comments, Panos _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 22:27:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12650 for ; Thu, 25 Apr 2002 22:27:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25308; Thu, 25 Apr 2002 21:48:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25276 for ; Thu, 25 Apr 2002 21:48:16 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11906 for ; Thu, 25 Apr 2002 21:48:11 -0400 (EDT) Received: from ella (ella [128.111.49.42]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3Q1mCO05184 for ; Thu, 25 Apr 2002 18:48:12 -0700 (PDT) Date: Thu, 25 Apr 2002 18:48:12 -0700 (PDT) From: Sumit Gwalani X-Sender: sumitg@ella To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Link layer notification Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello all, Just wondering if anyone can help me with the following: How can I implement "detecting link level notfication to determine connectivity" ? Are there any tools available for this? Thanks, Sumit _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Apr 25 22:27:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12665 for ; Thu, 25 Apr 2002 22:27:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA27883 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 22:28:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25308; Thu, 25 Apr 2002 21:48:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25276 for ; Thu, 25 Apr 2002 21:48:16 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11906 for ; Thu, 25 Apr 2002 21:48:11 -0400 (EDT) Received: from ella (ella [128.111.49.42]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3Q1mCO05184 for ; Thu, 25 Apr 2002 18:48:12 -0700 (PDT) Date: Thu, 25 Apr 2002 18:48:12 -0700 (PDT) From: Sumit Gwalani X-Sender: sumitg@ella To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Link layer notification Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello all, Just wondering if anyone can help me with the following: How can I implement "detecting link level notfication to determine connectivity" ? Are there any tools available for this? Thanks, Sumit _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Thu Apr 25 22:56:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14190 for ; Thu, 25 Apr 2002 22:56:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27600; Thu, 25 Apr 2002 22:24:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27561 for ; Thu, 25 Apr 2002 22:23:50 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12590 for ; Thu, 25 Apr 2002 22:23:43 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8c19.tkyoac00.ap.so-net.ne.jp [218.221.140.25]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g3Q2MRdl012357; Fri, 26 Apr 2002 11:22:29 +0900 Date: Thu, 25 Apr 2002 09:10:35 +0000 Message-ID: From: Ryuji Wakikawa To: pneumiller@meshnetworks.com Sent-via: pneumiller@meshnetworks.com Cc: charliep@IPRG.nokia.com, monet@nal.motlabs.com, manet@ietf.org Sent-via: charliep@IPRG.nokia.com, monet@nal.motlabs.com, manet@ietf.org Subject: Re: [monet] Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt In-Reply-To: <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Phil and Charlie. At Thu, 25 Apr 2002 13:42:13 -0400, Phil Neumiller wrote: > > > > 2). The mobile MUST use this home address when forming a MANET. > > > > I don't think this is acceptable, nor in the spirit of IPv6 address > > autoconfiguration. I have always thought that any IPv6 node should > > be able to use any address that it can successfully (and correcctly) > > configure. > > Aaaw, why not? It seems that *if* the MN has this MIPv6 home address in its > hip pocket doing nothing, it COULD be used for MANET addressing since it > is guaranteed to be unique. NOTE: I am not suggesting precluding the > autoconfigured address, just suggesting the use of the MIPv6 home address as > a viable option. We never disregard MIP6 in the draft, we've mentioned the operation of MIP6 in Appendix. But we do not want to force MIP6. This looks more like operational issue (someone may not want to use MIP6 on MANET) . > > > > > 3). The mobile MUST be a MIPv6 client. > > > > What if it doesn't want to use its home address, and just wants > > to use a fixed address in the foreign domain that happens to be > > extended at some wireless access point into an ad hoc network? > > Yes, and that is LIKELY to be be COA *if* the MN is indeed a MIPv6 client > right? Furthermore, the COA is likely to be gotten from DHCPv6 right? What is the difference between COA and autoconfigured IPv6 address? If node is MIP6 capable node, the address can be called COA. If the node is not MIP6 capable, the address can be called IPv6 autoconfigured address. There is no quite difference for these address to me. > > > 4). In the mobile's HA coverage area, assuming a set of fixed MANET > > > wireless routers supply this, the node will be reachable. > > > > I could not quite parse this. I guess it supposes that there is a > > home agent with a wireless interface. I also guess that you are > > setting the stage for (5). > > For NEMO: > My assumption is that you either have a mobile network with a gateway node > that speaks MANET on the inside and MAY speak OSPF or BGP (throwing > Jim a bone) on the outside of the NEMO. Alternatively, it may simply be a > BOOTp/DHCP relay that acquires its address from DHCPv6 and routes packets > to the MANET inside the NEMO. > > Either way you slice that it comes out allowing global connectivity of the MNNs > or MNs or whatever you want to call the hosts. BTW, we should also consider > the situation where the transceiver (assuming wireless) has its own IP address > (MANET routable) and the host either has the MIPv6 home address or COA. We do not limit adduress acquiring method (just use DHCP) on MANET. In the draft, we present two way to aquire global address from Gateway. So DHCP will be third possible way, but DHCP need additional server on MANET. But I think some documents will be needed as Charlie said. We expect nodes to access gateway before it sending packets to the Internet. Then gateway can examine whether the destination is locates in MANET or in the Internet. see section 9.1 "Route examination during communciation". When node discover gateway, gateway records node's reverse route at the same time. If we use BOOTp/DHCP, how can gateway record its reverse route? > > > > > 5). When the node wanders to a foreign MANET coverage area with a different subnet, > > > it may acquire a COA from DHCPv6, and be routable on that MANET subnet under > > > that gateway. > > > > Ahh! Finally we have total agreement :-) > > Except for the fact that I like the idea of using the COA as the MANET routing address as > well... > > > > > It is our purpose to provide for stateless autoconfiguration > > as well as stateful autoconfiguration. So, I reckon that > > both have to be specified. I also guess that eventually we > > will need some pretty simple text about DHCPv6 operation in > > the Globalv6 draft. > > OK, so what you are saying is that M-bit is still needed for stateless autoconfiguration. > What is the advantage of stateless autoconfiguraion to a MANET? Isn't DaD going to > be a lot harder? Also, it seems that when the MN is handing off between domains it > may have to go into an expanded ring search. This is pretty yucky for smooth/seamless/ > soft/fluffy handovers. I prefer my stateful method for this reason for MANET's that > provide infrastructures. What say you? For address aquisition, DAD will be done for link-local address by draft-ietf-manet-autocon-01.txt. So we may eliminate DAD operation for global address, if global address is generated by global prefix and host ID(EUI64). regards, ryuji _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Thu Apr 25 22:56:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14201 for ; Thu, 25 Apr 2002 22:56:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA29353 for manet-archive@odin.ietf.org; Thu, 25 Apr 2002 22:56:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27600; Thu, 25 Apr 2002 22:24:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27561 for ; Thu, 25 Apr 2002 22:23:50 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12590 for ; Thu, 25 Apr 2002 22:23:43 -0400 (EDT) Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8c19.tkyoac00.ap.so-net.ne.jp [218.221.140.25]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g3Q2MRdl012357; Fri, 26 Apr 2002 11:22:29 +0900 Date: Thu, 25 Apr 2002 09:10:35 +0000 Message-ID: From: Ryuji Wakikawa To: pneumiller@meshnetworks.com Sent-via: pneumiller@meshnetworks.com Cc: charliep@IPRG.nokia.com, monet@nal.motlabs.com, manet@ietf.org Sent-via: charliep@IPRG.nokia.com, monet@nal.motlabs.com, manet@ietf.org Subject: Re: [monet] Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt In-Reply-To: <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Phil and Charlie. At Thu, 25 Apr 2002 13:42:13 -0400, Phil Neumiller wrote: > > > > 2). The mobile MUST use this home address when forming a MANET. > > > > I don't think this is acceptable, nor in the spirit of IPv6 address > > autoconfiguration. I have always thought that any IPv6 node should > > be able to use any address that it can successfully (and correcctly) > > configure. > > Aaaw, why not? It seems that *if* the MN has this MIPv6 home address in its > hip pocket doing nothing, it COULD be used for MANET addressing since it > is guaranteed to be unique. NOTE: I am not suggesting precluding the > autoconfigured address, just suggesting the use of the MIPv6 home address as > a viable option. We never disregard MIP6 in the draft, we've mentioned the operation of MIP6 in Appendix. But we do not want to force MIP6. This looks more like operational issue (someone may not want to use MIP6 on MANET) . > > > > > 3). The mobile MUST be a MIPv6 client. > > > > What if it doesn't want to use its home address, and just wants > > to use a fixed address in the foreign domain that happens to be > > extended at some wireless access point into an ad hoc network? > > Yes, and that is LIKELY to be be COA *if* the MN is indeed a MIPv6 client > right? Furthermore, the COA is likely to be gotten from DHCPv6 right? What is the difference between COA and autoconfigured IPv6 address? If node is MIP6 capable node, the address can be called COA. If the node is not MIP6 capable, the address can be called IPv6 autoconfigured address. There is no quite difference for these address to me. > > > 4). In the mobile's HA coverage area, assuming a set of fixed MANET > > > wireless routers supply this, the node will be reachable. > > > > I could not quite parse this. I guess it supposes that there is a > > home agent with a wireless interface. I also guess that you are > > setting the stage for (5). > > For NEMO: > My assumption is that you either have a mobile network with a gateway node > that speaks MANET on the inside and MAY speak OSPF or BGP (throwing > Jim a bone) on the outside of the NEMO. Alternatively, it may simply be a > BOOTp/DHCP relay that acquires its address from DHCPv6 and routes packets > to the MANET inside the NEMO. > > Either way you slice that it comes out allowing global connectivity of the MNNs > or MNs or whatever you want to call the hosts. BTW, we should also consider > the situation where the transceiver (assuming wireless) has its own IP address > (MANET routable) and the host either has the MIPv6 home address or COA. We do not limit adduress acquiring method (just use DHCP) on MANET. In the draft, we present two way to aquire global address from Gateway. So DHCP will be third possible way, but DHCP need additional server on MANET. But I think some documents will be needed as Charlie said. We expect nodes to access gateway before it sending packets to the Internet. Then gateway can examine whether the destination is locates in MANET or in the Internet. see section 9.1 "Route examination during communciation". When node discover gateway, gateway records node's reverse route at the same time. If we use BOOTp/DHCP, how can gateway record its reverse route? > > > > > 5). When the node wanders to a foreign MANET coverage area with a different subnet, > > > it may acquire a COA from DHCPv6, and be routable on that MANET subnet under > > > that gateway. > > > > Ahh! Finally we have total agreement :-) > > Except for the fact that I like the idea of using the COA as the MANET routing address as > well... > > > > > It is our purpose to provide for stateless autoconfiguration > > as well as stateful autoconfiguration. So, I reckon that > > both have to be specified. I also guess that eventually we > > will need some pretty simple text about DHCPv6 operation in > > the Globalv6 draft. > > OK, so what you are saying is that M-bit is still needed for stateless autoconfiguration. > What is the advantage of stateless autoconfiguraion to a MANET? Isn't DaD going to > be a lot harder? Also, it seems that when the MN is handing off between domains it > may have to go into an expanded ring search. This is pretty yucky for smooth/seamless/ > soft/fluffy handovers. I prefer my stateful method for this reason for MANET's that > provide infrastructures. What say you? For address aquisition, DAD will be done for link-local address by draft-ietf-manet-autocon-01.txt. So we may eliminate DAD operation for global address, if global address is generated by global prefix and host ID(EUI64). regards, ryuji _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 26 06:35:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29052 for ; Fri, 26 Apr 2002 06:35:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29681; Fri, 26 Apr 2002 06:08:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29652 for ; Fri, 26 Apr 2002 06:08:06 -0400 (EDT) Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28687 for ; Fri, 26 Apr 2002 06:08:02 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by tc-mail.insa-lyon.fr (Postfix) with ESMTP id A269E13A20; Fri, 26 Apr 2002 12:07:53 +0200 (CEST) Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151) id 28B0813A10; Fri, 26 Apr 2002 12:07:53 +0200 (CEST) To: "Charles E. Perkins" Subject: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt Message-ID: <1019815673.3cc926f921829@tc-mail.insa-lyon.fr> Date: Fri, 26 Apr 2002 12:07:53 +0200 (CEST) From: Guillaume Chelius Cc: Phil Neumiller , monet@nal.motlabs.com, manet@ietf.org References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> <3CC848FE.166D2E8A@iprg.nokia.com> In-Reply-To: <3CC848FE.166D2E8A@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Virus-Scanned: by AMaViS snapshot-20010714 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello, How does a node knows which of its interfaces are in "ad hoc mode" ? A node with several network interfaces may want only a subset of them to work as ad hoc interfaces (the case of ad hoc network gateways). To me, the process of flooding an ad hoc network requires a node to know which of its interfaces are ad hoc ones. A solution that we propose in IPv6 could be to associate a particular scope (subnet scope for example) with an ad hoc network and to give all ad hoc interfaces of a given node the same scope index. Thanks, Guillaume Chelius. ----------------- Guillaume Chelius PhD student Ares Team, Inria, Citi Insa-Lyon Tel: (+33) 472 436 421 Email: gchelius@telecom.insa-lyon.fr _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Apr 26 06:35:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29063 for ; Fri, 26 Apr 2002 06:35:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA01437 for manet-archive@odin.ietf.org; Fri, 26 Apr 2002 06:35:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29681; Fri, 26 Apr 2002 06:08:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29652 for ; Fri, 26 Apr 2002 06:08:06 -0400 (EDT) Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28687 for ; Fri, 26 Apr 2002 06:08:02 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by tc-mail.insa-lyon.fr (Postfix) with ESMTP id A269E13A20; Fri, 26 Apr 2002 12:07:53 +0200 (CEST) Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151) id 28B0813A10; Fri, 26 Apr 2002 12:07:53 +0200 (CEST) To: "Charles E. Perkins" Subject: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt Message-ID: <1019815673.3cc926f921829@tc-mail.insa-lyon.fr> Date: Fri, 26 Apr 2002 12:07:53 +0200 (CEST) From: Guillaume Chelius Cc: Phil Neumiller , monet@nal.motlabs.com, manet@ietf.org References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> <00b201c1ec80$89001ea0$6200000a@meshnetworks.com> <3CC848FE.166D2E8A@iprg.nokia.com> In-Reply-To: <3CC848FE.166D2E8A@iprg.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Virus-Scanned: by AMaViS snapshot-20010714 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello, How does a node knows which of its interfaces are in "ad hoc mode" ? A node with several network interfaces may want only a subset of them to work as ad hoc interfaces (the case of ad hoc network gateways). To me, the process of flooding an ad hoc network requires a node to know which of its interfaces are ad hoc ones. A solution that we propose in IPv6 could be to associate a particular scope (subnet scope for example) with an ad hoc network and to give all ad hoc interfaces of a given node the same scope index. Thanks, Guillaume Chelius. ----------------- Guillaume Chelius PhD student Ares Team, Inria, Citi Insa-Lyon Tel: (+33) 472 436 421 Email: gchelius@telecom.insa-lyon.fr _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 26 08:19:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00963 for ; Fri, 26 Apr 2002 08:19:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05409; Fri, 26 Apr 2002 07:51:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05381 for ; Fri, 26 Apr 2002 07:51:34 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00147 for ; Fri, 26 Apr 2002 07:51:32 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFC9Z; Fri, 26 Apr 2002 07:51:31 -0400 Message-ID: <009301c1ed18$b5332330$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Sumit Gwalani" , References: Subject: Re: [manet] Link layer notification Date: Fri, 26 Apr 2002 07:51:31 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Sumit, This is a "very good" question. I have tried for a couple years now to get some work started in the IETF with respect to L2 triggers. I think there was a BOF in Minneapolis, but I missed that. I am not sure where the work currently stands. Can somebody refresh us on this work? For what its worth, I have always wondered why the top half of TCP/IP is fair game for standardization i.e. sockets for example, yet the bottom half has to remain secretive/proprietary/custom. I have always liked the idea of exposing the underbelly of IP to L2's, i.e. create service access/provision points underneath IP that provide L2 layers an API into IP' underbelly. This being said, some of the most critical things we would need to communicate to IP from a wireless L2 would be detetion of pilots and/or beacons and signal strength information. There are many other things that would be useful as well like how the TOS and TTL fields are interpreted by the MAC. Maybe I should just write a draft and see what the IESG does with it??? ----- Original Message ----- From: "Sumit Gwalani" To: Sent: Thursday, April 25, 2002 9:48 PM Subject: [manet] Link layer notification > Hello all, > > Just wondering if anyone can help me with the following: > > How can I implement "detecting link level notfication to determine > connectivity" ? > Are there any tools available for this? > > Thanks, > Sumit > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Apr 26 08:19:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00975 for ; Fri, 26 Apr 2002 08:19:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07621 for manet-archive@odin.ietf.org; Fri, 26 Apr 2002 08:19:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05409; Fri, 26 Apr 2002 07:51:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05381 for ; Fri, 26 Apr 2002 07:51:34 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00147 for ; Fri, 26 Apr 2002 07:51:32 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFC9Z; Fri, 26 Apr 2002 07:51:31 -0400 Message-ID: <009301c1ed18$b5332330$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Sumit Gwalani" , References: Subject: Re: [manet] Link layer notification Date: Fri, 26 Apr 2002 07:51:31 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Sumit, This is a "very good" question. I have tried for a couple years now to get some work started in the IETF with respect to L2 triggers. I think there was a BOF in Minneapolis, but I missed that. I am not sure where the work currently stands. Can somebody refresh us on this work? For what its worth, I have always wondered why the top half of TCP/IP is fair game for standardization i.e. sockets for example, yet the bottom half has to remain secretive/proprietary/custom. I have always liked the idea of exposing the underbelly of IP to L2's, i.e. create service access/provision points underneath IP that provide L2 layers an API into IP' underbelly. This being said, some of the most critical things we would need to communicate to IP from a wireless L2 would be detetion of pilots and/or beacons and signal strength information. There are many other things that would be useful as well like how the TOS and TTL fields are interpreted by the MAC. Maybe I should just write a draft and see what the IESG does with it??? ----- Original Message ----- From: "Sumit Gwalani" To: Sent: Thursday, April 25, 2002 9:48 PM Subject: [manet] Link layer notification > Hello all, > > Just wondering if anyone can help me with the following: > > How can I implement "detecting link level notfication to determine > connectivity" ? > Are there any tools available for this? > > Thanks, > Sumit > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 26 10:31:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05856 for ; Fri, 26 Apr 2002 10:31:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13902; Fri, 26 Apr 2002 10:04:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13871 for ; Fri, 26 Apr 2002 10:04:31 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04767 for ; Fri, 26 Apr 2002 10:04:27 -0400 (EDT) Received: from caboose.cse.ucsc.edu (dsl3-63-249-65-45.cruzio.com [63.249.65.45]) by mail.cruzio.com with ESMTP id HAA16307 for ; Fri, 26 Apr 2002 07:18:07 -0700 (PDT) Message-Id: <5.1.0.14.0.20020426065718.034db008@mail.cruzio.com> X-Sender: chane@mail.cruzio.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Apr 2002 07:04:51 -0700 To: From: "Dr. Chane L. Fullmer" In-Reply-To: <009301c1ed18$b5332330$6200000a@meshnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] Link API was [ Link layer notification ] Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi All.. A couple of years back I presented a formal Link API design at the DC IETF meeting that was drafted in the DARPA GloMo project. Perhaps its time to drag it out and take another look? Provisions were made to pass information across the LL/IP interface, as well as to other protocols (ie, a Neighbor Protocol). --regards --chane (Joe: are the slides archived on-line somewhere... ??) >For what its worth, I have always wondered why the top half of TCP/IP is >fair game for standardization >i.e. sockets for example, yet the bottom half has to remain >secretive/proprietary/custom. I have always >liked the idea of exposing the underbelly of IP to L2's, i.e. create >service access/provision points >underneath IP that provide L2 layers an API into IP' underbelly. > >This being said, some of the most critical things we would need to >communicate to IP from a wireless >L2 would be detetion of pilots and/or beacons and signal strength >information. There are many >other things that would be useful as well like how the TOS and TTL fields >are interpreted by the MAC. >Maybe I should just write a draft and see what the IESG does with it??? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Apr 26 10:31:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05868 for ; Fri, 26 Apr 2002 10:31:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15928 for manet-archive@odin.ietf.org; Fri, 26 Apr 2002 10:31:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13902; Fri, 26 Apr 2002 10:04:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13871 for ; Fri, 26 Apr 2002 10:04:31 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04767 for ; Fri, 26 Apr 2002 10:04:27 -0400 (EDT) Received: from caboose.cse.ucsc.edu (dsl3-63-249-65-45.cruzio.com [63.249.65.45]) by mail.cruzio.com with ESMTP id HAA16307 for ; Fri, 26 Apr 2002 07:18:07 -0700 (PDT) Message-Id: <5.1.0.14.0.20020426065718.034db008@mail.cruzio.com> X-Sender: chane@mail.cruzio.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 26 Apr 2002 07:04:51 -0700 To: From: "Dr. Chane L. Fullmer" In-Reply-To: <009301c1ed18$b5332330$6200000a@meshnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] Link API was [ Link layer notification ] Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi All.. A couple of years back I presented a formal Link API design at the DC IETF meeting that was drafted in the DARPA GloMo project. Perhaps its time to drag it out and take another look? Provisions were made to pass information across the LL/IP interface, as well as to other protocols (ie, a Neighbor Protocol). --regards --chane (Joe: are the slides archived on-line somewhere... ??) >For what its worth, I have always wondered why the top half of TCP/IP is >fair game for standardization >i.e. sockets for example, yet the bottom half has to remain >secretive/proprietary/custom. I have always >liked the idea of exposing the underbelly of IP to L2's, i.e. create >service access/provision points >underneath IP that provide L2 layers an API into IP' underbelly. > >This being said, some of the most critical things we would need to >communicate to IP from a wireless >L2 would be detetion of pilots and/or beacons and signal strength >information. There are many >other things that would be useful as well like how the TOS and TTL fields >are interpreted by the MAC. >Maybe I should just write a draft and see what the IESG does with it??? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 26 11:20:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07538 for ; Fri, 26 Apr 2002 11:20:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16737; Fri, 26 Apr 2002 10:41:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16626 for ; Fri, 26 Apr 2002 10:41:02 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06210 for ; Fri, 26 Apr 2002 10:40:59 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFD1C; Fri, 26 Apr 2002 10:41:01 -0400 Message-ID: <013701c1ed30$617623b0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , "Dr. Chane L. Fullmer" References: <5.1.0.14.0.20020426065718.034db008@mail.cruzio.com> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Fri, 26 Apr 2002 10:40:59 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yes, it would be very interesting to see. I am not so much interested in standardizing the LLC/MAC layer API for the use of IP, as I am standardizing the bottom half of IP looking in from an LLC/MAC perspective. Think of me as an LLC/MAC that wants to make effective use of the stack above me and vice versa. The age old protocol stack pattern has been pretty much top down from day one. I would like more of object oriented perspective on the layers where we can look at the IP stack as a layer pattern with a top and bottom and the bottom gets specified as nicely and cleanly as the top has been. Any steps in this direction with respect to wireless LLC/MACs would be extermely beneficial. I am sure optical devices would benefit as well. -Phil ----- Original Message ----- From: "Dr. Chane L. Fullmer" To: Sent: Friday, April 26, 2002 10:04 AM Subject: [manet] Link API was [ Link layer notification ] > Hi All.. > > A couple of years back I presented a formal Link API design at the DC IETF > meeting that was drafted in the DARPA GloMo project. Perhaps its time to > drag it out and take another look? Provisions were made to pass > information across the LL/IP interface, as well as to other protocols (ie, > a Neighbor Protocol). > > --regards > --chane > > (Joe: are the slides archived on-line somewhere... ??) > > > >For what its worth, I have always wondered why the top half of TCP/IP is > >fair game for standardization > >i.e. sockets for example, yet the bottom half has to remain > >secretive/proprietary/custom. I have always > >liked the idea of exposing the underbelly of IP to L2's, i.e. create > >service access/provision points > >underneath IP that provide L2 layers an API into IP' underbelly. > > > >This being said, some of the most critical things we would need to > >communicate to IP from a wireless > >L2 would be detetion of pilots and/or beacons and signal strength > >information. There are many > >other things that would be useful as well like how the TOS and TTL fields > >are interpreted by the MAC. > >Maybe I should just write a draft and see what the IESG does with it??? > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Fri Apr 26 11:20:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07553 for ; Fri, 26 Apr 2002 11:20:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19419 for manet-archive@odin.ietf.org; Fri, 26 Apr 2002 11:20:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16737; Fri, 26 Apr 2002 10:41:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16626 for ; Fri, 26 Apr 2002 10:41:02 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06210 for ; Fri, 26 Apr 2002 10:40:59 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFD1C; Fri, 26 Apr 2002 10:41:01 -0400 Message-ID: <013701c1ed30$617623b0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: , "Dr. Chane L. Fullmer" References: <5.1.0.14.0.20020426065718.034db008@mail.cruzio.com> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Fri, 26 Apr 2002 10:40:59 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Yes, it would be very interesting to see. I am not so much interested in standardizing the LLC/MAC layer API for the use of IP, as I am standardizing the bottom half of IP looking in from an LLC/MAC perspective. Think of me as an LLC/MAC that wants to make effective use of the stack above me and vice versa. The age old protocol stack pattern has been pretty much top down from day one. I would like more of object oriented perspective on the layers where we can look at the IP stack as a layer pattern with a top and bottom and the bottom gets specified as nicely and cleanly as the top has been. Any steps in this direction with respect to wireless LLC/MACs would be extermely beneficial. I am sure optical devices would benefit as well. -Phil ----- Original Message ----- From: "Dr. Chane L. Fullmer" To: Sent: Friday, April 26, 2002 10:04 AM Subject: [manet] Link API was [ Link layer notification ] > Hi All.. > > A couple of years back I presented a formal Link API design at the DC IETF > meeting that was drafted in the DARPA GloMo project. Perhaps its time to > drag it out and take another look? Provisions were made to pass > information across the LL/IP interface, as well as to other protocols (ie, > a Neighbor Protocol). > > --regards > --chane > > (Joe: are the slides archived on-line somewhere... ??) > > > >For what its worth, I have always wondered why the top half of TCP/IP is > >fair game for standardization > >i.e. sockets for example, yet the bottom half has to remain > >secretive/proprietary/custom. I have always > >liked the idea of exposing the underbelly of IP to L2's, i.e. create > >service access/provision points > >underneath IP that provide L2 layers an API into IP' underbelly. > > > >This being said, some of the most critical things we would need to > >communicate to IP from a wireless > >L2 would be detetion of pilots and/or beacons and signal strength > >information. There are many > >other things that would be useful as well like how the TOS and TTL fields > >are interpreted by the MAC. > >Maybe I should just write a draft and see what the IESG does with it??? > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 26 15:19:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28373 for ; Fri, 26 Apr 2002 15:19:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15461; Fri, 26 Apr 2002 14:41:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15432 for ; Fri, 26 Apr 2002 14:41:23 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23643 for ; Fri, 26 Apr 2002 14:41:19 -0400 (EDT) Received: from webmail.drexel.edu (webmail.drexel.edu [129.25.3.29]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GV600FQ5UI5SH@mail.drexel.edu> for manet@ietf.org; Fri, 26 Apr 2002 14:39:41 -0400 (EDT) Date: Fri, 26 Apr 2002 14:50:27 -0400 From: Harpreet Arora To: manet Message-id: <3CD77449@webmail.drexel.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61.08 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 1 X-WebMail-Urgent: Y X-WebMail-UserID: ha33 X-EXP32-SerialNo: 00003005 Content-Transfer-Encoding: 7BIT Subject: [manet] QoS issues in MANETs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Hi, I am interested in finding the feasibility of a differentiated services model for MANETs. WHile thinking about the implementation of diffserv in MANETs, I came across the follwing problem : diffserv aims to push the complexity to the edge of the network, by dividing the network into edge and core nodes. How can we do this in a MANET? Specifically, how can we differentiate the network of nodes into edge and core nodes? Since the nodes are mobile, I feel that every node should have the capability of acting as an edge node, which would mark, meter and police the packets, and also as a core node, which would simply forward the packets on the basis of the DSCP. The nodes can assume either functionality depending on the situation. But what node assumes what functionality is the question. Any suggestions? Harpreet Research Assistant ECE Department, Drexel University Philadelphia, PA-19104 ******************************************************************** A dream is just a dream. A goal is a dream with a plan and a deadline. A candle brightens the world around it. Unfortunately, it creates a shadow of its own. It still serves the purpose it is meant for. ********************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 26 15:19:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28384 for ; Fri, 26 Apr 2002 15:19:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17910 for manet-archive@odin.ietf.org; Fri, 26 Apr 2002 15:19:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15461; Fri, 26 Apr 2002 14:41:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15432 for ; Fri, 26 Apr 2002 14:41:23 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23643 for ; Fri, 26 Apr 2002 14:41:19 -0400 (EDT) Received: from webmail.drexel.edu (webmail.drexel.edu [129.25.3.29]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GV600FQ5UI5SH@mail.drexel.edu> for manet@ietf.org; Fri, 26 Apr 2002 14:39:41 -0400 (EDT) Date: Fri, 26 Apr 2002 14:50:27 -0400 From: Harpreet Arora To: manet Message-id: <3CD77449@webmail.drexel.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61.08 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 1 X-WebMail-Urgent: Y X-WebMail-UserID: ha33 X-EXP32-SerialNo: 00003005 Content-Transfer-Encoding: 7BIT Subject: [manet] QoS issues in MANETs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Hi, I am interested in finding the feasibility of a differentiated services model for MANETs. WHile thinking about the implementation of diffserv in MANETs, I came across the follwing problem : diffserv aims to push the complexity to the edge of the network, by dividing the network into edge and core nodes. How can we do this in a MANET? Specifically, how can we differentiate the network of nodes into edge and core nodes? Since the nodes are mobile, I feel that every node should have the capability of acting as an edge node, which would mark, meter and police the packets, and also as a core node, which would simply forward the packets on the basis of the DSCP. The nodes can assume either functionality depending on the situation. But what node assumes what functionality is the question. Any suggestions? Harpreet Research Assistant ECE Department, Drexel University Philadelphia, PA-19104 ******************************************************************** A dream is just a dream. A goal is a dream with a plan and a deadline. A candle brightens the world around it. Unfortunately, it creates a shadow of its own. It still serves the purpose it is meant for. ********************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 26 15:21:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28548 for ; Fri, 26 Apr 2002 15:21:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16342; Fri, 26 Apr 2002 14:56:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16314 for ; Fri, 26 Apr 2002 14:56:12 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25447 for ; Fri, 26 Apr 2002 14:56:07 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA07326; Fri, 26 Apr 2002 11:56:11 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA20739; Fri, 26 Apr 2002 11:56:03 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g3QIu2J19617; Fri, 26 Apr 2002 13:56:02 -0500 (CDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Apr 2002 14:56:02 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A38C2@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Harpreet Arora'" , manet Subject: RE: [manet] QoS issues in MANETs Date: Fri, 26 Apr 2002 14:56:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Arora, Actually, diffserv pretty much acknowledges that every "core" node can just as easily also be an "edge" node, and may therefore have to worry about such complexities as access control from edge hosts. There is no attempt to prevent core nodes from being edge nodes. But diffserv does not get into any sort of signaling or access control mechanisms between diffserv nodes and edge user hosts. People have mentioned possible signaling mechanisms for use in diffserv nets, such as the RSVP PATH and RESV messages. But always, such discussions were cut short on the list, because they are not germaine to diffserv itself. What diffserv offers is really a set of per-hop behaviors that every diffserv node has to support as it routes diffserv-labeled packets. These PHBs, when aggregated across a diffserv routing domain, create so-called "per domain behaviors" for aggregated diffserv paths. That's it, pretty much. And the MIB/PIB needed for diffserv node management, of course. It seems difficult to be able to support diffserv routes with any sort of stability if the hops of any "aggregated path" come and go frequently, but I suppose this could make for an interesting research project! Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Harpreet Arora [mailto:ha33@drexel.edu] > Sent: Friday, April 26, 2002 2:50 PM > To: manet > Subject: [manet] QoS issues in MANETs > Importance: High > > > Hi, > > I am interested in finding the feasibility of a > differentiated services model > for MANETs. WHile thinking about the implementation of > diffserv in MANETs, I > came across the follwing problem : diffserv aims to push the > complexity to the > edge of the network, by dividing the network into edge and > core nodes. How can > we do this in a MANET? Specifically, how can we differentiate > the network of > nodes into edge and core nodes? Since the nodes are mobile, I > feel that every > node should have the capability of acting as an edge node, > which would mark, > meter and police the packets, and also as a core node, which > would simply > forward the packets on the basis of the DSCP. The nodes can > assume either > functionality depending on the situation. But what node assumes what > functionality is the question. Any suggestions? > > Harpreet > Research Assistant > ECE Department, Drexel University > Philadelphia, PA-19104 > > ******************************************************************** > A dream is just a dream. A goal is a dream with a plan and a deadline. > > A candle brightens the world around it. Unfortunately, it > creates a shadow of its own. It still serves the purpose it > is meant for. > ********************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 26 15:21:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28561 for ; Fri, 26 Apr 2002 15:21:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17954 for manet-archive@odin.ietf.org; Fri, 26 Apr 2002 15:21:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16342; Fri, 26 Apr 2002 14:56:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16314 for ; Fri, 26 Apr 2002 14:56:12 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25447 for ; Fri, 26 Apr 2002 14:56:07 -0400 (EDT) Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA07326; Fri, 26 Apr 2002 11:56:11 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id LAA20739; Fri, 26 Apr 2002 11:56:03 -0700 (PDT) Received: from xch-phl-02p.ne.nos.boeing.com (xch-phl-02p.ne.nos.boeing.com [128.225.22.4]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id g3QIu2J19617; Fri, 26 Apr 2002 13:56:02 -0500 (CDT) Received: by xch-phl-02p.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Apr 2002 14:56:02 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8078A38C2@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Harpreet Arora'" , manet Subject: RE: [manet] QoS issues in MANETs Date: Fri, 26 Apr 2002 14:56:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi Arora, Actually, diffserv pretty much acknowledges that every "core" node can just as easily also be an "edge" node, and may therefore have to worry about such complexities as access control from edge hosts. There is no attempt to prevent core nodes from being edge nodes. But diffserv does not get into any sort of signaling or access control mechanisms between diffserv nodes and edge user hosts. People have mentioned possible signaling mechanisms for use in diffserv nets, such as the RSVP PATH and RESV messages. But always, such discussions were cut short on the list, because they are not germaine to diffserv itself. What diffserv offers is really a set of per-hop behaviors that every diffserv node has to support as it routes diffserv-labeled packets. These PHBs, when aggregated across a diffserv routing domain, create so-called "per domain behaviors" for aggregated diffserv paths. That's it, pretty much. And the MIB/PIB needed for diffserv node management, of course. It seems difficult to be able to support diffserv routes with any sort of stability if the hops of any "aggregated path" come and go frequently, but I suppose this could make for an interesting research project! Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Harpreet Arora [mailto:ha33@drexel.edu] > Sent: Friday, April 26, 2002 2:50 PM > To: manet > Subject: [manet] QoS issues in MANETs > Importance: High > > > Hi, > > I am interested in finding the feasibility of a > differentiated services model > for MANETs. WHile thinking about the implementation of > diffserv in MANETs, I > came across the follwing problem : diffserv aims to push the > complexity to the > edge of the network, by dividing the network into edge and > core nodes. How can > we do this in a MANET? Specifically, how can we differentiate > the network of > nodes into edge and core nodes? Since the nodes are mobile, I > feel that every > node should have the capability of acting as an edge node, > which would mark, > meter and police the packets, and also as a core node, which > would simply > forward the packets on the basis of the DSCP. The nodes can > assume either > functionality depending on the situation. But what node assumes what > functionality is the question. Any suggestions? > > Harpreet > Research Assistant > ECE Department, Drexel University > Philadelphia, PA-19104 > > ******************************************************************** > A dream is just a dream. A goal is a dream with a plan and a deadline. > > A candle brightens the world around it. Unfortunately, it > creates a shadow of its own. It still serves the purpose it > is meant for. > ********************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Fri Apr 26 17:14:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12180 for ; Fri, 26 Apr 2002 17:14:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22553; Fri, 26 Apr 2002 16:51:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22520 for ; Fri, 26 Apr 2002 16:51:27 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09748 for ; Fri, 26 Apr 2002 16:51:23 -0400 (EDT) Received: from sequoia (sequoia [128.111.40.85]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3QKpNO23911; Fri, 26 Apr 2002 13:51:23 -0700 (PDT) Date: Fri, 26 Apr 2002 13:51:23 -0700 (PDT) From: Sumit Gwalani X-Sender: sumitg@sequoia To: Phil Neumiller cc: manet@ietf.org Subject: Re: [manet] Link API was [ Link layer notification ] In-Reply-To: <013701c1ed30$617623b0$6200000a@meshnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Yes i agree, thanks for the information -Sumit On Fri, 26 Apr 2002, Phil Neumiller wrote: > Yes, it would be very interesting to see. I am not so much interested in standardizing the > LLC/MAC layer API for the use of IP, as I am standardizing the bottom half of IP looking > in from an LLC/MAC perspective. Think of me as an LLC/MAC that wants to make > effective use of the stack above me and vice versa. The age old protocol stack pattern > has been pretty much top down from day one. I would like more of object oriented > perspective on the layers where we can look at the IP stack as a layer pattern with a top > and bottom and the bottom gets specified as nicely and cleanly as the top has been. Any > steps in this direction with respect to wireless LLC/MACs would be extermely beneficial. > I am sure optical devices would benefit as well. > > -Phil > ----- Original Message ----- > From: "Dr. Chane L. Fullmer" > To: > Sent: Friday, April 26, 2002 10:04 AM > Subject: [manet] Link API was [ Link layer notification ] > > > > Hi All.. > > > > A couple of years back I presented a formal Link API design at the DC IETF > > meeting that was drafted in the DARPA GloMo project. Perhaps its time to > > drag it out and take another look? Provisions were made to pass > > information across the LL/IP interface, as well as to other protocols (ie, > > a Neighbor Protocol). > > > > --regards > > --chane > > > > (Joe: are the slides archived on-line somewhere... ??) > > > > > > >For what its worth, I have always wondered why the top half of TCP/IP is > > >fair game for standardization > > >i.e. sockets for example, yet the bottom half has to remain > > >secretive/proprietary/custom. I have always > > >liked the idea of exposing the underbelly of IP to L2's, i.e. create > > >service access/provision points > > >underneath IP that provide L2 layers an API into IP' underbelly. > > > > > >This being said, some of the most critical things we would need to > > >communicate to IP from a wireless > > >L2 would be detetion of pilots and/or beacons and signal strength > > >information. There are many > > >other things that would be useful as well like how the TOS and TTL fields > > >are interpreted by the MAC. > > >Maybe I should just write a draft and see what the IESG does with it??? > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Fri Apr 26 17:14:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12194 for ; Fri, 26 Apr 2002 17:14:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24360 for manet-archive@odin.ietf.org; Fri, 26 Apr 2002 17:14:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22553; Fri, 26 Apr 2002 16:51:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22520 for ; Fri, 26 Apr 2002 16:51:27 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09748 for ; Fri, 26 Apr 2002 16:51:23 -0400 (EDT) Received: from sequoia (sequoia [128.111.40.85]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g3QKpNO23911; Fri, 26 Apr 2002 13:51:23 -0700 (PDT) Date: Fri, 26 Apr 2002 13:51:23 -0700 (PDT) From: Sumit Gwalani X-Sender: sumitg@sequoia To: Phil Neumiller cc: manet@ietf.org Subject: Re: [manet] Link API was [ Link layer notification ] In-Reply-To: <013701c1ed30$617623b0$6200000a@meshnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Yes i agree, thanks for the information -Sumit On Fri, 26 Apr 2002, Phil Neumiller wrote: > Yes, it would be very interesting to see. I am not so much interested in standardizing the > LLC/MAC layer API for the use of IP, as I am standardizing the bottom half of IP looking > in from an LLC/MAC perspective. Think of me as an LLC/MAC that wants to make > effective use of the stack above me and vice versa. The age old protocol stack pattern > has been pretty much top down from day one. I would like more of object oriented > perspective on the layers where we can look at the IP stack as a layer pattern with a top > and bottom and the bottom gets specified as nicely and cleanly as the top has been. Any > steps in this direction with respect to wireless LLC/MACs would be extermely beneficial. > I am sure optical devices would benefit as well. > > -Phil > ----- Original Message ----- > From: "Dr. Chane L. Fullmer" > To: > Sent: Friday, April 26, 2002 10:04 AM > Subject: [manet] Link API was [ Link layer notification ] > > > > Hi All.. > > > > A couple of years back I presented a formal Link API design at the DC IETF > > meeting that was drafted in the DARPA GloMo project. Perhaps its time to > > drag it out and take another look? Provisions were made to pass > > information across the LL/IP interface, as well as to other protocols (ie, > > a Neighbor Protocol). > > > > --regards > > --chane > > > > (Joe: are the slides archived on-line somewhere... ??) > > > > > > >For what its worth, I have always wondered why the top half of TCP/IP is > > >fair game for standardization > > >i.e. sockets for example, yet the bottom half has to remain > > >secretive/proprietary/custom. I have always > > >liked the idea of exposing the underbelly of IP to L2's, i.e. create > > >service access/provision points > > >underneath IP that provide L2 layers an API into IP' underbelly. > > > > > >This being said, some of the most critical things we would need to > > >communicate to IP from a wireless > > >L2 would be detetion of pilots and/or beacons and signal strength > > >information. There are many > > >other things that would be useful as well like how the TOS and TTL fields > > >are interpreted by the MAC. > > >Maybe I should just write a draft and see what the IESG does with it??? > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Apr 27 16:49:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22144 for ; Sat, 27 Apr 2002 16:49:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25241; Sat, 27 Apr 2002 16:15:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25212 for ; Sat, 27 Apr 2002 16:15:56 -0400 (EDT) Received: from mailcity.com ([209.185.123.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18117 for ; Sat, 27 Apr 2002 16:15:51 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sat Apr 27 13:15:12 2002 To: "manet" Date: Sat, 27 Apr 2002 13:15:12 -0700 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] QoS issues in MANETs X-Sender-Ip: 64.230.105.32 Organization: Lycos Mail (http://www.mail.lycos.com) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Good answer, Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of handling traffic between two nodes. The other model which provided some enhancements to traditional DiffServ is the FQMM. Always try to distinguish signalling from the model. FQMM represent a model, INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment to RSVP. Ingress, and egress could be anynode. Ingress are always nodes initiating traffic. Egress are those submitting traffic to different domain. Yasser Carleton University ----------------------------------------------------------------- Hi Arora, Actually, diffserv pretty much acknowledges that every "core" node can just as easily also be an "edge" node, and may therefore have to worry about such complexities as access control from edge hosts. There is no attempt to prevent core nodes from being edge nodes. But diffserv does not get into any sort of signaling or access control mechanisms between diffserv nodes and edge user hosts. People have mentioned possible signaling mechanisms for use in diffserv nets, such as the RSVP PATH and RESV messages. But always, such discussions were cut short on the list, because they are not germaine to diffserv itself. What diffserv offers is really a set of per-hop behaviors that every diffserv node has to support as it routes diffserv-labeled packets. These PHBs, when aggregated across a diffserv routing domain, create so-called "per domain behaviors" for aggregated diffserv paths. That's it, pretty much. And the MIB/PIB needed for diffserv node management, of course. It seems difficult to be able to support diffserv routes with any sort of stability if the hops of any "aggregated path" come and go frequently, but I suppose this could make for an interesting research project! Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Harpreet Arora [mailto:ha33@drexel.edu] > Sent: Friday, April 26, 2002 2:50 PM > To: manet > Subject: [manet] QoS issues in MANETs > Importance: High > > > Hi, > > I am interested in finding the feasibility of a > differentiated services model > for MANETs. WHile thinking about the implementation of > diffserv in MANETs, I > came across the follwing problem : diffserv aims to push the > complexity to the > edge of the network, by dividing the network into edge and > core nodes. How can > we do this in a MANET? Specifically, how can we differentiate > the network of > nodes into edge and core nodes? Since the nodes are mobile, I > feel that every > node should have the capability of acting as an edge node, > which would mark, > meter and police the packets, and also as a core node, which > would simply > forward the packets on the basis of the DSCP. The nodes can > assume either > functionality depending on the situation. But what node assumes what > functionality is the question. Any suggestions? > > Harpreet > Research Assistant > ECE Department, Drexel University > Philadelphia, PA-19104 > > ******************************************************************** > A dream is just a dream. A goal is a dream with a plan and a deadline. > > A candle brightens the world around it. Unfortunately, it > creates a shadow of its own. It still serves the purpose it > is meant for. > ********************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > See Dave Matthews Band live or win a signed guitar http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/splash.asp _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sat Apr 27 16:49:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22159 for ; Sat, 27 Apr 2002 16:49:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27028 for manet-archive@odin.ietf.org; Sat, 27 Apr 2002 16:49:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25241; Sat, 27 Apr 2002 16:15:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25212 for ; Sat, 27 Apr 2002 16:15:56 -0400 (EDT) Received: from mailcity.com ([209.185.123.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18117 for ; Sat, 27 Apr 2002 16:15:51 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sat Apr 27 13:15:12 2002 To: "manet" Date: Sat, 27 Apr 2002 13:15:12 -0700 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] QoS issues in MANETs X-Sender-Ip: 64.230.105.32 Organization: Lycos Mail (http://www.mail.lycos.com) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Good answer, Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of handling traffic between two nodes. The other model which provided some enhancements to traditional DiffServ is the FQMM. Always try to distinguish signalling from the model. FQMM represent a model, INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment to RSVP. Ingress, and egress could be anynode. Ingress are always nodes initiating traffic. Egress are those submitting traffic to different domain. Yasser Carleton University ----------------------------------------------------------------- Hi Arora, Actually, diffserv pretty much acknowledges that every "core" node can just as easily also be an "edge" node, and may therefore have to worry about such complexities as access control from edge hosts. There is no attempt to prevent core nodes from being edge nodes. But diffserv does not get into any sort of signaling or access control mechanisms between diffserv nodes and edge user hosts. People have mentioned possible signaling mechanisms for use in diffserv nets, such as the RSVP PATH and RESV messages. But always, such discussions were cut short on the list, because they are not germaine to diffserv itself. What diffserv offers is really a set of per-hop behaviors that every diffserv node has to support as it routes diffserv-labeled packets. These PHBs, when aggregated across a diffserv routing domain, create so-called "per domain behaviors" for aggregated diffserv paths. That's it, pretty much. And the MIB/PIB needed for diffserv node management, of course. It seems difficult to be able to support diffserv routes with any sort of stability if the hops of any "aggregated path" come and go frequently, but I suppose this could make for an interesting research project! Bert albert.e.manfredi@boeing.com > -----Original Message----- > From: Harpreet Arora [mailto:ha33@drexel.edu] > Sent: Friday, April 26, 2002 2:50 PM > To: manet > Subject: [manet] QoS issues in MANETs > Importance: High > > > Hi, > > I am interested in finding the feasibility of a > differentiated services model > for MANETs. WHile thinking about the implementation of > diffserv in MANETs, I > came across the follwing problem : diffserv aims to push the > complexity to the > edge of the network, by dividing the network into edge and > core nodes. How can > we do this in a MANET? Specifically, how can we differentiate > the network of > nodes into edge and core nodes? Since the nodes are mobile, I > feel that every > node should have the capability of acting as an edge node, > which would mark, > meter and police the packets, and also as a core node, which > would simply > forward the packets on the basis of the DSCP. The nodes can > assume either > functionality depending on the situation. But what node assumes what > functionality is the question. Any suggestions? > > Harpreet > Research Assistant > ECE Department, Drexel University > Philadelphia, PA-19104 > > ******************************************************************** > A dream is just a dream. A goal is a dream with a plan and a deadline. > > A candle brightens the world around it. Unfortunately, it > creates a shadow of its own. It still serves the purpose it > is meant for. > ********************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > See Dave Matthews Band live or win a signed guitar http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/splash.asp _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Apr 27 19:39:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09232 for ; Sat, 27 Apr 2002 19:39:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02265; Sat, 27 Apr 2002 18:59:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02235 for ; Sat, 27 Apr 2002 18:59:03 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05018 for ; Sat, 27 Apr 2002 18:58:59 -0400 (EDT) Received: from webmail.drexel.edu (webmail.drexel.edu [129.25.3.29]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GV9007B214BUO@mail.drexel.edu> for manet@ietf.org; Sat, 27 Apr 2002 18:57:47 -0400 (EDT) Date: Sat, 27 Apr 2002 19:08:37 -0400 From: Harpreet Arora Subject: RE: [manet] QoS issues in MANETs To: manet Message-id: <3CD98899@webmail.drexel.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61.08 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 1 X-WebMail-Urgent: Y X-WebMail-UserID: ha33 X-EXP32-SerialNo: 00003005 Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Hi, The Insignia approach does seem to be a good approach for QoS in MANETs, but it is based on per flow guarantees, not per class, and thus can have the same problems associated with Intserv model like scalability and implementation issues. Each flow reserves resources at every node it passes through. THe FQMM simply suggests that the highest class gets per flow provisioning, while the lower classes get per class provisioning, so in essence the model adds the complexity of the two models. And it does not suggest any means of implementing the model in MANETs. The basic issue still remains of which node will mark the packets so that the subsequent nodes can process them accrodingly. If the source node does that job, then there is a good chance that the node can misbehave and use a DSCP corresponding to a high priority PHB even when it does not need to. In that case, who does the policing to stop the flow? thanks, Harpreet >===== Original Message From yasser.lotfy@lycos.com ===== >Good answer, >Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of handling traffic between two nodes. The other model which provided some enhancements to traditional DiffServ is the FQMM. > >Always try to distinguish signalling from the model. FQMM represent a model, INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment to RSVP. > >Ingress, and egress could be anynode. Ingress are always nodes initiating traffic. Egress are those submitting traffic to different domain. > > >Yasser >Carleton University > >----------------------------------------------------------------- >Hi Arora, > >Actually, diffserv pretty much acknowledges that every "core" node can just >as easily also be an "edge" node, and may therefore have to worry about such >complexities as access control from edge hosts. There is no attempt to >prevent core nodes from being edge nodes. > >But diffserv does not get into any sort of signaling or access control >mechanisms between diffserv nodes and edge user hosts. People have mentioned >possible signaling mechanisms for use in diffserv nets, such as the RSVP >PATH and RESV messages. But always, such discussions were cut short on the >list, because they are not germaine to diffserv itself. > >What diffserv offers is really a set of per-hop behaviors that every >diffserv node has to support as it routes diffserv-labeled packets. These >PHBs, when aggregated across a diffserv routing domain, create so-called >"per domain behaviors" for aggregated diffserv paths. That's it, pretty >much. And the MIB/PIB needed for diffserv node management, of course. > >It seems difficult to be able to support diffserv routes with any sort of >stability if the hops of any "aggregated path" come and go frequently, but I >suppose this could make for an interesting research project! > >Bert >albert.e.manfredi@boeing.com > > >> -----Original Message----- >> From: Harpreet Arora [mailto:ha33@drexel.edu] >> Sent: Friday, April 26, 2002 2:50 PM >> To: manet >> Subject: [manet] QoS issues in MANETs >> Importance: High >> >> >> Hi, >> >> I am interested in finding the feasibility of a >> differentiated services model >> for MANETs. WHile thinking about the implementation of >> diffserv in MANETs, I >> came across the follwing problem : diffserv aims to push the >> complexity to the >> edge of the network, by dividing the network into edge and >> core nodes. How can >> we do this in a MANET? Specifically, how can we differentiate >> the network of >> nodes into edge and core nodes? Since the nodes are mobile, I >> feel that every >> node should have the capability of acting as an edge node, >> which would mark, >> meter and police the packets, and also as a core node, which >> would simply >> forward the packets on the basis of the DSCP. The nodes can >> assume either >> functionality depending on the situation. But what node assumes what >> functionality is the question. Any suggestions? >> >> Harpreet >> Research Assistant >> ECE Department, Drexel University >> Philadelphia, PA-19104 >> >> ******************************************************************** >> A dream is just a dream. A goal is a dream with a plan and a deadline. >> >> A candle brightens the world around it. Unfortunately, it >> creates a shadow of its own. It still serves the purpose it >> is meant for. >> ********************************************************************** >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> > > > > >See Dave Matthews Band live or win a signed guitar >http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/ splash.asp > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sat Apr 27 19:39:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09244 for ; Sat, 27 Apr 2002 19:39:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA04395 for manet-archive@odin.ietf.org; Sat, 27 Apr 2002 19:39:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02265; Sat, 27 Apr 2002 18:59:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02235 for ; Sat, 27 Apr 2002 18:59:03 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05018 for ; Sat, 27 Apr 2002 18:58:59 -0400 (EDT) Received: from webmail.drexel.edu (webmail.drexel.edu [129.25.3.29]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GV9007B214BUO@mail.drexel.edu> for manet@ietf.org; Sat, 27 Apr 2002 18:57:47 -0400 (EDT) Date: Sat, 27 Apr 2002 19:08:37 -0400 From: Harpreet Arora Subject: RE: [manet] QoS issues in MANETs To: manet Message-id: <3CD98899@webmail.drexel.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61.08 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 1 X-WebMail-Urgent: Y X-WebMail-UserID: ha33 X-EXP32-SerialNo: 00003005 Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Hi, The Insignia approach does seem to be a good approach for QoS in MANETs, but it is based on per flow guarantees, not per class, and thus can have the same problems associated with Intserv model like scalability and implementation issues. Each flow reserves resources at every node it passes through. THe FQMM simply suggests that the highest class gets per flow provisioning, while the lower classes get per class provisioning, so in essence the model adds the complexity of the two models. And it does not suggest any means of implementing the model in MANETs. The basic issue still remains of which node will mark the packets so that the subsequent nodes can process them accrodingly. If the source node does that job, then there is a good chance that the node can misbehave and use a DSCP corresponding to a high priority PHB even when it does not need to. In that case, who does the policing to stop the flow? thanks, Harpreet >===== Original Message From yasser.lotfy@lycos.com ===== >Good answer, >Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of handling traffic between two nodes. The other model which provided some enhancements to traditional DiffServ is the FQMM. > >Always try to distinguish signalling from the model. FQMM represent a model, INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment to RSVP. > >Ingress, and egress could be anynode. Ingress are always nodes initiating traffic. Egress are those submitting traffic to different domain. > > >Yasser >Carleton University > >----------------------------------------------------------------- >Hi Arora, > >Actually, diffserv pretty much acknowledges that every "core" node can just >as easily also be an "edge" node, and may therefore have to worry about such >complexities as access control from edge hosts. There is no attempt to >prevent core nodes from being edge nodes. > >But diffserv does not get into any sort of signaling or access control >mechanisms between diffserv nodes and edge user hosts. People have mentioned >possible signaling mechanisms for use in diffserv nets, such as the RSVP >PATH and RESV messages. But always, such discussions were cut short on the >list, because they are not germaine to diffserv itself. > >What diffserv offers is really a set of per-hop behaviors that every >diffserv node has to support as it routes diffserv-labeled packets. These >PHBs, when aggregated across a diffserv routing domain, create so-called >"per domain behaviors" for aggregated diffserv paths. That's it, pretty >much. And the MIB/PIB needed for diffserv node management, of course. > >It seems difficult to be able to support diffserv routes with any sort of >stability if the hops of any "aggregated path" come and go frequently, but I >suppose this could make for an interesting research project! > >Bert >albert.e.manfredi@boeing.com > > >> -----Original Message----- >> From: Harpreet Arora [mailto:ha33@drexel.edu] >> Sent: Friday, April 26, 2002 2:50 PM >> To: manet >> Subject: [manet] QoS issues in MANETs >> Importance: High >> >> >> Hi, >> >> I am interested in finding the feasibility of a >> differentiated services model >> for MANETs. WHile thinking about the implementation of >> diffserv in MANETs, I >> came across the follwing problem : diffserv aims to push the >> complexity to the >> edge of the network, by dividing the network into edge and >> core nodes. How can >> we do this in a MANET? Specifically, how can we differentiate >> the network of >> nodes into edge and core nodes? Since the nodes are mobile, I >> feel that every >> node should have the capability of acting as an edge node, >> which would mark, >> meter and police the packets, and also as a core node, which >> would simply >> forward the packets on the basis of the DSCP. The nodes can >> assume either >> functionality depending on the situation. But what node assumes what >> functionality is the question. Any suggestions? >> >> Harpreet >> Research Assistant >> ECE Department, Drexel University >> Philadelphia, PA-19104 >> >> ******************************************************************** >> A dream is just a dream. A goal is a dream with a plan and a deadline. >> >> A candle brightens the world around it. Unfortunately, it >> creates a shadow of its own. It still serves the purpose it >> is meant for. >> ********************************************************************** >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> > > > > >See Dave Matthews Band live or win a signed guitar >http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/ splash.asp > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sat Apr 27 20:39:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15923 for ; Sat, 27 Apr 2002 20:39:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05366; Sat, 27 Apr 2002 20:06:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05335 for ; Sat, 27 Apr 2002 20:06:29 -0400 (EDT) Received: from hotmail.com (f21.law15.hotmail.com [64.4.23.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12149 for ; Sat, 27 Apr 2002 20:06:25 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 27 Apr 2002 17:05:57 -0700 Received: from 129.119.0.182 by lw15fd.law15.hotmail.msn.com with HTTP; Sun, 28 Apr 2002 00:05:56 GMT X-Originating-IP: [129.119.0.182] From: "Abdul Aziz" To: D.Kothris@bristol.ac.uk Cc: manet@ietf.org Subject: Re: [manet] Complexity VS enhanced functionality & flexibility Date: Sun, 28 Apr 2002 00:05:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Apr 2002 00:05:57.0997 (UTC) FILETIME=[791B41D0:01C1EE48] Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, Routing is Adhoc networks depends upon number of factors which effect the protocol design. A routing mechanism can certainly be complex one, but that would make more prone to fail against some of performance matrix measures. One example of such performance matrix being Processing time and Processing power. Both effect the efficiency in routing one way or the other. More the processing time, the more delays one would be relaying packets. As a result, you wouldn't be able to use any simple time out mechanism. You might also be experiencing fading channels, one way routes, and other such discrepencies because of power loss. Any mechanism for routing that can guarantee integrity of packet, security, minimum hop to destination, less processing delay, and less consumption of power would be an ideal candidate. hope that helped, Abdul Aziz >From: "D Kothris, Electrical & Electronic Engineering" > >To: manet@ietf.org >Subject: [manet] Complexity VS enhanced functionality & flexibility >Date: Tue, 23 Apr 2002 11:02:58 +0100 > >Dear co-workers, > >I'm fairly new in this research area (about a year), and I am >investigating ad hoc routing mechanisms. A kind of dilemma that has >risen in my mind has driven me to put forward this question >so that I can capture the general trend that exists within the MANET >research community. > >I am interested to find out whether complexity is thought of a just >means to achieve further or improved functionality. I am pondering that >the answer to this is not one sided, so if the answer is "gray", would >it be possible to get some suggestions of cases where simplicity in >design might be sacrificed for a better performance trade-off. I fear >that if i give an example some people might stick to that, but >nevertheless I will give one just to be more colorful: > >The use of a Neural network with multiple input feeds might be used >as a part of a classification system, in order to decide upon the >suitability of routing paths. This could only be one of many complex >approaches that may exist within a routing protocol solution. > >Please feel free to drop your comments. I would appreciate it a lot. > >Thanks > >Dimosthenis (Dimos) > > > >_________________________________________________________________ >***************************************************************** >Dimosthenis Kothris Centre for Communications Research, > University of Bristol, > Network & Protocols group > >Address: Contact numbers: >_________________________________________________________________ >Network & Protocols >Center for Communcations research >Merchant Venturers Building Tel : +44 117 903 1104 >Woodland Road Fax : +44 117 954 5206 >Bristol BS8 1UB Mobile: +44 7779 40 48 42 >United Kingdom Email : d.kothris@bristol.ac.uk >***************************************************************** > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sat Apr 27 20:39:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15937 for ; Sat, 27 Apr 2002 20:39:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA06690 for manet-archive@odin.ietf.org; Sat, 27 Apr 2002 20:39:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05366; Sat, 27 Apr 2002 20:06:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05335 for ; Sat, 27 Apr 2002 20:06:29 -0400 (EDT) Received: from hotmail.com (f21.law15.hotmail.com [64.4.23.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12149 for ; Sat, 27 Apr 2002 20:06:25 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 27 Apr 2002 17:05:57 -0700 Received: from 129.119.0.182 by lw15fd.law15.hotmail.msn.com with HTTP; Sun, 28 Apr 2002 00:05:56 GMT X-Originating-IP: [129.119.0.182] From: "Abdul Aziz" To: D.Kothris@bristol.ac.uk Cc: manet@ietf.org Subject: Re: [manet] Complexity VS enhanced functionality & flexibility Date: Sun, 28 Apr 2002 00:05:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Apr 2002 00:05:57.0997 (UTC) FILETIME=[791B41D0:01C1EE48] Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hi, Routing is Adhoc networks depends upon number of factors which effect the protocol design. A routing mechanism can certainly be complex one, but that would make more prone to fail against some of performance matrix measures. One example of such performance matrix being Processing time and Processing power. Both effect the efficiency in routing one way or the other. More the processing time, the more delays one would be relaying packets. As a result, you wouldn't be able to use any simple time out mechanism. You might also be experiencing fading channels, one way routes, and other such discrepencies because of power loss. Any mechanism for routing that can guarantee integrity of packet, security, minimum hop to destination, less processing delay, and less consumption of power would be an ideal candidate. hope that helped, Abdul Aziz >From: "D Kothris, Electrical & Electronic Engineering" > >To: manet@ietf.org >Subject: [manet] Complexity VS enhanced functionality & flexibility >Date: Tue, 23 Apr 2002 11:02:58 +0100 > >Dear co-workers, > >I'm fairly new in this research area (about a year), and I am >investigating ad hoc routing mechanisms. A kind of dilemma that has >risen in my mind has driven me to put forward this question >so that I can capture the general trend that exists within the MANET >research community. > >I am interested to find out whether complexity is thought of a just >means to achieve further or improved functionality. I am pondering that >the answer to this is not one sided, so if the answer is "gray", would >it be possible to get some suggestions of cases where simplicity in >design might be sacrificed for a better performance trade-off. I fear >that if i give an example some people might stick to that, but >nevertheless I will give one just to be more colorful: > >The use of a Neural network with multiple input feeds might be used >as a part of a classification system, in order to decide upon the >suitability of routing paths. This could only be one of many complex >approaches that may exist within a routing protocol solution. > >Please feel free to drop your comments. I would appreciate it a lot. > >Thanks > >Dimosthenis (Dimos) > > > >_________________________________________________________________ >***************************************************************** >Dimosthenis Kothris Centre for Communications Research, > University of Bristol, > Network & Protocols group > >Address: Contact numbers: >_________________________________________________________________ >Network & Protocols >Center for Communcations research >Merchant Venturers Building Tel : +44 117 903 1104 >Woodland Road Fax : +44 117 954 5206 >Bristol BS8 1UB Mobile: +44 7779 40 48 42 >United Kingdom Email : d.kothris@bristol.ac.uk >***************************************************************** > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Apr 28 10:29:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19370 for ; Sun, 28 Apr 2002 10:28:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11869; Sun, 28 Apr 2002 10:02:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11838 for ; Sun, 28 Apr 2002 10:02:13 -0400 (EDT) Received: from mailcity.com ([209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16359 for ; Sun, 28 Apr 2002 10:02:07 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sun Apr 28 07:01:31 2002 To: "manet" Date: Sun, 28 Apr 2002 07:01:31 -0700 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] QoS issues in MANETs X-Sender-Ip: 66.185.84.200 Organization: Lycos Mail (http://www.mail.lycos.com) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, If you're implementing a DiffServ Model on MANET, then allow me to add more questions need to be placed. 1- How can nodes agree on a set of DSCP? 2- How can nodes agree on a PHB? 3- Who will police traffic marking? Yasser Carleton University --------------------------------------------------------------- Hi, The Insignia approach does seem to be a good approach for QoS in MANETs, but it is based on per flow guarantees, not per class, and thus can have the same problems associated with Intserv model like scalability and implementation issues. Each flow reserves resources at every node it passes through. THe FQMM simply suggests that the highest class gets per flow provisioning, while the lower classes get per class provisioning, so in essence the model adds the complexity of the two models. And it does not suggest any means of implementing the model in MANETs. The basic issue still remains of which node will mark the packets so that the subsequent nodes can process them accrodingly. If the source node does that job, then there is a good chance that the node can misbehave and use a DSCP corresponding to a high priority PHB even when it does not need to. In that case, who does the policing to stop the flow? thanks, Harpreet >===== Original Message From yasser.lotfy@lycos.com ===== >Good answer, >Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of handling traffic between two nodes. The other model which provided some enhancements to traditional DiffServ is the FQMM. > >Always try to distinguish signalling from the model. FQMM represent a model, INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment to RSVP. > >Ingress, and egress could be anynode. Ingress are always nodes initiating traffic. Egress are those submitting traffic to different domain. > > >Yasser >Carleton University > >----------------------------------------------------------------- >Hi Arora, > >Actually, diffserv pretty much acknowledges that every "core" node can just >as easily also be an "edge" node, and may therefore have to worry about such >complexities as access control from edge hosts. There is no attempt to >prevent core nodes from being edge nodes. > >But diffserv does not get into any sort of signaling or access control >mechanisms between diffserv nodes and edge user hosts. People have mentioned >possible signaling mechanisms for use in diffserv nets, such as the RSVP >PATH and RESV messages. But always, such discussions were cut short on the >list, because they are not germaine to diffserv itself. > >What diffserv offers is really a set of per-hop behaviors that every >diffserv node has to support as it routes diffserv-labeled packets. These >PHBs, when aggregated across a diffserv routing domain, create so-called >"per domain behaviors" for aggregated diffserv paths. That's it, pretty >much. And the MIB/PIB needed for diffserv node management, of course. > >It seems difficult to be able to support diffserv routes with any sort of >stability if the hops of any "aggregated path" come and go frequently, but I >suppose this could make for an interesting research project! > >Bert >albert.e.manfredi@boeing.com > > >> -----Original Message----- >> From: Harpreet Arora [mailto:ha33@drexel.edu] >> Sent: Friday, April 26, 2002 2:50 PM >> To: manet >> Subject: [manet] QoS issues in MANETs >> Importance: High >> >> >> Hi, >> >> I am interested in finding the feasibility of a >> differentiated services model >> for MANETs. WHile thinking about the implementation of >> diffserv in MANETs, I >> came across the follwing problem : diffserv aims to push the >> complexity to the >> edge of the network, by dividing the network into edge and >> core nodes. How can >> we do this in a MANET? Specifically, how can we differentiate >> the network of >> nodes into edge and core nodes? Since the nodes are mobile, I >> feel that every >> node should have the capability of acting as an edge node, >> which would mark, >> meter and police the packets, and also as a core node, which >> would simply >> forward the packets on the basis of the DSCP. The nodes can >> assume either >> functionality depending on the situation. But what node assumes what >> functionality is the question. Any suggestions? >> >> Harpreet >> Research Assistant >> ECE Department, Drexel University >> Philadelphia, PA-19104 >> >> ******************************************************************** >> A dream is just a dream. A goal is a dream with a plan and a deadline. >> >> A candle brightens the world around it. Unfortunately, it >> creates a shadow of its own. It still serves the purpose it >> is meant for. >> ********************************************************************** >> See Dave Matthews Band live or win a signed guitar http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/splash.asp _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun Apr 28 10:29:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19385 for ; Sun, 28 Apr 2002 10:29:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12782 for manet-archive@odin.ietf.org; Sun, 28 Apr 2002 10:29:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11869; Sun, 28 Apr 2002 10:02:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11838 for ; Sun, 28 Apr 2002 10:02:13 -0400 (EDT) Received: from mailcity.com ([209.185.123.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16359 for ; Sun, 28 Apr 2002 10:02:07 -0400 (EDT) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sun Apr 28 07:01:31 2002 To: "manet" Date: Sun, 28 Apr 2002 07:01:31 -0700 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] QoS issues in MANETs X-Sender-Ip: 66.185.84.200 Organization: Lycos Mail (http://www.mail.lycos.com) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, If you're implementing a DiffServ Model on MANET, then allow me to add more questions need to be placed. 1- How can nodes agree on a set of DSCP? 2- How can nodes agree on a PHB? 3- Who will police traffic marking? Yasser Carleton University --------------------------------------------------------------- Hi, The Insignia approach does seem to be a good approach for QoS in MANETs, but it is based on per flow guarantees, not per class, and thus can have the same problems associated with Intserv model like scalability and implementation issues. Each flow reserves resources at every node it passes through. THe FQMM simply suggests that the highest class gets per flow provisioning, while the lower classes get per class provisioning, so in essence the model adds the complexity of the two models. And it does not suggest any means of implementing the model in MANETs. The basic issue still remains of which node will mark the packets so that the subsequent nodes can process them accrodingly. If the source node does that job, then there is a good chance that the node can misbehave and use a DSCP corresponding to a high priority PHB even when it does not need to. In that case, who does the policing to stop the flow? thanks, Harpreet >===== Original Message From yasser.lotfy@lycos.com ===== >Good answer, >Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of handling traffic between two nodes. The other model which provided some enhancements to traditional DiffServ is the FQMM. > >Always try to distinguish signalling from the model. FQMM represent a model, INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment to RSVP. > >Ingress, and egress could be anynode. Ingress are always nodes initiating traffic. Egress are those submitting traffic to different domain. > > >Yasser >Carleton University > >----------------------------------------------------------------- >Hi Arora, > >Actually, diffserv pretty much acknowledges that every "core" node can just >as easily also be an "edge" node, and may therefore have to worry about such >complexities as access control from edge hosts. There is no attempt to >prevent core nodes from being edge nodes. > >But diffserv does not get into any sort of signaling or access control >mechanisms between diffserv nodes and edge user hosts. People have mentioned >possible signaling mechanisms for use in diffserv nets, such as the RSVP >PATH and RESV messages. But always, such discussions were cut short on the >list, because they are not germaine to diffserv itself. > >What diffserv offers is really a set of per-hop behaviors that every >diffserv node has to support as it routes diffserv-labeled packets. These >PHBs, when aggregated across a diffserv routing domain, create so-called >"per domain behaviors" for aggregated diffserv paths. That's it, pretty >much. And the MIB/PIB needed for diffserv node management, of course. > >It seems difficult to be able to support diffserv routes with any sort of >stability if the hops of any "aggregated path" come and go frequently, but I >suppose this could make for an interesting research project! > >Bert >albert.e.manfredi@boeing.com > > >> -----Original Message----- >> From: Harpreet Arora [mailto:ha33@drexel.edu] >> Sent: Friday, April 26, 2002 2:50 PM >> To: manet >> Subject: [manet] QoS issues in MANETs >> Importance: High >> >> >> Hi, >> >> I am interested in finding the feasibility of a >> differentiated services model >> for MANETs. WHile thinking about the implementation of >> diffserv in MANETs, I >> came across the follwing problem : diffserv aims to push the >> complexity to the >> edge of the network, by dividing the network into edge and >> core nodes. How can >> we do this in a MANET? Specifically, how can we differentiate >> the network of >> nodes into edge and core nodes? Since the nodes are mobile, I >> feel that every >> node should have the capability of acting as an edge node, >> which would mark, >> meter and police the packets, and also as a core node, which >> would simply >> forward the packets on the basis of the DSCP. The nodes can >> assume either >> functionality depending on the situation. But what node assumes what >> functionality is the question. Any suggestions? >> >> Harpreet >> Research Assistant >> ECE Department, Drexel University >> Philadelphia, PA-19104 >> >> ******************************************************************** >> A dream is just a dream. A goal is a dream with a plan and a deadline. >> >> A candle brightens the world around it. Unfortunately, it >> creates a shadow of its own. It still serves the purpose it >> is meant for. >> ********************************************************************** >> See Dave Matthews Band live or win a signed guitar http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/splash.asp _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Sun Apr 28 12:39:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03218 for ; Sun, 28 Apr 2002 12:39:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17349; Sun, 28 Apr 2002 12:16:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17320 for ; Sun, 28 Apr 2002 12:16:02 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00729 for ; Sun, 28 Apr 2002 12:15:56 -0400 (EDT) Received: from webmail.drexel.edu (webmail.drexel.edu [129.25.3.29]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GVA004KXD5XMC@mail.drexel.edu> for manet@ietf.org; Sun, 28 Apr 2002 12:15:33 -0400 (EDT) Date: Sun, 28 Apr 2002 12:26:25 -0400 From: Harpreet Arora Subject: RE: [manet] QoS issues in MANETs To: manet , yasser.lotfy@lycos.com Message-id: <3CDA7FD5@webmail.drexel.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61.08 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 1 X-WebMail-Urgent: Y X-WebMail-UserID: ha33 X-EXP32-SerialNo: 00003005 Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Yasser, The set of DSCPs and the corresponding PHBs can always be set as standards. The third question remains unanswered. Harpreet >===== Original Message From yasser.lotfy@lycos.com ===== >Hi, >If you're implementing a DiffServ Model on MANET, then allow me to add more questions need to be placed. >1- How can nodes agree on a set of DSCP? >2- How can nodes agree on a PHB? >3- Who will police traffic marking? > > >Yasser >Carleton University >--------------------------------------------------------------- > >Hi, > >The Insignia approach does seem to be a good approach for QoS in MANETs, but >it is based on per flow guarantees, not per class, and thus can have the same >problems associated with Intserv model like scalability and implementation >issues. Each flow reserves resources at every node it passes through. THe FQMM >simply suggests that the highest class gets per flow provisioning, while the >lower classes get per class provisioning, so in essence the model adds the >complexity of the two models. And it does not suggest any means of >implementing the model in MANETs. The basic issue still remains of which node >will mark the packets so that the subsequent nodes can process them >accrodingly. If the source node does that job, then there is a good chance >that the node can misbehave and use a DSCP corresponding to a high priority >PHB even when it does not need to. In that case, who does the policing to stop >the flow? > >thanks, >Harpreet > > >>===== Original Message From yasser.lotfy@lycos.com ===== >>Good answer, >>Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of >handling traffic between two nodes. The other model which provided some >enhancements to traditional DiffServ is the FQMM. >> >>Always try to distinguish signalling from the model. FQMM represent a model, >INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment >to RSVP. >> >>Ingress, and egress could be anynode. Ingress are always nodes initiating >traffic. Egress are those submitting traffic to different domain. >> >> >>Yasser >>Carleton University >> >>----------------------------------------------------------------- >>Hi Arora, >> >>Actually, diffserv pretty much acknowledges that every "core" node can just >>as easily also be an "edge" node, and may therefore have to worry about such >>complexities as access control from edge hosts. There is no attempt to >>prevent core nodes from being edge nodes. >> >>But diffserv does not get into any sort of signaling or access control >>mechanisms between diffserv nodes and edge user hosts. People have mentioned >>possible signaling mechanisms for use in diffserv nets, such as the RSVP >>PATH and RESV messages. But always, such discussions were cut short on the >>list, because they are not germaine to diffserv itself. >> >>What diffserv offers is really a set of per-hop behaviors that every >>diffserv node has to support as it routes diffserv-labeled packets. These >>PHBs, when aggregated across a diffserv routing domain, create so-called >>"per domain behaviors" for aggregated diffserv paths. That's it, pretty >>much. And the MIB/PIB needed for diffserv node management, of course. >> >>It seems difficult to be able to support diffserv routes with any sort of >>stability if the hops of any "aggregated path" come and go frequently, but I >>suppose this could make for an interesting research project! >> >>Bert >>albert.e.manfredi@boeing.com >> >> >>> -----Original Message----- >>> From: Harpreet Arora [mailto:ha33@drexel.edu] >>> Sent: Friday, April 26, 2002 2:50 PM >>> To: manet >>> Subject: [manet] QoS issues in MANETs >>> Importance: High >>> >>> >>> Hi, >>> >>> I am interested in finding the feasibility of a >>> differentiated services model >>> for MANETs. WHile thinking about the implementation of >>> diffserv in MANETs, I >>> came across the follwing problem : diffserv aims to push the >>> complexity to the >>> edge of the network, by dividing the network into edge and >>> core nodes. How can >>> we do this in a MANET? Specifically, how can we differentiate >>> the network of >>> nodes into edge and core nodes? Since the nodes are mobile, I >>> feel that every >>> node should have the capability of acting as an edge node, >>> which would mark, >>> meter and police the packets, and also as a core node, which >>> would simply >>> forward the packets on the basis of the DSCP. The nodes can >>> assume either >>> functionality depending on the situation. But what node assumes what >>> functionality is the question. Any suggestions? >>> >>> Harpreet >>> Research Assistant >>> ECE Department, Drexel University >>> Philadelphia, PA-19104 >>> >>> ******************************************************************** >>> A dream is just a dream. A goal is a dream with a plan and a deadline. >>> >>> A candle brightens the world around it. Unfortunately, it >>> creates a shadow of its own. It still serves the purpose it >>> is meant for. >>> ********************************************************************** >>> > > > >See Dave Matthews Band live or win a signed guitar >http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/ splash.asp > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Sun Apr 28 12:39:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03229 for ; Sun, 28 Apr 2002 12:39:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18696 for manet-archive@odin.ietf.org; Sun, 28 Apr 2002 12:39:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17349; Sun, 28 Apr 2002 12:16:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17320 for ; Sun, 28 Apr 2002 12:16:02 -0400 (EDT) Received: from mail.drexel.edu (mail.drexel.edu [129.25.3.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00729 for ; Sun, 28 Apr 2002 12:15:56 -0400 (EDT) Received: from webmail.drexel.edu (webmail.drexel.edu [129.25.3.29]) by mail.drexel.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0GVA004KXD5XMC@mail.drexel.edu> for manet@ietf.org; Sun, 28 Apr 2002 12:15:33 -0400 (EDT) Date: Sun, 28 Apr 2002 12:26:25 -0400 From: Harpreet Arora Subject: RE: [manet] QoS issues in MANETs To: manet , yasser.lotfy@lycos.com Message-id: <3CDA7FD5@webmail.drexel.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.61.08 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 1 X-WebMail-Urgent: Y X-WebMail-UserID: ha33 X-EXP32-SerialNo: 00003005 Content-Transfer-Encoding: 7BIT Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7BIT Yasser, The set of DSCPs and the corresponding PHBs can always be set as standards. The third question remains unanswered. Harpreet >===== Original Message From yasser.lotfy@lycos.com ===== >Hi, >If you're implementing a DiffServ Model on MANET, then allow me to add more questions need to be placed. >1- How can nodes agree on a set of DSCP? >2- How can nodes agree on a PHB? >3- Who will police traffic marking? > > >Yasser >Carleton University >--------------------------------------------------------------- > >Hi, > >The Insignia approach does seem to be a good approach for QoS in MANETs, but >it is based on per flow guarantees, not per class, and thus can have the same >problems associated with Intserv model like scalability and implementation >issues. Each flow reserves resources at every node it passes through. THe FQMM >simply suggests that the highest class gets per flow provisioning, while the >lower classes get per class provisioning, so in essence the model adds the >complexity of the two models. And it does not suggest any means of >implementing the model in MANETs. The basic issue still remains of which node >will mark the packets so that the subsequent nodes can process them >accrodingly. If the source node does that job, then there is a good chance >that the node can misbehave and use a DSCP corresponding to a high priority >PHB even when it does not need to. In that case, who does the policing to stop >the flow? > >thanks, >Harpreet > > >>===== Original Message From yasser.lotfy@lycos.com ===== >>Good answer, >>Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of >handling traffic between two nodes. The other model which provided some >enhancements to traditional DiffServ is the FQMM. >> >>Always try to distinguish signalling from the model. FQMM represent a model, >INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment >to RSVP. >> >>Ingress, and egress could be anynode. Ingress are always nodes initiating >traffic. Egress are those submitting traffic to different domain. >> >> >>Yasser >>Carleton University >> >>----------------------------------------------------------------- >>Hi Arora, >> >>Actually, diffserv pretty much acknowledges that every "core" node can just >>as easily also be an "edge" node, and may therefore have to worry about such >>complexities as access control from edge hosts. There is no attempt to >>prevent core nodes from being edge nodes. >> >>But diffserv does not get into any sort of signaling or access control >>mechanisms between diffserv nodes and edge user hosts. People have mentioned >>possible signaling mechanisms for use in diffserv nets, such as the RSVP >>PATH and RESV messages. But always, such discussions were cut short on the >>list, because they are not germaine to diffserv itself. >> >>What diffserv offers is really a set of per-hop behaviors that every >>diffserv node has to support as it routes diffserv-labeled packets. These >>PHBs, when aggregated across a diffserv routing domain, create so-called >>"per domain behaviors" for aggregated diffserv paths. That's it, pretty >>much. And the MIB/PIB needed for diffserv node management, of course. >> >>It seems difficult to be able to support diffserv routes with any sort of >>stability if the hops of any "aggregated path" come and go frequently, but I >>suppose this could make for an interesting research project! >> >>Bert >>albert.e.manfredi@boeing.com >> >> >>> -----Original Message----- >>> From: Harpreet Arora [mailto:ha33@drexel.edu] >>> Sent: Friday, April 26, 2002 2:50 PM >>> To: manet >>> Subject: [manet] QoS issues in MANETs >>> Importance: High >>> >>> >>> Hi, >>> >>> I am interested in finding the feasibility of a >>> differentiated services model >>> for MANETs. WHile thinking about the implementation of >>> diffserv in MANETs, I >>> came across the follwing problem : diffserv aims to push the >>> complexity to the >>> edge of the network, by dividing the network into edge and >>> core nodes. How can >>> we do this in a MANET? Specifically, how can we differentiate >>> the network of >>> nodes into edge and core nodes? Since the nodes are mobile, I >>> feel that every >>> node should have the capability of acting as an edge node, >>> which would mark, >>> meter and police the packets, and also as a core node, which >>> would simply >>> forward the packets on the basis of the DSCP. The nodes can >>> assume either >>> functionality depending on the situation. But what node assumes what >>> functionality is the question. Any suggestions? >>> >>> Harpreet >>> Research Assistant >>> ECE Department, Drexel University >>> Philadelphia, PA-19104 >>> >>> ******************************************************************** >>> A dream is just a dream. A goal is a dream with a plan and a deadline. >>> >>> A candle brightens the world around it. Unfortunately, it >>> creates a shadow of its own. It still serves the purpose it >>> is meant for. >>> ********************************************************************** >>> > > > >See Dave Matthews Band live or win a signed guitar >http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/ splash.asp > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 29 15:23:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12967 for ; Mon, 29 Apr 2002 15:23:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11324; Mon, 29 Apr 2002 14:31:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11290 for ; Mon, 29 Apr 2002 14:31:07 -0400 (EDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10324 for ; Mon, 29 Apr 2002 14:31:04 -0400 (EDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 14:30:32 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> From: Scott Corson To: "'Phil Neumiller'" , manet@ietf.org, "Dr. Chane L. Fullmer" Subject: RE: [manet] Link API was [ Link layer notification ] Date: Mon, 29 Apr 2002 14:30:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > Yes, it would be very interesting to see. I am not so much > interested in standardizing the > LLC/MAC layer API for the use of IP, as I am standardizing > the bottom half of IP looking > in from an LLC/MAC perspective. Phil, I'll second that, and I can see you're interested in building something useful... ;-) I've got a drafty draft written along these lines in hopes of an eventual L2 triggers BOF...very drafty of course as I've zero time to put into this. Maybe we should each throw some pasta at the IESG wall and see if anything sticks. ;-) -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 29 15:23:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12982 for ; Mon, 29 Apr 2002 15:23:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14596 for manet-archive@odin.ietf.org; Mon, 29 Apr 2002 15:23:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11324; Mon, 29 Apr 2002 14:31:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11290 for ; Mon, 29 Apr 2002 14:31:07 -0400 (EDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10324 for ; Mon, 29 Apr 2002 14:31:04 -0400 (EDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 14:30:32 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> From: Scott Corson To: "'Phil Neumiller'" , manet@ietf.org, "Dr. Chane L. Fullmer" Subject: RE: [manet] Link API was [ Link layer notification ] Date: Mon, 29 Apr 2002 14:30:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org > Yes, it would be very interesting to see. I am not so much > interested in standardizing the > LLC/MAC layer API for the use of IP, as I am standardizing > the bottom half of IP looking > in from an LLC/MAC perspective. Phil, I'll second that, and I can see you're interested in building something useful... ;-) I've got a drafty draft written along these lines in hopes of an eventual L2 triggers BOF...very drafty of course as I've zero time to put into this. Maybe we should each throw some pasta at the IESG wall and see if anything sticks. ;-) -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 29 16:05:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17599 for ; Mon, 29 Apr 2002 16:05:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15431; Mon, 29 Apr 2002 15:36:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15404 for ; Mon, 29 Apr 2002 15:36:05 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15238 for ; Mon, 29 Apr 2002 15:36:01 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYF17X; Mon, 29 Apr 2002 15:35:53 -0400 Message-ID: <02cd01c1efb5$13356530$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Scott Corson" , , "Dr. Chane L. Fullmer" Cc: "James Kempf" References: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Mon, 29 Apr 2002 15:35:53 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Scott, I have some drafty draft stuff too. Is anybody else interested in this? I will start writing a draft since I have been "complaining" about this for years, so its time for me to put up or shut up. :-) I will start the water boiling for the spaghetti and mail my own drafty draft to folks that are interested. Also, if I missing some major body of work that has happened on this matter in the IETF or elsewhere could somebody kindly point it out to me (its pretty hard to keep up with so much stuff)? The most essential things to me seem to be: 1). A generic interrupting system, where L2 can "call" (or call back / publish / tigger) something to the underbelly of IP and tell it something has happened. That something could simply be a code with no qualification or a code with complete TLV qualification, as long as the IP layers interpretation is consitent there is not a problem. This type of mechanism could be the basis for a generic L2 signaling mechanism. It could also be the basis for passing link status up to (and even more importantly through the IP layer as out of band data (OOBD)). Routing mechanisms residing above or at the IP layer would very much like to use information passed from the link layer. I suggest using the model view controller model for this. Subscriber ---> Publisher ^ ^ | | View --------> Model <---- Controller Where say a MANET routing protocol is a subcriber to certain classes of L2 information such as pilot notification or received signal strentgth indication RSSI. Some of these will be wireless specific, some optics specific etc, but either way they are not tied to any particular L2. 2). Certain categories of these triggers are essential "base class" triggers, i.e. get a hunk of signaling info (possibly in the form of TLV) up to IP efficiently. The more L2 independent the better (please don't suggest ASN.1!). 3). It is necessary for IP to support a plethora of LLC/MAC(L2s) simultaneously. Each of these L2s will have different behaviour classifications for TTL, TOS fields etc. It will be important to abstract the behaviors across many different L2s so that the particular L2 does not have to be identified, only its interaction pattern with IP. 4). One could also postulate multiple stacks on a host (IPv4 and IPv6 at least) where it may be desirable for the L2 to send IPv4 packets one way and others another way. Also, one could imagine running multiple stacks per virtual machine on some hosts and having the L2 send the traffic to the properly bound host IP stack (IPsec with multiple many hostile users comes to mind). Thanks, Phil ----- Original Message ----- From: "Scott Corson" To: "'Phil Neumiller'" ; ; "Dr. Chane L. Fullmer" Sent: Monday, April 29, 2002 2:30 PM Subject: RE: [manet] Link API was [ Link layer notification ] > > > Yes, it would be very interesting to see. I am not so much > > interested in standardizing the > > LLC/MAC layer API for the use of IP, as I am standardizing > > the bottom half of IP looking > > in from an LLC/MAC perspective. > > Phil, > > I'll second that, and I can see you're interested in building something > useful... ;-) > > I've got a drafty draft written along these lines in hopes of an eventual L2 > triggers BOF...very drafty of course as I've zero time to put into this. > Maybe we should each throw some pasta at the IESG wall and see if anything > sticks. ;-) > > -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 29 16:05:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17619 for ; Mon, 29 Apr 2002 16:05:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17297 for manet-archive@odin.ietf.org; Mon, 29 Apr 2002 16:05:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15431; Mon, 29 Apr 2002 15:36:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15404 for ; Mon, 29 Apr 2002 15:36:05 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15238 for ; Mon, 29 Apr 2002 15:36:01 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYF17X; Mon, 29 Apr 2002 15:35:53 -0400 Message-ID: <02cd01c1efb5$13356530$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Scott Corson" , , "Dr. Chane L. Fullmer" Cc: "James Kempf" References: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Mon, 29 Apr 2002 15:35:53 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi Scott, I have some drafty draft stuff too. Is anybody else interested in this? I will start writing a draft since I have been "complaining" about this for years, so its time for me to put up or shut up. :-) I will start the water boiling for the spaghetti and mail my own drafty draft to folks that are interested. Also, if I missing some major body of work that has happened on this matter in the IETF or elsewhere could somebody kindly point it out to me (its pretty hard to keep up with so much stuff)? The most essential things to me seem to be: 1). A generic interrupting system, where L2 can "call" (or call back / publish / tigger) something to the underbelly of IP and tell it something has happened. That something could simply be a code with no qualification or a code with complete TLV qualification, as long as the IP layers interpretation is consitent there is not a problem. This type of mechanism could be the basis for a generic L2 signaling mechanism. It could also be the basis for passing link status up to (and even more importantly through the IP layer as out of band data (OOBD)). Routing mechanisms residing above or at the IP layer would very much like to use information passed from the link layer. I suggest using the model view controller model for this. Subscriber ---> Publisher ^ ^ | | View --------> Model <---- Controller Where say a MANET routing protocol is a subcriber to certain classes of L2 information such as pilot notification or received signal strentgth indication RSSI. Some of these will be wireless specific, some optics specific etc, but either way they are not tied to any particular L2. 2). Certain categories of these triggers are essential "base class" triggers, i.e. get a hunk of signaling info (possibly in the form of TLV) up to IP efficiently. The more L2 independent the better (please don't suggest ASN.1!). 3). It is necessary for IP to support a plethora of LLC/MAC(L2s) simultaneously. Each of these L2s will have different behaviour classifications for TTL, TOS fields etc. It will be important to abstract the behaviors across many different L2s so that the particular L2 does not have to be identified, only its interaction pattern with IP. 4). One could also postulate multiple stacks on a host (IPv4 and IPv6 at least) where it may be desirable for the L2 to send IPv4 packets one way and others another way. Also, one could imagine running multiple stacks per virtual machine on some hosts and having the L2 send the traffic to the properly bound host IP stack (IPsec with multiple many hostile users comes to mind). Thanks, Phil ----- Original Message ----- From: "Scott Corson" To: "'Phil Neumiller'" ; ; "Dr. Chane L. Fullmer" Sent: Monday, April 29, 2002 2:30 PM Subject: RE: [manet] Link API was [ Link layer notification ] > > > Yes, it would be very interesting to see. I am not so much > > interested in standardizing the > > LLC/MAC layer API for the use of IP, as I am standardizing > > the bottom half of IP looking > > in from an LLC/MAC perspective. > > Phil, > > I'll second that, and I can see you're interested in building something > useful... ;-) > > I've got a drafty draft written along these lines in hopes of an eventual L2 > triggers BOF...very drafty of course as I've zero time to put into this. > Maybe we should each throw some pasta at the IESG wall and see if anything > sticks. ;-) > > -Scott _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 29 16:27:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18513 for ; Mon, 29 Apr 2002 16:27:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16405; Mon, 29 Apr 2002 15:59:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16375 for ; Mon, 29 Apr 2002 15:59:17 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17382 for ; Mon, 29 Apr 2002 15:59:14 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3TJwfpZ015533; Mon, 29 Apr 2002 12:58:41 -0700 (PDT) Message-Id: <5.1.0.14.2.20020429125125.01af1910@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Apr 2002 12:58:41 -0700 To: ogier@erg.sri.com From: Fred Baker Cc: manet@ietf.org In-Reply-To: <200204241843.LAA28596@pit.erg.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] Re: IPR issue for TBRPF Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At 08:43 AM 4/24/2002 -0700, ogier@erg.sri.com wrote: >Does your statement "when confronted with a choice between a proposal >encumbered with IPR issues and an unencumbered proposal, [the IETF] will >choose the unencumbered one", still apply when all IP rights are to be >relinquished upon standardization? If so, can you give me an example? Let me count the ways... I have had the privilege of watching the IETF deal with any number of IPR issues since 1989; the first I dealt with was the Open Distance Vector IGP, aka Cisco IGRP recast as a public standard, in which Cisco guaranteed that it would license the necessary technology for $1.00 to anyone who asked. We have had IPR issues in IPv6, in Compression and Encryption standards, in PKI Certificate management (Entrust's could-be-called-submarine-patent attempt deep-sixed the working group for a number of months, perhaps a year), and a variety of other places. My observation is my own, nobody else's, but it comes from someone who has been watching the IETF for a *long* time. If you want to guarantee a scramble, say the word "patent", and if you want to guarantee that the IETF will proceed in a direction only under duress, apply for one. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 29 16:27:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18532 for ; Mon, 29 Apr 2002 16:27:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19284 for manet-archive@odin.ietf.org; Mon, 29 Apr 2002 16:27:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16405; Mon, 29 Apr 2002 15:59:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16375 for ; Mon, 29 Apr 2002 15:59:17 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17382 for ; Mon, 29 Apr 2002 15:59:14 -0400 (EDT) Received: from FRED-W2K6.cisco.com ([10.25.10.242]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3TJwfpZ015533; Mon, 29 Apr 2002 12:58:41 -0700 (PDT) Message-Id: <5.1.0.14.2.20020429125125.01af1910@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 29 Apr 2002 12:58:41 -0700 To: ogier@erg.sri.com From: Fred Baker Cc: manet@ietf.org In-Reply-To: <200204241843.LAA28596@pit.erg.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] Re: IPR issue for TBRPF Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At 08:43 AM 4/24/2002 -0700, ogier@erg.sri.com wrote: >Does your statement "when confronted with a choice between a proposal >encumbered with IPR issues and an unencumbered proposal, [the IETF] will >choose the unencumbered one", still apply when all IP rights are to be >relinquished upon standardization? If so, can you give me an example? Let me count the ways... I have had the privilege of watching the IETF deal with any number of IPR issues since 1989; the first I dealt with was the Open Distance Vector IGP, aka Cisco IGRP recast as a public standard, in which Cisco guaranteed that it would license the necessary technology for $1.00 to anyone who asked. We have had IPR issues in IPv6, in Compression and Encryption standards, in PKI Certificate management (Entrust's could-be-called-submarine-patent attempt deep-sixed the working group for a number of months, perhaps a year), and a variety of other places. My observation is my own, nobody else's, but it comes from someone who has been watching the IETF for a *long* time. If you want to guarantee a scramble, say the word "patent", and if you want to guarantee that the IETF will proceed in a direction only under duress, apply for one. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 29 19:03:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22317 for ; Mon, 29 Apr 2002 19:03:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26085; Mon, 29 Apr 2002 18:26:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26055 for ; Mon, 29 Apr 2002 18:26:50 -0400 (EDT) Received: from web11702.mail.yahoo.com (web11702.mail.yahoo.com [216.136.172.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21581 for ; Mon, 29 Apr 2002 18:26:45 -0400 (EDT) Message-ID: <20020429222648.65187.qmail@web11702.mail.yahoo.com> Received: from [128.251.168.92] by web11702.mail.yahoo.com via HTTP; Mon, 29 Apr 2002 15:26:48 PDT Date: Mon, 29 Apr 2002 15:26:48 -0700 (PDT) From: Behcet Sarikaya Subject: RE: [manet] Link API was [ Link layer notification ] To: Scott Corson , "'Phil Neumiller'" , manet@ietf.org, "Dr. Chane L. Fullmer" Cc: carlw@docomolabs-usa.com In-Reply-To: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Scott and Phil, I did attend L2 Triggers BOF at Minneapolis. I think it was decided to use pilc mailing list (apparently not manet) to discuss it further in the hopes of having a BOF at IETF 54. But so far no discussions on pilc. I am ccing this mail to Carl so that he follows it up. --- Scott Corson wrote: > > > Yes, it would be very interesting to see. I am > not so much > > interested in standardizing the > > LLC/MAC layer API for the use of IP, as I am > standardizing > > the bottom half of IP looking > > in from an LLC/MAC perspective. > > Phil, > > I'll second that, and I can see you're interested in > building something > useful... ;-) > > I've got a drafty draft written along these lines in > hopes of an eventual L2 > triggers BOF...very drafty of course as I've zero > time to put into this. > Maybe we should each throw some pasta at the IESG > wall and see if anything > sticks. ;-) > > -Scott > --behcet __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 29 19:03:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22329 for ; Mon, 29 Apr 2002 19:03:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28855 for manet-archive@odin.ietf.org; Mon, 29 Apr 2002 19:03:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26085; Mon, 29 Apr 2002 18:26:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26055 for ; Mon, 29 Apr 2002 18:26:50 -0400 (EDT) Received: from web11702.mail.yahoo.com (web11702.mail.yahoo.com [216.136.172.68]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21581 for ; Mon, 29 Apr 2002 18:26:45 -0400 (EDT) Message-ID: <20020429222648.65187.qmail@web11702.mail.yahoo.com> Received: from [128.251.168.92] by web11702.mail.yahoo.com via HTTP; Mon, 29 Apr 2002 15:26:48 PDT Date: Mon, 29 Apr 2002 15:26:48 -0700 (PDT) From: Behcet Sarikaya Subject: RE: [manet] Link API was [ Link layer notification ] To: Scott Corson , "'Phil Neumiller'" , manet@ietf.org, "Dr. Chane L. Fullmer" Cc: carlw@docomolabs-usa.com In-Reply-To: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Hello Scott and Phil, I did attend L2 Triggers BOF at Minneapolis. I think it was decided to use pilc mailing list (apparently not manet) to discuss it further in the hopes of having a BOF at IETF 54. But so far no discussions on pilc. I am ccing this mail to Carl so that he follows it up. --- Scott Corson wrote: > > > Yes, it would be very interesting to see. I am > not so much > > interested in standardizing the > > LLC/MAC layer API for the use of IP, as I am > standardizing > > the bottom half of IP looking > > in from an LLC/MAC perspective. > > Phil, > > I'll second that, and I can see you're interested in > building something > useful... ;-) > > I've got a drafty draft written along these lines in > hopes of an eventual L2 > triggers BOF...very drafty of course as I've zero > time to put into this. > Maybe we should each throw some pasta at the IESG > wall and see if anything > sticks. ;-) > > -Scott > --behcet __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 29 19:35:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23229 for ; Mon, 29 Apr 2002 19:35:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29586; Mon, 29 Apr 2002 19:11:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20114 for ; Thu, 25 Apr 2002 12:29:12 -0400 (EDT) Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26432 for ; Thu, 25 Apr 2002 12:29:07 -0400 (EDT) Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id SAA21641 for ; Thu, 25 Apr 2002 18:29:30 +0200 (MET DST) Message-ID: <3CC82EF2.2000602@telecom.lth.se> Date: Thu, 25 Apr 2002 18:29:38 +0200 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: MANET mailing list Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------020700040605090601060605" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------020700040605090601060605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Phil! (and Charlie) What Charlie writes is mentioned briefly in appendix B of the draft. >>2). The mobile MUST use this home address when forming a MANET. >> > >I don't think this is acceptable, nor in the spirit of IPv6 address >autoconfiguration. I have always thought that any IPv6 node should >be able to use any address that it can successfully (and correcctly) >configure. > If the node upon startup doesn't have any availble permanent address, (such as a Mobile IPv6 address), we propose that node can configure a temporary address by using the MANET_INITIAL_PREFIX during the aquisition of the global address. regards, Anders N --------------020700040605090601060605 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Phil! (and Charlie)

What Charlie writes is mentioned briefly in appendix B of the draft.
2).  The mobile MUST use this home address when forming a MANET.

I don't think this is acceptable, nor in the spirit of IPv6 address
autoconfiguration.  I have always thought that any IPv6 node should
be able to use any address that it can successfully (and correcctly)
configure.
If the node upon startup doesn't have any availble permanent address, (such as a
Mobile IPv6 address), we propose that node can configure a temporary address
by using the MANET_INITIAL_PREFIX during the aquisition of the global address.

regards,

Anders N
--------------020700040605090601060605-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 29 19:35:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23240 for ; Mon, 29 Apr 2002 19:35:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02412 for manet-archive@odin.ietf.org; Mon, 29 Apr 2002 19:35:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29586; Mon, 29 Apr 2002 19:11:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20114 for ; Thu, 25 Apr 2002 12:29:12 -0400 (EDT) Received: from anyida.tts.lth.se (anyida.tts.lth.se [130.235.18.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26432 for ; Thu, 25 Apr 2002 12:29:07 -0400 (EDT) Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id SAA21641 for ; Thu, 25 Apr 2002 18:29:30 +0200 (MET DST) Message-ID: <3CC82EF2.2000602@telecom.lth.se> Date: Thu, 25 Apr 2002 18:29:38 +0200 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: MANET mailing list Subject: Re: [manet] Preliminary comment on draft-wakikawa-manet-globalv6-00.txt References: <007501c1ec6d$be341800$6200000a@meshnetworks.com> <3CC827F8.C347C2B2@iprg.nokia.com> Content-Type: multipart/alternative; boundary="------------020700040605090601060605" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org --------------020700040605090601060605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Phil! (and Charlie) What Charlie writes is mentioned briefly in appendix B of the draft. >>2). The mobile MUST use this home address when forming a MANET. >> > >I don't think this is acceptable, nor in the spirit of IPv6 address >autoconfiguration. I have always thought that any IPv6 node should >be able to use any address that it can successfully (and correcctly) >configure. > If the node upon startup doesn't have any availble permanent address, (such as a Mobile IPv6 address), we propose that node can configure a temporary address by using the MANET_INITIAL_PREFIX during the aquisition of the global address. regards, Anders N --------------020700040605090601060605 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Phil! (and Charlie)

What Charlie writes is mentioned briefly in appendix B of the draft.
2).  The mobile MUST use this home address when forming a MANET.

I don't think this is acceptable, nor in the spirit of IPv6 address
autoconfiguration.  I have always thought that any IPv6 node should
be able to use any address that it can successfully (and correcctly)
configure.
If the node upon startup doesn't have any availble permanent address, (such as a
Mobile IPv6 address), we propose that node can configure a temporary address
by using the MANET_INITIAL_PREFIX during the aquisition of the global address.

regards,

Anders N
--------------020700040605090601060605-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 29 19:35:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23259 for ; Mon, 29 Apr 2002 19:35:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29241; Mon, 29 Apr 2002 19:09:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23504 for ; Fri, 26 Apr 2002 12:07:52 -0400 (EDT) Received: from cismrelais.univ-lyon1.fr (cismrelais.univ-lyon1.fr [134.214.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09271 for ; Fri, 26 Apr 2002 12:07:48 -0400 (EDT) Received: by cismrelais.univ-lyon1.fr (Postfix, from userid 1000) id 30A10388AD; Fri, 26 Apr 2002 18:07:51 +0200 (CEST) Received: from ares-fleury-1.insa-lyon.fr (ares-fleury-1.insa-lyon.fr [134.214.144.147]) by cismrelais.univ-lyon1.fr (Postfix) with ESMTP id 47C1A33B9F for ; Fri, 26 Apr 2002 18:06:47 +0200 (CEST) Received: (from fleury@localhost) by ares-fleury-1.insa-lyon.fr (8.11.2/8.8.7) id g3QFvLc07549 for manet@ietf.org; Fri, 26 Apr 2002 17:57:21 +0200 Date: Fri, 26 Apr 2002 17:57:21 +0200 From: Eric Fleury Message-Id: <200204261557.g3QFvLc07549@ares-fleury-1.insa-lyon.fr> To: manet@ietf.org X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Subject: [manet] CFP: DIALM 2002: Extended deadline to May 12 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org The deadline for DIALM 2002 paper submission has been extended to May 12, 2002. ----------------------------------------------------------------------- Please could you broadcast this message. Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- _____________________________ F I N A L C A L L F O R P A P E R S *** DEADLINE EXTENDED TO MAY 12*** ----------------------------- DIAL M for Mobility ___________________ 6th International Workshop on Discrete Algorithms and Methods for Mobile Computing and Communications September, 28, 2002 Atlanta, Georgia, USA (In conjunction with ACM MobiCom 2002) Sponsored by ACM Sigmobile (pending) http://dialm.insa-lyon.fr/ SCOPE Mobile computing and communications such as portable phones and Personal Digital Assistants will have an enormous impact on all of us over the next several decades. The introduction of mobility raises a number of new research questions. For many of them, approaches based on the continuous case are not satisfactory, and discrete models and algorithms are required in order to deal with real applications. The workshop DIAL M for Mobility is devoted to discrete algorithms and discrete modelling in the context of mobile and wireless computing and communications. It is intended to be a lively meeting, covering many of the algorithmic and discrete aspects of this field going from operations research to radio engineering problems. It aims, in particular, at fostering the cooperation among practitioners and theoreticians of the field. Following the success the first workshop held jointly with Mobicom 97 in Budapest, DIAL M for Mobility will be co-located with ACM/IEEE MobiCom 98 and will be composed of contributed and invited talks. TOPICS Papers are solicited in all research and applied areas related to mobile and wireless computing and communications where discrete algorithms and methods are used, including, but not limited to: * distributed algorithms * frequency allocation * location tracking * multihop packet radio networks * wireless networks * cryptography and security * error correcting codes * handover (handoff) * modelling * optimization * routing * satellite communication * scheduling * site allocation * synchronization * telecommunications PUBLICATION All contributions will be refereed by the Program Committee. All accepted papers will appear (7 to 10 pages each) in the workshop proceedings which will be published by ACM. SUBMISSION GUIDELINES The language of the conference is English. All submissions should be original and not currently under review by any other publication or conference. All papers will be reviewed by two or more reviewers. Accepted proposals will be published in the conference proceedings. It is expected that all accepted papers will be presented at the workshop. Papers should be full papers and be no longer than 5000 words (no more than 10 single-spaced pages). Submissions must include a cover page, containing the title, author name(s) and affiliation(s), the complete address (telephone, fax, email) of the corresponding author, and an abstract (max 150 words) followed by up to 5 keywords. Authors are requested to submit an electronic version (PDF or A4 Postscript format) of the paper. The PDF format is strongly recommended. All submissions will be handled electronically. You will submit your proposal via the WEB (http://dialm.insa-lyon.fr/) or E-MAIL (Eric.Fleury@inria.fr) if your web access is limited). Please review all these instructions before submitting your paper: * PDF format or * PostScript version 2 or later. * No longer than 10 pages. * Fits properly on "US Letter" size paper (8.5X11 inches) * Reference only Computer Modern or standard Adobe printer fonts * (i.e. Courier, Times, Roman, or Helvetica); other fonts may be used * but must be included in the PostScript file. IMPORTANT DATES * Final Paper Submission Deadline: May 12, 2002 * Notification of acceptance: June 15, 2002 * Camera-ready papers due: July 15, 2002 * Workshop: September, 28, 2002 ORGANIZATION CONFERENCE CHAIRS Éric FLEURY CITI/INRIA Rhône-Alpes Domaine Scientifique de la Doua - INSA de Lyon Bât. Léonard de Vinci - 21 av. Jean Capelle F-69621 Villeurbanne Cedex France Work Phone: +33 472 434 421 Fax Number: +33 472 436 227 Email: Eric.Fleury@inria.fr Madhav MARATHE Los Alamos National Laboratory P.O. Box 1663 Los Alamos, NM 87545 USA Work Phone: +1 505 667 8010 Fax Number: +1 505 665 6474 Email: marathe@lanl.gov TECHNICAL PROGRAM COMMITTEE P. Agarwal, Duke University, USA A. Bar-Noy, CUNY -- Brooklyn College, USA P. Crescenzi, U. Firenze, Italia B. Ducourthial, UTC, France M. Gerla, UCLA, USA P. Jacquet, INRIA, France S. Krumke, ZIB Berlin, Germany J-Y. Leboudec, EPFL, Switzerland G. R. Mateus, UFMG, Brasil M. Morvan, ENS-Lyon, France S. Naor, Technion, Israel D. Peleg, Weizmann Institute, Israel C. Phillips, Sandia National Laboratories, USA A. Richa, ASU, USA B. Schieber, IBM Watson, USA M. Steenstrup, BBN, USA A. Srinivasan, University of Maryland, USA P. Widmayer, ETH Zurich, Switzerland STEERING COMMITTEE Ian Akyildiz, Georgia Tech, USA Maurizio Bonuccelli, University of Pisa, Italy Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France E. Lloyd, University of Delaware, USA Arunabha Sen, Arizona State University, USA. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 29 19:35:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23273 for ; Mon, 29 Apr 2002 19:35:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02427 for manet-archive@odin.ietf.org; Mon, 29 Apr 2002 19:35:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29241; Mon, 29 Apr 2002 19:09:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23504 for ; Fri, 26 Apr 2002 12:07:52 -0400 (EDT) Received: from cismrelais.univ-lyon1.fr (cismrelais.univ-lyon1.fr [134.214.101.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09271 for ; Fri, 26 Apr 2002 12:07:48 -0400 (EDT) Received: by cismrelais.univ-lyon1.fr (Postfix, from userid 1000) id 30A10388AD; Fri, 26 Apr 2002 18:07:51 +0200 (CEST) Received: from ares-fleury-1.insa-lyon.fr (ares-fleury-1.insa-lyon.fr [134.214.144.147]) by cismrelais.univ-lyon1.fr (Postfix) with ESMTP id 47C1A33B9F for ; Fri, 26 Apr 2002 18:06:47 +0200 (CEST) Received: (from fleury@localhost) by ares-fleury-1.insa-lyon.fr (8.11.2/8.8.7) id g3QFvLc07549 for manet@ietf.org; Fri, 26 Apr 2002 17:57:21 +0200 Date: Fri, 26 Apr 2002 17:57:21 +0200 From: Eric Fleury Message-Id: <200204261557.g3QFvLc07549@ares-fleury-1.insa-lyon.fr> To: manet@ietf.org X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Subject: [manet] CFP: DIALM 2002: Extended deadline to May 12 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org The deadline for DIALM 2002 paper submission has been extended to May 12, 2002. ----------------------------------------------------------------------- Please could you broadcast this message. Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- _____________________________ F I N A L C A L L F O R P A P E R S *** DEADLINE EXTENDED TO MAY 12*** ----------------------------- DIAL M for Mobility ___________________ 6th International Workshop on Discrete Algorithms and Methods for Mobile Computing and Communications September, 28, 2002 Atlanta, Georgia, USA (In conjunction with ACM MobiCom 2002) Sponsored by ACM Sigmobile (pending) http://dialm.insa-lyon.fr/ SCOPE Mobile computing and communications such as portable phones and Personal Digital Assistants will have an enormous impact on all of us over the next several decades. The introduction of mobility raises a number of new research questions. For many of them, approaches based on the continuous case are not satisfactory, and discrete models and algorithms are required in order to deal with real applications. The workshop DIAL M for Mobility is devoted to discrete algorithms and discrete modelling in the context of mobile and wireless computing and communications. It is intended to be a lively meeting, covering many of the algorithmic and discrete aspects of this field going from operations research to radio engineering problems. It aims, in particular, at fostering the cooperation among practitioners and theoreticians of the field. Following the success the first workshop held jointly with Mobicom 97 in Budapest, DIAL M for Mobility will be co-located with ACM/IEEE MobiCom 98 and will be composed of contributed and invited talks. TOPICS Papers are solicited in all research and applied areas related to mobile and wireless computing and communications where discrete algorithms and methods are used, including, but not limited to: * distributed algorithms * frequency allocation * location tracking * multihop packet radio networks * wireless networks * cryptography and security * error correcting codes * handover (handoff) * modelling * optimization * routing * satellite communication * scheduling * site allocation * synchronization * telecommunications PUBLICATION All contributions will be refereed by the Program Committee. All accepted papers will appear (7 to 10 pages each) in the workshop proceedings which will be published by ACM. SUBMISSION GUIDELINES The language of the conference is English. All submissions should be original and not currently under review by any other publication or conference. All papers will be reviewed by two or more reviewers. Accepted proposals will be published in the conference proceedings. It is expected that all accepted papers will be presented at the workshop. Papers should be full papers and be no longer than 5000 words (no more than 10 single-spaced pages). Submissions must include a cover page, containing the title, author name(s) and affiliation(s), the complete address (telephone, fax, email) of the corresponding author, and an abstract (max 150 words) followed by up to 5 keywords. Authors are requested to submit an electronic version (PDF or A4 Postscript format) of the paper. The PDF format is strongly recommended. All submissions will be handled electronically. You will submit your proposal via the WEB (http://dialm.insa-lyon.fr/) or E-MAIL (Eric.Fleury@inria.fr) if your web access is limited). Please review all these instructions before submitting your paper: * PDF format or * PostScript version 2 or later. * No longer than 10 pages. * Fits properly on "US Letter" size paper (8.5X11 inches) * Reference only Computer Modern or standard Adobe printer fonts * (i.e. Courier, Times, Roman, or Helvetica); other fonts may be used * but must be included in the PostScript file. IMPORTANT DATES * Final Paper Submission Deadline: May 12, 2002 * Notification of acceptance: June 15, 2002 * Camera-ready papers due: July 15, 2002 * Workshop: September, 28, 2002 ORGANIZATION CONFERENCE CHAIRS Éric FLEURY CITI/INRIA Rhône-Alpes Domaine Scientifique de la Doua - INSA de Lyon Bât. Léonard de Vinci - 21 av. Jean Capelle F-69621 Villeurbanne Cedex France Work Phone: +33 472 434 421 Fax Number: +33 472 436 227 Email: Eric.Fleury@inria.fr Madhav MARATHE Los Alamos National Laboratory P.O. Box 1663 Los Alamos, NM 87545 USA Work Phone: +1 505 667 8010 Fax Number: +1 505 665 6474 Email: marathe@lanl.gov TECHNICAL PROGRAM COMMITTEE P. Agarwal, Duke University, USA A. Bar-Noy, CUNY -- Brooklyn College, USA P. Crescenzi, U. Firenze, Italia B. Ducourthial, UTC, France M. Gerla, UCLA, USA P. Jacquet, INRIA, France S. Krumke, ZIB Berlin, Germany J-Y. Leboudec, EPFL, Switzerland G. R. Mateus, UFMG, Brasil M. Morvan, ENS-Lyon, France S. Naor, Technion, Israel D. Peleg, Weizmann Institute, Israel C. Phillips, Sandia National Laboratories, USA A. Richa, ASU, USA B. Schieber, IBM Watson, USA M. Steenstrup, BBN, USA A. Srinivasan, University of Maryland, USA P. Widmayer, ETH Zurich, Switzerland STEERING COMMITTEE Ian Akyildiz, Georgia Tech, USA Maurizio Bonuccelli, University of Pisa, Italy Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France E. Lloyd, University of Delaware, USA Arunabha Sen, Arizona State University, USA. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 29 19:36:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23319 for ; Mon, 29 Apr 2002 19:36:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29638; Mon, 29 Apr 2002 19:11:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25302 for ; Mon, 29 Apr 2002 18:14:22 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21460 for ; Mon, 29 Apr 2002 18:14:17 -0400 (EDT) Message-ID: <023f01c1efca$f8bf3f80$7e6015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller" , "Scott Corson" , , "Dr. Chane L. Fullmer" Cc: "Carl Williams" , "Aaron Falk" References: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> <02cd01c1efb5$13356530$6200000a@meshnetworks.com> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Mon, 29 Apr 2002 15:12:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Phil, I think these would be of potential interest to the L2 triggers BOF. jak ----- Original Message ----- From: "Phil Neumiller" To: "Scott Corson" ; ; "Dr. Chane L. Fullmer" Cc: "James Kempf" Sent: Monday, April 29, 2002 12:35 PM Subject: Re: [manet] Link API was [ Link layer notification ] > Hi Scott, > > I have some drafty draft stuff too. Is anybody else interested in this? I will start writing a draft > since I have been "complaining" about this for years, so its time for me to put up or shut up. :-) > I will start the water boiling for the spaghetti and mail my own drafty draft to folks that are > interested. Also, if I missing some major body of work that has happened on this matter in > the IETF or elsewhere could somebody kindly point it out to me (its pretty hard to keep up > with so much stuff)? > > The most essential things to me seem to be: > > 1). A generic interrupting system, where L2 can "call" (or call back / publish / tigger) something to > the underbelly of IP and tell it something has happened. That something could simply be > a code with no qualification or a code with complete TLV qualification, as long as the IP > layers interpretation is consitent there is not a problem. > > This type of mechanism could be the basis for a generic L2 signaling mechanism. It could also > be the basis for passing link status up to (and even more importantly through the IP layer > as out of band data (OOBD)). Routing mechanisms residing above or at the IP layer would > very much like to use information passed from the link layer. I suggest using the model view > controller model for this. > > Subscriber ---> Publisher > ^ ^ > | | > View --------> Model <---- Controller > > Where say a MANET routing protocol is a subcriber to certain classes of L2 information such as > pilot notification or received signal strentgth indication RSSI. Some of these will be wireless > specific, some optics specific etc, but either way they are not tied to any particular L2. > > 2). Certain categories of these triggers are essential "base class" triggers, i.e. get a hunk of > signaling info (possibly in the form of TLV) up to IP efficiently. The more L2 independent > the better (please don't suggest ASN.1!). > > 3). It is necessary for IP to support a plethora of LLC/MAC(L2s) simultaneously. Each of these > L2s will have different behaviour classifications for TTL, TOS fields etc. It will be important > to abstract the behaviors across many different L2s so that the particular L2 does not have > to be identified, only its interaction pattern with IP. > > 4). One could also postulate multiple stacks on a host (IPv4 and IPv6 at least) where it may be > desirable for the L2 to send IPv4 packets one way and others another way. Also, one could > imagine running multiple stacks per virtual machine on some hosts and having the L2 send > the traffic to the properly bound host IP stack (IPsec with multiple many hostile users comes > to mind). > > Thanks, > > Phil > > > ----- Original Message ----- > From: "Scott Corson" > To: "'Phil Neumiller'" ; ; "Dr. Chane L. Fullmer" > Sent: Monday, April 29, 2002 2:30 PM > Subject: RE: [manet] Link API was [ Link layer notification ] > > > > > > > Yes, it would be very interesting to see. I am not so much > > > interested in standardizing the > > > LLC/MAC layer API for the use of IP, as I am standardizing > > > the bottom half of IP looking > > > in from an LLC/MAC perspective. > > > > Phil, > > > > I'll second that, and I can see you're interested in building something > > useful... ;-) > > > > I've got a drafty draft written along these lines in hopes of an eventual L2 > > triggers BOF...very drafty of course as I've zero time to put into this. > > Maybe we should each throw some pasta at the IESG wall and see if anything > > sticks. ;-) > > > > -Scott > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 29 19:36:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23330 for ; Mon, 29 Apr 2002 19:36:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02486 for manet-archive@odin.ietf.org; Mon, 29 Apr 2002 19:36:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29638; Mon, 29 Apr 2002 19:11:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25302 for ; Mon, 29 Apr 2002 18:14:22 -0400 (EDT) Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21460 for ; Mon, 29 Apr 2002 18:14:17 -0400 (EDT) Message-ID: <023f01c1efca$f8bf3f80$7e6015ac@T23KEMPF> From: "James Kempf" To: "Phil Neumiller" , "Scott Corson" , , "Dr. Chane L. Fullmer" Cc: "Carl Williams" , "Aaron Falk" References: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> <02cd01c1efb5$13356530$6200000a@meshnetworks.com> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Mon, 29 Apr 2002 15:12:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Phil, I think these would be of potential interest to the L2 triggers BOF. jak ----- Original Message ----- From: "Phil Neumiller" To: "Scott Corson" ; ; "Dr. Chane L. Fullmer" Cc: "James Kempf" Sent: Monday, April 29, 2002 12:35 PM Subject: Re: [manet] Link API was [ Link layer notification ] > Hi Scott, > > I have some drafty draft stuff too. Is anybody else interested in this? I will start writing a draft > since I have been "complaining" about this for years, so its time for me to put up or shut up. :-) > I will start the water boiling for the spaghetti and mail my own drafty draft to folks that are > interested. Also, if I missing some major body of work that has happened on this matter in > the IETF or elsewhere could somebody kindly point it out to me (its pretty hard to keep up > with so much stuff)? > > The most essential things to me seem to be: > > 1). A generic interrupting system, where L2 can "call" (or call back / publish / tigger) something to > the underbelly of IP and tell it something has happened. That something could simply be > a code with no qualification or a code with complete TLV qualification, as long as the IP > layers interpretation is consitent there is not a problem. > > This type of mechanism could be the basis for a generic L2 signaling mechanism. It could also > be the basis for passing link status up to (and even more importantly through the IP layer > as out of band data (OOBD)). Routing mechanisms residing above or at the IP layer would > very much like to use information passed from the link layer. I suggest using the model view > controller model for this. > > Subscriber ---> Publisher > ^ ^ > | | > View --------> Model <---- Controller > > Where say a MANET routing protocol is a subcriber to certain classes of L2 information such as > pilot notification or received signal strentgth indication RSSI. Some of these will be wireless > specific, some optics specific etc, but either way they are not tied to any particular L2. > > 2). Certain categories of these triggers are essential "base class" triggers, i.e. get a hunk of > signaling info (possibly in the form of TLV) up to IP efficiently. The more L2 independent > the better (please don't suggest ASN.1!). > > 3). It is necessary for IP to support a plethora of LLC/MAC(L2s) simultaneously. Each of these > L2s will have different behaviour classifications for TTL, TOS fields etc. It will be important > to abstract the behaviors across many different L2s so that the particular L2 does not have > to be identified, only its interaction pattern with IP. > > 4). One could also postulate multiple stacks on a host (IPv4 and IPv6 at least) where it may be > desirable for the L2 to send IPv4 packets one way and others another way. Also, one could > imagine running multiple stacks per virtual machine on some hosts and having the L2 send > the traffic to the properly bound host IP stack (IPsec with multiple many hostile users comes > to mind). > > Thanks, > > Phil > > > ----- Original Message ----- > From: "Scott Corson" > To: "'Phil Neumiller'" ; ; "Dr. Chane L. Fullmer" > Sent: Monday, April 29, 2002 2:30 PM > Subject: RE: [manet] Link API was [ Link layer notification ] > > > > > > > Yes, it would be very interesting to see. I am not so much > > > interested in standardizing the > > > LLC/MAC layer API for the use of IP, as I am standardizing > > > the bottom half of IP looking > > > in from an LLC/MAC perspective. > > > > Phil, > > > > I'll second that, and I can see you're interested in building something > > useful... ;-) > > > > I've got a drafty draft written along these lines in hopes of an eventual L2 > > triggers BOF...very drafty of course as I've zero time to put into this. > > Maybe we should each throw some pasta at the IESG wall and see if anything > > sticks. ;-) > > > > -Scott > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 29 19:39:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23391 for ; Mon, 29 Apr 2002 19:39:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29831; Mon, 29 Apr 2002 19:12:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21102 for ; Thu, 25 Apr 2002 05:39:17 -0400 (EDT) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29998 for ; Thu, 25 Apr 2002 05:39:13 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18571; Thu, 25 Apr 2002 03:39:15 -0600 (MDT) Received: from sun.com (vpn-129-156-96-12.EMEA.Sun.COM [129.156.96.12]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g3P9d9g01836; Thu, 25 Apr 2002 11:39:09 +0200 (MEST) Message-ID: <3CC7CB9A.C05BB000@sun.com> Date: Thu, 25 Apr 2002 11:25:47 +0200 From: gabriel montenegro Reply-To: gab@sun.com X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Claude Castelluccia CC: Philippe Jacquet , manet@ietf.org Subject: Re: [manet] Re: Re Security considerations in MANET References: <00bc01c1ec2b$95a8c8a0$1d1fc7c2@charmette.inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Claude Castelluccia wrote: > There are at least two good reasons for combining it with the routing > protocol: Just to reinforce what Claude said but stepping back a bit. It is all too common when designing network protocols that the specification is first done assuming (perhaps implicitly) primarily well-behaving and conforming host population. Security is left for later. But if you're serious about security you start with security. The idea with this approach in general is to try to secure from the very beginning. If one doesn't do this and takes any routing message at face value, this will populate routing tables throughout with unverified information. It seems simpler to only populate tables after verifying information (or at least provide the means to do so). This also implies the less change to the spec and implementations of whatever protocol you're using. Otherwise, you might have to augment your routing table to distinguish between verified and unverified entries, and handling those two can get messy. -gabriel _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 29 19:39:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23405 for ; Mon, 29 Apr 2002 19:39:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02744 for manet-archive@odin.ietf.org; Mon, 29 Apr 2002 19:39:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29831; Mon, 29 Apr 2002 19:12:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21102 for ; Thu, 25 Apr 2002 05:39:17 -0400 (EDT) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29998 for ; Thu, 25 Apr 2002 05:39:13 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18571; Thu, 25 Apr 2002 03:39:15 -0600 (MDT) Received: from sun.com (vpn-129-156-96-12.EMEA.Sun.COM [129.156.96.12]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g3P9d9g01836; Thu, 25 Apr 2002 11:39:09 +0200 (MEST) Message-ID: <3CC7CB9A.C05BB000@sun.com> Date: Thu, 25 Apr 2002 11:25:47 +0200 From: gabriel montenegro Reply-To: gab@sun.com X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Claude Castelluccia CC: Philippe Jacquet , manet@ietf.org Subject: Re: [manet] Re: Re Security considerations in MANET References: <00bc01c1ec2b$95a8c8a0$1d1fc7c2@charmette.inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Claude Castelluccia wrote: > There are at least two good reasons for combining it with the routing > protocol: Just to reinforce what Claude said but stepping back a bit. It is all too common when designing network protocols that the specification is first done assuming (perhaps implicitly) primarily well-behaving and conforming host population. Security is left for later. But if you're serious about security you start with security. The idea with this approach in general is to try to secure from the very beginning. If one doesn't do this and takes any routing message at face value, this will populate routing tables throughout with unverified information. It seems simpler to only populate tables after verifying information (or at least provide the means to do so). This also implies the less change to the spec and implementations of whatever protocol you're using. Otherwise, you might have to augment your routing table to distinguish between verified and unverified entries, and handling those two can get messy. -gabriel _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Mon Apr 29 19:57:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23749 for ; Mon, 29 Apr 2002 19:57:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29277; Mon, 29 Apr 2002 19:09:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14045 for ; Fri, 19 Apr 2002 18:27:04 -0400 (EDT) Received: from c000.snv.cp.net (h007.c000.snv.cp.net [209.228.32.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12041 for ; Fri, 19 Apr 2002 18:26:55 -0400 (EDT) Received: (cpmta 10526 invoked from network); 19 Apr 2002 15:26:27 -0700 Received: from 12.221.64.123 (HELO Carter.net) by smtp.carter.net (209.228.32.71) with SMTP; 19 Apr 2002 15:26:27 -0700 X-Sent: 19 Apr 2002 22:26:27 GMT Message-ID: <3CC09928.5030206@Carter.net> Date: Fri, 19 Apr 2002 17:24:40 -0500 From: Casey Carter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manel Guerrero Zapata CC: ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Manel Guerrero Zapata wrote: > Hi Casey, > > That is a very good observation. Because if two nodes simulate that > they have a link, it is very complicated to detect that they actualy > don't > have a link (even with misbehavior detection schemes). > > I've been thinking about the whole problem for a while > and I realized about a funny thing: > > I usually thing about AODV route discovery assuming that it returns > the shortest path between originator and destination. > But that's not really true. Is it? > > It returns the shortest path among the paths through which the RREQ > traveled faster from the originator to each final or intermediate node > that has the route to the destination. > (Or just the fastest one, in the case no intermediate nodes know a route > to de destination). And that's the selected path in AODV. > > 8<------------------------------------------------- > 6.5. Processing and Forwarding Route Requests > > When a node receives a RREQ, it first checks to determine whether it > has received a RREQ with the same Originator IP Address and RREQ ID > within at least the last PATH_TRAVERSAL_TIME milliseconds. If such a > RREQ has been received, the node silently discards the newly received > RREQ. The rest of this subsection describes actions taken for RREQs > that are not discarded. > ------------------------------------------------->8 > > According to this ... > > A-----B------C------D > \ / > --E--F--G-- > > ... if A initiates a route discovery to D, > and C receives first the RREQ from G than from B the discovered > route will be this one: A E F G C D > and not: A B C D. > Because when C receives the RREQ from B, C "silently discards" the > packet. Yes, this is characteristic of on-demand routing protocols, not just AODV. > > > So for the attack you are suggesting to succeed, they would have to > manage that > the RREQ forwarded by the second bad guy (with the faked hop count) will > be the fastest one to reach one of those nodes who can issue a RREP back > (because they are intermediate nodes that have a route to the > destination, > or because they are the destination). > And that is not easy because that means that they actually have to be the > fastest path (acording to AODV policy of RREQ forwarding) to at least > that > intermediate node. Or, just the fastest path if there are no > intermediate nodes Unfortunately, you have to assume that the attacker always knows what he is doing; we replace the notion "shortest" with "fastest". Although I can't find anything on the subject in the draft, it is well known among implementors of ad hoc routing protocols that immediate rebroadcast of flooded packets (e.g., route requests) is a bad idea: the synchronized broadcasts from multiple nodes cause extremely high contention, and (especially in simulations) lots of collisions. The solution for this problem is for each node to choose a small random backoff timer to better distribute the rebroadcasts. The consequence of this is that a route request travels slower through the MANET than regular unicast traffic. So if my attackers have a clue, they will maintain an active route between them to support the packet tunnel. This tunnel will deliver the route request from the source's tail to the destination's tail slightly before the route request flood reaches the destination's region of the MANET, and the first route request the destination receives will be through the "magic" link. The attackers can coordinate to make sure that they are on or near the shortest path between the source and destination, so this attack should be quite effective in denying communication betweem source and dest. The attack is assisted by expanding ring search (Section 6.4 in draft 10), since the attackers can probably tail the source and destination fairly closely. In this case, the attackers need only be "close" to the fastest path. If the attackers have more resources at their disposal, they can improve upon this margin. The attackers can purchase better radios than what is commonly used in the MANET, so that they actually DO have the fastest, shortest link across the MANET. AODV/DSR/whatever will then choose the path through the attackers as the shortest path. The gist of this argument is that simply authenticating the RREQ/RREPs is not sufficent to preserve availability of communication between source and destination, but only to verify that a route exists. > (And in SAODV you can tell intermediate nodes not to respond RREQs if you > want more security by sacrificing performance in route discovery. > That is by using Single Signature Extensions (SSE) instead of Double > Signature > Extensions (DSE)). > > So actually with the increase level of security provide by SAODV when > we don't allow intermediate nodes to reply (SSE); the attakers should > be in > the best path (acording to AODV way of selecting the path) to succeed > to make the system > believe that they are in the best path ;) So they are achieving nothing. > > And even in Double Signature Extensions, the attackers should manage > to be the fast ones to arrive to one of the intermediate nodes to > succeed. Exactly. It is only necessary that the attackers be on the fastest path, and they can subvert traffic. > > [snip] > >>> >>> >>> P.D.: Another way to do the attack is that no matter how close they >>> are to the path, >>> but be one hop away from src & dst and have a whole path of bad guy >>> no matter how long it is. (but then you need more bad boys than hops >>> has the optimal path and being just one hop away form src & dst) >>> So I thing bad guys will have a hard time doing this (now: imagine >>> all nodes >>> moving). >>> >> Or, have one bad guy next to the source, and one next to the >> destination. The two bad guys collude by tunneling route >> requests/route replies between src and dst to make it appear that the >> bad guys know a three-hop route between them. Only requires two bad >> guys to divert traffic. >> > > > -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@ns.ietf.org Mon Apr 29 19:57:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23760 for ; Mon, 29 Apr 2002 19:57:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA03742 for manet-archive@odin.ietf.org; Mon, 29 Apr 2002 19:57:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29277; Mon, 29 Apr 2002 19:09:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14045 for ; Fri, 19 Apr 2002 18:27:04 -0400 (EDT) Received: from c000.snv.cp.net (h007.c000.snv.cp.net [209.228.32.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12041 for ; Fri, 19 Apr 2002 18:26:55 -0400 (EDT) Received: (cpmta 10526 invoked from network); 19 Apr 2002 15:26:27 -0700 Received: from 12.221.64.123 (HELO Carter.net) by smtp.carter.net (209.228.32.71) with SMTP; 19 Apr 2002 15:26:27 -0700 X-Sent: 19 Apr 2002 22:26:27 GMT Message-ID: <3CC09928.5030206@Carter.net> Date: Fri, 19 Apr 2002 17:24:40 -0500 From: Casey Carter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manel Guerrero Zapata CC: ext Claude Castelluccia , manet@ietf.org, Seung Yi Subject: Re: [manet] Security Considerations of AODV References: <029f01c1e6eb$47269b20$1d1fc7c2@charmette.inrialpes.fr> <3CBEF145.8050706@nokia.com> <3CBEFF76.7030706@Carter.net> <3CC02F14.6010707@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Manel Guerrero Zapata wrote: > Hi Casey, > > That is a very good observation. Because if two nodes simulate that > they have a link, it is very complicated to detect that they actualy > don't > have a link (even with misbehavior detection schemes). > > I've been thinking about the whole problem for a while > and I realized about a funny thing: > > I usually thing about AODV route discovery assuming that it returns > the shortest path between originator and destination. > But that's not really true. Is it? > > It returns the shortest path among the paths through which the RREQ > traveled faster from the originator to each final or intermediate node > that has the route to the destination. > (Or just the fastest one, in the case no intermediate nodes know a route > to de destination). And that's the selected path in AODV. > > 8<------------------------------------------------- > 6.5. Processing and Forwarding Route Requests > > When a node receives a RREQ, it first checks to determine whether it > has received a RREQ with the same Originator IP Address and RREQ ID > within at least the last PATH_TRAVERSAL_TIME milliseconds. If such a > RREQ has been received, the node silently discards the newly received > RREQ. The rest of this subsection describes actions taken for RREQs > that are not discarded. > ------------------------------------------------->8 > > According to this ... > > A-----B------C------D > \ / > --E--F--G-- > > ... if A initiates a route discovery to D, > and C receives first the RREQ from G than from B the discovered > route will be this one: A E F G C D > and not: A B C D. > Because when C receives the RREQ from B, C "silently discards" the > packet. Yes, this is characteristic of on-demand routing protocols, not just AODV. > > > So for the attack you are suggesting to succeed, they would have to > manage that > the RREQ forwarded by the second bad guy (with the faked hop count) will > be the fastest one to reach one of those nodes who can issue a RREP back > (because they are intermediate nodes that have a route to the > destination, > or because they are the destination). > And that is not easy because that means that they actually have to be the > fastest path (acording to AODV policy of RREQ forwarding) to at least > that > intermediate node. Or, just the fastest path if there are no > intermediate nodes Unfortunately, you have to assume that the attacker always knows what he is doing; we replace the notion "shortest" with "fastest". Although I can't find anything on the subject in the draft, it is well known among implementors of ad hoc routing protocols that immediate rebroadcast of flooded packets (e.g., route requests) is a bad idea: the synchronized broadcasts from multiple nodes cause extremely high contention, and (especially in simulations) lots of collisions. The solution for this problem is for each node to choose a small random backoff timer to better distribute the rebroadcasts. The consequence of this is that a route request travels slower through the MANET than regular unicast traffic. So if my attackers have a clue, they will maintain an active route between them to support the packet tunnel. This tunnel will deliver the route request from the source's tail to the destination's tail slightly before the route request flood reaches the destination's region of the MANET, and the first route request the destination receives will be through the "magic" link. The attackers can coordinate to make sure that they are on or near the shortest path between the source and destination, so this attack should be quite effective in denying communication betweem source and dest. The attack is assisted by expanding ring search (Section 6.4 in draft 10), since the attackers can probably tail the source and destination fairly closely. In this case, the attackers need only be "close" to the fastest path. If the attackers have more resources at their disposal, they can improve upon this margin. The attackers can purchase better radios than what is commonly used in the MANET, so that they actually DO have the fastest, shortest link across the MANET. AODV/DSR/whatever will then choose the path through the attackers as the shortest path. The gist of this argument is that simply authenticating the RREQ/RREPs is not sufficent to preserve availability of communication between source and destination, but only to verify that a route exists. > (And in SAODV you can tell intermediate nodes not to respond RREQs if you > want more security by sacrificing performance in route discovery. > That is by using Single Signature Extensions (SSE) instead of Double > Signature > Extensions (DSE)). > > So actually with the increase level of security provide by SAODV when > we don't allow intermediate nodes to reply (SSE); the attakers should > be in > the best path (acording to AODV way of selecting the path) to succeed > to make the system > believe that they are in the best path ;) So they are achieving nothing. > > And even in Double Signature Extensions, the attackers should manage > to be the fast ones to arrive to one of the intermediate nodes to > succeed. Exactly. It is only necessary that the attackers be on the fastest path, and they can subvert traffic. > > [snip] > >>> >>> >>> P.D.: Another way to do the attack is that no matter how close they >>> are to the path, >>> but be one hop away from src & dst and have a whole path of bad guy >>> no matter how long it is. (but then you need more bad boys than hops >>> has the optimal path and being just one hop away form src & dst) >>> So I thing bad guys will have a hard time doing this (now: imagine >>> all nodes >>> moving). >>> >> Or, have one bad guy next to the source, and one next to the >> destination. The two bad guys collude by tunneling route >> requests/route replies between src and dst to make it appear that the >> bad guys know a three-hop route between them. Only requires two bad >> guys to divert traffic. >> > > > -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 08:33:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16613 for ; Tue, 30 Apr 2002 08:33:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16910; Tue, 30 Apr 2002 07:48:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16868 for ; Tue, 30 Apr 2002 07:48:37 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14801 for ; Tue, 30 Apr 2002 07:48:34 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFF32; Tue, 30 Apr 2002 07:48:33 -0400 Message-ID: <031101c1f03c$f45af430$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "James Kempf" , "Scott Corson" , , "Dr. Chane L. Fullmer" Cc: "Carl Williams" , "Aaron Falk" References: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> <02cd01c1efb5$13356530$6200000a@meshnetworks.com> <023f01c1efca$f8bf3f80$7e6015ac@T23KEMPF> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Tue, 30 Apr 2002 07:48:32 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit James, I was unable to make that BOF. Did it happen? Is there a list? I was going to write up a draft and just throw it at the IESG to see if it sicks and where they stick it. My interests are WLAN/MANET primarily. I do not want to create anything to heavy, just something immediately useful facilitating QoS and security issues with ad hoc wireless devices. Is there a web page for the BOF? Thanks, Phil ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller" ; "Scott Corson" ; ; "Dr. Chane L. Fullmer" Cc: "Carl Williams" ; "Aaron Falk" Sent: Monday, April 29, 2002 6:12 PM Subject: Re: [manet] Link API was [ Link layer notification ] > Phil, > > I think these would be of potential interest to the L2 triggers BOF. > > jak > > ----- Original Message ----- > From: "Phil Neumiller" > To: "Scott Corson" ; ; "Dr. Chane L. > Fullmer" > Cc: "James Kempf" > Sent: Monday, April 29, 2002 12:35 PM > Subject: Re: [manet] Link API was [ Link layer notification ] > > > > Hi Scott, > > > > I have some drafty draft stuff too. Is anybody else interested in > this? I will start writing a draft > > since I have been "complaining" about this for years, so its time for > me to put up or shut up. :-) > > I will start the water boiling for the spaghetti and mail my own > drafty draft to folks that are > > interested. Also, if I missing some major body of work that has > happened on this matter in > > the IETF or elsewhere could somebody kindly point it out to me (its > pretty hard to keep up > > with so much stuff)? > > > > The most essential things to me seem to be: > > > > 1). A generic interrupting system, where L2 can "call" (or call back > / publish / tigger) something to > > the underbelly of IP and tell it something has happened. That > something could simply be > > a code with no qualification or a code with complete TLV > qualification, as long as the IP > > layers interpretation is consitent there is not a problem. > > > > This type of mechanism could be the basis for a generic L2 > signaling mechanism. It could also > > be the basis for passing link status up to (and even more > importantly through the IP layer > > as out of band data (OOBD)). Routing mechanisms residing above > or at the IP layer would > > very much like to use information passed from the link layer. > I suggest using the model view > > controller model for this. > > > > Subscriber ---> Publisher > > ^ ^ > > | | > > View --------> Model <---- Controller > > > > Where say a MANET routing protocol is a subcriber to certain > classes of L2 information such as > > pilot notification or received signal strentgth indication > RSSI. Some of these will be wireless > > specific, some optics specific etc, but either way they are > not tied to any particular L2. > > > > 2). Certain categories of these triggers are essential "base class" > triggers, i.e. get a hunk of > > signaling info (possibly in the form of TLV) up to IP > efficiently. The more L2 independent > > the better (please don't suggest ASN.1!). > > > > 3). It is necessary for IP to support a plethora of LLC/MAC(L2s) > simultaneously. Each of these > > L2s will have different behaviour classifications for TTL, > TOS fields etc. It will be important > > to abstract the behaviors across many different L2s so that > the particular L2 does not have > > to be identified, only its interaction pattern with IP. > > > > 4). One could also postulate multiple stacks on a host (IPv4 and > IPv6 at least) where it may be > > desirable for the L2 to send IPv4 packets one way and others > another way. Also, one could > > imagine running multiple stacks per virtual machine on some > hosts and having the L2 send > > the traffic to the properly bound host IP stack (IPsec with > multiple many hostile users comes > > to mind). > > > > Thanks, > > > > Phil > > > > > > ----- Original Message ----- > > From: "Scott Corson" > > To: "'Phil Neumiller'" ; > ; "Dr. Chane L. Fullmer" > > Sent: Monday, April 29, 2002 2:30 PM > > Subject: RE: [manet] Link API was [ Link layer notification ] > > > > > > > > > > > Yes, it would be very interesting to see. I am not so much > > > > interested in standardizing the > > > > LLC/MAC layer API for the use of IP, as I am standardizing > > > > the bottom half of IP looking > > > > in from an LLC/MAC perspective. > > > > > > Phil, > > > > > > I'll second that, and I can see you're interested in building > something > > > useful... ;-) > > > > > > I've got a drafty draft written along these lines in hopes of an > eventual L2 > > > triggers BOF...very drafty of course as I've zero time to put into > this. > > > Maybe we should each throw some pasta at the IESG wall and see if > anything > > > sticks. ;-) > > > > > > -Scott > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 08:33:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16630 for ; Tue, 30 Apr 2002 08:33:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20357 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 08:33:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16910; Tue, 30 Apr 2002 07:48:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16868 for ; Tue, 30 Apr 2002 07:48:37 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14801 for ; Tue, 30 Apr 2002 07:48:34 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFF32; Tue, 30 Apr 2002 07:48:33 -0400 Message-ID: <031101c1f03c$f45af430$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "James Kempf" , "Scott Corson" , , "Dr. Chane L. Fullmer" Cc: "Carl Williams" , "Aaron Falk" References: <8C92E23A3E87FB479988285F9E22BE4699472E@ftmail> <02cd01c1efb5$13356530$6200000a@meshnetworks.com> <023f01c1efca$f8bf3f80$7e6015ac@T23KEMPF> Subject: Re: [manet] Link API was [ Link layer notification ] Date: Tue, 30 Apr 2002 07:48:32 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit James, I was unable to make that BOF. Did it happen? Is there a list? I was going to write up a draft and just throw it at the IESG to see if it sicks and where they stick it. My interests are WLAN/MANET primarily. I do not want to create anything to heavy, just something immediately useful facilitating QoS and security issues with ad hoc wireless devices. Is there a web page for the BOF? Thanks, Phil ----- Original Message ----- From: "James Kempf" To: "Phil Neumiller" ; "Scott Corson" ; ; "Dr. Chane L. Fullmer" Cc: "Carl Williams" ; "Aaron Falk" Sent: Monday, April 29, 2002 6:12 PM Subject: Re: [manet] Link API was [ Link layer notification ] > Phil, > > I think these would be of potential interest to the L2 triggers BOF. > > jak > > ----- Original Message ----- > From: "Phil Neumiller" > To: "Scott Corson" ; ; "Dr. Chane L. > Fullmer" > Cc: "James Kempf" > Sent: Monday, April 29, 2002 12:35 PM > Subject: Re: [manet] Link API was [ Link layer notification ] > > > > Hi Scott, > > > > I have some drafty draft stuff too. Is anybody else interested in > this? I will start writing a draft > > since I have been "complaining" about this for years, so its time for > me to put up or shut up. :-) > > I will start the water boiling for the spaghetti and mail my own > drafty draft to folks that are > > interested. Also, if I missing some major body of work that has > happened on this matter in > > the IETF or elsewhere could somebody kindly point it out to me (its > pretty hard to keep up > > with so much stuff)? > > > > The most essential things to me seem to be: > > > > 1). A generic interrupting system, where L2 can "call" (or call back > / publish / tigger) something to > > the underbelly of IP and tell it something has happened. That > something could simply be > > a code with no qualification or a code with complete TLV > qualification, as long as the IP > > layers interpretation is consitent there is not a problem. > > > > This type of mechanism could be the basis for a generic L2 > signaling mechanism. It could also > > be the basis for passing link status up to (and even more > importantly through the IP layer > > as out of band data (OOBD)). Routing mechanisms residing above > or at the IP layer would > > very much like to use information passed from the link layer. > I suggest using the model view > > controller model for this. > > > > Subscriber ---> Publisher > > ^ ^ > > | | > > View --------> Model <---- Controller > > > > Where say a MANET routing protocol is a subcriber to certain > classes of L2 information such as > > pilot notification or received signal strentgth indication > RSSI. Some of these will be wireless > > specific, some optics specific etc, but either way they are > not tied to any particular L2. > > > > 2). Certain categories of these triggers are essential "base class" > triggers, i.e. get a hunk of > > signaling info (possibly in the form of TLV) up to IP > efficiently. The more L2 independent > > the better (please don't suggest ASN.1!). > > > > 3). It is necessary for IP to support a plethora of LLC/MAC(L2s) > simultaneously. Each of these > > L2s will have different behaviour classifications for TTL, > TOS fields etc. It will be important > > to abstract the behaviors across many different L2s so that > the particular L2 does not have > > to be identified, only its interaction pattern with IP. > > > > 4). One could also postulate multiple stacks on a host (IPv4 and > IPv6 at least) where it may be > > desirable for the L2 to send IPv4 packets one way and others > another way. Also, one could > > imagine running multiple stacks per virtual machine on some > hosts and having the L2 send > > the traffic to the properly bound host IP stack (IPsec with > multiple many hostile users comes > > to mind). > > > > Thanks, > > > > Phil > > > > > > ----- Original Message ----- > > From: "Scott Corson" > > To: "'Phil Neumiller'" ; > ; "Dr. Chane L. Fullmer" > > Sent: Monday, April 29, 2002 2:30 PM > > Subject: RE: [manet] Link API was [ Link layer notification ] > > > > > > > > > > > Yes, it would be very interesting to see. I am not so much > > > > interested in standardizing the > > > > LLC/MAC layer API for the use of IP, as I am standardizing > > > > the bottom half of IP looking > > > > in from an LLC/MAC perspective. > > > > > > Phil, > > > > > > I'll second that, and I can see you're interested in building > something > > > useful... ;-) > > > > > > I've got a drafty draft written along these lines in hopes of an > eventual L2 > > > triggers BOF...very drafty of course as I've zero time to put into > this. > > > Maybe we should each throw some pasta at the IESG wall and see if > anything > > > sticks. ;-) > > > > > > -Scott > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 09:13:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18916 for ; Tue, 30 Apr 2002 09:13:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20707; Tue, 30 Apr 2002 08:38:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20678 for ; Tue, 30 Apr 2002 08:37:59 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17399 for ; Tue, 30 Apr 2002 08:37:52 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFFPV; Tue, 30 Apr 2002 08:37:54 -0400 Message-ID: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: Date: Tue, 30 Apr 2002 08:37:52 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Standardizing IP's Under-specified Underbelly Draft Kickoff Party - Was Link API Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, OK, seems like there is some interest. Here is the list of interested folks I have so far. Have I missed anybody? Corson@flarion.com - Scott Corson Einar.Vollset@newcastle.ac.uk - Einar Vollset gerharz@cs.uni-bonn.de - Michael Gerharz budden@nps.navy.mil - Rex Buddenberg M.Sasuta@motorola.com - Mike Sasuta chane@cse.ucsc.edu - Dr. Chane Fullmer If anybody else is interested in working on the draft please let me know. If we come up with a draft fairly quickly it may be submitted into the L2 tiggers BOF I suppose depending on how/when that happens. Either way we can see what the IESG says when we submit it. I plan to send my first version of the drafty draft to the above folks in plain vanilla ASCII, i.e. no IETF formatting at first. Everybody can take a swipe at it and mail it back to me. Meanwhile... Here is a draft problem statement.... Please pile on. Problem Statement ============= Many years of development have gone into the TCP/IP protocol suite, primarily from a "top down" design perspective where layer upon layer have been built upon each other. Each layer functions as a client accessing the server layer below it. This model has served the global Internet extremely well for many hears. However, as software design methodologies have progressed so have software design patterns. The IP stack is highly standardized on its "top" side, but it is proprietary/hidden and somewhat of a black art on its bottom side. With the advent of ubiquitous wireless devices, it is extremely important to allow L2 devices to form a tight coupling with the IP (L3) layer. Wireless devices have links that can change state on the order of milliseconds and routing, QoS, and security decisions, if they are to be implemented at the IP layer, must interact quickly. Currently, there are no standard event notification methods or triggering mechanisms into the under-specified under-belly of the IP stack. Proposed Title: Steps Toward Standardizing IP's Underspecified Underbelly (I hate this title, but it gets the point across) Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 09:13:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18930 for ; Tue, 30 Apr 2002 09:13:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA22749 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 09:13:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20707; Tue, 30 Apr 2002 08:38:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20678 for ; Tue, 30 Apr 2002 08:37:59 -0400 (EDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17399 for ; Tue, 30 Apr 2002 08:37:52 -0400 (EDT) Received: from neumillersimul (neumiller-simul.meshnetworks.com [10.0.0.98]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHSYFFPV; Tue, 30 Apr 2002 08:37:54 -0400 Message-ID: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: Date: Tue, 30 Apr 2002 08:37:52 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Standardizing IP's Under-specified Underbelly Draft Kickoff Party - Was Link API Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, OK, seems like there is some interest. Here is the list of interested folks I have so far. Have I missed anybody? Corson@flarion.com - Scott Corson Einar.Vollset@newcastle.ac.uk - Einar Vollset gerharz@cs.uni-bonn.de - Michael Gerharz budden@nps.navy.mil - Rex Buddenberg M.Sasuta@motorola.com - Mike Sasuta chane@cse.ucsc.edu - Dr. Chane Fullmer If anybody else is interested in working on the draft please let me know. If we come up with a draft fairly quickly it may be submitted into the L2 tiggers BOF I suppose depending on how/when that happens. Either way we can see what the IESG says when we submit it. I plan to send my first version of the drafty draft to the above folks in plain vanilla ASCII, i.e. no IETF formatting at first. Everybody can take a swipe at it and mail it back to me. Meanwhile... Here is a draft problem statement.... Please pile on. Problem Statement ============= Many years of development have gone into the TCP/IP protocol suite, primarily from a "top down" design perspective where layer upon layer have been built upon each other. Each layer functions as a client accessing the server layer below it. This model has served the global Internet extremely well for many hears. However, as software design methodologies have progressed so have software design patterns. The IP stack is highly standardized on its "top" side, but it is proprietary/hidden and somewhat of a black art on its bottom side. With the advent of ubiquitous wireless devices, it is extremely important to allow L2 devices to form a tight coupling with the IP (L3) layer. Wireless devices have links that can change state on the order of milliseconds and routing, QoS, and security decisions, if they are to be implemented at the IP layer, must interact quickly. Currently, there are no standard event notification methods or triggering mechanisms into the under-specified under-belly of the IP stack. Proposed Title: Steps Toward Standardizing IP's Underspecified Underbelly (I hate this title, but it gets the point across) Thanks, Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 10:10:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21161 for ; Tue, 30 Apr 2002 10:10:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24331; Tue, 30 Apr 2002 09:38:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24300 for ; Tue, 30 Apr 2002 09:38:10 -0400 (EDT) Received: from ocean (earth.ise.eng.osaka-u.ac.jp [133.1.52.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19832 for ; Tue, 30 Apr 2002 09:38:06 -0400 (EDT) Received: (qmail 14286 invoked from network); 30 Apr 2002 22:29:41 +0900 Received: from localhost (HELO Ricky) (127.0.0.1) by localhost with SMTP; 30 Apr 2002 22:29:41 +0900 Message-ID: <000f01c1f04c$6cba1640$9b01a8c0@ise.eng.osakau.ac.jp> From: "wooighee" To: References: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> Date: Tue, 30 Apr 2002 22:39:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] AODV control packet length: 32 bits ? 32 bytes? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello, I have read the AODV internet draft version 10. In the draft, it is stated that the control packet length is 32. May I know whether it means 32 bits or 32 bytes ? I am still new in ad-hoc networking research. Thank you for your kind advice. Regards, Ricky _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 10:10:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21172 for ; Tue, 30 Apr 2002 10:10:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26876 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 10:10:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24331; Tue, 30 Apr 2002 09:38:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24300 for ; Tue, 30 Apr 2002 09:38:10 -0400 (EDT) Received: from ocean (earth.ise.eng.osaka-u.ac.jp [133.1.52.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19832 for ; Tue, 30 Apr 2002 09:38:06 -0400 (EDT) Received: (qmail 14286 invoked from network); 30 Apr 2002 22:29:41 +0900 Received: from localhost (HELO Ricky) (127.0.0.1) by localhost with SMTP; 30 Apr 2002 22:29:41 +0900 Message-ID: <000f01c1f04c$6cba1640$9b01a8c0@ise.eng.osakau.ac.jp> From: "wooighee" To: References: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> Date: Tue, 30 Apr 2002 22:39:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] AODV control packet length: 32 bits ? 32 bytes? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello, I have read the AODV internet draft version 10. In the draft, it is stated that the control packet length is 32. May I know whether it means 32 bits or 32 bytes ? I am still new in ad-hoc networking research. Thank you for your kind advice. Regards, Ricky _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 10:36:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22633 for ; Tue, 30 Apr 2002 10:36:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26247; Tue, 30 Apr 2002 10:06:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26208 for ; Tue, 30 Apr 2002 10:06:30 -0400 (EDT) Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20870 for ; Tue, 30 Apr 2002 10:06:26 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by tc-mail.insa-lyon.fr (Postfix) with ESMTP id 9C00B139F8; Tue, 30 Apr 2002 16:06:28 +0200 (CEST) Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151) id 190F9139F6; Tue, 30 Apr 2002 16:06:27 +0200 (CEST) To: Phil Neumiller Subject: Re: [manet] Standardizing IP's Under-specified Underbelly Draft Kickoff Party - Was Link API Message-ID: <1020175587.3ccea4e3e4805@tc-mail.insa-lyon.fr> Date: Tue, 30 Apr 2002 16:06:27 +0200 (CEST) From: Guillaume Chelius Cc: manet@ietf.org References: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> In-Reply-To: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Virus-Scanned: by AMaViS snapshot-20010714 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit ----------------- Guillaume Chelius PhD student Ares Team, Inria, Citi Insa-Lyon Tel: (+33) 472 436 421 Email: gchelius@telecom.insa-lyon.fr Quoting Phil Neumiller : > Hi, > > OK, seems like there is some interest. Here is the list of interested > folks I have so far. > Have I missed anybody? > > Corson@flarion.com - Scott Corson > Einar.Vollset@newcastle.ac.uk - Einar Vollset > gerharz@cs.uni-bonn.de - Michael Gerharz > budden@nps.navy.mil - Rex Buddenberg > M.Sasuta@motorola.com - Mike Sasuta > chane@cse.ucsc.edu - Dr. Chane Fullmer > > If anybody else is interested in working on the draft please let me > know. If we come up with > a draft fairly quickly it may be submitted into the L2 tiggers BOF I > suppose depending on > how/when that happens. Either way we can see what the IESG says when we > submit it. > > I plan to send my first version of the drafty draft to the above folks > in plain vanilla ASCII, > i.e. no IETF formatting at first. Everybody can take a swipe at it and > mail it back to me. > > Meanwhile... Here is a draft problem statement.... Please pile on. > > Problem Statement > ============= > Many years of development have gone into the TCP/IP protocol suite, > primarily from a "top > down" design perspective where layer upon layer have been built upon > each other. Each > layer functions as a client accessing the server layer below it. This > model has served the global > Internet extremely well for many hears. However, as software design > methodologies have > progressed so have software design patterns. The IP stack is highly > standardized on > its "top" side, but it is proprietary/hidden and somewhat of a black art > on its bottom side. > > With the advent of ubiquitous wireless devices, it is extremely > important to allow L2 devices > to form a tight coupling with the IP (L3) layer. Wireless devices have > links that can change > state on the order of milliseconds and routing, QoS, and security > decisions, if they are to be > implemented at the IP layer, must interact quickly. Currently, there > are no standard event > notification methods or triggering mechanisms into the under-specified > under-belly of the IP > stack. > > Proposed Title: Steps Toward Standardizing IP's Underspecified > Underbelly > (I hate this title, but it gets the point across) > > Thanks, > > Phil > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 10:36:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22645 for ; Tue, 30 Apr 2002 10:36:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26627; Tue, 30 Apr 2002 10:09:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26599 for ; Tue, 30 Apr 2002 10:09:11 -0400 (EDT) Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21068 for ; Tue, 30 Apr 2002 10:09:07 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by tc-mail.insa-lyon.fr (Postfix) with ESMTP id 84D7D13A1D; Tue, 30 Apr 2002 16:09:10 +0200 (CEST) Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151) id 09A99139F6; Tue, 30 Apr 2002 16:09:10 +0200 (CEST) To: Phil Neumiller Subject: Re: [manet] Standardizing IP's Under-specified Underbelly Draft Kickoff Party - Was Link API Message-ID: <1020175749.3ccea58602a83@tc-mail.insa-lyon.fr> Date: Tue, 30 Apr 2002 16:09:10 +0200 (CEST) From: Guillaume Chelius Cc: manet@ietf.org References: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> In-Reply-To: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Virus-Scanned: by AMaViS snapshot-20010714 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello, Sorry for my last mail, a poor manipulation error. I'm also interested in working for this draft, if you accept my participation. Thanks, Guillaume Chelius. Quoting Phil Neumiller : > Hi, > > OK, seems like there is some interest. Here is the list of interested > folks I have so far. > Have I missed anybody? > > Corson@flarion.com - Scott Corson > Einar.Vollset@newcastle.ac.uk - Einar Vollset > gerharz@cs.uni-bonn.de - Michael Gerharz > budden@nps.navy.mil - Rex Buddenberg > M.Sasuta@motorola.com - Mike Sasuta > chane@cse.ucsc.edu - Dr. Chane Fullmer > > If anybody else is interested in working on the draft please let me > know. If we come up with > a draft fairly quickly it may be submitted into the L2 tiggers BOF I > suppose depending on > how/when that happens. Either way we can see what the IESG says when we > submit it. ----------------- Guillaume Chelius PhD student Ares Team, Inria, Citi Insa-Lyon Tel: (+33) 472 436 421 Email: gchelius@telecom.insa-lyon.fr _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 10:36:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22659 for ; Tue, 30 Apr 2002 10:36:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29132 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 10:36:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26627; Tue, 30 Apr 2002 10:09:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26599 for ; Tue, 30 Apr 2002 10:09:11 -0400 (EDT) Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21068 for ; Tue, 30 Apr 2002 10:09:07 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by tc-mail.insa-lyon.fr (Postfix) with ESMTP id 84D7D13A1D; Tue, 30 Apr 2002 16:09:10 +0200 (CEST) Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151) id 09A99139F6; Tue, 30 Apr 2002 16:09:10 +0200 (CEST) To: Phil Neumiller Subject: Re: [manet] Standardizing IP's Under-specified Underbelly Draft Kickoff Party - Was Link API Message-ID: <1020175749.3ccea58602a83@tc-mail.insa-lyon.fr> Date: Tue, 30 Apr 2002 16:09:10 +0200 (CEST) From: Guillaume Chelius Cc: manet@ietf.org References: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> In-Reply-To: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Virus-Scanned: by AMaViS snapshot-20010714 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit Hello, Sorry for my last mail, a poor manipulation error. I'm also interested in working for this draft, if you accept my participation. Thanks, Guillaume Chelius. Quoting Phil Neumiller : > Hi, > > OK, seems like there is some interest. Here is the list of interested > folks I have so far. > Have I missed anybody? > > Corson@flarion.com - Scott Corson > Einar.Vollset@newcastle.ac.uk - Einar Vollset > gerharz@cs.uni-bonn.de - Michael Gerharz > budden@nps.navy.mil - Rex Buddenberg > M.Sasuta@motorola.com - Mike Sasuta > chane@cse.ucsc.edu - Dr. Chane Fullmer > > If anybody else is interested in working on the draft please let me > know. If we come up with > a draft fairly quickly it may be submitted into the L2 tiggers BOF I > suppose depending on > how/when that happens. Either way we can see what the IESG says when we > submit it. ----------------- Guillaume Chelius PhD student Ares Team, Inria, Citi Insa-Lyon Tel: (+33) 472 436 421 Email: gchelius@telecom.insa-lyon.fr _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 10:37:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22721 for ; Tue, 30 Apr 2002 10:37:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26073; Tue, 30 Apr 2002 10:04:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26044 for ; Tue, 30 Apr 2002 10:04:42 -0400 (EDT) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20787 for ; Tue, 30 Apr 2002 10:04:38 -0400 (EDT) Received: from gwialo (camelot.antd.nist.gov [129.6.50.51]) by email.nist.gov (8.12.2/8.12.2) with SMTP id g3UE4evU006884; Tue, 30 Apr 2002 10:04:40 -0400 (EDT) From: "Luke Klein-Berndt" To: "wooighee" , Subject: RE: [manet] AODV control packet length: 32 bits ? 32 bytes? Date: Tue, 30 Apr 2002 10:04:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000f01c1f04c$6cba1640$9b01a8c0@ise.eng.osakau.ac.jp> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, That is probably 32 bytes - RREQ are 24 bytes RREP are 20 bytes and RERR can vary in size. IP addresses are usaully 32 bits long (in IPv4). Sequence numbers in AODV are also 32 bits. 32 bits translates into 4 bytes because there are 8 bits in a byte. Here is an article which goes a little more in depth: http://www.loadstar.com/articles/bytes.htm . Hope this helps, Luke Klein-Berndt > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of > wooighee > Sent: Tuesday, April 30, 2002 9:39 AM > To: manet@ietf.org > Subject: [manet] AODV control packet length: 32 bits ? 32 bytes? > > > Hello, > > I have read the AODV internet draft version 10. > > In the draft, it is stated that the control packet > length is 32. May I know whether it means 32 bits or > 32 bytes ? > > I am still new in ad-hoc networking research. > > Thank you for your kind advice. > > Regards, > Ricky > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 10:37:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22730 for ; Tue, 30 Apr 2002 10:37:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29179 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 10:37:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26073; Tue, 30 Apr 2002 10:04:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26044 for ; Tue, 30 Apr 2002 10:04:42 -0400 (EDT) Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20787 for ; Tue, 30 Apr 2002 10:04:38 -0400 (EDT) Received: from gwialo (camelot.antd.nist.gov [129.6.50.51]) by email.nist.gov (8.12.2/8.12.2) with SMTP id g3UE4evU006884; Tue, 30 Apr 2002 10:04:40 -0400 (EDT) From: "Luke Klein-Berndt" To: "wooighee" , Subject: RE: [manet] AODV control packet length: 32 bits ? 32 bytes? Date: Tue, 30 Apr 2002 10:04:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000f01c1f04c$6cba1640$9b01a8c0@ise.eng.osakau.ac.jp> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, That is probably 32 bytes - RREQ are 24 bytes RREP are 20 bytes and RERR can vary in size. IP addresses are usaully 32 bits long (in IPv4). Sequence numbers in AODV are also 32 bits. 32 bits translates into 4 bytes because there are 8 bits in a byte. Here is an article which goes a little more in depth: http://www.loadstar.com/articles/bytes.htm . Hope this helps, Luke Klein-Berndt > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of > wooighee > Sent: Tuesday, April 30, 2002 9:39 AM > To: manet@ietf.org > Subject: [manet] AODV control packet length: 32 bits ? 32 bytes? > > > Hello, > > I have read the AODV internet draft version 10. > > In the draft, it is stated that the control packet > length is 32. May I know whether it means 32 bits or > 32 bytes ? > > I am still new in ad-hoc networking research. > > Thank you for your kind advice. > > Regards, > Ricky > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 11:27:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22647 for ; Tue, 30 Apr 2002 10:36:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29118 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 10:36:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26247; Tue, 30 Apr 2002 10:06:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26208 for ; Tue, 30 Apr 2002 10:06:30 -0400 (EDT) Received: from tc-mail.insa-lyon.fr (tc-mail.insa-lyon.fr [134.214.202.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20870 for ; Tue, 30 Apr 2002 10:06:26 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by tc-mail.insa-lyon.fr (Postfix) with ESMTP id 9C00B139F8; Tue, 30 Apr 2002 16:06:28 +0200 (CEST) Received: by tc-mail.insa-lyon.fr (Postfix, from userid 1151) id 190F9139F6; Tue, 30 Apr 2002 16:06:27 +0200 (CEST) To: Phil Neumiller Subject: Re: [manet] Standardizing IP's Under-specified Underbelly Draft Kickoff Party - Was Link API Message-ID: <1020175587.3ccea4e3e4805@tc-mail.insa-lyon.fr> Date: Tue, 30 Apr 2002 16:06:27 +0200 (CEST) From: Guillaume Chelius Cc: manet@ietf.org References: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> In-Reply-To: <039e01c1f043$d8308ca0$6200000a@meshnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.8 X-Virus-Scanned: by AMaViS snapshot-20010714 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 8bit ----------------- Guillaume Chelius PhD student Ares Team, Inria, Citi Insa-Lyon Tel: (+33) 472 436 421 Email: gchelius@telecom.insa-lyon.fr Quoting Phil Neumiller : > Hi, > > OK, seems like there is some interest. Here is the list of interested > folks I have so far. > Have I missed anybody? > > Corson@flarion.com - Scott Corson > Einar.Vollset@newcastle.ac.uk - Einar Vollset > gerharz@cs.uni-bonn.de - Michael Gerharz > budden@nps.navy.mil - Rex Buddenberg > M.Sasuta@motorola.com - Mike Sasuta > chane@cse.ucsc.edu - Dr. Chane Fullmer > > If anybody else is interested in working on the draft please let me > know. If we come up with > a draft fairly quickly it may be submitted into the L2 tiggers BOF I > suppose depending on > how/when that happens. Either way we can see what the IESG says when we > submit it. > > I plan to send my first version of the drafty draft to the above folks > in plain vanilla ASCII, > i.e. no IETF formatting at first. Everybody can take a swipe at it and > mail it back to me. > > Meanwhile... Here is a draft problem statement.... Please pile on. > > Problem Statement > ============= > Many years of development have gone into the TCP/IP protocol suite, > primarily from a "top > down" design perspective where layer upon layer have been built upon > each other. Each > layer functions as a client accessing the server layer below it. This > model has served the global > Internet extremely well for many hears. However, as software design > methodologies have > progressed so have software design patterns. The IP stack is highly > standardized on > its "top" side, but it is proprietary/hidden and somewhat of a black art > on its bottom side. > > With the advent of ubiquitous wireless devices, it is extremely > important to allow L2 devices > to form a tight coupling with the IP (L3) layer. Wireless devices have > links that can change > state on the order of milliseconds and routing, QoS, and security > decisions, if they are to be > implemented at the IP layer, must interact quickly. Currently, there > are no standard event > notification methods or triggering mechanisms into the under-specified > under-belly of the IP > stack. > > Proposed Title: Steps Toward Standardizing IP's Underspecified > Underbelly > (I hate this title, but it gets the point across) > > Thanks, > > Phil > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 13:52:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01109 for ; Tue, 30 Apr 2002 13:52:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10034; Tue, 30 Apr 2002 13:25:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09974 for ; Tue, 30 Apr 2002 13:25:35 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29751 for ; Tue, 30 Apr 2002 13:25:32 -0400 (EDT) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g3UHPSO27076; Tue, 30 Apr 2002 10:25:28 -0700 (PDT) Message-Id: <200204301725.g3UHPSO27076@letters.cs.ucsb.edu> Date: Tue, 30 Apr 2002 10:25:28 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: manet@ietf.org, aodvimpl-public@lists.sourceforge.net Cc: eroyer@cs.ucsb.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zb2+dsTWrnImMLXuKsjSDw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [manet] Reminder: AODV Next Generation (AODVng) 2002 Workshop Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Reminder: The submissions for the AODV Next Generation (AODVng) 2002 Workshop are due *today* (April 30th)! ***************************************************************** We are pleased to announce the AODV Next Generation (AODVng) 2002 Workshop, the first workshop on the Ad hoc On-Demand Distance Vector (AODV) routing protocol. AODVng 2002, held in conjunction with the Third ACM International Symposium on Mobile Ad Hoc Networking and Computing (Mobihoc) 2002, will bring together researchers and engineers who have experience working with AODV, to discuss future directions and enhancements for AODV. The workshop will include presentations by participants, as well as a discussion session on suggested extensions to the basic AODV protocol. The setting of the workshop is informal, and will take place at Ecole Polytechnique Federale de Lausanne (EPFL), the same site as Mobihoc. Date: June 8, 2002 Location: Lausanne, Switzerland We invite one-page abstracts describing recent work related to AODV. If your abstract is accepted, you will be asked to give a presentation on this work at the workshop. There will be no formal proceedings from the workshop, although during the workshop we may decide on some avenue for a publication describing the event. Participation in the workshop is by invitation only. Because of the limited time available, there are currently no plans for interoperability testing at this event. If there is interest, we can use part of the workshop time to plan the next such event. Also, informal interoperability testing may be possible. Topics of interest include, but are not limited to: - Quality of Service - Multi-path routing - Security - Uni-directional links - Implementation and test-bed experience - Energy usage - Scalability - Interoperability testing and future events - Freely available implementations and simulations - Location-aware routing - Scatternet formation - Limiting rebroadcasts for flooding (broadcast backbones) - Parameter selection for specific mobility and traffic scenarios - Service discovery Note that the topic must be related to the AODV protocol, and geared towards future improvement. Submission Instructions: All submissions will be handled electronically and must be in ASCII text, PDF or PostScript format. Submissions must be in the form of an abstract and must not exceed *500 words*. Because there will not be any formal proceedings, the work may be previously published elsewhere. The proposal may also be a work-in-progress, although meaningful results must be included. Please send submissions to Charles E. Perkins at charliep@iprg.nokia.com. Submission Deadline: *April 30, 2002* Notification of Acceptance: May 10, 2002 For more information, visit the AODVng Workshop homepage at http://moment.cs.ucsb.edu/AODV/workshop.html, or send email to Charles Perkins (charliep@iprg.nokia.com) or Elizabeth Belding-Royer (ebelding@cs.ucsb.edu) for any questions or more information. Organizers: Charles E. Perkins, Nokia Research Center Elizabeth M. Belding-Royer, UC Santa Barbara _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 13:52:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01127 for ; Tue, 30 Apr 2002 13:52:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12487 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 13:52:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10034; Tue, 30 Apr 2002 13:25:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09974 for ; Tue, 30 Apr 2002 13:25:35 -0400 (EDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29751 for ; Tue, 30 Apr 2002 13:25:32 -0400 (EDT) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with SMTP id g3UHPSO27076; Tue, 30 Apr 2002 10:25:28 -0700 (PDT) Message-Id: <200204301725.g3UHPSO27076@letters.cs.ucsb.edu> Date: Tue, 30 Apr 2002 10:25:28 -0700 (PDT) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: manet@ietf.org, aodvimpl-public@lists.sourceforge.net Cc: eroyer@cs.ucsb.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Zb2+dsTWrnImMLXuKsjSDw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [manet] Reminder: AODV Next Generation (AODVng) 2002 Workshop Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Reminder: The submissions for the AODV Next Generation (AODVng) 2002 Workshop are due *today* (April 30th)! ***************************************************************** We are pleased to announce the AODV Next Generation (AODVng) 2002 Workshop, the first workshop on the Ad hoc On-Demand Distance Vector (AODV) routing protocol. AODVng 2002, held in conjunction with the Third ACM International Symposium on Mobile Ad Hoc Networking and Computing (Mobihoc) 2002, will bring together researchers and engineers who have experience working with AODV, to discuss future directions and enhancements for AODV. The workshop will include presentations by participants, as well as a discussion session on suggested extensions to the basic AODV protocol. The setting of the workshop is informal, and will take place at Ecole Polytechnique Federale de Lausanne (EPFL), the same site as Mobihoc. Date: June 8, 2002 Location: Lausanne, Switzerland We invite one-page abstracts describing recent work related to AODV. If your abstract is accepted, you will be asked to give a presentation on this work at the workshop. There will be no formal proceedings from the workshop, although during the workshop we may decide on some avenue for a publication describing the event. Participation in the workshop is by invitation only. Because of the limited time available, there are currently no plans for interoperability testing at this event. If there is interest, we can use part of the workshop time to plan the next such event. Also, informal interoperability testing may be possible. Topics of interest include, but are not limited to: - Quality of Service - Multi-path routing - Security - Uni-directional links - Implementation and test-bed experience - Energy usage - Scalability - Interoperability testing and future events - Freely available implementations and simulations - Location-aware routing - Scatternet formation - Limiting rebroadcasts for flooding (broadcast backbones) - Parameter selection for specific mobility and traffic scenarios - Service discovery Note that the topic must be related to the AODV protocol, and geared towards future improvement. Submission Instructions: All submissions will be handled electronically and must be in ASCII text, PDF or PostScript format. Submissions must be in the form of an abstract and must not exceed *500 words*. Because there will not be any formal proceedings, the work may be previously published elsewhere. The proposal may also be a work-in-progress, although meaningful results must be included. Please send submissions to Charles E. Perkins at charliep@iprg.nokia.com. Submission Deadline: *April 30, 2002* Notification of Acceptance: May 10, 2002 For more information, visit the AODVng Workshop homepage at http://moment.cs.ucsb.edu/AODV/workshop.html, or send email to Charles Perkins (charliep@iprg.nokia.com) or Elizabeth Belding-Royer (ebelding@cs.ucsb.edu) for any questions or more information. Organizers: Charles E. Perkins, Nokia Research Center Elizabeth M. Belding-Royer, UC Santa Barbara _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 14:38:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03501 for ; Tue, 30 Apr 2002 14:38:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14456; Tue, 30 Apr 2002 14:10:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14425 for ; Tue, 30 Apr 2002 14:10:55 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02067 for ; Tue, 30 Apr 2002 14:10:52 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA22768; Tue, 30 Apr 2002 11:04:07 -0700 (PDT) Message-Id: <200204301804.LAA22768@pit.erg.sri.com> To: T.Clausen@computer.org, manet@ietf.org cc: ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com In-reply-to: Your message of "Thu, 29 Nov 2001 18:33:14 +0100." Date: Tue, 30 Apr 2002 11:04:07 -0700 Subject: [manet] ns-2 code for OLSR Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At the last IETF meeting in Minneapolis, Joe Macker mentioned the availability of ns-2 code for OLSR that has newer features than the code available from INRIA's web site. Does anyone know where I can find this code? Also, I would like to know when the new ns-2 code from INRIA will be available (see the message from Thomas below). Richard > Richard, > > On Wed, 31 Oct 2001 ogier@erg.sri.com wrote: > > > > > > > Can we also obtain your ns-2 code for OLSR? > > ns2-code for OLSR is available in an "old" version, compliant with a now > expired and outdated draft. We're working on new code, which should be > both usefull for ns2 and for running on a "real" network - and, of > course, be compliant with the latest draft. We anticipate that work and > testing of this to be completed in january. If you wish, I will be happy > to let you know when this happens, as well as provide you with a copy? > > > > ------------------------------------------- > Thomas Heide Clausen > Civilingeniør i Datateknik (cand.polyt) > M.Sc in Computer Engineering > > E-Mail: T.Clausen@computer.org > WWW: http://www.cs.auc.dk/~voop > ------------------------------------------- > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 14:39:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03522 for ; Tue, 30 Apr 2002 14:39:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16903 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 14:38:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14456; Tue, 30 Apr 2002 14:10:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14425 for ; Tue, 30 Apr 2002 14:10:55 -0400 (EDT) Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02067 for ; Tue, 30 Apr 2002 14:10:52 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id LAA22768; Tue, 30 Apr 2002 11:04:07 -0700 (PDT) Message-Id: <200204301804.LAA22768@pit.erg.sri.com> To: T.Clausen@computer.org, manet@ietf.org cc: ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com In-reply-to: Your message of "Thu, 29 Nov 2001 18:33:14 +0100." Date: Tue, 30 Apr 2002 11:04:07 -0700 Subject: [manet] ns-2 code for OLSR Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org At the last IETF meeting in Minneapolis, Joe Macker mentioned the availability of ns-2 code for OLSR that has newer features than the code available from INRIA's web site. Does anyone know where I can find this code? Also, I would like to know when the new ns-2 code from INRIA will be available (see the message from Thomas below). Richard > Richard, > > On Wed, 31 Oct 2001 ogier@erg.sri.com wrote: > > > > > > > Can we also obtain your ns-2 code for OLSR? > > ns2-code for OLSR is available in an "old" version, compliant with a now > expired and outdated draft. We're working on new code, which should be > both usefull for ns2 and for running on a "real" network - and, of > course, be compliant with the latest draft. We anticipate that work and > testing of this to be completed in january. If you wish, I will be happy > to let you know when this happens, as well as provide you with a copy? > > > > ------------------------------------------- > Thomas Heide Clausen > Civilingeniør i Datateknik (cand.polyt) > M.Sc in Computer Engineering > > E-Mail: T.Clausen@computer.org > WWW: http://www.cs.auc.dk/~voop > ------------------------------------------- > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 18:41:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11424 for ; Tue, 30 Apr 2002 18:41:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29283; Tue, 30 Apr 2002 18:02:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29255 for ; Tue, 30 Apr 2002 18:02:44 -0400 (EDT) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10454 for ; Tue, 30 Apr 2002 18:02:39 -0400 (EDT) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with SMTP id g3UM2gs29439; Tue, 30 Apr 2002 18:02:42 -0400 From: "Andrew T. Campbell" To: "'Harpreet Arora'" , "'manet'" Cc: "Andrew Campbell \(E-mail\)" Subject: RE: [manet] QoS issues in MANETs Date: Tue, 30 Apr 2002 17:59:37 -0400 Message-ID: <01e501c1f092$525fdc30$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CD77449@webmail.drexel.edu> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Harpreet: My research group looked at stateful (INSIGNIA Project) and stateless (SWAN Project) approaches to building QOS into MANETS. SWAN (for stateless wireless ad hoc networks) is a diffserv-like approach and may answer some of your good questions. SWAN is rather simple but effective. It uses rate control for UDP and TCP best-effort traffic, and sender-based admission control for UDP real-time traffic. SWAN uses ECN to dynamically regulate admitted real-time traffic in the face of network dynamics brought on by mobility and/or traffic overload conditions. SWAN does not require the support of a QOS-capable MAC. Rather, soft real-time services are built using existing best effort wireless MAC technology. For details of the mode take a look at our INFOCOM 2002 paper. It includes simulation, analysis, and results from an experimental wireless testbed that shows real-time applications experience low and stable delays under various multi-hop, traffic and mobility conditions: Gahng-Seop Ahn, Andrew T. Campbell, Andras Veres and Li-Hsiang Sun, "SWAN: Service Differentiation in Stateless Wireless Ad Hoc Networks", Proc. IEEE INFOCOM'2002, New York, New York, 2002 (to be published). You can get the paper from: http://comet.columbia.edu/swan/ The SWAN ns simulation and testbed code will be made available in June 2002. QOS is not on the table in the MANET WG so this is more academic right now. Best, --- Andrew http://comet.columbia.edu/~campbell > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of > Harpreet Arora > Sent: Friday, April 26, 2002 2:50 PM > To: manet > Subject: [manet] QoS issues in MANETs > Importance: High > > > Hi, > > I am interested in finding the feasibility of a > differentiated services model > for MANETs. WHile thinking about the implementation of > diffserv in MANETs, I > came across the follwing problem : diffserv aims to push the > complexity to the > edge of the network, by dividing the network into edge and > core nodes. How can > we do this in a MANET? Specifically, how can we differentiate > the network of > nodes into edge and core nodes? Since the nodes are mobile, I > feel that every > node should have the capability of acting as an edge node, > which would mark, > meter and police the packets, and also as a core node, which > would simply > forward the packets on the basis of the DSCP. The nodes can > assume either > functionality depending on the situation. But what node assumes what > functionality is the question. Any suggestions? > > Harpreet > Research Assistant > ECE Department, Drexel University > Philadelphia, PA-19104 > > ******************************************************************** > A dream is just a dream. A goal is a dream with a plan and a deadline. > > A candle brightens the world around it. Unfortunately, it > creates a shadow of its own. It still serves the purpose it > is meant for. > ********************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 18:41:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11435 for ; Tue, 30 Apr 2002 18:41:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01270 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 18:41:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29283; Tue, 30 Apr 2002 18:02:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29255 for ; Tue, 30 Apr 2002 18:02:44 -0400 (EDT) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10454 for ; Tue, 30 Apr 2002 18:02:39 -0400 (EDT) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with SMTP id g3UM2gs29439; Tue, 30 Apr 2002 18:02:42 -0400 From: "Andrew T. Campbell" To: "'Harpreet Arora'" , "'manet'" Cc: "Andrew Campbell \(E-mail\)" Subject: RE: [manet] QoS issues in MANETs Date: Tue, 30 Apr 2002 17:59:37 -0400 Message-ID: <01e501c1f092$525fdc30$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CD77449@webmail.drexel.edu> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hello Harpreet: My research group looked at stateful (INSIGNIA Project) and stateless (SWAN Project) approaches to building QOS into MANETS. SWAN (for stateless wireless ad hoc networks) is a diffserv-like approach and may answer some of your good questions. SWAN is rather simple but effective. It uses rate control for UDP and TCP best-effort traffic, and sender-based admission control for UDP real-time traffic. SWAN uses ECN to dynamically regulate admitted real-time traffic in the face of network dynamics brought on by mobility and/or traffic overload conditions. SWAN does not require the support of a QOS-capable MAC. Rather, soft real-time services are built using existing best effort wireless MAC technology. For details of the mode take a look at our INFOCOM 2002 paper. It includes simulation, analysis, and results from an experimental wireless testbed that shows real-time applications experience low and stable delays under various multi-hop, traffic and mobility conditions: Gahng-Seop Ahn, Andrew T. Campbell, Andras Veres and Li-Hsiang Sun, "SWAN: Service Differentiation in Stateless Wireless Ad Hoc Networks", Proc. IEEE INFOCOM'2002, New York, New York, 2002 (to be published). You can get the paper from: http://comet.columbia.edu/swan/ The SWAN ns simulation and testbed code will be made available in June 2002. QOS is not on the table in the MANET WG so this is more academic right now. Best, --- Andrew http://comet.columbia.edu/~campbell > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of > Harpreet Arora > Sent: Friday, April 26, 2002 2:50 PM > To: manet > Subject: [manet] QoS issues in MANETs > Importance: High > > > Hi, > > I am interested in finding the feasibility of a > differentiated services model > for MANETs. WHile thinking about the implementation of > diffserv in MANETs, I > came across the follwing problem : diffserv aims to push the > complexity to the > edge of the network, by dividing the network into edge and > core nodes. How can > we do this in a MANET? Specifically, how can we differentiate > the network of > nodes into edge and core nodes? Since the nodes are mobile, I > feel that every > node should have the capability of acting as an edge node, > which would mark, > meter and police the packets, and also as a core node, which > would simply > forward the packets on the basis of the DSCP. The nodes can > assume either > functionality depending on the situation. But what node assumes what > functionality is the question. Any suggestions? > > Harpreet > Research Assistant > ECE Department, Drexel University > Philadelphia, PA-19104 > > ******************************************************************** > A dream is just a dream. A goal is a dream with a plan and a deadline. > > A candle brightens the world around it. Unfortunately, it > creates a shadow of its own. It still serves the purpose it > is meant for. > ********************************************************************** > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 22:00:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15657 for ; Tue, 30 Apr 2002 22:00:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09708; Tue, 30 Apr 2002 21:31:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09655 for ; Tue, 30 Apr 2002 21:31:10 -0400 (EDT) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14319 for ; Tue, 30 Apr 2002 21:31:06 -0400 (EDT) Received: from comet.columbia.edu (bongo.comet.columbia.edu [128.59.64.210]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with ESMTP id g411V9s01584; Tue, 30 Apr 2002 21:31:09 -0400 Received: from localhost (sbl@localhost) by comet.columbia.edu (8.8.7/8.8.7/COMET) with SMTP id VAA26727; Tue, 30 Apr 2002 21:31:09 -0400 (EDT) X-Authentication-Warning: bongo.ctr.columbia.edu: sbl owned process doing -bs Date: Tue, 30 Apr 2002 21:30:07 -0400 (EDT) From: Seoung-Bum Lee To: Harpreet Arora cc: manet , sbl@comet.columbia.edu Subject: RE: [manet] QoS issues in MANETs In-Reply-To: <3CD98899@webmail.drexel.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Granted INSIGNIA is a stateful approach for per-flow QoS but the state explosion issue for wireless ad hoc networks is nowhere near as pressing as core Internet (considering the size of the network and the size of routing tables of MANET routing protocols). Therefore I do not think the issue of maintaining per-flow state in ad hoc networks is as critical as the Internet. Moreover, in practice, INSIGNIA admits and maintains finite number of 'high-priority' flows (best-effort flows are not maintained) through concept of soft-state. When a node carries too many high-priority flows (or states) and can not be handled, INSIGNIA simply ignores/discards additional high-priority flows (and those denied ones will be treated as best effort flows). So, our definition of 'resources' are not limited to 'bandwidth' but includes others like 'buffer-occupancy', 'computational-power' and etc., ... anything that throttles the end-to-end QoS and INSIGNIA operations. -Seoung-Bum Lee- On Sat, 27 Apr 2002, Harpreet Arora wrote: > Hi, > > The Insignia approach does seem to be a good approach for QoS in MANETs, but > it is based on per flow guarantees, not per class, and thus can have the same > problems associated with Intserv model like scalability and implementation > issues. Each flow reserves resources at every node it passes through. THe FQMM > simply suggests that the highest class gets per flow provisioning, while the > lower classes get per class provisioning, so in essence the model adds the > complexity of the two models. And it does not suggest any means of > implementing the model in MANETs. The basic issue still remains of which node > will mark the packets so that the subsequent nodes can process them > accrodingly. If the source node does that job, then there is a good chance > that the node can misbehave and use a DSCP corresponding to a high priority > PHB even when it does not need to. In that case, who does the policing to stop > the flow? > > thanks, > Harpreet > > > >===== Original Message From yasser.lotfy@lycos.com ===== > >Good answer, > >Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of > handling traffic between two nodes. The other model which provided some > enhancements to traditional DiffServ is the FQMM. > > > >Always try to distinguish signalling from the model. FQMM represent a model, > INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment > to RSVP. > > > >Ingress, and egress could be anynode. Ingress are always nodes initiating > traffic. Egress are those submitting traffic to different domain. > > > > > >Yasser > >Carleton University > > > >----------------------------------------------------------------- > >Hi Arora, > > > >Actually, diffserv pretty much acknowledges that every "core" node can just > >as easily also be an "edge" node, and may therefore have to worry about such > >complexities as access control from edge hosts. There is no attempt to > >prevent core nodes from being edge nodes. > > > >But diffserv does not get into any sort of signaling or access control > >mechanisms between diffserv nodes and edge user hosts. People have mentioned > >possible signaling mechanisms for use in diffserv nets, such as the RSVP > >PATH and RESV messages. But always, such discussions were cut short on the > >list, because they are not germaine to diffserv itself. > > > >What diffserv offers is really a set of per-hop behaviors that every > >diffserv node has to support as it routes diffserv-labeled packets. These > >PHBs, when aggregated across a diffserv routing domain, create so-called > >"per domain behaviors" for aggregated diffserv paths. That's it, pretty > >much. And the MIB/PIB needed for diffserv node management, of course. > > > >It seems difficult to be able to support diffserv routes with any sort of > >stability if the hops of any "aggregated path" come and go frequently, but I > >suppose this could make for an interesting research project! > > > >Bert > >albert.e.manfredi@boeing.com > > > > > >> -----Original Message----- > >> From: Harpreet Arora [mailto:ha33@drexel.edu] > >> Sent: Friday, April 26, 2002 2:50 PM > >> To: manet > >> Subject: [manet] QoS issues in MANETs > >> Importance: High > >> > >> > >> Hi, > >> > >> I am interested in finding the feasibility of a > >> differentiated services model > >> for MANETs. WHile thinking about the implementation of > >> diffserv in MANETs, I > >> came across the follwing problem : diffserv aims to push the > >> complexity to the > >> edge of the network, by dividing the network into edge and > >> core nodes. How can > >> we do this in a MANET? Specifically, how can we differentiate > >> the network of > >> nodes into edge and core nodes? Since the nodes are mobile, I > >> feel that every > >> node should have the capability of acting as an edge node, > >> which would mark, > >> meter and police the packets, and also as a core node, which > >> would simply > >> forward the packets on the basis of the DSCP. The nodes can > >> assume either > >> functionality depending on the situation. But what node assumes what > >> functionality is the question. Any suggestions? > >> > >> Harpreet > >> Research Assistant > >> ECE Department, Drexel University > >> Philadelphia, PA-19104 > >> > >> ******************************************************************** > >> A dream is just a dream. A goal is a dream with a plan and a deadline. > >> > >> A candle brightens the world around it. Unfortunately, it > >> creates a shadow of its own. It still serves the purpose it > >> is meant for. > >> ********************************************************************** > >> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www1.ietf.org/mailman/listinfo/manet > >> > > > > > > > > > >See Dave Matthews Band live or win a signed guitar > >http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/ > splash.asp > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > Best Regards, ----------------------------------------------------- Seoung-Bum Lee COMET Group, Columbia University e-mail : sbl@comet.columbia.edu http://www.comet.columbia.edu/~sbl * Push your limits! ----------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 22:00:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15672 for ; Tue, 30 Apr 2002 22:00:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA10943 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 22:01:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09708; Tue, 30 Apr 2002 21:31:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09655 for ; Tue, 30 Apr 2002 21:31:10 -0400 (EDT) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14319 for ; Tue, 30 Apr 2002 21:31:06 -0400 (EDT) Received: from comet.columbia.edu (bongo.comet.columbia.edu [128.59.64.210]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with ESMTP id g411V9s01584; Tue, 30 Apr 2002 21:31:09 -0400 Received: from localhost (sbl@localhost) by comet.columbia.edu (8.8.7/8.8.7/COMET) with SMTP id VAA26727; Tue, 30 Apr 2002 21:31:09 -0400 (EDT) X-Authentication-Warning: bongo.ctr.columbia.edu: sbl owned process doing -bs Date: Tue, 30 Apr 2002 21:30:07 -0400 (EDT) From: Seoung-Bum Lee To: Harpreet Arora cc: manet , sbl@comet.columbia.edu Subject: RE: [manet] QoS issues in MANETs In-Reply-To: <3CD98899@webmail.drexel.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Granted INSIGNIA is a stateful approach for per-flow QoS but the state explosion issue for wireless ad hoc networks is nowhere near as pressing as core Internet (considering the size of the network and the size of routing tables of MANET routing protocols). Therefore I do not think the issue of maintaining per-flow state in ad hoc networks is as critical as the Internet. Moreover, in practice, INSIGNIA admits and maintains finite number of 'high-priority' flows (best-effort flows are not maintained) through concept of soft-state. When a node carries too many high-priority flows (or states) and can not be handled, INSIGNIA simply ignores/discards additional high-priority flows (and those denied ones will be treated as best effort flows). So, our definition of 'resources' are not limited to 'bandwidth' but includes others like 'buffer-occupancy', 'computational-power' and etc., ... anything that throttles the end-to-end QoS and INSIGNIA operations. -Seoung-Bum Lee- On Sat, 27 Apr 2002, Harpreet Arora wrote: > Hi, > > The Insignia approach does seem to be a good approach for QoS in MANETs, but > it is based on per flow guarantees, not per class, and thus can have the same > problems associated with Intserv model like scalability and implementation > issues. Each flow reserves resources at every node it passes through. THe FQMM > simply suggests that the highest class gets per flow provisioning, while the > lower classes get per class provisioning, so in essence the model adds the > complexity of the two models. And it does not suggest any means of > implementing the model in MANETs. The basic issue still remains of which node > will mark the packets so that the subsequent nodes can process them > accrodingly. If the source node does that job, then there is a good chance > that the node can misbehave and use a DSCP corresponding to a high priority > PHB even when it does not need to. In that case, who does the policing to stop > the flow? > > thanks, > Harpreet > > > >===== Original Message From yasser.lotfy@lycos.com ===== > >Good answer, > >Also, I'd to refer you to the INSEGNIA model, which provides a vihcle of > handling traffic between two nodes. The other model which provided some > enhancements to traditional DiffServ is the FQMM. > > > >Always try to distinguish signalling from the model. FQMM represent a model, > INSEGNIA is a model with it's own signaling approach. dRSVP is an ammendment > to RSVP. > > > >Ingress, and egress could be anynode. Ingress are always nodes initiating > traffic. Egress are those submitting traffic to different domain. > > > > > >Yasser > >Carleton University > > > >----------------------------------------------------------------- > >Hi Arora, > > > >Actually, diffserv pretty much acknowledges that every "core" node can just > >as easily also be an "edge" node, and may therefore have to worry about such > >complexities as access control from edge hosts. There is no attempt to > >prevent core nodes from being edge nodes. > > > >But diffserv does not get into any sort of signaling or access control > >mechanisms between diffserv nodes and edge user hosts. People have mentioned > >possible signaling mechanisms for use in diffserv nets, such as the RSVP > >PATH and RESV messages. But always, such discussions were cut short on the > >list, because they are not germaine to diffserv itself. > > > >What diffserv offers is really a set of per-hop behaviors that every > >diffserv node has to support as it routes diffserv-labeled packets. These > >PHBs, when aggregated across a diffserv routing domain, create so-called > >"per domain behaviors" for aggregated diffserv paths. That's it, pretty > >much. And the MIB/PIB needed for diffserv node management, of course. > > > >It seems difficult to be able to support diffserv routes with any sort of > >stability if the hops of any "aggregated path" come and go frequently, but I > >suppose this could make for an interesting research project! > > > >Bert > >albert.e.manfredi@boeing.com > > > > > >> -----Original Message----- > >> From: Harpreet Arora [mailto:ha33@drexel.edu] > >> Sent: Friday, April 26, 2002 2:50 PM > >> To: manet > >> Subject: [manet] QoS issues in MANETs > >> Importance: High > >> > >> > >> Hi, > >> > >> I am interested in finding the feasibility of a > >> differentiated services model > >> for MANETs. WHile thinking about the implementation of > >> diffserv in MANETs, I > >> came across the follwing problem : diffserv aims to push the > >> complexity to the > >> edge of the network, by dividing the network into edge and > >> core nodes. How can > >> we do this in a MANET? Specifically, how can we differentiate > >> the network of > >> nodes into edge and core nodes? Since the nodes are mobile, I > >> feel that every > >> node should have the capability of acting as an edge node, > >> which would mark, > >> meter and police the packets, and also as a core node, which > >> would simply > >> forward the packets on the basis of the DSCP. The nodes can > >> assume either > >> functionality depending on the situation. But what node assumes what > >> functionality is the question. Any suggestions? > >> > >> Harpreet > >> Research Assistant > >> ECE Department, Drexel University > >> Philadelphia, PA-19104 > >> > >> ******************************************************************** > >> A dream is just a dream. A goal is a dream with a plan and a deadline. > >> > >> A candle brightens the world around it. Unfortunately, it > >> creates a shadow of its own. It still serves the purpose it > >> is meant for. > >> ********************************************************************** > >> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www1.ietf.org/mailman/listinfo/manet > >> > > > > > > > > > >See Dave Matthews Band live or win a signed guitar > >http://r.lycos.com/r/bmgfly_mail_dmb/http://win.ipromotions.com/lycos_020201/ > splash.asp > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > Best Regards, ----------------------------------------------------- Seoung-Bum Lee COMET Group, Columbia University e-mail : sbl@comet.columbia.edu http://www.comet.columbia.edu/~sbl * Push your limits! ----------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-admin@ietf.org Tue Apr 30 23:26:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18289 for ; Tue, 30 Apr 2002 23:26:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13176; Tue, 30 Apr 2002 22:54:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13145 for ; Tue, 30 Apr 2002 22:54:27 -0400 (EDT) Received: from ocean (earth.ise.eng.osaka-u.ac.jp [133.1.52.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17867 for ; Tue, 30 Apr 2002 22:54:22 -0400 (EDT) Received: (qmail 21625 invoked from network); 1 May 2002 11:45:56 +0900 Received: from localhost (HELO Ricky) (127.0.0.1) by localhost with SMTP; 1 May 2002 11:45:56 +0900 Message-ID: <000c01c1f0bb$aadac860$9b01a8c0@ise.eng.osakau.ac.jp> From: "wooighee" To: "Luke Klein-Berndt" , References: Date: Wed, 1 May 2002 11:55:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] AODV control packet length: 32 bits ? 32 bytes? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Thank you for your advice. That means the Reserved Field in RREQ is 13 bits and the Reserved Field in RREP is 9 bits, right? Thank you. Regards, Ricky > Hi, > > That is probably 32 bytes - > RREQ are 24 bytes > RREP are 20 bytes > and RERR can vary in size. > > IP addresses are usaully 32 bits long (in IPv4). Sequence numbers in AODV > are also 32 bits. 32 bits translates into 4 bytes because there are 8 bits > in a byte. Here is an article which goes a little more in depth: > http://www.loadstar.com/articles/bytes.htm . > > Hope this helps, > > Luke Klein-Berndt _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From daemon@optimus.ietf.org Tue Apr 30 23:26:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18302 for ; Tue, 30 Apr 2002 23:26:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA14632 for manet-archive@odin.ietf.org; Tue, 30 Apr 2002 23:26:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13176; Tue, 30 Apr 2002 22:54:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13145 for ; Tue, 30 Apr 2002 22:54:27 -0400 (EDT) Received: from ocean (earth.ise.eng.osaka-u.ac.jp [133.1.52.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17867 for ; Tue, 30 Apr 2002 22:54:22 -0400 (EDT) Received: (qmail 21625 invoked from network); 1 May 2002 11:45:56 +0900 Received: from localhost (HELO Ricky) (127.0.0.1) by localhost with SMTP; 1 May 2002 11:45:56 +0900 Message-ID: <000c01c1f0bb$aadac860$9b01a8c0@ise.eng.osakau.ac.jp> From: "wooighee" To: "Luke Klein-Berndt" , References: Date: Wed, 1 May 2002 11:55:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] AODV control packet length: 32 bits ? 32 bytes? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Mobile Ad-hoc Networks X-BeenThere: manet@ietf.org Content-Transfer-Encoding: 7bit Hi, Thank you for your advice. That means the Reserved Field in RREQ is 13 bits and the Reserved Field in RREP is 9 bits, right? Thank you. Regards, Ricky > Hi, > > That is probably 32 bytes - > RREQ are 24 bytes > RREP are 20 bytes > and RERR can vary in size. > > IP addresses are usaully 32 bits long (in IPv4). Sequence numbers in AODV > are also 32 bits. 32 bits translates into 4 bytes because there are 8 bits > in a byte. Here is an article which goes a little more in depth: > http://www.loadstar.com/articles/bytes.htm . > > Hope this helps, > > Luke Klein-Berndt _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet